>>It is not that simple, at least not for the general case (i.e. with no
>>limitations on the superclasses).  The trickiest thing is the instance
>>layout.
>>Alternative solutions would need the VM support.

>That's no problem as I actually talked about a VM-level solution and asked
>whether this small VM change would be enough.

Speaking in general (across the space of interpreted and compiled
implementations of languages in general) multiple inheritance is
not at all simple.  It may look simple in a particular interpreted
VM, but other yet-to-be-designed/written implementations for that
same language just got much more difficult.

For example, when there is single inheritance, there are relatively
simple algorithms that require a small per-type space overhead, that
allow you to determine in constant time if one type is a subtype
of another, and that allow you to determine in O(log N) time (after
preprocessing of an N-element sequence of types) which is the first
match from a sequence of N types.  In this case, only O(N) storage
is required for the data structure.

If you want to consider Java, and its singly-inherited classes and
multiply-inherited interfaces, you'll find that the VM spec and
the bytecode generators (java-to-bytecode compilers) are inconsistent
in their treatment of interface types, and have remained inconsistent
for a year after having had this problem pointed out.  Multiple
inheritance is more complicated than it looks.

Note that this Java experience suggests that banning multiple
inheritance of instance variables (that is, "interfaces", to use
the Java jargon) does not do away with all MI problems, though
it takes care of some.  Any state sharing that occurs undermines
any sort of black-box reasoning that you might like to apply to
parts of a complex program; if two inherited types unwittingly
share state, you're hosed.  (Yes, it is possible to devise a
"multiple inheritance" that does not share state.)

David Chase
NaturalBridge LLC