Superclass defaults

[Simon Peyton-Jones]

(Adding GHC users, and changing title.)

| Conor McBride wrote:
| > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
| > I don't know if it's likely to be implemented in GHC anytime soon,..
| > So things are looking up. It should soon be technically feasible to
| > separate the issues of whether the Monoid operator should be (<>) and
| > whether it should actually live in a Semigroup superclass...
| 
| Nice. But will it be happening soon, or not? And how soon is
| soon?

Not soon enough to be useful for this mappend question.

But, concerning proposed extensions to GHC about class aliases/superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue).  Rather, it's uncertainty about 

 (a) Is there a reasonably large group of users who really want such a change?  
     Or is it just "nice to have"?

 (b) What is the "right" design? 

 (c) Does it pay its way? (ie do the programming benefits justify the cost in terms of
     both language complexity and ongoing maintenance burden of one more feature 
     to bear in mind when changing anything)

With help from Conor we have made some progress on this: we have a draft design:
	http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

If you care about the issue, maybe you can help resolve the above questions. In particular, to give 
concrete evidence for (b), working out some case studies would be a Good Thing. The examples given in other proposals using the extension proposed here would be one starting point.

If someone felt able to act as moderator for the discussion, willing to summarise conclusions, open questions, and so on, on the wiki page, that would be enormously helpful.  I am in too many inner loops.   But I *am* willing to contemplate such an extension -- it has the same flavour as default methods themselves, which are a very useful part of H98.

Simon