Inheritance of Slots and Slot Options

[Dick Gabriel <RPG@SAIL.STANFORD.EDU>]

Moon's rewrite has some features of interest. Recall  I don't claim that
what ended up in the draft is the last word, but it was meant to be
clear (at least) though not written as best it could be. I have a few minor
questions and comments about it:

Moon writes:

``We say that a slot is accessible in an instance of a class if the slot
is defined by the class of the instance or is inherited from a
superclass of that class.  A detailed explanation of the inheritance of
slots is given in the section ``Inheritance of Slots and Slot Options.'' ''

He removed the sentence:

``At most, one slot of a given name can be accessible in an instance.''

Although he inserts it later, I think it doesn't hurt to leave it where
it is (as well).

Moon writes:

``- The type of a slot is (and T1 T2 T3...), where T1, T2, T3, and so on
    are the :type slot options contained in all of the slot specifiers.  If
    no slot specifier contains :type, the type is t.''

Here I think the language is unclear. Does this mean that the :type option
for the most specific class is taken to be (and ...)? Is the slot
constrained to hold values that satisfy (and ...) in the sense that an
error is signaled if someone tries to store something there that does not
satisfy the type? The language we had originally stated that the :type
option defaulted to T, and the contents of the slot would always be of
type (and ...). This mimicked the language in CLtL for defstruct and
represents a statement more in line with types as optional information to
the compiler.

Later Moon writes:

``A consequence of the type rule is that the value of a slot must satisfy
the type constraint in -every- slot specifier that contributes to that
slot.''

The convention in CLtL is that the phrase ``x must do y'' means that
otherwise it is an error, so we can deduce that he means that the slot is
not constrained in the sense of signaling an error. We should probably
include at the beginning of these chapters a warning to read page 6 of
CLtL to understand the conventions of the language we use.

Moon writes in the next paragraph:

``An argument to a method can be an instance of a subclass of the class
declared by a parameter specializer, so the compiler cannot know the exact
class.''

This should be expanded because many will not easily see the connection
between random methods and optimizing based on the types of slots.

The strong type constraint rule Moon proposes has some effects that might
be difficult for a reader to understand unless explained properly. Suppose
we have:

(defclass c1 () ((foo :type t1)))
(defclass c2 (c1) ((foo :type t2)))
(defclass c3 (c1) ((foo :type t3)))

The FOO slot in C1 must be of type (and T1 T2) when regarded from the
point of view of C2, and it must be of the type (and T1 T3) when regarded
from the point of view of C3. Therefore, it actually must be of type 
(and T1 T2 T3). The compiler compiling methods on C2 or C3 alone won't care
much, and when it compiles a method on C2 and C3 it might discover the happy
fact. A reader of this specification might be confused into thinking that
there is some intractable problem at hand and that the type of a slot cannot
actually be deduced because it depends on classes very far away.

Moon writes near the end:

``The :reader and :accessor slot options were not mentioned above because
they create methods rather than defining characteristics of a slot.
Reader and accessor methods are inherited in the sense described in the
section ``Inheritance of Methods.'' ''

This needs to be made clear at the outset: two-pass reading is bad
news.

			-rpg-