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