Front page | perl.perl6.language.data |
Postings from September 2000
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. ;-) -NateThread Previous | Thread Next