comments on portions of the Oct 26 10:05 draft

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

In general the document is greatly improved and I'm fairly happy with it,
execpt for these last few points.

I've excluded comments on things that appeared to be already fixed in the
TEX source, since I was reading an unproofread draft.  Also I tried to
avoid duplications others' comments.

1-10: "A subclass inherits methods in the sense that any method applicable to
       an instance of a class is also applicable to instances of any subclass
       of that class (all other arguments to the method being the same)."
At the beginning of the second line, should "an instance" be "all instances"
so as to avoid any questions about methods-on-individuals?

1-17: "Note that instances of standard-type classes are disjoint with all other
       types."
This is wrong, type disjointness of standard-type classes is controlled
by CLtL, not by us.  The previous draft said "Note that instances of
standard classes are type disjoint with all other types" and I think the
switch from standard classes to standard-type classes was an editing
error.  In the "built-in-class" stuff I mailed out last night, I
included a suggested rewrite that more explicitly conveys the idea that
I think this paragraph was hinting at.

1-19 top of page: the explanation of looping precedence order is too complicated,
I don't think we really need double indices here.  Can't we just say
C1 through Cn, n>=2, where each precedes the next and also Cn precedes C1?
I think trying to call Cn C2 was what complicated the notation.

1-19 last paragraph before examples: I still think this should be generalized
to cover relatively separated subgraphs whose common element is not T, as
I said in earlier comments.

1-23 2nd para:
"When a new {\bf defgeneric} form is evaluated and a generic
function of the given name already exists, the existing generic function
object is modified.  This does not modify any of the methods associated
with the generic function."
except for modifications as a result of :method options in the defgeneric.

1-23 2nd bullet: "The lambda-list of the new method
must be congruent with the lambda-list of the generic function or else
an error is signaled." applies to both new and redefined methods, i.e. both
bullets, so this should not be inside the second bullet.  It looks like
it and the cross-referenced to congruence should be a separate paragraph
immediately after the bullets, preceding the paragraph about what happens
when no generic function by that name already exists.

1-24: "...parameter specializers
are used in the functional interface to method creation ({\bf
make-instance} of {\bf standard-method} and {\bf get-method})." would
be more legible if it said: "...parameter specializers
are used in the functional interface to method creation ({\bf get-method}
and {\bf make-instance} of {\bf standard-method})."

1-25 first paragraph: "By convention, qualifiers are usually
symbols, but it is possible to use a vector used as a qualifier."
delete "used"

1-25 second paragraph: "When a method combination type is
defined using the short form of {\bf define-method-combination},
primary methods are defined to include not only the methods qualified
with the name of the type of method combination, but certain others as
well."  Delete "not only" and "but certain others as well".  The only
primary methods are the qualified ones.  Add that auxiliary methods
for this case are :around methods.

1-41: the term "setf macro" is used without being defined.  Adding
", defined by defsetf or define-setf-method," should be sufficient to
give the reader the idea of what we mean by "setf macro."

We might want to be a little more explicit, rather than just relying
on the example in the last bullet, about the fact that the new-value
is received by the setf function as its first argument.  Also to avoid
any wondering, we could say that in a setf generic function this argument
is just as specializable as any other required argument.