define-method-combination

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

    Date: Sat, 21 May 88 15:18 EDT
    From: Richard MlynBaOrik <Mly@AI.AI.MIT.EDU>

    [common-lisp-object-system@SAIL.STANFORD.EDU removed]

[Added back since I thought it was useful for the whole list to see
the reply.  I don't expect I'm embarrassing you.]

	Date: Fri, 20 May 88 20:02 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	    * I find the `evalness' of define-method-combination very disturbing.
	    It seems to me that a full lisp compiler or evaluator will need to be
	    present in any world into are loaded methods on generic functions which
	    use user-defined method-combination.  I would -very- much like to be
	    convinced that this isn't the case.

	I don't understand your point.  How is define-method-combination different
	from defmacro in this respect?  Perhaps you've been misled by the way the
	spec describes everything as if it was interpreted into thinking that it
	cannot be compiled?

    I'm wondering how add-method works.

    If one does a random add-method to a generic function (say by loading a
    file containing a defmethod form) then whenever the combined
    (`effective') method is created (at instance instantiation time or
    whenever) something has got to look at the lisp code produced by the
    `macroexpansion' of a define-method-combination form.  This
    macroexpasion can't be performed any earlier, because it depends on the
    applicable methods.

That's quite a reasonable concern to have, however we've thought of it.

The compiler can anticipate what add-method calls are going to be
produced by forms the compiler has seen, such as defmethod forms.  The
code resulting from method-combination can be predicted at compile time
and compiled then, with a simple mechanism to make sure at load time
that that pregenerated code gets used.  This is how it works in Flavors,
so that's an existence proof.

Of course if a program calls add-method at run time in a way the compiler
can't anticipate, such techniques can't win.  But I'd say that kind of
program, which changes its structure at run time, should not be surprised
to depend on having a compiler at run time.

    As I see it, either the lisp evaluator is used whenever the combined
    method is called or else the lisp code produced by
    define-method-combination has to be turned into something executable by
    `the machine.'

It's also true that an evaluator different from the Lisp evaluator can
be used.  For example, the form returned by the method combination
function can be recognized as an instance of a pattern and the effective
method can be a closure of a preexisting function that knows how to
"evaluate" such forms; the enclosed variables typically have methods or
lists of methods as their values.  The preexisting functions can even be
generated automatically when the system is compiled, from declarative
specifications (arrange for x type of method combination to work with n
applicable methods in role z).  Some types of method combination work
this way in Flavors in 7.2 [oh, I see you know that], and I'm told PCL
also works this way.  I assume that CLOS can work this way, too, using
the world's simplest pattern matcher to recognize forms returned by
method combination functions.