Re: How foreach loops decide what to iterate through (push array inside foreach)

I notice that the following code runs forever:

Adding a print inside the loop might shine some light on it:

foreach (@a) { push @a, 1; print scalar @a, "\n" }
[download]

Prints:

2
3
4
5
...
[download]

Apparently, the push causes the array to grow by one element, somehow triggering the loop to iterate again.

I found this in the docs for Foreach Loops:

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.

Now I am curious as to what perl is doing internally. Can any monks offer a deeper explanation?

Comment on Re: How foreach loops decide what to iterate through (push array inside foreach) Select or Download Code

Replies are listed 'Best First'.
Re^2: How foreach loops decide what to iterate through (push array inside foreach) by ikegami (Patriarch) on Feb 14, 2009 at 03:14 UTC
Now I am curious as to what perl is doing internally. Can any monks offer a deeper explanation? I think it iterates over the array instead of putting it on the stack. You can circumvent the optimisation by changing `for (@a)` to `for ((),@a)`.	[reply] [d/l] [select]
Re^2: How foreach loops decide what to iterate through (push array inside foreach) by jethro (Monsignor) on Feb 14, 2009 at 03:33 UTC
I don't know, but my guess is that perl simply keeps a pointer to the array-element it is at in the loop. I did a few tests with splice and perl did exactly what I expected from it. It looped over the array positions (!! not the array values) until it was outside the array length (because of looping or a shrinking of the array). Would be nice if someone could show me a case where perl gets confused. I could not create one	[reply]
Re^3: How foreach loops decide what to iterate through (push array inside foreach) by ikegami (Patriarch) on Feb 14, 2009 at 03:51 UTC
Would be nice if someone could show me a case where perl gets confused. I could not create one Confused by addition: `>perl -wle"@a=1; for ((),@a) { push @a,$_+1; print }" 1 >perl -wle"@a=1; for (@a) { push @a,$_+1; print }" 1 2 3 4 ...` [download] Confused by deletion: `>perl -wle"@a=(1,2); for (@a) { pop @a; print qq{<$_>} }" <1> >perl -wle"@a=(1,2); for ((),@a) { pop @a; print qq{<$_>} }" <1> Use of freed value in iteration at -e line 1.` [download]	[reply] [d/l] [select]
Re^4: How foreach loops decide what to iterate through (push array inside foreach) by jethro (Monsignor) on Feb 14, 2009 at 05:25 UTC
Actually, the first 3 examples work exactly how the simple model I offered in my previous posts would expect them to. In the first case the concatenation with () creates a new list to loop over so that the addition to @a has no consequences while the second case adds to @a keeping the end out of reach like a carrot on a stick dangling before the horse. Same for the third case. After the second value was poped from the array, the loop naturally was finished early. But the fourth case shows the problem. Seems the values of the "anonymous array" are aliased to the real values and have a problem when that value isn't there anymore. But I can see why "Don't do it" is the better answer. Otherwise too much of the internas would spill out into the language design.	[reply]
Re^5: How foreach loops decide what to iterate through (push array inside foreach) by ikegami (Patriarch) on Feb 14, 2009 at 05:37 UTC