Proposed revision of "Inheritance of Slots and Slot Options" section

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

The description of "Inheritance of Slots and Slot Options" is too
complex and too long.  So far we have not been able to come up with a
description of this that is both precise and understandable.  Because I
don't believe there is anything inherently complicated in the idea, I'm
making another attempt to write a description.  To keep the terminology
consistent, I find I also have to change the section "Slots" on page
1-5.  For readability I have removed all formatting controls; once we
have agreed on the wording the formatting controls can be restored.


\beginsubSection{Slots}

[first two paragraphs unchanged]

We say that a slot is defined by a class if the defclass form for that
class contains a slot specifier with the given slot's name.
[Metaclasses extend this idea, because they allow classes that aren't
defined by defclass, but I don't think we need to go into that here.
We could separate the ideas of "slot specifier" (source language syntax
found in defclass forms) and "slot description" (object found in data
structure, computed from a slot specifier), but that didn't seem to
add to understandability when I tried it, so I prefer not to introduce
slot descriptions until the meta-object chapter.]

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


\beginsubSection{Inheritance of Slots and Slot Options}

The set of the names of all slots accessible in an instance of a class,
C, is the union of the sets of names of slots defined by C and its
superclasses.  At most one slot of a given name can be accessible in an
instance.

In the simplest case, only one class in the class precedence list of C
defines a slot with a given slot name.  If the class that defines the
slot is not C, we say that the slot is inherited.  The characteristics
of the slot are determined by that class's slot specifier.  If the
:allocation slot option is omitted or specifies a local slot, then each
instance of C stores its own value for the slot.  If :allocation
specifies a shared slot, the class that defined the slot stores the
value and all instances of C access that single slot.

In general, more than one class in the class precedence list can define
a slot with a given name.  In such cases, at most one slot with a given
name is accessible in an instance of C, and the characteristics of that
slot are a combination of the several slot specifiers, computed as
follows.

- All the slot specifiers for a given slot name are ordered
  from most specific to least specific, according to the order of
  the classes that define them in the class precedence list.

- The allocation of a slot is controlled by the most specific slot
  specifier.  If the most specific slot specifier does not contain
  an :allocation slot option, :instance is used.  Less specific slot
  specifiers never affect the allocation.

- The initform of a slot is controlled by the most specific slot
  specifier that contains an :initform slot option.  If no slot specifier
  contains an :initform, the slot has no default initial value form.

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

A consequence of the allocation rule is that shared slots can be
shadowed.  If a class C-sub-1 defines a shared slot named S, normally
that single slot is accessible in instances of C-sub-1 and all of its
subclasses.  However, if C-sub-2 is a subclass of C-sub-1 and also
defines a slot named S, C-sub-1's slot is not shared by instances of
C-sub-2 and its subclasses.  See S2 in the section ``Examples of
Inheritance.''

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.  This maximally restrictive rule allows a compiler to optimize on
the basis of the :type slot option.  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.

Methods that access slots know only the name of the slot and the type of
the slot's value.  Suppose a superclass provides a method that expects
to access a shared slot of a given name and a subclass defines a local
slot with the same name.  If the method provided by the superclass is
used on an instance of the subclass, the method accesses the local slot.

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


[I also tried writing the above in notational form, in the spirit of
Dick's notation used in 87-002.  However, with the new simplified
description the notation doesn't appear to add any understandability, so
I won't bother mailing it out.  It's available on request.]