yacc with multiple attributes

[blandy at cornell.UUCP]

In article <838 at garth.UUCP> smryan at garth.UUCP (Steven Ryan) writes:
>In article <16345 at brl-adm.ARPA> jbaker at ee.ucla.edu (Joe Baker) writes:
>
>I am currently doing something in this style and found out too late about
>major Yacc bugs/features/problems/characteristics: although the stack is
>very good about passing up synthesised attributes, it is terrible at passing
>down inherited attributes.
>
>I have patched around this by inserting semantics into a production to set
>aside inherited attributes. Yacc converts these embedded semantics into a
>null production, but seems unable/unwilling to compute lookahead through
>these null productions. This has distorted the language and its grammar.
>

Yacc is actually resonably capable at this;  the problem you've having
with lookahead comes from the fact that you're using unnamed actions;
yacc assumes that all unnamed actions are different, and so cannot do
much lookahead beyond them.

Yacc will choke on:

prod:
   a { fiddle something } b c { first result }
 | b { identical fiddle } b c { different result }
 ;

because it doesn't realize that the two fiddles are identical; because it
generates a different null production for each, that grammar is truly
not LR(1).

Try replacing the above with:

FIDDLE:
    /* empty rule */ { the same fiddle as above }
   ;

prod:
    a FIDDLE b c { first result }
  | a FIDDLE b c { second result }
  ;

In this case, yacc knows that the two fiddles are the same, and so can 
generate a parser for the thing.

Right?


--
Jim Blandy - blandy at crnlcs.bitnet
"insects were insects when man was just a burbling whatisit."  - archie