Modeling multiple inheritance

[Brandon Michael Moore]

On Fri, 26 Sep 2003 oleg at pobox.com wrote:
>
> Brandon Michael Moore wrote regarding the first solution: chain of
> super-classes:
>
> > I'm worried about large class hierarchies. If it works on the
> > java.* classes I should be fine. Have you used this approach before? I'm
> > worried about compile time, runtime costs from the casts (hopefully they
> > compile out), and maybe exceeding maximum stack depth in context
> > reduction.
>
> I didn't use the approach for anything as complex as all java.*
> classes. The only run-time costs are evaluating the chain of fst . snd
> . fst . ....

I think I can use the pair types as phantom types on a reference type, so
my casts will hopefully be the identity function. (.) should be small
enough to inline, so GHC probably compiles id . id ... id to id. Correct?

> The length and the composition of the chain is statically
> known. Perhaps the compiler can do something smart here. The maximum
> length of the chain is the maximum depth of the inheritance tree. It
> shouldn't be too big. A cast from a subclass to a superclass has to be
> executed anyway (if not by your code then by JVM). If the maximum
> stack depth is exceeded, we can repeat the compilation with a compiler
> flag to allocate a bigger stack. In my experience the only time I've
> seen the derivation stack depth exceeded is when the derivation truly
> diverges.

Same for me, but I've never tried to model the java.* hierarchy either. I
think you get a cast (fst in your code) for each parent of each ancestor
along the inheritance path, which probably increses the count some.

Your code doesn't quite work. The instances you gave only allow you to
inherit from the rightmost parent. GHC's inference algorithm seems to pick
one rule for a goal and try just that. To find instances in the first
parent and in other parents it needs to try both. I think I'll just give
up on inheriting methods, and generate unrelated instances for each class
that needs one.

Brandon