develooper Front page | perl.perl5.porters | Postings from December 2021

Re: "no snails"; or having signatured subs complain about @_

Thread Previous | Thread Next
Paul "LeoNerd" Evans
December 6, 2021 15:48
Re: "no snails"; or having signatured subs complain about @_
Message ID:
On Sun, 5 Dec 2021 20:39:04 +0000
Nicholas Clark <> 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      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About