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

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

Thread Previous
From:
Stephen McCamant
Date:
March 2, 2003 10:58
Subject:
Re: PROPOSAL: my $x if $false; and lexical initialisation
Message ID:
15970.21554.201497.554632@syllepsis.MIT.EDU
>>>>> "DM" == Dave Mitchell <davem@fdgroup.com> writes:

DM> Another option would be to insert an OP_STARTMY after each nextstate
DM> that preceeeded a my declaration ???
 
DM> On Sat, Mar 01, 2003 at 04:29:26PM -0800, Gurusamy Sarathy wrote:

GS> Seems kludgey for the cases where there is no nextstate preceding
GS> the padsv.

DM> ....

GS> Another way to approach it is to separate out the OP_PAD?V ops
GS> and move them to execute at the beginning of the statement, sort
GS> of as a preamble.  This means transforming:

GS> my ($x, $y) = ("xxx") if $z;

GS> into the approximate equivalent of:

GS> my ($x, $y), (($x, $y) = ("xxx") if $z);


DM> Don't both these two approaches have roughly the same effect - ie
DM> they are both migrating the 'intro' actions to the start of the
DM> statement containing the my?

Yes. It sounds to me like you and Sarathy are in violent agreement, on
what I agree is the best solution.

DM> Although presumably your approach involves manipulating the parser
DM> while mine involves the peephole optimiser?

Presumably you wouldn't be changing the grammar of the parser
(perly.y), just the routines in op.c that build the OP tree. (Because
perl is mainly one-pass, the distinction between the parser, semantic
analysis, and optimization is fuzzy). In particular, I'd guess you
could add the introduction OPs in newSTATEOP(), and null out
void-context PADSVs in scalarvoid() (where there's already a check
that warns "useless use of my variable in void context" when a
variable isn't being introduced). Removing useless the now-useless OPs
should probably happen in peep() in any case.

Three short notes:

* I think the check for "op_flags & OPf_MOD" in pp_padsv was just
  added to group the two different flags checks so that only one was
  needed in the common case of no flags; when the two checks are
  separated, you shouldn't need it.

* Even if you're no longer going to check OPpLVAL_INTRO in pp_padsv,
  it would make B::Deparse's life easier if you left it (or
  potentially some other flag) turned on, so that

  my($x, $y) = @_;

  and

  my($x, $y); ($x, $y) = @_;

  are still easily distinguishable.

* As a name for the new OP, I'd suggest "OP_PADINTRO". But I think if
  you're writing the code, you ultimately get to pick. :-)

 -- Stephen

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About