Re: Dangling else

> I have a silly suggestion--avoid the whole problem. The dangling-else
> syntax problem was solved over 40 years ago. But apparently the one
> time exercise of adding the extra productions is too burdensome, so
> we must instead use ever more complicated rules for parser generators.
>
> The first language with CF grammar specified, Algol-60, managed to
> to show how to parse expressions according to precedence and
> associativity by simply writing the rules a particular way. But again
> this is too burdensome; instead it is better to add all these
> obscure %xyzzy directives to parser generators.


Early programmers managed to show how to write programs with
conditionals and loops and function calls simply writing their
programs a particular way. But apparently the one time exercise of
adding these particular GOTO statements is too burdensome, so we must
instead use ever more complicated flow-control constructs for
programming languages.




I find the "make the programmer do it" approach to precedence
completely unsatisfying. I'd rather just have "expression" and then
give a list of operator precedences somewhere than have to compile the
precedences into the grammar by hand with "postfix_expression",
"cast_expression", "unary_expression", etc. Creating the equivalent
no-precedence-table version of a grammar is a completely mechanical
and tedious transformation that a well-written computer program is
much less likely to make a mistake doing than a human.


It doesn't make any sense at all to me to say, as the ANSI C grammar does:


relational_expression
: shift_expression
| relational_expression '<' shift_expression
| relational_expression '>' shift_expression
| relational_expression '>=' shift_expression
| relational_expression '<=' shift_expression


Should I really have to know, when writing the relational_expression
rules, that shift_expression is the next level down in the precedence
hierarchy? What if some new operator comes along later that I want
to put between them? Then I have to go find all the rules that implicitly
"know" that shift comes after relational.


If there's a precedence table, I just add the new "expression" rules
and then insert a new line in the precedence table. How is this a bad
thing?


Russ


[I don't know anyone who thinks that C's million levels of precedences
are a good idea. Back in the 1950s, it seemed reasonable in Fortran
for exponentiation to bind tighter than multiplication and division
which bound tighter than addition and subtraction, in line with most
mathemetical notation, and then it got away from us. How do you like
the APL rule that everything binds and associates the same? -John]

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