Monad非编程术语 [英] Monad in non-programming terms

问题描述

可能存在重复：

什么是monad？

您如何描述monad非编程术语？是否有一些概念/东西在编程之外（在所有编程之外，而不仅仅是FP）可以被认为是行为或者是一种显着的monad -

解决方案

这是我目前的刺伤：

Monads是 bucket brigades ：

$ b

1. 每个操作都是排队的人;即有一个明确的操作顺序。


2. 每个人都需要一个桶作为输入，从中取出一些东西，并将新东西放入桶中。反过来，存储桶又传递给旅中的下一个人（通过绑定或>> = ，操作）。


3. return 操作只是将资料放入存储桶中的操作。 code>>> ）操作时，桶的内容在被传递给下一个人之前被转储。下一个人不在乎什么在桶中，他们只是在等待接收它。


4. 对于（），一张票正在桶内传递。这就是所谓的单位，它只是一张白纸。
对于IO monad，每个人都会大声地说出一些非常深刻或完全愚蠢的东西 - 但他们可以只有当他们拿着水桶时才会说话。

希望这会有所帮助。 ： - ）

---

编辑：我非常感谢您的支持，但不幸的是，诅咒再次袭来。我所描述的只是带容器的函数应用，而不是monad！但我不是虚无主义者 - 我相信Monad教程诅咒可能会被破坏！所以这里有一个更复杂的图片，我认为它更好一些。你决定是否值得带给你的朋友。

Monads是一个带项目经理的桶装旅。项目经理除了这个旅的第一个成员外，其他所有人都站在后面。水桶旅的成员坐在凳子上，并在他们前面有水桶。

第一个人收到了一些东西，用它做了一些事，然后把它放进去一个桶。那个人然后交出来 - 而不是去大队的下一个人，那太容易了！项目经理（她的名字是 bind ，或<$ c $>），而是指向站在该人后面的项目经理。 c>>> = ）接受存储并决定如何处理它。她可能会决定把第一个人的东西从桶中拿出来，然后把它交给在她面前的人，不要紧张（这就是IO monad）。她可能会选择扔掉水桶并结束旅（这是失败）。她可能会决定绕过她面前的人，并毫不犹豫地将该桶传递给旅中的下一位经理（这就是 Nothing 在也许 monad）。她甚至可能决定把这些东西从桶里拿出来，一次递给她面前的人！ （这就是List monad。）在序列的情况下（>>< / code>），她只是点击在她面前的人的肩膀，而不是交给他们任何东西。

当下一个人制作一桶东西时，该人将其交给下一个项目经理。下一位项目经理再次指出如何处理她给予的桶，并将桶中的东西交给她的人。最后，将这个存储桶传递给项目经理链，他们可以选择对存储桶做些什么（如 List monad assemble所有结果）。第一个项目经理产生了一堆东西作为结果。

对于 do 语法，每个人实际上是一个在现在所有事情的前提下定义的操作 - 就好像项目经理不仅传递了桶中的内容，而且传递了前一个成员生成的值（呃，东西）的旅。如果您使用绑定和序列而不是使用 do 语法来编写计算，则在这种情况下的上下文构建更容易看出 - 注意每个连续的语句是匿名函数在该点之前的操作中构造。

（）值，IO monads和 return 操作仍然存在如上所述。

但这太复杂了！为什么人们不能自己卸下桶？我听到你问。那么，项目经理可以在幕后做一些工作，否则这些工作会变得复杂。我们试图让这些旅成员轻松一点，所以他们不必做太多。例如，在Maybe monad的情况下，每个人都不必检查他们给予的价值，看他们是否被给予任何东西 - 项目经理为他们照顾。

那么，如果你真的想让每个人的工作变得更简单，那么为什么不能一路走下去 - 让一个人只拿东西并交出东西，然后让项目经理担心分水吗？这通常是完成的，它有一个名为的特殊名称，将人员（呃，操作）提升到monad 中。然而，有时候，你想让一个人做一些更复杂的事情，他们想要对生产的桶进行一些控制（例如，他们是否需要返回 Nothing in Maybe monad）的情况，这就是monad的完整概括所提供的。

要点如下：

1. 操作按顺序进行。


2. 每个人都知道如何制作水桶，但不知道如何从桶中取出东西。


3. 每个项目经理都知道如何处理桶，以及如何从桶中取出东西，但不关心它们是什么。 b $ b

因此，结束了我的睡前教程。 :-P

Possible Duplicate:
What is a monad?

How would you describe a monad in non-programming terms? Is there some concept/thing outside of programming (outside of all programming, not just FP) which could be said to act or be monad-like in a significant way?

解决方案

Here's my current stab at it:

Monads are bucket brigades:

1. Each operation is a person standing in line; i.e. there's an unambiguous sequence in which the operations take place.
2. Each person takes one bucket as input, takes stuff out of it, and puts new stuff in the bucket. The bucket, in turn, is passed down to the next person in the brigade (through the bind, or >>=, operation).
3. The return operation is simply the operation of putting stuff in the bucket.
4. In the case of sequence (>>) operations, the contents of the bucket are dumped before they're passed to the next person. The next person doesn't care what was in the bucket, they're just waiting to receive it.
5. In the case of monads on (), a ticket is being passed around inside the bucket. It's called "the Unit", and it's just a blank sheet of paper.
6. In the case of IO monads, each person says something aloud that's either utterly profound or utterly stupid – but they can only speak when they're holding the bucket.

Hope this helps. :-)

---

Edit: I appreciate your support, but sadly, the Monad Tutorial curse has struck again. What I've described is just function application with containers, not monads! But I'm no nihilist – I believe the Monad Tutorial curse can be broken! So here's a somewhat more, um, complicated picture that I think describes it a bit better. You decide whether it's worth taking to your friends.

Monads are a bucket brigade with project managers. The project managers stand behind all but the first member of the brigade. The members of the bucket brigade are seated on stools, and have buckets in front of them.

The first person receives some stuff, does something with it, and puts it in a bucket. That person then hands off – not to the next person in the brigade, that would be too easy! :-) – but to the project manager standing behind that person.

The project manager (her name is bind, or >>=) takes the bucket and decides what to do with it. She may decide to take the first person's stuff out of the bucket and just hand it to the person in front of her without further ado (that's the IO monad). She may choose to throw the bucket away and end the brigade (that's fail). She may decide to just bypass the person in front of her and pass the bucket to the next manager in the brigade without further ado (that's what happens with Nothing in the Maybe monad). She may even decide to take the stuff out of the bucket and hand it to the person in front of her a piece at a time! (That's the List monad.) In the case of sequence (>>) she just taps the shoulder of the person in front of her, instead of handing them any stuff.

When the next person makes a bucket of stuff, the person hands it to the next project manager. The next project manager figures out again what to do with the bucket she's given, and hands the stuff in the bucket to her person. At the end, the bucket is passed back up the chain of project managers, who can optionally do stuff with the bucket (like the List monad assembling all the results). The first project manager produces a bucket of stuff as the result.

In the case of the do syntax, each person is actually an operation that's defined on the spot within the context of everything that's gone before – as if the project manager passes along not just what's in the bucket, but also the values (er, stuff) that have been generated by the previous members of the brigade. The context building in this case is much easier to see if you write out the computation using bind and sequence instead of using the do syntax – note each successive "statement" is an anonymous function constructed within the operation that's preceded that point.

() values, IO monads, and the return operation remain described as above.

"But this is too complicated! Why can't the people just unload the buckets themselves?" I hear you ask. Well, the project manager can do a bunch of work behind the scenes that would otherwise complicate the person's work. We're trying to make it easy on these brigade members, so they don't have to do too much. In the case of the Maybe monad, for example, each person doesn't have to check the value of what they're given to see if they were given Nothing – the project manager takes care of that for them.

"Well, then, if you're realliy trying to make each person's job easier, why not go all the way – have a person just take stuff and hand off stuff, and let the project manager worry about the bucketing?" That's often done, and it has a special name called lifting the person (er, operation) into the monad. Sometimes, though, you want a person that has something a bit more complicated to do, where they want some control over the bucket that's produced (e.g. whether they need to return Nothing in the case of the Maybe monad), and that's what the monad in full generality provides.

The points being:

1. The operations are sequenced.
2. Each person knows how to make buckets, but not how to get stuff out of buckets.
3. Each project manager knows how to deal with buckets, and how to get stuff out of them, but doesn't care what's in them.

Thus ends my bedtime tutorial. :-P

这篇关于Monad非编程术语的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！