gpt4 book ai didi

haskell - 用 Monad 的 Applicative 来定义 Functor 更好,反之亦然?

转载 作者:行者123 更新时间:2023-12-03 14:38:00 24 4
gpt4 key购买 nike

这是一个普遍的问题,与任何一段代码无关。

假设你有一个类型 T a可以给出 Monad 的实例.因为每个 monad 都是一个 Applicative通过分配 pure = return(<*>) = ap ,然后每个应用程序都是 Functor通过 fmap f x = pure f <*> x , 定义 Monad 的实例更好吗?首先,然后琐碎地给出T Applicative 的实例和 Functor ?

对我来说感觉有点落后。如果我在做数学而不是编程,我会认为我会首先证明我的对象是一个仿函数,然后继续添加限制,直到我也证明它是一个 monad。我知道 Haskell 只是受到范畴论的启发,显然构建证明时使用的技术不是编写有用程序时使用的技术,但我想从 Haskell 社区获得意见。从 Monad 出发会更好吗?下至 Functor ?或来自 Functor高达 Monad ?

最佳答案

我倾向于写和看到写的Functor先例。加倍如此,因为如果您使用 LANGUAGE DeriveFunctor然后编译指示 data Foo a = Foo a deriving ( Functor )大部分时间都在工作。

当您的 Applicative可以比您的 Monad 更通用.例如,这是一个 Err数据类型

data Err e a = Err [e] | Ok a deriving ( Functor )

instance Applicative (Err e) where
pure = Ok
Err es <*> Err es' = Err (es ++ es')
Err es <*> _ = Err es
_ <*> Err es = Err es
Ok f <*> Ok x = Ok (f x)

instance Monad (Err e) where
return = pure
Err es >>= _ = Err es
Ok a >>= f = f a

上面我在 Functor 中定义了实例-to- Monad顺序,并且单独来看,每个实例都是正确的。不幸的是, ApplicativeMonad实例不对齐: ap(<*>)(>>) 明显不同和 (*>) .
Err "hi" <*>  Err "bye" == Err "hibye"
Err "hi" `ap` Err "bye" == Err "hi"

出于敏感性的目的,特别是一旦 Applicative/Monad 提案在每个人的手中,这些应该保持一致。如果您定义了 instance Applicative (Err e) where { pure = return; (<*>) = ap }然后他们将对齐。

但是,最后,您可能能够仔细梳理 Applicative 中的差异。和 Monad以便它们以良性的方式表现不同——例如拥有更懒惰或更高效的 Applicative实例。这实际上发生得相当频繁,我觉得陪审团仍然对“良性”的含义以及您的实例应该在什么样的“观察”下保持一致。在 Facebook 的 Haxl 项目中,可能最常用的就是其中的 Applicative。实例比 Monad 更并行化例如,因此以一些相当严重的“未观察到的”副作用为代价,效率要高得多。

无论如何,如果它们不同,请记录下来。

关于haskell - 用 Monad 的 Applicative 来定义 Functor 更好,反之亦然?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19635265/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com