haskell - 为什么不是 Haskell 中 Eq 的每个类型部分？

Question

或者更确切地说，为什么不是 (==)可用于每种数据类型？为什么要推导Eq我们自己？在其他语言中，例如 Python、C++ 和其他语言，它对所有内容都有默认实现!
我想不出无法比较的类型。

Answer 1

在 Python 中，默认的相等实现比较身份，而不是值。这对于用户定义的类很有用，默认情况下这些类是可变的，并且不必具有明确定义的“值”概念。但即使在那种情况下，使用 is 也更为正常。运算符直接比较可变对象的身份。

有了 Haskell 的不变性，分享这个“身份”的概念就没有多大意义了。如果您可以通过身份比较两个术语，您可以找出它们是否共享，但通常由实现决定可能共享的两个术语实际上是否共享，因此此类信息不应影响行为程序(除非您 喜欢 在不同编译器优化策略下改变其行为的程序)。

所以 Haskell 中的平等总是值(value)平等；它告诉您两个术语是否表示相同的值(不一定它们是否具有相同的结构；如果您使用无序列表实现一个集合，那么具有不同结构的两个列表可以表示相同的集合)。

几乎所有的内置类型都是 Eq 的成员已经;最大的异常(exception)是函数类型。函数值相等的唯一真正合理的概念是外延相等(它们是否为每个输入返回相同的输出)。很容易说我们将使用它并让编译器访问函数定义的表示来计算它，但不幸的是，确定两个任意算法(这里用 Haskell 语法编码)是否总是产生相同的输出是一个已知的不可计算问题；如果编译器真的可以做到这一点，它就可以解决停机问题，我们就不必忍受底值是每个类型的成员。

不幸的是，函数不能是 Eq 的成员。意味着很多其他的东西也不能；整数列表可以比较相等性，但函数列表不能，对于包含函数的所有其他容器类型也是如此。这也适用于您编写的 ADT，除非您可以为该类型定义一个合理的相等概念，该概念不依赖于所包含函数的相等性(也许该函数只是实现中的一个方便，以及哪个函数它不会影响您用 ADT 表示的值)。

因此，有 (1) 个类型已经是 Eq 的成员。 , (2) 不能成为 Eq 成员的类型, (3) 可以是 Eq 成员的类型很明显，(4) 个类型可以是 Eq 的成员。但仅限于非显而易见的方式，以及 (5) 类型可以是 Eq 的成员以一种显而易见的方式，但程序员更喜欢另一种方式。我认为 Haskell 处理这些情况的方式实际上是正确的方式。 (1) 和 (2) 不需要你提供任何东西，并且 (4) 和 (5) 总是需要一个显式的实例声明。编译器可以为您提供更多帮助的唯一情况是 (3)，它可能会为您节省 12 个键入字符(如果您已经是 deriving 其他任何字符，则为 4 个字符)。

我认为这对于成本来说是一个很小的胜利。编译器必须尝试构建所有内容的实例，并假设任何失败的内容都不应该有 Eq实例。目前如果你想派生一个 Eq实例并且不小心编写了一个不起作用的类型，编译器会告诉你然后那里有问题。使用建议的“隐式制作 Eq 的所有内容”策略，此错误将在您转到 时显示为无法解释的“无 Eq 实例”错误。使用 假设的实例。这也意味着，如果我将类型视为表示合理相等关系不是简单结构相等的值(上面的情况(5)；还记得由无序列表表示的集合吗？)，我忘记写了我自己的 Eq例如，那么编译器可能会自动生成错误的 Eq以我为例。当我去使用它时，我宁愿被告知“你还没有编写 Eq 实例”，而不是让程序编译并运行，但编译器引入了一个错误!