Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Why so? Python methods don't have a notion of an object - it's just the
>> first argument passed into a function. So I don't quite understand your
>> conclusion.
> In the case of
> x.y(z)
> The caller is passing one argument. The recipient is expecting two.
> The recipient defines what is expected as the first argument (in class
> methods it is the class, in instance methods it is the instance).
Yes. Let's start at the called sub/method.
Specifically a user function "y" would looks this:
1)
.sub y
.param pmc x
.param pmc z
as this is the general translation of the user code "y". If you know
that it's a method, you currently could translate it like:
2)
.sub y method
.param pmc z
x = interpinfo .INTERPINFO_CURRENT_OBJECT
But at the caller site you don't know anything about "y" - so with your
proposed argument passing the code in "y" would need a prologue to
handle both cases in both callee variants, right?
> So, in the general case, the callee is responsible for inserting a
> parameter at the beginning of the PMC parameters.
That's not all. Case 2) above - the method - can in all our target
languages be called with a sub call syntax - AFAIK:
y(x, z)
This is the normal call syntax for Perl6 multi-subs.
With two different schemes for the callee, we got two variants that
would work w/o further argument adaption and two variants that need
either shifting arguments up or down. But this prologue would be needed
in every function or method.
> ... Insertion by setting
> a value into P2 is cheaper than insertion by shifting and then setting a
> value into P5.
Already optimizing? - SCNR. Anyway: src/sub.c:copy_regs() already copies
registers from the caller's register frame to the callee. Implementing
argument shifting there is cheap - if it's still needed.
By defining that all subs or methods get the arguments (including the
object) passed in P5, P6 ... we'd only have half of the mis-matching
argument orderings.
> At definition time, the PyFunc PMC has a number of properties (or flags)
> which are set defining names of the formal arguments, defaults, and the
> like.
Yes, more complications.
> ... A similar approach can be used to define whether the first
> parameter is expected in P2 or P5.
Sure. But why should we go the more complicated way in the first place?
> Note: different languages may chose different strategies as to when to
> shift. What is important is that we come to an agreement on what is
> expected of the caller.
>From the caller's POV its quite clear if it's a method or a function
call. But if the other end has two incarnations, things get messy.
> - Sam Ruby
leo
