"use feature 'invocant'" enables the $-> operator. There are twovariants:

- "use invocant '$self" looks for the specific lexical variablenamed $self in the current context, and bails out in compiletime if not found.

- "use invocant 'auto'" looks for the first real pad entry in thenearest scope as the default invocant.

I am not sure which one suites as better default behaviour. thelatter seems less intrusive on insisiting variable names by canbe a bit confusing.

Conflicts:

$-> can be parsed as $- > ($- greater than .. ), so we need todeprecate the use of $- (and hopefully the whole format system byrequiring use of formats to add additional "use format" line.)the feature can install a warning when accessing $- before suchdeprecation.

David GoldenIf we're really pondering this sort of thing, why not think more broadly and finally get around to dealing with method/object syntax? (Like some of the syntax manglers on CPAN do.) Hypothetically: use feature 'method'; method foo { self->wibble($_) for @_; } I.e. Given a "method" keyword, set up the invocant in some way and leave it out of @_. People can bikeshed the most efficient way to set up the invocant -- in my example I have a bareword, but it could be "$self" or "$*" (available now

If we're really pondering this sort of thing, why not think morebroadly and finally get around to dealing with method/object syntax?(Like some of the syntax manglers on CPAN do.)

Hypothetically:

use feature 'method';

method foo {self->wibble($_) for @_;}

I.e. Given a "method" keyword, set up the invocant in some way andleave it out of @_. People can bikeshed the most efficient way to setup the invocant -- in my example I have a bareword, but it could be"$self" or "$*" (available now without a deprecation cycle) orwhatever else people dream up.

ChromaticThis proof of concept patch enables that, with $self as the invocant. It could use more robust testing, but all existing tests pass. The trick of using lex_stuff_pvs() seems grotty, but it's far, far easier than building a new optree with the appropriate lexical bindings within the method production in perly.y. The patch needs make regen_perly after applying. -- c

ZeframAs something to go in the core, I do not approve of this shortcut. You should definitely build the optree rather than stuff source. It also seems very unwise for the core to take the keyword "method" at this stage. We have several CPAN modules supplying "method" keywords with various semantics, it's an unresolved area. -zefram

chromatic wrote:This proof of concept patch enables that, with $self as the invocant. Itcould use more robust testing, but all existing tests pass.You should prototype this as a CPAN module, using the keyword hook.The trick of using lex_stuff_pvs() seems grotty, but it's far, far easier thanbuilding a new optree with the appropriate lexical bindings within the methodproduction in perly.y.

As something to go in the core, I do not approve of this shortcut.You should definitely build the optree rather than stuff source.

It also seems very unwise for the core to take the keyword "method" atthis stage. We have several CPAN modules supplying "method" keywordswith various semantics, it's an unresolved area.

ChromaticThat means: * grabbing the optree *already generated* for the body of the sub * creating a new lexical $self binding in that optree * rummaging through every variable access in that entire optree to find $self, if it exists * rebinding those package globals to the lexical * building up the appropriate optree for 'my $self = shift'; * splicing the new optree to the existing optree I've done all of this before with B::Generate activated by a new :method attribute on existing subs. It's fragile

You should prototype this as a CPAN module, using the keyword hook.How do you use keyword hooks to add 'method' to the imports of feature.pm?It also seems very unwise for the core to take the keyword "method" atthis stage. We have several CPAN modules supplying "method" keywordswith various semantics, it's an unresolved area.To my knowledge, none of them import 'method' from feature.pm.As something to go in the core, I do not approve of this shortcut.You should definitely build the optree rather than stuff source.

That means:

* grabbing the optree *already generated* for the body of the sub* creating a new lexical $self binding in that optree* rummaging through every variable access in that entire optree to find $self,if it exists* rebinding those package globals to the lexical* building up the appropriate optree for 'my $self = shift';* splicing the new optree to the existing optree

I've done all of this before with B::Generate activated by a new :methodattribute on existing subs. It's fragile and unpleasant enough in Perl, andit's a lot of special-purpose code to stuff into perly.y.

The worst part is doing this all in a way that doesn't trip the strict pragma.I don't know how to do that.

Alternately, you could take the approach that doesn't add at least a fewhundred lines of new code to the parser for a special case. You could use asmuch existing code as possible (code that knows how to build an optree, codethat knows how to create lexicals, code that knows how to decide $self islexical, et cetera).

David GoldenThis is why I was pondering a "self" keyword. If it could access the right reference at runtime you wouldn't need to worry about the existing bindings. Imagine: * method { ... } somehow marks the subroutine body as a method * dispatch to such a marked method doesn't put the invocant in @_ but puts it "somewhere else" (big hand-waving here) * keyword self retrieves invocant from wherever it got put I leave it to people who know the guts in detail to explain why that is doomed to fail. :-) --

On Thu, Jan 20, 2011 at 2:28 PM, chromatic wrote:* grabbing the optree *already generated* for the body of the sub* creating a new lexical $self binding in that optree* rummaging through every variable access in that entire optree to find $self,if it exists

This is why I was pondering a "self" keyword. If it could access theright reference at runtime you wouldn't need to worry about theexisting bindings.

Steffen Mueller"wherever" would likely still be the stack, except @_ is populated only with the elements after the invocant. The little understanding I have of these matters suggests that arguments will be passed via the stack no matter what and @_ is then "aliased" (SV* copy? Too lazy to check.) to the elements since the last pushmark. If there was a flag to start only after the first element and make the sp accessible via "self" by some mechanism, that might just do it. Yes, it is now up to them :) Cheers,

* grabbing the optree *already generated* for the body of the sub* creating a new lexical $self binding in that optree* rummaging through every variable access in that entire optree to find $self,if it exists

This is why I was pondering a "self" keyword. If it could access theright reference at runtime you wouldn't need to worry about theexisting bindings.

"wherever" would likely still be the stack, except @_ is populated onlywith the elements after the invocant.

The little understanding I have of these matters suggests that argumentswill be passed via the stack no matter what and @_ is then "aliased"(SV* copy? Too lazy to check.) to the elements since the last pushmark.If there was a flag to start only after the first element and make thesp accessible via "self" by some mechanism, that might just do it.

I leave it to people who know the guts in detail to explain why thatis doomed to fail. :-)

Reini UrbanI'm completely with chromatic here. Maybe Zefram could help hooking into the lexer to make that patch work as module, but currently it's not possible. And suggesting the optree manipulation is not stable and also not clever. It would be good to have better optree manipulation methods, but they do not exist yet. Stuffing the core source is definitely easier, and for this case a new self or this keyword is definitely something we need in core sooner or later. We already have the modules. They

You should prototype this as a CPAN module, using the keyword hook.How do you use keyword hooks to add 'method' to the imports of feature.pm?It also seems very unwise for the core to take the keyword "method" atthis stage. We have several CPAN modules supplying "method" keywordswith various semantics, it's an unresolved area.To my knowledge, none of them import 'method' from feature.pm.As something to go in the core, I do not approve of this shortcut.You should definitely build the optree rather than stuff source.

That means:

* grabbing the optree *already generated* for the body of the sub* creating a new lexical $self binding in that optree* rummaging through every variable access in that entire optree to find $self,if it exists* rebinding those package globals to the lexical* building up the appropriate optree for 'my $self = shift';* splicing the new optree to the existing optree

I've done all of this before with B::Generate activated by a new :methodattribute on existing subs. It's fragile and unpleasant enough in Perl, andit's a lot of special-purpose code to stuff into perly.y.

The worst part is doing this all in a way that doesn't trip the strict pragma.I don't know how to do that.

Alternately, you could take the approach that doesn't add at least a fewhundred lines of new code to the parser for a special case. You could use asmuch existing code as possible (code that knows how to build an optree, codethat knows how to create lexicals, code that knows how to decide $self islexical, et cetera).

I'm completely with chromatic here.

Maybe Zefram could help hooking into the lexer to make that patch workas module,but currently it's not possible.And suggesting the optree manipulation is not stable and also not clever.It would be good to have better optree manipulation methods, but theydo not exist yet.

Stuffing the core source is definitely easier, and for this casea new self or this keyword is definitely something we need in coresooner or later. We already have the modules. They have no impact.core must lead.

Eric BrineIf you can write the following to define a class, no problem. use 5.016; use Something::Which::Provides::Method; If you have to write the following to define a class using another module, maybe "method" is not the best choice of keyword. use 5.016; no feature 'method'; use Something::Which::Provides::Method; * ... > Why can't the parser handle it when generating the optree in the first place? The parser knows that the block will be a method body before the block is parsed. - Eric

ZeframYou don't. But there's no reason for your particular version of "method" to be controlled by feature.pm. No. You add the pad entry *before* parsing the body. It's not as difficult as you make out. The code that you're referring to there doesn't just generate ops and pad entries, it also parses general Perl code, in which (for example) "shift" could mean all sorts of things. Using lex_stuff, your implementation is liable to be broken by local redefinition of a keyword that doesn't appear in the

chromatic wrote:How do you use keyword hooks to add 'method' to the imports of feature.pm?

You don't. But there's no reason for your particular version of "method"to be controlled by feature.pm.

* grabbing the optree *already generated* for the body of the sub

No. You add the pad entry *before* parsing the body. It's not asdifficult as you make out.

You could use asmuch existing code as possible (code that knows how to build an optree, codethat knows how to create lexicals, code that knows how to decide $self islexical, et cetera).

The code that you're referring to there doesn't just generate ops and padentries, it also parses general Perl code, in which (for example) "shift"could mean all sorts of things. Using lex_stuff, your implementationis liable to be broken by local redefinition of a keyword that doesn'tappear in the user's source. That's OK for a prototype, but not at allOK for a serious language feature.

ZeframReasonably sane implementation. Though I strongly suspect you could replace quite a bit of your added code with more reuse of existing code. I remain opposed to actually adding this to core. I don't see a justification for favouring this particular set of semantics for the "method" keyword over any of the other proposals; there's certainly no consensus yet about which version of it from CPAN is preferred. And of course it doesn't need to be in core to work. -zefram

chromatic wrote:but this swatch of optree building seems to do the trick.

Reasonably sane implementation. Though I strongly suspect you couldreplace quite a bit of your added code with more reuse of existing code.

I remain opposed to actually adding this to core. I don't see ajustification for favouring this particular set of semantics for the"method" keyword over any of the other proposals; there's certainlyno consensus yet about which version of it from CPAN is preferred.And of course it doesn't need to be in core to work.

Reasonably sane implementation. Though I strongly suspect you couldreplace quite a bit of your added code with more reuse of existing code.

I remain opposed to actually adding this to core. I don't see ajustification for favouring this particular set of semantics for the"method" keyword over any of the other proposals; there's certainlyno consensus yet about which version of it from CPAN is preferred.And of course it doesn't need to be in core to work.

ZeframNot of the currently-available ones, and I don't think we've yet got the facilities to design one that will stand the test of time. I want to see a proper signature system implemented, and then a round of designs for "method" built around that. *Then* we'll be in a position to start talking about blessing one. -zefram

Not of the currently-available ones, and I don't think we've yet got thefacilities to design one that will stand the test of time. I want tosee a proper signature system implemented, and then a round of designsfor "method" built around that. *Then* we'll be in a position to starttalking about blessing one.

Zefram wrote:Not of the currently-available ones, and I don't think we've yet got thefacilities to design one that will stand the test of time. I want tosee a proper signature system implemented, and then a round of designsfor "method" built around that.*Then* we'll be in a position to starttalking about blessing one.

Is there any reason method signatures (or attributes) wouldn't work ontop of this implementation?

ChromaticAttributes work, but the tokenizer deliberately rejects prototype syntax after a method keyword (given the uselessness of prototypes for methods). This implementation is certainly compatible with a general signature system added for both methods and subs. -- c

Is there any reason method signatures (or attributes) wouldn't work ontop of this implementation?

Attributes work, but the tokenizer deliberately rejects prototype syntax aftera method keyword (given the uselessness of prototypes for methods). Thisimplementation is certainly compatible with a general signature system addedfor both methods and subs.

David GoldenFWIW, I would be happy to see 'method' added without signatures. Or, put differently, I'd hate to see 'method' not happen because we're waiting for an officially sanctioned implementation of signatures. Since I'd want signatures for regular (non-method) subroutines, too, I'd prefer to see the two concepts separated so I can have my cake and eat it while waiting for the next cake to arrive. -- David

On Wed, Feb 2, 2011 at 6:23 PM, Zefram wrote:Not of the currently-available ones, and I don't think we've yet got thefacilities to design one that will stand the test of time. I want tosee a proper signature system implemented, and then a round of designsfor "method" built around that. *Then* we'll be in a position to starttalking about blessing one.

FWIW, I would be happy to see 'method' added without signatures. Or,put differently, I'd hate to see 'method' not happen because we'rewaiting for an officially sanctioned implementation of signatures.

Since I'd want signatures for regular (non-method) subroutines, too,I'd prefer to see the two concepts separated so I can have my cake andeat it while waiting for the next cake to arrive.

David E. WheelerThis seems entirely reasonable to me. I wouldn't mind seen a design spec for signatures, too, but that needn't hold up adding the method keyword any more than it would hold up the sub keyword. N'est pas? Best, David

FWIW, I would be happy to see 'method' added without signatures. Or,put differently, I'd hate to see 'method' not happen because we'rewaiting for an officially sanctioned implementation of signatures.

Since I'd want signatures for regular (non-method) subroutines, too,I'd prefer to see the two concepts separated so I can have my cake andeat it while waiting for the next cake to arrive.

This seems entirely reasonable to me. I wouldn't mind seen a design spec for signatures, too, but that needn't hold up adding the method keyword any more than it would hold up the sub keyword. N'est pas?

Sam VilainMooseX::Method::Signatures suffers from huge performance problems, precisely because it is *not* in core - it has to use PPI to parse the signatures. That sucks very very much. It also has to try and apply those signatures using very hairy code. There is absolutely zero way that these type constraints can be proved at compile time even when you declare variables' types so you pay a huge runtime penalty. A project I worked on had to back out some very elegant (IMHO) use of MXMS because it was

Reasonably sane implementation. Though I strongly suspect you couldreplace quite a bit of your added code with more reuse of existing code.

I remain opposed to actually adding this to core. I don't see ajustification for favouring this particular set of semantics for the"method" keyword over any of the other proposals; there's certainlyno consensus yet about which version of it from CPAN is preferred.And of course it doesn't need to be in core to work.

MooseX::Method::Signatures suffers from huge performance problems,precisely because it is *not* in core - it has to use PPI to parse thesignatures. That sucks very very much. It also has to try and applythose signatures using very hairy code. There is absolutely zero waythat these type constraints can be proved at compile time even when youdeclare variables' types so you pay a huge runtime penalty.

A project I worked on had to back out some very elegant (IMHO) use ofMXMS because it was simply too slow and had a huge number of dependencies.

Adding type constraints is supposed to help the computer execute thecode faster, not slower. This needs to be on Perl's long-term roadmap IMHO.

I think that we already have a great "preferred" approach for methodsignatures. All of the modules on CPAN that I have looked at simplychoose a subset of MXMS as a compromise position to be faster.

If declared well enough in advance, "use 5.014" implies "use feature'method'" is fair game IMHO. So long as there is a new API to accessthe parsed signature (yay, finally) and/or influence parsing (yuck) thenthe modules can adapt appropriately for the way forward.

On 2/2/2011 5:54 PM, Sam Vilain wrote:MooseX::Method::Signatures suffers from huge performance problems,precisely because it is *not* in core - it has to use PPI to parse thesignatures. That sucks very very much. It also has to try and applythose signatures using very hairy code. There is absolutely zero waythat these type constraints can be proved at compile time even when youdeclare variables' types so you pay a huge runtime penalty.

Indeed, these latter problems are why I like Method::Signatures (whichamounts to 'just' syntactic sugar), but not its MooseX sibling.

Sam VilainNot instantly, no - but it would be nice to be able to move towards a world where Perl is actually capable of skipping some run-time type checks because it already knows that they can't be violated. I'm not saying this is going to be easy! Sam

On 04/02/11 00:04, Zefram wrote:There is absolutely zero waythat these type constraints can be proved at compile time even when youdeclare variables' types so you pay a huge runtime penalty.

That wouldn't change if it were in the core.

Not instantly, no - but it would be nice to be able to move towards aworld where Perl is actually capable of skipping some run-time typechecks because it already knows that they can't be violated. I'm notsaying this is going to be easy!

Chris PratherConceptually this is is a subset of MooseX::Method::Signatures[1], Method::Signatures::Simple[2] Method::Signatures[3], Perl6::Subs[4], as well as similar in principle to selfvars[5], self[6], and Object::LocalVars[7]. What exactly are you looking for from a prototype that isn't provided in one of those seven (7!) modules? -Chris Note: I generated this list with a quick search for "self" and "method" on CPAN. Two of these modules I knew existed because various members of the Moose community use

On Thu, Jan 20, 2011 at 1:32 PM, Zefram wrote:You should prototype this as a CPAN module, using the keyword hook.

Conceptually this is is a subset of MooseX::Method::Signatures[1],Method::Signatures::Simple[2] Method::Signatures[3], Perl6::Subs[4],as well as similar in principle to selfvars[5], self[6], andObject::LocalVars[7].

What exactly are you looking for from a prototype that isn't providedin one of those seven (7!) modules?

-Chris

Note: I generated this list with a quick search for "self" and"method" on CPAN. Two of these modules I knew existed because variousmembers of the Moose community use them in production environments(specifically MooseX::Method::Signatures andMethod::Signatures::Simple). There may be other modules whichreplicate this behavior as well, I gave up when I found the two I knewabout ... and five more.