Re: incorrect yychar for unambiguous GLR

[Joel E. Denny]

On Wed, 11 Jan 2006, Joel E. Denny wrote:

> +In any semantic action, you can examine @code{yychar} to determine the type 
> of
> +the look-ahead token present at the time of the associated reduction.
> +After checking that @code{yychar} is not set to @code{YYEMPTY} or 
> @code{YYEOF},
> +you can then examine @code{yylval} and @code{yylloc} to determine the
> +look-ahead token's semantic value and location, if any.
> +In a nondeferred semantic action, you can also modify any of these variables 
> to
> +influence syntax analysis.

I'm now thinking that last statement may not be true. "yacc.c" seems to 
use yychar to direct the parse, so a semantic action can redirect the 
parse by changing its value.  However, "glr.c" seems to use yytoken.

Below is a test case I'll add at some point.  As it stands, there's no 
syntax error.  Add %glr-parser and there is a syntax error because yytoken 
is not set correctly.  Change:

  yychar = 'a';

to:

  *yystackp->yytokenp = YYTRANSLATE ('a');

and the syntax error goes away.

Why must the lookahead token be maintained in two variables?  Why not just 
maintain yychar and invoke YYTRANSLATE whenever yytoken is needed?

Joel

-----------------------------------------------
%{
  #include <stdio.h>
  static int yylex (void);
  static void yyerror (char const *);
%}

%%

start:
  look 'a' {}
  ;
look:
  { yychar = 'a'; }
  | 'b' {}
  ;

%%

static int
yylex (void)
{
  return 0;
}

static void
yyerror (char const *msg)
{
  fprintf (stderr, "%s\n", msg);
}

int
main (void)
{
  return yyparse ();
}