Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdchem!tps
From: tps@sdchem.UUCP
Newsgroups: comp.lang.c
Subject: Re: Paying attention to parentheses
Message-ID: <673@sdchema.sdchem.UUCP>
Date: Wed, 15-Apr-87 17:09:39 EST
Article-I.D.: sdchema.673
Posted: Wed Apr 15 17:09:39 1987
Date-Received: Fri, 17-Apr-87 06:03:18 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <532@omepd> <2094@mmintl.UUCP>
Sender: news@sdchem.UUCP
Reply-To: tps@sdchemf.UUCP (Tom Stockfisch)
Organization: UC San Diego
Lines: 96

In article <2094@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:

>Instead of using the unary plus to force its argument to be evaluated as a
>unit, I believe that a much better syntax would be to use square brackets to
>enclose such subexpressions...

>>Here are some examples of parenthesized expressions, pulled from the
>>Elefunt tests, which want the order of evaluation guaranteed by the
>>parentheses:
>>		x = ((one + x * a) - one) * 16.0;
>>		y = x / ((half + x * half) *((half - x) + half));...

>Under the proposed standard, these would be:
>
>	x = +(+(one + x * a) - one) * 16.0;
>	y = x / (+(half + x * half) * +(+(half - x) + half));...

>With my proposal, one would instead have:
>
>	x = [[one + x * a] - one] * 16.0;
>	y = x / ([half + x * half] * [[half - x] + half]);...

>(Actually, I'm not really sure that *all* the parentheses I have marked as
>needing to be respected really do need to be; there is no way to tell for
>sure from the original code.

This is good argument for separating the default-precedence-overide use of
parentheses from the evaluation-order use.  You never know if you're
maintaining this code if the order is important.  If you require a different
syntax the meaning is very clear not only to the optimizing compiler but to
the human readers.

>I claim that the third set of expressions is much more readable than the
>second; in fact, it loses no readability from the original set.

I think its *more* readable because the programmers intentions are unambiguously
laid out -- "add these two together first, add these others in the most
expeditious manner".

>Several arguments were advanced against this proposal, which I will repeat
>and answer here:
>
>(1) Novice C programmers would say "gee, C supports both parentheses and
>brackets for expressions; I can use whichever looks better".

Even non-novice programmers have admitted in this group that they never
realised what was happening to their parentheses.  Confusion between
bracket and parens will be quite innocuous for novices.

>(2) Brackets for order of evaluation will be confused with subscripts.
>
>I don't think this problem amounts to a hill of beans.  People very rarely
>get confused between parentheses for grouping and parentheses for function
>arguments; I don't think this would cause any more problems.

I think arrays are a little different than functions.  You can't do
arithmetic with functions, whereas you can with arrays.  However, most
floating point expressions do only simple subscripting and avoid applying
arithmetic operators to arrays.  I think it would be wise to keep the
proposed meaning of unary plus for those who think the double meaning
of brackets would be confusing for a particular expression.

Fortran programmers shouldn't complain about this syntax because in Fortran,
parentheses are overloaded for grouping expressions and as array subscripts.

>(3) It is hard to make compilers recognize brackets as a function, when
>parentheses are used just for grouping.
>
>I don't believe it!  I have studied some compiler theory, although I have
>never had occasion to put much of it into practice.  I know of no parsing
>algorithms for which implementing this would be any harder than
>implementing the ANSI proposal.  I don't believe there are any where it
>would be significantly harder.

Has anyone added brackets like this to their local C compiler?  Have they
found any problems? Was it hard to do?  If not, would someone try this?
That way it would be harder for the Committee to reject the proposal
on the grounds of "no prior art".

>(4) It is rather late in the process to make this kind of change.

Why was the adoption of the standard delayed for months and months for
another public review period if we don't get a chance to actually change
it?  The next release from ANSI had better have some non-trivial changes
adopted to justify all the delay.

>Comments?  If you think this is a good idea, say so.  It won't get adopted
>without vocal support.
>Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
>Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

Thanks for the proposal.  In case it wasn't apparent, I'm all for this
proposal.

|| Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.ucsd.edu
					or  sdcsvax!sdchem!tps