pdd03 and method calls
Leopold Toetsch
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't really
play with Perl5 <-> Perl6 interoperbility IMHO. Perl5 methods are plain
subs, where the first param is the object. I dunno, if Ponie will ever
use ParrotClass/ParrotObject, but I'm sure, that calling Perl6 methods
should work (and vv). So me thinks that the method PMC should be the
first PMC argument living in P5.
sub meth {
my ($self, $arg1) = @_;
# P5 P6
...
Comments?
leo
Dan Sugalski
>While playing with calling threaded subs, I came along a thing which
>I think might be suboptimal:
>pdd03 states that the method PMC should go into P2. This doesn't
>really play with Perl5 <-> Perl6 interoperbility IMHO. Perl5 methods
>are plain subs, where the first param is the object.
PDD 03 states that the *object* goes in P2. This works out just fine
with perl 5 style method calls, where the argument list doesn't
distinguish the object other than by position. What happens is that
when a perl 5 sub is called, @_ is a combination of P2 if it's
non-NULL, and the remaining PMC registers. It's slightly more work
for the perl 5 code generator to handle the check, but other than
that it shouldn't be a problem.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Juergen Boemmels
> While playing with calling threaded subs, I came along a thing which I
> think might be suboptimal:
>
> pdd03 states that the method PMC should go into P2. This doesn't
> really play with Perl5 <-> Perl6 interoperbility IMHO. Perl5 methods
> are plain subs, where the first param is the object. I dunno, if Ponie
> will ever use ParrotClass/ParrotObject, but I'm sure, that calling
> Perl6 methods should work (and vv). So me thinks that the method PMC
> should be the first PMC argument living in P5.
When I was experimenting with native methods in ParrotIO.pmc i had
also the problem that there was no way to put the P2 register to the
argument list. I don't know if this changed since then, but I had
put the object to P5.
> sub meth {
> my ($self, $arg1) = @_;
> # P5 P6
> ...
>
This makes a method-call and a sub-call more symetric. Both a method
object and a sub object are called via
invokecc P0
and returned with
invoke P1
the difference between them is currently that a method will use one more
register for the data transfer: P2
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Luke Palmer
> At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote:
> >While playing with calling threaded subs, I came along a thing which
> >I think might be suboptimal:
> >pdd03 states that the method PMC should go into P2. This doesn't
> >really play with Perl5 <-> Perl6 interoperbility IMHO. Perl5 methods
> >are plain subs, where the first param is the object.
>
> PDD 03 states that the *object* goes in P2. This works out just fine
> with perl 5 style method calls, where the argument list doesn't
> distinguish the object other than by position. What happens is that
> when a perl 5 sub is called, @_ is a combination of P2 if it's
> non-NULL, and the remaining PMC registers. It's slightly more work
> for the perl 5 code generator to handle the check, but other than
> that it shouldn't be a problem.
Or perhaps the invocant can go in both P2 and $_[0] (depending on where
that happens to be).
Luke
Juergen Boemmels
> PDD 03 states that the *object* goes in P2. This works out just fine
> with perl 5 style method calls, where the argument list doesn't
> distinguish the object other than by position. What happens is that
> when a perl 5 sub is called, @_ is a combination of P2 if it's
> non-NULL, and the remaining PMC registers. It's slightly more work for
> the perl 5 code generator to handle the check, but other than that it
> shouldn't be a problem.
It is missing from PDD03 that P2 must be set to NULL in case of a
normal subroutine call. Otherwise P2 can contain everything and the
called function has no way to decide if the data is valid.
An other possibility would be to let invoke set P2 to null, but I
don't like the idea of having more sideeffects in invoke. This also
makes it impossible to write callmeth as:
find_method P0, P2, S0
invoke P0
Melvin Smith
Makes sense to me for non-prototyped methods.
How 'bout:
Non-prototyped: pass object in P5 array with rest of arguments
Prototyped: pass in P2 as in current spec
-Melvin
Leopold Toetsch
> At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote:
>>While playing with calling threaded subs, I came along a thing which
>>I think might be suboptimal:
>>pdd03 states that the method PMC should go into P2. This doesn't
>>really play with Perl5 <-> Perl6 interoperbility IMHO. Perl5 methods
>>are plain subs, where the first param is the object.
> PDD 03 states that the *object* goes in P2.
Yep, typo - sorry.
> This works out just fine
> with perl 5 style method calls, where the argument list doesn't
> distinguish the object other than by position. What happens is that
> when a perl 5 sub is called, @_ is a combination of P2 if it's
> non-NULL, and the remaining PMC registers. It's slightly more work
> for the perl 5 code generator to handle the check, but other than
> that it shouldn't be a problem.
That seems to indicate, that we have to expose the whole parameter
passing to HLLs and that Perl5 (and probably other languages) can't use
the builtin PIR shortcuts (or we have to provide both schemes depending
on some pragma directive).
Additionally to the test:
isnull P2, no_object # must be set to NULL on non-method calls
we would need 2 code paths: For leaf subs[1], one can use registers as
is, one would need rearanging the param regs.
And as outlined by Juergen it doesn't fit very well for calling NCI PMC
class methods: We would need another signature letter to denote the
object.
That's of course all doable but is adding assymmetry to method calls,
which I don't like much.
[1] these just use P5..Pn as passed in.
leo
Dan Sugalski
Nope. The object is a special thing, and as such needs a special
place. Both Python and Ruby treat it differently at the language
level, and Parrot needs to treat it specially at the low level to do
proper method dispatching. I'd rather it stay where it is, off on the
side.
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> writes:
>
>> PDD 03 states that the *object* goes in P2. This works out just fine
>> with perl 5 style method calls, where the argument list doesn't
>> distinguish the object other than by position. What happens is that
>> when a perl 5 sub is called, @_ is a combination of P2 if it's
>> non-NULL, and the remaining PMC registers. It's slightly more work for
>> the perl 5 code generator to handle the check, but other than that it
>> shouldn't be a problem.
>
>It is missing from PDD03 that P2 must be set to NULL in case of a
>normal subroutine call.
Fixed. Should be checked in, or will be soon.
Leopold Toetsch
> Yep, typo - sorry.
> Additionally to the test:
> leo
leo