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

Re: Semantics of vector operations

Thread Previous | Thread Next
Scott Walters
February 13, 2004 14:36
Re: Semantics of vector operations
Message ID:
This is still raging. I was going to let it slide. I hate the mechanics
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.

On  0, Luke Palmer <> wrote:
> > 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
> alternative:
>     @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:

I really like this too. It is like Lisp's special forms: "apply operator to data
in interesting way". It opens the door for numerous other operations in
a generic system. Maybe Damian will champion this for us =)

Taken to an ugly extreme, it could look like the correlation I wrote for
AI::FuzzyLogic, where sets permutate, correlate, or aggregate. Creating a framework
where this can exist outside of core prevents something horrid from being
suggested for core =)

>     each(&infix:+= , zip(@arr, @foo))
> But that's getting pretty far away from what the operators originally
> intended.

This isn't very far away from map when used on built-ins. 

  @foo = map &infix:*, zip(@foo, @bar);

  map -> $a is rw, $b { $a *= $b }, zip @foo, @bar; # except that zip would copy in all probability

each() as a map type operator that applies operators (and other closures), modifying
the LHS, covers what people want to do with vectorized operators and covers
gaps in map. 

So, in summary, I really like Luke's proposal.


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

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