[Grace-core] Multiple inheritance & module inheritance

[Michael Homer]

On Mon, Mar 16, 2015 at 8:25 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
> Maybe I'm missing something, but this seems mainly to be an example of why family polymorphism is very tricky to get right.  Your example of overriding a in a subobject of module is clearly unsafe.  Any reasonable definition of family polymorphism would ban this.
>
> In fact, I think it would be a bad idea at this point for us to incorporate family polymorphism.  That is, one should not be able to override a class definition in "module" in any subobject of "module".
>
> If one did want to allow that (and again, I don't think we should), then one would have to insist that the new class extend the old in that it would have to have an x def in it.  There are rules for safe family polymorphism that are available in various places, but again I don't believe (at least at this point) that we should attempt to support family polymorphism.
>
> So suppose we were to ban family polymorphism.  Is there still an issue?
>
> I can imagine that there are situations where we might lose the "statically-known" property, but I don't see the problem of inheriting from a class in a module (as opposed to overriding a class in a module).
>
> Again, help me out here in understanding the problems.
1) Inheritance 2) Overriding (general) methods 3) Uniform access. Pick any two.

You can have no inheritance, and all problems with inheritance go away.

You can have no overriding, and any method chain you can identify the
origin of is statically resolvable.

You can have no uniform access, and classes are declarative within a
separate static namespace.

You can't have all three and a rule that requires inheritance to be
statically resolvable.

You can't have static typing without such a rule.

Any method on "self" or a surrounding object could have been
overridden and is not a trustworthy origin point. Anything defined on
an object is a method. Anything defined on "self" or a surrounding
object is not a valid origin point for a chain of requests used for
inheritance.

Many method requests, none of which are "class"es, may be traversed
before the "class" is reached. Anything not in lexical scope involves
at least one such request.

The only origin points for which a chain of requests beginning with
them can definitely be statically resolved are literals and
definitions immediately inside method and block bodies.

All of this is true regardless of whether anybody overrides a "class".
Any rules you instate must apply to every occurrence of method
overriding. You must first distinguish classes from objects and
methods before any rule to ban overriding them can work in any case.

This has nothing to do with family polymorphism and nothing to do with
overriding types. It is a straightforward consequence of using method
requests to access everything.
-Michael