[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on comments on Chapter 1
I agree strongly with Moon that the concept of "setf generic function"
is now essentially bankrupt and that we shouldn't give it any real
emphasis in the proposal.
1-3 sixth paragraph: "ordered set" should be "list" in two places,
to avoid implying that duplicates are eliminated from the "set" of
parameter specializers or the "set" of qualifiers.
1-23 first paragraph under Introduction to Methods: same comment.
I would rather that the word used here was "sequence" instead of "list",
just because "sequence" is a bit less evocative of a particular Lisp
1-11 last sentence: needs to be updated with a correction I sent
because :default-initargs can appear more than once in a defclass.
Perhaps I'm just missing something, but what's the use of multiple
1-16 fourth paragraph last sentence: "It is not allowed" is not defined
in the error terminology section. I think you mean "CLOS may be
extended to cover make-instance of a standard-type class or inclusion
a standard type class as a superclass of a class."
I like this wording much better. The other wording, aside from being
undefined, implied to me that such extensions were not acceptable.
Simon says (oops, I mean Moon says):
1-23 last bullet: "(EQL -object-)" should be "(EQL -form-)", because
in a parameter specializer name, we have a form that is to be evaluated
to produce the object that appears in the parameter specializer. The
paragraph immediately following is wrong where it says "otherwise N
equals P" for this reason. We changed this when we changed QUOTE to
So, to test my understanding, "(EQL -form-)" is a parameter specializer
name and "(EQL -object-)" is the resulting parameter specializer, where
-object- is the result of evaluating -form-. Is this right?
1-17 I still think it's wrong for list to be more specific than symbol
in the CPL of null. Consider the print-object methods. Also consider
the introjection of symbol between list and sequence, a surprising CPL.
I agree with this. I was surprised when I saw that LIST was more
specific than SYMBOL.
1-17, Figure 1-1
The column header "Superclasses" doesn't make it clear that the order
these classes is from most to least specific. In my draft of this
column header was "Class Precedence List", which did make this clear.
I would also prefer "Class Precedence List" to "Superclasses" here.
1-21, 3rd paragraph
"Ordinary functions and generic functions are called with identical
syntax." I can't remember for sure, but I believe we decided that
generic functions must have at least one required argument. If so,
this is one (minor) syntactic difference between ordinary and generic
If this has, indeed, been decided, the document should say so somewhere.
Does it? I could imagine uses for generic functions without arguments.
For example, the only distinction could be in the qualifiers, which
could, perhaps, be integers implementing some sort of method priority
scheme. Was there a real reason for this decision, if indeed it has
Sonya and Moon say:
1-30, Standard Method Combination
I think the standard method combination should have a name, such as
"standard-method-combination". That name should be able to be given
to the :method-combination option to defgeneric, etc. It should be
noted as one of the Built-in Method Combination types. Just because
is the default doesn't mean that it shouldn't have a name.
I strongly agree. The name should be just "standard" I think, rather
than the longer name, since the other m-c types have short names.
Method combination types aren't in the same namespace as anything
so they don't need to tack "-method-combination" onto the end of
name to distinguish them.
Rather than add one more symbol in the LISP package that has no
intrinsic meaning (e.g., no value), I would like to see this named
:STANDARD. The only reason the various other built-in m-c types aren't
named with keywords is to make their association with the Lisp operators