Moon's Errata for Chapter 2

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

Moon writes:

``2-5 Values paragraph: Replace the whole sentence with
"The value is {\it generic-function}." to clarify that the value
is EQ to the argument.''

We should agree on and adopt a means of stating that some function
destructively alters an argument, returning the altered thing as its
value. I'm not sure this suggestion accomplishes that best, but maybe it
does.

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.

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.

Moon writes:

``2-18 first bullet (:type).  There is no discussion of the meaning and
enforcement of :type.  Add the following (stolen from CLtL p.310):...''

This overlaps with the discussion about chapter 1.  The language in chapter
1 has been variously vague on this also, but the version mailed to X3J13 
also copied terminology from CLtL.

We minimally changed the DEFINE-METHOD-COMBINATION description due to lack
of time. It needs a major rewrite in addition to the comments Moon has about
it.

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?

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

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

Moon writes:

``2-47 Values paragraph: same as the preceding.

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

My earlier comments apply here, too.

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

			-rpg-