[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on chapter 2
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Comments on chapter 2
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 2 Nov 87 17:18 EST
Page numbers are from the Oct 26 10:17 draft, but I've omitted comments
on things that are already fixed in the source in the latest version on SAIL.
2-10: Cross-reference to ``Changing Classes'', which has been renamed.
Example hasn't been updated yet to realize that rho is the radius and
theta is the angle.
2-11: First remarks paragraph: this could just speak of classes whose
metaclass is standard-class, without worrying about whether or not the
:metaclass option was specified, similar to the way some similar text
was fixed up in chapter 1 recently. Not edited for standard-type-class
removal yet. The phrase "After completing all other actions, {\bf
change-class} invokes the generic function {\bf class-changed}." is
somewhat unclear as to what "all other actions" are, maybe some text got
lost here. This should be improved when the business of who evaluates
the :initforms is straightened out.
2-12: Cross reference to ``Redefining Classes'' should be to
``Changing the Class of an Instance''.
2-14: Cross reference to ``Changing Classes'' should be to
``Changing the Class of an Instance''.
2-39: missing quote mark in (documentation (setf symbol) 'function).
I forget if this one was already commented upon.
2-54: under make-instance, we have
"The {\bf :function} argument is the method function.
The length of the list of specializers must be equal to
the number of required arguments of the method function, or
else an error is signaled."
Since Common Lisp doesn't require implementations to be able to
determine the number of required arguments of a function, given the
function, I don't see how this requirement to signal an error
can be implemented. We might have to make this the same less stringent
error checking that CLtL prescribes for calling a function with the
wrong number of arguments.
Also as mentioned before this section will need to discuss more about
the relations between the method lambda-list and the method function
lambda-list.
2-55: The first Purpose ("Purposes"?) sentence for make-instances-obsolete
is misleading. Not every defclass redefinition calls this, it's only
guaranteed to be called under the circumstances described on 1-13.
Also there is a conflict between the value of make-instances-obsolete
being eq to the class argument, and the class argument being allowed
to be a name of a symbol; just needs the wording cleaned up a little.
Also I'm not sure what the remark
"The generic function {\bf make-instances-obsolete} is invoked only on
classes that are instances of {\bf standard-class}."
means; does this mean the user is not allowed to invoke it on other
classes, or is this more of the statement under Purpose of when defclass
invokes this?
2-70: I think we ought to mention that the typical implementation will
compile slot-value inline, or somehow efficiently, in methods. Users need
to have some rough idea of what sort of efficiency to expect, and reading
the document the way it is right now would tend to lead the naive reader
to think that CLOS slots are much less efficient to access than defstruct
slots, whereas the intention has clearly been that there be only a minor
efficiency cost for using CLOS slots, at least in the majority of
implementations. We don't have to give the details (except maybe in the
meta-object chapter), but we ought to mention the possibility of optimization.
2-72: In the first remarks paragraph for symbol-macrolet, "expansion"
is probably supposed to be in italics. At least, I think what is intended
here is to say that the scope does not include the -expansion- forms
that are substituted for the -symbols-. At first I thought "expansion"
referred to the result of expanding the invocation of symbol-macrolet.
2-73: First sentence for update-instance-structure is missing "be".
Also this hasn't been updated yet to reflect the division of labor between
caller and primary method that has been adopted in chapter 1.
2-77: The remarks for with-added-methods still speak of modifying an existing
generic function. This needs to be rephrased in terms of defaulting the
values of these options, for the newly-created generic function, from their
values in the existing generic function.
2-79: "The macro {\bf with-slots} can be used inside a method or inside
any function." implies it can't be used at top level, but that's not what
we mean to say.