the MPTC Dilemma (please solve)

Claus Reinke claus.reinke at
Tue Feb 28 14:12:28 EST 2006

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

generally, that may be true,-) but in this specific case, I was just asking 
for an effort to document the differences in current handling of extended
Haskell in hugs and ghc, by collecting test cases such as those I included. 

whether or not the haskell' process manages to help eradicate those 
differences is another matter, but collecting them seems a useful basis 
for decisions, hence a task rather than a proposal. I addressed that to 
you because (a) I was hoping this more moderate approach would be 
down your alley and (b) because you have a stake in this at ghc hq, 
and probably would want to collect the test cases for possible fixing.

I guess I will create the ticket myself, but if no committee member
or implementer has a stake in it, that won't do much good..

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

that might work. apart from the fact that I really, really hate the 
braindead wiki markup processor, especially when editing through
that tiny ticket change field instead of loading up text. I went through
that experience once, when Isaac suggested the same for my labels
proposal - I don't want to have to do that again.

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

perhaps I'll just restrict myself to attaching my example code to
some ticket (are guests allowed to update attachments?). will see..


| -----Original Message-----
| From: Claus Reinke [mailto:claus.reinke at]
| Sent: 25 February 2006 15:33
| To: Simon Peyton-Jones
| Cc: haskell-prime at
| 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:
| 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

More information about the Haskell-prime mailing list