bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: push parser


From: Bob Rossi
Subject: Re: push parser
Date: Wed, 27 Sep 2006 13:56:17 -0400
User-agent: Mutt/1.5.11

On Wed, Sep 27, 2006 at 09:50:46AM -0700, Paul Eggert wrote:
> Bob Rossi <address@hidden> writes:
> 
> > How is the interface coming along? Do you see any other
> > modifications that should take place?
> 
> Sorry, I'm not sure what you mean here.  The interface is improving,
> yes.

OK, good.

> > {
> >   struct yypvars *ctx = yypvarsinit ();
> >   int status, ch;
> >   do {
> >     ch = yylex ();
> >     status = yypushparse (ctx, ch, &yylval, &yylloc);
> >   } while (status == YYPUSH_MORE);
> >   free (ctx);
> >   return status;
> > }
> >
> > One potential problem that I can think of is that the push parser still 
> > allows the user to use the global variables yylval and yylloc.
> 
> It doesn't _require_ that, does it?  It merely _allows_ it.  One could
> use code like this instead:
> 
>  {
>    struct yypvars *ctx = yypvarsinit ();
>    YYSTYPE my_lval;
>    YYLTYPE my_lloc;
>    int status, ch;
>    do {
>      ch = my_lex (&my_lval, &my_lloc);
>      status = yypushparse (ctx, ch, &my_lval, &my_lloc);
>    } while (status == YYPUSH_MORE);
>    free (ctx);
>    return status;
>  }
> 
> This would be more reentrant, etc.  We should use it as an example,
> rather than the nonreentrant version.

OK, done.

> > The push parser also has it's own version of these variables in the
> > yypvars struct. I don't know if it's a good thing or a bad thing
> > that we still use the global variables. At a minimum, it will allow
> > users to not have to modify there lexers. What do you think?
> 
> I didn't remember that the push parser has its own copy.  If the push
> parser must have its own version of these variables *ctx, perhaps we
> should make them visible to the user.  E.g.,
> 
>  {
>    struct yypvars *ctx = yypvarsinit ();
>    YYSTYPE *my_lval = yypv_lval (ctx);
>    YYLTYPE *my_loc = yypv_loc (ctx);
>    int status;
>    do {
>      status = yypushparse (ctx, my_lex (my_lval, my_loc));
>    } while (status == YYPUSH_MORE);
>    free (ctx);
>    return status;
>  }
> 
> or even this, assuming the lexer is changed to use yypv_lval,
> yypv_loc:
> 
>  {
>    struct yypvars *ctx = yypvarsinit ();
>    int status;
>    do
>      status = yypushparse (ctx, my_lex (ctx));
>    while (status == YYPUSH_MORE);
>    free (ctx);
>    return status;
>  }

Well, this is what is happening. Either the user is using there own 
version of the yylval and yylloc, or they are using the global vars
that are provided. Either way, when they call yypushparse, it copies
that data into ctx. yypushparse then uses the data in ctx. The first
thing the yypushparse function does is copy the ctx variables to the
global and local variables in the function, so that yypushparse can
operate on the local/global variables and not know anything about the 
ctx.

So, the question is, should we include these 2 particular variables in
the ctx, or assume the user is responsible for storing and using this
data, along with passing it into the yypushparse function? Does the
parser modify either of these variables? If it did, the user may wish
to see what they are after the yypushparse function is called, and
currently there is no way to do that.

Not to be totally annoying, but the variables 'int yychar;', and 
'int yynerrs' also fall under this same category. That is, they are
both declared global and in the ctx.

Below is the snippet of code from a generated push parser.

Thanks,
Bob Rossi


/* The lookahead symbol.  */
int yychar;

/* The semantic value of the lookahead symbol.  */
YYSTYPE yylval;

/* Number of syntax errors so far.  */
int yynerrs;
/* Location data for the lookahead symbol.  */
YYLTYPE yylloc;


struct yypvars
  {
/* The lookahead symbol.  */
int yychar;

/* The semantic value of the lookahead symbol.  */
YYSTYPE yylval;

/* Number of syntax errors so far.  */
int yynerrs;
/* Location data for the lookahead symbol.  */
YYLTYPE yylloc;







reply via email to

[Prev in Thread] Current Thread [Next in Thread]