[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Continuing comments on Draft 11
- To: jonl@lucid.COM, Cyphers@JASPER.SCRC.Symbolics.COM
- Subject: Continuing comments on Draft 11
- From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
- Date: Fri, 2 Nov 1990 10:30:00 PST
- Cc: gregor@parc.xerox.com, mop@arisia.Xerox.COM
- In-reply-to: <9011021751.AA21624@caligula>
Date: Fri, 2 Nov 1990 12:51 EST
From: Jon L White <jonl@lucid.com>
re: Internally, in our implementation, all the functions that implement
methods (I'll avoid the word method-function), as well as those which
implement the connecting glue of an effective method, take an extra
argument.
Since you said this in the context of the comment:
In addition, as far as I know, no one has addressed the question of
methods requireing "next methods" context yet.
I presume you are talking about your technique for implementing
"next methods" contexts? I think that TI does it by passing a hidden
argument to the function (the method-call protocol bashes it into
a pre-arranged local var in the forming stackframe). But this isn't
suitable for interpretation, nor is it practical for Lucid's
implementaion.
What you are talking about looks like "currying" on an extra formal
parameter to the method-lambda. We had considered that at Lucid a
long time ago, and decided that we couldn't tolerate the extra stack
shuffling that would imply in certain circumstances where the extra
"curry'd" argument caused the frame to be "off by one". But it is
still a very attractive idea.
The idea goes back at least to old flavors, probably about the time when
instance variables stopped being specials. On the 386, if the compiler
believes a generic function is being called, I think it leaves a hole
for the extra argument (hence it helps performance to have your
defgenerics appear early). The hole doesn't matter if it turns out not
to have been a generic function. If a generic function gets called
where the compiler didn't leave the hole, then the arguments get copied.
This turned out to work pretty well. On Ivory, the start call
instruction will push an extra argument if the data type of the function
is one of several things, one of which is a generic function. On the
3600, function calls always copy the arguments, and the microcode knows
to put the hole in for the extra argument.
So I wonder, is the vanilla definition of METHOD-FUNCTION really every
going to be very useful?
I was wondering about that myself. I'd like to see a simple example of
a proposed use of METHOD-FUNCTION; it may be doing something completely
different from what we are thinking it does.
-- JonL --