Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!pesnta!amd!amdcad!lll-crg!brooks
From: brooks@lll-crg.ARpA (Eugene D. Brooks III)
Newsgroups: net.lang.c
Subject: Re: unary +
Message-ID: <1341@lll-crg.ARpA>
Date: Wed, 26-Mar-86 00:30:50 EST
Article-I.D.: lll-crg.1341
Posted: Wed Mar 26 00:30:50 1986
Date-Received: Thu, 27-Mar-86 07:32:09 EST
References: <1227@mtx5a.UUCP> <138@myab.UUCP> <1502@wucec2.UUCP>
Reply-To: brooks@lll-crg.UUCP (Eugene D. Brooks III)
Distribution: net
Organization: Lawrence Livermore Labs, CRG Group
Lines: 20

In article <1502@wucec2.UUCP> jdz@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.