haskell - Haskell 标准库类型类的替代实现

Question

我见过很多人提示标准库中的一些类型类，比如“Monad 应该需要 Functor”，甚至“Monad 应该需要 Applicative”、“Applicative 应该需要 Pointed”、“Num 不应该”需要显示”等，所以，我有几个问题:

1. 类型类依赖关系树是否存在社区认为的“缺陷”，或者这只是历史上完成事情的结果？

2. 对此进行的更改会对现有代码造成多大程度的破坏？

3. 是否有基本类型类(特别是箭头、单子(monad)、应用程序等)的替代实现来实现“正确”的类依赖集？

Answer 1

除了向后兼容性之外，由于 Haskell 处理类型类的方式相当简单，还存在一些(主要是装饰性的，但处理起来很繁琐)问题:

无向上隐式定义:Monad完全由 pure 定义和(>>=) ; fmap和(<*>)可以用这些来写。在“正确的”层次结构中，每个实例都需要被写出。在这种情况下，这还不算太糟糕，但随着粒度的增加，每个添加一些小功能的实例数量也会增加。如果类定义可以根据自己的函数为父类(super class)函数提供默认实现，那么像(>>=)这样的函数就会大大简化事情。它完全包含父类(super class)中的多个函数，可以作为整个相关层次结构的定义。

上下文膨胀:只要有“原因”Num需要Show和Eq ，这是因为打印和比较数字相等是很常见的。它们是严格正交的，但将它们分开意味着执行所有三件事的函数现在必须在其类型中指定所有三个类。从技术上讲，这是一件好事，但同样，随着粒度的增加，函数类型签名也会增加。

整体依赖:可以添加类型类及其父类(super class)的层次结构，但不能更改或替换。如果一段代码感觉需要替换某些常见类型类的自己版本 - 例如，使用 something like this替换Monad --层次结构在此时被切断；与使用 Monad 的其他定义的代码的兼容性必须在某种程度上手动提供，并且即使仅依赖于两个定义共享的行为子集，也必须重新实现或翻译构建在另一个定义之上的任何类型类。

没有明确正确的层次结构:正如上面所暗示的，需要在类的粒度上做出选择。例如， Pointed 吗？确实需要存在，或者只是 Applicative够了吗？这里确实没有普遍理想的答案，也不应该有。

我怀疑，首先解决上述问题会更好地服务于替换现有类型类，之后替换类型类会少得多痛苦，甚至只是一种形式。例如，@luqui 提到的类型类同义词提案将是朝这个方向迈出的重要一步。