``Instance''

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

I thought about this for a while.  I have to say that because I don't
always know if it shows in the body of the letter!

    Date: Tue, 31 Oct 89 13:58:36 PST
    From: Richard P. Gabriel <rpg@lucid.com>

    In addition to the ``mistake'' Moon found, the following sentences
    will need to be examined to see whether they still mean what we
    thought they meant:

    ``The class named {\bf standard-object} is an instance of the class {\bf
    standard-class} and is a superclass of every class that is an instance
    of {\bf standard-class} except itself.''

    ``Any class that corresponds to a standard Common Lisp type specified in
    {\it Common Lisp: The Language\/} might be an instance of {\bf
    built-in-class}.''

    ``A class that is an instance of {\bf standard-class} can be redefined
    if the new class will also be an instance of {\bf standard-class}.''

    ``\item{\bull} The \OS\ may be extended to support an updating process
    when either the old or the new class is an instance of a class other
    than {\bf standard-class} that is not a built-in class.''

It might be interesting to see what Gregor, as the metaobject expert,
says, but I would tend to believe that these sentences were always
intended to mean what they say.  Specifically, they don't guarantee the
behavior of instances of subclasses of standard-class.  Metaclasses that
are subclasses of standard-class can do whatever they want.  Didn't we
decide that most user-defined metaclasses would be defined as subclasses
of standard-class, rather than starting fresh from class?  That makes it
more important that subclasses of standard-class have the flexibility
to deviate from the contract of standard-class.

I really did look at every occurrence of "instance" in 88-002R before I
sent my earlier mail.  It took a while.

    Moon says that that the CLOS specification ``always carefully uses the
    word "instance" in the way I [Moon] just described.''  [Note: he
    described ``X is an instance of Y'' as the same as
    (eq (class-of X) (find-class Y)).]

    This implies that the first of these sentences means:

    ``The class named {\bf standard-object} is an instance of the class
    {\bf standard-class} and is a superclass of every class that is an
    instance of {\bf standard-class} except itself. The class {\bf
    standard-object} is not an instance of a subclass of {\bf
    standard-class}, and it is unspecified whether an instance of a
    subclass of {\bf standard-class} is a subclass of {\bf
    standard-object}.''

    Though this doesn't violate the informal prohibition we have against
    subtractive inheritance (since nowhere does it state that such
    behavior as is derived from being a subclass of standard-class is
    method or structure supported), it seems pointless to imply that this
    aspect of gross behavior might not be inherited.

I don't see why user-defined metaclasses shouldn't be able to replace
standard-object with something else.  In fact that seems highly probable
to me (not that I have any significant experience with metaclasses to go
by).

    I think we will need to go over the meta-object stuff (chapter 3 of
    CLOS) to determine whether places where it currently says (or we think
    it says) ``instance'' is meant ``instance of a class or its
    subclasses.''

Sure, although I'm not sure that document is in anywhere good enough
shape yet to be worth the trouble (unless there's a newer version that
I haven't seen).  Fortunately it's not part of the ANSI Common Lisp
specification so we don't have to worry too much about what exactly
it says.

    Note that the Smalltalk-80 book seems to define ``instance'' the way
    Moon does, but is not very clear about it, nor do they have a word
    that corresponds to ``member''. 

    I think ``member'' is a very bad word to use for the concept of an
    object whose structure (slots) and behavior (methods) correspond to
    the specification provided by a class. 

As far as I can see, ``instance'' is the word I am proposing for that.
A member of a class C that is an instance of a subclass of C does not
have its structure and behavior controlled by the parent class C.
The subclass might shadow every slot of C with a shared slot and
might shadow every method applicable to C.

					   Common Lisp types correspond
    more closely to sets, but CLOS classes have much more structure,
    which, to me, implies a different word. 

I'm really using "member" in connection with types, but since "class"
is a subtype of "type", it applies to classes as well.

    The definition of ``class'' is as follows:

    ``A {\bit class\/} object determines the structure and behavior of a set
    of other objects, which are called its {\bit instances}.''

    [Note that this definition is wrong because it includes the word
    ``other'' which overly restricts the definition.]

Agreed.  standard-class is (in all known implementations) an instance of
itself.

    The only set referred to in this definition is the set of instances of
    the class; the class itself is not a set, and therefore it is
    nonsensical to say that an object is a ``member'' of a non-set.

Well, I disagree.  This part of the definition of class doesn't say that
a class is a type, but someplace else says that.  So a class is a type
and a type is a set.  CLtL page 11 says a type is a set.  You can say
that the class "names" or "designates" the set of type members, rather
than "is" that set, but that doesn't interfere with the sense of "member
of a class" as far as I can see.  If we didn't want to blur the notion
of class with the notion of type, why did we modify TYPEP to accept
class objects as the second argument?

    Moon's proposed rewording (``A structure-object is an instance whose
    class is a member of structure-class.'') should be as follows if we
    want to use the word ``member'' somehow:

    ``A structure-object is an instance whose class is a member of the set
    of instances of structure-class and its subclasses.''

I disagree, as above.

    Besides, if we say ``the object O is a member of the class C,'' some
    might believe that (member O C) is a reasonable way to validate the
    statement (thinking a class is a sequence).

This is a valid point, but not, I think, an argument for using a different
word from member.  After all, (instance O C) doesn't work either.  What
this really shows is that Common Lisp is not Oaklisp (which I imagine
doesn't surprise any of us!).  If Common Lisp was fully object-oriented
and generic, we wouldn't need TYPEP as a function separate from MEMBER,
we would just define MEMBER to accept types as another kind of sequence.
Oh well, save that for the next language.

    Since we need to come up with a word to mean ``instance of a class or
    its subclasses,'' and since that word should be more commonly used
    than the word meaning ``instances of a class but not of its
    subclasses,'' why not use ``instance'' for the first and ``direct
    instance'' for the second?

We could have chosen that terminology, but since we didn't, I think it
would be dangerous to change now.  A lot of text would change its meaning
as a result (such as the metaobject stuff you quoted at the beginning
of this message) and in the process of changing it back we might mess it up.
Also I'm not sure that the "class and its subclasses" word would be used
more often than the "direct" word; in my survey of 88-002R chapter 1,
the "direct" case seemed to come up a lot more often.  I don't know how
representative that is of the ANSI CL specification as a whole.

Of course, meanwhile my CLOS implementor escaped my scrutiny and defined
CLOS-INTERNALS:INSTANCE-OF-CLASS to be what ought to be called
CLOS-INTERNALS:MEMBER-OF-CLASS.  Terminological purity is a never ending
battle.  I guess I'll send this message and then go chase after him.