Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uokvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!okstate.UUCP!uokvax.UUCP!emjej
From: emjej@uokvax.UUCP
Newsgroups: net.lang.c
Subject: Re: unary +
Message-ID: <3000073@uokvax.UUCP>
Date: Tue, 18-Mar-86 10:40:00 EST
Article-I.D.: uokvax.3000073
Posted: Tue Mar 18 10:40:00 1986
Date-Received: Sat, 22-Mar-86 06:12:55 EST
References: <1227@mtx5a.UUCP>
Lines: 30
Nf-ID: #R:mtx5a.UUCP:1227:uokvax.UUCP:3000073:000:1144
Nf-From: uokvax.UUCP!emjej    Mar 18 09:40:00 1986


/* Written 12:11 pm  Mar 11, 1986 by bright@dataioDataio.UUCP in net.lang.c */
One Answer [to the question why not require C compilers to honor parentheses
if the human takes the time to put the #$!#! things in]:
	Compilers frequently parse the expressions into an internal form
which is a binary tree. a+(b+c) would look like:

	  +
	 / \
	a   +
	   / \
	  b   c

Where are the parentheses? They're gone, they are only used in guiding
the parser as it builds the tree. Thus, the optimizer doesn't know where
the parentheses were. 
/* End of text from net.lang.c */

Eh?  It doesn't *need* to know where the parentheses were; the order of
operations is completely specified by the tree.  If the coder had written
a+b+c most parsers would turn it into (+ (+ a b) c), linearizing the
notation to save space.

Optimizers that reorder operations, especially on floating-point computation,
at best will induce some detectable error, such as overflow.  At worst, they
will cause loss of precision.  I doubt that conscientious numerical analysts
would ever use a language that permitted such finagling behind the programmer's
back.

						James Jones