а не, это я протупил) не заметил _ символ

А есть какие-то (эмпирические) правила когда надо ставить типы параметров?

Когда не компилируется, по идее

Когда не компилируется, по идее

Это как-то странно, в том же хаскеле обычно типы явно расставляют (хоть это не обязательно).

По идее,в больших проектах надо всегда ставить

Для облегчения понимания

Я обычно ставлю типы для всех функций, которые за пределами модуля видны.

Когда не компилируется, по идее

:D

Товарищи, есть тут кто знакомый с beam или с Core erlang?

https://github.com/fabrizioschiavi/pragmatapro отличный шрифт

и firaCode еще https://github.com/tonsky/FiraCode

и firaCode еще https://github.com/tonsky/FiraCode

Да, Fira Code для F# юзаю в VSCode - там есть красивый pipe оператор Для Kotlin/C#/Java - Hasklig - https://github.com/i-tu/Hasklig

https://github.com/fabrizioschiavi/pragmatapro отличный шрифт

но он платный)

https://www.visualstudio.com/ru-ru/news/releasenotes/vs2017-relnotes ctrl + f f#

https://github.com/Microsoft/visualfsharp/pull/2574

А мы и не знали https://i.gyazo.com/c3dd10a4b9ee2bc7b141bf807979e4a1.png

А мы и не знали https://i.gyazo.com/c3dd10a4b9ee2bc7b141bf807979e4a1.png

1c чтоу?

1c чтоу?

файлы с расширением *.bcl

Fira Code шикарен

https://github.com/kika/fixedsys — я олдскульщик и вот этот шрифтец юзаю :3

А у меня Consolas обыкновенный.

"Консолас обыкновенный" звучит как отрывок из заметок натуралиста.

:3

Лел

Кто какие фичи из 4.1 уже попробовал?

Кто какие фичи из 4.1 уже попробовал?

let mul2 x = x * 0____0___0__0_2 ?

0___0

Я тоже юзаю fira code

Жалко, что обычные кортежи в F# по умолчанию не struct.

Эта приписка struct не очень красиво выглядит. :(

А теперь никуда не денешься -- обратная совместимость.

https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1030-anonymous-records.md

https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1030-anonymous-records.md

Анонимные рекорды?

Этого иногда оч не хватало.

А теперь никуда не денешься -- обратная совместимость.

Если будут работать все те же ф-ции и паттерн матчинг что и с классическими кортежами, то тогда разница будет только при иницилизаии.

@neftedollar Ну, при инициализации, в типах, в паттернах надо struct расставлять.

@neftedollar Ну, при инициализации, в типах, в паттернах надо struct расставлять.

В паттернах печально

Привет, как можно это код проще написать (без Async.AwaitTask)? async { let! me = Async.AwaitTask(bot.GetMeAsync()) // C# 'Task<User> bot.GetMeAsync()' printfn "%O" me }

Async.AwaitTask

Тьфу

Проще вряд ли

Может можно какой-то оператор свой написать?

Мне тоже кажется, что проще уж не напишешь, если не впадать в крайности (и не навешивать Then, например).

Ой, или как его, ContinueWith

А какой тебе тут оператор нужен, что ты хочешь им делать?

А какой тебе тут оператор нужен, что ты хочешь им делать?

Убрать Async.AwaitTask (заменить на пару символов) - не эстетично

Я думаю, что можно попробовать написать свой computation expression для Task (а не для Async), но гемор лишний имхо.

Убрать Async.AwaitTask (заменить на пару символов) - не эстетично

А, ну дак let inline aat = Async.AwaitTask :)

Или даже обзови функцию await, будет веселуха.

let! me = await (bot.GetMeAsync()) — красота, а?

let waitTask=Async.AwaitTask

let waitTask=Async.AwaitTask

Интуиция подсказывает мне, что тут недостаёт либо inline, либо <_>. Обычно такие псевдонимы просто так не компиляются.

А, да

Тут резолв типа не сработает

Ну ладно, считай что мы тебя поняли :)

Но в целом это пример того, что интероп F# с C# пока не очень :)

Да ладно, тут всё норм.

Это интероп Task и Async не очень, да и то ещё под вопросом.

Если сильно хочется, можно такой же flow написать для Task<T>, и всё будет зошибись.

СКажем так, если хочется наружу из F# либы выдать интерфейс, похожий на C# придется поотжиматься

Да я не сказал бы, что это особо проблематично. Сам такие либы всю дорогу делаю :)

Просто не выставляешь наружу туплей, каррированных функций и Async заворачиваешь в Task. Ну и с нугетом немножко упражняешься, чтоб FSharp.Core оттудова подтягивался.

Да, код, который в публичном C#-совместимом слое, смотрится немного чужеродно (потому что я ещё и конвенции именования в нём соблюдаю). Но ничего критичного, на самом-то деле.

Может можно какой-то оператор свой написать?

Есть в fsharpx аналог async'a называется task.

Тоже монадки выражение. Работает с c# тасками

О, прекрасно.

Есть в fsharpx аналог async'a называется task.

Ну блин еще либы тащи сторонние (перебюсь await :)

As you wish) хотя да я бы в стандартную либу уже включил и работу с тасками.

Мусорная либа получится. И async, и task, которые делают одно и то же :(

По-хорошему бы тогда уж async выпилить или как-то заинтегрировать их оба вместе. Но язык так не умеет :(

Да, хотя для .net core это не проблема. Там и так тянутся куча либ и заменить например async либу на task либу было бы не плохо, но они скорее всего сами и так и так в зависимости подтянутся.

А task {} это один файлик

Все больше погружаюсь в интеропт с C# - возникла очередная проблема. Как в F# идиоматично подвесится на C# событие public event EventHandler<MessageEventArgs> OnMessage; VSforMac предлагает юзать add_OnMessage ...

Все больше погружаюсь в интеропт с C# - возникла очередная проблема. Как в F# идиоматично подвесится на C# событие public event EventHandler<MessageEventArgs> OnMessage; VSforMac предлагает юзать add_OnMessage ...

Да, правильно предлагает. Такие события (с одним аргументом) — та ещё задница. В F# с ними работать неудобно.

А, хотя постой, EventHandler<T> это же с двумя аргументами?

А, хотя постой, EventHandler<T> это же с двумя аргументами?

System.EventHandler<T> (sender: object, e: MessageEventArgs)

А, не, это на F#-события можно удобно подписаться. С такими придётся страдать :(

А, не, это на F#-события можно удобно подписаться. С такими придётся страдать :(

Скажи хоть как правильно страдать ?

Но ты попробуй Event.add на всякий случай.

По-моему, с какими-то событиями это работало — хотя я щас не смог найти в документации, с какими именно.

[<CLIEvent>]

https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/members/events

Не, [<CliEvent>] это в другую сторону — если ты C#-событие хочешь выставить.

let form = new Form(Text = "F# Windows Form", Visible = true, TopMost = true) form.MouseMove |> Event.filter ( fun evArgs -> evArgs.X > 100 && evArgs.Y > 100) |> Event.add ( fun evArgs -> form.BackColor <- System.Drawing.Color.FromArgb( evArgs.X, evArgs.Y, evArgs.X ^^^ evArgs.Y) )

[<CLIEvent>]

У меня стороная C# библиотечка с евентами, на которые нужно подписаться.

Во, вот да, Event.add работает.

Но я бы обертку сделал все же на стрим событий

Во, вот да, Event.add работает.

Работает ?, правда VSforMac все так же подчеркивает ошибку (ну да хрен с ней).

Но я бы обертку сделал все же на стрим событий

Это следующий шаг

Все больше погружаюсь в интеропт с C# - возникла очередная проблема. Как в F# идиоматично подвесится на C# событие public event EventHandler<MessageEventArgs> OnMessage; VSforMac предлагает юзать add_OnMessage ...

Я помню там свой Observable был, еще в F# 2, откуда Rx-то и пошел.

Но ты попробуй Event.add на всякий случай.

или это, да

let form = new Form(Text = "F# Windows Form", Visible = true, TopMost = true) form.MouseMove |> Event.filter ( fun evArgs -> evArgs.X > 100 && evArgs.Y > 100) |> Event.add ( fun evArgs -> form.BackColor <- System.Drawing.Color.FromArgb( evArgs.X, evArgs.Y, evArgs.X ^^^ evArgs.Y) )

Вот такое не работает разве? @angmarr

Вот такое не работает разве? @angmarr

Я же написал что работает, только ide ошибку подсвечивает, но все компилируется и это главное (мы же знаем какой в F# тулинг, особенно за пределами VS)

Я же написал что работает, только ide ошибку подсвечивает, но все компилируется и это главное (мы же знаем какой в F# тулинг, особенно за пределами VS)

а проект под xamarin ?