Hi Cedric,

...

http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/

Good compromise between complexity, typing and usefulness.

[unfortunately also limited, which is the reason that we came up with the monadic version: PoorMens2.]

I noticed that both Rectangle and Circle need to redefine the operators because of the different names of their respective delegate to Shape, namely rectangle2shape and circle2shape.

I we were to give these fields the same name ('parent', or 'super') in both Rectangle and Circle, could it be that we can avoid to redefine the operators by moving their definition upwards (and thus requiring only one definition for both classes) ?

Won't work. ;-) Haskell standard records are not polymorphic like this. You can't write an operation that uses a record selector without committing to a specific record type. (With HList that underlies OOHaskell, of course, you can!!!) This is *precisely* the reason that: - Gracjan's code had a get_super. - my code has the generic .?. operator. We could try to give up on using "normal" records. That is, we could use a tuple convention where the first projection returns the data part of the base class, and the second projection returns the contribution of the derivation. However, this won't get us anywhere. We need the nominal types introduced by the new record types in order to represent the inheritance hierarchy in the type system (through the Inherits or Subtype classes).

Would it then be a problem if we further subclass Rectangle in, say, two subclasses Square and NonSquareRectangle ? Would that still work or would there be a collision between the multiple 'parent' fields ?

Due to the abovementioned reasons, any sort of parent fields will not interfere. Repeated inheritance simply leads to nested data composition; that's Ok. Ralf