haskell - 为什么要使用类型类而不是模式匹配？

Question

这是一个哲学问题，但我希望通过官方文档或“上帝的话语”(阅读:SPJ)来回答。 Haskell 委员会选择以类型类的形式要求显式接口(interface)而不是基于模式匹配的更统一的解决方案是否有特定的原因？

以 Eq 为例:

class Eq a where
    (==), (/=) :: a -> a -> Bool
    x == y = not $ x /= y
    x /= y = not $ x == y

instance Eq Int where
    (==) = internalIntEq

为什么我们不能这样做(忍受伪Haskell):

(==), (/=) :: a -> a -> Bool
default x == y = not $ x /= y             -- 1
default x /= y = not $ x == y

(Int a) == (Int b) = a `internalIntEq` b  -- 2

也就是说，如果 Haskell 允许普通数据类型的模式匹配，那么:

程序员可以创建临时类，即 instance将是隐含的 (2)

仍然可以静态推断和匹配类型 (SupportsEqualsEquals a => ...)

默认实现将“免费”提供

类(class)可以轻松扩展而不会破坏任何内容

需要有一种方法来指定默认模式 (1)，尽管在其他模式之前声明，但始终匹配最后。这些假设特征中的任何一个与 Haskell 中固​​有的东西有冲突吗？正确推断类型会变得困难或不可能吗？这似乎是一个强大的功能，可以很好地与 Haskell 的其他部分融为一体，所以我认为 We Don't Do It That Way™ 是有充分理由的。这种临时多态性机制是否过于临时？

Answer 1

Is this mechanism of ad-hoc polymorphism simply too ad-hoc?

这个问题只是请求与 Philip Wadler 和 Steve Blott 1988 年的论文 How to make ad-hoc polymorphism less ad-hoc 联系起来。 ，在那里他们提出了 Type 类的想法。瓦德勒可能是“上帝的话语”之一。

我看到建议的“任何 Haskell 数据类型的模式匹配”技术存在一些问题。

模式匹配技术是 不足以定义多态常量 ，如 mempty :: Monoid a => a .

模式匹配技术仍然依赖于类型类，除了更糟糕的方式。类型类对类型进行分类(看图)。但是模式匹配技术使它相当模糊。您应该如何指定函数 foo和 bar是“同一”类的一部分吗？ 类型类约束将变得完全不可读 如果您必须为您使用的每个多态函数添加一个新函数。

模式匹配技术将新语法引入 Haskell， 使语言规范复杂化 . default关键字看起来还不错，但是“类型”的模式匹配是新的且令人困惑。

“在普通数据类型上”的模式匹配打败了无点风格。而不是 (==) = intEq , 我们有 (Int a) == (Int b) = intEq a b ;这种人工模式匹配 防止 eta 减少 .

最后是 彻底改变了我们对类型签名的理解。 a -> a -> Foo当前是不能检查输入的保证。无法假设 a输入，但两个输入的类型相同。 [a] -> [a]再次意味着无法以任何有意义的方式检查列表的元素，给你 Theorems for Free (另一篇瓦德勒论文)。

可能有解决这些问题的方法，但我的总体印象是 Type 类已经以一种优雅的方式解决了这个问题，并且建议的模式匹配技术没有增加任何好处，但会导致一些问题。