Haskell中超类约束与带约束实例声明的差异及选型问题

两种写法看起来效果接近，本质上是完全不同的机制，核心差异有三点：

• 实例作用域完全不同
  你写的instance Monoid a => Semigroup a是一个覆盖所有类型的全局实例，只要类型满足Monoid约束就会自动匹配这个实例。这会直接占用Semigroup类的全局实例命名空间：只要导入了这个实例，你就没法给任何已经是Monoid的类型写自定义Semigroup实例，甚至给非Monoid类型写Semigroup实例时，编译器也会因为实例重叠规则报冲突，必须开启不安全的重叠实例扩展才能勉强工作。
  而超类约束class Semigroup a => Monoid a不会定义任何全局实例，它只是给Monoid类加了一条前置规则：任何类型要实现Monoid，必须先有对应的Semigroup实例。你完全可以自由给非Monoid类型写Semigroup实例，不会有任何冲突。
• 约束求解逻辑和可靠性天差地别
  超类约束是类型类定义层面的强规则，编译器只要看到Monoid a的约束，就能直接推导出Semigroup a，不需要做任何实例搜索，求解是确定性的O(1)操作，报错也清晰直接。
  反过来那个全局带约束实例，会让编译器每次遇到Semigroup a的约束时，都要反向检查a是否满足Monoid约束，一旦实例链变长，很容易出现循环求解、约束发散的问题，报错信息会极其晦涩。甚至会出现意外的循环定义：

  -- 采用替代写法后很容易写出的死循环代码
  data MyNum = MyNum Int
  instance Monoid MyNum where
    mempty = MyNum 0
    -- 未手动实现mappend，走默认定义mappend = (<>)
    -- 而(<>)来自全局Monoid a => Semigroup a实例，实现是(<>) = mappend
    -- 调用时会直接无限递归
  

• 语义表达层级不同
  超类约束表达的是类型类之间的本质从属关系：所有Monoid必然是Semigroup，这是类本身的公理，和具体实现无关。而带约束的实例表达的是实例层面的派生规则：满足某约束的类型可以获得另一个类的实例，不涉及类本身的公理约束。用实例替代超类约束，本质上是把类层面的公理降级成了模块层面的实例规则，语义完全不对等。

• 只要你要表达的是「B类型类的所有实例，必然满足A类型类的约束」这种本质从属关系，无条件优先用超类约束。这是Haskell表达类型类层级关系的标准写法，符合社区共识，性能、可维护性、可读性都是最优的。标准库中Functor -> Applicative -> Monad、Semigroup -> Monoid这类层级关系全都是用超类约束实现的。
• 带约束的实例声明只适合用在非从属关系的场景：两个类型类之间没有必然的“所有B都是A”的关系，只是某一类满足特定约束的类型，可以独立派生出另一个类的实例。比如你定义了一个新类型newtype Ap f a = Ap (f a)，就可以写instance Applicative f => Semigroup (Ap f a)来实现通用的Applicative提升拼接——这里Semigroup不是Applicative的超类，也不是所有Applicative都必然是Semigroup，只是满足Applicative的f对应的Ap类型可以有Semigroup实例，这种场景才适合用带约束的实例。

当然不是。超类约束是极强的绑定关系，一旦你给B类加了A作为超类，就意味着所有B的实例，永久都必须实现A，这个规则是写在B的定义里的，所有依赖B的代码都会默认遵循这个约定。如果两个类之间没有这种强本质从属关系，只是部分实例逻辑可复用，硬加超类约束会直接破坏类型类的通用性。比如你不能因为很多Monad类型有Monoid实例，就给Monad加Monoid超类——毕竟大量Monad根本不存在合法的mempty实现。

内容的提问来源于stack exchange，提问作者QuantumWiz