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
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
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
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
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
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
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
Heiko Wundram wrote:
> Am Freitag, 22. September 2006 15:26 schrieb Tim Van Holder:
>> I would expect this to accept any input starting with A(B|C?D?E)+,
>> but in practice, it only accepts input starting with A(B|CDE)+,
>> because for the xyzzy nterm, it always tries to reduce the opt_C.
>>
>> >Fr
Am Freitag, 22. September 2006 15:26 schrieb Tim Van Holder:
> I would expect this to accept any input starting with A(B|C?D?E)+,
> but in practice, it only accepts input starting with A(B|CDE)+,
> because for the xyzzy nterm, it always tries to reduce the opt_C.
>
> >From the .output:
>
> state 1
Given a simple grammar
%token A B C D E F
%%
foo
: bar { YYACCEPT; }
;
bar
: A plus_xyzzy
;
plus_xyzzy
: xyzzy
| plus_xyzzy xyzzy
;
xyzzy
: B
| opt_C opt_D E
;
opt_C
:
| C
;
opt_D
:
| D
;
%%
I would expect this to accept any input starting with A(B|C?D?E)+,
but in practice, it only accept
10 matches
Mail list logo
