Superclass defaults

[Simon Peyton-Jones]

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