Generic deriving: new default methods

[Simon Peyton-Jones]

| * Does the generic default have to be fixed at the time of the class
| definition?
| 
| I think that Pedro's proposal's say "no", whereas Simon's proposals
| imply "yes" to this question. I think that it may be a common scenario
| that someone writes a library defining a class, and someone else comes
| up with a generic way to define instances for the class. I think it
| would be good if we could support that.

Harumph.  Well that would involve a new nest of design issues

* What if there was more than one generic default visible?

* What if a class had both a H98 default for a method, and a "later" generic default?

* Could the generic defaults be overlapping? eg
	generic instance Representable a => C a where
	  op4 = blah
	generic instance Representable a => C [a] where
	  op4 = blah-list

* What does it mean for a generic default to be "visible" anyway?  I suppose you could say "use the same rules as instance declarations, but those rules are horrible.

* Can different methods (op3 and op4) have different generic defaults?  eg
	generic instance Representable a => C a where
	  op3 = blah3

	...and somewhere else...

	generic instance Foogle a => C a where
	  op4 = blah 4

* How do generic instances differ from ordinary (overlapping) instances.  They are pretty close as you can see above.


Now there are legitimate questions about "superclass defaults" etc, see http://hackage.haskell.org/trac/ghc/ticket/788 and http://hackage.haskell.org/trac/ghc/ticket/2895.  But I don't want to conflate the two.

So for my money, I say let's stick to the H98 mechanism, of specifying defaults with the class, and treat the issue of overriding etc separately.

Or can you see simple answers to the above?


Simon