у меня поломалось когда я новые жирафовские функции заюзал) ServerErrors.INTERNAL_ERROR вместо setStatusCode 500 >=> text

А TaskBuilder.fs ты случайно при этом не юзаешь?

Не жирафовский, а отдельный.

да, жираф же теперь его референсит, а свой выкинул)

Это только в превьюшке, кажись?

нет, уже в стейбле

А, хорошо. А то народ жаловался, что у них всё поломалось как раз из-за этого.

Но теперь всё должно быть ок в этом плане, да.

Ну, у меня без хинта эта функция не собирается в принципе.

Ругается, что obj не умеет в GetAwaiter.

вызови ее со стрингом

ну или мою скопируй let httpGetString (url: string) = task { use client = new HttpClient() let! result = client.GetAsync(url) if (isNull result.Content) then return Error (result.StatusCode.ToString() + "|" + result.ReasonPhrase + " " + "Empty response") else let! resultString = result.Content.ReadAsStringAsync() if (result.IsSuccessStatusCode) then return Ok resultString else return Error (result.StatusCode.ToString() + "|" + result.ReasonPhrase + " " + resultString) }

я ее вместо f передаю

Ага, спасибо.

Vladimir Занятный баг.

Надо оформлять?

и интересно чей баг)

Я думаю, что это баг FCS.

В этих computational expressions вечно какая-то чертовщина творится.

Я говорил про баг с накатом-откатом какого-то старого PR, если что. Помните, на днях его обсуждали?

Угу. Про SRTP.

Надо оформлять?

если есть желание, я только за)

Угу. Про SRTP.

Там в TaskBuilder.fs из-за него что-то отъехало, и это ломало вывод типов (?)

Там в TaskBuilder.fs из-за него что-то отъехало, и это ломало вывод типов (?)

Но TaskBuilder.fs уже починили.

Мб у Владимира старый TaskBuilder?

А, у тебя-то новый, и ты воспроизвёл баг, ок.

у меня старый, не preview

Давайте превью попробуем?

Но TaskBuilder.fs уже починили.

Я проверил — да, починили только в RC.

https://github.com/rspeele/TaskBuilder.fs/commits/master вот история коммитов https://github.com/rspeele/TaskBuilder.fs/commit/9e2c178edca06c1179999cf4cc591caf4b0e4fae — баг исправили тут

Пример в тестах чем-то отдалённо напоминает ваш кейс.

Vladimir В превью все правильно выводится.

Хо!

@fvnever Спасибо.

Vladimir В превью все правильно выводится.

спасибо)

@forcewake Если кратко, потому что хочется писать веб в функциональном стиле. https://dusted.codes/functional-aspnet-core

я написал такой код, который пробрасывает результат http запрос let httpAction f (url: string) next (ctx : HttpContext) = task { let! stringResult = f url match stringResult with | Ok resultString -> Log.Debug("{Url} response {Response}", url, resultString) do! ctx.Response.WriteAsync(resultString) return Some ctx | Error (error: string) -> Log.Error("{Url} response error {Error}", url, error) return! ServerErrors.INTERNAL_ERROR error <| next <| ctx }

Кстати, в F# планируют добавить match!, чтобы не писать let! для промежуточного результата.

Кстати, в F# планируют добавить match!, чтобы не писать let! для промежуточного результата.

Вроде этого: async { match! fooAsync with | Ok p -> p |> ... | ... } ?

выглядит круто

Вроде этого: async { match! fooAsync with | Ok p -> p |> ... | ... } ?

Да.

Я джва года ждал эту фичу!

Спорная фича

Спорная фича

не понимаю такой логики. Старый вариант никто не отменяет же? Какие тогда могут быть проблемы от добавленной функциональности, если ты можешь её просто не использовать в кейсах, где она 'спорная'. Нет?

не понимаю такой логики. Старый вариант никто не отменяет же? Какие тогда могут быть проблемы от добавленной функциональности, если ты можешь её просто не использовать в кейсах, где она 'спорная'. Нет?

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

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

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

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

Читаемость кода это не улучшит

субъективно очень

по мне так лишние let всё портят, с точки зрения читабельности

Ну да, субъективно

и потому спорно)

Про let отдельный разговор

Это попытка смешать цепочку исполнения данных и то, как она будет исполнятся

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

Альтернативы?

Считать let и let! expression, not statement.

Подумать в сторону free monad etc для цепочки исполнения плюс обёртка для энвайронмента,в данном случае асинки

Подумать в сторону free monad etc для цепочки исполнения плюс обёртка для энвайронмента,в данном случае асинки

Правильный ответ был — asyncResult.

Не

Это опять смесь

Это опять смесь

Я не вижу проблемы.

С моей точки зрения, она есть

Если у тебя нет глубокой вложенности, то можно сделать явный match!, иначе asyncResult.

Но она достаточно неосязаема

Я просто хочу разделять поток преобразования данных и контекст исполнения

А я просто хочу писать код.

А я просто хочу писать код.

Ну код я пишу уже лет 17, хочется писать его более эффективно :)

Если не разделять, невольно начинаешь данные подгонять под контекст исполнения

Привет.

Приветствую господа

Зашёл на сайт и увидел что F# работает и в браузерах, каким образом не скажете?

Может ли данный язык являтся некой альтернативой для вычеслений заместо js?

Зашёл на сайт и увидел что F# работает и в браузерах, каким образом не скажете?

Компилируется в JS. http://fable.io/

@wardef Вот тут можно посмотреть пример фронта и бэка на F#. https://github.com/SAFE-Stack/SAFE-BookStore

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

Может ли данный язык являтся некой альтернативой для вычеслений заместо js?

Можно использовать в качестве альтернативы. Но нужно понимать, что придется жить в инфраструктуре .NET Core и JS одновременно.

Если хочется уйти и от .NET, и от JS, то стоит обратить внимание на язык Elm. Он неплохо прячет всё, что связано с джаваскриптом. :)

Если хочется уйти и от .NET, и от JS, то стоит обратить внимание на язык Elm. Он неплохо прячет всё, что связано с джаваскриптом. :)

У тебя опечатка в слове "PureScript"!

У тебя опечатка в слове "PureScript"!

Нет.

Если хочется уйти и от .NET, и от JS, то стоит обратить внимание на язык Elm. Он неплохо прячет всё, что связано с джаваскриптом. :)

Да, не, сам .net мне по душе с его clr, я просто не особо любитель js :)

У тебя опечатка в слове "PureScript"!

Смотрел доклады Алексея Пирогова?

Смотрел доклады Алексея Пирогова?

И доклады смотрел, и сам все эти скрипты смотрел. Elm видится каким-то не очень серьёзным, нишевым языком чисто для веб-фронтенда. В отличие от пурсы или того же Fable.

И доклады смотрел, и сам все эти скрипты смотрел. Elm видится каким-то не очень серьёзным, нишевым языком чисто для веб-фронтенда. В отличие от пурсы или того же Fable.

Вот это смех, типа purescript это не нишевый язык для поехавших фунциональщиков с 1.5 библтиотеками

Вот это смех, типа purescript это не нишевый язык для поехавших фунциональщиков с 1.5 библтиотеками

Ну, я поехавший, мне норм.

Осталось только Reason вспомнить, и на этой раздойдемся.

надо сделать чатик FSharp <| HolyWar

надо сделать чатик FSharp <| HolyWar

Для этого есть @dotnettalks.

Но он не решает проблему, если ты пришёл холиварить конкретно с F# разработчиками

Но он не решает проблему, если ты пришёл холиварить конкретно с F# разработчиками

Решает. Я обычно всех туда выгоняю.

Решает. Я обычно всех туда выгоняю.

Зачем, он если тебя там нет ?

Да, не, сам .net мне по душе с его clr, я просто не особо любитель js :)

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

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

А надо только с рантайм

Прямая трансляция с бирапа: тут только я пока)

Прямая трансляция с бирапа: тут только я пока)

Продолжаем следить за развитием событий))