Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

[email protected]
> Nathan Wiger wrote:
> >
> > > This RFC proposes that operators in a list context should be applied
> > > element-wise to the elements of their arguments:
> > >
> > >   @d = @b * @c;   # Returns (2,8,18)
> > >
> > > If the lists are not of equal length, an error is raised.
> >
> > I've been watching this RFC for a while. I would hesitate to change the
> > default behavior of * and other operators in so radical a sense,
> > especially since it would create unexpected error conditions. I think
> > these operations should remain scalar.
>
> I disagree.

So do I.

<...>
> > The idea would be operator and data overloading is completely integrated
> > with tie, based on the concept of polymorphic objects. As such, you
> > could create native PDL classes that would allow @a * @b to do what you
> > want.

Not only do you lose consistency here (as Christian already pointed out),
but also speed. Array functions and operations would be tightly optimised
loops, and furthermore multiple operations would avoid redundant loops and
copies. Good luck finding a way of getting C<tie> to do this, RFC 200
notwithstanding.

> > Otherwise, you have to decide if @a * @b should be element-wise, a
> > cross-product, a vector, or ??? I just think it's a can of worms that's
> > going to result in a set of arbitrary decisions, which in the the end
> > makes less sense than having these contexts remain scalar by default.

No, there's no arbitrary decision. *Every* operator is component wise on
lists. It is internally consistent, and consistent with most other languages
that provide array/list operators. It's easy to get stuck on the '*'
example, because different mathematicians have different feelings about what
matrix operation should map to '*'. However, there is no consistant and
meaningful definition of array operations (for _all_ operators) other than
that defined in RFC 82.

This RFC is absolutely fundamental to providing numeric programming
capabilities in Perl 6, and it happens to make a lot of other stuff simpler
besides (e.g. the text processing examples in the RFC). It would improve the
speed and clarity of code, and Perl 5 scripts can be converted with a simple
C<scalar>. I can't really see the argument for not doing this.