| 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).

Simon

_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to