Comments On Moon's Errata (Chapter 1 only)

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

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

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
can be explained. The original had more information about the relationship
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.
Try this instead:

    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.

I'll think about the Chapter 2 comments later.

			-rpg-