Comments on most recent draft: Chap 1 and 2

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

CHAPTER 1

page 8: 

We have discussed extensively why we should not force a restriction on the value
of class-name.  The following text would reflect the looser condition.

A class can have a name.  The function class-name takes a class object and
returns its name.  The name of an anonymous class is nil.  All the names used in
this specification are symbols, though we place no restriction of the type of a
name.  Two names are the same if they are eql.  The function symbol-class takes
a name and returns the class associated with that name, or nil if there is none.

p 1-20  There is a paragraph "Each class that corresponds to a predefined ..."
which is a good specification of how Common Lisp classes may be implemented.
Can we remove the paragraph "The Object System specifes that all predefined ..."
which confuses the issue.

At the bottom, it does not specify if make-instance can be used for objects
defined by defstruct.  We should say one way or the other.  

p 1-30
Rule 5 is incorrect as it stands.  It is described corrctly in the text later on
the page. This rule could be rephrased as:

"If &allow-other-keys is mentioned in the lambda-list of a method, then that
method is applicable, any keyword argument may be mentioned in the call to this
generic function." 

p1-48  Shouldn't it say in this section that we
are depending on an extension to Common Lisp to allow
(symbol-function '(setf foo))
to return the corresponding function object.

CHAPTER 2

p2-8
  The method signature should use method instead of standard-method.  Moon has
argued that standard-accessor-method should be disjoint from standard-method.  I
pointed out some differences in behavior that would require negative inheritance
if they are not disjoint.  But both need to be able to be added to generic
functions.

P 2-17 class-name
To correspond to the class-name change, remove the phrase "this result is a
symbol."

p2-19 
To go along with the change to class-name

"The function cmakunbound causes the given name to no longer refer to a class in
the given environment; that is, (symbol-class name env) will now return nil for
that name."

And replace "symbol" by "name" in Syntax and Remarks.

p2-28 Remarks spells out a number of cases for replacement and retention of
methods, but omits the case where there are methods on an existing generic
function, and there are method descriptions which do not overlap entirely.  This
paragraph might read:

"If a generic function with the same name already exists, all methods on that
generic function are retained, or replaced by a corresponding method specified
in a method description.  A method description corresponds to an existing method
if it has the same parameter specializers and the same qualifiers.  New methods
are added to the generic function for method descriptions which do not
correspond to any existing methods." 

p2-52
The description makes it clear that the default value of errorp is t.  Shouldn't
that be reflected in the method signature?

EXCEPTION CONDITION HANDLERS
  Generic functions for handling exception conditions are defined in order to
allow users to specialize their behavior.  They only signal an error.  Hence
they ought have a method signature with no specialization.  Moon made that point
in an earlier message.  Thus:

p 2-64 
no-applicable-method (generic-function t) &rest function-arguments

This allows a programming environment (or a delegation hacker) to define the
behavior for standard-generic-function without having to remove the system
defined method (which under certain circumstances may still want to be invoked
with call-next-method).

Similarly
p 2-71
slot-missing (class t) object slot-name operation &optional new-value
It needs to say below that "the default method signals an error"


and
p 2-72
slot-unbound (class t) instance slot-name
It needs to say below that "the default method signals an error"

p 2-74
symbol-class
  The occurences of symbol should be replaced by name.