чат это конечно круто. Но я могу зашедулить митинг с Доном

Хех.

Я точно кого-то мог забыть, не серчайте.

Спасибо)

Ну, и милых дам поздравляем с праздником. :)

Спасибо! ?

Ну, и милых дам поздравляем с праздником. :)

А остальных, не милых, не поздравляем

Спасибо!

А остальных, не милых, не поздравляем

Право, у нас таких и нет.

@gsomix Привет!

Завтра в 5 в ресторане брюссель столик на имя Дона Сайма, Москва

Кстати, он должен пиво @gsomix

Блин, не читайте до обеда /r/fsharp.

Там какой-то псих грозится написать куда-то в MSFT, чтобы VF# PM уволили. :)

Блин, не читайте до обеда /r/fsharp.

Там странный сабреддит

Блин, не читайте до обеда /r/fsharp.

А что там?

А что там?

Там какой-то псих грозится написать куда-то в MSFT, чтобы VF# PM уволили. :)

Там какой-то псих грозится написать куда-то в MSFT, чтобы VF# PM уволили. :)

Visual F#??

А что там?

Я предупредил. https://www.reddit.com/r/fsharp/comments/82eofe/improvements_for_f_in_visual_studio_2017_release/

Visual F#??

Ага.

Ага.

Эм... Много курили перед тем как это придумать?

Эм... Много курили перед тем как это придумать?

Ты о чем?

Об этой концепции. Блин. Ладно

Об этой концепции. Блин. Ладно

Ну, Visual C++, Visual F#. Стандартное именование тулинга для языков в Visual Studio.

А, ок. Значит я не так воспринимал это слово.

У меня перед глазами возник билдер для формочек.

У меня перед глазами возник билдер для формочек.

https://github.com/Microsoft/visualfsharp же, ну.

Под этим брендом у нас по факту компилятор + интеграция со студией + FSharp.Compiler.Service, который используется для разработки некоторых других вариантов тулинга.

У меня перед глазами возник билдер для формочек.

А было бы не плохо для подаванов

https://www.contino.io/insights/comparing-aws-lambda-runtime-performance-across-go-net-core-2-0-node-js-java-and-python

Какой самый простой способ к IEnumerable<T> добавить элемент T и получить опять IEnumerable<T>?

Какой самый простой способ к IEnumerable<T> добавить элемент T и получить опять IEnumerable<T>?

.Concat(new[] { t }) :C

seq.Concat я и видел, как-то вариант не очень)

Да, не очень.

Какой самый простой способ к IEnumerable<T> добавить элемент T и получить опять IEnumerable<T>?

yield?

seq { yield! s; yield t }

Типа такого чтоль?

но так ведь нельзя добавлять много элементов, разве нет?

не будет stack overflow?

Гм, хороший вопрос.

seq { yield! s; yield t }

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

я почти уверен, что будет stack owerflow

если много добавить

в моем случае много не будет

yield?

спасибо)

А откуда там быть stack owerflow? Генераторы разве на рекурсии работают? https://sharplab.io/#v2:DYLgZgzgNAJiDUAfYBTALgAglgjBleAvFigI4YDeGAngJYrAwCEuA3DfY/ngL4ZA - вот тут похоже что, как и в C#, для yield создается класс с конечным автоматом.

А откуда там быть stack owerflow? Генераторы разве на рекурсии работают? https://sharplab.io/#v2:DYLgZgzgNAJiDUAfYBTALgAglgjBleAvFigI4YDeGAngJYrAwCEuA3DfY/ngL4ZA - вот тут похоже что, как и в C#, для yield создается класс с конечным автоматом.

на SO нарваться можно в некоторых вариантах

https://twitter.com/atlerudshaug/status/971472604610605057?s=19

В каких?

В каких?

Сравни. let rec nat i = seq { yield i; yield! nat (i+1) } let rec natF i = seq { if i >= 0 then yield! natF (i-1); yield i }

Сравни. let rec nat i = seq { yield i; yield! nat (i+1) } let rec natF i = seq { if i >= 0 then yield! natF (i-1); yield i }

Если явно указана рекурсия, то возможность SO по крайней мере ожидаема:) Но меня смутило бы, если бы я мог получить SO при использовании генераторов без rec.

Если явно указана рекурсия, то возможность SO по крайней мере ожидаема:) Но меня смутило бы, если бы я мог получить SO при использовании генераторов без rec.

Ну, рекурсия — это такой способ добавить много элементов, как говорил @fillpackart.

Кстати я сейчас позапускал - SO нет :) Оптимизация хвостовой рекурсии сработала, похоже.

Кстати я сейчас позапускал - SO нет :) Оптимизация хвостовой рекурсии сработала, похоже.

Как запускал?

Как запускал?

let rec nat i = seq { yield i; yield!nat(i + 1) } nat 1 |> Seq.length |> Dump

natF должен падать, потому что там никакой хвостовой рекурсии нет.

просто бесконечно крутится

просто бесконечно крутится

Так nat и не падает. :)

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

Просто господин @fvnever написал в примере вставку в конец, а я гиперболизировал ее в natF.

Да, natF упала, я количество итераций первоначально задал слишком маленьким)

А почему не let rec natF i = seq { yield! natF(i+1); yield i } ?

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

А почему не let rec natF i = seq { yield! natF(i+1); yield i } ?

Ну, эту штуку же нельзя вычислить.

+

Ну, эту штуку же нельзя вычислить.

Понятно. Переписал немного, теперь для меня стало все наглядно. Спасибо :) let iters = 100000 let rec nat i = seq { yield i; yield! nat(i + 1) } let rec natF i = seq { yield! natF(i + 1); yield i } let test fn = fn 0 |> Seq.take iters |> Seq.length |> printf "%i" test nat test natF

Так что в итоге? Кларифицируйте, коллеги

Так что в итоге? Кларифицируйте, коллеги

Если yield! в tail call позиции, то все хорошо.

Но хотелось бы предупреждений от компилятора. https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1011-warn-on-recursive-without-tail-call.md

т.е. в итоге, если я создам функцию let add item seq = { yield! seq yield item } то я рискую?

а если let add item seq = { yield item yield! seq } то всё ок? или я не правильно понимаю?

т.е. в итоге, если я создам функцию let add item seq = { yield! seq yield item } то я рискую?

Да.

потому что компиль может с оптимизировать второй кейс, верно?

т.е. суть в том, что я не должен 'использовать' возвращаемое значение yield!

потому что компиль может с оптимизировать второй кейс, верно?

Да.

ясно, спасибо.

@fillpackart Ты и сам можешь проверить, это на пять минут развлекуха.

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

Всем привет) Я снова с насущными проблемами пришел)

я написал такой код, который пробрасывает результат 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 }

val f: : string -> Threading.Tasks.Task<Result<string,string»

Если вместо Error (error: string) -> написать Error error -> то у stringResult тип становится Result<string, obj> вместо Result<string, string>, что приводит к ошибке "Unable to cast object of type 'System.Threading.Tasks.UnwrapPromise`1[Microsoft.FSharp.Core.FSharpResult`2[System.String,System.String]]' to type 'System.Threading.Tasks.Task`1[Microsoft.FSharp.Core.FSharpResult`2[System.String,System.Object]]'."

Собственно вопрос в том - почему тип stringResult определяется по матчингу, а не по функции f

А это не тот самый баг, об который народ спотыкается всю прошлую неделю?

Собственно вопрос в том - почему тип stringResult определяется по матчингу, а не по функции f

Компилятор не знает, какой тип у f.

Знает, я же написал

val f: : string -> Threading.Tasks.Task<Result<string,string»

вот

А это не тот самый баг, об который народ спотыкается всю прошлую неделю?

не знаю, может быть)

вот

Если там у аргумента функции аннотировать — не помогает?

я написал такой код, который пробрасывает результат 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# ? Просто потому что так хочется?)

А можно чуть-чуть холиварный вопрос - зачем такое писать на f# ? Просто потому что так хочется?)

Холивары потом, сейчас надо проблему решить.

Если там у аргумента функции аннотировать — не помогает?

помогает) интересно тогда откуда интелисенс там стринг пишет)

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

То есть он вывел для httpAction сигнатуру со строкой?

да

и в VS и в VSCode

и в VS и в VSCode

Ну, компилятор-то один и тот же там :)

Как бы это быстро воспроизвести.

Жираф к проекту подключить

Пожалуй, попробую.

тулинг сейчас должен все неймспейсы разрулить сам)