develooper Front page | perl.perl5.porters | Postings from March 2003

Re: PROPOSAL: my $x if $false; and lexical initialisation

Thread Previous | Thread Next
Gurusamy Sarathy
March 1, 2003 11:20
Re: PROPOSAL: my $x if $false; and lexical initialisation
Message ID:
On Sat, 01 Mar 2003 18:27:14 GMT, Dave Mitchell wrote:
>My proposal is to move all the SAVECLEARSV() calls from the pad* ops
>to the nearest preceeding cop, ie nextstate or dbstate.
>I believe this will remove the bug and may also make things faster.
>I have written some cobbled-together proof-of-concept test code, the
>patch for which I include below.
>The idea is that when peep() sees a pad* op, it removes the OPpLVAL_INTRO
>flag from the pad op, and appends the op's target index to a list
>stored in the last COP seen by peep().
>1) Is this idea sound in principle, or am I overlooking some semantics
>that could do nasty things? (my trial patch passes all tests except for
>Storable and some B::*'s, which gives me some hope... :-)

I'm not sure nextstate is the best place for this.  Since this is
only needed once per scope, checking for it once-per-statement
seems like wasted cycles.

Why not do it in the OP_LEAVE* ops?  Or perhaps even introduce
a new OP_LEAVEMY that only fires if there are lexicals that
need to be finalized in that scope.

>2) Is the best place to do this in peep()?

Probably.  A cleaner option might be to just maintain a global
accumulator of lexicals that have been introduced, and then
create the OP_LEAVEMY op in block_end() or maybe in pad_leavemy().

>3) What's the best way to store a list of integers in a COP? I'm assuming
>I'll add an int* pointer and len to the struct cop, then malloc (and if
>necessary grow) an int array.

How about an SV with with its PVX holding this array?

Bloating every COP for this purpose seems overkill, though.

>4) How can the unneeded pad* ops be optimised away for a bare 'my $x;' or
>'my (...);', since they are not needed if they're not part of an
>Even better, how would I optimise away both the padsv ops and the
>intervening nextstate op in 'my $x; my $y;' ?

peep() seems like the right place for this.  If the OP_PAD*V is in
a void context, just null() it out along with any OP_NEXTSTATE that

>5) Since peep() sometimes sets PL_curcop to point to ops that have been
>optimised away, I found I needed a separate global var that gets updated
>by peep() similar to PL_curcop, but which doesn't get updated for null-ed
>cops. is there a better way of doing this?

Moving away from COPs might take care of this. :)

>6) What is the average air-speed velocity of a swallow?

More or less that of the air-speed of its falling poop.  Poops,
did I say poop?  I meant peep.


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