LYHFGG：“Monads只是支持>> =”的应用函子。这种说法在何种意义上是正确的？

在LYHFGG作者指出，“Monads只是应用仿函数，支持>> =” （见下图）。我不明白如果我看看Monad type class的定义，这种说法可能是真实的。LYHFGG：“Monads只是支持>> =”的应用函子。这种说法在何种意义上是正确的？

Monad类型类似乎与Control.Applicative类型类没有任何关系，例如Monad类型类不是Applicative的子类型。所以很明显，在技术上，在Haskell中，Monads和Applicative仿函数是完全独立的类型类。因此，如果作者的陈述是真实的，那么在不同的情况下它必须是真实的。

有人能解释一下这本看似不真实的陈述的作者意味着什么吗？

他的陈述应该如何解释？在什么情况下？也许在类别理论的背景下？

换句话说： 我不明白如何将任何给定的Monad转换为Applicative函数。因为如果作者的陈述是真实的，那么每个Monad都可以机械地（通过使用算法）转换为Applicative函子。但是真的有可能这样做吗？如果是，如何？

enter image description here

来源

2014-10-04 jhegedus

是的，这是真的可能，正如在这个问题的答案中所述：http://stackoverflow.com/questions/13533769/the-equivalence-between-applicative-functor-and-monad。 – MvanGeest 2014-10-04 15:26:32

你说得对这种说法意味着，当你知道的是，你的类型的构造是一个单子，你可以写一个应用型的实例。如果M是一个单子，那么你可以这样写：

instance Applicative M where 
    pure = return 
    mf <*> mx = 
    mf >>= \f -> 
     mx >>= \x -> 
     return (f x)

而实际上，与GHC 7.10，Applicative开始将是Monad超类，这意味着概念“Monad的是应用型加...”会在标准库中烘焙。

来源

2014-10-04 15:30:50 Tarmil

非常感谢您解决这个困惑！ – jhegedus 2014-10-04 18:02:06

作者是完全正确的。

所以很明显，在技术上，在Haskell中，Monads和Applicative仿函数是完全独立的类型类。

实际上，Monad应该是Applicative的“子类”。它可能在2014年的Haskell中被标准化。每个人都认为从一开始就不这样做是个错误。

我们知道，一个Monad是一个单子，如果它定义：

return
>>=
>>（可从>>=和return导出）

我会离开故意抛开fail。

你可以看到Applicative定义，除其他事项外，pure，这是一样的return，并*>这是一样的>>。因此唯一剩下的区别是>>=的定义。

来源

2014-10-04 15:47:51 Shoe

现在，如果您想更新答案，Monad * *现在是“Applicative”的一个子类。 – 2016-12-06 15:10:29

LYHFGG：“Monads只是支持>> =”的应用函子。这种说法在何种意义上是正确的？

回答

相关问题