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

从验证的例子（https://hackage.haskell.org/package/Validation），我试图直观地检测应用程序如何/为什么不能是 Monad （为什么 AccValidation 不能有 Monad 实例？)

你能挑战我的推理吗？

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

in data Validation err a，函子结构为 (Validation err)。当您查看 Monad 的绑定定义并专门化验证类型时，您会得到以下结果：

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

如果你减少（>>=）你会得到：

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

因此，该连接只是删除最外层的结构，只有最内层类型中的值（最内层函子的值）通过序列保留/传输。

在 monad 中，我们无法将一些信息从函子结构（例如验证错误）传递到下一个“动作”，我们唯一可以传递的就是值。您对该结构唯一可以做的就是使序列短路以从中获取信息。

您无法对函子结构中的信息执行一系列操作（例如累积错误之类的东西......）

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

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

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

这记录在Applicative阶级作为一种法律，但我并不完全相信它是合理的。争论似乎是，有一个Applicative and Monad不同意这种方式是令人困惑的。

我的使用经验Validation用它做任何大的事情都是一场噩梦，既因为符号变得一团糟，又因为你发现你有一些数据依赖性（例如，你需要根据前一节的解析来解析和验证一个节）。你最终定义bindV其行为就像Error monad >>=由于适当的Monad实例被认为是可疑的。

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

我对其他类型没有足够的经验Applicative但不是Monad知道是否有一个合理的规则来规定应用语何时可以以这种方式表达不同意见。也许这完全是任意的Validation似乎工作很明智。

任何状况之下...

我不知道如何直接回答你的问题。我认为你首先要了解底部记录的法律Applicative类文档，然后翻转它们，这样你就得到：

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

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