[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) writes:
> I do not blame ghc for that. IMHO overlapping instances together
> with the rest of Haskell are impossible to be safely and effectively
> implemented.
>
> Unless one accepts that subtle differences in contexts, ones
> depending on the implementation rather than the interface, change
> the meaning. And that definition like "g :: some signature; g = f"
> can cause g to be defined on exactly the same types as f, but with
> a different meaning. And that the same polymorphic function used on
> the same type has different meanings in various places.
I can see a couple of ways to get around the problems you described
here. (BTW, thanks for a cogent and easy to understand explanation of
the problems with overlapping instances.)
1) Stop using a dictionary-based translation scheme for overloading.
Instead, pass around some sort of type identifier in overloaded
function calls; when you need to call a class member, look it up with
some sort of hash table scheme. (If you require classes with possibly
overlapping instances to be marked somehow, then this method can be
combined with the old dictionary-based mechanism.)
This is obviously a large change in implementation strategy, with very
unclear performance implications. It would probably be somewhat
slower, but it could be a win in situations where code must now
repeatedly create new dictionaries for the same class at the same
type.
2) Change the rules for overlapping instances. Instead of the
preferred "the most specific instance will be called", go for the much
easier "any of the overlapping instances may be called". Better
compilers would do a better job of calling the most specific instance
in more cases, but no compiler would promise to always call the most
specific instance.
Carl Witty
[EMAIL PROTECTED]
