opaque type proposal

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

    Date: Wed, 1 Jun 88 19:40:22 PDT
    From: Pavel.pa@Xerox.COM

    Of course, I forgot to mention my most important issue about this
    proposal:  inheritance.  I don't see any worm cans surrounding a
    single-inheritance facility.  It's simple (all other possibilities
    have this as a special case, all with the same semantics), useful
    (especially for the definition of an error system) and easily
    extendable to some hairy multiple-inheritance setup if that's found
    desirable in the future.

I see that nobody takes anything I say on faith.  OK, here are two problems:

- Single inheritance makes type checking and predication of inheritable-from
record types slow.  It is no longer possible to simply compare a slot in
the record against a descriptor representing "the" expected type of the
record, since there is no longer a single possible expected type, but
rather a set of them.

I would favor addressing this by providing a way of optionally
specifying that a record type cannot be subtyped; this could be realized
as a boolean argument to MAKE-RECORD-TYPE.  This vaguely corresponds to
the construct in the Larch specification language where one declares
that a sort (?) is "generated by" a given set of constructors.  E.g. the
natural numbers are generated by zero and successor; there ain't any
others.

- It's no longer clear what constructor procedures should do.  If the
constructor for the subtype takes initial values for all the fields,
including those of the supertype, then you have a serious modularity
violation -- changes to the implementation of the supertype require
changes to the implementation of every subtype.  I don't know how to fix
this, although I imagine there exists some solution involving passing
control between constructors, perhaps using continuations.  It would be
nice if records could be constructed without either copying an instance
of the parent type (as would happen if the new fields were adjoined --
assuming records are stored linearly in memory, and slots are mutable,
both of which seem important) or side-affecting slots (as would happen
if the larger record were created first, and the slots filled in
separately by procedures handling each layer).

We could probably argue of months about these issues, but I wanted to
avoid that for now.