Remarks about Comments on Latest Draft Documents

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

The name of a class is restricted to be a symbol in chapter 1, and that
text has been there for a long time.  That restriction appears in the
paragraph about proper names.  As you recall, that paragraph was discussed
at great length in person and by netmail during rounds of review of the
chapters earlier this fall.  Apparently no one thought to criticize the
restriction at that point.

The restriction and the implementation of the restriction are two
different topics. 

I believe the restriction is fine, and I am also perturbed that
sections of the specification that have been reviewed extensively
are often subject to later changes. At some point we need to
decide that something is final so that the entire document can be
made consistent. Linda was simply trying to make the descriptions in
chapter 2 coincide with statements in chapter 1.

At this point I believe that compelling arguments must be made for even
small changes. There is no tradition of using non-symbols for names in
Lisp. Non-symbols are used as keys for various purposes, but not as names.
Defstruct restricts names to symbols.  Therefore, I can see no compelling
reason to break the tradition and allow non-symbols to be the names of
classes.

I do not find silly the use of parameter specializers to do typechecking.
I find it hard to imagine what sort of argument one could make to show
that point of view. That issue is different from the one about whether we
ought to use parameter specializers in the document for that purpose.  On
this point I suppose it is better to simply state the restrictions in
English in the remarks. Therefore, I suggest that chapter 2 reflect
chapter 1 on this point in the remarks. saying that the parameter
specializer for the new value is T.

On the topic of the DOCUMENTATION generic function, my opinion is that the
remarks ought to state in English the restriction that the new value in a
SETF of DOCUMENTATION must be a string or it must be NIL to signify that
the association between any existing documentation and the object in
question must be eliminated.  This restriction is stronger than any that
can be conservatively deduced from CLtL, though it is not stronger can be
reasonably deduced.

The following reasoning was stated against this restriction:

	   CLtL doesn't say anywhere what values are allowed, but a
	   reasonable inference is that NIL is allowed, and "documentation
	   information" might have been meant to include some sort of
	   structures as well. 

CLtL states four times that strings are the things that are associated
with symbols as documentation. It never states that anything else can be
associated with symbols as documentation.  CLtL does state that the
function DOCUMENTATION will return NIL if no documentation exists.  The
statement ``SETF may be used with DOCUMENTATION to update documentation
information'' in the context of the documentation section and the section
on SETF does not imply anything about the types of new values, but it
similarly does not imply anything about the nature of the update except
that whatever happens, DOCUMENTATION returns a string or NIL. So if a
structure is given as the new value in a SETF expression, DOCUMENTATION
will return a string or NIL - one cannot be sure that if it returns a
string that the string is related to the structure.

It is reasonable to conclude that NIL can be given to SETF of DOCUMENTATION,
but the reasonable conclusion about the effect of this is to remove any
association between an existing documentation string and the symbol.

I therefore favor introducing the restriction.

			-rpg-