Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site mit-eddie.MIT.EDU
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!barmar
From: barmar@mit-eddie.MIT.EDU (Barry Margolin)
Newsgroups: net.lang.c
Subject: Re: unary +
Message-ID: <1223@mit-eddie.MIT.EDU>
Date: Sat, 8-Mar-86 17:22:49 EST
Article-I.D.: mit-eddi.1223
Posted: Sat Mar  8 17:22:49 1986
Date-Received: Sun, 9-Mar-86 09:28:08 EST
References: <1227@mtx5a.UUCP>
Reply-To: barmar@eddie.UUCP (Barry Margolin)
Distribution: net
Organization: MIT EECS Dept.
Lines: 28

In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP (ed gokhman) writes:
>An expression a + (b + c) may be calculated by some
>implementations as (a + b) + c. To enforce the
>intended precedence of operations one should use
>a + +(b + c).
>
>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" ?

I don't know what the committee's explanation is, but I agree with them
for the following reason:

Parentheses in expressions already have a meaning, that of overriding
the default precedence.  In the expression f(a)*(b+c), the parentheses
mean that the result of the function call should be multiplied by the
sum.  When writing that, the programmer ordinarily doesn't care which is
computed first, the function call or the sum.  Making parentheses have
two meanings would restrict the transformations that optimizers may
perform.

To me, this is what it means for an implementation to "respect
parenthesising as intended."
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar