单子 vs. 箭头

Question

我对函数式编程中使用的monad和 箭头的概念非常熟悉。 我也明白它们可以用来解决类似的问题。

但是，对于在任何给定情况下如何选择使用哪个，我仍然有些困惑。

什么时候应该使用 monad，什么时候应该使用箭头？

Answer 1

Lindley、Wadler 和 Yallop 发表了两篇出色的论文（在 LTU此处讨论）。

需要理解的最重要的事情是，有更多的东西是比箭有东西是单子。 相反，monad 严格来说比箭头更强大（ 上面的第二篇论文精确地指定了哪种方式）。

特别是，monad 是配备了类型为(a ~> b, a) ~> b的 apply 函数的箭头，其中(~>)是给定箭头的构造函数。 林德利等人。 指出这破坏了箭头在术语和命令（或者，如果您愿意，对象和态射）之间保持的细致区分。

应用函子有广泛的应用，特别是对于那些最好被认为是对流的操作的东西。 事实上，人们可以将箭头看作是在流上推广转换器的概念（即，为由给定的应用函子构造的对象上的态射引入一种新语言）。

根据我的经验，由于 monad 模糊了对象和态射之间的区别（即，如果我正确使用了这些词，则会产生一个封闭的笛卡尔范畴），那么 monad 中的术语通常比一个箭头或应用函子（尽管请注意，两者都允许您分别通过arr和pure方法注入任意函数）。

因此，如果某些东西没有被赋予 monad 的特征（即使在概念上它形成了一个），那么它就有可能接受更多的检查和优化。 序列化也可能更容易。 因此在解析器和电路建模中使用了应用程序和箭头。

---

以上试图是一般性和描述性的。 以下是我的一些自以为是的经验法则。

如果您需要对看起来像状态的东西进行建模，请从 monad 开始。 如果您需要对看起来像全局控制流（即异常、延续）的东西进行建模，请从 monad 开始。 如果出现与 monad 的功能和通用性相冲突的需求（即对于哪个 join (join :: m (ma) -> ma)过于强大），那么请考虑削弱您正在使用的东西的功能。

如果您需要对流和流上的转换进行建模，特别是某些特征（尤其是过去和未来的无限视图）应该是不透明的流，那么从应用函子开始。 如果您需要对流上的转换属性进行更深入的推理，请考虑使用箭头。

或者，非常粗略地说，applicative 用于电路的动作，箭头用于电路的结构，而 monad 用于通用计算效果。

当然还有更多的故事。 对于应用程序，请特别参阅Conal Elliott 在 FRP方面的工作。 对于箭头，请参阅HXT XML 解析器库、 Yampa FRP 项目、 Haskell on a Horse Web 框架、Hudak 和 Liu 的经典文章 “用箭头堵塞空间泄漏”等。 对于 monad，请查看任何地方。 当然，请注意，仅仅因为某物是 monad，并不意味着应用符号可能不会更清晰和更具表现力。

Answer 2

简短的回答是 Arrows 比 Monads 更通用，而且使用起来也更麻烦。 因此，您应该尽可能使用 Monads，在 Monads 不适用的情况下使用 Arrows。

“风景路线”的答案如下。

介绍 Arrows 的人 John Hughes 发表了两篇我推荐的伟大论文： “将单子推广到箭头”和“用箭头编程” 。 这两篇文章易于阅读，并为您的问题提供了答案。 即使有些人不理解这两篇文章中的所有细节或代码，他们肯定会找到很多关于 Monads 和 Arrows 的信息和非常有用的解释。

我现在将强调这些文章中与您的问题有关的要点

当 Monads 被引入时，人们认为它们是无所不能的。 确实，Monads 具有强大的功能。 但是到了某个时候，发现有些情况下，Monads 是不能应用的。 这些情况与多个输入有关，尤其是当某些输入是静态的而某些输入是动态的时。 因此，约翰·休斯（John Hughes）挺身而出，介绍了 Arrows。

箭头比 Monad 更通用。 箭头是 Monad 的超集。 他们可以完成 Monad 所做的一切，甚至更多。 但它们也更难使用。 John Hughes 建议你应该尽可能使用 Monads，当你不能使用 Monads 时应该使用 Arrows。

我同意约翰休斯的观点。 我还想起了爱因斯坦的名言“一切都应该尽可能简单，但不能更简单”。

当然，这一切都取决于手头的特定情况。 让我解释一下。 让我们假设您正在学习 Haskell。 然后使用一元方法完成每个程序并使用基于箭头的方法重做它将是一项伟大的任务。 在学习的时候，你应该努力探索所有的可能性，实现各种方法。 通过这种方式，您可以获得深刻的洞察力，并且能够直接比较不同的解决方案。

现在让我们假设您想向社区提供一个库。 好吧，您应该感谢会阅读您代码的人，您应该使用最容易理解的方法并且仍然可以完成工作。 您还应该感谢将使用您的代码的人，您的解决方案缺乏不必要的复杂性。 这样，您的解决方案更易于维护，并且更不容易出错和出错。

但是，如果您处于边缘情况怎么办？ 让我们假设您不确定是否需要 Arrows 的额外力量。 那你应该怎么做？ 您是否应该从一元方法开始，然后在需要时切换到基于箭头的方法？ 还是应该从一开始就使用 Arrows，避免在项目中途进行昂贵的转换？

同样，我的答案是尝试第一种方法：如果可以，尝试使用 Monads。 如果你后来发现你不能使用 Monads，你将不得不忍受代价高昂的转换，你必须重新启动并重做项目才能使用 Arrows。 这种方法肯定需要您提供更多的时间和其他资源。 但是你会知道你做了正确的事情，那就是试图提供最简单、最清晰、最简单的解决方案。

避免不必要的复杂性是最重要的。 信不信由你，这就是将范畴论中的概念（例如函数组合、Monads 和 Arrows）引入计算机科学的原因。 讽刺？