call-method proposal prime prime

[Gregor.pa@Xerox.COM]

    Date: Thu, 28 Jan 88 21:38 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I noticed that MAKE-METHOD is never actually macroexpanded, but I think
    it is easier for the user to think of it as a local macro that changes a
    form into a method, even though it's not implemented that way.  I don't
    feel real strongly about this, but unless you feel strongly let's leave
    it alone.

I don't know how strongly I feel, but let me show you the case that
bothers me, and if it doesn't bother you too much we'll leave it.

The general form of the case is when you don't construct the second
argument to call-next-method in a special place, so you have the whole
call-method form laid out in front of you.  Suppose you knew there was
one around method and two or methods.  Lets just say that was a special
kind of method combination you had.  It would look like:

(define-method-combination 1-n-2 ()
        ((around (:around))
         (or (:or)))
   (let ((around (car around))
	 (or-1 (car or))
	 (or-2 (cadr or)))
     `(call-method ,around
		   ((make-method (or ,or-1 ,or-2))))))

It seems like when the user sees that case they are going to start
realizing pretty quick that make-method isn't really a lexical macro.
There is this whole question of when naivete is helpful and when it is
confusing.  I kind of believe that in this case, the naive model we are
proposing might confuse people without them knowing why.

But as I said before if this doesn't bother anyone else I am will to let it
go.
-------