develooper Front page | perl.perl6.language | Postings from January 2004

Re: Semantics of vector operations

Thread Previous | Thread Next
Scott Walters
January 29, 2004 21:33
Re: Semantics of vector operations
Message ID:
On  0, Rod Adams <> wrote:
> Also, isn't it a pain to type all these characters when they are not on 
> your keyboard? As a predominately Win2k/XP user in the US, I see all 
> these glyphs just fine,but having to remember Alt+0171 for a « is going 
> to get old fast... I much sooner go ahead and write E<raquo> and be done 
> with it.
> Thoughts?
> -- Rod

Agreed. Cryptic, but in a different way than usual. I'd rather see 
plain old keywords as long as I'm typing things out or making that
many key-strokes. 

  sub each (*);

  each @arr += 3;

  each @arr += each @foo;

Larry Wall suggested reading >> and << as "each". 

This would require a small comprimise on the p5 each. Or else it could be 
named "vector". Shouldn't be a problem with %hash.keys, %hash.values, 
%hash.each anyway.

This wouldn't implement as an operator very well, admittedly, but more like
a control keyword. It would seem closely related to foreach, though. 

What happens when there are a bunch of the puppies? Vectorizing operators
do the right thing, working according to the rules of precedence. "each"
would have to just share one iterator per statement, or else do ugly things
to the rest of the statement. It would be very difficult to do something like:

  (each @foo + each @bar) + (each @baz + each @baz)

This would lend itself a P5 backport that did overload on its argument, too. If
it found that the thing on the right hand side was also overloaded into the
same class, it is could use a single iterator on both sides, otherwise it would
treat the 2nd argument as a scalar. This would solve the "single iterator
per line" problem for p5 atleast. It would work correctly. Any number of
vectorized arrays could be floating around in an expression, each interacting
with each other correctly.

Would it be possible to subclass things on the fly, returning a specialized
object representing the argument that knew how to vectorize when asked to add?
Aren't add, substract, multiply, and so on, implemented as class methods in
Perl 6, much like Perl 5's overload module?

foreach and map are looking really good, combined with argument binding and
pipelines. Is this redundant perhaps?

Would a keyword for vectorizing be more consistent with the "zip" keyword?

Can you smell the speculation in the air?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About