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 <[EMAIL PROTECTED]> 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.
-scott
>
> > 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
