In Apocalypse 2 Larry Wall wrote:
> RFC 082: Arrays: Apply operators element-wise in a list context
>
> APL, here we come... :-)
>
> This is by far the most difficult of these RFCs to decide, so I'm going
> to be doing a lot of thinking out loud here. This is research--or at
> least, a search. Please bear with me.
<snip>
> So the resolution of this is that the unmarked forms of operators will
> force scalar context as they do in Perl 5, and we'll need a special
> marker that says an operator is to be auto-iterated. That special
> marker turns out to be an uparrow, with a tip o' the hat to
> higher-order functions. That is, the hyper-operator:
>
>
> @a ^* @b
Excuse me, but *bletch*, - this is as ugly as sin. Especially when we
get into
complex formulae. Imagine:
@solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
(or would it be ^sqrt() ?) - This looks like sendmail :-)
What is wrong with using @a * @b - the only reason I can think is to
preserve
a backward compatibility which is not needed? perl6 is supposed to prefer
improvement over backward compatibility. The last thing we need is yet
more
line noise in perl6. This is a pity because in many ways perl6 changes
all look
rather attractive to me (e.g. consistent sigils, use of . vs ->, no need
to make PDL
arrays any different from perl arrays).
Why do we need to preserve @x as array length when you are proposing
@x.length ?
As instigator of PDL, I am very concerned. Clearly inbuilt vectorization
and compact
arrays in perl6 will make PDL obsolete. I have no problem with that. A
sign of
success to get in the core. :-) What I do have a problem with is
replacing it with a
construct this ugly.
If I was forced to write vector code like this I *WILL* give up on perl,
and resort to Numerical
Python or IDL instead.
appalled,
Karl Glazebrook
