为什么在即将推出的.NET 4.0中没有类似IMonad 的东西
…与所有那些新的（如果我们计算IEnumerable并不是那么新）monad相关的东西？
interface IMonad { SelectMany/Bind(); Return/Unit(); } 这将允许编写以任何monadic类型操作的函数。 或者它不是那么重要？
想想IMonad方法的签名必须是什么。 在Haskell中，Monad类型类被定义为
class Monad m where (>>=) :: ma -> (a -> mb) -> mb return :: a -> ma
将它直接转换为C＃接口是很棘手的，因为您需要能够在一般IMonad接口的定义中引用特定的实现子类型（“ma”或ISpecificMonad ）。 好吧，我们不会尝试将（例如） IEnumerable直接实现IMonad ，而是尝试将IMonad实现分解为一个单独的对象，该对象可以与特定的monad类型实例一起传递给任何需要将其视为monad（这是“字典传递风格”）。 这将是IMonad ，TMonad这里不是IEnumerable ，而是IEnumerable本身。 但是等等 – 这也行不通，因为例如Return的签名必须让我们从任何类型T到TMonad ，对于任何 TMonad<> 。 IMonad必须被定义为类似的东西
interface IMonad> { TMonad Unit (T x); TMonad SelectMany(TMonad x, Func> f); }
使用假设的C＃特性，允许我们使用类型构造函数 （如TMonad <>）作为泛型类型参数。 但当然C＃没有这个功能（更高的多态性） 。 您可以在运行时（ typeof(IEnumerable<>) ）实现类型构造函数，但不能在不给它们参数的情况下在类型签名中引用它们。 因此除了-100点之外，实现这个“正确”不仅需要添加另一个普通的接口定义，而且需要对类型系统进行深入的添加。
这就是为什么能够对你自己的类型进行查询理解的能力被攻击（如果正确的魔法方法名称带有正确的签名，那么它们只是“神奇地”工作）而不是使用接口机制等。
Monads对.NET程序员来说并不重要。 即使不知道monad存在，您仍然可以构建LINQ框架。 更重要的是，它看起来不会有任何不同。 如果你考虑monads（Haskell），表达式树重写（Lisp），基于集合的操作（SQL），或者使用map / reduce来创建新类型（Ruby，Python），这无关紧要，最终的结果是会是一样的。
事实上，我甚至会说，monads对于.NET开发人员来说是完全没用的。 每当我看到基于monad的.NET库时，它总是比直接的C＃或VB代码更冗长，更难以理解。 原因很简单，像C＃和VB这样的语言建立在比Haskell这样的语言更强大的构建块上。
Haskell特别需要使用monad来处理所有事情，因为这就是他们所拥有的一切。 对于Lisp中的宏或JavaScript中的动态类型，也是如此。 当你有一个单一的小马时，那个技巧必须非常好。
关于LINQ，Monads和权力的盲目性