单子 vs. 箭头 [英] Monads vs. Arrows

问题描述

我对monads 和箭头 用于函数式编程.我也明白它们可以用来解决类似的问题.

I'm broadly familiar with the concepts of monads and arrows as used in functional programming. I also understand that they can be used to solve similar kinds of problems.

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

However, I'm still a bit confused about how to select which one to use in any given situation.

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

When should I use monads and when should I use arrows?

推荐答案

Lindley, Wadler & 有两篇优秀论文Yallop(在 LTU 此处讨论).

There are two excellent papers by Lindley, Wadler & Yallop (discussed at LTU here).

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

The most important thing to understand is that there are more things which are arrows than there are things which are monads. Conversely, monads are strictly more powerful than arrows (the second paper above specifies precisely in which fashion).

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

In particular, monads are arrows equipped with an apply function of type (a ~> b, a) ~> b, where (~>) is the constructor for a given arrow. Lindley et al. point out that this destroys the meticulous distinction arrows maintain between terms and commands (or, if you prefer, objects and morphisms).

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

Applicative functors have a wide variety of applications, particularly for things which are best thought of as operations on streams. One can in fact think of arrows as arising from generalizing the notion of a transformer on streams (i.e. introducing a new language for morphisms on objects constructed by a given applicative functor).

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

In my experience, because monads blur the distinction between objects and morphisms (i.e., if I'm using the words correctly, give rise to a closed cartesian category), then a term in a monad is generally far more necessarily opaque than a term in an arrow or applicative functor (although note that both let you inject arbitrary functions by the arr and pure methods respectively).

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

So if something is not given the characteristics of a monad (even though conceptually it forms one), then it is potentially open to greater inspection and optimization. It is also potentially easier to serialize. Hence the use of applicatives and arrows in parsers and circuit modeling.

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

The above attempted to be general and descriptive. Below are some of my opinionated rules of thumb.

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

If you need to model something that looks like state, start with a monad. If you need to model something that looks like global control flow (i.e. exceptions, continuations), start with a monad. If a requirement arises that conflicts with the power and generality of monads (i.e. for which join (join :: m (m a) -> m a) is too powerful), then consider chipping away at the power of the thing you're using.

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

If you need to model streams, and transformations on streams, and particularly streams for which certain characteristics (particularly unlimited views of the past and future) should be opaque, then start with an applicative functor. If you need stronger reasoning about properties of transformations on streams, then think about reaching for an arrow.

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

Or, very crudely put, applicatives are for the actions of circuits, arrows are for the structures of circuits, and monads are for general-purpose computational effects.

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

There's of course much more to the story. For applicatives, see Conal Elliott's work on FRP in particular. For arrows, see the HXT XML parser library, the Yampa FRP project, the Haskell on a Horse web framework, Hudak and Liu's classic "Plugging a Space Leak with an Arrow" paper, among other things. For monads, see everywhere. And of course take note that just because something is a monad, that doesn't mean that applicative notation might not be clearer and more expressive.

这篇关于单子 vs. 箭头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！