haskell - 我们怎么知道应用程序不能是 Monad？

Question

从验证示例 (https://hackage.haskell.org/package/Validation) 中，我试图获得一种直觉来检测应用程序如何/为什么不能是 Monad (Why can AccValidation not have a Monad instance?)

你能质疑我的推理吗？

我以我们处理连接 (m ( m b) -> m b) 的方式来考虑 monad，让我们通过验证这样的例子来加深我的理解:

在data Validation err a中，仿函数结构为(Validation err)。当您查看 Monad 的绑定(bind)定义并专门化验证类型时，您会得到以下内容:

(>>=)  :: m a -> (a -> m b) -> m b
(>>=)  :: (Validation err) a -> (  a -> (Validation err) b) -> (Validation err) b

如果你 beta reduce (>>=) 你会得到:

m a -> (a -> m b) -> m b // if we apply (m a) in the monadic function  
m ( m b) -> m b

然后要获得 (>>=) 的结果，即 m b，您将使用 join :

join              :: (Monad m) => m (m a) -> m a
join x            =  x >>= id

如果你玩你会得到的类型:

join m ( m b ) = m ( m b) >>= (\(m b) -> m b -> m b) which gives m b

所以 join 只是删除最外层的结构，只有最内层类型的值(最内层仿函数的值)通过序列保留/传输。

在 monad 中，我们无法将一些信息从仿函数结构(例如验证错误)传递到下一个“ Action ”，我们唯一可以传递的是值。您唯一可以使用该结构做的事情就是将序列短路以从中获取信息。

您不能对仿函数结构中的信息执行一系列操作(例如，累积诸如错误之类的东西......)

所以我想说，如果一个应用程序在其结构上使用某些逻辑来压缩其结构，那么它可能会因为无法成为 Monad 而受到怀疑？

Answer 1

这不是真正的答案，但对于评论来说太长了。

This以及该线程中的其他引用讨论是相关的。我认为这个问题有点倒退:所有 Monad 自然会产生 Applicative(其中 pure = return 等)；问题是大多数用户期望/假设(类型是实例 Monad)Applicative 实例在语义上等同于 Monad 产生的实例.

这在 Applicative 类中记录为一种法律，但我并不完全相信它是合理的。争论点似乎是，以这种方式不一致的 Applicative 和 Monad 令人困惑。

我使用 Validation 的经验是，用它做任何大的事情都是一场噩梦，这既是因为符号变得一团糟，也是因为你发现你有一些数据依赖性(例如，你需要解析和验证一个部分基于上一节的解析)。您最终定义了 bindV，它的行为类似于 Error monad >>=，因为正确的 Monad 实例被认为是可疑的.

然而，像这样使用 Monad/Applicative 对可以满足您的需求:尤其是在使用 ApplicativeDo 时(我想；还没有尝试过这个)，以 Monadic 风格编写解析器(例如)的效果是，根据解析代码的数据依赖性，您可以在每个级别上积累尽可能多的错误。 Haxl 可以说以类似的方式捏造了这个“定律”。

我对其他 Applicative 但不是 Monad 的类型没有足够的经验，不知道是否有一个合理的规则来判断 Applicative 什么时候“可以”不同意这种方式。也许 Validation 似乎可以正常工作是完全随意的。

无论如何...

我不确定如何直接回答您的问题。我认为您首先要采用记录在 Applicative 类文档底部的定律，然后翻转它们，这样您就可以得到:

 return = pure
 ap m1 m2 = m1 <*> m2

如果 ap 是 Monad 的一个方法并且上面是一个最小的完整定义那么你只需要测试上面是否通过了 Monad 法律来回答您对任何 Applicative 的问题，但当然不是这种情况。