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？”中的答案）

蒙纳斯的一个很好的动机是西格菲（丹·皮波尼）的《你本可以发明蒙纳斯！（也许你已经有了）。还有很多其他monad教程，其中许多都试图使用各种类比以“简单的术语”来解释monad：这就是monad教程谬论；避开它们。

正如MacIver博士在《告诉我们为什么你的语言很糟糕》中所说：所以，我讨厌Haskell的事情：让我们从显而易见的开始。Monad教程。不，不是单子。特别是教程。他们没完没了，夸夸其谈，亲爱的上帝，他们太乏味了。此外，我从未见过任何令人信服的证据表明它们确实有帮助。阅读类定义，编写一些代码，忘掉这个可怕的名字。

你说你懂“也许莫纳德”吗？很好，你在路上了。只要开始使用其他monad，迟早你会了解monad的一般含义。

（如果你以数学为导向，你可能想忽略几十个教程，学习定义，或遵循类别理论的讲座：）定义的主要部分是Monad M包含一个“类型构造器”，为每个现有类型“T”定义一个新类型“M T”，以及在“常规”类型和“M”类型之间来回移动的一些方式。]

同样，令人惊讶的是，对monad最好的介绍之一实际上是介绍monad的早期学术论文之一，Philip Wadler的Monad for functional programming。它实际上有一些实用的、非平凡的激励性例子，与许多人工教程不同。

对于来自命令式背景（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和大量关于函数式编程的信息

我也在努力理解单子。这是我的版本：

Monad是关于对重复的事物进行抽象的。首先，monad本身是一个类型化接口（像抽象泛型类），它有两个函数：bind和return，它们定义了签名。然后，我们可以基于抽象的monad创建具体的monad，当然还有绑定和返回的具体实现。此外，绑定和返回必须满足几个不变量，以便可以组合/链接具体的单体。

当我们有接口、类型、类和其他工具来创建抽象时，为什么要创建monad概念？因为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），而是实际上让代码更简单。

经过努力，我想我终于明白了单子。在重新阅读了我自己对绝大多数投票结果的冗长批评之后，我将给出这个解释。

要理解单子，需要回答三个问题：

你为什么需要蒙纳德？什么是单子？如何实现monad？

正如我在最初的评论中所指出的，有太多的monad解释被第3个问题所困扰，没有，也没有充分地涵盖第2个问题或第1个问题。

你为什么需要蒙纳德？

Haskell等纯函数式语言与C或Java等命令式语言的不同之处在于，纯函数式程序不一定按特定顺序执行，一步一步执行。Haskell程序更类似于一个数学函数，在该函数中，您可以以任意数量的潜在阶数求解“方程”。这带来了许多好处，其中之一是它消除了某些类型的错误的可能性，特别是那些与“状态”相关的错误。

然而，使用这种编程风格，有些问题不是很容易解决的。有些事情，比如控制台编程和文件i/o，需要按照特定的顺序进行，或者需要维护状态。处理这个问题的一种方法是创建一种表示计算状态的对象，以及一系列将状态对象作为输入并返回新修改的状态对象的函数。

因此，让我们创建一个假设的“状态”值，它表示控制台屏幕的状态。这个值是如何构造的并不重要，但假设它是一个字节长度的ascii字符数组，表示屏幕上当前可见的内容，以及一个表示用户输入的最后一行伪代码的数组。我们已经定义了一些接受控制台状态、修改它并返回新控制台状态的函数。

consolestate MyConsole = new consolestate;

因此，要进行控制台编程，但以纯函数的方式，您需要在彼此之间嵌套许多函数调用。

consolestate FinalConsole = print(input(print(myconsole, "Hello, what's your name?")),"hello, %inputbuffer%!");

以这种方式编程保持了“纯”的功能风格，同时强制对控制台的更改按特定顺序进行。但是，我们可能希望像上面的示例一样，一次只执行几个操作。以这种方式嵌套函数将开始变得笨拙。我们想要的是基本上与上面相同的代码，但编写得更像这样：

consolestate FinalConsole = myconsole:
                            print("Hello, what's your name?"):
                            input():
                            print("hello, %inputbuffer%!");

这确实是一种更方便的写法。但我们如何做到这一点呢？

什么是单子？

一旦你定义了一个类型（比如consoleestate），以及一系列专门为该类型操作而设计的函数，你就可以通过定义一个操作符（比如：（bind））将这些东西的整个包变成一个“monad”，该操作符会自动将返回值输入到左边的函数参数中，转换为与特定类型的绑定运算符一起工作的函数。

如何实现monad？

看到其他答案，似乎可以很自由地跳到细节中。