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
