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.

## Advertising

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