| > 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 <[email protected]> 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: [email protected] > [mailto:glasgow-haskell-users- > | [email protected]] On Behalf Of Sebastian Fischer > | Sent: 30 August 2011 03:49 > | To: Bas van Dijk > | Cc: [email protected]; Simon Peyton-Jones > | Subject: Re: Superclass defaults > | > | On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk <[email protected]> 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 > | [email protected] > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
