Moon's comments on RPG's comments on Moon's Errata for Chapter 2

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

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

[comments where I had nothing to add omitted for brevity]

    Moon writes:

    ``2-11 second Arguments paragraph: Delete the second sentence.  It lost
    its intended meaning as a result of previous editing.''

    I'm not sure of this. I would agree to an argument that the paragraph
    is hard to understand, but I think it stands on its own:

    ``When change-class is invoked on an instance, a copy [definition of the
    `copy'] of that instance is made; change-class then destructively alters
    the original instance [not the copy].  The first argument to
    class-changed, previous, is that copy [reference to the `copy'], and the
    second argument, current, is the altered original instance.''

    Is this wrong? If it's unclear we can re-do it somehow.

That's the first Arguments paragraph.  I have no problems with it.  I
was referring to the second Arguments paragraph, and suggesting removal
of "Any function, generic or not, can receive the value passed as
-previous- as an argument."

    Moon writes:

    ``2-11 first Remarks paragraph: Delete this.  It contradicts an
    example on page 2-8 and it isn't true.''

    While he is literally correct, I think we need to reinforce somewhere in
    this section that the functional interface must be used when classes are
    redefined.  This paragraph is the result of a hurry.

I think we could leave that to the discussion of class redefinition in
chapter 1.  I see it more as a property of the "obsolete" class than a
property of the class-changed generic function.

    Moon writes a specific comment that requires a general policy answer:

    ``2-34 second paragraph...[This paragraph duplicates information found
    elsewhere so perhaps it should be shortened.]''

    In general I repeated information that I thought would puzzle readers.
    Should we establish a convention of putting information on some topic
    mostly in one place?

Either way is okay with me.  I suggested shortening it because I thought that
would be easier than making the same corrections in more than one place.

    Moon writes:

    ``2-48 second Purpose paragraph: Delete "to the top level".''

    Or change it to 

    ``Whether ... or returns via THROW''

    I don't like the terminology ``or throws.''

That's better.  I changed my draft errata file to read:

2-41 second Purpose paragraph: Replace it with "Whether
{\bf invalid-method-error} returns to its caller or exits
via {\bf throw} is implementation dependent."

2-48 second Purpose paragraph: Replace it with "Whether
{\bf method-combination-error} returns to its caller or exits
via {\bf throw} is implementation dependent."

    Moon writes:

    ``2-46 second Purpose paragraph first sentence: It was not intended to
    guarantee that the returned value is a list with certain objects in its car
    and cdr.  Add the phrase "or a form with equivalent effect" at the end of
    the sentence.''

    Or maybe:

    ``The function {\bf make-method-call} returns a form whose effect is the
    same as a form whose first element is the operator specified by the {\bf
    :operator} keyword argument (the default is {\bf progn}) and the rest of
    which is a list of forms that call the methods in the given method
    list....''

Yes, that's better.  I put it into my draft errata file.

    Moon writes:

    ``2-53 last Arguments paragraph: Change "second" to "errorp".
    Change (twice) "If there is no such method" to
    "If {\it generic-function} does not know {\it method}".''

    How about one of these:

    ``If {\it generic-function} does not perceive directly {\it method}.''

    ``If {\it generic-function} does not perceive or apprehend as
    true {\it method}.''

    ``If {\it generic-function} does not have immediate experience of {\it
    method}.''

    ``If {\it generic-function} has not been apprised of {\it method}.''

    Abstract objects in a computer are not people, so we cannot use verbs
    that apply to people to talk about them. Leave it as it is.

    (I had to have fun somewhere in this message.)

I guess we can't fix this nicely without terminology that comes from the
meta-object chapter.  We should all have more fun.  Should we make an
end run around the problem and simply remove the errorp argument and say
that remove-method never signals an error?  Sort of like REMPROP, REMOVE,
and REMHASH.