А можно простой пример как это выглядит?

https://github.com/dotnet/csharplang/issues/164 — вот тут глянь секцию "Implementation".

https://github.com/dotnet/csharplang/issues/164 — вот тут глянь секцию "Implementation".

спасибо

есть ли типы, которые моно использовать только внутри бидонов?

*билдера?

есть ли типы, которые моно использовать только внутри бидонов?

Роман, я обожаю твоё автодополнение :)

https://github.com/dotnet/csharplang/issues/164 — вот тут глянь секцию "Implementation".

я имел в виду как это на F# выглядит

типа graph { let a = myTypeConstructFunction() let b = another () return a+b}

Роман, я обожаю твоё автодополнение :)

:)

типа graph { let a = myTypeConstructFunction() let b = another () return a+b}

Тут на самом деле a+b должно бы раскрыться в graph.Add(a,b)

я имел в виду как это на F# выглядит

Не, я на C# так фигачу. На F# обычно (пока что) хватает выпендрежа на инлайнах. А вот можно ли на F# составить такие конструкции — это вопрос, на самом деле. Зависимость между генерик-аргументами же не получалось построить?

Не, я на C# так фигачу. На F# обычно (пока что) хватает выпендрежа на инлайнах. А вот можно ли на F# составить такие конструкции — это вопрос, на самом деле. Зависимость между генерик-аргументами же не получалось построить?

ну так вроде FSharpplus именно про это. Не, на инлайнах не то. Я почему спросил - когда-то давно пробовал по приколу сделать windows forms контролы аппликативами с помощью Fsharpplus (как раз таки для декларативного описани UI, за которое вчера говорили)

Хмм, интересно!

было бы интересно, если бы получилось) а так - пшик, не более. трихомонада не выросла одним словом)

а получалось ли у кого-нибудь подружить свои кастомные computation expressions с async?

А в чем там может быть проблема?

Там же вроде внутри реализации bind вызываешь Async.Нужная ф-ция и все ок

let r2=async{ return req{ header "Authorization" "Basic" header "MyHeader" "MyValue" } }

сейчас

а получалось ли у кого-нибудь подружить свои кастомные computation expressions с async?

type TestAsyncBuilder(name, focusState) = ... member __.Bind(p1, p2) = async.Bind(p1, p2)

https://github.com/haf/expecto/blob/master/Expecto/Expecto.fs#L1389

https://github.com/haf/expecto/blob/master/Expecto/Expecto.fs#L1389

то что надо, спасибо!

была мысль попробовать что-то вроде этого - https://stackoverflow.com/a/4306711

но т.к. сейчас почти все асинхронное, то надо еще и асинк как-то туда прикручивать

Ну введи кастомную операцию Async

По ссылке интересная концепция репозитория

В теории, можно сделать ее интереснее\

ну у меня была мысль все сайд эффекты обернуть в IEnvironment :)

но т.к. сейчас почти все асинхронное, то надо еще и асинк как-то туда прикручивать

кстати если тупо всё делать асинхронным, следуя "моде", можно напороться на страшные грабли. Например выбор между какой нибудь WebClien.Download и WebClient.DownLoadAsync по умолчанию ВСЕГДА в пользу первой синхронной версии - если только нет действительно веских оснований брать вторую асинхронную

ну веб-клиентовский DownloadDataAsync вообще не про новый async

а в целом - конечно, думать надо)

Ну всегда можно HttpClient.SendRequest завернуть в async внутри своего кода

Нафиг тащить c# имплементацию, неясно

"Нафиг тащить c# имплементацию, неясно" - например чтобы иметь возможность нормально отменить асинхронное вычисление, А не ждать комплита какого нибудь часового лонгпола.

кстати если тупо всё делать асинхронным, следуя "моде", можно напороться на страшные грабли. Например выбор между какой нибудь WebClien.Download и WebClient.DownLoadAsync по умолчанию ВСЕГДА в пользу первой синхронной версии - если только нет действительно веских оснований брать вторую асинхронную

С общим посылом я согласен, но в чём конкретная проблема WebClient.DownloadAsync?

вообще я не знаю ни одного программиста (включая себя) который бы умел правильно раставлять асинки и авэйты.

вообще я не знаю ни одного программиста (включая себя) который бы умел правильно раставлять асинки и авэйты.

Учитывая, во что это под капотом разворачивается, неудивительно :)

"Нафиг тащить c# имплементацию, неясно" - например чтобы иметь возможность нормально отменить асинхронное вычисление, А не ждать комплита какого нибудь часового лонгпола.

Да, согласен. В целом есть Async.FromTask

"Нафиг тащить c# имплементацию, неясно" - например чтобы иметь возможность нормально отменить асинхронное вычисление, А не ждать комплита какого нибудь часового лонгпола.

в Async тоже его можно отменить, насколько я понмю там есть и канселэйшн токены и таймаут можно явно указать.

С общим посылом я согласен, но в чём конкретная проблема WebClient.DownloadAsync?

в await шедулер может распаралелить вычисления. Это очень тяжко дебажить и иногда приводит к совсем уж фантастическим гонкам данных - в агентах,например. Я как то раз долго не мог въехать какого хрена у меня агент одновременно пишет в базу. Очень трудно просчитать все ветвления control flow при одновременности, а любой async увеличивает их количество эксполненциально. Но конечно для хелуворда пофиг)

а никто не знает, почему FAKE в ionide не встроили в стандартный таскраннер для VSCode? как напримерс gulp сделали

в Async тоже его можно отменить, насколько я понмю там есть и канселэйшн токены и таймаут можно явно указать.

попробуй отмени вот это async { System.threading.Thread.Sleep(100500 * 100500) } |> Async.Start

попробуй отмени вот это async { System.threading.Thread.Sleep(100500 * 100500) } |> Async.Start

ну так говнокод же.

попробуй отмени вот это async { System.threading.Thread.Sleep(100500 * 100500) } |> Async.Start

тут можно даже в async не заворачивать, ща проверю.

говнокод не говнокод, но Sleep ты хрен-с-два отменишь в safe коде

Как и любое вычисление, в которое не проброшен CancellationToken.

говнокод не говнокод, но Sleep ты хрен-с-два отменишь в safe коде

так это к async не относится

ты и в Task его не отменишь. Не пользуйся Thread.Sleep для того чтоб что-то ждать. Пользуйся Task.Delay

так речь шла про то, почему не надо заворачивать HttpClient.SendRequest в async. Потому что он ни чем не оличается от Sleep

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

так речь шла про то, почему не надо заворачивать HttpClient.SendRequest в async. Потому что он ни чем не оличается от Sleep

Если есть только синхронная функция (какой-нибудь File.Exists), то можно и завернуть.

Я, кстати, всегда дико печалюсь, что нету асинхронного File.Exists :(

у тебя наверное совсем старый механический винт)

У меня есть специальный ноутбук для выездов на исследования, в нём и правда всё железо смертельно бюджетное. Чтоб не жалко было потерять, если что.

И на нём серьёзно заметны тормоза при File.Exists :)

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

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

offtop { say "Винчестер Шрёдингера" }

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

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

Он же про асинхронность, а не про параллельность

Он же про асинхронность, а не про параллельность

Да не, это как раз проблему решает, я так и делаю :)

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

Параллельный File.Exists?

Параллельный File.Exists?

Главное чтоб гуй-тред не блокировал.

Ну ни параллельный, ни асинхронный не будут блокировать гуй же?

Да.

Но асинхронного не существует, а параллельный мы можем сами сделать из любого кода :)

Task.Run(() => files.Any(f => File.Exists(f)))

Чем не асинхронный? :)

Я чёт в твоей терминологии запутался. Мне казалось, что это "параллельный".

Ну, в том смысле, что он на всё время выполнения блокирует параллельный тред.

А асинхронный бы не блокировал.

Параллельный - это когда в нескольких потоках выполняется решение задачи Асинхронный - это когда в одном потоке выполняется задача Оба неблокирующие получаются, т.к. работают в отличном от UI потоке*

Короче, у меня там один файл. Его нельзя проверять на существование "параллельно" в твоей терминологии :)

Параллельный - это когда в нескольких потоках выполняется решение задачи Асинхронный - это когда в одном потоке выполняется задача Оба неблокирующие получаются, т.к. работают в отличном от UI потоке*

  Асинхронный не обязательно на одном потоке. Вообще параллелизм и асинхронность это ортогональные понятия

var files = new string[] { "a.txt", "b.txt", "c.txt" }; var a = Task.Run(() => files.Any(f => File.Exists(f))); // асинхронно var p = files.AsParallel().Any(f => File.Exists(f)); // параллельно

Вот что я имел ввиду)

var files = new string[] { "a.txt", "b.txt", "c.txt" }; var a = Task.Run(() => files.Any(f => File.Exists(f))); // асинхронно var p = files.AsParallel().Any(f => File.Exists(f)); // параллельно

А чойта первое "асинхронно"? Где тут асинхронность?

Первая функция неверна

Оу, забыл в таск обернуть

  Асинхронный не обязательно на одном потоке. Вообще параллелизм и асинхронность это ортогональные понятия

Тут у всех свои определения, и поэтому мы путаемся :)

Вот так лучше

нее

Чем не асинхронный? :)

Тем что поток ждет File.Exists

var a = Task.Run(() => files.Any(f => File.Exists(f))).ContinueWith(...);

Тем что поток ждет File.Exists

Но это выполняется в отдельном потоке, не блокируя UI

то что внутри континуейшена будет выполнено асинхронно

Но это не асинхронность

:(

File.Exists будет работать паралелльно а континуейшн асинхронно

Вы уж с терминами определитесь

При асинхронности твой поток бы ушел в пул, а не висел в ожидании

Внутри ContinueWith все равно есть поток, который ожидает выполнения задачи

var files = new string[] { "a.txt", "b.txt", "c.txt" }; var a = Task.Run(() => files.Any(f => File.Exists(f))); // асинхронно var p = files.AsParallel().Any(f => File.Exists(f)); // параллельно

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

Или я совсем не понимаю, как оно работает

Внутри ContinueWith все равно есть поток, который ожидает выполнения задачи

не обязательно

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

Почему?

не обязательно

А что тогда?

Иначе это начинает выглядеть как магия

Внутри ContinueWith — обязательно