Front page | perl.perl5.porters |
Postings from December 2021
On Sun, 5 Dec 2021 20:39:04 +0000
Nicholas Clark <nick@ccl4.org> wrote:
> I think that (2), (3) and (5) are all possible if pp_entersub
> operates in two modes:
>
> legacy: set up @_, reset the stack pointer
> signatures: leave the arguments on the stack
>
>
> and we make sure that we store enough state that OP_ARGCHECK,
> OP_ARGLEN and OP_CALLER all know where to look (and how many items to
> look for)
...
> instead having GvAV(PL_defgv) pointing to a tied array singleton that
> is built to croak.
>
>
> and we change OP_ARGCHECK, OP_ARGLEN and OP_CALLER to look at
> PAD_SVl(0) instead of GvAV(PL_defgv) to find the (hidden) @_
Ahhhh - that's a fun idea. Simply poison the uses of real @_ but have
the signatures-related arg opcodes all look in pad slot 0. It doesn't
buy us much-if-anything performance wise but it does allow detection
and complaint of @_-using code (even implicit in things like `shift()`)
while still letting signatures work.
Though having done that I don't think we'd even need to leave argument
values on the stack; they can just be moved into the AV referred to by
pad slot 0, much as the code does now. The only thing we do is no
longer point GvAV(PL_defgv) at it.
Plus it permits a very simple implementation of `builtin::argc` by just
av_count of the AV in pad slot 0.
In fact we could possibly even go a slight step further in peepholing
and still permitting uses of @_ as a scalar; thus in e.g.
return unless @_ > 1;
that would get compiled into some new OP_ARGCOUNT op instead of
OP_RV2AV{OP_GV(PL_defgv)} with OPf_SCALAR.
I could see this working...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next