re: Aaron Larson's comments

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

[This was a private reply from Dick, but it seemed appropriate
to send my comments back to the whole (small) list.  If we can't
reach a concensus on terminology I don't see how we are ever
going to finish this standard.]

    Date: 30 Oct 89  2158 PST
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    [In reply to message sent Tue, 31 Oct 89 00:20 EST.]

    In general, I agree that we need to be careful with terminology,
    but I happen to disagree with some of Moon's suggestions.

    ``Thus I would clean up the wording to:  "A structure-object is an
    instance whose class is a member of structure-class" which is an
    abbreviation of "A structure-object is an instance whose class is an
    instance of structure-class or of a subclass of structure-class."

    I suggest:

    ``A structure-object is an instance whose class is an instance of
    structure-class.''

    If it isn't clear that being an instance of a class could mean being
    an instance of a subclass, we should clarify.

I don't think that is correct.

The terminology that I was under the impression we have been using all along
is that "X is an instance of class Y" means (eq (class-of x) (find-class y))
and "X is a member of class Y" means (typep x (find-class y)).  I haven't
looked systematically, but I believe the body of the ANSI CL document is
consistent with this.  88-002R doesn't use the word "member" (except in one
reference to the MEMBER type-specifier and informally in connection with
method-groups), but it always carefully uses the word "instance" in the way
I have just described, with one exception: In the description of the
Method Signature notation at the beginning of chapter 2, it says:

  \noindent This signature indicates that this method on the generic function
  {\bf F} has two required parameters, {\it x\/}, which must be an
  instance of the class {\it class}, and {\it y}, which can be any
  object.

Here the word "instance" should be "member" or else the text should refer to
class and its subclasses.  I think this notation was added at the last
minute when we were all tired and we made a mistake.

The instance/member terminology is also consistent with CLtL (except for a
couple of places such as simple-vector on p.47, which uses "element" where
it should say "member", that have been acknowledged as inconsistencies).

However, the glossary is not consistent with this.  There is no entry for
"member", and the entry for "instance" is inconsistent with the terminology
I thought we were using, is ungrammatical, and uses the word "element" in
yet another new way (derived from "element of a set", but inconsistent with
other uses of "element" in the specification; anyway "member of a set" is
as good as "element of a set" so let's use it).  Actually, in spite of the
number of reviews it has been through the glossary is still pretty terrible.

Am I right in thinking that people from other language communities would
laugh at us for still not having worked out our terminology some seven
years into the language definition effort?  Certainly terminology has not
visibly been a priority for most members of X3J13, or most members of the
Lisp community for that matter.  Some 31 years into the history of the
language most people still don't seem to be sure what a "form" is.

    On the issue of element, component, slot, I agree we need to straighten
    this out. My view is that ``element'' should refer to storage indexable in
    constant time by using integers (meaning arrays). ``Component'' should
    refer to parts and constituents, just as in the English definition.
    ``Slot'' should refer to a component of storage indexed by name in
    constant time (meaning class slots and structure slots). The constant time
    aspect is probably not necessary, but I used to term to get across to you
    what I mean.

I don't like the constant time aspect for two reasons.  One is that it assumes
things about the implementation that may not be true; consider a fictive Japanese
implementation that stores strings (vectors of characters) in a compressed form
that saves space but is slow to access (see ISO WG 16 document N49).  The second
reason is that we need a name for the elements of a list, and I think element is
the appropriate word in spite of the lack of constant time access.  In particular
I think there should be one word for the elements of all types of sequence.

I'd also like to avoid bringing in the concept of storage here if at all
possible.  For example, a pathname has a host component even if no storage
is allocated for that component because the implementation only supports one
host.

I agree with you that elements are things indexable by integers, slots are
things indexable by name, and components are parts and constituents, generally
not indexable.  To that I will add that members are members of sets (including
types viewed as sets and classes viewed as types and hence as sets), and
instances are "direct instances" of classes.

    The incorrectness of the definition of ``slot'' in the glossary is
    twofold, in my opinion.  First, there needs to be separate definitions for
    class and structure slots.  Second, the existing definition needs to talk
    about storage and indexing by name.

    Note that ``component'' does not refer to contiguous storage, or to storage
    necessarily. 

    But, that's just what I think.

			    -rpg-