define-method-combination

[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 only partially believe what Moon says about define-method-combination.

On the whole, I find his arguments unfortunate sorts of thing to have to
claim, especially when there are another ways of declaring method
combination this which avoids this sort of problem.  (By constructing
closures rather than s-expressions.)

I do believe his arguments as applied to system-predefined
method-combination -- after all, and as he says, we have Flavors as an
existence proof.

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.  So I suppose we should say that we would have Flavors as
existence proof in principle...


I very much doubt that a user will in fact be able to declare enough to
the system to generate the same quality of code as the specially-
recognised predefined system method combination types -- let
alone that s/he would be able to declare this is any portable way!

I realize that CLOS is only specifying semantics, but why make things
harder than they need be, so hard they they need a Sufficiently Smart
Compiler Sufficiently Useful Magic-Unspecified-Declarations/
Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
(For years there has been talk about sufficiently smart compilers taking
all of my troubles away, but I've yet to see evidence of such things.)

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 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 know there are limits to this argument -- for example I doubt that J.
Random Generic-function Metaclass could expect the same performance as
implementation-tuned standard-generic-function.)

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) 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?   Especially, why clutter the world so much the EVAL
becomes required (when nothing else in CLtL except for the section on
the evaluator seems to require such a horrible thing)?



BTW I've looked at the pattern-matchers (by no means ``the world's
simplest'' -- PCL's uses a real code-walker) in both PCL and Flavors and
still doubt that they can do enough before they become full lisp
compilers.  (When Flavor's pattern-matcher punts, it ends up calling
compile.)

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.



I guess Scheme has gone badly to my brain -- the mere hint of run-time
evaluation/compilation makes me feel ill (the symptoms are flames coming
from the mouth.)  There is another reason, though:  I have recently had
very bad experiences with a very large piece of software which suffered
and suffered (and made me suffer) because of the way it called out to
the evaluator. 



Anyway, this whole issue was originally filed under the
``Just to be contentious'' label -- I didn't expect and still do not
expect to convince anybody.

I am not going to continue to flame about this.