Superclass defaults

[Conor McBride]

Hi Simon

On 15 Aug 2011, at 11:36, Simon Peyton-Jones wrote:

> | 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)

> 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.

I can't speak for "typical" users, but I can relay my own experience.
I added this feature to SHE last time there was an outbreak of
Functor/Applicative/Monad, just to focus a bit of concrete thought on
the matter. Hacking on Epigram the other day, I finally got annoyed
enough (with dumb extra instances) to use it, so I wired in default
superclass instances

   Functor for Applicative, Applicative for Monad
   Functor for Traversable, Foldable for Traversable
   Alternative for MonadPlus

and then went on the rampage! Nothing broke. I got rid of a lot of
cruft. I did make essential use of

   hiding instance Functor

for structures which were both Applicative and Traversable. I cut
tens of lines for the cost of one or two hidings.

> 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'm up for that role, if that's appropriate.

>  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.

One thing that's really noticeable and sad about the status quo is that
we can't refine the structure of a bunch of related classes without
breaking established interfaces. I guess an interesting question might
be what progress is effectively being blocked by our current inability
to engineer around this problem. What are we stuck with just now?

This is a recurring issue, at least as far as mailing list heat is
concerned, but it would be good to have more evidence of substantial
impact. The Monoid vs Semigroup issue is a case in point, perhaps.
Folks, what do you think?

Cheers

Conor

PS Are there any other default superclass instances for standard classes
that SHE could usefully bake in? Sadly, we can't purge redundant methods
from standard classes just yet, but we can at least get rid of
boilerplate instances.