Comments on comments on Chapter 1

[Pavel.pa@Xerox.COM]

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.

Moon says:
	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
data structure.

Moon says:
	1-11 last sentence: needs to be updated with a correction I sent
earlier,
	because :default-initargs can appear more than once in a defclass.

Perhaps I'm just missing something, but what's the use of multiple
:default-initargs options?

Moon says:
	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
of
	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
EQL.

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?

Moon says:
	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.

Sonya says:
	1-17, Figure 1-1

	The column header "Superclasses" doesn't make it clear that the order
of
	these classes is from most to least specific.    In my draft of this
the
	column header was "Class Precedence List", which did make this clear.

I would also prefer "Class Precedence List" to "Superclasses" here.

Sonya says:
	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
	functions.

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
been made?

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
it
	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
else,
   so they don't need to tack "-method-combination" onto the end of
their
   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
clear.

	Pavel