``Instance''

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

    Date: Wed, 1 Nov 89 10:18:59 PST
    From: Richard P. Gabriel <rpg@lucid.com>

      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.

    The only problem is that I (and Dussud) think they were intended to
    mean what they say when ``instance'' means what I think it means. So,
    the statements are correct, now the only problem is the definitions of
    the words that constitute the sentence (I presume we don't need to
    settle on the meaning of the syntax).

Well, I really don't think there can be any serious argument that in 88-002R
"X is an instance of class C" means "X is a direct instance of class C or a
direct instance of a subclass of C" unless each section of 88-002R is assumed
to be using a different terminology.  Thus I don't think anyone can seriously
argue that 88-002R claims to define the behavior of instances whose metaclass
is a subclass of standard-class.

On the other hand, it's certainly reasonable for you to argue that what
88-002R says is wrong and ought to be changed.  You can argue on various
grounds that the behavior of instances whose metaclass is a subclass of
standard-class ought to be specified to be some particular behavior.  I
think that has to be brought up as a proposed change, part of your
comments as a result of reviewing the current draft.  I doubt that I
would vote against such a change, although I would want to think about
it a bit.  I would certainly oppose putting in such a change through the
backdoor of redefining after the fact what the document that everybody
voted for said.  Even if in practice no one but you and me cares which
way it is, or even knows that there is a difference, it's still better
not to change it behind their back.

Another part of your comments, and mine as well, has to be that the
draft is insufficiently clear about what exactly it means by "instance."
I've started leaning towards using Lisp code rather than English to
explain these things (simple code using just typep, subtypep, class-of,
eq, and find-class).  Do you think it would be reasonable for the draft
to use Lisp instead of (or more likely in addition to) English where
precision is necessary?  Even if we don't use Lisp, we certainly have
to fix the current situation where different parts of the draft are
written with different terminology, and the glossary, which if it's
worth anything at all ought to explain the terminology used to describe
the language, is incomplete and inconsistent with the body of the draft.

If I ever do this (language standardization) again (no way!), I'll
do the terminology first instead of last.

      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.

    The decision was justified, I thought, because we felt most people
    would want to merely add to the contract, not to change it by
    subtraction. People who want to change it should make subclasses of
    CLASS - isn't that why CLASS exists?

Well, this is all very murky, especially when we don't know who these
people are and what they are trying to accomplish by using metaclasses.
We've been around this merrygoround before.  I don't even know whether
replacing standard-object with proprietary-object in the CPL should be
counted as addition or as subtraction.  I doubt that there is any
definite answer to that.

 From this I conclude that we shouldn't let the design of ANSI Common
Lisp be held up waiting for an answer to these meta-issues.  I would be
comfortable either with saying that ANSI Common Lisp only talks about
classes that are direct instances of standard-class, structure-class,
and built-in-class, and doesn't specify anything about any other
classes, which is the conservative approach of specifying only what's
needed for this basic language; or with saying that ANSI Common Lisp
talks about all classes that are members of standard-class,
structure-class, and built-in-class, and to go outside ANSI CL you have
to start from just CLASS, which is the approach of specifying more, so
user programs have a stronger guarantee of the behavior of the objects
that they might see.  Either of these is okay, except that if we have to
talk about it for a long time I would prefer to not talk about it and
just go with the first one, which is what 88-002R says (regardless of
whether any of the authors of 88-002R, myself included, wanted it to say
that).

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

    There is no such someplace. The text in question reads:

      ``\beginSection{Integrating Types and Classes} 

      The \CLOS\ maps the space of classes into the Common Lisp type space.
      Every class that has a proper name has a corresponding type with the same 
      name.  

      ...

      Many but not all of the predefined Common Lisp type specifiers have a
      corresponding class with the same proper name as the type.''

    We did want integrate the notions of class and type, but we couldn't
    do it because they are different beasts. The use of the word
    ``corresponding'' is carefully chosen to help convey that a class is
    an object whose instances (using the transitive closure meaning) form
    a type whose type name is the proper name of the class. Since the use
    of names as types in TYPEP would seem to disallow using classes as
    arguments to TYPEP when there was a clear meaning trivially derived
    from the correspondence between properly named classes and types, we
    extended TYPEP.

    If we want to use a word like ``member'' to contrast with
    ``instance'', I think do a disservice to precision to not chose
    phrasing that recognizes that there is a correspondence and not an
    identification. If a class were a chimerical thing (like a type name)
    I would agree with you, but it really is an object that is tied in an
    important way to a set, but not through identification.

Alright.  Evidently I shouldn't have deleted the part of my original message,
which I thought was just a digression, that explained "member of class C"
as an abbreviation for "member of type that corresponds to class C."

      We could have chosen that terminology, but since we didn't, I think it
      would be dangerous to change now.

    Well, I think we have a problem, because Dussud and I think that using
    your definition of ``instance'' alters the meaning of CLOS from what
    we thought it was. This will require some action anyway, but I think
    the only places we need to concentrate our effort is on the metaclass
    material.

I agree, based on my survey of the use of "instance" in 88-002R, that
this mainly affects only the metaclass material.  I have to say again
that what matters is what the document actually says, not what you or I
thought it says or what you would have made it say if you had been able
to spend more time making it precise.  If what it actually says is not
what we want, then we should change it, but we should present that as a
change (or as a clarification if we honestly believe that what it
actually says is ambiguous).

It's actually a bit odd to be spending so much time on this particular
point, when this is actually one of the most precise and least ambiguous
areas of the ANSI CL draft.  If we devoted equal attention to the rest
of the document, I think I can estimate that we would need to expend
between 300,000 and 1,000,000 lines of mail to deal with the whole
thing.  It's scary.