unary +

[rbj%icst-cmr at smoke.UUCP]

> In article <2447 at brl-smoke.ARPA> rbj at icst-cmr (Root Boy Jim) writes:
> >~ (OOE = Order-Of-Evaluation.)
> >~ [1]  "()" is worse.  The code generator should NOT have to assume all
> >~ parens specify OOE.  In the example given it looks intuitive (since I could
> >~ write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect
> >~ intended OOE), but it's not true in general.  Also, it's already been
> >~ observed that expanded macros often have extraneous parens.
> >
> >Which serve to specify OOE. I think it slightly weird that K&R allowed
> >rearranging OOE for associative operators, but mostly it doesn't hurt.
> 
> Parentheses DO NOT SPECIFY ORDER OF EVALUATION ( at least not in this
> sense). They are used to override the bindings of operators. In compiler
> terms, this means that ()'s are used to control the shape of the parse
> tree, but they do not otherwise affect the order of the code generated for it.

Which to my mind is OOE. At least when we're talking simple variables.
True, if `a', `b', & `c' are expressions (funxion calls in particular)
any funxion might be called first. In all other cases except associative
operators specify OOE by changing the bindings of the operators. I don't
understand the distinxion you are drawing.

> Consider that ?: groups right-to-left [ meaning a?b:c?d:e == a?b:(c?d:e)]
> but is evaluated left to right: 'a' is always done first. Don't look at
> K&R page 215 - it is wrong on this point. Pg. 49 is correct.
> 
> >Anyone for a reverse polish notation C spec?
> 
> *No*. Try Forth. You'll soon agree.

Hey, why not? Let's get rid of the distinxion between `statements' and
expressions. Then we don't need an IF. Just use `?:'.

	<exp> 	?	<true>
		:	<false>

> Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg

	(Root Boy) Jim Cottrell		<rbj at cmr>