Stuart Cook wrote: > 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 [*}@a == 1 [~]@a eq '' (also covered by ~undef) [?&]@a ~~ true [?|]@a ~~ false (also covered by ?undef) [?^]@a ~~ false (also covered by ?undef) [+&]@a == MAXINT (whatever that is) [+|]@a == 0 (also covered by +undef) [+^]@a == 0 (also covered by +undef) chained ops are wierd [<]@a ~~ false [>]@a ~~ false [<=]@a ~~ true [>=]@a ~~ true Other ops have theoritical values that I don't know if we can handle: [~&]@a should be an infinitely long bitstring of 1's [~|]@a 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. -- mark@biggar.org mark.a.biggar@comcast.netThread Previous | Thread Next