不具有"flatMap"功能的单声道但是"flatUnit"? [英] Monads not with "flatMap" but "flatUnit"?

问题描述

范畴论中的单子词由三元组 T，单位，平坦⟩定义.

Monads in category theory is defined by triples T, unit, flat⟩.

class Monad t where
  map :: (a -> b) -> (t a -> t b) -- functorial action
  unit :: a -> t a
  flat :: t (t a) -> t a

class KleisliTriple t where
  unit :: a -> t a
  flatMap :: t a -> (a -> t b) -> t b

KleisliTriple由运算符flatMap(或Haskell中的bind)对结构进行平坦化，该结构由map和flat组成.

KleisliTriple flats the structure by the operator: flatMap (or bind in Haskell) that is composition of map and flat.

但是，我始终认为，通过使用诸如unit和flat组成的对象(c4)来使结构扁平化，理解和实现函数式编程中的Monad概念就变得更加容易和容易.

However, I always think it's much simpler and easier to understand and implement the Monad conept in functional programming to compose functions by flatten the structure with the object such as flatUnit that is composition of unit and flat.

在这种情况下，为flatUnit(flatUnit(x)) = flatUnit(x).我实际上是在JavaScript中以这种方式实现的，并且使用flatUnit和map(仅是传统函子运算符)，似乎可以得到Monad的所有好处.

In this case, flatUnit(flatUnit(x)) = flatUnit(x). I actually implemented in this manner in JavaScript, and with flatUnit and map (just a legacy functor operator), all the benefit of Monad seems to be obtained.

所以，这是我的问题.

我一直在寻找有关函数式编程中flatUnit形式化类型的文档，但从未找到.我了解有一个历史背景，Eugenio Moggi首先发现了函数式编程中monad的相关性，并且在他的论文中碰巧是KleisliTriple应用程序，但是由于Monad不限于Kleisli类别并且考虑了flatUnit的简单性，因此我很奇怪.

I have kept looking for documents about the kind of flatUnit formalization in functional programming, but never found it. I understand there's a historical context that Eugenio Moggi who first discovered the relevance of monads in functional programming, and in his paper that happened to be KleisliTriple application, but since Monads are not limited to Kleisli Category and considering the simplicity of flatUnit, to me it's very strange.

那是为什么?我想念什么?

Why is that? and what do I miss?

代码已删除.

推荐答案

在此答案中，我将不讨论flatUnit.正如其他人指出的那样，join . return = id对于任何monad(这是monad法则之一)，因此，关于它本身及其本身，没有太多要讨论的内容.相反，我将在这里讨论讨论中提出的一些周围主题.

In this answer, I won't dwell on flatUnit. As others have pointed out, join . return = id for any monad (it is one of the monad laws), and so there isn't much to talk about it in and of itself. Instead, I will discuss some of the surrounding themes raised in the discussion here.

引用评论:

换句话说，具有平坦结构的函子是单子.

in other words, functor with a flat structure, it's a monad.

我认为，这是问题的核心. monad不必是具有平坦结构的函子，而可以是其值可以遵循某些定律("endofunctors类别中的类人动物")保持平坦 tened (带有join)的函子. ， 俗话说).平坦化不需要是无损操作(即join是同构).

This, I believe, is the heart of the question. A monad need not be a functor with a flat structure, but a functor whose values can be flattened (with join) in a way that follows certain laws ("a monoid in the category of endofunctors", as the saying goes). It isn't required for the flattening to be a lossless operation (i.e. for join to be an isomorphism).

其join是同构的单子在类别论中被称为等幂单子 ¹ .但是，要使Haskell Monad成为幂等，单价值必须没有额外的结构.这意味着程序员最关注的大多数monad都不是幂等的(实际上，我很难想到不是Identity或类似身份的幂等的Haskell Monad).评论中已经提出的一个示例是列表的示例:

Monads whose join is an isomorphism are called, in category theory parlance, idempotent monads ¹. For a Haskell Monad to be idempotent, though, the monadic values must have no extra structure. That means most monads of immediate interest to a programmer won't be idempotent (in fact, I'm having trouble to think of idempotent Haskell Monads that aren't Identity or identity-like). One example already raised in the comments was that of lists:

join [[1,2],[3,4,5]] = [1,2,3,4,5] -- Grouping information discarded

函数/阅读器monad给出了一个更加生动的插图:

The function/reader monad gives what I'd say is an even more dramatic illustration:

join (+) = \x -> x + x

最近的问题给出了一个有趣的例子，涉及到Maybe.那里的OP具有签名功能...

This recent question gives an interesting illustration involving Maybe. The OP there had a function with signature...

appFunc :: Integer -> Integer -> Bool -> Maybe (Integer,Integer)

...并像这样使用它...

... and used it like this...

appFunc <$> u <*> v <*> w

...因此获得Maybe (Maybe (Integer, Integer))结果. Maybe的两层对应于两种不同的失败方式:如果u，v或w为Nothing，则得到Nothing；否则，我们得到Nothing.如果其中三个是Just值，但appFunc导致Nothing，则得到Just Nothing;最后，如果一切成功，我们将在Just中获得一个Just值.现在，可能是这样的情况，我们像该问题的作者一样，并不在意Maybe的哪一层导致了失败.在这种情况下，我们可以通过在结果上使用join或将其重写为u >>= \x -> v >>= \y -> w >>= \b -> appFunc x y b来丢弃该信息.无论如何，这些信息都可以供我们使用或丢弃.

... thus obtaining a Maybe (Maybe (Integer, Integer)) result. The two layers of Maybe correspond to two different ways of failing: if u, v or w are Nothing, we get Nothing; if the three of them are Just-values but appFunc results in Nothing, we get Just Nothing; finally, if everything succeeds we get a Just-value within a Just. Now, it might be the case that we, like the author of that question, didn't care about which layer of Maybe led to the failure; in that case, we would discard that information, either by using join on the result or by rewriting it as u >>= \x -> v >>= \y -> w >>= \b -> appFunc x y b. In any case, the information is there for us to use or discard.

注1:在King和Wadler的合并Monads 中()，作者介绍了另一种且几乎没有关联的含义，即幂等单子".从他们的意义上讲，一个幂等单子是f <$> u <*> u = (\x -> f x x) <$> u(以应用符号表示)的一个例子-Maybe.

Note 1: In Combining Monads by King and Wadler (one of Wadler's papers about monads), the authors introduce a different, and largely unrelated, meaning for "idempotent monad". In their sense, an idempotent monad is one for which (in applicative notation) f <$> u <*> u = (\x -> f x x) <$> u -- one example would be Maybe.

这篇关于不具有"flatMap"功能的单声道但是"flatUnit"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！