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