unary +

[Eugene D. Brooks III]

In article <1502 at wucec2.UUCP> jdz at wucec2.UUCP (Jason D. Zions) writes:
>This is the same problem I have withthe suggestion that parentheses should
>indicate desired order of evaluation. As has already been pointed out, the
>poor parenthesis already does duty to change precedence of operations. Using
Lets see now:
	a * (b + c)	(a)
means add b and c and then multiply by a but in
	a + (b + c)	(b)
the parens have no meaning because we need to reserve them for precedence
changing.  Is this not how you interpret the parens under these conditions?
The two plus operators have equal precedence and when the parens occur it
raises the precendence of the enclosed plus operator above the other.  Your
fault with interpreting the parens correctly in case (b) becomes its proof!

>Unary plus makes sense to me - it hangs around in the parse tree, which is
>one of the things optimizers optimize. They don't see the source text; they
>either look at the parse tree, intermediate text (probably without parens and
There is no reason why the parser can't suitably decorate the
parse tree when parens are encountered as in case (b).  One could even call
the internal operator UPLUS to keep the compiler standards committee happy.