the MPTC Dilemma (please solve)

[Simon Peyton-Jones]

You addressed this to me -- but I'm an advocate for rather conservative
extensions whereas you are calling for extensions that go beyond what
any current implementation can do.

Anyway, there is already a ticket for overlapping instances, I think --
why don't you just add to that.

If you send me Wiki-marked-up text I'll gladly paste it in for you.

Simon

| -----Original Message-----
| From: Claus Reinke [mailto:claus.reinke at talk21.com]
| Sent: 25 February 2006 15:33
| To: Simon Peyton-Jones
| Cc: haskell-prime at haskell.org
| Subject: Re: the MPTC Dilemma (please solve)
| 
| | Is the behaviour of GHC with -fallow-undecidable-instances (and
| | -fcontext-stack) well-understood and specifiable?
| >I would not say that it's well-specified, no.
| 
| to start improving that situation, could we please have a task ticket
| for "document differences in unconstrained instance handling", then
| ask everyone to attach source examples showing such differences?
| [can guests attach code to task tickets?]
| 
| the hope being, of course, that implementations nominally providing
| the same feature will eventually converge on providing the same
| interpretation of all programs using that feature.
| 
| an example of the current oddities (at least they seem odd to me;):
| both hugs and ghc claim to resolve overlapping instances in favour
| of the most specific instance declaration. both claim that functional
| dependencies uniquely determine the range types from the domain
| types. but they do not agree on which programs to accept when
| we try to combine best-match with FDs.
| 
| I've already given an example where ghc allows me to define
| record selection, while hugs complains that the overlap violates
| the FDs.
| 
| I reported that as a hugs bug, because I think the best-match
| resolution of overlaps should ensure that the FD violation cannot
| happen, so the code should be valid. there are different ways to
| interpret FDs (something to check, or something to use), but it
| seemed that ghc was doing the right thing there. thread start:
| 
| http://www.haskell.org//pipermail/hugs-bugs/2006-February/001560.html
| 
| but after further experimentation, I'm not longer sure that ghc
| is doing the right thing for the right reasons. here is a tiny example
| of one of the disagreements:
| 
| {- ghc ok
|    hugs "Instance is more general than a dependency allows" -}
| 
| class C a b | a -> b
| instance C a b
| 
| so what is ghc doing there? is it going to guarantee that b will
| always be uniquely determined?
| 
| {- ghc ok
|    hugs "Instance is more general than a dependency allows" -}
| 
| class C b | -> b where c :: b
| instance C b     where c = error "b"
| 
| safely m = m `CE.catch` print
| main = do
|   safely $ print $ (c::Int)
|   safely $ print $ (c::Bool)
|   safely $ print [id,c]
| 
| oh, apparently not. unless b is uniquely determined to be universally
| quantified, and the instantiations happen "after" instance selection.
| 
| {- ghc ok
|    hugs "Instance is more general than a dependency allows" -}
| 
| class C b | -> b where c :: b
| instance C b     where c = error "b"
| 
| class D a where d :: a -> String
| instance C a => D a where d a = "a"
| instance C Int => D Int where d a = "Int"
| 
| -- try at ghci prompt:  (d 1,d (1::Int))
| -- gives: ("a","Int")
| 
| so that parameter of C isn't all that unique. at least not long enough
| to influence instance selection in D.
| 
| comments?
| 
| cheers,
| claus