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

发布于 2024-12-16 14:28:59 字数 939 浏览 2 评论 0原文

我对 Haskell 相当陌生，并且慢慢地意识到 Monad failure 的存在有问题。 Real World Haskell 警告不要使用它（“我们再次建议你几乎总是避免使用失败！”）。我今天才注意到罗斯帕特森称其为“一个疣，而不是一个设计模式” 早在 2008 年（似乎在这一点上达成了相当多的一致）线）。

在观看 Ralf Lämmel 博士谈论函数式编程的本质，我开始理解可能导致 Monad 失败的一种紧张关系。在讲座中，Ralf 谈到了向基础单子解析器添加各种单子效果（日志记录、状态等）。许多效果需要更改基本解析器，有时还需要更改所使用的数据类型。我认为向所有单子添加“失败”可能是一种妥协，因为“失败”非常常见，并且您希望尽可能避免对“基本”解析器（或其他）进行更改。当然，某种“失败”对于解析器来说是有意义的，但并不总是如此，例如 State 的 put/get 或 Reader 的 Ask/local。

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不疑不惑不回忆 2024-12-23 14:28:59

一些 monad 具有合理的故障机制，例如终端 monad：

data Fail x = Fail

一些 monad 没有合理的故障机制（未定义不合理），例如初始 monad：

data Return x = Return x

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

当在特定的 monad 中工作时，我发现很少有人反对使用 fail（特别是间接地，通过匹配 Pat <- 计算），而该 monad 的良好 fail > 行为已被明确规定。这样的程序有望在回到旧规则的情况下继续存在，在旧规则中，重要的模式匹配创建了对 MonadZero 而不仅仅是 Monad 的需求。

有人可能会说，更好的纪律总是明确地处理失败案例。我反对这个立场有两个原因：（1）一元编程的目的是避免这种混乱，（2）当前对一元计算结果进行案例分析的表示法非常糟糕。 SHE 的下一个版本将支持该符号（也在其他变体中找到），

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

这可能会有所帮助。

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

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

Some monads have a sensible failure mechanism, e.g. the terminal monad:

data Fail x = Fail

Some monads don't have a sensible failure mechanism (undefined is not sensible), e.g. the initial monad:

data Return x = Return x

In that sense, it's clearly a wart to require all monads to have a fail method. If you're writing programs that abstract over monads (Monad m) =>, it's not very healthy to make use of that generic m's fail method. That would result in a function you can instantiate with a monad where fail shouldn't really exist.

I see fewer objections to using fail (especially indirectly, by matching Pat <- computation) when working in a specific monad for which a good fail behaviour has been clearly specified. Such programs would hopefully survive a return to the old discipline where nontrivial pattern matching created a demand for MonadZero instead of just Monad.

One might argue that the better discipline is always to treat failure-cases explicitly. I object to this position on two counts: (1) that the point of monadic programming is to avoid such clutter, and (2) that the current notation for case analysis on the result of a monadic computation is so awful. The next release of SHE will support the notation (also found in other variants)

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

which might help a little.

But this whole situation is a sorry mess. It's often helpful to characterize monads by the operations which they support. You can see fail, throw, etc as operations supported by some monads but not others. Haskell makes it quite clumsy and expensive to support small localized changes in the set of operations available, introducing new operations by explaining how to handle them in terms of the old ones. If we seriously want to do a neater job here, we need to rethink how catch works, to make it a translator between different local error-handling mechanisms. I often want to bracket a computation which can fail uninformatively (e.g. by pattern match failure) with a handler that adds more contextual information before passing on the error. I can't help feeling that it's sometimes more difficult to do that than it should be.

So, this is a could-do-better issue, but at the very least, use fail only for specific monads which offer a sensible implementation, and handle the 'exceptions' properly.

回复收藏 0 原文

椒妓 2024-12-23 14:28:59

在 Haskell 1.4 (1997) 中没有失败。相反，有一个包含 zero 方法的 MonadZero 类型类。现在，do 表示法使用零来指示模式匹配失败；这引起了人们的惊讶：他们的函数是否需要 Monad 还是 MonadZero 取决于他们如何在其中使用 do 表示法。

稍后设计 Haskell 98 时，他们做了一些更改，以使编程对新手来说更简单。例如，单子推导式被转变为列表推导式。同样，为了消除 do 类型类问题，删除了 MonadZero 类；对于do的使用，在Monad中添加了fail方法；对于 zero 的其他用途，MonadPlus 中添加了 mzero 方法。

我认为，有一个很好的论点，即 fail 不应该明确用于任何事情；它唯一的预期用途是翻译 do 表示法。尽管如此，我自己也经常顽皮地使用 fail 。

您可以在此处访问原始 1.4 和 98 报告。我确信导致更改的讨论可以在一些电子邮件列表档案中找到，但我没有方便的链接。