公主对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内部，它只是不需要暴露。

[免责声明：我仍在努力完全了解monads。以下是我目前所了解的情况。如果这是错误的，希望有有知识的人会在地毯上给我打电话。]

Arnar写道：

Monads只是一种包装东西的方法，它提供了对包装好的东西进行操作而不展开的方法。

正是这样。想法是这样的：

你需要一些价值，并用一些附加信息来包装它。就像值是某种类型的（例如整数或字符串）一样，附加信息也是某种类型的。例如，该额外信息可能是“可能”或“IO”。然后，您有一些运算符，允许您在携带附加信息的同时对打包的数据进行操作。这些运算符使用附加信息来决定如何更改包装值上的操作行为。例如，Maybe Int可以是Just Int或Nothing。现在，如果您将Maybe Int添加到Maybe Int，则运算符将检查它们是否都是内部的Just Int，如果是，则将展开Int，将其传递给加法运算符，将生成的Int重新包装为新的Just Int（这是有效的Maybe Int），从而返回Maybe Int。但如果其中一个是内部的Nothing，则该运算符将立即返回Nothing，这也是一个有效的Maybe Int。这样，你可以假装Maybe Ints只是正常的数字，并对它们进行常规运算。如果你得到了一个Nothing，你的方程仍然会产生正确的结果——而不必到处乱检查Nothing。

但这个例子正是Maybe所发生的事情。如果额外的信息是IO，那么将调用为IO定义的特殊运算符，并且在执行添加之前，它可以执行完全不同的操作。（好吧，将两个IO Int加在一起可能是荒谬的——我还不确定。）

基本上，“monad”大致意思是“模式”。但是，您现在有了一种语言构造（语法和所有），可以将新模式声明为程序中的东西，而不是一本充满了非正式解释和专门命名的模式的书。（这里的不精确之处在于所有模式都必须遵循特定的形式，因此monad不像模式那样通用。但我认为这是大多数人都知道和理解的最接近的术语。）

这就是为什么人们觉得单子如此令人困惑：因为它们是一个通用的概念。问是什么使某物成为monad与问是什么让某物成为模式类似。

但是想想在语言中对模式的概念提供语法支持的含义：你不必阅读“四人帮”一书，记住特定模式的构造，只需编写一次代码，以不可知的通用方式实现这个模式，然后就完成了！然后，您可以重用此模式，如Visitor或Strategy或Façade等，只需用它装饰代码中的操作，而无需反复重新实现它！

所以，这就是为什么理解monad的人会发现它们如此有用的原因：这并不是知识势利者以理解为荣的象牙塔概念（好吧，当然也是如此，teehee），而是实际上让代码更简单。

http://code.google.com/p/monad-tutorial/正是为了解决这个问题而进行的工作。

你应该首先了解函子是什么。在此之前，先了解高阶函数。

高阶函数只是一个以函数为自变量的函数。

函子是任何类型构造T，其中存在一个高阶函数，称之为map，它将类型为A->b的函数（给定任意两个类型A和b）转换为函数Ta->Tb。该map函数还必须遵守恒等式和复合法则，以便以下表达式对所有p和q返回true（Haskell表示法）：

map id = id
map (p . q) = map p . map q

例如，名为List的类型构造函数是一个函子，如果它配备了一个类型为（a->b）->Lista->Listb的函数，该函数遵守上述定律。唯一实际的实施是显而易见的。生成的Lista->Listb函数在给定列表上迭代，为每个元素调用（a->b）函数，并返回结果列表。

monad本质上只是一个函子T，它有两个额外的方法，类型为T（T A）->T A的join和类型为A->T A的unit（有时称为return、fork或pure）。对于Haskell中的列表：

join :: [[a]] -> [a]
pure :: a -> [a]

为什么有用？因为例如，您可以使用返回列表的函数映射列表。Join获取生成的列表列表并将它们连接起来。列表是monad，因为这是可能的。

您可以编写一个函数，先映射，然后连接。此函数称为bind或flatMap，或（>>=）或（=<<）。这通常是Haskell中给出monad实例的方式。

monad必须满足某些定律，即联接必须是关联的。这意味着，如果您的值x类型为[[a]]]，那么join（join x）应该等于join（map joinx）。纯必须是联接的标识，这样联接（纯x）==x。

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空间中的正方形，它的面积绝对不能是任何东西，只有它的长度平方，这几乎是微不足道的。这是非常强大的，因为我们不需要断言我们的世界是这样的，我们只需要使用现实的含义来预测它。”防止我们的节目偏离轨道。

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

遵循您简短、简洁、实用的指示：

理解monad最简单的方法是在上下文中应用/组合函数。假设你有两个计算，它们都可以看作是两个数学函数f和g。

f取一个String并生成另一个String（取前两个字母）g获取一个String并生成另一个String（大写转换）

因此，在任何语言中，“取前两个字母并将其转换为大写”的转换都会写成g（f（“某个字符串”））。因此，在纯完美函数的世界中，合成只是：先做一件事，然后再做另一件事。

但假设我们生活在一个功能可能失败的世界中。例如：输入字符串可能有一个字符长，因此f将失败。所以在这种情况下

f获取一个String并生成一个String或Nothing。g仅在f未失败时生成字符串。否则，将不生成任何内容

所以现在，g（f（“somestring”））需要一些额外的检查：“计算f，如果它失败，那么g应该返回Nothing，否则计算g”

此思想可应用于任何参数化类型，如下所示：

让Context[Sometype]是Context中Sometype的计算。考虑功能

f： ：AnyType->上下文[Sometype]g： ：某些类型->上下文[AnyOtherType]

合成g（f（））应该读作“compute f。在这个上下文中，做一些额外的计算，然后计算g，如果它在上下文中有意义”