Damian Conway wrote:
> > 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.
>
Couldn't reduce return a list just through concatenating its elements? For
instance:
@a = (1,3,2,4,3,6,4,8);
@sum = reduce( (^total, ^x+^y ), @a ); # (4,6,9,12)
I'm not necessarily saying this is the best way, mind you. We've got two
options here:
1- Build the concept of multidimensionality into Perl's proposed arrays
2- Make Perl support only 1d arrays
The benefit of (1) is that we can build the syntax directly to allow
reduction over dimensions, transposition, and so forth. The downside is that
we have to work out a lot more of these details up front.
The benefit of (2) is that we achieve the same thing through fewer language
additions. A rich set of functions for slicing, indirection, partitioning,
and interleaving arrays would allow pure Perl to be used to define
multidimensional behaviour. The downside is that the compiler (and run-time
optimisations) would have to be _extremely_ smart to optimise out all this
indirection when it's actually used.
We probably need to get some feedback from the internals team here--how much
optimisation is possible would impact what notation is suggested, I think.
Or should we propose the full multi-dimensional notation and just let the
internals team implement it in pure Perl if they think that's best?
