Jonathan Lang writes:
> Luke Palmer wrote:
> > Scott Walters writes:
> > > 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, subtract, 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.
>
> Exactly how far can we go without the "each" tags? We could define
> multimethods for the standard operators such that if one or both of their
> arguments are lists, they're treated as distributed functions, which would
> cover a _lot_ of ground on its own. However, there's a problem with
> extensibility: every time you add a new operator under this scheme, you'd
> also have to add overloaded versions which implement the distribution
> functionality or do without. I have a feeling that a large number of
> programmers would rather do without than write the extra code if it came
> down to that choice.
>
> How about this: if an operator is declared using one or more scalar
> parameters, and there's no defined alternative using list parameters in
> their places, implicit "distributing operators" are made available by the
> compiler. So:
>
> multi sub infix:+ ($x, $y) {...}
>
> would imply something like the existence of
>
> multi sub infix:+ (@x, $y) {return $_ + $y for @x;}
> multi sub infix:+ ($x, @y) {return $x + $_ for @y;}
> multi sub infix:+ (@x, @y) {...}
>
> (Yes, I know I abused the syntax for "return" and "for" above, and that it
> wouldn't do what you'd expect it to at first glance. Maybe it should?)
This was all discussed in Apocalypse 3. It's not happening, in
particular, because people like to do:
if $index < @array-1 {...}
It has been pointed out before: Polymorphic variables + polymorphic
operators = Bad Idea.
>
> Can you coerce a scalar value into a list? I'd love to be able to say
> something like "5 x $x" and have perl interpret it as "($x, $x, $x, $x,
> $x)"
You can do that. It looks like C<$x xx 5>.
> - or, better yet, take "5 x rand()" and get (rand(), rand(), rand(),
> rand(), rand())".
C<rand() xx 5> returns C<do { my $x = rand; ($x,$x,$x,$x,$x) }>.
> Combine this with the above: to add five random numbers
> to the first five elements of a list, you'd say "@x + 5 x rand()". The
> only drawback to this is that the "x" operator has already been claimed as
> a string operation.
>
> And, upon review, I'd rather _not_ have the core syntax of perl rely on
> unicode; so no using × (or whatever it's called in Unicode) for
> this. Unicode's fine for supplemental material; but until such time as
> unicode keyboards are more widespread, I don't want to be forced to use
> it.
Uh huh. Already been discussed. It ain't up for negotiation (it may
change, but it won't be from our direct influence).
> ==
>
> Is there anything else that <<+>> can do that the above can't?
No, but there's something that + can do that >>+<< can't, and that's why
the each operators have to be there.
Luke
