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

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]

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

Replies are listed 'Best First'.
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
Actually, the first 3 examples work exactly how the simple model I offered in my previous posts would expect them to. Perhaps, but they don't all behave according to the documentation which say each of the loop pairs I provided should behave the same. Thus the deviation from the documentation is Perl being "confused". However, I must concur that it's very predictable confusion. But I can see why "Don't do it" is the better answer. There are way less obscure ways to structure the code this optimisation enables. Stack and queues are by far the most common usage of modifying an array being processed, and both are quite clear and concise without foreach. `while (@todo) { my $item = pop(@todo); ... push @todo, ...; ... }` [download] `while (@todo) { my $item = shift(@todo); ... push @todo, ...; ... }` [download]	[reply] [d/l] [select]