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
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-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@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