haskell - Applicative IO 是基于 Monad IO 的函数实现的吗？

Question

在“向您学习 Haskell for Great Good!”作者声称 Applicative IO实例是这样实现的:

instance Applicative IO where
    pure = return
    a <*> b = do
        f <- a
        x <- b
        return (f x)

我可能错了，但似乎 return , 和 do - 特定结构(一些糖化结合 (>>=) )来自 Monad IO .假设这是正确的，我的实际问题是:

为什么Applicative IO实现取决于 Monad IO功能/组合器？

不是 Applicative不如 Monad 强大的概念?

编辑 (一些澄清):

这个实现违背了我的直觉，因为根据 Typeclassopedia 文章它要求给定类型是 Applicative在它可以制作之前 Monad (或者理论上应该是这样)。

Answer 1

(...) according to Typeclassopedia article it's required for a given type to be Applicative before it can be made Monad (or it should be in theory).

是的，您的括号旁正是这里的问题。理论上，任何 Monad也应该是 Applicative ，但这实际上不是必需的，因为历史原因(即，因为 Monad 已经存在了更长的时间)。这不是 Monad 的唯一特点。 ， 任何一个。

考虑相关类型类的实际定义，取自 base软件包在 Hackage 上的来源。

这里是 Applicative :

class Functor f => Applicative f where
    pure  :: a -> f a
    (<*>) :: f (a -> b) -> f a -> f b
    (*>)  :: f a -> f b -> f b
    (<*)  :: f a -> f b -> f a

...我们可以观察到以下几点:

给定当前存在的类型类，上下文是正确的，即它需要 Functor .

它是根据函数应用定义的，而不是(从数学角度可能更自然)提升元组的术语。

它包括技术上多余的运算符，相当于提升常量函数。

同时，这里是 Monad :

class Monad m where
    (>>=)       :: m a -> (a -> m b) -> m b
    (>>)        :: m a -> m b -> m b
    return      :: a -> m a
    fail        :: String -> m a

...我们可以观察到以下几点:

上下文不仅忽略了Applicative , 还有 Functor ，这两者在逻辑上都被 Monad 所暗示但没有明确要求。

它也是根据函数应用定义的，而不是使用 return 的更自然的数学定义。和 join .

它包括一个技术上多余的运算符，相当于提升一个常量函数。

它还包括fail这根本不适合。

一般来说， Monad 的方式类型类不同于它所基于的数学概念，可以追溯到其作为编程抽象的历史。一些，比如它与 Applicative 共享的功能应用偏差。 , 是函数式语言中存在的反射(reflect)；其他，例如 fail或者缺乏适当的类(Class)背景，都是历史上的意外。

这一切都归结为拥有 Monad 的实例。表示 Applicative 的实例, 这又意味着 Functor 的实例.类上下文只是明确地形式化了这一点；无论如何，它仍然是正确的。就目前而言，给定 Monad例如，两个 Functor和 Applicative可以以完全通用的方式定义。 Applicative比 Monad“弱”在更一般的意义上完全一样:任何 Monad自动为 Applicative如果您复制+粘贴通用实例，但存在 Applicative不能定义为 Monad 的实例.

类上下文，如 Functor f => Applicative f说了两件事:后者暗示了前者，并且必须存在一个定义来实现该暗示。在许多情况下，无论如何定义后者都会隐式定义前者，但编译器通常无法推断出这一点，因此需要显式写出这两个实例。使用 Eq 可以观察到同样的情况和 Ord --后者显然暗示了前者，但你仍然需要定义一个 Eq实例，以便为 Ord 定义一个.