[Haskell] Superclass default methods
Yitzchak Gale
gale at sefer.org
Mon Mar 28 06:46:20 EST 2005
Thomas Hallgren wrote:
> If classes were allowed to declare default
> methods for superclasses...
Benjamin Franksen wrote (on Haskell Libraries):
> Robert Will has written a fully specified proposal for this. He calls it
> "delayed method definition", see
> http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/, sections... 4.3.2.
> Looks like a really good idea to me.
Cale Gibbard wrote:
> One issue might be which default instance gets chosen
> when two classes both provide default instances for a
> given class. Perhaps in this case, we can just force the
> user to provide an instance,
In other words, we either
(a) throw a compile-time error, or
(b) issue a compile-time warning and bind the method to
undefined.
Robert Will's specification is not completely explicit
about which of these to choose, but he implies (a).
> or produce a compile-time warning and select one
> automatically in some canonical fashion.
No, that would lead to problems. See below.
Simon Peyton-Jones wrote:
> It seems overkill to have a whole new language feature
> to deal with one library issue.
Ross Paterson wrote:
> It's not just here -- this would make lots of fairly
> fine-grained class hierarchies a lot less painful.
Right. This is not just one library issue. In my opinion
it is a major limitation in Haskell's type system.
This restriction has often forced me to write gobs of
boiler-plate code, and to make awkward distortions in what
should have been simple hierarchies of classes.
> The idea comes up very occasionally...
For me it comes up all the time. This is an upward-compatible
change that is very intuitive.
Ross Paterson also wrote:
> But I agree that there's a cross-module problem.
No. A cross-module problem only arises if we arbitrarily
choose a default method when there is an ambiguity.
If we choose (a) or (b) above, there is no problem.
-Yitz
More information about the Haskell
mailing list