Haskell表达式类型注解中类约束行为不符预期的疑问

你疑惑的核心点在于：Num类本身虽未定义==，但它默认带有Eq超类约束——所有实现Num的类型，必须先满足Eq接口要求（即实现==和/=）。

具体细节拆解： #

1. Num的隐式超类约束
   你用:i Num看到的输出没显示超类，但Haskell标准中Num的实际定义是：

   class Eq a => Num a where
     -- 你输出中列出的各类算术方法
   

   这里的Eq a =>就是超类约束，它强制要求：任何要成为Num实例的类型，必须先实现Eq的接口。所以你看到的所有Num实例（Int、Integer、Double等），同时也都是Eq的实例。

2. GHC的类型默认机制
   当你执行a ==5时，GHC需要给类型变量a确定一个具体类型（类型变量无法直接在运行时存在）。它会触发类型默认规则，将Num a => a默认解析为Integer（或根据GHC配置可能是Double），而Integer既是Num实例也是Eq实例，因此==的调用完全合法。

3. 验证超类约束的小实验
   如果你尝试定义一个只实现Num但不实现Eq的类型，GHC会直接报错：

   data MyNum = MyNum Int
   instance Num MyNum where
     (+) (MyNum x) (MyNum y) = MyNum (x+y)
     (*) (MyNum x) (MyNum y) = MyNum (x*y)
     abs (MyNum x) = MyNum (abs x)
     signum (MyNum x) = MyNum (signum x)
     fromInteger n = MyNum (fromInteger n)
     negate (MyNum x) = MyNum (negate x)
   

   这段代码编译时会提示MyNum缺少Eq实例，因为Num的超类约束强制要求实现Eq。

总结 #

a ==5能正常运行的本质是：Num类强制依赖Eq，所有Num类型天然支持相等比较；再加上GHC的类型默认机制给a确定了具体的Num/Eq实例，因此不会触发类型错误。

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