I agree. Option 2 FTW :) The recent discussion concerns whether option 2 should eventually be shifted to option 1. Everyone seems to agree that option 2 should be used initially.
Regards, Jonas On 2 September 2011 18:55, Simon Peyton-Jones <simo...@microsoft.com> wrote: > Too many words! I'm losing track. What I'm proposing is Option 2 under "The > design of the opt-out mechanism" on > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances > > I believe that meets everyone's goals: > * A warning encourages you to fix the client code > * But you can turn it off, and it's not fatal. > > Does anyone advocate something else? > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users- > | boun...@haskell.org] On Behalf Of Jonas Almström Duregård > | Sent: 02 September 2011 16:50 > | To: Conor McBride > | Cc: GHC users > | Subject: Re: Superclass defaults > | > | > The question then comes down to whether that warning should ever be > | > strengthened to an error. > | > | Indeed. > | > | > I agree that such a scenario is possible. The present situation gives > | > no choice but to do things badly, but things often get done badly the > | > first time around anyway. Perhaps I'm just grumpy, but I think we > | > should aim to make bad practice erroneous where practicable. Once > | > the mistake is no longer forced upon us, it becomes a mistake that > | > deserves its penalty in labour. Silent pre-emption is bad practice and > | > code which relies on it should be fixed: it's not good to misconstrue > | > an instance declaration because you don't know which instance > | > declarations are somewhere else. Nonmonotonic reasoning is always a > | > bit scary. > | > > | > From a library design perspective, we should certainly try to get these > | > hierarchical choices right when we add classes. I accept that it should > | > be cheap to fix mistakes (especially when the mistake is lack of > | > foresight. Sticking with the warning rather than the error reduces the > | > price of this particular legacy fix at the cost of tolerating misleading > | > code. I agree that the balance of this trade-off is with the warning, > | > for the moment, but I expect it to shift over time towards the error. > | > But if it's clear what the issue is, then we can at least keep it under > | > review. > | > | I agree. Making bad practice erroneous is good, but its not really the > | bad practice that raises the error here. You have no serious problems > | until you try to change your bad design to a good one. Like you say it > | should be cheap to fix mistakes. > | > | >> Will there be a solution to this dilemma that I have missed? Should > | >> the client code be allowed opt-out from the superclass preemptively > | >> before it is given a default? Won't that cause a similar perplexity? > | > > | > I don't know what you mean by this. Perhaps you could expand on it? > | > | What I'm trying to ask is if you can write compatible code that will > | work across gradual changes of the compiler and the libraries. > | > | Suppose we have library with class C. In a newer version of the > | library we add an intrinsic superclass S. Also suppose the compiler > | implements option 1. Now the users of the library want to write code > | that uses both C and S, and that's compatible with both the new and > | the old library. From what I can tell there are three situations that > | needs to be covered: > | > | 1) Old compiler - Old library > | Here we need to specify both instances, and we cant hide the default S > | instance because its not supported by the compiler. This also applies > | for other situations where the client must use Haskell 2010 compatible > | code. > | > | 2) New compiler - Old library > | Here we also need to specify both instances. > | > | 3) New compiler - New library > | We can either write both instances and hide the default or we can just > | write an instance for C. > | > | Clearly code that covers situation 1 will never be compatible with > situation 3. > | > | The question I was asking was if we are allowed to hide the default > | instance of S in situation 2. In that case you can write compatible > | code for situation 2 and 3. The possible confusion from this is that > | you hide a default implementation thats not defined. Maybe it's not as > | bad as overriding silently, but there is some room for error where you > | think you have blocked a superclass instance but really you have just > | blocked some completely unrelated class. > | > | Of course we can get compatibility across all three using CPP but I > | really wish we won't need that. > | > | As time passes, situation 1 will become more rare, although situation > | 2 and 3 can reoccur endlessly as new libraries are designed and > | redesigned. > | > | Regards, > | Jonas > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
