Блокчейн на F#!

https://github.com/bitcoinfs/bitcoinfs - пожалуйте :)

В группе ризонмл тоже спам

Довольно безобидный. Вдруг кто-нибудь и правда пойдет блокчейн хахатонить. :)

В группе ризонмл тоже спам

Да, и в кложачатике спам. Жги!

У них там ещё мутный договор оферты.

https://github.com/fsprojects/FSharpLint/blob/master/README.md

Не знал о такой штуке

https://twitter.com/JetBrainsRider/status/976151384432300032

Upgraded support for F# scripting: - Navigation commands such as Search Everywhere, Go to Symbol, Go to File Member, Find Usages, and Viewing File Structure, and as well as #load directives, all work correctly. - Smart Code Completion for files in directives provides all the applicable files from subdirectories and inserts the relative path. - Code Completion, highlighting, and analysis work as expected.

@auduchinok ?

Когда ж релиз

@auduchinok ?

Остались порядок файлов и мультитаргетинг из обещанного родмапа. :)

Остались порядок файлов и мультитаргетинг из обещанного родмапа. :)

А это будет в последующем встраиваться в каком-то виде? https://github.com/fsprojects/Mechanic

Пока не придумал, зачем. У нас будет drag-and-drop для редактирования порядка.

Хотя идея про "подвинь, насколько можешь" интересная.

@auduchinok Больше всего не хватает ренейма типов и типов над функциями.

Кстати 15.6.3 студия опять с багами. Теперь мультитаргетинг в проетах отвалился.. Билд не проходит нормально.

Правда это С№

Ivan И то, и другое сейчас в планах на 2018.2.

Для последнего жду поддержки в API решарпера/райдера.

То есть этого куска из идиа еще не прокинули?

Ага. И тут нужно этому сначала научить решарпер, а потом прокидывать в идею.

А не проще было нучить идию кушать langauge service, а уже из него выбрасывать общий интерфейс для решарпера?

Тут заодно кучу готовых для вс коде подтянуть можно ?

Тут заодно кучу готовых для вс коде подтянуть можно ?

Кучу готовых чего?

Сервисов. Там под раст и под что то еще есть

https://twitter.com/zaid_ajaj/status/976157720331120640

https://twitter.com/zaid_ajaj/status/976157720331120640

Было бы круто такое для вебсокетов или хотя бы для signalr

Привет.

Обновил вчера студию, думал пофиксили билд проекта с ресурсами, фиг там) Error writing code fragment: System.Exception: Language name must be F# at Microsoft.FSharp.Build.WriteCodeFragment.Microsoft-Build-Framework-ITask-Execute()

Обновил вчера студию, думал пофиксили билд проекта с ресурсами, фиг там) Error writing code fragment: System.Exception: Language name must be F# at Microsoft.FSharp.Build.WriteCodeFragment.Microsoft-Build-Framework-ITask-Execute()

Они все запороли,у меня теперь обычный фшарп проект не открывается

Ну у меня открывается, через студию билд тоже работает, только через dotnet build не работает как и раньше

А откуда в проекте берутся F# build targets и FSharp.Core.dll? Если используется FSharp.Compiler.Tools и FSharp.Core из нюгетов, то проблем быть не должно. Много старых шаблонов рассчитывали на то, что эти файлы живут в SDK из студии, но в обновлении папка с SDK переехала, сломав старые шаблоны.

Они все запороли,у меня теперь обычный фшарп проект не открывается

> Since then, it's been a long process where we didn't just decide to implement C# as a subset of F# - that would be one way you could do it O_o

Интересное получилось бы решение.

> Since then, it's been a long process where we didn't just decide to implement C# as a subset of F# - that would be one way you could do it O_o

Кажется, компилятор Nemerle поддерживает режим, в котором компилирует C#.

(ну, наверное, старый C# теперь уже)

В итоге получилось, довольно неплохо. Хотя ОО часть выглядит совсем непривычно для тех, кто приходит из C#.

С одной стороны концептуальные правильные вещи, вроде явного self-referential связывания через бесконечные __, x, this, параметризация вместо наследования, иммутабельность.

С другой — неприятные синтаксические решения. Ну, кто помнит, как ОО писать в F#? Я всегда в доку лезу.

Дизайн — это сложно. :)

> Since then, it's been a long process where we didn't just decide to implement C# as a subset of F# - that would be one way you could do it O_o

Кто и где сие сказал?

Кто и где сие сказал?

https://www.infoq.com/interviews/F-Sharp-Don-Syme

С другой — неприятные синтаксические решения. Ну, кто помнит, как ОО писать в F#? Я всегда в доку лезу.

Я помню)

Я вечно путаюсь, как свойства объявлять.

С одной стороны концептуальные правильные вещи, вроде явного self-referential связывания через бесконечные __, x, this, параметризация вместо наследования, иммутабельность.

Концептуально отличные вещи, реализация интерфейсов по мне так зкмечательная

Я вечно путаюсь, как свойства объявлять.

А это, я тоже, да)

Стыдно спрашивать, но всё же, подскажите, пожалуйста, должен получиться метод с такой логикой: let set (value : 'a) : string = match value with | :? (sbyte<a b>) as s -> "is sbyte<a b>" | :? (int<a c>) as s -> "is int<a c>" | :? (int<d>) as s -> "is int<d>" | _ -> "is unknown" Как нужно ограничить 'a или чем заменить, чтобы заработало? Использую вот эти docs.microsoft https://docs.microsoft.com/ru-ru/dotnet/fsharp/language-reference/generics/constraints как примеры основ ограничений шаблонов, но не вижу тут как сделать ValueType<[<Measure>] 'm>.

@yerumaku А что ты пытаешься сделать?

Я не очень понимаю. a b, a c и d — это единицы измерения? Они стираются в рантайме, а :? — это рантаймовая проверка.

Я не очень понимаю. a b, a c и d — это единицы измерения? Они стираются в рантайме, а :? — это рантаймовая проверка.

единицы имерений да, стираются, можно это предовратить?

@yerumaku А что ты пытаешься сделать?

понять какое masute и тип значения (int, float, sbyte)

Можно описать discriminated union. type DomainValue = | AB of sbyte<ab> | AC of int<ac> | D of int<d> И с такой штукой как-то работать: правильно создавать, передавать, делать match.

Units of measure (UoM) в F# — это бесплатная штука для некоторой дополнительной типизации всякой арифметики. Бесплатная, потому что UoM существуют только на этапе компиляции, а потом стираются.

Если информация о единицах измерения нужна в рантайме, то, конечно, нужно работать с discriminated union, кейсы которого будут отображать величины из твоего домена.

понять какое masute и тип значения (int, float, sbyte)

Нужно помнить, что :? — это динамическая проверка типа в рантайме, которая для типов значений требует боксинга. Это плохое решение с точки зрения статической типизации. Лучше смоделировать свой домен в терминах кейсов discriminated union.

Guid<userId> - вместо single case unions

Guid<userId> - вместо single case unions

Я бы предпочел single case DU все-таки.

А UoM оставил для арифметики.

Их значениями рекордов неудобно

Полей рекордов

Нужно помнить, что :? — это динамическая проверка типа в рантайме, которая для типов значений требует боксинга. Это плохое решение с точки зрения статической типизации. Лучше смоделировать свой домен в терминах кейсов discriminated union.

По итогу нужно, чтобы в метод приходило значение неизветного численного типа с неизветными единицами измерений, а дальше *главное* определить какие единицы измерений

По итогу нужно, чтобы в метод приходило значение неизветного численного типа с неизветными единицами измерений, а дальше *главное* определить какие единицы измерений

Ну, я говорю, что так не получится сделать. :)

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

Ну, я говорю, что так не получится сделать. :)

Допускаем тогда, что мы знаем, что это float, sbyte или int (пусть три функции), тогда можно как-то выудить какие единицы измерений?

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

Оу, спс

Кстати, а в 4.1 Single Case Unions сделали бесплатными?

Как в хаскеле

Кстати, а в 4.1 Single Case Unions сделали бесплатными?

Их можно скомпилировать с структурку, если повесить атрибут.

Еще такой вопрос по DU, указывать внутри ветви числовые типы как ref это _плохо_ и возбраняется сообществом?

Еще такой вопрос по DU, указывать внутри ветви числовые типы как ref это _плохо_ и возбраняется сообществом?

А какая цель?

А какая цель?

Хранить значение, потом менять значение. Идти по перезаписи ветки DU желательно?

Видимо цель - сделать сложно :-)

Хранить значение, потом менять значение. Идти по перезаписи ветки DU желательно?

Плохо и возбраняется. Лучше делать иммутабельно.

Плохо и возбраняется. Лучше делать иммутабельно.

Думал над этим, ведь если нужно поменять значение в ветви DU, но внути DU всё неизменяемо, тогда придётся перезаписывать весь DU, что сводит опять к вопросу мутабельности, нормально ли так делать? Объявить ветвь как изменяемую

На низком уровне это выглядит так: принимаешь в функцию одно значение DU, возвращаешь другое.

Где-то снаружи у тебя, конечно, может существовать что-то вроде хранилища значений. Ну, пусть оно будет мутабельное, это необходимое зло.

Где-то снаружи у тебя, конечно, может существовать что-то вроде хранилища значений. Ну, пусть оно будет мутабельное, это необходимое зло.

Дело в том, что мутабельных элементов должно быть очень много. Пусть есть мутабельное хранилище, внутри него списки объектов, которые имеют изменяемые параметры, то есть ФП поддталкивает удалять из списка объект, заменяя его неполной копией (чтобы объекты были не изменяемыми)?

ФП подталкивает создавать новый список с измененными элементами. ;)

ФП подталкивает создавать новый список с измененными элементами. ;)

Ну да-да, то есть память будет постоянно расходоваться на каждую такую маленькую операцию, перезаписывающую вообще все данные, которые в общем-то ёмкие.

Есть ответ и на эту ситуацию.

Ну да-да, то есть память будет постоянно расходоваться на каждую такую маленькую операцию, перезаписывающую вообще все данные, которые в общем-то ёмкие.

неизменяемые данные легче эффективно хранить в памяти и собирать сборщиком мусора

неизменяемые данные легче эффективно хранить в памяти и собирать сборщиком мусора

Тут такие данные, которые GC не должен чистить до выхода из приложения

Ну да-да, то есть память будет постоянно расходоваться на каждую такую маленькую операцию, перезаписывающую вообще все данные, которые в общем-то ёмкие.

Необязательно перезаписывать все данные. Есть эффективные структуры данных, позволяющие перезаписывать только некоторую часть, которую необходимо изменить.

Если и это не подходит, например, у тебя очень критический к производительности код, тогда стоит прибегнуть к мутабельности.

Стандартное правило: сначала бенчмаркаешь, потом решаешь, что делать.

Если и это не подходит, например, у тебя очень критический к производительности код, тогда стоит прибегнуть к мутабельности.

Например?

Например?

Ну, массивы, let mutable, ref. Вся вот эта нечисть. :)

Это вопрос баланса.

Ну, массивы, let mutable, ref. Вся вот эта нечисть. :)

Пример критически важного к производительности кода

Пример критически важного к производительности кода

Например, математические расчеты. Но они хороши тем, что их можно в кишки функций прятать.

Или веб-сервера, или какие-то системы обработки информации с датчиков, и так далее, и тому подобное.

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

Для этого тоже есть свои решения.

Но правило, кажется, одно: сначала бенчмарки, потом думать. :)