# Re: Musings on operator overloading

```HaloO,

Larry Wall wrote:
```
```As it stands the .() forms are a great way to stack ops after
a term. Together with knowing about the ops on the symbolic unary
level you can easily read expressions from the terms outwards.
```

```
I'm not actually parsing expressions. Or as you point out below
with respect to look-ahead I'm bad at it as a human. But as a
human I've got a 2D vision and mathematical expressions are inherently
2D on paper. So they are more like a drawing than a writing.

The poor equivalent in a programming language is whitespace markup.
Consider the triangle inequality:

|\$x+\$y| <= |\$x| + |\$y|

This nicely breaks apart into five clusters of characters. I recognize
the two infix ops <= and + and bring my precedence knowledge to
bear or look it up. After that I analyze the remaining three
clusters. I see all of them having | as first and last character.
So I know that three absolute values are linked by two operators.
And only then do I start to analyze the things inside the | |s which
gives me the sum of \$x and \$y and the same values separately.

The version with more spaces is different

|\$x + \$y| <= |\$x| + |\$y|

because now I tend to perceive the two +s on equal footing and
converge visually on |\$x using prefix | and \$y| postfix. To avoid
that an ASCII equivalent of a typesetting system gives

| \$x + \$y |   <=   | \$x |   +   | \$y |

to guide my visual distance parsing or however that might be called.

```
```Good practice would then be to join these extended terms by an
obvious set of infix ops---usually one. The only twists to learn in
this scheme would be ++, -- and **.
```
```
I don't follow that.  Example?
```
```
The twist of ++, -- and ** is that they lay between method and symbolic
unary precedence and that ** is the only binary operator with tighter
precedence then the symbolic unarys.

By operator stacking I mean something like

!+-~?|+^~^\$x.a.b.c + [EMAIL PROTECTED]

which splits into two blobs left and right of + each of which has a
sigiled term as nucleus. From there I would work outwards in operator
precedence. In other words, writing the former example as

\$x ** \$y!

visually attaches ! to \$y and deters from the precedence issue.
So it should be something like

\$x**\$y\ !

to highlight it. But parens aren't that bad here either

(\$x ** \$y)!

But the tight precedence of infix ** should be made obvious by
not surrounding it with whitespace. Which gives

(\$x**\$y)!

as the best option.

I would make more infix ops list like. We already have

,      associative, non-commutative

| & ^   associative, commutative

and could add ~ into the first group and *, +, +&, +|, ~&, ~&, +^
and ~^ into the second one. The code generator and the optimizer would
use these features and give erroneous results when overloads don't
respect them.

Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl
```