Is there a replacement for yychar
Hi,
I have a problem compiling my parser generated by Bison 3.0.2. For
error recovery I use the lookahead variable `yychar' like this:
...
| error { if (yychar != '}' && yychar != ';') yyclearin; else
yyerrok; }
;
But in commit 39be90223b73a42d249f99cdf283c4ab46a10a21 this variable
was removed from $parser_class_name::parse(), which means my grammar
does not compile for recent bison releases anymore. Is there a
replacement for `yychar', which also works for older bison versions,
like 2.7? The manual still mentions `yychar', and suggests nothing there
and I am little clueless. I could workaround that within my buildsystem,
but I would prefer keeping things simple.
Cheers,
Matthias
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Is there a replacement for yychar
> On 11 Dec 2014, at 19:17, Matthias Simon wrote:
>
> Hi,
>
> I have a problem compiling my parser generated by Bison 3.0.2. For error
> recovery I use the lookahead variable `yychar' like this:
>
> ...
>| error { if (yychar != '}' && yychar != ';') yyclearin; else yyerrok; }
>;
>
> But in commit 39be90223b73a42d249f99cdf283c4ab46a10a21 this variable was
> removed from $parser_class_name::parse(), which means my grammar does not
> compile for recent bison releases anymore. Is there a replacement for
> `yychar’, ...
Comparing the parser .cc and .hh old and new suggests it is yyla.type.
> ...which also works for older bison versions, like 2.7?
It is probably best to stick to the newer version only, to avoid bugs.
> The manual still mentions `yychar', and suggests nothing there and I am
> little clueless. I could workaround that within my buildsystem, but I would
> prefer keeping things simple.
Hopefully the developers chime in.
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Is there a replacement for yychar
It is probably best to stick to the newer version only, to avoid bugs. Sadly, that is not really an option for me (due to outdated targets, high variety of developer-machines, difficulties with non-standard installations,...). Hence, I probably will workaround in the build-system like: if [ $($BISON --version | head 1 | ...) -lt 3 ]; then write_header_config "#define yychar yyla.type" fi ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: How to implement optional semicolon rules
Hi again, I want to share my solution with you and the future generations stumbling across similar problems ;) I decided implementing the exact semicolon rules was not worth the trouble: - The grammar is already quite complex and difficult to understand, changing these to respect semicolon rules is a waste of effort - Let bison instruct the lexer when to inject a semicolon, like>, did not work out, because when the mid-action is executed, bison already has read the next token, so it is to late to inject. But moving this action one token earlier would cause the lexer to inject semicolon in the wrong places. So, I just made all semicolons optional and tried to cope with the conflicts. I just had two kinds of conflicts ( \o/ ), actually. One --probably a quite common-- was: Stmt: ... | "return" | "return" Expression | Assignment Expression and Assignment both may begin with an identifier. So bison does not know whether to shift for the second option or to reduce the first and start with the Assignment. The default --shifting the Expression-- totally works for me. First because, having an Assignment right after a `return' does virtually never appear, secondly the type-checker is able dectect a `mis-shifted' return and could suggest an explicit semicolon. Problem solved. Thank you a lot for your support :) Cheers, Matthias ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
