develooper Front page | perl.perl5.porters | Postings from April 2001

for(;;) loops and compiler backends

From:
Robin Houston
Date:
April 26, 2001 12:49
Subject:
for(;;) loops and compiler backends
Message ID:
20010426204911.A28298@puffinry.freeserve.co.uk
One of the remaining bugs in B::Deparse happens with for(;;) loops.
Consider this code:

  for(my $x=1; $x<10; ++$x) {print $x}

The compiled form of that, in B::Concise language, is like this:

...
1g    <;> nextstate(main 9 -e:1) v ->1h
1j    <2> sassign vKS/2 ->1k
1h       <$> const(IV 1) s ->1i
1i       <0> padsv[$x:7,9] sRM*/LVINTRO ->1j
-     <@> lineseq vK ->1y
1k       <;> nextstate(main 9 -e:1) v ->1l
1x       <2> leaveloop vK/2 ->1y
1l          <{> enterloop(next->1p last->1x redo->1m) v ->1t
...

and B::Deparse currently produces the following:

  my $x = 1;
  for (; $x < 10; ++$x) {
      print $x;
  };

Yes, it's another scoping problem. The scope of the lexical
variable ought not to extend beyond the loop.

However, B::Deparse (and presumably any compiler backend)
has a bit of a problem here. By the time the loop is seen,
the previous statement has already been processed. And
short of either looking ahead arbitrarily far, or else
doing some very tricky magic with the lexical scope
indicators, it's difficult to avoid.

My proposal is that we set OPf_SPECIAL for the nextstate
COP 1g above and its ilk. OPf_SPECIAL currently has no
meaning for COPs as far as I can tell. Then this situation
could easily be detected.

I don't think this is too radical. Several of the flags which
are set at compile time are not inspected by the runtime,
but it's nice to have them there, and it can simplify debugging. 

Anyway, is there any strenous objection to this proposal? It
would mean a one-line change to perly.y, and an extra comment
in op.h. That's all, I think.

 .robin.



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