Jeremy Howard wrote:
>
> 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.
Right, well tie as currently implemented would be unusable for this. But
I have my eyes on trying to get it to work out better.
> 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.
I'm actually not strongly against this RFC. What I was trying to convey
is consistency concerns - which this RFC does address somewhat, granted
- but which are #1 on my mind always. The language should look and act
consistently, without having to RTFM to understand why "@a + @b" doesn't
work like "@a * @b" or "@a || @b".
The only thing that *really* makes me nervous about the RFC is this
part:
> > @d = @b * @c; # Returns (2,8,18)
> >
> > If the lists are not of equal length, an error is raised.
I really don't like the "error is raised" part, at least not by default.
Maybe "use strict 'ops'" could turn this on. I think by default arrays
should DWIM in this context, whether it be auto-padding with undef's,
1's, or whatever we decide. I'd prefer:
@a = qw(1 2 3);
@b = qw(4 5);
@c = @a + @b; # @c = (5, 7, 3)
But that's just my($.02), and I'm not a PDL'er, so feel free to point
out if this is bad. ;-)
-Nate
