Re: Dangling else

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


Russ

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