在几年前回答了这个问题之后，我相信我可以通过。。。

monad是一种函数组合技术，它使用组合函数bind将某些输入场景的处理具体化，以在组合过程中预处理输入。

在正常合成中，函数compose（>>）用于按顺序将合成的函数应用于其前身的结果。重要的是，所组成的函数需要处理其输入的所有场景。

（x->y）>>（y->z）

这种设计可以通过重组输入来改进，以便更容易地询问相关状态。因此，如果y包含有效性的概念，则值可以变成Mb，例如（is_OK，b），而不是简单的y。

例如，当输入仅可能是一个数字时，而不是返回一个可以尽职尽责地包含数字或不包含数字的字符串，您可以将类型重新构造为bool，以指示元组中存在有效数字和数字，例如bool*float。组合函数现在不再需要解析输入字符串来确定数字是否存在，而只需要检查元组的布尔部分。

（Ma->Mb）>>（Mb->Mc）

在这里，合成与合成一起自然发生，因此每个函数必须单独处理其输入的所有场景，尽管现在这样做要容易得多。

然而，如果我们能够将审讯的工作外化，以应对那些处理场景是常规的情况，那又会怎样呢。例如，如果我们的程序在输入不正常时什么都不做，比如is_OK为false时。如果做到了这一点，那么组合函数就不需要自己处理该场景，从而大大简化了代码并实现了另一个级别的重用。

为了实现这种外部化，我们可以使用bind（>>=）函数来执行组合而不是组合。因此，不是简单地将值从一个函数的输出传递到另一个函数输入，而是检查Ma的M部分，并决定是否以及如何将组合函数应用于a。当然，函数绑定将专门为我们的特定M定义，以便能够检查其结构并执行我们想要的任何类型的应用。尽管如此，a可以是任何东西，因为bind仅在确定应用程序需要时将未检查的a传递给组合函数。此外，组合函数本身也不再需要处理输入结构的M部分，从而简化了它们。因此

（a->Mb）>>=（b->Mc）或更简洁地Mb>>=

简言之，一旦输入被设计为充分暴露某些输入场景，monad就外部化了，从而提供了关于处理这些输入场景的标准行为。这种设计是一种外壳和内容模型，其中外壳包含与组合函数的应用程序相关的数据，并由绑定函数查询，并且仅对绑定函数可用。

因此，单子是三件事：

M外壳，用于保存monad相关信息，实现的绑定函数，用于在将组合函数应用于其在外壳中找到的内容值时使用该外壳信息，以及形式为a->Mb的可组合函数，生成包含单元管理数据的结果。

一般来说，函数的输入比其输出更具限制性，其中可能包括错误条件等；因此，Mb结果结构通常非常有用。例如，当除数为0时，除法运算符不返回数字。

此外，monad可以包括将值a包装成monadic类型Ma的包装函数，以及将一般函数a->b包装成monodic函数a->Mb的包装函数。当然，像bind一样，这样的包装函数是M特有的。例如：

let return a = [a]
let lift f a = return (f a)

绑定函数的设计假定了不可变的数据结构和纯函数，其他事情变得复杂，无法保证。因此，有一元定律：

鉴于

M_ 
return = (a -> Ma)
f = (a -> Mb)
g = (b -> Mc)

然后

Left Identity  : (return a) >>= f === f a
Right Identity : Ma >>= return    === Ma
Associative    : Ma >>= (f >>= g) === Ma >>= ((fun x -> f x) >>= g)

关联性意味着无论何时应用绑定，绑定都会保留求值顺序。也就是说，在上述关联性的定义中，对f和g的括号化绑定的强制早期评估只会导致期望Ma的函数完成绑定。因此，必须先确定Ma的值，然后才能将其值应用于f，进而将结果应用于g。

Monoid似乎可以确保在Monoid和受支持的类型上定义的所有操作始终返回Monoid内部的受支持类型。任何数字+任何数字=一个数字，没有错误。

而除法接受两个分数，并返回一个分数，该分数在haskell somewhy中将除以零定义为无穷大（恰好是分数somewhy）。。。

在任何情况下，Monads似乎只是一种确保您的操作链以可预测的方式运行的方法，而一个声称为Num->Num的函数，由另一个用x调用的Num->Num的函数组成，并不意味着发射导弹。

另一方面，如果我们有一个功能可以发射导弹，我们可以将它与其他功能组合起来，也可以发射导弹。

在Haskell中，main的类型是IO（）或IO[（）]，这种区分很奇怪，我不会讨论它，但我认为会发生以下情况：

如果我有main，我希望它做一系列动作，我运行程序的原因是产生一个效果——通常是通过IO。因此，我可以将IO操作串联在一起，以便——做IO，而不是其他。

如果我尝试做一些不“返回IO”的事情，程序会抱怨链不流动，或者基本上“这与我们正在尝试做的事情有什么关系——IO动作”，这似乎迫使程序员保持思路，不偏离并思考发射导弹，同时创建排序算法——不流动。

基本上，Monads似乎是编译器的一个提示，“嘿，你知道这个函数在这里返回一个数字，它实际上并不总是有效的，它有时会产生一个number，有时什么都没有，请记住这一点”。知道了这一点，如果你试图断言一个单元动作，单元动作可能会作为一个编译时异常，说“嘿，这实际上不是一个数字，这可能是一个数字。但你不能假设这一点。做一些事情以确保流是可接受的。”这在一定程度上防止了不可预测的程序行为。

似乎monad不是关于纯粹性，也不是关于控制，而是关于维护一个类别的身份，在这个类别上，所有行为都是可预测和定义的，或者不编译。当你被要求做某事时，你不能什么都不做，如果你被要求什么都不干（可见），你也不能做。

我能想到的Monads的最大原因是——看看程序/OOP代码，你会发现你不知道程序从哪里开始，也不知道程序的结束，你看到的只是大量的跳跃和大量的数学、魔法和导弹。您将无法维护它，如果可以的话，您将花费大量的时间来思考整个程序，然后才能理解其中的任何部分，因为在这种情况下，模块化是基于代码的相互依赖的“部分”，其中代码被优化为尽可能相关，以保证效率/相互关系。单子是非常具体的，并且通过定义得到了很好的定义，并确保程序流程可以进行分析，并隔离难以分析的部分——因为它们本身就是单子。monad似乎是一个“可理解的单元，它在完全理解时是可预测的”——如果你理解“可能”monad，那么它除了“可能”之外就没有可能做任何事情，这看起来微不足道，但在大多数非monad代码中，一个简单的函数“helloworld”可以发射导弹，什么都不做，或者摧毁宇宙，甚至扭曲时间——我们不知道也不能保证它是什么样子。一个单子保证它就是什么样子。这是非常强大的。

“现实世界”中的所有事物似乎都是单子，因为它受到防止混淆的明确可观察规律的约束。这并不意味着我们必须模仿这个对象的所有操作来创建类，相反，我们可以简单地说“一个正方形就是一个正方形”，只不过是一个正方形，甚至不是矩形或圆形，和“一个正方形的面积是它现有维度的长度乘以它自身的面积。无论你有什么正方形，如果它是2D空间中的正方形，它的面积绝对不能是任何东西，只有它的长度平方，这几乎是微不足道的。这是非常强大的，因为我们不需要断言我们的世界是这样的，我们只需要使用现实的含义来预测它。”防止我们的节目偏离轨道。

我几乎可以肯定是错的，但我认为这可以帮助一些人，所以希望它能帮助一些人。

对于来自命令式背景（c#）的人，

考虑以下代码

bool ReturnTrueorFalse(SomeObject input)
{
    if(input.Property1 is invalid)
    {
        return false;
    }

    if(input.Property2 is invalid)
    {
        return false;
    }

    DoSomething();
    return true;
}

您会看到很多这样的代码，甚至不会看到早期返回，但所有检查都是嵌套完成的。现在，Monad是一种模式，它可以像下面一样被压平

Monad<bool> ReturnTrueorFalse(SomeObject input) =>
    from isProperty1Valid in input.Property1
    from isProperty2Valid in input.Property2
    select Monad.Create(isProperty1Valid && isProperty2Valid);

这里有几点需要注意。首先，更改函数的返回值。其次，输入的两个财产都必须是Monad。接下来，Monad应该实现SelectMany（LINQ的展平运算符）。由于SelectMany是为该类型实现的，因此可以使用查询语法编写语句

那幺，什么是莫纳德？它是一种以可组合方式对返回相同类型的表达式进行扁平化的结构。这在函数式编程中特别有用，因为大多数函数式应用程序倾向于将状态和IO保持在应用程序的边缘层（例如：控制器），并在整个调用堆栈中返回基于Monad的返回值，直到需要解包该值。当我第一次看到这张照片时，我最大的优点是它很容易在眼睛上看到，也很有陈腔滥调。

每个c#（现在几乎每个人）开发人员都能立即识别的Monad的最佳示例是async/await。在.Net4.5之前，我们必须使用ContinueWith编写基于任务的语句来处理回调，在async/await之后，我们开始使用同步语法来处理异步语法。这是可能的，因为Task是一个“monad”。

关于OOP开发人员的详细说明，请参阅本文，这是一个简单的实现和语言文本，其中包含许多很棒的Monad和大量关于函数式编程的信息

事实上，与一般人对蒙得斯的理解相反，他们与国家无关。Monads只是一种包装东西的方法，它提供了对包装好的东西进行操作而不展开的方法。

例如，您可以在Haskell中创建一个类型来包装另一个类型：

data Wrapped a = Wrap a

包装我们定义的东西

return :: a -> Wrapped a
return x = Wrap x

要在不展开的情况下执行操作，假设您有一个函数f：：a->b，然后您可以执行此操作来提升该函数以作用于包装的值：

fmap :: (a -> b) -> (Wrapped a -> Wrapped b)
fmap f (Wrap x) = Wrap (f x)

这就是所有需要理解的。然而，事实证明，有一个更通用的函数来执行此提升，即bind：

bind :: (a -> Wrapped b) -> (Wrapped a -> Wrapped b)
bind f (Wrap x) = f x

bind可以比fmap做得更多，但反之亦然。实际上，fmap只能用绑定和返回来定义。因此，在定义monad时。。您给出它的类型（这里是Wrapped a），然后说明它的返回和绑定操作是如何工作的。

很酷的是，这是一个普遍的模式，它会在所有地方弹出，以纯方式封装状态只是其中之一。

有关如何使用monad来引入函数依赖关系，从而控制求值顺序（如Haskell的IO monad中所用）的好文章，请查看IOInside。

至于理解单子，不要太担心。读一些你觉得有趣的东西，如果你不马上理解，也不要担心。那就用Haskell这样的语言潜水吧。修道院就是这样一种东西，在那里，通过练习，理解慢慢地进入你的大脑，有一天你突然意识到你理解了它们。

在Scala的上下文中，您会发现以下是最简单的定义。基本上，flatMap（或bind）是“关联”的，并且存在一个标识。

trait M[+A] {
  def flatMap[B](f: A => M[B]): M[B] // AKA bind

  // Pseudo Meta Code
  def isValidMonad: Boolean = {
    // for every parameter the following holds
    def isAssociativeOn[X, Y, Z](x: M[X], f: X => M[Y], g: Y => M[Z]): Boolean =
      x.flatMap(f).flatMap(g) == x.flatMap(f(_).flatMap(g))

    // for every parameter X and x, there exists an id
    // such that the following holds
    def isAnIdentity[X](x: M[X], id: X => M[X]): Boolean =
      x.flatMap(id) == x
  }
}

E.g.

// These could be any functions
val f: Int => Option[String] = number => if (number == 7) Some("hello") else None
val g: String => Option[Double] = string => Some(3.14)

// Observe these are identical. Since Option is a Monad 
// they will always be identical no matter what the functions are
scala> Some(7).flatMap(f).flatMap(g)
res211: Option[Double] = Some(3.14)

scala> Some(7).flatMap(f(_).flatMap(g))
res212: Option[Double] = Some(3.14)


// As Option is a Monad, there exists an identity:
val id: Int => Option[Int] = x => Some(x)

// Observe these are identical
scala> Some(7).flatMap(id)
res213: Option[Int] = Some(7)

scala> Some(7)
res214: Some[Int] = Some(7)

注：严格地说，函数编程中的Monad的定义与范畴理论中的Monard的定义不同，后者是按映射和展平的顺序定义的。尽管它们在某些映射下是等价的。这个演示非常好：http://www.slideshare.net/samthemonad/monad-presentation-scala-as-a-category

公主对F#计算表达式的解释帮助了我，尽管我仍然不能说我真的理解了。

编辑：这个系列-用javascript解释monad-对我来说是一个“打破平衡”的系列。

http://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/http://blog.jcoglan.com/2011/03/06/monad-syntax-for-javascript/http://blog.jcoglan.com/2011/03/11/promises-are-the-monad-of-asynchronous-programming/

我认为理解单子是一件让你毛骨悚然的事。从这个意义上说，尽可能多地阅读“教程”是一个好主意，但通常奇怪的东西（不熟悉的语言或语法）会让你的大脑无法专注于基本内容。

有些事情我很难理解：

基于规则的解释对我来说从未奏效，因为大多数实际示例实际上需要的不仅仅是返回/绑定。此外，称之为规则也无济于事。这更像是“有些东西有共同点，我们把它们称为‘单子’，把共同点称为‘规则’”。Return（a->M<a>）和Bind（M<a>->（a->M<b>）->M<b>）很好，但我永远无法理解Bind如何从M<a>中提取a，以便将其传递给a->M<b>。我不认为我在任何地方读过（也许这对其他人来说都很明显），Return（M<a>->a）的反面必须存在于monad内部，它只是不需要暴露。