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 the
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
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
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,
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 to
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
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 called as
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
have
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
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
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
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
12 matches
Mail list logo
