Front page | perl.perl5.porters |
Postings from December 2021
On Mon, Nov 29, 2021 at 04:08:54PM +0000, Paul "LeoNerd" Evans wrote:
> The final part of the "signatures" feature still to be implemented, is
> getting rid of the @_ setup as part of OP_ENTERSUB when entering a
> signature'd sub, for the speed benefit it gives. I've been thinking
> about how to implement this.
Sorry I know I've been AWOL, but I have both: designs, and ideas for how
to implement it.
TL;DR: we need to agree what minimal changes we need for 5.36.0 to allow
it to move out of experimental mode (not necessarily moving out in 5.36.0,
but setting the foundations for moving it out in 2 releases time). If
agreement is reached, I'm likely to have enough enthusiasm to do the
implementation work.
My original proposals can be found in the thread
Jumbo Signatures extensions discussion
http://nntp.perl.org/group/perl.perl5.porters/256677
and more specifically in the subthreads:
@_ Suppression
http://nntp.perl.org/group/perl.perl5.porters/256681
Query Parameters
http://nntp.perl.org/group/perl.perl5.porters/256680
But it boils down to:
1) subs compiled within the scope of 'use signatures' don't get @_
populated: @ is still the @_ of the caller. There is no separate pragma or
other switch to allow this to be dis/enabled on a per-sub basis: if it's
a signature sub, it doesn't get @_, full stop. Otherwise we'd have to have
two code paths, two sets of tests etc for everything.
2) Within the lexical scope of a signature sub (but not in the scope of
e.g. nested signature-less anon subs etc), use of @_ and $_[X] is a
compile-time warning. This should catch most coder errors associated with
converting existing subs to use signatures.
If someone needs to populate @_ (e.g. for tail call recursion) it can be
done as, e.g. :
{
no warnings 'snails'; # or whatever the real warning name is
local *_ = [ qw(my new args) ];
goto &foo;
}
3) In the short term, if people still need access to @_, they can always
stick with using a traditional sub for now. In the longer term, my
proposal included mechanisms for specifying that a parameter is an alias,
so e.g.
sub inc (*$x) { $x++ }
works. My proposal also included 'query parameters', which declare a
parameter (i.e. a lexical var) but don't consume an argument - instead the
var is set to some value indicating the current state of argument
processing. Two query parameter types particularly relevant here are:
(??$has_a, $a) # $has_a is set to true if there's an argument for $a
(?*@args, ...) # the lexical var @args behaves just like the old @_
# i.e. whose elements are aliases of the passed
# arguments
4) In terms of implementation, the only logic that should go in
pp_entersub() is checking a flag on the CV to see if it's a signatured
sub. If so, it uses a pre-existing code path - the '&foo;' call mechanism.
All the other logic should go in the sub itself - initially just as extra
code in the OP_ARG* ops; later additions will add extra ops, and sometime
after the sig implementation is complete, the optimiser will convert a
suitable series of OP_ARG* ops into a single OP_SIGNATURE op which
processes all args.
--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.
Thread Previous
|
Thread Next