为什么要使用类而不是仅使用模式匹配? [英] Why typeclasses instead of just pattern matching?

问题描述

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

This is something of a philosophical question, but one I hope to have answered by official documentation or "word of god" (read: SPJ). Is there a specific reason that the Haskell committee chose to require explicit interfaces in the form of typeclasses rather than a more uniform solution based on pattern-matching?

例如，以Eq:

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

instance Eq Int where
    (==) = internalIntEq

为什么我们不能做这样的事情(伪哈斯克尔熊):

Why could we not do something like this instead (bear with the pseudo-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允许普通数据类型的模式匹配，则:

That is, if Haskell were to allow pattern-matching of ordinary data types, then:

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

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

Types could still be inferred and matched statically (SupportsEqualsEquals a => ...)

默认实现将免费"提供

类可以很容易地扩展而不会破坏任何内容

Classes could readily be extended without breaking anything

将需要一种方法来指定默认模式(1)，尽管默认模式(1)在其他模式之前声明，但始终与最后一个模式匹配.这些假设功能是否与Haskell固有的功能冲突?正确推断类型会变得困难还是不可能?这项功能似乎很强大，可以与Haskell的其他部分很好地融合在一起，因此我认为我们不要那样做"是有充分理由的.临时多态性的这种机制是否只是太临时性的?

There would need to be a way to specify a default pattern (1) that, though declared before others, always matches last. Do any of these hypothetical features clash with something inherent in Haskell? Would it become difficult or impossible to correctly infer types? It seems like a powerful feature that’d gel very well with the rest of Haskell, so I figure there’s a good reason We Don’t Do It That Way™. Is this mechanism of ad-hoc polymorphism simply too ad-hoc?

推荐答案

这种特殊的多态性机制是否也很特殊?

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

这个问题只是与Philip Wadler和Steve Blott在1988年发表的论文有关，如何为了减少ad-hoc多态性，他们提出了Type类的概念.瓦德勒(Wadler)可能就是这个词的上帝之道".

This question simply begs to be linked to Philip Wadler and Steve Blott's 1988 paper, How to make ad-hoc polymorphism less ad-hoc, where they present the idea of Type classes. Wadler is probably "word of God" on this one.

我所建议的任何Haskell数据类型上的模式匹配"技术存在一些问题.

There are a few problems I see with the proposed "pattern match on any Haskell data type" technique.

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

The pattern matching technique is not sufficient to define polymorphic constants, such as mempty :: Monoid a => a.

模式匹配技术仍然会退回到类型类上，除非以更糟糕的方式.类型类分类类型(如图).但是模式匹配技术使它变得比较模糊.您应该如何准确地指定函数foo和bar是"same"类的一部分?如果必须为使用的每个多态函数添加一个新的类型，则类型类约束将变得完全不可读.

The pattern matching technique still falls back onto type classes, except in a worse way. Type classes classify types (go figure). But the pattern matching technique makes it rather vague. How exactly are you supposed to specify that functions foo and bar are part of the "same" class? Typeclass constraints would become utterly unreadable if you have to add a new one for every single polymorphic function you use.

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

The pattern matching technique introduces new syntax into Haskell, complicating the language specification. The default keyword doesn't look so bad, but pattern matching "on types" is new and confusing.

与普通数据类型"匹配的模式击败了无点样式.代替(==) = intEq，我们有(Int a) == (Int b) = intEq a b；此类人工模式匹配防止了eta减少.

Pattern matching "on ordinary data types" defeats pointfree style. Instead of (==) = intEq, we have (Int a) == (Int b) = intEq a b; this sort of artificial pattern match prevents eta-reduction.

最后，它完全改变了我们对类型签名的理解. a -> a -> Foo当前是保证，不能检查输入.关于a输入，除了两个输入的类型相同，都不能做任何假设. [a] -> [a]再次表示无法以任何有意义的方式检查列表的元素，从而为您

Finally, it completely changes our understanding of type signatures. a -> a -> Foo is currently a guarantee that the inputs cannot be inspected. Nothing can be assumed about the a inputs, except that the two inputs are of the same type. [a] -> [a] again means the elements of the list cannot be inspected in any meaningful way, giving you Theorems for Free (another Wadler paper).

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

There may be ways to address these concerns, but my overall impression is that Type classes already solve this problem in an elegant way, and the suggested pattern matching technique adds no benefit, while causing several problems.

这篇关于为什么要使用类而不是仅使用模式匹配?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！