Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!claris!sts!cohesive!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c
Subject: Re: precedence of && (was: precedence of ?:)
Message-ID: <8034@goofy.megatest.UUCP>
Date: 14 Sep 89 02:57:22 GMT
Organization: Megatest Corporation, San Jose, Ca
Lines: 71

In article <3242@solo12.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>... there is no legal way to parse
>>	0 && i = 0
>>as
>>	(0 && i) = 0
>>but there is a legal parse as
>>	0 && (i = 0)


According to the the grammar at the back, there is no legal way to
parse this at all. But, according to the precedence table on page 53
it does indeed parse as

         <0 && i> = 0

So if you believe the table, Mr. Gwyn had it exactly backwards,
because the following is NOT a legal parse, according to either
the precedence table or the grammar:

	0 && <i = 0>

But let's be generous and give him partial credit, assuming that
the grammar is the Law and the precedence table is for amusement
purposes only.

Of course, even if you do parse it according to the precedence rules,
you still get an error, because (0 && i) is not a legal
L-value for an assignment operator. No surprise there. That's the way
it was in old C.

Like I said, it takes a bit of doing, but you can show that according
to the grammar, it does not parse at all.  But, interestingly,
you can use parentheses to force it to parse the way the precedence
rules say it does:

      ( 0 && i ) = 0

The grammar will parse that.  Naturally, it parses as 

      <0 && i> = 0

... and we are back to the old not-an-L-value-problem.

Allow me to test-burn my flamethrower for just one short burst...

The grammar at the back of the book, presumably close to the ANSII
standard, does not use precedence for "disambiguation". Too easy, I guess.
Instead it has lot's of very confusing different kinds of expressions.
Among them are "assignment-expression" and "logical-and-expression",
for example. A crock, it you ask me. Presumably, (if they got it right),
those rules imply the precedence given in the K&R table, except that, as
we saw, some expressions are rejected by the grammar rather than by
"semantic" rules, such as the L-value rule. I would like to hear the
rationale behind creating such a convoluted grammar, when the precedence
rules are so much easier to understand.  I can just picture a beginning
programmer trying to push and pop his mental stack through that maze
as he tries to figure out why his program is in error.  Besides, the
precedence rules are also much better for compiler-writers, too! It's easy
to go from a precedence table to a grammar like the published one, although
I can't think of any reason why you would want to. But the reverse, going
from the grammar to the precedence table is difficult. If it were easy, we
wouldn't be having this discussion, right?  I think they really botched
it there. Big time.

Ah. That's much better. Thank you.

(If I ever write a C compiler, I'm going to use precedence, and if
anybody ever complains that they got an "L-value" error message when they
distinctly asked for a "syntax" error message, maybe I'll offer to wash
their car.)