To summarise what I think everyone is saying, []-reducing an empty list yields either:
1) undef (which may or may not contain an exception), or 2) some unit/identity value that is a trait of the operator,
depending on whether or not people think (2) is actually a good idea.
The usual none(@Larry) disclaimer applies, of course...
Well the only case where it probably really matters is [+] where you really want the result to be 0. Of course +undef == 0, so maybe returning undef might be okay. I'm thinking about the case:
[+] grep &some_condition, @a
where you really want the total to be 0, even if the result of the grep is empty.
A case can also be made for (assuming @a = ();) that
[EMAIL PROTECTED] == 1 [EMAIL PROTECTED] eq '' (also covered by ~undef) [?&[EMAIL PROTECTED] ~~ true [?|[EMAIL PROTECTED] ~~ false (also covered by ?undef) [EMAIL PROTECTED] ~~ false (also covered by ?undef) [+&[EMAIL PROTECTED] == MAXINT (whatever that is) [+|[EMAIL PROTECTED] == 0 (also covered by +undef) [EMAIL PROTECTED] == 0 (also covered by +undef)
chained ops are wierd
[<[EMAIL PROTECTED] ~~ false [>[EMAIL PROTECTED] ~~ false [<[EMAIL PROTECTED] ~~ true [>[EMAIL PROTECTED] ~~ true
Other ops have theoritical values that I don't know if we can handle:
[~&[EMAIL PROTECTED] should be an infinitely long bitstring of 1's [~|[EMAIL PROTECTED] should be an infinitely long bitstring of 0's
Again, given that that the really important case [+] is covered by +undef == 0, maybe just always returning undef is good enough.
-- [EMAIL PROTECTED] [EMAIL PROTECTED]
