[resend to GHC users, now I've subscribed!]
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.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users