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