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.
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
