Your solution attempts to modify lexer state from the parser,
which ties you to what would, ideally, be the implementation-dependent
details of precisely when the parser invokes the lexer.
Also seems like your solution only catches one side of the issue,
if I've understood it correctly.
AFAIK, bison doesn't support predicates for plain
LR parsing, but so long as all hacks are
on the table... Suppose that your lexer maintained
two global variables: PreviousToken and CurrentToken.
Then perhaps this would work:
Semicolon
: ';'
| { if(PreviousToken != '}' && CurrentToken != '}')
Error("Expecting ';' to end statement\n"); }
Still ties you to the details of parser lookahead,
but tries to handle both cases and perhaps makes
the correct guess about when lookahead occurs...
On Tue, Nov 18, 2014 at 3:53 PM, Matthias Simon <m...@5nord.de> wrote:
> Thank you for all your answers. The language I am trying to implement is
> quite complex, unfortunately. It has various --and also optional--
> block-like structures. Hence I personally would prefer setting the context
> variable for the lexer, over rearranging the whole grammar just for this
> nagging semicolon-rule. What I tried was following:
>
> Block
> : '{' Statements '}'
> ;
>
> Statements
> : Statement Semicolon
> | Statements Statement Semicolon
> ;
>
> Semicolon
> : { driver.expect_semicolon = 1; } ';'
> ;
>
> If expect_semicolon is set and the lexer reads a '}', it then will unput
> this character and return a ';' instead. My problem is, expect_semicolon is
> set _after_ the next is already read and the ';'-injection is too late. What
> am I missing?
>
>
> _______________________________________________
> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
