Anyway, if I change it to:print reduce { $a + $b } 1,2,3;
I get:print reduce{ print "a = $a, b = $b\n"; eval "$a + $b" } 1,2,3,4;
a = 1, b = 2 Use of uninitialized value in concatenation (.) or string at 1 line 4. a = , b = 3 Use of uninitialized value in concatenation (.) or string at 1 line 4. Use of uninitialized value in concatenation (.) or string at 1 line 4. a = , b = 4 Use of uninitialized value in concatenation (.) or string at 1 line 4. 4which explains the 3 that you're seeing. Apparently the eval is returning undef.
No further ideas, I'm afraid. Hmmm... maybe an optimalization that's over optimizing?
Liz
Update
Mine was with the 20581 snapshot (5.8.1-RC5 to be, List::Util 1.11)
Update:
Graham Barr wrote on p5p on August 14, 2003:
This is close, but not right as it will result in $a being modified when the sub returns. Later today I will release 1.12 with a fix for this.while referring to List::Util.
In reply to Re: An anomaly with List::Util::reduce and/or eval?
by liz
in thread An anomaly with List::Util::reduce and/or eval?
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |