Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!sri-unix!hplabs!ucbvax!sdcsvax!sdchem!tps
From: tps@sdchem.UUCP (Tom Stockfisch)
Newsgroups: net.lang.c
Subject: Re: Expression sequencing query
Message-ID: <390@sdchema.sdchem.UUCP>
Date: Thu, 9-Oct-86 19:15:20 EDT
Article-I.D.: sdchema.390
Posted: Thu Oct  9 19:15:20 1986
Date-Received: Fri, 10-Oct-86 08:33:10 EDT
References: <760@oakhill.UUCP> <111@titan.UUCP> <468@jc3b21.UUCP> <160@geac.UUCP>
Reply-To: tps@sdchema.UUCP (Tom Stockfisch)
Distribution: net
Organization: Chemistry Dept, UC San Diego
Lines: 52
Keywords: Bugs

In article <160@geac.UUCP> len@geac.UUCP (Leonard Vanek) writes:
>The one thing that is clear from all of the discussion on
>the problem of expression sequencing is that one can never
>be sure of the order in which an expression in C will be
>evaluated.
>
>...
>... To ignore parentheses in determining the
>evaluation order (i.e. (a+b)+c does not guarantee that a and
>b are added first) causes problems with round off errors,
>not just side effects -- and is totally counter-intuitive.

Allowing optimizing compilers the freedom to rearrange expressions is (I
am told) crucial to performance on many machines.  Good portability means
not only that a program will  w o r k  on any machine, but that it will
work  e f f i c i e n t l y  on any machine, and people won't be tempted
to waste time fine-tuning programs to many different machines (a maintenance
nightmare).  For non-numerical calculations, order of evaluation almost
never matters, except with poorly written expressions (e.g.  multiple
side effects).
For numerical calculations it would be very nice to be able
to specify order.  Breaking up the expression into individual ones is  n o t
a viable option, as serious numerical work can have rather long expressions
which would be rendered unreadable.

I think the best solution would be a unary operator with syntax like 'return',
so that the compiler would have to respect parentheses for order of evaluation
of the following statement.
Unfortunately, this would probably mean another key word or another obscure
overloading of a current one.  But a feature like this is really important for
numerical programming.  For instance, call the operator "respect".  Then
	
	respect	<expr> ;

would mean that <expr> must have its parentheses respected.  I think this is
much better than
	
	respect( <expr> );

because extra parentheses tend to muck things up in numeric work, altho of
course wimps (:-) who insist on using

	return(expr);

instead of
	
	return	expr;

could do likewise with "respect".
-- 

-- Tom Stockfisch, UCSD Chemistry