c# - C#异步/等待如何与更通用的构造相关，例如F#工作流程还是monad？

Question

C#语言设计一直(从历史上)一直致力于解决特定问题，而不是寻找解决潜在的一般性问题:例如，参见http://blogs.msdn.com/b/ericlippert/archive/2009/07/09/iterator-blocks-part-one.aspx中的“IEnumerable vs.协程”:

We could have made it much more general. Our iterator blocks can be seen as a weak kind of coroutine. We could have chosen to implement full coroutines and just made iterator blocks a special case of coroutines. And of course, coroutines are in turn less general than first-class continuations; we could have implemented continuations, implemented coroutines in terms of continuations, and iterators in terms of coroutines.

或 http://blogs.msdn.com/b/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx(用于SelectMany)作为(某种)单子(monad)的替代品:

The C# type system is not powerful enough to create a generalized abstraction for monads which was the primary motivator for creating extension methods and the "query pattern"

我不想问为什么会这样(已经给出了很多很好的答案，尤其是在Eric的博客中，这可能适用于所有这些设计决策:从性能到复杂性，对于编译器和程序员而言)。

我想了解的是async/await关键字与哪个“通用构造”相关(我的最佳猜测是延续monad-毕竟，F#async是使用工作流实现的，据我所知，它是一个延续monad)，并且它们之间的关系(它们之间有什么区别？缺少什么？为什么存在差距，如果有的话？)

我正在寻找与我链接的Eric Lippert文章相似的答案，但与异步/等待而不是IEnumerable/yield有关。

Edit: besides the great answers, some useful links to related questions and blog posts where suggested, I'm editing my question to list them:

• A starting point for bind using await
• Implementation details of the state machine behind await
• Other details on how await gets compiled/rewritten
• Alternative, hypothetical implementation using continuations (call/cc)

Answer 1

C#中的异步编程模型与F#中的异步工作流非常相似，后者是常规monad模式的一个实例。实际上，C#迭代器语法也是此模式的一个实例，尽管它需要一些其他结构，所以它不仅仅是简单的monad。

对此的解释远远超出了单个SO答案的范围，但是让我解释一下关键思想。

Monadic操作。
C#异步实质上包含两个原始操作。您可以await异步计算，也可以return异步计算的结果(在第一种情况下，这是使用new关键字完成的，而在第二种情况下，我们将重新使用该语言中已经存在的关键字)。

如果您遵循常规模式(monad)，则可以将异步代码转换为对以下两个操作的调用:

Task<R> Bind<T, R>(Task<T> computation, Func<T, Task<R>> continuation);
Task<T> Return<T>(T value);

使用标准任务API可以很容易地实现它们-第一个本质上是 ContinueWith和 Unwrap的组合，第二个简单地创建了一个立即返回值的任务。我将使用上面的两个操作，因为它们可以更好地捕获想法。

翻译。 关键是将异步代码转换为使用上述操作的普通代码。

让我们看一个案例，当我们等待表达式 e然后将结果分配给变量 x并评估表达式(或语句块) body(在C#中，您可以在表达式内部等待，但是您始终可以将其转换为首先分配的代码结果转换为变量):

[| var x = await e; body |] 
   = Bind(e, x => [| body |])

我使用的编程语言中很常见的一种表示法。 [| e |] = (...)的含义是，我们将表达式 e(在“语义括号”中)转换为其他表达式 (...)。

在上述情况下，当您拥有一个带有 await e的表达式时，该表达式将转换为 Bind操作，并且正文(等待代码的其余部分)被插入一个lambda函数中，该函数作为第二个参数传递给 Bind。

这是有趣的事情发生的地方!代替立即评估其余代码(或在等待时阻塞线程)， Bind操作可以运行异步操作(由 e类型的 Task<T>表示)，并且当操作完成时，它最终可以调用lambda函数(继续)使 body 的其余部分运行。

转换的想法是，它将将返回某种 R类型的普通代码转换为一个异步返回值的任务，即 Task<R>。在上面的公式中， Bind的返回类型确实是一项任务。这也是为什么我们需要翻译 return的原因:

[| return e |]
   = Return(e)

这非常简单-当您有结果值并想返回它时，只需将其包装在立即完成的任务中即可。这听起来没什么用，但是请记住，我们需要返回 Task，因为 Bind操作(以及整个翻译过程)都需要这样做。

较大的示例。 如果您查看包含多个 await的更大示例:

var x = await AsyncOperation();
return await x.AnotherAsyncOperation();

该代码将被翻译成如下形式:

Bind(AsyncOperation(), x =>
  Bind(x.AnotherAsyncOperation(), temp =>
    Return(temp));

关键在于，每个 Bind都会将其余的代码转换为延续代码(意味着可以在异步操作完成后对其进行评估)。

续单。 在C#中，异步机制实际上并未使用上述翻译实现。原因是，如果仅关注异步，则可以进行更有效的编译(这是C#的工作)，并直接生成状态机。但是，以上内容几乎是异步工作流在F#中的工作方式。这也是F#额外灵活性的源泉-您可以定义自己的 Bind和 Return来表示其他含义-例如用于处理序列，跟踪日志记录，创建可恢复计算或什至将异步计算与序列结合的操作(异步序列可以产生多个结果，但也可以等待)。

F#实现基于延续monad，这意味着F#中的 Task<T>(实际上是 Async<T>)大致定义如下:

Async<T> = Action<Action<T>> 

即，异步计算是某种 Action 。当给它 Action<T>(一个延续)作为参数时，它将开始做一些工作，然后，当最终完成时，它将调用您指定的操作。如果您搜索延续单子(monad)，那么我相信您可以在C#和F#中找到对此更好的解释，所以我在这里停止...