Marcin 'Qrczak' Kowalczyk wrote:
I'm afraid of making too many small classes. But it would perhaps be not so bad if one could define superclass' methods in subclasses, so that one can forget about exact structure of classes and treat a bunch of classes as a single class if he wishes. It would have to be combined with compiler-inferred warnings about mutual definitions giving bottoms.
I totally agree with this. We should be able to split up Num into many superclasses, while still retaining the traditional Num, and not inconveniencing anybody currently using Num. We could even put the superclasses into Library modules, so as not to "pollute" the standard Prelude's namespace. The Prelude could import those modules, then define Num and Num's instances, and only export the Num stuff. We shouldn't have to be afraid of making too many classes, if that more precisely reflects reality. It is only the current language definition that makes us afraid of this. We should be able to work with a class, subclass it, and define instances of it, without needing to know about all of its superclasses. This is certainly true in OOP, although I realize of course that OOP classes are not Haskell classes. I also wonder: should one be allowed to create new superclasses of an existing class without updating the original class's definition? Also, should the subclass be able to create new default definitions for functions in the superclasses? I think it should; such defaults would only be legal if the superclass did not define a default for the same function. What do you mean by mutual definitions? Matt Harden