Superclass defaults

[Sebastian Fischer]

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