# 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: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
• Date: 19 Feb 87 1422 PST

Moon writes:

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

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

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.

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

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

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\/})}.

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

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.