On Wed, 09 Aug 2000 09:41:22 -0400, Dan Sugalski wrote:
>> >> @foo = @bar * 12;
>> @foo = map { $_ * 12 } @bar;
>>I don't see the need for a new notation.
>
>Well, compactness for one. With a scalar on one side it's less odd (it was
>a bad example). When funkier, though:
>
> @foo = @bar * @baz;
>
>the expansion becomes less obvious and quite a bit larger, especially if
>the arrays are multidimensional.
(Isn't this becoming a "language" issue? -language CC'ed.)
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.
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.
No, I am more in favor of solid yet flexible overloading mechanism, so
that you can use the appropriate module, which does the multiplication
of your choice, and which still allows you to use something like the
above notation. $foo and $bar will then be (vector or matrix) objects,
instead of plain Perl arrays. Much like BigInt now.
--
Bart.
