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