Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ll-xn!mit-eddie!husc6!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP
Newsgroups: comp.lang.c
Subject: Paying attention to parentheses
Message-ID: <2103@mmintl.UUCP>
Date: Thu, 9-Apr-87 18:55:57 EST
Article-I.D.: mmintl.2103
Posted: Thu Apr  9 18:55:57 1987
Date-Received: Wed, 15-Apr-87 04:32:15 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <532@omepd>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 102

[This is a reposting, since I don't think the original got out.  My apologies
if this is a duplication.]

OK, I'm going to try this once again.  I think the ANSI committee is doing
the right thing by keeping the current C rules for respecting parentheses,
and providing an alternative, but the syntax for the alternative they are
providing is *horrible*.

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.  The result is much more readable.  Consider
the following examples from an article by Jim Valerio (532@omepd):

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));
		x = (x + eight) - eight;
		while (((b+one)-b)-one == zero);
		if ((a+betam1)-a != zero)

Under the proposed standard, these would be:

	x = +(+(one + x * a) - one) * 16.0;
	y = x / (+(half + x * half) * +(+(half - x) + half));
	x = +(x + eight) - eight;
	while (+(+(b+one)-b)-one == zero);
	if (+(a+betam1)-a != zero)

With my proposal, one would instead have:

	x = [[one + x * a] - one] * 16.0;
	y = x / ([half + x * half] * [[half - x] + half]);
	x = [x + eight] - eight;
	while ([[b+one]-b]-one == zero);
	if ([a+betam1]-a != zero)

(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.  For example, it might well suffice to write
"x = ([one + x * a] - one) * 16.0;" for the first statement.)

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 suspect
it would avoid reactions like the following (from the same article):

I'm even reasonably happy with the
parenthesis situation, since I just overspec my compiler and require it
to preserve parentheses for floating-point operations.  (Sure, that's
not encouraging portable code, but it's an easy dependency to document
and consequently doesn't bother me much.)

Most likely, Jim would instead specify that brackets be used instead of
parentheses for all floating point expressions.

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".

So what?  They aren't hurting themselves any.  Anyone seriously interested
in writing very efficient code should have a better understanding of the
language than that; meanwhile programs will work whenever they would have
worked using only parentheses.

(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.

(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.

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

That it is.  I can only say that if I had been aware of the situation sooner,
I would have said something earlier.  Maybe the committee should have more
studiously avoided adding functionality, so that things could have been
tried before being standardized on.

Still, I think the current proposal is quite ugly, and no arguments about
timeliness should let us put ugliness into the language, when a better
alternative is available.  Nor is this a really major change to the
standard; one could add it to a formal syntax in a few minutes, and adjust
the specification in relatively short order.

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