On 8/15/11 7:44 AM, Conor McBride wrote:

On 15 Aug 2011, at 11:36, Simon Peyton-Jones wrote:

...

But, concerning proposed extensions to GHC about class aliases/superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue). Rather, it's uncertainty about

(a) Is there a reasonably large group of users who really want such a change? Or is it just "nice to have"?

(b) What is the "right" design?

(c) Does it pay its way? (ie do the programming benefits justify the cost in terms of both language complexity and ongoing maintenance burden of one more feature to bear in mind when changing anything) [...]

One thing that's really noticeable and sad about the status quo is that we can't refine the structure of a bunch of related classes without breaking established interfaces. I guess an interesting question might be what progress is effectively being blocked by our current inability to engineer around this problem. What are we stuck with just now?

Right. IMO, this concern deserves to be added to the three that Simon mentioned. In particular, I think this is more to the point than (a), though clearly in the same spirit. We've known that the monadic and numeric towers have been in need of refinement for quite some time, but the status quo actively impedes resolving the issues with the current design. While the numeric-prelude, yap, and other packages have made a go at setting up new hierarchies, the status quo essentially forces people to buy into a single hierarchy for all their work because intercompatibility is just too hard. Due to package dependencies, this amounts to sending Haskell down the route of Lisp dialects, which adds additional compatibility problems to the original class hierarchy issues. Thus, the age-old response that people can set up their own class hierarchies has been shown not to work in practice. To my mind, this means that Simon's (a) or my/Conor's (a') is resolved with certainty. The remaining issues are the uncertainty with (b) and (c). Naturally the answer to (c) is going to depend on the design given in (b). So I suppose I ought to read the wiki page about the current proposal :) -- Live well, ~wren

| > I don't completely understant how does it work. Does client need to enable | > language extension to get default instances? | | I think that the extension would only be required to *define them*, | not for them to be generated. The more conservative choice would | indeed be to require the extension for both, though. Yes. I've clarified http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to say this. | > Also proposal cannot fix Functor/Applicative/Monad problem without breaking | > client code. It requires explicit opt-out but client may define Applicative | > instance. And unless "hiding" is added it will result in compile error. | | I think the intention (at least as I understand it) is that a | superclass default is only used to generate an instance if there is | not already some suitable instance in scope, just like a default | method is only used if there is not some explicit definition for the | method in the instance. Actually that is not what Conor and I proposed. See http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances. Under "Variations" we discuss the "silent-opt-out" choice. But it's bad enough knowing exactly what instances are in scope (given that they are not named), let alone having that control what further instances are or are not generated! For superclass defaults there is no such ambiguity. Simon

"Option 3 avoids that problem but risks perplexity: if I make use of some cool package which introduces some Foo :: * -> *, I might notice that Foo is a monad and add a Monad Foo instance in my own code, expecting the Applicative Foo instance to be generated in concert; to my horror, I find my code has subtle bugs because the package introduced a different, non-monadic, Applicative Foo instance which I'm accidentally using instead."

talks about "subtle bugs". Could you give an example of such a bug?

I would expect that the non-monadic Applicative Foo instance is always  somehow "compatible" with the monadic one. However I don't have a clear definition of "compatible" yet...

I think it's something like that. Module Foo defines list and make ZipList-like Applicative instance. Would you add standard list monad you have a bug. But if you add monad instance which is not compatible with existing applicative you have bug whether you use extension or not. module Foo where data [a] = a : [a] | [] instance Functor [] where fmap = map instamce Applicative [] where pure = repeat (<*>) = zipWith ($) module Main where instance Monad [] where return x = [x] (>>=) = concatMap

Hi, First of all, I love the idea of default superclass instances! About the opt-out feature, the problem with option 3 is only present if the superclass instance is defined in another module (you won't see unexpected behavior from your own instances). One solution is to use option 3 if the offending is defined in the same module and reject/warn only when there is a superclass instance in another module. This way users are not surprised when the compiler rejects a Functor/Applicative pair because they need to explicitly tell it to hide the intrinsic Functor, and the case that Functor and Applicative instances are defined in separate modules must be relatively rare (outside the Applicative library)? We might even require the data type to be defined in the same module (which i guess is easier to check and still very common) to silently override a default? Documenting this feature might not be very pretty i guess... I think the most important thing is to enable users to write compatible code, i.e. modules that works with the Applicative class whether it defines a default Functor or not. I suppose if option 1 is used, hiding should be allowed even for classes that would not have been defined anyway (with a warning)? If we allow the Multi-headed instance declarations described in the suggestion then we can always write compatible code by merging instances, since an instance for (Functor,Applicative) would always hide the default Functor instance if there is one (right?). Regards, Jonas On 28 August 2011 23:21, Bas van Dijk wrote:

On 22 August 2011 10:10, Simon Peyton-Jones wrote:

...

| > I don't completely understant how does it work. Does client need to enable | > language extension to get default instances? | | I think that the extension would only be required to *define them*, | not for them to be generated. The more conservative choice would | indeed be to require the extension for both, though.

Yes. I've clarified http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to say this.

| > Also proposal cannot fix Functor/Applicative/Monad problem without breaking | > client code. It requires explicit opt-out but client may define Applicative | > instance. And unless "hiding" is added it will result in compile error. | | I think the intention (at least as I understand it) is that a | superclass default is only used to generate an instance if there is | not already some suitable instance in scope, just like a default | method is only used if there is not some explicit definition for the | method in the instance.

Actually that is not what Conor and I proposed.  See http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances.  Under "Variations" we discuss the "silent-opt-out" choice.  But it's bad enough knowing exactly what instances are in scope (given that they are not named), let alone having that control what further instances are or are not generated!  For superclass defaults there is no such ambiguity.

Simon

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Won't option 1 "Reject this as a duplicate instance declaration, which indeed it is." conflict with design goal 1: "a class C can be re-factored into a class C with a superclass S, without disturbing any clients"?

Take the transformers package for example. It defines lot's of instances of Functor and Applicative for its monad transformers. Doesn't transformers have to be changed if we go for option 1 (by either dropping the Functor and Applicative instances or listing hiding clauses in the Monad instances) thereby seriously conflicting with the design goal of not disturbing any clients.

I expected the semantics to be like option 3: "Allow the explicit to supersede the intrinsic default silently". It has the advantage of:

1) Not disturbing any client code.

2) Giving the ability to define optimized implementations if you're not happy with the default ones (without using the hiding mechanism).

3) Feeling very much like the semantics of default methods thereby conforming to the rule of least surprise.

The argument against option 3, which I quote:

"Option 3 avoids that problem but risks perplexity: if I make use of some cool package which introduces some Foo :: * -> *, I might notice that Foo is a monad and add a Monad Foo instance in my own code, expecting the Applicative Foo instance to be generated in concert; to my horror, I find my code has subtle bugs because the package introduced a different, non-monadic, Applicative Foo instance which I'm accidentally using instead."

talks about "subtle bugs". Could you give an example of such a bug?

I would expect that the non-monadic Applicative Foo instance is always  somehow "compatible" with the monadic one. However I don't have a clear definition of "compatible" yet...

Thanks,

Bas

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

| > Won't option 1 "Reject this as a duplicate instance declaration, which | > indeed it is." conflict with design goal 1: "a class C can be | > re-factored into a class C with a superclass S, without disturbing any | > clients"? Yes, option 1 does conflict with design goal 1; good point. There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? I've updated the wiki page http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to reflect this discussion. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Sebastian Fischer | Sent: 30 August 2011 03:49 | To: Bas van Dijk | Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones | Subject: Re: Superclass defaults | | On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk wrote: | | > Won't option 1 "Reject this as a duplicate instance declaration, which | > indeed it is." conflict with design goal 1: "a class C can be | > re-factored into a class C with a superclass S, without disturbing any | > clients"? | | If yes, I prefer option 3: | | > "Allow the explicit to supersede the intrinsic default silently". | | The argument against this option is: | | > I might notice | > that Foo is a monad and add a Monad Foo instance in my own code, | > expecting the Applicative Foo instance to be generated in concert; to | > my horror, I find my code has subtle bugs because the package | > introduced a different, non-monadic, Applicative Foo instance which | > I'm accidentally using instead. | | This seems rare enough that it's feasible to issue a warning if a | default instance is overwritten by an explicit instance in a different | module which would prevent the described perplexity. This wouldn't, | for example, disturb the transformers example mentioned by Bas because | (I think) all instances are defined in the same module. | | Sebastian | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi Sorry to be late again...I'm trying to have what's laughably described as a holiday, but it seems more like the common cold to me. On 31 Aug 2011, at 08:52, Jonas Almström Duregård wrote:

| > There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)?

At least in the short term, I think Option 2 is a good compromise. It's true that when I started using default superclass instances (which SHE supports) in the Epigram codebase, the first thing I had to do was delete a bunch of dull default instance stacks. That was fun, but it wasn't nothing.

I think option 2 sounds very good. Possibly with the exception of only warning when the manual instance is in another module, since you will never experience the "perplexity" described in option 3 if you have written the instance yourself.

I become perplexed very easily. I think we should warn whenever silent pre-emption (rather than explicit) hiding is used to suppress a default instance, because it is bad --- it makes the meaning of an instance declaration rather more context dependent. Perhaps a design principle should be that to understand an instance declaration, you need only know (in addition) the tower of class declaration s above it: it is subtle and worrying to make the meaning of one instance declaration depend on the presence or absence of others. Arguably, option 1 does not conflict with design goal 1. Design goal 1 supports a methodology for refining a class into a hierarchy without creating the need for stacks of default instances or breaking code. If the new superclass is a brand new thing without legacy instances, there's no problem. If we'd had this mechanism in place, Functor would always have been made a superclass of Monad, Applicative would have been easily inserted, and we wouldn't have the stacks of manually added default instances to worry about. The main problem with Option 1 is in dealing with the legacy of classes which currently require a stack of default instances, creating a hierarchy from parts which already exist. Option 1 would create a bunch of instance conflicts and thus demand changes to code. Design goal 1 isn't very explicit (sorry!) about this distinction between introducing new classes as superclasses and building hierarchies from legacy classes, but it was the former I intended. I always expected the latter to cause trouble. If it is also a design goal to minimize damage with respect to the current unfortunate situation, then Option 1 is problematic. Whatever we might wish, we are where we are. We should be pragmatic. I think we should set Option 1 as the direction of travel, but go with Option 2 for the moment. We should make sure that the warnings generated by Option 2 are sufficiently informative that it is easy to track down the conflicts and resolve them explicitly, for Option 1 compliance. Does this sound plausible? Conor

Hi On 2 Sep 2011, at 10:55, Jonas Almström Duregård wrote:

On 31 August 2011 12:22, Conor McBride wrote:

...

I become perplexed very easily. I think we should warn whenever silent pre-emption (rather than explicit) hiding is used to suppress a default instance, because it is bad --- it makes the meaning of an instance declaration rather more context dependent. Perhaps a design principle should be that to understand an instance declaration, you need only know (in addition) the tower of class declaration s above it: it is subtle and worrying to make the meaning of one instance declaration depend on the presence or absence of others.

Those are all good arguments, and you've convinced me that always warning is better.

The question then comes down to whether that warning should ever be strengthened to an error.

First of all, I think the design goal is quite clear: "a class C can be re-factored into a class C with a superclass S, without disturbing any clients". Requiring client C to opt-out from the default implementation of S is a clear violation of the design goal. So I disagree that option 1 can be compatible with the design goal, but like you say the design goal might be at fault.

Design goal 1 does not explicitly distinguish the scenarios where S is pre-existing or being introduced afresh. If the former, it's inaccurate to describe what's happening as refactoring C, for S is experiencing some fall-out, too. We should clearly seek more precision, one way or another.

Also, if I understand you correctly, you say the current situation is exceptional, and suggest option 2 as a temporary solution to it. You seem convinced that these kind of situations will not appear in the future, but I'm not as optimistic about that.

Even when superclass defaults are implemented, people will occasionally implement classes without realizing that there is a suitable intrinsic superclass (or add the superclass but not the default instance). People will start using the new class and give separate instances for the superclass, and eventually someone will point out that the there should be a default instance for the superclass. Now if option 1 is implemented, the library maintainers will be reluctant to add the superclass instance because it will break a lot of client code.

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.

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? All the best Conor

Hi On 2 Sep 2011, at 16:34, Brandon Allbery wrote:

I hope I am misunderstanding this....

I wrote:

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

with the response:

So, when the whole point is that an unfortunate design years ago can't be reasonably fixed without rewriting massive amounts of code, the only correct answer is to rewrite massive amounts of code?

I'm not sure what you're asking here. Of course we should compare the pain of the treatment with that of the symptoms.

Especially when the original proposal was put forward *specifically to avoid* rewriting massive amounts of code?

Which original proposal? How does it avoid rewriting code?

Yes, we'd love a perfect world. We don't have one. That's the *point*.

Recall that Option 2 resolves the duplicate superclass instances in favour of an explicit prior instance, but issues a warning (which should offer the data to choose between explicit resolutions). That deals with a chunk of the legacy scenario (although it doesn't handle the situation where some M is made a Monad in one module and made Applicative in a later module, which is possible (common, even?) because Applicative is not currently a superclass of Monad). If we make one existing class a superclass of another existing class, some disruption is inevitable: we can try to minimize that disruption, but we can't eliminate it entirely. For another example, if some F is made Applicative and Traversable in the same module, which default Functor instance pre-empts the other? We should question whether the disruption of even Option 2/3 makes it worth adding default superclass instances at all. Maybe, depressingly, we've reached the can't-fix-it stage. It would be good to get some data. It's also worth considering tools to support migration, using the diagnostics generated by warnings. If it is worth adding default superclass instances, Option 2 looks like a crucial disruption-minimizing expedience, while we have a legacy of newly extraneous instances to deal with. As far as "an unfortunate design years ago" is concerned, we should be careful to minimize the amount of rewriting required. If that minimum is still too much, we'd better not go there. I'm in favour of moving to Option 1 eventually, as somehow the better choice for code comprehension. But I can see reasons to resist the changeover: * too much unmigrated code still relying on pre-emption under Option 2; * new instances of the old problem (an existing S is suddenly made a superclass of an existing C, with a default S instance for C) come into being, The former is a real risk, but hopefully with a finite lifespan. It would be too costly to switch from a warning to an error while too much code relies on the deprecated practice. Please don't imagine I'm in favour of that. The latter, however, requires us to be a bit dim in a way which was certainly not in evidence when most of the current motivating examples arose. In the legacy code (Monad-Applicative-Functor, Traversable-Foldable-Functor), we've had to choose between two bad options, but the candidate superclass-with-default-implementation has usually been evident. I'm sure we're capable of being that dim. I'm also sure we're capable of screwing up by writing an instance and assuming we get the default superclass instance we expect, without noticing that someone else's chunk of the codebase pre-empts it. I'd be troubled if someone knackered my applicative- style use of Monad [] by adding a zipping Applicative [], or even an instance which appeared to have the same functionality but also did some sneaky unsafePerformIO badness. That's an example of the risk we take by allowing pre-emption. We have to balance the risk of going back and resolving duplicates with the risk of bugs caused by code meaning less than it says. So, are default superclass instances just too disruptive? All the best Conor PS We'd love a perfect world. We don't have one. That's why we change things.

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

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- default 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 Conor

Regards, Jonas

On 2 September 2011 18:55, Simon Peyton-Jones 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-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

On Mon, Aug 22, 2011 at 10:05 AM, Max Bolingbroke < batterseapower@hotmail.com> wrote:

On 21 August 2011 21:03, Alexey Khudyakov wrote:

...

I don't completely understant how does it work. Does client need to enable language extension to get default instances?

I think that the extension would only be required to *define them*, not for them to be generated. The more conservative choice would indeed be to require the extension for both, though.

Please allow me to voice my not-so-humble opinion that, as a rigid principle, any extension is ALWAYS enabled with a flag, and never enabled silently. This is what Max calls the "conservative" choice, while I would like to call it the "only sensible" choice. 1. In particular: adhering to this principle makes it much much easier to achieve consistency between different compilers and tools working with Haskell code. GHC is currently in so strong a position as to make its own laws, but with great power comes great responsibility. Even if GHC will always have the proper context available, it is by no means certain that other tools will. In this particular instance, it is certainly not inconceivable or even improbable that tools other than compilers might want to analyse a module containing instance declarations, without knowing a priori that some default superclass instances are assumed. Having a flag always makes this clear. (As an example, GHC already breaks this principle in (at least) one instance - MPTC when used as contexts - which creates problems for haskell-src-exts). 2. If you are worried about breakage of legacy code, you can always achieve silent enabling by having a flag and having it on by default. Then GHC can declare that it, by default, compiles a Haskell extension and not the standard. This could still create problems when programmers expect other tools to work on their GHC-specific files, but then at least we have a clear story and can put blame where blame is due (on GHC). Other tools can then also opt to enable the same extensions by default, or by flag. Also, it would make it possible to explicitly remove the flag in client code (with the appropriate -XNo... flag).

From a principle point of view this is still not a perfect solution, and I would prefer that an explicit flag was always needed (unless and until the extension is adopted in the proper Haskell' revision). I realise this would break a lot of code though, and having a flag enabled by default is far, far better than not using a flag at all.

3. I must admit I don't fully see how client code can be kept from the need to enable the extension. In particular, if client code must use the explicit opt-out, this is a rather obvious syntactic change - are you really suggesting that we enable new syntax without the need to declare what language (i.e. extensions) the file uses? Of course, there is precedent for such a move with the ugly MPTCs-in-contexts mentioned above - a precedent that I would very much like to see revoked. I would in any case like to voice my very strong opinion against such a choice. That said - I definitely like the general idea of default superclass instances, I think the proposed extension is very elegant and fixes a definite wart. But please let's not introduce other problems by adopting it! To be concrete, I propose the following named extensions (exact names up for bike-shed discussion): * DefaultSuperInstances: Enables the full SHE-bang (pun fully intended), including in particular the syntactic additions in class and instance declarations. * SilentDefaultSuperInstances: Enables ONLY the possibility for client code to use inherited default instances. This extension is subsumed by DefaultSuperInstances (except for error/warning behavior discussed below), just like RankNTypes subsumes Rank2Types. I further propose that GHC enables SilentDefaultSuperInstances by default, as a pragmatic choice to avoid legacy issues, but not DefaultSuperInstances. If (only) SilentDefaultSuperInstances is enabled, I propose that Option 2 is used. It makes perfect sense to warn if you override a default instance, just like it is sensible to warn about name shadowing. Option 3 strikes me as strictly worse. However, if DefaultSuperInstances is enabled (which must then be done explicitly), I propose that Option 1 is used instead. 2011/9/2 Conor McBride

On 2 Sep 2011, at 18:19, Jonas Almström Duregård wrote:

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.

With my proposal this discussion becomes moot. SilentDefaultSuperInstances effects option 2, DefaultSuperInstances effects option 1. The discussion can then instead turn to whether or not DefaultSuperInstances should be adopted in Haskell', and (only) at that point there will be an automatic switch to option 1. A similar warning should perhaps indicate that a "hiding" clause has

nothing to hide, as Jonas suggests.

Yes, I agree with this.

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.

... and the proper transition process from one to the other is the Haskell' process. What sayeth ye all? Cheers, /Niklas