Bart Lateur wrote:
> If you're talking about matrix manipulations, I should immediately hold
> you back. Perl arrays are pretty bad as is for representing matrices.
> Don't let anybody tell you otherwise: Perl data structures are
> one-dimensionaly by nature.
>
A lazily evaluated slicing operator would make arrays look like matrices and
tensors (an RFC for this should be appearing RSN). Of course this would have
to be implemented efficiently by Perl, which Dan has already talked about
doing.
> For vector manipulation, I can understand that, *in principle*, but not
> really. I remember that a few functional language extensions have been
> proposed, including "apply a function (code block) to each combination
> of item i from the first list with item i of the second list, for each
> i". You can easily roll your own. It will do what you want, not what the
> implementors thought useful. For example: vector multiplication. What
> will @foo*@bar do? Will it return the scalar product
> (abs(@foo)*abs(@bar)*cos(angle), the vector product (returning a vector
> orthogonal to both others), or a matrix multiplication? If you roll your
> own, you can choose.
>
It should provide a component-wise multiplication by default. This would
provide consistency amongst all operators applied to a list in list context
(and many functions could provide this behaviour too--like chomp(), as Bryan
Warnock mentioned earlier).
Of course, if the user wants to overload this behaviour, we should let them.
In the multiplication example, however, I would have thought that 'x' is a
more suitable inner product operator...
