为什么验证会违反monad法律?

Jan*_*ols 5 monads scalaz applicative scala-cats arrow-kt

SO上给出了一个解释,为什么像scalaz,猫(Scala)或Arrow(Kotlin)这样的验证不能成为monad.

据我所知,这是因为他们已经根据应用函子和所需的验证行为对monad进行建模,因为应用程序(收集所有残留物)与作为monad的验证的所需行为不同(序列验证并快速失败)第一个无效).因此,当您希望快速发生故障时,您需要将验证转换为其中一个(这是一个monad).

https://groups.google.com/forum/#!msg/scalaz/IWuHC0nlVws/syRUkXJklWIJ上,他们提到验证不是monad的原因,是因为以下属性不会成立:

x <|*|> y === x >>= (a => y map ((a, _))) 
Run Code Online (Sandbox Code Playgroud)

但是看一个monad的定义,上面的属性不是monad法则的一部分.那么,这是因为monad是以应用程序的形式实现的,还是上述属性是monad的先决条件?

这种更高级的推理对我来说都是新的,但是由于我对FP的理解有限,我可以使用一种验证数据类型,当用作应用程序(累积invalids)时有一种行为,当用作mo​​nad时有另一种行为(快速失败).

Tom*_*ula 5

您已经做好了所有准备工作。是的,可能有合法的monad实例Validation。问题在于,它将ApplicativeValidation以下情况生成两个不同的实例:一个实例累积错误,另一个实例源自monad实例并快速失败。这将导致类型类不一致:程序行为取决于类型类实例的到达方式。

您提到的财产,

x <|*|> y === x >>= (a => y map ((a, _)))
Run Code Online (Sandbox Code Playgroud)

可以作为定义<|*|>在以下方面>>=map,从而保持自动为一个应用型从一个单子的。问题在于,已经存在具有不同行为的Applicative <|*|>