Scott Walters writes:
> On 0, Rod Adams <[EMAIL PROTECTED]> 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
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:
each(&infix:+= , zip(@arr, @foo))
But that's getting pretty far away from what the operators originally
intended.
> 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
