overriding invoke from PIR

Andrew Whitworth wknight8111 at gmail.com
Thu Nov 12 13:27:21 UTC 2009

My thought on this is that they can be in any order, and we don't need
to make them only the first one or two parameters. We can treat them
like any ordinary positional parameter (so they must come before all
optional and named parameters).

All the parameters get filled in the loop inside fill_params(), so it
doesn't matter which order.

--Andrew Whitworth

On Wed, Nov 11, 2009 at 6:58 PM, kjstol <parrotcode at gmail.com> wrote:
> I just have one issue with using flags like :self and :current_sub to
> indicate what a particular .param would be, and that's the order.
> Using :flags like these implies that you could write:
> .sub foo :method
>  .param pmc x
>  .param pmc y
>  .param pmc a :self
>  .param int b
>  .param string c :optional
>  .param int hasc :opt_flag
>  .param pmc :current_sub
> ...
> .end
> In other words: the position of the :self and :current_sub parameters
> seems to be  random. Of course, the reply on this would be: don't
> allow that. Just allow :self and :current_sub on the first parameters.
> You could do that, implement this kind of check, but it just feels
> very hacky to me.
> Just a note of the language lawyer here :-)
> kjs
> On Wed, Nov 11, 2009 at 9:33 PM, Austin Hastings
> <Austin_Hastings at yahoo.com> wrote:
>> Andrew Whitworth wrote:
>>> 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
>> This is just wrong. In every single case, according to your scenario, foo is
>> a custom method PMC. And therefore in every single case the dispatch of
>> interest will be to the foo.invoke method. So mysub had better be C< invoke
>>>, rather than C< foo >. (Of course, the foo.invoke may transfer the
>> execution someplace else, in which case all bets are off. But I don't think
>> that's what we're talking about, is it?)
>> In cases where C< .invoke > is not overridden, the C< mysub > has very
>> little value that I can see, and in cases where C< .invoke > *is*
>> overridden, it provides no information.
>> I don't have any problem understanding the current semantics of C< self >.
>> If vtable invoke is overridden, I maintain that C< self > should refer to
>> the invocant of the C< .invoke() >, which is going to be C< foo >, rather
>> than C< bar >.
>> If you're going to campaign for the C< :invocant > keyword, and I understand
>> there is a TT on this issue (plus some unsatisfied promises in the PDDs, I
>> think), I don't think this area is where the problems will occur. A better
>> question is the relationship between C< :invocant > and the C< :method >
>> attribute.
>> Pmichaud has been campaigning to get methods out of the namespace. Which
>> means that C< :method > should be doing ":anon + predefine(self)". If we
>> eliminate the C< self > builtin, then AFAICT, C< :method > becomes an alias
>> for C< :anon >.
>> Since that's where I think a lot more use cases are going to happen, can we
>> get any C< :invocant >-inspired changes to C< :method > hammered out first?
>> =Austin
>>> 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
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev

More information about the parrot-dev mailing list