Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: unary +
Message-ID: <2523@utcsri.UUCP>
Date: Thu, 10-Apr-86 03:31:09 EST
Article-I.D.: utcsri.2523
Posted: Thu Apr 10 03:31:09 1986
Date-Received: Thu, 10-Apr-86 04:21:15 EST
References: <2447@brl-smoke.ARPA>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 26
Summary: be careful what you mean by OOE.

In article <2447@brl-smoke.ARPA> rbj@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.
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.
-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg