Superclass defaults

Brandon Allbery allbery.b at
Fri Sep 2 17:34:25 CEST 2011

I hope I am misunderstanding this....

2011/9/2 Conor McBride <conor at>

> Also, if I understand you correctly, you say the current situation is
>> exceptional, and suggest option 2 as a temporary solution to it. You
>> seem convinced that these kind of situations will not appear in the
>> future, but I'm not as optimistic about that.
>> Even when superclass defaults are implemented, people will
>> occasionally implement classes without realizing that there is a
>> suitable intrinsic superclass (or add the superclass but not the
>> default instance). People will start using the new class and give
>> separate instances for the superclass, and eventually someone will
>> point out that the there should be a default instance for the
>> superclass. Now if option 1 is implemented, the library maintainers
>> will be reluctant to add the superclass instance because it will break
>> a lot of client code.
> I agree that such a scenario is possible. The present situation gives
> no choice but to do things badly, but things often get done badly the
> first time around anyway. Perhaps I'm just grumpy, but I think we
> should aim to make bad practice erroneous where practicable. Once
> the mistake is no longer forced upon us, it becomes a mistake that
> deserves its penalty in labour. Silent pre-emption is bad practice and

So, when the whole point is that an unfortunate design years ago can't be
reasonably fixed without rewriting massive amounts of code, the only correct
answer is to rewrite massive amounts of code?  Especially when the original
proposal was put forward *specifically to avoid* rewriting massive amounts
of code?

Yes,  we'd love a perfect world.  We don't have one.  That's the *point*.

brandon s allbery                                      allbery.b at
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list