Perl6 Operator (REMAINING ISSUES)

[Ed Peschko]

Michael Lazarro wrote:

> 1) Need a definite syntax for hypers
> ^[op] and <<op>>
> have been most seriously proposed -- something that keeps a
> bracketed syntax, but solves ambiguity issues.

hm. What was wrong with just '^' again? Reading the threads, it seems to have
gotten lost in the shuffle.

Ed

[Luke Palmer]

> Mailing-List: contact perl6-lan...@perl.org; run by ezmlm
> Date: Thu, 31 Oct 2002 11:13:28 -0800
> From: Ed Peschko <es...@rama.comp.pge.com>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/

Xor needs it. I'd place hypers in front of xor on my importance list,
but that's just me.

> Ed
>

[Me]

> > 1) Need a definite syntax for hypers
> > ^[op] and <<op>>
> > have been most seriously proposed -- something that keeps a
> > bracketed syntax, but solves ambiguity issues.
>
> hm. What was wrong with just '^' again?

Right. I didn't have a problem with ^ in the first place.

But...

A ^ prefix visually interferes a lot more with the op being
hypered. I didn't understand that until I first saw use of
square brackets (interestingly, use of angle brackets
didn't grab my attention, though that may have been
due to other factors).

Personally, I liked the use of single backtick someone
suggested. I suspect that this is because it seemed
to be just as good as square brackets at getting out
of the way visually (vastly better than ^); was enough
to catch my attention to suggest something special
was going on; was just one, unshifted, character (or
two, if used for a `op`= variant); and seemed to be
the least disruptive (it left ^ for other duties and just
meant one needed to eliminate `` for a syscall; hmm,
maybe that's not acceptable...)

--
ralph

[David Wheeler]

On Thursday, October 31, 2002, at 11:36 AM, Me wrote:

> A ^ prefix visually interferes a lot more with the op being
> hypered. I didn't understand that until I first saw use of
> square brackets (interestingly, use of angle brackets
> didn't grab my attention, though that may have been
> due to other factors).

If we're talking about operators being "hypered," then I think that
«op» makes a lot of sense. It reminds me of Perl 5's "spaceship"
operator, <=>, and I think of a spaceship taking the operator and
jumping into hyperspace. What could be a better analogy than that,
quantumly speaking?

Plus, it turns out not to be at all hard to type on Mac OS X. ;-)

Regards,

David

--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org

[Ed Peschko]

On Thu, Oct 31, 2002 at 01:36:20PM -0600, Me wrote:
> > > 1) Need a definite syntax for hypers
> > > ^[op] and <<op>>
> > > have been most seriously proposed -- something that keeps a
> > > bracketed syntax, but solves ambiguity issues.
> >
> > hm. What was wrong with just '^' again?
>
> Right. I didn't have a problem with ^ in the first place.
>
> But...
>
> A ^ prefix visually interferes a lot more with the op being
> hypered. I didn't understand that until I first saw use of
> square brackets (interestingly, use of angle brackets
> didn't grab my attention, though that may have been
> due to other factors).

I know it clutters up things a bit, that's my very argument; that
^[ ] clutters up things even *more*. especially, with use of arrays:

@array[1,2,3] ^[+=] @array[4,5,6];

bleah.

@array[1,2,3] ^+= @array[4,5,6];

Not much of a improvement, but its palpable. There's some comfort knowing that
'^' is being used as a sigil for an operator, and that all you need is one
keystroke in order to use it.

I guess it depends on how much hyperoperators are meant to be used. The more
they are, the shorter the operator should be.

Oh by the way. IMO 'vector' operators should be the proper term. Looking
at the above sentence, the term 'hyperoperator' should be quietly euthanized.
(or quickly shot.)

Ed

[Me]

> > A ^ prefix visually interferes a lot more
>

> I know it clutters up things a bit, that's my very argument; that
> ^[ ] clutters up things even *more*. especially, with use of arrays:
>
> @array[1,2,3] ^[+=] @array[4,5,6];
>
> bleah.
>
> @array[1,2,3] ^+= @array[4,5,6];
>
> Not much of a improvement, but its palpable.

Maybe. I slightly prefer the first line right now.
But it's close, and I think I've gotten too used to
both notations to know what I'd think if I saw one
or other for the first time, and I don't know what
I'd think after a month of use of one or other. As
I said, it's close. This will defintely be my last
email on the topic...

There's a couple other reasons to go for ^[op].

One is that [] is more obviously indicative to a
newbie that there is some array aspect to how
the op applies than ^ (or backtick) would be.

Another is that bracketing works better to indicate
the difference between the two ...= variants that
might be useful:

@a ^[+=] @b
@a ^[+]= @b # vectorize the +, not the =

@a ^+= @b
@a ^+^= @b # vectorize the +, not the = ?!?

> '^' is being used as a sigil for an operator, and that all
> you need is one keystroke in order to use it.

On my keyboard it's two (shift and the 6 key).

> Oh by the way. IMO 'vector' operators should be the
> proper term.

Oops. Yes.

--
ralph

[Mark J. Reed]

On 2002-10-31 at 12:45:23, David Wheeler wrote:
> Plus, it turns out not to be at all hard to type on Mac OS X. ;-)

Well, the angle quotes happen to fall within Latin-1, and so they're
easier to get to. On Windows you can either set up special key mappings or
just type ALT+171 for « and ALT+187 for », which gets wearisome after
a while although you can get your fingers taught pretty quickly.
Vim and emacs and XIM all take care of the UNIX case.

Once you wander away from Latin-1 into the more general world
of Unicode, you start running into trouble on the input side.
On Windows you pretty much have to use the Character map accessory.
Emacs and vim still work on UNIX, but I don't know of a XIM
implementation for general Unicode. (Although if you log into
your Unix machine using Kermit-95, it has a keystroke sequence for
arbitrary Unicode input).

Presumably, though, if Perl did have Unicode operators, it would
also have an ASCII alternative, even if only something like
\u00ab and \u00bb.

--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754

[fear...@figaro.weizmann.ac.il]

Me writes:
> > > A ^ prefix visually interferes a lot more
> >
> > I know it clutters up things a bit, that's my very argument; that
> > ^[ ] clutters up things even *more*. especially, with use of arrays:
> >
> > @array[1,2,3] ^[+=] @array[4,5,6];
> >
> > bleah.
> >
> > @array[1,2,3] ^+= @array[4,5,6];
> >
> > Not much of a improvement, but its palpable.
>
> Maybe. I slightly prefer the first line right now.
> But it's close, and I think I've gotten too used to
> both notations to know what I'd think if I saw one
> or other for the first time, and I don't know what
> I'd think after a month of use of one or other. As
> I said, it's close. This will defintely be my last
> email on the topic...
>

actually , ones we decide that ^ *is necessary for vectorization , we
can allow other brackets , optional brackets ( where unambiguous ) ,
and spaces inside the brackets :

@a ^+= @b

@a ^[+]= @b

@a ^(+)= @b
@a ^( + )= @b

@a ^{ + }= @b
@a ^{+}= @b
@a ^[ + ]= @b

all that can *coexist* !

[Ed Peschko]

> Maybe. I slightly prefer the first line right now.
> But it's close, and I think I've gotten too used to
> both notations to know what I'd think if I saw one
> or other for the first time, and I don't know what
> I'd think after a month of use of one or other. As
> I said, it's close. This will defintely be my last
> email on the topic...

likewise..

>
> There's a couple other reasons to go for ^[op].
>
> One is that [] is more obviously indicative to a
> newbie that there is some array aspect to how
> the op applies than ^ (or backtick) would be.

I think that this advantage pales to the cost of having to type three characters
every single time someone has to use a vector operation. Its just as easy
for a newbie to say 'aha! ^ means array!'.

> Another is that bracketing works better to indicate
> the difference between the two ...= variants that
> might be useful:
>
> @a ^[+=] @b
> @a ^[+]= @b # vectorize the +, not the =
>
> @a ^+= @b
> @a ^+^= @b # vectorize the +, not the = ?!?
>

Ok, I can sort of see this, but what the #%@@$ do both of these things mean? I
can see @a ^+= @b meaining

$a[0] += $b[0]
$a[0] += $b[1]
$a[0] += $b[2]
$a[0] += $b[3]...etc

but @a ^[+]= @b??

I swear, this whole vector operator thing would be a lot easier to
understand if everything was vectored or not, ie:

@a = @b ^+ @c;

was a syntax error or was optimised to:

@a ^= @b ^+ @c;

In that case, ^[+]= doesn't really make sense.

Ed

[Markus Laire]

On 31 Oct 2002 at 15:59, Mark J. Reed wrote:

> Once you wander away from Latin-1 into the more general world
> of Unicode, you start running into trouble on the input side.
> On Windows you pretty much have to use the Character map accessory.
> Emacs and vim still work on UNIX, but I don't know of a XIM
> implementation for general Unicode. (Although if you log into your
> Unix machine using Kermit-95, it has a keystroke sequence for
> arbitrary Unicode input).

Emacs and vim also works on Windows, not just UNIX.

--
Markus Laire 'malaire' <markus...@nic.fi>

[Brent Dax]

Markus Laire:
# Emacs and vim also works on Windows, not just UNIX.

So does DOS 'edit'. That doesn't mean Windows users use it. Windows
users want tools that look and act like Windows tools--if they didn't,
they'd be using another OS. Neither GNU emacs nor xemacs fits the bill,
and I doubt vim does either.

I'm an aberration--I use Windows, but I have a Cygwin toolkit installed
and use it regularly. Still, I use VS.Net (with Visual Perl) for my
editing, not a Unix editor. When telnetting, I use emacs, so I
installed XEmacs, used it for a while, and decided I didn't like it for
my local work. It had some really cool features--I was *very*
pleasantly surprised at how nicely it meshed with CVS--but it just
didn't fit my Windows-shaped brain.

You can bet that if I, a Perl core hacker who keeps two copies of
cmd.exe open at all times with c:\cygwin\bin in his path, am not going
to use XEmacs, your average Joe who downloads ActiveState Perl 6 to test
his hit-counter script won't use emacs or vim either.

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)

[Ed Peschko]

> actually , ones we decide that ^ *is necessary for vectorization , we
> can allow other brackets , optional brackets ( where unambiguous ) ,
> and spaces inside the brackets :
>
> @a ^+= @b
> @a ^[+]= @b
> @a ^(+)= @b
> @a ^( + )= @b
> @a ^{ + }= @b
> @a ^{+}= @b
> @a ^[ + ]= @b
>

right, and what does this all mean? I have yet to see a good meaning for
@array ^[+]= @array2 ...

Perhaps, having just ^ as a vector op, and using ^[op] to disambiguate (or
as an equivalent) is the way to go.

Ed

[John Williams]

Personally, I would like to see us come full circle back to just ^ again
too.

The main problem seems to be that we want ^ and ^^ for xor-ing things,
so ^^ could be either a logical-xor or a vector-one-superposition.

So what if we just made the [] optional? Then all the original
hyper/vector documentation is still valid. (The meanings of ^+ ^|| ^<<=
etc are all non-ambiguous.) For the ambiguous case, ^^ is logical-xor
because it is used more often, and vector-one-superposition is
unambiguously ^[^] .

~ John Williams

[Luke Palmer]

y> Mailing-List: contact perl6-lan...@perl.org; run by ezmlm
> Date: Fri, 1 Nov 2002 10:39:59 -0700 (MST)
> From: John Williams <will...@morinda.com>
> Cc: <perl6-l...@perl.org>
> X-OriginalArrivalTime: 01 Nov 2002 17:40:00.0029 (UTC) FILETIME=[B38AC4D0:01C281CD]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/

You know, I like it. In any "potentially ambiguous" cases, the
non-vector version would be preferred. It doesn't seem exactly
"elegant," but there's some appeal that I'm drawn to.

Luke

[Ed Peschko]

> > right, and what does this all mean? I have yet to see a good meaning
> > for
> > @array ^[+]= @array2 ...
>

> I think it's this:
>
> @a [+=] @b -> @a[x] += @b[x]
>
> @a [+]= @b -> @temp = @a [+] @b; a = @temp;
>

Ok, so the '=' isn't being explicitly vectorized. So -

@a ^[+]= @b;

@a = (1,2,3,4); @b = (5,6,7,8);

@temp = @a ^+ @b; = (1+5,2+6,3+7,4+8) = (6,8,10,12);

@temp = (6,8,10,12);

@a = (6,8,10,12);

wheras:

@a ^+= @b;

$a[0] += $b[0];

$a[1] += $b[1];
$a[2] += $b[2];
$a[3] += $b[3];

$a[0] = 1 + 5;
$a[1] = 2 + 6;
$a[2] = 3 + 7;
$a[3] = 4 + 8;

@a = (6,8,10,12);

ie: they are exactly the same. I'd say that '=' has *implicit* vectorization
here in the array case. In the scalar case:

@a ^[+]= 1;

@temp = @a ^+ 1;

it is exactly the same.

@a ^+= 1;

$a[0] +=1;
....
$a[3] +=;

So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms
as far as I can see, and hence no need for the first form.

Ed

[fear...@figaro.weizmann.ac.il]

Ed Peschko writes:
>
> So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms
> as far as I can see, and hence no need for the first form.
>
> Ed
>
>
>

somebody before ( dont remember who)
showed how they can be different if the first argument is scalar.

arcadi .

[Austin Hastings]

Ed,

Under normal definitions, you're right. But under overload, you're
seeing two different sets of operators get invoked?

@temp = @a [+] @b;

@a = @temp;

This invokes N iterations of (multidispatch(operator:+, $a[n], $b[n])),

which likely results in:

N x Some_Class.new
N x Underlying_type.operator:+($a[n], $b[n])
N x Some_Class.operator:=

followed by one invocation of @a.operator=.

Potentially useful if objects should be "rebalanced" or "snapshot" or
"transactionalized" or something whenever a vector operation happens.
Especially where variables are tied, or represent fanciful classes with
simplified interfaces, this will be significant.

OTOH:

@a [+=] @b

This invokes N iterations of (multidispatch(operator:+=, $a[n], $b[n]))
which likely results in (if it doesn't actually IMPLEMENT):

N x Underlying_type.operator:+
N x Some_Class.operator:=

and nothing else.

So there's no "initialize the temp object" or "close down the original
@a TIE" or "whatever" getting invoked. And that can be a win,
database-session-closeout-wise, or whatever your TIE'ing application
happens to be.

=Austin

__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute

[John Williams]

On Fri, 1 Nov 2002, Ed Peschko wrote:

> @a ^[+]= @b;

compared to

> @a ^+= @b;

>
> ie: they are exactly the same.

You are right, you get the same answer whether you do the hyper or the
assignment first, except in the "scalar ^op= list", in which case doing
the assignment last gets you the length of the list or some other useless
result.

> I'd say that '=' has *implicit* vectorization
> here in the array case. In the scalar case:

Right. ^= is rather pointless, because = already understands list
context.

OTOH, you can get some different effects out of ^= by virtue of the
"dimensionally replicate, quantitatively undef-extend" rule for vectoring
operators.

@a ^= @b # @a.length == max( @a.length, @b.length )
@a ^= $b # all currently existing elements of @a are set to $b
$b ^= @a # Yuck! $b = last element of @a.

~ John Williams

[Unknown]

On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote:
> So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms
> as far as I can see, and hence no need for the first form.

Only in the absence of overloading, and only because we've naively defined array
ops to always do "union" rather than "intersection". If there were a vector op
that took the shorter of two arrays as the overall length, then

@a = @a »op« @b

will truncate @a, while

@a »op=« @b

might only change the elements they have in common. I don't know if we'll have
any such operators on arrays, but they've already been proposed for hashes.

So

%a »op=« %b

might well be different from

%a »op«= %b

depending on what op is.

Larry

[Unknown]

On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote:
> Right. ^= is rather pointless, because = already understands list
> context.

They're not quite the same because list assignment truncates first. To wit:

@a = [1,2,3];
@b = [4,5];

@a = @b; # @a gets [4,5]

@a ^= @b; # @a gets [4,5,undef]

And if you define = as an "intersection" rather than a "union" op, you'd get

@a ^= @b; # @a gets [4,5,3]

Maybe. Or there could be a truncation implicit in intersection operators.

> OTOH, you can get some different effects out of ^= by virtue of the
> "dimensionally replicate, quantitatively undef-extend" rule for vectoring
> operators.
>
> @a ^= @b # @a.length == max( @a.length, @b.length )
> @a ^= $b # all currently existing elements of @a are set to $b
> $b ^= @a # Yuck! $b = last element of @a.

Every possible utterance doesn't have to make practical sense...

Larry

[John Williams]

On Fri, 1 Nov 2002, it was written:

> On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote:
> > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms
> > as far as I can see, and hence no need for the first form.
>
> Only in the absence of overloading, and only because we've naively
> defined array ops to always do "union" rather than "intersection".
> If there were a vector op that took the shorter of two arrays as the
> overall length, then
>
> @a = @a »op« @b

Ooo! I have it!

@a »op« @b # picks the shorter of the two lengths (intersection)
@a «op» @b # picks the longer of the two lengths (union)

Maybe the hyper-hash guys could work with it too.

~ John Williams

[Ed Peschko]

>> So again, I don't see the difference between the two. ^[+]= and ^+= are
>> synonyms as far as I can see, and hence no need for the first form.

> Only in the absence of overloading, and only because we've naively defined
> array ops to always do "union" rather than "intersection". If there were a
> vector op that took the shorter of two arrays as the overall length, then
>
> @a = @a »op« @b
>
> will truncate @a, while
>
> @a »op=« @b
>
> might only change the elements they have in common. I don't know if we'll
> have any such operators on arrays, but they've already been proposed for
> hashes.

argh. you're scaring me just mentioning '»' and '«' as vector ops (ascii
please!). Also, just mentioning array versus intersection scares me. You
could make a case that:

@a ^+= @b;

does a truncate on @a if @b is shorter, and that

@a v+= @b;

is the 'true' union operator. You could hence argue that there are really two
vector operators one for union and one for intersection, and that the place
to define whether or not something as intersection or union belongs there, and
not in the operator itself.

Ed

[Markus Laire]

On 31 Oct 2002 at 16:04, Brent Dax wrote:

> Markus Laire:
> # Emacs and vim also works on Windows, not just UNIX.
>
> So does DOS 'edit'. That doesn't mean Windows users use it. Windows
> users want tools that look and act like Windows tools--if they didn't,
> they'd be using another OS. Neither GNU emacs nor xemacs fits the
> bill, and I doubt vim does either.

gvim looks and acts a lot like usual Windows editors if you install
it in proper 'windows compatible' mode. Still it is a bit different.

[fear...@figaro.weizmann.ac.il]

to me , this discussion approaches the conclusion that
^[] and v[] are *just* another operators with their own behavior
that accept as ( optional ) argument a Code reference .

to follow the beautifull philosophy of perl6 -- "A is just B" we can
say ( following Larry Wall )

...
> A Perl5 magic is just a property.
> A Perl5 attribute is just a property.
> A block is just a closure.
> A control structure is just a subroutine that can call closures.
...
(maybe...)
A "for" loop is *almost* a subroutine that can call closures .
A vector operation is just a ( cryptographic ) "for" loop
with one or two input streams and <op> name inside brackets
as a closure.

so it is just a function :

sub infix:^[] ( Code &op : Array @a , Array @b
) is parsed /^[ <op> | \[<op>\] ]/
{
my @inds = union( @a.keys, @b.keys);
return for @inds {
&op ( @a[$_] , @b[$_] ) ;
}
}

sub infix:v[] ( Code &op : Array @a , Array @b
) is parsed /^[ <op> | \[<op>\] ]/
{
my @inds = intersection( @a.keys, @b.keys);
return for @inds {
&op ( @a[$_] , @b[$_] ) ;
}
}

or maybe

sub infix:^[] ( Code &op : Array @a , Array @b
) is parsed /^[ <op> | \[<op>\] ]/
{
return for @a ; @b -> ($x is rw ; $y is rw ) {
&op ( $x , $y ) ;
}
}

sub postfix:^[] ( Code &op : Array @a
) is parsed /^[ <op> | \[<op>\] ]/
{ for @a -> $x is rw &op( $x ) }
....

and analogous things for v[] . and this can be prefix, infix, postfix
; and each argument can be $a, @a, %a ; so it is a multimethod.

in that case the vectorization is *compleatly* orthogonal to the
details of op and we even can have something like

@a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b

arcadi

[fear...@figaro.weizmann.ac.il]

Larry Wall <> writes:
> On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote:
> > Right. ^= is rather pointless, because = already understands list
> > context.
>
> They're not quite the same because list assignment truncates first. To wit:
>
> @a = [1,2,3];
> @b = [4,5];
>
> @a = @b; # @a gets [4,5]
>
> @a ^= @b; # @a gets [4,5,undef]
>
> And if you define = as an "intersection" rather than a "union" op, you'd get
>
> @a ^= @b; # @a gets [4,5,3]
>
> Maybe. Or there could be a truncation implicit in intersection operators.
>

is it possible to make more clear this entry in the perl6 just-ice :

for loop is just ...

because it seems that all "plaintive wine" flows because that is
unclear .

.... because the second part seems to be obvious :

vector operation is just a "for" loop with arguments "scattered" around (
and inside) it .

something like

sub operator:^[] (Code &op, @a, @b) is parsed /\^\[<op>\]/ { ... }

if we assume that ^[] staff is just a "for" loop ( that is, subroutine
) with one ( for prefix/postfix) or two ( for infix ) input streams (
wich can be degenerate if one of the arguments is scalar ) ( and ^[] is
more general , because it can accept hashes ( maybe we should allow
hash as input stream in "for" loop ) ) so if we assume that,
than probably the decision on union/intersection in vector ops and for
loop with multiple streams should be unifyed .

in for loop we have special "|" , "&" , stream separators to
distinguish/force what we want. why for vector operations this have to
be more implicit ? ( or may be I misunderstood and It is not ) .

in other words , is it going to be that each op will have its own
default behavior ( with respect to unify/intersect and such ) when
vectorized ? can I define an operator and be sure about its behavior
when vectorized , or should I specify it at scalar operator definition
, or should I define explicitely both scalar and vector version.

arcadi

[Ed Peschko]

On Sat, Nov 02, 2002 at 02:18:44AM +0200, fear...@figaro.weizmann.ac.il wrote:
>
.... snip ...

>
> in that case the vectorization is *compleatly* orthogonal to the
> details of op and we even can have something like
>
> @a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b
>

I agree with all that you said above, I'm just saying we should make typing []
*optional*. 99% of the time, people are not going to need it, as they are not
defining their own operators as you did above.

Ed

[fear...@figaro.weizmann.ac.il]

Ed Peschko writes:
> I agree with all that you said above, I'm just saying we should make typing []
> *optional*. 99% of the time, people are not going to need it, as they are not
> defining their own operators as you did above.
>
> Ed
>
>

long ago ( when xor was "!" and ^ was called hyper ) Larry Wall was
talking about allowing spaces between "bulding blocks of long
operators @a ^ .+ = @b . so optional [ ] in vector operations becomes
*very* similar to optional ( ) in function call . Now almost sure ,
that name of the vectorization will change couple of times ( and if
it's sub one ( everyone will ! ) can define alias
&operator:^[] := &operator:`<<>>` ( very vague ) ).
so , maybe , the fruitfull way to generalize vector operations is to
say :
perl do not have vector operations .
perl have operator algebra ( does it ? ) that can produce "vector"
version of any operator , but more so .

op
op =
^ op
v op
t op
...

arcadi