Scalable and Continuous

[Matt Harden]

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