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

Re: Semantics of vector operations

Thread Previous | Thread Next
Luke Palmer
January 30, 2004 18:41
Re: Semantics of vector operations
Message ID:
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 &times; (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.


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