Superclass defaults

[Jonas Almström Duregård]

| > 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 <simonpj at microsoft.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"?
>
> 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
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>