доку уже дополнили про match! https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#match

лично мне и лишний let! не в падлу было написать)

Не,match! это круто

Не,match! это круто

ну удобно, но как-то вау эффекта не вызывает

Я жду, когда не нужно будет yield писать в списках.

Я жду, когда не нужно будет yield писать в списках.

вот это реально круто

ответ модератора прекрасен: https://forums.perforce.com/index.php?/topic/5657-p4merge-feature-request-respect-bom-presenceabsence-in-utf-8-files/

Уфф, вроде завелся нормально ui на акторах

Ух ты, билдеры снова вернулись в основной.

Ненадолго :)

Только теперь они называются ce

ке

К сожалению, конструктор объекта вида (a,b,c,..n) нельзя привести к виду a->b...

А ведь можно было бы делать красиво

ну, это логично. Конструктор должен быть как бы атомарен.

Он атомарен будет

Пока все параметры не заданы, его как бы нет

Пока все параметры не заданы, его как бы нет

Закаррируй руками.

Закаррируй руками.

Это возможно, но не очень интересно

Пока все параметры не заданы, его как бы нет

но это теоретически означает при наличии функции a -> b -> Class должен существовать способ b -> Class

т.е. способ получения объекта при наличии ТОЛЬКО b

Нет

Батл

Я согласен с нефтепродуктом

Ты забываешь, что а -> б -> с Превращаясь в б -> с хранит а в замыкании

Ты забываешь, что а -> б -> с Превращаясь в б -> с хранит а в замыкании

это верно только пока ты знаешь о замыкании. Наружу может торчать b -> c

Короче, я бы внес что-нить вроде op_Constructor

В компилятро

это верно только пока ты знаешь о замыкании. Наружу может торчать b -> c

Но а тоже есть. То что можно ф-цию каррировать это и так понятно, лол)

В общем, кто готов запилить?

Я бы другое сделал, автообёртку для всех функций из ванила либы вида: System.File.IO.WriteAllText(string path, string content) Хочу я например вот так делать object |> serialize |> fun x -> System.File.IO.WriteAllText(path, x) а хотелось бы так object |> serialize |> System.File.IO.WriteAllText path

Чтобы конструктор можно было получать паршиал апплаем

Ну это из той же оперы

но чтобы это компилировалось в обычный некарированный вид. просто удобный интерфейс из F#

Но, помнится, @gsomix приводил аргументы против

Только я их уже не помню

да я уверен тут подстав много, но мне вот хочется

Ну мне тоже хочется такого

Только надо обдумать, в каком виде

То ли через спец атрибут

да не, просто mscorlib весь)

другие либы не надо

Всегда можно написать tp

На типах

Кстати

О.о

КОторый этим будет аниматься

Ну, когда tp by types появятся

Т.е. суешь ему объект

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

И все довольны

https://medium.com/background-thread/the-future-of-programming-is-dependent-types-programming-word-of-the-day-fcd5f2634878

https://medium.com/background-thread/the-future-of-programming-is-dependent-types-programming-word-of-the-day-fcd5f2634878

"будущее" => "одно из направлений развития"

"будущее" => "одно из направлений развития"

Да, согласен. Слишком категоричный заголовок

Ок, и примеры надуманные опять.

Я из статьи не понял, шо это

Внезапно

Шо, опять? (с)

Мы чот алкаши, да. Но специально не договаривались)

Я из статьи не понял, шо это

А мне статья подтвердила моё представление о зависимых типах, но все ещё я не уверен, что это представление верное. Кстати - dependent types = HKT?

А мне статья подтвердила моё представление о зависимых типах, но все ещё я не уверен, что это представление верное. Кстати - dependent types = HKT?

Нет) хкт это генерики генериков. Т.е. Ещё более общие типы. Т.е. надмножества. А депендт типы это... Типы которые зависят от значений. Т.е. подмножества типов. Например из всех интов только четные.

Нет) хкт это генерики генериков. Т.е. Ещё более общие типы. Т.е. надмножества. А депендт типы это... Типы которые зависят от значений. Т.е. подмножества типов. Например из всех интов только четные.

Сложнее

А можно глупенький вопрос? чем отличаются такие проекты в плане философии? я думала, что это просто чтобы писать на чём-то нормальном, а потом транслировать в JS и запускать на каждом утюге

Ещё есть elm конечно, но там совсем другая философия.

А мне статья подтвердила моё представление о зависимых типах, но все ещё я не уверен, что это представление верное. Кстати - dependent types = HKT?

На самом деле для того, чтобы поиграться с зависимыми типами и получить базовое представление о них советую посмотреть на интерактивный онлайн туториал по F*, он достаточно понятный и при этом основные идеи донесет: https://www.fstar-lang.org/tutorial/

Первые части совсем простые, их можно быстро пройти

@AnutaU Elm крутится вокруг идеи замены JS, который нужно спрятать подальше.

Свой тулчейн, свои пакеты.

Fable и Bucklescript/Reason стараются наборот попроще взаимодействовать с JS.

а, чтобы ничего JSного вообще не трогать в процессе?

а, чтобы ничего JSного вообще не трогать в процессе?

Да.

Взамен получаешь гарантии — контроль эффектов.

Но идея глобально одинаковая - писать фронт на том же что и бэк/ писать фронт на чём-то приятном, сильно типизированном и т п?

Но идея глобально одинаковая - писать фронт на том же что и бэк/ писать фронт на чём-то приятном, сильно типизированном и т п?

Да.

окей :)

Чем я и хочу сейчас заняться!

я тоже примерно этим уже неделю хочу заняться

но происходит какой-то дурдом