On Mon, Aug 15, 2011 at 12:36 PM, 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?
My only input is that we have at least 2-3 (depending on whether the latter two are to be considered separate) hierarchies in want of refactoring: Functor/Applicative/Monad, Num and friends, and Monoid. Ideally any solution would "solve the problem" for all of them, but even if it doesn't (and only solves, say, Monad's case), I think it should be a requirement that it at least allows for the others to be solved as well in an incremental fashion afterwards (whether by 'upgrading' the by-then existing feature, or adding a new, orthogonal one). The undesirable scenario would be where you would have to "change the world" all over again a second time to resolve the remaining problems. This is just in the abstract; my brain is too under-resourced to figure out where the proposed feature stands in relation to this. (On its own terms, I like it.)
(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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Work is punishment for failing to procrastinate effectively.