Comments on Chapter 1

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

As with other commenters, I am impressed with the general high level of
quality of the chapter.  I have tried to leave out those comments
already made by Moon, Sonya and Pavel, and others of my comments that I
have sent out.

1-3 Para 4.  The terminology of "a generic function can be specialized
by the definition of methods" may be confusing -- since it is not
necesarily the case that what is added is more special -- specialized in
the sense that classes are specialized.  Methods can be completely
independent of ones added before.  How about "a generic function can be
extended by the addition of methods".  Also in that paragraph and below,
the terminology of "class-specific operations" ignores individuals.
Perhaps better would be "parameter-specialized operations" 
  
p 1-6  It might mention after the third paragraph that "A class can be
given a name by using
(setf (symbol-class <symbol>) class), but that this does not guarantee
that the class-name of class is <symbol>.  A class may also have more
than one name, at most one of which is its proper name.

In the paragraph about a class precedence list being consistent with its
local precedence order, it is worth making it explicit that subclasses
always precede their supers (although that is implicit in your
definition of local precedence list)

p 1-7 para 2 you say "CLOS provides a default metaclass that is
appropriate for most programs."  Please add  "The default metaclass is
called standard-class." so that later we can refer to it.  

p 1-8  "Slots can be accessed in two ways: by use of METHODS defined by
the defclass form,  added to the appropriate generic function, and by
use of the primitive function slot-value."

A sentence here about why one defines these accessors may be in order.
"These accessors provide a more abstract interface for external users of
instances of a class.  It allows implementors to later change the
definition of a class, removing the slot, but providing a method that
implements the functionality formerly captured structurally."

I support the removal of the sentence with the phrase "individual slots"

p1-9 Sometimes it is convenient to access slots from within the body of
a method or function ** simply by using the name of the slots as if they
were variables. **

p1-11 :reader :accessor paragraph.  To make things more explicit, add
"If a slot specifier contains a reader or accessor option, the specified
methods are created only in the class in which the slot specifier
explicitly appears."

"A consequence of the type rule ..." Add at the end "It is an error to
assign a value to a slot that does not satisfy the type constraint."  

p 1-13  There is a mention of :constructor here.  We agreed to postpone
decision on constructors. I would like to see all mention of
constructors disappear from this version of the spec until agreement is
reached.  
Paragraph "Note that redefining ..." The last sentence would be better
as the third sentence of that paragraph.

Last paragraph should have sentence "If there is a shared slot in the
old class definition that has the same name as a local slot in the new
class definition, the local slot in every updated instance is eql to the
value that was in the shared slot. 

p1-14 "The Object System guarantees that ..."  references to being
defined by defclass should be replaced by being instances of
standard-class.  We have talked about mechanisms that undercut this
defclass condition, so the level of indirection is better.  This is a
specification, and it is the metaclass that will count for this
guarantee.

p1-15 Changing the class of an instance
  "to conform to the definiton of the SPECIFIED class."

Paragraph 2 ought to be after paragraph 3, and have a sentence added,
"This initialization is done by the default method on the
generic-function class-changed.

Para 5 should be deleted.  The interesting sentence that might be added
is the one I wrote above (p1-13) for shared slot to local slot updating.

p 1-16
  I have sent out a comment on this, and hope we can get rid of the
standard-type-class notion in favor of "built-in-class" as a metaclass
and "Common Lisp data type class" as a descriptive term.

I think we should put in the spec something about package stream etc,
saying that we expect them to be forced to be distinct types, and
include them as Common Lisp data type classes.

p1-18
Why is (c,c) for classes in SC added to R.  This means there is never a
situation in which there is no pair in the ordering that has some
specific c as its right hand element.  I am missing something I am sure.

p 1-21 in with-added-methods, we had better specify here that these are
copies of methods in the lexically visible generic function, or we may
get unwanted side effects.

p1-22 para 2  It should say  that an error is signalled if there a
defgeneric is evaluated, and the name is bound to a non generic
function.

"the lambda list of the generic function is CONSTRUCTED to be congruent
with the lambda-list of the new method.

p1-23  Can both (EQL form) and (EQL object) be Common Lisp type
specifiers.  The first is what is the name, the second is what is
described below.  On the next page it says both parameter specializers
and parameter specializer names must be CL type specifiers.

p1-25 Point 4 "in in" --> "in"

p 1-28  Mention next-method-exists-p here (I like Pavel's suggested name
change)

p 1-33  Question about standard-type-class again.  We need a different
statemetn about structure-class (I could easily imagine a CL that made
it a subclass of standard-class)

p1-35  Top line.  It is not true for all metaobject programming that the
arguments are classes e.g. methods on generic-fucntion and methods.  So
it should be clear here that you mean metaprogramming with respect to
initialization.

p1-38  "(This is true even if a :before method ..."  This should say "if
any code has stored a slot value before the default method is run.  e.g
:around, more specialized primaries using call-next-method as well as
:before.

p1-39  Is unitinitialized state better than unbound.  The latter agrees
with the function names.

There is the error condition missing from the make-instance symbol case
in case the symbol is not a class-name.  At least a comment ought to be
made.