> I don't see it.
>
> 1 == f((reduce +, undef), 1) == reduce +, undef, 1
undef isn't an empty list, it's a one element list.
Consider the other "common" reduction:
sub f { $_[0] * $_[1] }
Now:
f((reduce \&f, ()), 1) == 0 # f(undef,1) -> f(0,1) -> 0
But
reduce \&f, (), 1 == 1 # list flattens to (1),
# single element immediately returned
> I really would like to be able to pass around an empty list and get
> a _reasonable_ answer. Having to check the list for emptyness before
> passing it in just seems dirty. One doesn't have to do this for anyother
> looping operator in the language.
>
> for (@empty) {}
> grep {} @empty
> map {} @empty
None of which *combines* its (possibly non-existent) values together.
> AS> Also, the RFC should specify that the function is always evaluated in
> AS> a scalar context (for things to make sense).
>
> Why? reduce should be able to reduce a set of matrices to a matrix. Or
> actually any aggregate (plural whatzit).
>
> I think this is too limiting.
>
> Depending upon the context reduce should return undef, an empty list,
> or other empty plural whatzit.
Hmmmm. I need to see more debate on this before I decide what to propose
in the next version of the RFC.
Damian
