# Instance''

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.



• Follow-Ups:
• References: