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

Re: getting signatures out of experimental

Thread Previous | Thread Next
Nicholas Clark
December 5, 2021 19:52
Re: getting signatures out of experimental
Message ID:
On Mon, Nov 29, 2021 at 04:51:31PM +0000, Paul "LeoNerd" Evans wrote:
> On Mon, 22 Nov 2021 09:58:18 -0500
> "Ricardo Signes" <> wrote:
> > Have we ever discussed how these would be meant to work inside
> > signatures?  There's an argument to be made that it could return the
> > list of targets to which the arguments were assigned
> That information isn't stored anywhere. It is emergent in the pad
> targets of the OP_ARGELEM ops at the beginning of the sub:

[I don't think that this matters ...]

> @DB::args was simple because all it has to do is alias itself to the @_
> AV of the called target; which for those was stored at pad index 0 of
> the topmost pad in the padlist - an easy and reliable one to find. No
> such array would exist for signatured subs in a "no snails" world.

Dave comments on @DB::args

     No, if anything it would make it better. If @_ is no longer being
     populated, then the original args would instead be left on the stack
     (so that pp_signature or whatever have access to them), so pp_caller
     would have access to the original unadulterated call args.

and I'd roughly reach the same conclusion before I re-read that message:

I don't know if it needs to (change).

The *call* side of a function or method (which happens to have a signature)
doesn't change - it's still a flat list of arguments on the perl stack.

A function call is effectively (just another) list operator.

I admit to not being familiar with much of the complexity of pp_entersub.
I had assumed that the arguments were left on the stack (as well as being
copied to @_) but I think from Dave's comment above, I'm wrong. I infer
that they are (currently, always) cleared (because the stack pointer is

So, if instead, pp_entersub does exactly one of

legacy:     set up @_, reset the stack pointer
signatures: leave the arguments on the stack

then if pp_caller is setting up @DB::args, then it needs some new code to
handle the second case, and possibly we might need to store some more state

Remember, pp_caller doesn't need to be fast. (pp_entersub does)

Sideways from this, two other things

Firstly, the exact *fast* *frugal* implementation doesn't need to be
written "this week" (or before v5.36.0 ships). What matters is that we
have enough of a plan for it that we know the knock-on effects on the
language semantics, and what we need to forbid.

If *all* we do immediately is change the third line in pp_entersub:

    defavp = &GvAV(PL_defgv);
    cx->blk_sub.savearray = *defavp;
    *defavp = MUTABLE_AV(SvREFCNT_inc_simple_NN(av));

to instead be

    *defavp = MUTABLE_AV(SvREFCNT_inc_simple_NN(PL_av_that_goes_boom));

for a sub using signatures, then maybe that's good enough to enforce our
language semantics for this release. With the optimised implementation for
the next release. (Or any time we're not feeling pressured by a deadline -
You rush a miracle man, you get rotten miracles)

Secondly, if there needs to be a way to *introspect* how that flat list of
arguments in the caller got mapped to parameters within the function or
method, it should be a new thing, and not part of caller. But does even it
need to exist?

Signatures, effectively, are just a very terse way to write preamble regular
Perl code at the start of a function. I guess that the only thing that you
can't do here is set a breakpoint within the signature so that the debugger
can single-step the signature code. Maybe that's enough to be useful?

Nicholas Clark

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