在SO上给出了一个解释，为什么像scalaz，cats（Scala）或Arrow（Kotlin）这样的Validation不能成为monad。
据我了解，这是因为他们已经按照适用函子对monad进行了建模，并且Validation的期望行为是可应用的（收集所有无效项），与Validation的monad期望行为不同（序列验证，并且快速失败）。首先无效）。结果，当您想要快速失败时，您需要将验证转换为任一验证（单子验证）。
在https://groups.google.com/forum/#!msg/scalaz/IWuHC0nlVws/syRUkXJklWIJ上，他们提到验证不是monad的原因是因为以下属性不成立：
x <|*|> y === x >>= (a => y map ((a, _)))
但是从单子的定义来看，上述财产不是单子法的一部分。那么，这是否是单子应用程序实现了单子的事实的结果，还是上述特性是成为单子的先决条件？
这种高级推理对我来说已经不新鲜了，但是由于我对FP的有限了解，我可能拥有一个验证数据类型，该数据类型在用作应用程序（累积无效数）时具有一种行为，而在用作monad时具有另一种行为（快速失败）。
您已经做好了所有准备工作。是的，可能有合法的monad实例Validation。问题在于，它将Applicative为两个不同的实例生成Validation一个：一个累积错误，另一个从monad实例派生并快速失败。这将导致类型类不一致：程序行为取决于类型类实例的到达方式。
您提到的财产，
x <|*|> y === x >>= (a => y map ((a, _)))
可以作为定义<|*|>在以下方面>>=和map，从而保持自动为一个应用型从一个单子的。问题在于，已经存在具有不同行为的Applicative <|*|>。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句