[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Standardizing the macroexpansion of make-method-call
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Standardizing the macroexpansion of make-method-call
- From: Gregor.pa@Xerox.COM
- Date: Tue, 5 Jan 88 12:54 PST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Fcc: BD:>Gregor>mail>outgoing-mail-1.text
- In-reply-to: <19871229034700.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
- Line-fold: no
Date: Mon, 28 Dec 87 22:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Gregor pointed out that in order to be able to analyze effective method
forms, which is something we claim can be done, it is necessary to be
able to recognize the macroexpansion of MAKE-METHOD-CALL. This is true.
This message is a fairly long discussion of the issues. You needn't
include all of it in replies.
I see three possible approaches:
Offhand, I prefer approach 3 although the gruesomeness of the examples
is pretty frightening. I think I want to think about this a bit more.
The purpose of this message is to say that we also need some facility
which lets the user call a random function on the same arguments the
generic function received. This facility might be called
MAKE-FUNCTION-CALL or FUNCTION-CALL or hopefully we could come up with a
better name. We have seen several examples of people who want a method
combination type which performs some specific behavior as part of the
combined method but that behavior needs access to the arguments to the
generic function.
Inventing this might even lead us out of the mess we have with
make-method-call because it might force us to come up with a real
abstraction for 'captured calls' and for 'access to the generic function
arguments'.
More on this later if I can think of anything, I sent this now hoping it
might help someone else think of something.
-------