Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!uw-beaver!cornell!blandy From: blandy@cornell.UUCP Newsgroups: comp.lang.c Subject: Re: yacc with multiple attributes Message-ID: <18773@cornell.UUCP> Date: 1 Jul 88 14:44:25 GMT References: <16345@brl-adm.ARPA> <838@garth.UUCP> Sender: nobody@cornell.UUCP Reply-To: blandy@cs.cornell.edu (Jim Blandy) Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 50 In article <838@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: >In article <16345@brl-adm.ARPA> jbaker@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@crnlcs.bitnet "insects were insects when man was just a burbling whatisit." - archie