为什么实例仅通过其头部进行匹配？

我将首先介绍一个具体的问题（StackOverflow 的人就是这样）。 假设您定义了一个简单类型

data T a = T a

这种类型是一个Functor, Applicative and a Monad。忽略自动派生，要获取这些实例，您必须编写每个实例，即使Monad暗示Applicative，这意味着Functor。 更重要的是，我可以定义一个这样的类

class Wrapper f where
    wrap   :: a -> f a
    unwrap :: f a -> a

这是一个相当强的条件，它绝对意味着Monad，但我写不出来

instance Wrapper f => Monad f where
    return = wrap
    fa >>= f = f $ unwrap fa

因为出于某种原因，这意味着“一切都是Monad (every f），仅当它是Wrapper”，而不是“一切都是Wrapper is a Monad".

同样，你不能定义Monad a => Applicative a and Applicative a => Functor a实例。

您不能做的另一件事（这可能只是相关的，我真的不知道）是让一个类成为另一个类的超类，并提供子类的默认实现。当然，这很棒class Applicative a => Monad a，但是我仍然需要定义Applicative在我可以定义之前实例Monad one.

这不是咆哮。我写了很多，因为否则很快就会被标记为“太宽泛”或“不清楚”。问题归结为标题。 我知道（至少我很确定）这有一些理论上的原因，所以我想知道这里到底有什么好处。

作为一个子问题，我想问是否有可行的替代方案仍然保留所有（或大部分）这些优点，但允许我写的内容。

添加： 我怀疑答案之一可能是“如果我的类型是Wrapper，但我不想使用Monad这意味着什么？”。对此我问，为什么编译器不能选择最具体的一个？如果有一个instance Monad MyType，肯定比instance Wrapper a => Monad a.

这里有很多问题。但我们一次只拿一个。

第一：为什么编译器在选择使用哪个实例时不查看实例上下文？这是为了保持实例搜索高效。如果你要求编译器只考虑实例头满足的实例，那么你实际上最终要求你的编译器在所有可能的实例中进行回溯搜索，此时你已经实现了 Prolog 的 90%。另一方面，如果您采取这样的立场（如 Haskell 所做的那样），即在选择要使用的实例时只查看实例头，然后简单地强制执行实例上下文，则不会出现回溯：在每时每刻，只有您可以做出的一个选择。

下一步：为什么不能让一个类成为另一个类的超类，并提供子类的默认实现？此限制没有根本原因，因此 GHC 提供此功能作为扩展。你可以写这样的东西：

{-# LANGUAGE DefaultSignatures #-}
class Applicative f where
    pure :: a -> f a
    (<*>) :: f (a -> b) -> f a -> f b

    default pure :: Monad f => a -> f a
    default (<*>) :: Monad f => f (a -> b) -> f a -> f b
    pure = return
    (<*>) = ap

然后一旦你提供了instance Monad M where ...，你可以简单地写instance Applicative M没有where条款并让它正常工作。我真的不知道为什么标准库没有这样做。

最后：为什么编译器不能允许多个实例并只选择最具体的一个？这个问题的答案有点像前两个的混合体：有很好的根本原因，这不能很好地工作，但 GHC 仍然提供了一个扩展来做到这一点。这不能很好地工作的根本原因是在运行时之前无法知道给定值的最具体实例。 GHC 对此的回答是，对于多态值，选择与可用的完整多态性兼容的最具体的值。如果后来那件事变得单态，那么对你来说就太糟糕了。这样做的结果是，某些函数可能会在一个实例中对某些数据进行操作，而其他函数可能会在另一实例中对相同的数据进行操作；这可能会导致非常微妙的错误。如果经过所有讨论后您仍然认为这是一个好主意，并且拒绝从别人的错误中吸取教训，您可以打开IncoherentInstances.

我认为这涵盖了所有问题。