Re: Superclass defaults

| > There seems to be a lot of support for Option 3... but what about Option 2 (ie pre-empt but give a warning)? 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. This means that most modules will not get any warning when a class is changed to give a default superclass instance. Even omitting the warning only when the instantiated datatype is in the same module as the instances might be enough to suppress most warnings. Also i wonder if there will be a way of suppressing the warnings and still have compatible code (with the current compiler, preferably without using CPP)? /J On 31 August 2011 09:21, Simon Peyton-Jones 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"?

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

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