Re: Help, searching for a yacc group, is there one?

2006-09-25 Thread Heiko Wundram
Am Montag, 25. September 2006 04:15 schrieb Dustin Robert Kick: > I know this is the help-bison group, but I can't find a yacc group > for my problem, and I want to do the basics in yacc, before I move on > to learning bison (mainly for the C++ support). Why'd you want to learn writing parsers wit

Help, searching for a yacc group, is there one?

2006-09-25 Thread Dustin Robert Kick
I know this is the help-bison group, but I can't find a yacc group for my problem, and I want to do the basics in yacc, before I move on to learning bison (mainly for the C++ support). Can anyone point me to the right group for yacc questions?... Would it be ok to post a yacc question here

Re: Odd parser behaviour

2006-09-25 Thread Tim Van Holder
Heiko Wundram wrote: > Am Montag, 25. September 2006 10:34 schrieb Tim Van Holder: >> 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. I consider the topic more or less closed now, but here g

Re: Odd parser behaviour

2006-09-25 Thread Heiko Wundram
Am Montag, 25. September 2006 11:02 schrieben Sie: > I am not sure what additional compressions that Bison uses besides > LALR(1), but the phenomenon is due to these compressions, where one > deliberately merges states, accepting certain additional extra > reductions. The technique is described in

Re: Odd parser behaviour

2006-09-25 Thread Hans Aberg
On 25 Sep 2006, at 10:45, Heiko Wundram wrote: [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 rule

Re: Odd parser behaviour

2006-09-25 Thread Heiko Wundram
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 ru

Re: Odd parser behaviour

2006-09-25 Thread Tim Van Holder
Heiko Wundram wrote: > Am Montag, 25. September 2006 08:49 schrieben Sie: >> >> >> Except that it actually takes the entire "opt_C opt_D E" path - if an A >> is seen, it will reduce opt_C and opt_D then error out on the "E" rule, >> while it should have reduced up to the "bar" nterm, and only try

Re: Odd parser behaviour

2006-09-25 Thread Hans Aberg
On 25 Sep 2006, at 09:01, Heiko Wundram wrote: Bison reduces everything as far as possible before erroring out (that's a general properly of LALR(1)-parsers), but here, there's absolutely no rule for it to do what you want, so the error occurs on the shift on the expected E. Actually, LR

Re: Odd parser behaviour

2006-09-25 Thread Heiko Wundram
Am Montag, 25. September 2006 08:49 schrieben Sie: > > > Except that it actually takes the entire "opt_C opt_D E" path - if an A > is seen, it will reduce opt_C and opt_D then error out on the "E" rule, > while it should have reduced up to the "bar" nterm, and only try to > error out then (except