Am Montag, 25. September 2006 10:34 schrieb Tim Van Holder: > I don't expect it to reduce foo, I expect it to reduce bar - it's the > foo rule I expect to error out on an unexpected token (and that error > would be avoided by the YYACCEPT).
Err, how do you expect it to reduce to bar? There's no rule either, which allows for foo -> bar *-> A (which would be introduced by star_xyzzy which I posted) so basically, what the bison parser does is very much correct, considering the grammar you posted. > [I now see Hans Aberg's reply - so ok, it's an artifact of LALR(1), I > can live with that - and I hereby second any motion to introduce that > LR(1) option] It's not only an artifact of LALR(1). AFAIK, bison table generation uses $default rules which might create additional (though in the context invalid) reductions, to compress the parsing table, because then reductions don't have to be stored for every input token explicitly. So, the behaviour you're seeing is only partially due to LALR(1), but also to the table compression algorithm employed by bison. An LALR(1) parser would not reduce on state 1 either, because there's no way that you can see lookahead A or F in any form of combined LR(1) states (which state 1 is). > If seeing a portion of the actual grammar where I encountered the > behaviour would be clearer, let me know and I'll post it. Sure, please post that. -- --- Heiko Wundram. ____ _ _ ___ _____ / ___| ___| |__ _ __| | _____ _ __ ___ |_ _|_ _| | | _ / _ \ '_ \| '__| |/ / _ \ '_ \/ __| | | | | | |_| | __/ | | | | | < __/ | | \__ \_ | | | | \____|\___|_| |_|_| |_|\_\___|_| |_|___(_)___| |_| FON 0511-59027954 FAX 0511-59027957 Gehrkens.IT GmbH Mailänder Strasse 2 http://www.gehrkens.it http://www.xencon.net _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
