Comments On Moon's Errata (Chapter 1 only)

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

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

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

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
what when you say "corresponding".  How about this wording?

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.

I look forward to your comments.