define-method-combination

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

    Date: Sat, 21 May 88 22:27 EDT
    From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>

    Before I launch into the usual tirade, I'd like to make a suggestion
    which might have some hope of being considered:

    define-method-combination should accept an option
      (:generic-function <symbol>)
    and bind <symbol> to the relevant generic function.
    This has much the same flavour as the existing :arguments option.
    I think that this is a nicer solution than binding
    a magic variable named `generic-function'.

I agree.  I think this just got overlooked when :arguments was added,
because before that there wasn't any agreed-upon syntax for saying
things like this.  Group: Is there still time to change this?

    ....
    On the other hand, as long as I've been using lisp machines (up to this
    very day) I've encountered combined methods which weren't caught at
    compile-time.

And as long as I've been using Lisp, I've encountered files that use a macro
that has been changed, but no one remembered to recompile the file, so the
caller of the macro was not updated.  Few people propose to remove macros
from Lisp for that reason.  I just don't think your argument is relevant.

    ....
    My overall fear is that this sort of approach will create two classes of
    programs -- those which use the system's predefined method combination
    types and standard method definition (such as defmethod with
    :method-class standard-method) and those which use anything else.  The
    first class of programs can expect a much higher level of support than
    the latter, because the compiler has been taught special tricks.  

I agree that that could happen, but I see no reason why it must.

								      I like
    to think that one of the aims of CLOS in general (though Chapter 3-style
    specifications) is to expose as much of the underlying works as is
    necessary to allow non-`standard' classes/method-combination/etc to be
    able to expect a level of support which is at least of the same order of
    magnitude as that provided by the system.  This certainly does not seem
    to be the case with user-defined method-combination types.

I agree with your first sentence, but don't see why you think
user-defined method-combination types are any different from anything
else.  Also, you've changed your argument.  First you said user-defined
method combination types require the existence of a compiler at load
time (and implicitly you assumed that all Lisps are like most of today's
(but not the 1950's!) Lisps, in that if you have a compiler at load
time, you cannot get rid of it at run time).  Now you're saying that
user-defined method combination won't compile as efficiently as standard
method combination, an entirely different argument.  I think your new
argument is analogous to saying that it's better to use DO than LOOP,
not because you like the syntax better, but because DO as a built-in
macro is likely to compile more efficient code than LOOP, as a
user-defined macro.  That's even true to some extent with some
compilers, but few people change their whole programming style on the
basis of that kind of consideration, and in all the arguments against
LOOP I've heard over the years, I don't recall ever hearing that one.
I really believe that method combination is just like a macro.

    However, if user-defined method combination is to be a toy which works
    1/1000th as well as system-defined method combination (because it has to
    call out to the evaluator or otherwise do a bunch of unnecessary hair at
    run time or require the presence of a full lisp compiler)

Please, please, please do not be confused by the interpreter-oriented
presentation, any more than you would be confused by a Lisp textbook which
explained the language in interpretive terms and only introduced the compiler
in a late chapter.  Semantics are easier to explain interpretively, but no
one proposes calling out to the evaluator in any real implementation.

    then why
    bother specifying it at all?  I'm sure most people will be happy with a
    few standard method combination types -- why clutter up the world and
    raise people's expectations with something which can't be guaranteed to
    work very well?

Change "method combination type" to "macro" and read your argument again.
Of course, there are people in the Scheme community who believe that argument.
I think Common Lisp is way past aspiring to that level of purity, though.

    I don't believe Moon's argument that something less than a full lisp
    evaluator will do to interpret user-defined effective methods -- it is
    trivial to define a method combination type (and not even a particularly
    contrived one) which will defeat this.

Of course.  It's also trivial to write a program that cannot be compiled.
In practice, people who care about the issue you're concerned with don't
do those things.