More comments on the draft document

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Additional comments resulting from comparing the document to my
clos-decisions file and the 87-002 amendments handout:

We need to note somewhere that SYMBOL-FUNCTION, FBOUNDP, and
FMAKUNBOUND take an optional environment argument, just like
ENSURE-GENERIC-FUNCTION, SYMBOL-CLASS, CBOUNDP, and CMAKUNBOUND.
This is necessary to be able to find a generic function object,
given its name, in the compile environment.  FMAKUNBOUND may
be just for consistency, but FBOUNDP and SYMBOL-FUNCTION are to
allow ENSURE-GENERIC-FUNCTION to work.

Add to Remarks fields: The body of (DEFMETHOD -name- ...) is surrounded
by an implicit block named -name-, if that is a symbol, or -name1-, if
-name- is (SETF -name1-), by analogy with DEFUN.  The same applies to
methods defined by the :METHOD option to DEFGENERIC, GENERIC-FLET,
GENERIC-LABELS, and WITH-ADDED-METHODS.  There is no implicit block around
the body of a method defined by the :METHOD option to GENERIC-FUNCTION.

What can be done with method objects, e.g. can one method be added
to more than one generic function?

  Gregor: I believe it should signal an error to attempt to put a method on more
  than one generic function.  My model of this is that if you want to do
  something like that, you can take one function, use it as the method function
  of multiple methods, each of which would be on a different generic function.

  September: Agreed.

  I don't see anything about this in the document.  Should the discussion under
  make-instance of how to make a method require a :generic-function initarg?
  Or should there be a remark under add-method saying it can signal an error
  if the method is already claimed?

Which symbols defined by the standard go in what package?  I think we need to
say explicitly that we have postponed a decision on this.

2-20 second paragraph: delete "from their superclasses and so on", or
else change "superclasses" to "direct superclases".  As written it doesn't
make sense, since a superclass of a superclass of C is always a superclass
of C, and might encourage confusion about the difference between a superclass
and a direct superclass.

2-65 Same comment that the value is always eq to the first argument as on 2-6
and 2-10.