Re: overlapping instances in ghc-3.02

[Simon L Peyton Jones]

I'm guilty of not having properly documented what
"allow overlapping instances" means.

GHC's current story is this.  Two instance decls

        instance <context1> => C <type1> where ...
        instance <context2> => C <type2> where ...

are allowed together iff

        a) EITHER <type1> and <type2> do not unify

        b) OR <type1> is a substitution instance of <type1>
                (but not identical to <type1>)

        c) OR vice versa

Notice that these rules

        i) make it clear which instance decl to use
           (pick the most specific one that matches)

        ii) do not mention the contexts <context1>, <context2>
            Reason: you can pick which instance decl
            "matches" based on the type.

So I had intended to reject your two instance decls:

> instance R a              => S  (F a)  where  s x = x
> instance (R a,OS a,Num a) => S  (F a)  where  s _ = error ""  --

The fact that they aren't rejected is a bug (at least, compared
to my intentions).  I didn't check for identical-ness.  So what
is happening is that the second one simply overwrites the first.

I understand your reasoning:

> The idea was that the second  S (F a)  is defined more specifically.
> OS (F a)  uses the instance of  S (F a).  It has to choose the one
> which is more specific for the given data - ?

But I don't understand *in general* how to determine which
instance decl is "more specific".

Hence the rather conservative rules.  I'm nervous enough about
overlapping instance decls without making them more complicated
still, but as ever I'm on the lookout for convincing examples
that motivate something more expressive.

Simon