Ну если зависимость не кольцевая, все вроде и так ок должно быть

ну вообще полезно бывает вычислить на старте (например), а когда оно понадобится уже не ждать

Насколько я помню, на том же старте можно сделать через do

Ну если зависимость не кольцевая, все вроде и так ок должно быть

Ещё раз. ок - это когда ссылки вместе с объектами по ссылкам вычисляются в порядке их объявления (Go). В F# объекты, на которые ссылаются привязки let уровня модуля, вычисляются по требованию. И это не то что не ок, это ужос ужос, чревато NullReferenceException-ами и изрядным количеством обезьяньего кодинга

Ну объявляются же они в порядке вычисления, а не произвольно

Т.е. на текущий момент я не могу в f# использовать необъявленное значение

так в том то и дело что в F# объявлено != инициализировано, объявление вовсе не означает, что правая часть привязки будет вычислена к моменту её использования

Я правильно понимаю, что мы сейчас заходим в область ленивых/асинхронных вычислений?

А нет такой штуки, которая конвертирует C# в F#?

Нету.

Я правильно понимаю, что мы сейчас заходим в область ленивых/асинхронных вычислений?

уж и не знаю как ещё сказать по другому. По моему предельно ясно изложил. Вот пример https://gist.github.com/fpawel/6d7d99f3b4830a5161527e9cbe2e4faf Если не задать __DEBUG__ , то вывода не будет

Ох уж эта мемоизация...

мемоизация здесь совершенно не при чём

А ты поставь () в объявлениях x1 и x2

И в вызовах соответственнр

моя цель в данном случае заключается не в том, чтобы получить вывод в консоль, а в том, чтобы продемонстрировать баг

Ну надо тогда не на unit type

да там по фигу какой тип, совершенно фиолетово

Ну я бы все же попробовал с интом,например, чтобы исключить сайд эффекты

Ну я бы все же попробовал с интом,например, чтобы исключить сайд эффекты

Он сайд-эффекты и демонстрирует в этом коде :)

Ну я бы на сайд эффектах не стал писать

Ну я бы на сайд эффектах не стал писать

Видишь, тут нету такого выбора — писать или не писать. Нужно человеку инициализировать сторонние библиотеки, и он эту задачу будет решать, хочет или не хочет.

Привет :)

@ZloyTatarin Пожалуйте.

Здравствуйте

А у вас есть/будет/планируется курс по такого рода вещам?

Вообще уже сейчас есть курс на интуите. Я давно пробовал начинать его, но "повесился" ближе к середине как раз на тестах по таким штукам. Хотя может там и не так хардкорно как мне казалось, ибо это была моя первая серьезная попытка влезть в F#.

Ну я бы на сайд эффектах не стал писать

в таком случае ты пишешь только пруверы теорем на F* или Idris. Снимаю шляпу)

В чём разница между проектами FSharp.Data.DesignTime.fsproj и FSharp.Data.fsproj не знаете?

@Dolfik https://github.com/fsharp/FSharp.Data/blob/master/CONTRIBUTING.md#projects-and-multi-targeting

Ясно, спасибо

@Dolfik Хочешь поправить FSharp.Data, чтобы он поддерживал Mono 5?

@Dolfik Хочешь поправить FSharp.Data, чтобы он поддерживал Mono 5?

Не, я смотрел что там для кор требуется

@Dolfik Но зачем?

Ну, в смысле, erased providers должны работать под .Net Standard 2.0

А generative providers не будут работать, пока не завезут необходимые API.

Ну тогда забить на Funogram и пилить после .Net Standard 2.0

@Dolfik А что ты хотел из FSharp.Data использовать?

@Dolfik А что ты хотел из FSharp.Data использовать?

Json

JsonProvider?

Да

А erased providers это что такое?

По сути это хитрый трюк компилятора. Erased type provider "генерируют" типы, которые стираются после компиляции.

А generative providers генерируют настоящий IL код.

В сборку, сгенерированный код потом можно использовать в даже C#.

И чем generative лучше erased? Производительность?

Generative дает настоящие типы, которые могут хранить состояние, лежат в сборке, их можно использовать из остального дотнета.

Видишь, тут нету такого выбора — писать или не писать. Нужно человеку инициализировать сторонние библиотеки, и он эту задачу будет решать, хочет или не хочет.

Я понял, что меня смущает-пример вырожденный,и почему не работает, тоже более-менее понятно

С чёрненьким мне почему-то больше нравится.

Контрастнее что ли

Там реально недетерменированное поведение-зависит от того, когда консоль инициализируется.А второй раз не выполняется как раз из-за мемоизации функций без параметров

С чёрненьким мне почему-то больше нравится.

Хотя на тёмной поверхности белая наклейка, возможно, будет лучше смотреться.

Как наклейка лучше пойдет светлый вариант. Хотя так темный и выглядит приятнее

Я понял, что меня смущает-пример вырожденный,и почему не работает, тоже более-менее понятно

никакой мемоизации там нет никаких функций без параметров там нет пример отражает практику, которая используется чуть более чем во всех продовых проектах - банальная инициалзация повторно используемого объекта в модуле поведение абсолютно детерминированное - и глупое. Связано с тем, что авторы языка хотели исключить неиспользуемые вычисления. Но вместо того, чтобы проверить при компиляции востребованность _всех_ объявлений в модуле (опять таки как в Go), сделали как в Ocaml.

Обе хороши

Спасибо за мнения, ребята! Пошаманю с векторами, скину исходники, как будет готово. Потом можно будет на мероприятиях раздавать!

Ноут только для этого купить осталось ?

немножко оффтопа про дядюшку боба. Тут вроде кто-то удивлялся чего это я его не уважаю www.youtube.com/watch?v=e-p35Z3Z7DI - типичная проповедь ООП))

Жалко, что в CLI нельзя делать generic-полей.

Я все еще не понимаю, причем здесь generic-поля. let notNull = not << isNull не работает, потому что компилятор не может генерализовать значение. Если, например, явно прописать все generic параметры, то данная функция скомпилируется в internal класс и статический generic-метод, возвращающий инстанс этого класса.

Белые границы

Хотя оба

Мне кажется нужна и белая и чёрная

Там в svg VS code-ом можно цвет фона махнуть при желании )

SVG вообще офигенский формат.

@susloparov Привет!

@Worldbeater Спасибо!

Черный покрасивше

в зависимости от крышки ноута на самом деле

На светлую с черной рамкой, на свой (у меня темный люминий) с белой каймой

Я все еще не понимаю, причем здесь generic-поля. let notNull = not << isNull не работает, потому что компилятор не может генерализовать значение. Если, например, явно прописать все generic параметры, то данная функция скомпилируется в internal класс и статический generic-метод, возвращающий инстанс этого класса.

Это определение не работает потому, что компилятор *не хочет* генерализовать значение. Даже если прописать генерик-параметры (let notNull<_> = ...) — всё равно не заработает, потому что генерик-полей и переменных в CLI не бывает. (Хотя, может, оно и к лучшему — они могут вызывать путаницу.)

@fvnever Я не могу согласиться.

@fvnever let notNull<'a when 'a : null> : 'a -> bool = not << isNull

Хм.

Посмотри, заодно, во что это компилируется.

А чо оно тогда с <_> не хочет?

@fvnever Да, компилятор действительно не хочет генерализовывать значение, потому что в некоторых случаях это может привести к неправильному поведению.

@fvnever Рекомендую к вечернему прочтению. https://blogs.msdn.microsoft.com/mulambda/2010/05/01/finer-points-of-f-value-restriction/

а зачем нужна такая функция notNull ? код с ней короче не будет, зато будет более запутанным

Как это не будет?

Вместо if (not << isNull) x пишешь if notNull x.

Намного короче, как по мне.

И читабельнее — не путаешься во всех вот этих >> << |<|

tl;dr So when it is safe to automatically generalize? It is hard to argue precisely, but one simple answer suggests itself: generalization is safe if the expression on right-hand side of “let” both: - is side-effect free (also known as pure) - produces an immutable object

И там еще немного про аннотации [<GeneralizableValue>] и [<RequiresExplicitTypeArguments>].

Хорошая статья.

Вместо if (not << isNull) x пишешь if notNull x.

не-а) нормальный код - это if x <> null))))

@ruzzke_mir Это плохой код.

http://latkin.org/blog/2015/05/18/null-checking-considerations-in-f-its-harder-than-you-think/

Ну смотри... x - это nullable, default(a) - статический null. Код GenericEqualityObj аналогичен Object.ReferenceEquals. В чём проблема то?

@ruzzke_mir В производительности. https://stackoverflow.com/questions/6817852/handling-null-values-in-f/6818329#6818329

В F#4.0 добавили isNull. И это самый правильный сейчас способ сравнивать с null.

obj.ReferenceEquals (x,null) vs. isNull x - ну офигеть как проще стало )

@ruzzke_mir В производительности. https://stackoverflow.com/questions/6817852/handling-null-values-in-f/6818329#6818329

Не вижу каким образом If you have a type that has been declared in C# or a .NET library in general (not in F#) then null is a proper value of that type and you can easily compare the value against null as posted by kvb. а для других значений, которые из F#, операция сравнения с null как минимум странная