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

Re: Semantics of vector operations

Thread Previous | Thread Next
Luke Palmer
January 30, 2004 05:13
Re: Semantics of vector operations
Message ID:
Scott Walters writes:
> 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;

That would be a hard macro to write.  Not impossible, of course :-)

I'm not sure it's a good idea to change the syntax just because Unicode
is unavailable.  There was a definite reason for bundling the "each"
modifiers near the operator, and we'd be changing that.  You also get
ambiguities regarding to which operator the C<each> applies if there is
more than one.

On the other hand, it does read quite wonderfully, unlike the seeming

    @arr each += each @foo;

What about just a function?

    each(&infix:+= , @arr, @foo)

Such that the Unicode is the only way to get at the syntactic shortcut?
We've done a lot to make functions readable in a lot of ways.  Indeed,
there are many ways the function could work.  A function that operates
on alternating arguments may not be unhandy either:

    each(&infix:+= , zip(@arr, @foo))

But that's getting pretty far away from what the operators originally

> 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.

Perl5 C<each> is going away anyway, in favor of the new construct:

    for %hash.kv -> $k, $v {

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

Which is also going away :-)

> 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)

Don't worry about implementation.  That's not our job.

It would probably be implemented as a macro that just put it back into
the Unicode notation.

> 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.

Of course you mean "損interacting with束 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?

No!  And I couldn't be happier!  They're multimethods, dispatching based
on I<both> their arguments, not just the left one.


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