Inheritance of Slots and Slot Options

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 27 Feb 87  2258 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    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).

I put it back, in the revised errata I am about to mail out.

    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.

The errata sheet already contains a description of what the :type slot
option means, based on earlier discussion over the mail.  What may be
confusing is that it's buried in the description of defclass in chapter 2.
I don't see a really good place to put it in chapter 1.

    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. 

Again, this is explained in chapter 2.  In the revised errata sheet I am
about to mail out, I changed the wording of the offending sentence to be
clearer.

							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.

I agree, it wouldn't hurt to say that we are using the same terminology
as CLtL in the next version of this document.

    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.

Instead, I removed the whole discussion.  It seems either a whole page of
design rationale is needed here, or it's better simply to state how it is
without trying to explain why.

    The strong type constraint rule Moon proposes 

Please note that I never proposed this, I only tried to make the explanation
understandable.  If I had my druthers, there would be no :type slot option.

						  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.

Your last sentence here was what really convinced me that it was better not to
try to explain the design rationale here.  I removed all mention of compilers.

    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.

I agree; I moved this up to a more appropriate place.