Haskell自定义类型派生Eq实例问题及UndecidableInstances使用咨询

让我们逐个解答你的问题：

1. 为什么第一个示例可以编译通过，第二个却不行？ #

这要从GHC自动派生实例的上下文检查规则说起。

对于data A f t = A (f t) deriving (Eq)，GHC会自动生成如下实例：

instance (Eq (f t)) => Eq (A f t) where
    (A x) == (A y) = x == y

这个实例的上下文Eq (f t)符合GHC默认的“合理性要求”：它的语法复杂度和实例头部A f t中的参数f t完全一致，没有更深的嵌套，GHC可以安全地接受这个约束，所以不需要额外扩展就能编译通过。

而对于data B f t = B (f (f t)) deriving (Eq)，GHC尝试生成的实例会是：

instance (Eq (f (f t))) => Eq (B f t) where ...

这里的上下文Eq (f (f t))比实例头部的参数f t多嵌套了一层f，GHC默认会拒绝这种情况——它担心这类嵌套约束可能导致类型检查时陷入无限循环（比如如果f是某种递归类型构造器）。这就是你看到如下错误的原因：

No instance for (Eq (f (f t)))
arising from the first field of ‘B’ (type ‘f (f t)’)
Possible fix:
use a standalone 'deriving instance' declaration,
so you can specify the instance context yourself

GHC其实已经提示了解决方案：用独立派生声明来手动指定上下文。

2. 此时使用UndecidableInstances是否不合适？ #

完全合适，这属于该扩展的合理使用场景。

UndecidableInstances的风险在于它允许GHC接受那些理论上可能导致类型检查无限循环的实例，但在你的案例中，这个风险不存在：你写的实例

deriving instance (Eq (f (f t)), Eq (f t)) => Eq (B f t)

只要f本身的Eq实例是终止的（比如Maybe、[]这些标准库中的类型构造器），那么f (f t)的Eq实例必然也是终止的，不会出现无限递归的情况。

这个扩展的设计初衷就是为了这类场景：当你明确知道实例不会造成循环，只是需要绕过GHC的保守检查时，放心用就好。

3. 有没有办法无需编写大量实例就能实现需求？ #

当然有，最简洁的方式是结合StandaloneDeriving、FlexibleContexts和UndecidableInstances这三个扩展，一次性为B派生出所有需要的实例，完全不用手动编写Eq1、Show1这类“提升版”实例或类：

{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE StandaloneDeriving #-}

import Control.DeepSeq (NFData)

data B f t = B (f (f t))

-- 一次性派生Eq、Show、Read、NFData实例
deriving instance Eq (f (f t)) => Eq (B f t)
deriving instance Show (f (f t)) => Show (B f t)
deriving instance Read (f (f t)) => Read (B f t)
deriving instance NFData (f (f t)) => NFData (B f t)

这样写的话，只要f对应的f (f t)能拥有这些实例（比如f是Maybe时，Maybe (Maybe t)天然就有Eq、Show等实例），GHC就会自动为B生成正确的实例逻辑，你完全不用手动实现任何方法。

如果你实在不想使用UndecidableInstances，可以借助generic-deriving库自动生成Eq1、Show1等实例，再基于它们实现B的实例，但这需要额外引入依赖，反而不如上面的方法直接高效。

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