Firs set of comments on TAOTMOP part 2

[Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>]

Comments on Volume 2 of "The Art of the Metaobject Protocol..."

3-7 first paragraph of Classes section:       
       A class metaobject determines the structure and
Add    default
       behavior of its instances.
Reason: Methods can also be EQL specialized.

3-8: second paragraph       
       directly
Rem    in
Add    by
       the class
Reason: Sounds better to me.

3-8: third paragraph
       Certain kinds of information
Rem    is
Add    are
Reason: Grammar.

3-8: 4th par.
       available as
Rem    forms
Add    objects

3-8: second bullet       
       as a function of no arguments
Add    ,
Reason: Grammar

3-8: fifth bullet
       those generic functions
Rem    for which there are
Add    with
Reason:  Simpler

3-8: first bullet for generic functions section
       the name is available as a function name.
What if the generic function is unnamed?

3-9: 4th bullet in Methods
       ... method-function-applier
I can't find a definition for this, so I can't say whether or not I can
go along with this.

3-10:  I think that there should be a class STANDARD-DEFMETHOD-METHOD
with direct superclasses STANDARD-METHOD.  STANDARD-DEFMETHOD-METHOD is
what DEFMETHOD would normally expand into.  One reason is that accessor
methods have no need of a METHOD-FUNCTION, but ones defined by defmethod
do.

3-11: 3rd par
       described in the section "Special Metaclasses".
The referred to section needs something in it before these classes can
be evaluated.

3-11: 4th par
       the class
Rem    es
       standard-object is
Reason: Grammar.

3-12: end of 2nd bullet
       and in fact call-next-method is
Add    always
       invoked 
Reason:  Conditionals.  Perhaps something should be said
about extensions which signal an error when things are inconsistent
being permitted.  This whole area of extensions is getting way out
beyond what I think we have a good grasp on.

3-13:  We need some concept of extensions to method combinations.  If
method combination MC allows methods qualified on qualifiers from the
set Q, then MC+, with accepted qualifiers Q+ is an extension of MC iff Q
is a subset of Q+ and MC+ behaves identically to MC when methods are
qualified with qualifiers only from Q, and adding methods qualified from
elements of Q+ not in Q will not change the order in which those methods
qualified from Q will execute.  For example, the following would be an
extension to STANDARD:

   (DEFINE-METHOD-COMBINATION STANDARD-ERROR-CHECKING ()
	 ((AROUND (:AROUND))
	  (BEFORE (:BEFORE))
	  (PRIMARY () :REQUIRED T)
	  (ERROR-CHECK (ERROR-CHECK)
		       :ORDER :MOST-SPECIFIC-LAST)
	  (AFTER (:AFTER)
		 :ORDER :MOST-SPECIFIC-LAST))
     (FLET ((CALL-METHODS (METHODS)
	      (MAPCAR #'(LAMBDA (METHOD)
			  `(CALL-METHOD ,METHOD))
		      METHODS)))
       (LET ((FORM (IF (OR BEFORE AFTER ERROR-CHECK (REST PRIMARY))
		      `(MULTIPLE-VALUE-PROG1
			 (PROGN ,@(CALL-METHODS BEFORE)
				(CALL-METHOD ,(FIRST PRIMARY)
					     ,(REST PRIMARY)))
			 ,@(CALL-METHODS ERROR-CHECK)
			 ,@(CALL-METHODS AFTER))
		      `(CALL-METHOD ,(FIRST PRIMARY) ()))))
	 (IF AROUND
	     `(CALL-METHOD ,(FIRST AROUND)
			   (,@(REST AROUND)
			    (MAKE-METHOD ,FORM)))
	     FORM))))

All the generic functions use STANDARD method combination, or an
extension of it.

3-13: Last bullet
      Portable metaclasses cannot be redefined.
Why not?  I can see why user code shouldn't go around redefining the
standard metaclasses for the same reason they shouldn't be allowed to
redefine CAR, but I can't think of any reason to disallow it for
user-defined metaclasses.  I think the CLOS implementation should just
make this kind of thing happen automatically via inheritance.

3-17:  I can not accept the section for parsing of DEFCLASS, since it
prohibits compile-time checking for spelling mistakes in option names.

3-18:  The figure is obsolete and inconsistent with page 3-17.

If I define the PLANE class with documentation, and then redefine it
without documentation, what makes the documentation go away? 

3-19:  As stated previously, I can not accept the macroexpansion for
SST.

3-19:  Methods -- I'd still like to let the method body be involved in
choosing the method's class.  For example, 

   (DEFMETHOD FOO-X ((THING FOO))
     (SLOT-VALUE THING 'X))

should be able to turn into a reader method.  This helps while expanding
method combinations, a topic which I hope to get into the CLOS report.
I think I sent a proposal for how to make DEFMETHOD, etc. do this back
in May.

3-21:  The above excepted, this expansion looks about right.

3-21: third par of Processing Method Bodies
       ensure-generic-function's :environment keyword -- How about just
saying that this is an allowed keyword, the details of which are
implementation-dependent?