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 _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
