Inheritance of Slots

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

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

    Moon writes:

    ``No, :allocation doesn't inherit.''

    Moon wrote in CONCEPTS:

    ``{\bf :allocation} comes from the most specific slot description in
    the class precedence list---if it 
    does not explicitly specify {\bf :allocation}, the default is 
    {\bf :allocation} {\bf :instance}.''

    What is the ``most specific slot description''? Is it the one closest
    to the front? Is there some intrinsic specificity of a slot description?

I thought this was clear from context, in the three paragraphs before the
one you quoted.  Re-reading them, it would be clearer to some readers if it
said explicitly "The slot descriptions are ordered according to the order
of classes in the class precedence list." instead of only implying that.

    What is ``it''? Is ``it'' the most specific slot description? Is ``it''
    the class precedence list? Is this not some sort of inheritance?

"It" is the most specific slot description; slot descriptions are the only
things that specify {\bf :allocation}.  This would be better written as two
sentences with no pronouns.

Dick, the problem here is that in the piece of mail you quoted I used the
word "inherit" in a different sense from the way it's used in the document.
I think the 31 Jan version of the document is consistent in its use of
inherit, and has it that :allocation does inherit.  When I said :allocation
does not inherit, I meant that only the most specific slot description for
a given slot affects :allocation.  When the document says that :allocation
does inherit, it means that the most specific slot description controls
:allocation, even if that slot description is attached to a superclass of
the class whose slots are being discussed.  So I don't think we are disagreeing
about anything here.

    Moon wrote in CONCEPTS:

    ``{\bf :initform} comes from the most specific slot description 
    that explicitly specifies {\bf :initform}. ''
 
    So what does this do:

    (defclass c1 () ((s :allocation :class :initform 99)))
    (defclass c2 (c1)((s :initform 22)))

    Is S an :instance in instances of C2 ?

Of course.  :allocation comes from the most specific slot description.

    Is it a :class in C2?

No, since it's :instance.

    Is it shared with the one in C1?

Of course not.

    Do we reinitialize S?

I don't know what this means.  My guess is you're referring to the weird
thing that would happen if we had different inheritance rules for :allocation,
so that C2's class definition referred to a :class slot of C1.

A weirdo case you were perhaps thinking of is

    (defclass c1 () ((s :allocation :class :initform 99)))
    (defclass c2 (c1)((s)))

Here the instance slot named S in a C2 is initialized to 99.
I propose that this not a problem.

    ``{\bf :type} is constrained to satisfy all of the type constraints given
    by classes in the class precedence list.''

    What does ``constrained'' mean? Is there enforcement? Is it the same way that
    slots in Defstructs have :type declarations? If so, this doesn't say it.
    Steele's working is much better.

I don't know what it means.  We just put it in the document based on what
was said in the mail.  Here is all the mail I was able to find on the
subject.

Date: 17 Nov 86 14:33 PST
Sender: Bobrow.pa@Xerox.COM

  :type type-expression
should be allowed as it is in DEFSTRUCT.  No requirements on its use
should be in the standard.

Date: Fri, 21 Nov 86 23:08 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

I don't see what use this could be, but I don't see how it could hurt,
other than by making the language larger.  Let's go ahead and put it in.

Date: 22 Nov 86  1048 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

Sometimes a compiler will be able to optimize things a little given some
information like this.  It might not be that the storage or its direct
handling will improve or change, but, perhaps, some other operation can be
slightly improved - such a being able to emit the machine addition
instruction with only overflow checking - when the slot, directly, is 
involved in an arithmetic expression.

Date: 5 Jan 87 11:07 PST
Sender: Bobrow.pa@Xerox.COM

:type is inherited, but we do not specify what the system does with it.
An open question is whether inheritance here should be a union
operation, or if the more specific type must always be a subtype of the
inherited one.

If "Steele's wording" refers to p.310 of CLtL, that's probably saying the
same thing, although it's a little vague too.  The analogy to type declaration
of a variable is valuable and should be used in our document.

    Well, maybe Moon's right, we should leave it as it is so that the readers of
    the document can have fun guessing what this mess means. LGD and I sure had
    fun for a day doing exactly this. All we were doing with our suggestions was
    to propose something that someone could understand along with a description
    of it that was understandable.

    The point of a specification is to spell out the details in such a way
    that they are precise, unambiguous, and clearly stated. This specification
    does not do that.

I will say only that I am glad that the process of review is resulting in
an improved document.