From Dominus's blog:

Perl: modifying an array in a loop

Another example is the question of what happens when you modify an array inside a loop over the array, as with:

  @a = (1..3);
  for (@a) {
    print;
    push @a, $_ + 3 if $_ % 2 == 1;
  }
[download]

(This prints 12346.) The internals are simple, and the semantics are well-defined by the implementation, and straightforward, but the manual has the heebie-jeebies about it, and most of the Perl community is extremely superstitious about this, claiming that it is "entirely unpredictable". I would like to support this with a quotation from the manual, but I can't find it in the enormous and disorganized mass that is the Perl documentation.

Addendum: Tom Boutell found it. The perlsyn page says "If any part of LIST is an array, foreach will get very confused if you add or remove elements within the loop body, for example with splice. So don't do that."

The behavior, for the record, is quite straightforward: On the first iteration, the loop processes the first element in the array. On the second iteration, the loop processes the second element in the array, whatever that element is at the time the second iteration starts, whether or not that was the second element before. On the third iteration, the loop processes the third element in the array, whatever it is at that moment. And so the loop continues, terminating the first time it is called upon to process an element that is past the end of the array. We might imagine the following pseudocode:

        index = 0;     
        while (index < array.length()) {
          process element array[index];
          index += 1;
        }
[download]

There is nothing subtle or difficult about this, and claims that the behavior is "entirely unpredictable" are probably superstitious confessions of ignorance and fear.

IMHO it is foolish to rely on undocumented behaviour, even if it works with the current perl version. There's no guarantee that future implementations will do it the same way. Future implementations might implement a more iterator-like approach (for example to remove the memory panelty that for (<filehandle>){...} involves, or for other reasons).

If somebody relies on the current behaviour, sending a doc patch to p5p is the thing to do. Once that doc patch is in a stable version of perl, you can rely on it.

I would strongly advise against such constructs. Even though it may work in this particular case, it may stop to do so, if something happens to change in some subtle way...  The fact that it works here presumably relies on an optimisation to not flatten the array into a list, so the foreach loop is operating on the original array, not a copy aliases of its elements. IOW, it's implementation dependent... Try adding an empty list () before the array, and you'll see the effect:

my @a = (1,2,3);
my $c = $a[-1];

#for (@a) {      # prints 1..10
for ((), @a) {   # prints 1..3
    push @a, ++$c if $c < 10;
    print "$_\n";
}
[download]

Update: changed 'copy' into 'aliases', as this better reflects what's going on:

...
for ((), @a) {
    push @a, ++$c if $c < 10;
    $_ *= 2;      # modify aliased elements
    print "$_\n";
}

use Data::Dumper;
print Dumper \@a;

__END__
2
4
6
$VAR1 = [
          2,
          4,
          6,
          4,
          5,
          6
        ];
[download]

it is guaranteed that we won't go to infinite recursion due to include files indirectly included into themselves

I must be missing something here. In the following case we do have an infinite loop:

1. @ctOutput = ('include weird.1');
2. file 'weird.1' contains include weird.2
3. file 'weird.2' contains include weird.1

How come it is guaranteed infinite recursion will not happen?

I assume the "in this particular case" was meant to indicate that the data has no such recursive references, not that the code would avoid infinite recursion.
--
Online Fortune Cookie Search