[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proof of CLOS Document
Linda & Dick:
Compliments on the fine job you've both done! I had no trouble TeXing
the document, once I found out that LaTeX didn't work and I had to
use straight TeX.
I only had an opportunity to go through the document this weekend, so
these comments may not be in time for the November meeting, but I
wanted to post them anyway. For the most part, they are simple typos
or regularization of wording. I did not have time to read the
discussion last week (sorry) so there may be some duplicates here.
Overall: meta-object v.s. metaobject v.s. meta-class v.s. metaclass
Might it not be a good idea to stick to one meta notation
rather than using meta-object and metaclass?
pg. 1-7: Last sentence. Shouldn't this be pharased in terms of the
pg. 1-9: Second last line. "The macro WITH-SLOTS invokes the function
SLOT-VALUE is to access slots."
pg. 1-11: Last line. "earliest in the class precedence list" Since the
class precedence list hasn't yet been introduced, perhaps "most
specific class" would be more approprate.
pg. 1-16: 4th Paragraph, 4th line. "Each standard type class has the
class STANDARD-TYPE as a metaclass"
Implies there may be more than one. Perhaps "as its" would be better.
pg. 1-16: 4th Paragraph. Last sentence. Again, use of the error
terminology would probably be appropriate.
pg. 1-16: 6th Paragraph. Again, this looks like a forward reference
to the CPL.
pg. 1-17: Last Paragraph. It is not clear from this what should happen
if (TYPE-OF <obj>) returns a type speciifer which is a list. Should an
error be signalled or should the CAR of the list be used? On pg. 42 of
CLtL, the description of type specifiers which are lists suggests
that the CAR should work.
pg. 1-25: List item 4. Last sentence. "in in the generic function"
Overall: When referring to SETF functions, the list specifying a
SETF function name is often not quoted. Example: (fboundp (setf <name>)).
If the argument had been a function symbol name, however, it would have
been quoted, since FBOUNDP is a function and therefore the arguments
are evaluated. Shouldn't this be so for SETF function names as well,
or is the assumption that (SETF <name>) is a macro which returns the
actual name of the function (e.g. expands into something like '<actual name>)?
Perhaps using the italic <setf-function-specification> would be more
Overall: The criterion mentioned in the first chapter for whether a
generic function is part of the metaobject protocol (at least, the
impression I obtained after reading Ch. 1) was that the generic function
operated on class objects. There are, however, several functions
in Chapter 2 which have class arguments in their interface. Leaving
aside the obvious exceptions such as CLASS-NAME which are used heavily
during interactive development, reasons for others are not so obvious.
Should either the wording in Chapter 1 be tightened up to exclude the
exceptions, or should some of the functions in Chapter 2 which discriminate
on class objects be moved to Chapter 3?
pg. 2-7: Is CALL-NEXT-METHOD a function? From the as yet incomplete
e-mail discussion, it would seem to be either a macro (if Moon's
implementation is accepted) or a special form.
pg. 2-7: 2nd Paragraph under ARGUMENTS. "the same set of applicable methods"
I think what you mean here is the effective method, since, the intent is
to avoid having to recalculate the effective method.
pg. 2-21: 2nd Paragraph. Shouldn't this be phrased in terms of the error
pg. 2-26: :DECLARE description. Why prohibit INLINE and NOTINLINE? One
optimization a compiler writer might want is to have the generic function
code inserted in line. Or is the assumption that this should be controlled
in the lexical context enclosing the generic function invocation, rather
than in the definition of the generic function's interface?
pg. 2-27: Top of page. If the class name given to the :METHOD-CLASS
and :GENERIC-FUNCTION-CLASS does not specify a class whose protocol
conforms to that required for a method or a generic function, is an error
signalled? Or are these options caveat empor?
pg. 2-30: Top of page. I'm curious if the form generated is expected to
be executable. That is, if <operator> can be a keyword symbol, then the
implicit assumption is that the function cell of keywords can be
bound. I know this is possible in Symbolics CL and not in ours, also
I don't think CLtL says anything either way. Is there a Cleanup proposal
pg. 2-32: Top of page. "semantic meaning". Redundant. Should be either
"semantics" or "meaning".
pg. 2-40: 2nd bullet item, last line. Do you mean list? (SETF <name>)
is something more than a general list, I think. Perhaps function
pg. 2-57: Last line. I believe this line is out of date, because
the extension to CALL-NEXT-METHOD was adopted (i.e. allowing arguments).
pg. 2-61: VALUES. Don't you mean T or NIL? There are no true and
false types in CL.
pg. 2-61: REMARKS. Wording on the first sentence is a little rough.
"...within the method within which it is referenced." might be better
phrased as "...within the method where it is referenced."
pg. 2-73: REMARKS. Last sentence. Wording is a little rough.
"...convert variable uses into calls to generic function" might be better
phrased as "...convert variable uses into calls to generic functions".
pg. 2-74: First sentence. "The generic function UPDATE-INSTANCE-STRUCTURE
is not intended to called by..."
Suggest adding a "be".
Overall: There are a couple of function descriptions with the wording:
The results are undefined if the values returned by the
function are modified.
It is permitted, but not required, for an implementation
to return values that share with internal data structures.
In the context of what the results of invoking the function being
described are, the first sentence makes no sense, because, once the
function has returned a value, further "results" are not forthcoming:
the function has completed its task. I believe what is meant here
is that the results of further operations using the Object System
may or may not be impacted by modifying returned values, depending
on whether the implementation does or does not choose to return
a shared data structure.
pg. 3-6: 2nd Paragraph. Last Sentence. "class" is misspelled as
pg. 3-12: SYNTAX. Shouldn't the argument list be an &REST parameter,
since its size will vary depending on the number of required arguments
the generic function accepts?
pg. 3-12: I'm confused by where the effective method is calculated.
Is it this function, or is there another?
pg. 3-13: PURPOSE. The implication of the first sentence is that
<initarg list> is modified, while the last sentence specifically forbids
that. Why not simply say in the first sentence that the initialization
arguments are appended to a copy of <initarg list>?
pg. 3-14: This is pretty vague.
pg. 3-15: 1st Paragraph. "instead" misspelled as "instand".