Superclass defaults

[wren ng thornton]

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