[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