overlapping instances and constraints

[Claus Reinke]

>> both hugs and ghc clearly specify that the more specific instance 
>> declaration is chosen when overlapping instance declarations are 
>> permitted.
>
>I have trouble with this "more specific" term. It's not well-defined,
>i.e. not a total order on possible instance declarations.
>
>The point I was trying to make was that in the case where a
>precondition (in this case, Fail a) does not apply, what stops the
>resolution algorithm falling back on the other instance declaration?

preconditions (instance constraints) are not taken into account in
best-fit overlap resolution. the ordering is plain substitution: instance
A is more specific than instance B if there is a (non-empty) substitution 
that can be applied to make B's head identical to A's. where that is not 
possible, the overlapping declarations are not accepted. see, eg.:

http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#instance-overlap

in that sense, the flag name -fallow-overlapping-instances is slightly
misleading, because it really only permits a subset of overlaps - ones
that can be resolved unambiguously, using a substitution ordering of
the instance heads. it is always clear which instance to choose - no 
search, no backtracking.

cheers,
claus

ps people, including me, have argued the instance context ought to
    be taken into account. but again, that doesn't need to lead to
    much search - most of us would be happy if instance contexts
    would be required to uniquely determine the instance to be
    chosen, a rather conservative extension of current practice. 

    that is because we often use a pair of instance declarations
    where the context for one includes the negation of some of the
    context in the other - they are mutually exclusive, so everything
    is happily deterministic, but the implementation does not notice..