On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk
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