overriding invoke from PIR

Andrew Whitworth wknight8111 at gmail.com
Wed Nov 11 19:44:09 UTC 2009

That's a good point, Austin, but I think it does a lot to illustrate
just how complicated and confusing the keyword "self" is in PIR.
Looking at three examples here, where bar is an Object, and foo is a
custom method PMC:

1) foo("x")
2) bar.foo("x")
3) foo.invoke("x")

My suggestion is this: First, we get rid of the keyword "self". It's
too limiting and confused. Instead, I suggest we do this:

.param pmc myself :invocant
.param pmc mysub :current_sub

Now, for the three examples:

1) myself = null, mysub = foo
2) myself = bar, mysub = foo
3) myself = foo, mysub = invoke

In these three cases, the values for myself and mysub have consistent
semantic meanings, and yet we're able to identify and handle all three
of these causes unambiguously. Because all three cases are
semantically distinct, and we shouldn't be shoehorning all instances
of invocation to use a single pattern.

I say we deprecate the "self" keyword in PIR, or we agree that it
should have a consistent semantic meaning as an alias for :invocant.
Anything else is far too confusing.

--Andrew Whitworth

On Wed, Nov 11, 2009 at 2:19 PM, Austin Hastings
<Austin_Hastings at yahoo.com> wrote:
> IMO:
> A method is, in this case, an object that is performing one of its possibly
> myriad behaviors.
> That is, if I say
>   my $bank_account := CheckingAccount.new('100.00');
>   $bank_account.debit('5.00');
> it is pretty clear what is happening. I think that the same is true for
>   my $method := Method.new(...);
>   my $call_signature := CallSignature.new(...);
>   $method.invoke($call_signature);
> In this case, the $method is the object, and so should be self. The
> hypothetical invocant of the method should be encapsulated, along with all
> the other arguments, inside the call signature.
> Self, IMO, refers to the method, while $call_signature[0], or
> $call_signature<self>, or however you want to access it, refers to the
> object upon which the method is operating.
> The point here is that by making the override, we have "gone meta" and so
> the method is no longer just a sub, but now is a first-class object. Anytime
> you're inside the namespace of that object, self refers to the object.
> =Austin
> Andrew Whitworth wrote:
>> NotFound posted a very interesting patch to TT #1262 to enable us to
>> start overriding invoke VTABLE from PIR. it's incomplete at the
>> moment, because there is a bit of a syntactical question that needs
>> answering.
>> To illustrate, consider two objects: foo and bar. Bar is an ordinary
>> Object, while foo is a custom Sub-like PMC type with invoke. First:
>> foo()
>> here, we invoke foo directly. Second:
>> bar.foo()
>> Now we're invoking foo again, but now bar is the invocant.
>> In PIR, the "self" keyword refers to the invocant. So in the second
>> example I think we would all agree that bar is the invocant and so in
>> the invoke override "self" should refer to bar. So how then, inside
>> the invoke, do we get a reference to foo? If you look in
>> compilers/imcc/pcc.c:unshift_self(), the handling of the invocant is
>> relatively lousy and O(n).
>> I would like to propose a change. I propose that "self" no longer be a
>> magic keyword. Instead, I suggest that we should use new .param types
>> to get references to the current invocant and the currently executing
>> sub:
>> .sub baz
>> .param pmc myself :self
>> .param pmc currsub :current_sub
>> ...
>> .end
>> So in the case of "foo()", myself == currsub == foo (or, myself ==
>> null, currsub == foo). In the case of "bar.foo()" myself == bar,
>> currsub == foo.
>> This gives us a few benefits:
>> 1) We'll be able to start overriding VTABLE_invoke in a meaningful way
>> 2) We'll be able to detect whether a Sub was invoked as a
>> standalone-sub or as a method
>> 3) This should get the :invocant thing working, which has been
>> requested for some time (whether we call it :invocant or :self or
>> whatever is a matter of some bikeshedding).
>> 4) I think we can implement these flags without decreasing PCC performance
>> 5) We should be able to do this without deprecating or chnging the
>> behavior of the "self" keyword as it is now (though we could make it
>> lazy, so "self" only exists if an ":invocant" has not been explicitly
>> specified), etc
>> ...And drawbacks:
>> 1) In every other VTABLE, "self" will refer to foo. But in invoke
>> "self" will be something else and :current_sub will be foo.
>> 2) I'm going to have to get within 100 feet of IMCC.
>> So I would like to get some feedback from devs, especially HLL devs
>> about whether this would be a good change.
>> --Andrew Whitworth
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev

More information about the parrot-dev mailing list