``Instance''

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

  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?

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

Again, if users want to replace STANDARD-OBJECT, I think they should
make subclasses of CLASS. This presumes that a good CLOS
implementation has a metaclass structure that allows them to inherit
the pieces of behavior that go into the parts of STANDARD-CLASS they
like.

  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.

To do this in such as way as to violate the nature of the class is a
perversity. That is, the reason for subclasses is to extend the
applicability of the contract (I don't like this word, but alas) that
the class provides, and to extend the generic functions in such a way
that its abstract behavior can be applied to more objects. We defined
CLOS in such a way that users can violate this principle, but why
should we encourage such activities?

For example, suppose some user defined an operation named PLUS for a
class named PSEUDO-NUMBER and which for instances of NUMBER acted like
+. If that user made a subclass of PSEUDO-NUMBER that had things that
were a sort of number but PLUS was defined as -, we would think that
the user did not understand the contract of PSEUDO-NUMBER and PLUS.

I think the main import of the definition of ``instance'' is on
sentences related to metaclasses, since my survey of the use of
``instance'' in the specification reveals that in the majority or all
of non-metaclass-related sentences, the meaning is made clear by the
use of phrases like ``and its subclasses.'' Here I think we want to
encourage the use of additive inheritance by saying that various
statements are true of all instances of a metaclass and its subclasses
(using your definition). When someone is making a subclass of a
subclass of a metaclass, we want them to be able to rely on the
behavior described in the specification for the metaclass, which means
we need to encourage writers of those intermediate subclasses to not
randomly implement a subtractive structure or behavior change. Since
we cannot define additive and subtractive inheritance as applied to
semantics, we need to encourage good behavior as best we can - by
using terminology and phrasing.

My point is that I don't think we should define terminology and our
strategy for presentation so that undesired and perverse corner cases
are optimized or, worse yet, used as the driving force for our the
terminology.

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

I couldn't figure out what this means. I hope it isn't important to
your argument.

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

We need to make sure this doesn't slip through the cracks.

  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.

  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.

			-rpg-