On 8/15/11 7:44 AM, Conor McBride wrote:
On 15 Aug 2011, at 11:36, Simon Peyton-Jones wrote:
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)
[...]
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?
Right. IMO, this concern deserves to be added to the three that Simon
mentioned. In particular, I think this is more to the point than (a),
though clearly in the same spirit.
We've known that the monadic and numeric towers have been in need of
refinement for quite some time, but the status quo actively impedes
resolving the issues with the current design. While the numeric-prelude,
yap, and other packages have made a go at setting up new hierarchies,
the status quo essentially forces people to buy into a single hierarchy
for all their work because intercompatibility is just too hard. Due to
package dependencies, this amounts to sending Haskell down the route of
Lisp dialects, which adds additional compatibility problems to the
original class hierarchy issues. Thus, the age-old response that people
can set up their own class hierarchies has been shown not to work in
practice.
To my mind, this means that Simon's (a) or my/Conor's (a') is resolved
with certainty. The remaining issues are the uncertainty with (b) and
(c). Naturally the answer to (c) is going to depend on the design given
in (b). So I suppose I ought to read the wiki page about the current
proposal :)
--
Live well,
~wren
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
