Sam Ruby wrote:
Leopold Toetsch wrote:
class_self."__super"(args)
so again the invocant is the first argument after interpreter.
Believe it or not, I think we are agreeing.
*g*
To invoke a method on an object using Parrot Calling Conventions, P2
needs to be the object used for dispatch purposes
Leopold Toetsch wrote:
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often th
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often the case that the first a
Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
Why do we have the special notion of current_object in the first place?
Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> Why do we have the special notion of current_object in the first place?
>> Why not just pass all in as P5, P6, ...?
> I agree that this is the way to go. Especially if we have some marker
> somewhere that tells us that we were ca
Leopold Toetsch writes:
> Why do we have the special notion of current_object in the first place?
> Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that we were called as a method.
Luke
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The note here is that Parrot's MMD function signature for binary ops
> doesn't match what Python needs. Parrot is:
> void binary_mmd_op(pmc left, pmc right, pmc dest)
> where Python is:
> pmc dest = left.add(pmc right)
Perl6 allows (according
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
>>Thinking more about that it seems that we don't have much chance to keep
>>the current scheme that the destination is passed in.
> I fully expected this to be an issue. Perl 5 and perl 6 are going to
> ha
At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
Thinking more about that it seems that we don't have much chance to keep
the current scheme that the destination is passed in.
(This is probably out of order -- I've a lot of mail I'm backed up on
unfortunately, but since it was CC'd directly to me
Leopold Toetsch wrote:
Comments?
leo
As enjoyable as this discussion has been, I'd like to ask that it be put
on hold for a few days. I've nearly got all the previously defined
languages/python/t/basic tests running, and once they are running, I'd
like to do a bit of refactoring and documentat
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ fullquote ]
> A recent discussion with Sam has shown that the current calling
> conventions for overloaded operators don't match Python semantics (nor
> Perl6 when I interpret S06 and S13 correctly).
> The difference is that Parrot is passing in the d
A recent discussion with Sam has shown that the current calling
conventions for overloaded operators don't match Python semantics (nor
Perl6 when I interpret S06 and S13 correctly).
The difference is that Parrot is passing in the destination argument
while these languages are returning the oper
12 matches
Mail list logo
