On Mon, Aug 15, 2011 at 12:36 PM, Simon Peyton-Jones <simo...@microsoft.com> wrote: > (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 > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
