My comments on Chapter 1

[Pavel.pa@Xerox.COM]

Here are those of my comments that haven't already been covered by Moon
and Sonya.  Some of these are typos and some are more substantial, but I
haven't got the energy at this point to go through and separate them
out.

	Pavel

Page 1-4, second paragraph, last sentence -- A typo: "the syntax of
Object System" should be "the syntax of the Object System".

Page 1-4, second set of bullets, second bullet -- Can't valid programs
rely on that error being signalled if they also specify (SAFETY 3)?  I'm
generally unhappy with the phrase "at least in code compiled under one
compiler safety optimization level".  I'd prefer a direct statement that
that level is 3.

Page 1-5, third bullet -- What does the clause "but they must remain
undefined" mean?  Does that mean that my implementation is incorrect if
I document just which nasty bug will crop up if situation S occurs?  I
can't derive any useful content from this clause.

Page 1-6, third and fourth paragraphs -- On my copy, produced by TeXing
the source with the AMFONT file in use, the not-equal symbol comes out
funny; in particular, it does not use the proper slash to cross out the
equals sign.  I traced to problem to the AMFONT file.  In the last six
or so lines of this, several uses of CM fonts were not changed into
their AM equivalents.  Thus, our ancient Dovers used the old, OLD CM
fonts, which have a different layout of characters.

Page 1-6, eighth paragraph -- Should "class named t" be "class with the
proper name t"?  I have a lot of reservations and questions about the
class-naming solution presented here, but I think I'll send them out
separately.

Page 1-7, first bullet -- Should this be "A proper name for the new
class"?

Page 1-7, sixth bullet -- I agree with Sonya (I think) that this should
say "methods for certain generic functions" rather than use the term
"appropriately named".

Page 1-8, third paragraph, first line -- "a slot which is visible"
should be "a slot that is visible"

Page 1-11, second bullet, last sentence -- "contains :type slot option"
should be "contains the :type slot option

Page 1-11, last paragraph in the section that ends here -- I found this
to be a very surprising statement until I remembered that everything
having to do with slots is defined ultimately in terms of SLOT-VALUE.
Some of my surprise could have been avoided by a mention of SLOT-VALUE
as the reason for this mildly unintuitive notion.

Page 1-13, second paragraph, fifth line -- Is there any reason this
mentions the EQ function instead of the more usual EQL function?

Page 1-13, second paragraph, last line -- a hyphen is missing in
"implementation dependent".  Such a hyphen is not required except to be
consistent with other uses of "implementation-dependent", as in earlier
lines of the same paragraph.

Page 1-13, third paragraph -- Is there any way for a user to know if a
particular redefinition of a class will change "the order of slots in
storage"?  I found this criterion very much out of place.  Is it there
for a reason?  If so, isn't it possible that there are other
implementation-dependent reasons that a class redefinition would
necessitate updating instances?

Page 1-15 -- I would like to add my voice to Moon's and Sonya's for
changing the name of this section to "Changing the Class of an
Instance".

Page 1-15, fifth paragraph -- I certainly hope that Moon is right and
that this paragraph should simply be deleted.

Page 1-16, second paragraph -- The phrase "the proper name" ignores the
possibility that, by the definition given on page 1-6, a given class can
have many proper names.  Also in this paragraph, the phrase "some class
C named S" appears.  I'm not sure what's meant here.  Is this saying
that S = (CLASS-NAME C)?  If so, it should say so more clearly.  I think
that I must be missing something that supposed to have been said back on
page 1-6...

Page 1-17, table -- The contents of the table, not the headings, should
be in a fixed-pitch font.

Page 1-17, first line -- This says "Note that instances of standard
classes are type disjoint with all other types."  I can't make any sense
of this.

Page 1-17 -- What is the cleanup status of the other types that we
wanted to give classes to, such as STREAM, PATHNAME, etc.?

Page 1-19, first paragraph --  The implicit "proof" here concerning the
uniqueness of a rightmost direct subclass might want ot be spelled out a
bit more.  Also, in the last line, it isn't clear to me how there can be
no such candidate classes.  Does someone have an example?

Page 1-19, second paragraph -- Is there a reason to use the unusual
forms "2 <= m" and "1 <= n" instead of the more common "m >= 2" and "n
>= 1"?

Page 1-19, the example -- A good example, but it would be better with
some sort of picture.  Perhaps one can be pasted in or even done with
(gack!) character graphics.  If the document we done in LaTeX, I'd
recommend using its "picture" environment, but it isn't...

Page 1-23, second paragraph in the new section -- In the last sentence,
the phrase "the new definition" should probably be replaced by "the
method-function object".

Page 1-23, third paragraph in the new section, second sentence -- For
clarity the word "required" should be added before the last word in the
sentence.

Page 1-23, second-to-last paragraph -- I think that the clause "if N is
a class name, then P is the class with that name" should be "if N is a
symbol and (CBOUNDP N) is true, then P is (SYMBOL-CLASS N)".

Page 1-23, last sentence -- Since GET-METHOD does not create a method,
the phrase "functional interface to method creation" should perhaps be
""functional interface to method manipulation".

Page 1-24, fourth paragraph -- I think this would be clearer written as
"This proposal specifies that all parameter specializers and parameter
specializer names are Common Lisp type specifiers."

Page 1-24, eighth paragraph -- The reason why qualifiers can't be lists
(ambiguity in the syntax of DEFMETHOD) should be mentioned.  Otherwise,
this just sticks out as a weird glitch.

Page 1-25 -- I'm now confused about what the generic function's
lambda-list is used for.  It appears to affect only the checking for
congruency.  Is that really all it's for?  If so, this seems a bit odd.

Page 1-27, third bullet -- This would be clearer, I think, as "For each
method, which other method, if any, is called when CALL-NEXT-METHOD is
invoked".

Page 1-28, fourth complete paragraph, last line -- If the method called
by invoking CALL-NEXT-METHOD is to be called the "next method" in
general, without regard to the method-combination type, then this line
should be in a different paragraph, one that doesn't so strongly tie
itself to standard method-combination.

Page 1-29, first and second bullets -- The words "primary method" at the
end of each of these should perhaps be "primary method(s)" instead,
since there can be more than one primary method.

Page 1-29, first and third ticks of the sixth bullet --
"most-specific-first" and "most-specific-last" really need the hyphens.

Page 1-29 -- I really don't like the name NEXT-METHOD-P.  It sounds like
I pass it a method object and it tells me whether or not that method is
"next".  Perhaps NEXT-METHOD-EXISTS-P?

Page 1-33, second bullet -- The "it is not allowed" phrase mentioned by
others pops up here as well and should be changed.

Page 1-33, third section -- The term "meta-objects" has not been defined
anywhere.

Page 1-35, third complete paragraph -- "initform" is not a word, so this
should perhaps be ":initform option".

Page 1-36, second complete paragraph -- Since an initialization argument
can be declared as valid by a method on initialize-instance, it is a bit
weird to speak of "the class that declared the initialization argument
as valid".

Page 1-38, table -- It would be nice if this were formatted as nicely as
the table on page 1-17.

Page 1-38, first sentence -- There should be a general line somewhere
stating that all generic functions defined by the proposal (unless
explicitly mentioned otherwise? Are there any exceptions?) use standard
method combination.