# Comments On Moon's Errata (Chapter 1 only)

• To: Common-lisp-object-system@SAIL.STANFORD.EDU
• Subject: Comments On Moon's Errata (Chapter 1 only)
• From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Date: Wed, 25 Feb 87 17:57 EST
• In-reply-to: The message of 19 Feb 87 17:22 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Date: 19 Feb 87  1422 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

Sorry about the slow response to these, I've been tied up with other things
the past few days.

Moon writes:
1-11 fourth paragraph: Delete the entire paragraph, it isn't true....

I think the original statement is true, and it is because of that fact
that Moon's re-statement would be true.  Possibly both statements should
be made, suitably phrased:

Because redefining a class does not change its name, the class $C\sub o$
does not have a name.  Thus, writing a method for {\bf class-changed} that
is specialized to a particular $C\sub o$ must be done through the
functional interface, using {\bf add-method} rather than using {\bf
defmethod}.  See the section Introduction to Methods.''

I think this might make the situation clearer to the reader.

I agree that this is better, except for one thing.  The reason that C-sub-o does
not have a name is -not- because redefining a class does not change its name.  For
example, in an earlier proposal from Xerox C-sub-o was given the name
(intern (concatenate 'string "obsolete-" (symbol-name (class-name class)))),
or something similar.  This had a problem if the class was redefined twice,
but that could easily be fixed.

I put the following into my errata file, is this okay with everybody?

1-11 fourth paragraph: Delete the entire paragraph, it isn't true.  Replace
it with this paragraph:
Because the class C-sub-O does not have a name, writing a method for
class-changed that is specialized to a particular C-sub-O
must be done through the functional interface, using add-method rather
than using defmethod.  See the section Introduction to Methods.''

Moon writes:

1-18 first paragraph under "Introduction to setf Generic Functions":
Change "(setf (generic-function-name arguments) new-value)"
to "(setf (function-name arguments) new-value)" because the base
function does not have to be generic, in fact it does not even have to
be defined.''

If this is correct, then it should be:  (setf (symbol arguments)
new-value)''

Good point, I made that change in my file.

Moon writes:

1-18 last paragraph: The term "parameter specifier" is used in a way that
is inconsistent with its use by CLtL and there are a couple of typographical
problems.  Replace the entire paragraph with:
Each method has a {\bit specialized lambda-list}, which determines
when that method can be selected.  A specialized lambda-list is like
an ordinary lambda-list except that a {\bit specialized parameter} may occur
instead of the name of a parameter.  A specialized parameter is a list,
{\tt ({\it variable-name parameter-specializer-name\/})}.  Every
parameter specializer name is a Common Lisp type specifier, but the only
Common Lisp type specifiers that are valid as parameter specializer names
are the following:''

The comment about bad use of parameter specifier'' is correct; I only
wish he had brought it up sooner.

I would have brought it up sooner if I had seen this edition of the
document sooner.  The previous edition used "parameter specifier" in a way
that was consistent with CLtL.

I think the re-wording is not as good as
the original, though. We need to connect the linguistic item {\it
parameter-specializer-name} (typeset in italics) with an English phrase that
between parameter specializer names and Common Lisp type specifiers, and the
implicitness of that information in Moon's re-wording (and in earlier versions)
rendered the whole section incomprehensible.

I didn't think the phrase "where {\it parameter-specializer-name\/} is a
parameter specializer name" added anything to understandability.  If you
strongly disagree we can put it back, but to me it seems unnecessary.
Aside from that, the only changes I made to the paragraph were to change
"parameter specifier" to "specialized parameter", removing a typo
("specializers" for "specializer"), and removing the portions of the
last two sentences that were redundant with the table at the top of
1-19.  The explanation that quote and member are the same also appears
in the eighth paragraph on 1-19.

Here is a possible re-wording:

Each method has a {\bit specialized lambda-list}, which determines when
that method can be selected.  A specialized lambda-list is like an
ordinary lambda-list except that a {\bit specialized parameter} may occur
instead of the name of a parameter.  A specialized parameter is a list,
{\tt ({\it variable-name parameter-specializer-name\/})}, where {\it
parameter-specializer-name\/} is a parameter specializer name.  Every
parameter specializer name is a Common Lisp type specifier, but the only
Common Lisp type specifiers that are parameter specializers names are type
specifier symbols with corresponding classes and type specifier lists of
the form {\tt ({\bf quote} {\it object})}. The form {\tt ({\bf quote} {\it
object})} is equivalent to the type specifier {\tt ({\bf member} {\it
object\/})}.

This undoes the changes I made, other than "parameter specifier" to
"specialized parameter".  I really think that this would make it harder to
understand.  Think about it again, and if you still disagree we can keep
discussing it, or strike this correction from the errata and do it later.

Moon writes:

1-19 fourth paragraph, beginning "Only required parameters can be specialized":
The term "parameter specifier" is misused again.  Replace the paragraph with:
Only required parameters can be specialized, and each required parameter
must have an associated parameter specializer.  For notational simplicity,
ordinary lambda-list syntax can be used, that is, a parameter name can be
used instead of a specialized parameter.  In this case the parameter
specializer defaults to the class named {\bf t}, the class of all objects.''

Again, the substantive point is well-taken, but the re-wording is bad.
The style has become flabby and imprecise. If you need to say that is,''
then you said the wrong thing in the first place. The paragraph is talking
about the required parameters, and the comment linking the syntax of them to
lambda-list syntax doesn't restrict the lambda-list syntax of interest to
the lambda-list syntax of required parameters. It is usually good to link
new concepts with old ones, but this wording simply confuses the issue.

Only required parameters can be specialized, and each required parameter
must be a specialized parameter.  For notational simplicity, if some
required parameter in a specialized lambda-list is simply a variable
name, the corresponding parameter specifier is taken to be {\tt
({\it variable-name} {\bf t})}.

This is better than what I suggested, but self-contradictory.  First it
says that each required parameter must be a specializer parameter, which
was earlier defined as a list, then it says that a required parameter
can be a symbol.  Also I have trouble figuring what is corresponding to

Only required parameters can be specialized, and there must be a
parameter specializer for each required parameter.  For notational
simplicity, if some required parameter in a specialized lambda-list is
simply a variable name, its parameter specializer defaults to the class
named {\bf t}.

Moon writes:

1-19, seventh, eighth, and tenth paragraphs, discussing the relationship of
parameter specializers to type specifiers: Change "parameter specializer"
to "parameter specializer name" throughout these paragraphs, to be
consistent with the terminology used in earlier paragraphs.''

Nope. Moon missed the point, which, I guess, needs to be clarified even
more. The second paragraph on page 19 defines parameter specializers (PS)
in terms of parameter specializer names (PSN). The PSN's correspond to
names of classes while the PS's are the classes. Satisfaction'' operates
on the classes.  This is so that the functional interface (ADD-METHOD et
al) can take PS's and DEFMETHOD can take PSN's. Otherwise we cannot
explain the change-class protocol.

I did not miss this point.  Indeed, I thought that clarifying this distinction
substantially improved the document.  Since I was only making an errata sheet
and since I didn't think you needed me to stroke your ego I left out
comments on the things that I thought were improved, and only commented
on the things that I thought were not good enough yet.

Read the offending paragraphs again.  Paragraph 7 says
This proposal requires that parameter specializers also be Common Lisp
type specifiers.
and paragraph 8 says typep accepts parameter specializers.  If this means that
typep is to be extended to accept class objects, that is a reasonable extension
to propose, however since it is mentioned nowhere else in the document and is
not stated explicitly here, and was never discussed on the mailing list,
I assumed that that was not the intention, and instead the problem was
that the conversion from "parameter specializer" to "parameter
specializer name" had not been carried out uniformly.  So which is it?
If typep is to accept class objects, we need an errata entry that makes
that very explicit.

Later in paragraph 8 it says
Note that in general a
parameter specializer cannot be a type specifier list, such as {\tt
({\bf vector single-float})}.
which is true, but would make more sense to say of parameter specializer
names since that's what users write.

Paragraph 10 says
A method all of whose parameter specializers are {\bf t}...
but a parameter specializer cannot be t, only a parameter specializer name
can be t.  This was the point that convinced me that all of these occurrences
of "parameter specializer" were typos for "parameter specializer name".

I'll think about the Chapter 2 comments later.