HaloO, Larry Wall wrote:

Another minor psychological factor is comes into play is that, besides being "too hard to type", รท is visually a symmetrical operator, while division is inherently an asymmetric operation. You'll notice that other asymmetric operators invented by mathematicians tend to convey that asymmetry visually.

## Advertising

OK, with symmetric equal to commutative. But you don't have this concern with - which is as asymmetric as /. Also x and xx are asymmetric without visual indication. These are not even symmetric in the types of their operants.

: > Second, a path is much more like a string than a number.:: Right. Which means there's no room for confusion with division,: 'cause you can't divide strings! Ambiguity gone, problem solved, no : worries. Er, except for hordes of Perl 5 programmers who think you can... :)

Yeah! We could actually invent x/ for a "inverse" operation of x in the sense that you factor a string. E.g. 'aaa' x/ 3 eq 'a' but 'abc' x/ 3 eq ''. That is a non-repetitive string is kind of primal. Hmm, or x/ behaves more like % and 'abc' x/ 3 eq 'abc' and 'aaa' x/ 2 eq 'a' and of course 'aaa' x/ 3 eq ''. But that might better be spelled x%, I think. Speaking of x actually makes me wonder about two things in its definition: (1) why is it non-associative and (2) why is it not on the multiplicative precedence but below addition? It could be made left associative: 'ab' x 3 x 2 eq 'abababababab' which implies

`that 3 x 2 == 6. So we would get a multiplication operator that the`

`optimizer wouldn't touch commutatively. Hence it would be a good`

candidate for the vector cross product and quaternion multiplication and such. Or we could use it for the scalar multiplication of vectors. That would require it to be commutative, though. Note that this is no problem if we define &infix:<x>:(::T,::T) to be a type error whilst &infix:<x>:(::T, Num | Num, ::T) allows 3 x 'a' eq 'a' x 3 eq 'aaa' when ::T === Str. Actually we could make x commutatively list associative and define that at most one operant can be of a type different from Num or better a type that is a Field, e.g. Complex. This automatically gives (1,2,3) x 3 === 3 x (1,2,3) === (2,6,9). Uhh, and ~~ might check linear dependence of vectors or so. BTW, how would the signature of x look like if you want to enforce the presence of at most one argument of type Field? The problem is you can't have the variadic array at the front or the middle to get multi *listfix:<x> ( none(Field) ::T $v, Field [EMAIL PROTECTED] | Field [EMAIL PROTECTED], none(Field) ::T $v | Field [EMAIL PROTECTED], none(Field) ::T $v, Field [EMAIL PROTECTED] --> T) {...} perhaps multi *listfix:<x> ( [EMAIL PROTECTED] where { one(@scalars) does none(Field) or all(@scalars) does Field } ) {...} but that makes capturing the non-field type impossible. An additional idea of mine is to also introduce a generic multiplication operator &infix:<o> as ASCII equivalent of U+2218. An exponentiation in terms of o would be written oo. That somewhat makes xx oddly overloaded with list replication where one could expect it to be exponentiation in terms of x. Then again scalar multiplication has no exponential form. For geometric algebra one would introduce _| (U+2A3C) and |_ (U+2A3D) for left and right contraction and /\ for the wedge. And then choose x

`for the geometric product if it had multiplicative precedence. Or if we`

`follow the scalar multiplication approach outlined above,`

&infix:<*>:(::T, T --> T) would become a generic list associative non-commutative product operator. Note that a proper product is homogeneous in ::T whereas multiplicative x is generally not. Sorry if this is off-topic, but this is the outcome if I'm musing about operator overloading. My driving idea is to abstractly define the properties of operators that should hold when overloaded. E.g. + for string concatenation is bad because I would expect $a + $b eqv $b + $a. From the commutativity point of view it could be argued to overload - which isn't commutative like ~. But I've never seen - being overloaded with string concatenation ;) In the last section of S03 good names for the three groups of operators are asked for. I would call the group with guaranteed sequence points just that: sequential operators. They come in two types: left and right sequential. Basically this replaces the "wrong" usage of associativity of an operator. Then associativity could retain its mathematical meaning and allow the optimizer/parallizer to group at will. E.g + would be associative but - left-sequential or forcing associative addition with prior unary -. Same thing with * and / if we have e.g. &prefix:<1/> applied before associating the factors. Commutativity would be an even better property of an operator because it doesn't have to assemble values returned from multiple threads in the order prescribed by the source code. E.g. if 10 threads are started for [*]1..100 each multiplying 10 consecutive values the main thread can *= them together in the order they happen to arrive. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl