Path: utzoo!attcan!uunet!husc6!bloom-beacon!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: possible operator precedence bug?
Message-ID: <9450@haddock.ima.isc.com>
Date: 14 Oct 88 16:56:07 GMT
References: <751@mcrware.UUCP> <4700025@m.cs.uiuc.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 25

In article <4700025@m.cs.uiuc.edu> kenny@m.cs.uiuc.edu writes:
>karl@haddock.ima.isc.com writes:
>>[someone writes:]
>>>Operator precedence only comes into play when there is ambiguity.  Here
>>>there is no ambiguity - the above can only be legal C when parsed one
>>>way, so there is no need to turn to operator precedence.
>>
>>This turns out not to be the case.  For example, "a + b=0" ...
>
>Come on, Karl, you can do better than that.

You're right.  The point I was trying to make was that the comment was
misleading, as it suggests that the compiler ought to parse "a+b=0" as
"a+(b=0)" because it's the "only way that yields legal C".  It doesn't work
that way, of course, but the stereotypical "dumb user" won't know that.

When I wrote that example, I had the dpANS but not K&R in front of me, and I
didn't realize that the latter uses an ambiguous grammar.  Using the ANSI
grammar as a base, I think the analogy holds: "a?b,c:d" can only be parsed one
way, so there is no need to parenthesize (b,c).  "a+b=0" can only be parsed
one way, which then fails to make sense semantically.  "Precedence" is just a
word you can use to help understand the situation; it's not used in the formal
grammar, which is already unambiguous.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint