Superclass defaults
wren ng thornton
wren at freegeek.org
Mon Aug 15 23:07:55 CEST 2011
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
More information about the Glasgow-haskell-users
mailing list