在最近简要回顾了Haskell之后，对于monad本质上是什么，有什么简单、简洁、实用的解释？
我发现，我遇到的大多数解释都很难理解，而且缺乏实际细节。
当前回答
monad是一个容器，但用于数据。一个特殊的容器。
所有容器都可以有开口、把手和喷口，但这些容器都保证有一定的开口、把手或喷口。
为什么？因为这些有保证的开口、把手和喷口对于以特定、常见的方式拾取和连接容器非常有用。
这使您可以选择不同的容器，而不必对它们了解太多。它还允许不同类型的容器轻松连接在一起。
其他回答
如果我理解正确的话，IEnumerable是从monad派生出来的。我想知道，对于我们这些来自C#世界的人来说，这可能是一个有趣的视角吗？
值得一提的是，这里有一些帮助我的教程链接（不，我还不知道单子是什么）。
http://osteele.com/archives/2007/12/overloading-semicolonhttp://spbhug.folding-maps.org/wiki/MonadsEnhttp://www.loria.fr/~kow/monads/
经过努力，我想我终于明白了单子。在重新阅读了我自己对绝大多数投票结果的冗长批评之后，我将给出这个解释。
要理解单子，需要回答三个问题：
你为什么需要蒙纳德？什么是单子？如何实现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？
看到其他答案，似乎可以很自由地跳到细节中。
monad是一个容器，但用于数据。一个特殊的容器。
所有容器都可以有开口、把手和喷口，但这些容器都保证有一定的开口、把手或喷口。
为什么？因为这些有保证的开口、把手和喷口对于以特定、常见的方式拾取和连接容器非常有用。
这使您可以选择不同的容器，而不必对它们了解太多。它还允许不同类型的容器轻松连接在一起。
解释monad似乎就像解释控制流语句一样。想象一下，一个非程序员要求你解释它们？
你可以给他们一个涉及理论的解释——布尔逻辑、寄存器值、指针、堆栈和框架。但那太疯狂了。
你可以用语法来解释它们。基本上，C中的所有控制流语句都有大括号，您可以通过它们相对于括号的位置来区分条件和条件代码。这可能更疯狂。
或者，您也可以解释循环、if语句、例程、子例程以及可能的协例程。
Monad可以取代相当多的编程技术。语言中有一种特定的语法支持它们，还有一些关于它们的理论。
它们也是函数式程序员使用命令式代码而不承认它的一种方式，但这并不是他们唯一的用途。
正如丹尼尔·斯皮瓦克（Daniel Spiewak）所解释的，修道院不是隐喻，而是从一种共同模式中产生的一种实用的抽象。
