[P5P] Proposal: "$->" for implicit invocant

This alone would cause me to try to issue a veto. Perl5 has format.
Period. And I use it. A lot.

Already effectively available. It's spelled "$_->", as in

given(shift) {
$_->foo;
$_->bar;
}

-zefram

If 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 without a deprecation cycle) or
whatever else people dream up.

-- David

+1

-- Johan

This 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

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" at
this stage. We have several CPAN modules supplying "method" keywords
with various semantics, it's an unresolved area.

-zefram

Tie it to `use 5.14.0;` or, more likely, `use 5.16.0;`?

Oh, and the class keyword would be handy to have too, if we're gonna have `method`.

Best,

David

It's called "package".

package Foo 1.23 {
...
}

-- David

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 :method
attribute on existing subs. It's fragile and unpleasant enough in Perl, and
it'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 few
hundred lines of new code to the parser for a special case. You could use as
much existing code as possible (code that knows how to build an optree, code
that knows how to create lexicals, code that knows how to decide $self is
lexical, et cetera).

-- c

This 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. :-)

-- David

"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,
Steffen

I'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 have no impact.
core must lead.

If 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

You 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 user's source. That's OK for a prototype, but not at all
OK for a serious language feature.

-zefram

Okay, all of the explanations for how to do this are severely undocumented,
but this swatch of optree building seems to do the trick.

-- c

Reasonably 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

I'm curious to see how. My perusal of the documented interfaces yielded little
insight.

-- c

Do you have a favorite, Zefram?

Best,

David

Not 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

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

Attributes 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

FWIW, 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

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?

Best,

David

MooseX::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 simply too slow and had a huge number of dependencies.

Adding type constraints is supposed to help the computer execute the
code 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 method
signatures. All of the modules on CPAN that I have looked at simply
choose 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 access
the parsed signature (yay, finally) and/or influence parsing (yuck) then
the modules can adapt appropriately for the way forward.

Sam

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

That's going to get a lot better with the new parser callback interfaces
in 5.14. No more PPI, you can call into the real parser.
That wouldn't change if it were in the core.

-zefram

Not 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

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], 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 them in production environments
(specifically MooseX::Method::Signatures and
Method::Signatures::Simple). There may be other modules which
replicate this behavior as well, I gave up when I found the two I knew
about ... and five more.

[1]: http://search.cpan.org/dist/MooseX-Method-Signatures
[2]: http://search.cpan.org/dist/Method-Signatures-Simple
[3]: http://search.cpan.org/dist/Method-Signatures
[4]: http://search.cpan.org/dist/Perl6-Subs
[5]: http://search.cpan.org/dist/selfvars
[6]: http://search.cpan.org/dist/self
[7]: http://search.cpan.org/dist/Object-LocalVars