Superclass defaults

[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 at haskell.org [mailto:glasgow-haskell-users-
| bounces at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users