unary +

[jdz at wucec2.UUCP]

In article <1227 at mtx5a.UUCP> esg at mtx5a.UUCP (ed gokhman) writes:
>Question: what is the rational for not saying that an
>	implementation *must* respect parenthesising
>	as intended rather then providing an extra
>	operator simply to state "i mean these parenthesis" ?

Optimization, plain and simple. The example you gave was:
	a + (b+c) might be computed as (a+b) + c.
Suppose the compiler knew a and b were already in registers, and was generating
code for a load/store machine (i.e. RISC-type architectures, with memory
access only via load register or store register).

Cheap: a_reg = a_reg + b_reg	! Sum a and b, saving where a was
       load c into b_reg	! Get c into register
       a_reg = a_reg + b_reg	! Finishing sum

Expensive:
	store a_reg into temp	! Free up a register
	load c into a_reg	! Get c
	a_reg = a_reg + b_reg	! Compute b+c
	load temp into b_reg	! Get a back in
	a_reg = a_reg + b_reg	! Finish sum

Getting a little less contrived, if any of the terms in the sum were a
function call, the compiler might decide to call the function any time it
wanted to during evaluation of the expression, for optimization. I.e.
	x = ((a + f(a+b)) + b)
would be most cheaply evaluated by computing a+b, then calling f() on that
term and adding the returned value to a+b. Any other way involves computing
a+b twice (in one way or another).

I like the notion of being able to control reordering of expressions because
it lets the programmer clearly specify the order in which side-effects occur.
Yeah, I know, side effects make for ugly programs, but most of us are guilty
of using them more often than we should. Nobody is perfect, and we all do
strange things under the pressure of deadlines.
-- 
Jason D. Zions			...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz
Box 1045 Washington University
St. Louis MO 63130  USA		(314) 889-6160
Nope, I didn't say nothing. Just random noise.