Re[2]: Empty rule spoiling error reporting

[hz kto]

-----Original Message-----
From: Hans Aberg <address@hidden>
To: hz kto <address@hidden>
Date: Wed, 4 Aug 2004 10:11:02 +0200
Subject: Re: Empty rule spoiling error reporting

> 
> At 03:56 +0400 2004/08/04, hz kto wrote:
> >My grammar contains a lot of optional rules like this
> >
> >opt_something1: /*empty/
> >     |<some grammar>
> >     |<some grammar>
> >     |<some grammar> ...
> >
> >And then
> >
> >rule1 : token3 {...}
> >     | token2 {...}
> >     | opt_something1 token1 {...}
> >
> >
> >When in certain context parser does not see token1,2,3 nor anything
> >non-empty from opt_something1, it matches an empty rule and then, when it
> >starts searching for tokens that could follow next, it only finds token1
> >since it already in the state corresponding to opt_something1.
> >
> >Is it possible to make a check inside error reporting routine for whether
> >the last thing matched was an "empty" rule?
> >Then I could just pop one state of the stack and start error reporting as
> >normally. (I can't really remove optional rules that match empty strings,
> >it would make the grammar many times bigger)
> 
> It sounds as though you are hitting a problem with LALR(1) error reporting.
> In LR(1), when you are in the state that contains the items
>   rule1 -> . token3
>   ...
>   rule1 -> . opt_something1 token1
> and all else coming from . opt_something1, and not a valid token shows up
> in the input, it will report an error immediately.
> 
> Under LALR(1), which Bison uses, the states have been compacted in a way
> that the error may be reported first after some additional rules have been
> reduced (and thus, their actions have been exported). This is the downside
> with LALR(1), deliberately chosen to save parsing table space.
> 
> There is, as far as I know, no way to augment LALR(1) so that it behaves as
> LR(1) in this respect. Bison does not currently support LR(1). You can know
> that a rule has been exported by setting a flag in its action, but I do not
> see how you could exploit that. The states themselves inside the parser are
> just numbers, and you cannot extract any state information about them
> directly; only limited information about lookaheads and actions can be
> extracted from the parsing tables.
> 
> So your best shot is probably to explain more carefully why you need this
> feature, in case you want to stick with Bison.

I have to stick with Bison. Reason why I need this is pretty simple:
I just want to report more possible tokens. As it stands now I report only one 
instead of several in these cases.