Re: Yacc poll summary (long)

In article <710@ima.ISC.COM> Pedz Thing <sun!texsun!pollux!bobkat!pedz@ucbvax.Berkeley.EDU> writes:
>I was mis-quoted in the Yacc poll and would like to clarify. In the
>example,
>
>a) statement : IF ( blah ) statement | IF ( blah ) stateement ELSE statement
>b) statement : IF ( blah ) thing
> thing : statement | statement ELSE statement
>
>version a does NOT produce a conflict while version b DOES. (This
>assumes that ELSE has been declared as the lowest precedence operator
>and has left associativity.) This is opposite of what the article said.


Sorry for misquoting. However I have since checked out Perry's assertions.
In fact, both (a) and (b) produce s/r conflicts. (See PS.)


This isn't the fault of 'yacc', or LALR, or LR(k) theory.
The IF/ELSE construction, when stated as baldly as either of the above,
really is ambiguous!


Basically, Perry doesn't seem to want formal methods to work formally:
>This indicates that the construct can be resolved intelligently if the
>conflict from version b is looked upon more as a macro substitution
>rather than a significant production.


I do not know what this means. In any case how could yacc know which
productions are 'significant' to their author and which are 'more ... macro
substitutions'?


In any case, for those who may prefer not to fiddle with yacc's precedences and
associativities, the ambiguity is resolvable with a balanced_if construction
as shown in many textbooks.


P.S. Just for the record, here is my (a).y:


%token IF
%token ELSE
%left ELSE
%token ID
%%
statement
: id '=' id ';' /* trivia for reduction to terminal */
| IF '(' ID ')' statement
| IF '(' ID ')' statement ELSE statement
;
--
Esmond Pitt, Austec International Ltd
...!seismo!munnari!ausmelb!ejp,ejp@ausmelb.oz.au
[As they say in Computing Reviews, this ends the skirmishing, on this
topic at least. -John]
--

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