[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Continuing comments on Draft 11
- To: Cyphers@JASPER.SCRC.Symbolics.COM
- Subject: Continuing comments on Draft 11
- From: Jon L White <jonl@lucid.COM>
- Date: Fri, 2 Nov 1990 09:51:12 PST
- Cc: gregor@parc.xerox.com, mop@arisia.Xerox.COM
- In-reply-to: "Scott Cyphers's message of Fri, 2 Nov 1990 10:49-0500 <19901102154943.7.CYPHERS@SEAR.SCRC.Symbolics.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.
So I wonder, is the vanilla definition of METHOD-FUNCTION really every
going to be very useful?
-- JonL --