> class     TypeEq a b e  | a b -> e
> instance TypeEq a a TTrue
> instance TypeEq a b TFalse

In case of multiple FunDeps for an instance, improvement must use all FunDeps for a given instance, but not go on to improve from a less specific instance -- if one of the FunDeps is Full.

Note a Full FunDep needn't actually deliver any improvement (change of types) for this 'don't go on' to apply -- it's sufficient if some other improvement has already got the Wanted to match the instance. (In effect this is selecting the instance -- although Hugs doesn't 'officially' do so until a later step.)

Getting the preference sequence of instances was tricky -- especially in case of multiple FunDeps: in comparing two instance heads, they might be apart going by some FunDeps, but overlapping going by others.