haskell - 重叠实例有什么好的用例吗？

Question

我正在设计一个库，它将极大地受益于 OverlappingInstances 编译器标志的使用。但是everyone会谈smack关于此扩展并警告其危险。我的问题是，在 hackage 的任何地方都有很好地使用这个扩展的例子吗？关于如何封装坏处并正确使用扩展是否有任何经验法则？

Answer 1

也许一个思想实验会让这个扩展有点神秘。

假设我们已经取消了使用多个模式案例定义的函数必须全部在一个地方的限制，这样你就可以写 foo ("bar", Nothing) = ...在模块的顶部，然后有 foo ("baz", Just x) = ... 之类的情况别处。事实上，让我们更进一步，让案例完全定义在不同的模块中!

如果您认为这听起来会令人困惑且容易出错，那么您是对的。

为了恢复一些理智，我们可以添加一些限制。例如 (ha, ha)，我们可以要求以下属性保持:

在任何使用这种函数的地方，给定的参数必须完全匹配一种模式。其他任何东西都是编译器错误。

添加新模式(包括通过导入另一个模块)永远不应改变有效代码的含义——要么选择相同的模式，要么产生编译器错误。

应该清楚，匹配简单的构造函数，如 True或 Nothing很简单。我们也可以稍微手动一下，并假设编译器可以消除文字的歧义，例如 "bar"和 "baz"以上。

另一方面，使用 (x, Just y) 之类的模式绑定(bind)参数变得尴尬——编写这样的模式意味着放弃编写像 (True, _) 这样的模式的能力或 (False, Just "foobar")稍后，因为这会产生歧义。更糟糕的是，模式保护几乎变得毫无用处，因为它们需要非常普遍的匹配。许多常见的习语会产生无尽的歧义头痛，当然编写一个“默认”的贯穿模式是完全不可能的。

这大致是类型类实例的情况。

我们可以通过放宽所需的属性来重新获得一些表达能力:

在任何使用这种函数的地方，它必须至少匹配一种模式。没有匹配是编译器错误。

如果使用一个函数以使多个模式匹配，则将使用最具体的模式。如果没有唯一的最特定模式，则会产生错误。

如果以与一般实例匹配的方式使用函数，但可以在运行时将其应用于与更具体实例匹配的参数，则这是编译器错误。

请注意，我们现在处于这样一种情况，即仅导入一个模块就可以通过将一个新的、更具体的模式带入范围来改变函数的行为。在涉及高阶函数的复杂情况下，事情也可能变得模糊不清。尽管如此，在许多情况下，问题是不太可能出现的——例如，在库中定义一个通用的失败模式，同时让客户端代码在需要时添加特定的案例。

大概是 OverlappingInstances把你。正如上面示例中所建议的，如果创建新的重叠总是不可能或不希望的，并且不同的模块最终不会看到不同的、冲突的实例，那么它可能没问题。

真正归结为 OverlappingInstances 消除了限制。是否可以在“开放世界”假设下使用类型类表现得明智，即以后可以添加任何可能的实例。通过放宽这些要求，您自己承担了这些负担；因此，请仔细考虑可以添加新实例的所有方式，以及这些场景中的任何一个是否是一个重大问题。如果您确信在晦涩难懂的极端情况下没有什么可以打破，那么请继续使用扩展。