FYI: a metaobject extension

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

Just for your information, not as a proposal, here's a brief description of a
metaobject protocol extension that I had to make recently in order to
implement efficiently a somewhat complex form of parameterized type
inheritance.  The basic need is for one argument to a method to be different
from the argument passed to the generic function, in a way controlled by the
relationship between the class of another argument to the generic function and
the class on which the method specializes that argument.  The implementation
technique is for method combination to insert into the effective method form
code that computes the modified argument.

The first extension is a way to make CALL-METHOD able to change the arguments.
If CALL-METHOD has more than two arguments, then its lambda-list is
(method &key next-methods arguments), where :next-methods is the same as the
second argument in the standard syntax, and :arguments is an alist of
argument substitutions ((index substitute)...) where index is a 0-origin
index into the argument list and substitute is a form to be evaluated to
produce the replacement value for that argument.  The form can depend on the
original values of that and other arguments, picked up through the :ARGUMENTS
option to DEFINE-METHOD-COMBINATION.

The second extension was a modified form of COMPUTE-EFFECTIVE-METHOD with more
arguments, including information about the classes of the arguments that will
be supplied to the generic function when this effective method is executed.  I
don't want to describe the exact way this was done, but only to point out that
it is a deficiency of the current metaobject protocol that this information is
not made available.

By the way, although it's not really part of this, in the same project I also 
had to extend DEFMETHOD to allow a parameter specializer name to be a class rather
than a class name.  This was necessary because not all classes have names.  This
was the only place in CLOS I could find where a class object cannot be used where
a class name is accepted, so I think it's an inconsistency and would propose
to change it if the CLOS language were not stable.