Simon Peyton-Jones wrote:
> | I think I've worked out what's going on now. But I don't like it.
> | When I use -fallow-undecidable-instances and -fallow-overlapping-instances
> | (as I did) I was assuming (like Keith Wansbrough did) that
> | GHC would do a Prolog-style backtracking search when it was time to
> resolve
> | an overloading, and would only complain if there were more or fewer than
> one
> | chain of inferences. Instead Haskell eagerly tries to anticipate possible
>
> | conflicts, which is a nuisance when it is obvious (as it is to me in this
> case) that such
> | conflicts are unlikely to arise. For a simpler example, imagine that we
> have two classes
> | Integral a (things corresponding to integers) and String a
> | (things corresponding to strings). It is a pity that we cannot write
> |
> | instance Integral a => Show a
> | and
> | instance String a => Show a
> |
> | just because someone may come along later on and try to show
> | something which is an instance of both Integral and String. (Though
> obviously if
> | they do, we DO need an error message.)
>
> I agree with this. Here's GHC's current policy:
>
> a) when trying to 'solve' a constraint (C T1 .. Tn) it finds an instance
> decl whose head matches, and commits to that. If two match (and we're
> allowing
> overlap) then it picks the most specific.
>
> b) to make (a) make sense, GHC complains about overlap, at least
> where one head is not more specific than the other
>
> A better policy might be
>
> a') when trying to solve a constraint, search for all solutions, and check
> that in the end there is only one.
>
> b') never comlain of overlap when declaring instance declarations; instead
> only complain when solving constraints.
>
> This is no more expensive than (a) in the common no-overlap case,
> but it's more expressive when overlaps exist.
>
> All this makes perfect sense, I think. I don't have time to implement
> it right now, but maybe someone else does? It's a well-separated
> piece of GHC (one module).
This has already been implemented in hugs (option +m - for `multi-instance
resolution') as of about June 99. See the hugs user manual for details. It
worked pretty well at the time, but may have suffered some bit-rot - I just
haven't used that option in a long time, and since then there have been a
couple interesting changes to the type checker.
It was a fairly localized change in hugs, and I'd hope it would also be fairly
localized in GHC.
--Jeff
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
