conor at strictlypositive.org
Fri Sep 2 19:48:44 CEST 2011
On 2 Sep 2011, at 18:19, Jonas Almström Duregård wrote:
> 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.
A similar warning should perhaps indicate that a "hiding" clause has
nothing to hide, as Jonas suggests.
I'm in favour of Option 2 now and Option 1 later, where "later" has
non-disruptiveness criteria attached. A bit like being in favour of
the pound now and the euro later.
As I've mentioned in another message just now, even Option 2 entails
some disruption, when you make one old class a new superclass-with-
of another (e.g. Functor for Monad): if old code makes M a Functor in a
later module than its Monad instance, that Functor M instance comes too
late to pre-empt the default and is rejected as a duplicate.
All the best
> On 2 September 2011 18:55, Simon Peyton-Jones
> <simonpj at 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?
>> | -----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
>> | > 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
>> | > 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
>> | > 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
>> | > code. I agree that the balance of this trade-off is with the
>> | > for the moment, but I expect it to shift over time towards the
>> | > 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
>> | 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?
>> | >> the client code be allowed opt-out from the superclass
>> | >> before it is given a default? Won't that cause a similar
>> | >
>> | > I don't know what you mean by this. Perhaps you could expand on
>> | What I'm trying to ask is if you can write compatible code that
>> | 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
>> | 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
>> | 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
>> | for other situations where the client must use Haskell 2010
>> | 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
>> | 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
>> | 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
>> | 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
>> | 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
More information about the Glasgow-haskell-users