[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comments on portions of the Oct 26 10:05 draft

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