> > This RFC proposes a builtin C<reduce> function, modelled after
> > Graham Barr's C<reduce> subroutine from builtin.pm
>
> Please refer to List::Util rather than builtin.pm
Noted. Thanks.
> the module name was changed as many did not like the name builting,
> as it was not.
Bah. I liked it -- I always thought of it as "proactive nominative
determinism" ;-)
> > In all cases, the elements of the list are lazily evaluated. That is,
> > any element of the list that is not a literal value is only evaluated
> > when that element is passed to (and actually used by) the reduction
> > subroutine.
>
> Should lists be lazy by default ? I would suggest that is a separate
> language issue then reduce and reduce should follow what all other
> list operators do.
The difference is that I propose that C<reduce> be able to short-circuit.
Other list operators don't, and the proposal they they be allowed to seems
to have drowned in its own complexities :-(
Perhaps I'll remove that bit and leave it in the hands of the Master Designer.
> > If the original list has no elements, C<reduce> immediately throws an
> > exception.
>
> What do you mean by exception, die ?
Yes.
> No other builtin dies like that at
> runtime. Perhaps a return of undef would be more like other operators.
That was my original proposal, but it was howled down by the
mathematical elite, who vigorously insisted that it would break the
fundamental mathematical properties of the entire Cosmos, leading to
catastrophic rifts in the timespace continuum. Or something like that.
Eventually, I gave in.
> > If the original list has a single element, that element is
> > immediately returned (without ever calling the reduction subroutine).
> > Otherwise, in a scalar context, the result of the final reduction call
> > is the result returned by C<reduce>. In a list context, a list of all
> > the interim values, plus the final value, would be returned.
>
> Um, if it is returning a list then it is not reducing, is it ?
Sure it is: cumulatively.
> > If the reduction subroutine is ever terminated by a call to C<last>, the
> > enclosing C<reduce> immediately returns the last reduction value -- or
> > list of partial values -- to that point. If the C<last> occurs during
> > the first reduction, an exception is thrown.
>
> Again, no other builting currently throws an exception. If throwing
> an exception is to become the norm then that should be a separate
> RFC suggesting that builtins throw exceptions, but reduce should do
> what others do.
Even at the risk of Destroying the Entire Universe???
What do others think?
Damian
