Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Denom, Вы писали:
D>>Маросы для async / await никто не планирует делать?
H>Зачем? Есть ComputationExpression.
Добавлю, что есть статья про ComputationExpression.
Здравствуйте, BogdanMart, Вы писали:
D>>Маросы для async / await никто не планирует делать?
BM>Ну асинк есть в стандартной билиотеке.. а что такое await не знаю
Аналог defcomp из той библиотеки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Denom, Вы писали:
D>>Маросы для async / await никто не планирует делать?
H>Зачем? Есть ComputationExpression.
Ну все-таки, несмотря на внешнее сходство, они отличаются реализацией и кодом на выходе.
Computation expressions — превращаются в вызовы Bind, Return и т.д. у соотв билдера + генерируются объекты замыканий.
А async/await генерируют state machine как enumerable с yield, и в точках await вставляются вызовы методов класса Awaiter.
Здравствуйте, Denom, Вы писали:
D>Ну все-таки, несмотря на внешнее сходство, они отличаются реализацией и кодом на выходе.
D>Computation expressions — превращаются в вызовы Bind, Return и т.д. у соотв билдера + генерируются объекты замыканий. D>А async/await генерируют state machine как enumerable с yield, и в точках await вставляются вызовы методов класса Awaiter.
Дело в том, что C# команде было проще приспособить уже готовый код построителя автомата состояния "yield".
Здравствуйте, hardcase, Вы писали:
H>Дело в том, что C# команде было проще приспособить уже готовый код построителя автомата состояния "yield".
Ок. У Липперта была серия постов, почему сделали именно так. Но на выходе меньше кода и он проще. Да и с сериализацией меньше проблем. Насколько реально сериализовать состояние продолжений на основе ComputationExpressions (Для нужд веб фреймворка)?
Здравствуйте, hardcase, Вы писали:
D>>Насколько реально сериализовать состояние продолжений на основе ComputationExpressions (Для нужд веб фреймворка)?
H>Без понятия, я в тот код нос не сувал. Об этом лучше WolfHound-а трясти.
Он говорил, что без проблем. Но одно дело говорить, а другое сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Denom, Вы писали:
D>Насколько реально сериализовать состояние продолжений на основе ComputationExpressions (Для нужд веб фреймворка)?
Может понадобиться поддержка со стороны компилятора Nemerle. Такая поддержка есть частично в F#. Технические подробности ниже.
Макрос comp создает много замыканий. Они преобразовываются в коде на IL в большое количество маленьких объектов. Если вычисление comp во внутреннем представлении опирается на эти замыкания, то для сериализации такого вычисления нужно, чтобы представляющие замыкания объекты были сериализуемыми.
Например, компилятор F# для замыканий автоматически добавляется атрибут Serializable, если есть такая возможность. Но есть исключения. По-моему важное исключение — последовательности (мне сейчас не понятно — почему).
Что касается async, то нужно действительно спрашивать у WolfHound. У него особая реализация непохожая на другие. В F# используются продолжения, и там необходимы сериализуемые замыкания для сериализации самого асинхронного вычисления (что, видимо, не всегда возможно ??). WolfHound придумал свой собственный метод, но полагаю, что сериализуемые замыкания нужны и там тоже.
Так получается уже три разных способа реализации async. Другие два из C# и F#.
