monads - 我应该避免使用 Monad 失败吗？

Question

我对 Haskell 还很陌生，并且慢慢地意识到 Monad fail 的存在有问题。真实世界的 Haskell warns against its use (“再一次，我们建议您几乎总是避免使用失败!”)。我今天才注意到罗斯帕特森称它为“一个疣，而不是设计模式”back in 2008 (并且似乎在该线程中达成了相当的一致)。

在观看 Ralf Lämmel 博士时 talk on the essence of functional programming ，我开始理解可能导致 Monad 失败的可能紧张局势。在讲座中，Ralf 谈到了将各种 monadic 效果添加到基本 monadic 解析器(日志记录、状态等)。许多效果需要更改基本解析器，有时还需要更改使用的数据类型。我认为向所有 monad 添加“失败”可能是一种妥协，因为“失败”是如此普遍，并且您希望尽可能避免更改“基本”解析器(或其他)。当然，某种“失败”对解析器来说是有意义的，但并非总是如此，例如，put/get of State 或 ask/local of Reader。

让我知道我是否会走错路。

我应该避免使用 Monad 失败吗？
Monad失败的替代方案是什么？
是否有任何不包含此“设计疣”的替代 monad 库？
我在哪里可以阅读更多关于这个设计决策的历史？

Answer 1

一些单子(monad)有一个合理的失败机制，例如终端单子(monad):

data Fail x = Fail

一些 monad 没有合理的失败机制( undefined 不合理)，例如最初的单子(monad):

data Return x = Return x

从这个意义上说，要求所有单子(monad)都有一个 fail 显然是一个缺点。方法。如果你正在编写对单子(monad)进行抽象的程序 (Monad m) => , 使用那个通用的 m 不是很健康的 fail方法。这将导致您可以使用 monad 实例化一个函数，其中 fail不应该真的存在。

我认为使用 fail 的反对意见较少。 (尤其是间接地，通过匹配 Pat <- computation )在一个特定的 monad 中工作时，它有一个好的 fail行为已明确规定。这样的程序有望在回到旧学科中幸存下来，在旧学科中，非平凡的模式匹配创造了对 MonadZero 的需求。而不仅仅是 Monad .

有人可能会争辩说，更好的纪律总是明确地处理失败案例。我在两个方面反对这个立场:(1)monadic 编程的重点是避免这种困惑，以及(2)当前对 monadic 计算结果进行案例分析的符号是如此糟糕。 SHE 的下一个版本将支持该表示法(也可以在其他变体中找到)

case <- computation of
  Pat_1 -> computation_1
  ...
  Pat_n -> computation_n

这可能会有所帮助。

但这整个情况是一团糟。通过它们支持的操作来表征 monad 通常是有帮助的。你可以看到 fail , throw等作为某些单子(monad)支持的操作，但其他单子(monad)不支持。 Haskell 使得在可用操作集中支持小的本地化更改变得非常笨拙和昂贵，通过解释如何根据旧操作来处理它们来引入新操作。如果我们真的想在这里做一个更整洁的工作，我们需要重新考虑如何 catch工作，使其成为不同本地错误处理机制之间的转换器。我经常想用一个在传递错误之前添加更多上下文信息的处理程序将可能无信息失败的计算(例如，通过模式匹配失败)括起来。我不禁感到，有时做这件事比应该做的更难。

所以，这是一个可以做得更好的问题，但至少，使用 fail仅适用于提供合理实现并正确处理“异常”的特定 monad。