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

• To: Common-lisp-object-system@SAIL.STANFORD.EDU
• Subject: Moon's comments on RPG's comments on Moon's Errata for Chapter 2
• From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Date: Tue, 3 Mar 87 01:33 EST
• In-reply-to: The message of 28 Feb 87 04:18 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>

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

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}".''

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.