Re: Dangling else

"Russ Cox" <>
6 Mar 2006 02:14:09 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: Dangling else (SM Ryan) (2006-03-05)
Re: Dangling else (SM Ryan) (2006-03-05)
Re: Dangling else (=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=) (2006-03-05)
Re: Dangling else (2006-03-05)
Re: Dangling else (Dave Thompson) (2006-03-05)
Re: Dangling else (Dmitry A. Kazakov) (2006-03-06)
Re: Dangling else (Russ Cox) (2006-03-06)
Re: Dangling else (Marco van de Voort) (2006-03-11)
Re: Dangling else (Brian Inglis) (2006-03-11)
Re: Dangling else (2006-03-14)
Re: Dangling else (Karsten Nyblad) (2006-03-15)
Re: Dangling else (Hans-Peter Diettrich) (2006-03-15)
Re: Dangling else (Marco van de Voort) (2006-03-15)
[1 later articles]
| List of all articles for this month |

From: "Russ Cox" <>
Newsgroups: comp.compilers
Date: 6 Mar 2006 02:14:09 -0500
Organization: Compilers Central
References: 06-03-011
Keywords: syntax, design
Posted-Date: 06 Mar 2006 02:14:09 EST

> have (fully-ordered) precedence. In fact C has two places that aren't
> expressible as precedence:
> - (int) x is - ( (int) x ) but (int) -x is (int) (- x)
> x = a ? b , c : d is x = (a? (b, c): d) but
> a ? b : d , e is (a?b:d) , e.
> C++ shares the former but partially fixes the latter by going down to
> assignment-expression (but still not expression).

I'm not certain I understand what you mean here
by "aren't expressible as precedence". At least as I think
about them, precedences come into play only when deciding
how to resolve a shift/reduce conflict. If your rules are:

expr: - expr
expr: ( type ) expr

and you're trying to parse -(int)x or (int)-x, there's no
conflict, and thus no consulting of precedence.

Similarly, in the ?: case, the ? and : must always be balanced
and thus act as left and right delimiters just as parentheses do:
there's no shift/reduce conflict and only one possible way to
parse a ? b ? c : d : e. So you can just say that an arbitrary
expression is inside the ? and :.

Getting back to your original comment, I think you mean
either that precedence tables aren't enough to explain
the examples you gave or that "compiling out" the precedence
as done in the ANSI C grammar isn't enough to explain them.
But I don't think either statement is true.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.