Re: push parser

[Bob Rossi]

On Wed, Sep 27, 2006 at 11:42:36AM -0700, Paul Eggert wrote:
> Bob Rossi <address@hidden> writes:
> 
> > 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.
> 
> "global and local variables in the function"?  I thought that
> push parsers were always pure, so that there was no need for
> global variables.

When I said "global and local variables" what I meant was, yypushparse
copies the contents of ctx into the local variables declared in
yypushparse and into the global variables defined in the output parser.
In particular, all of the copies are to local variables except the 4
global variables users traditionally have been able to use.

There are no need for global variables, you are correct. The patch I
originally made simply did not do away with the 4 global variables that
the user traditionally used. I was a afraid this would break backwards
compatibility for many users. So instead, I simply left the 4 globals,
and also put the 4 variables in the context. Now, when the user called
yypushparse, (before they had to do yylloc_set...) they have to supply
the variables they are using so the ctx can know about them.

This was the simplest solution at the time. Now I'm wondering if it
needs cleaning up, or should simply stay the way it is.

> If yypushparse simply copies context to local vars, then perhaps
> we should remove lval and lloc info from the context, and stick
> with something like this interface:
> 
>  {
>    struct yypvars *ctx = yypvarsinit ();
>    int status;
>    do {
>      YYSTYPE my_lval;
>      YYLTYPE my_lloc;
>      status = yypushparse (ctx, my_lex (&my_lval, &my_lloc),
>                            &my_lval, &my_lloc);
>    } while (status == YYPUSH_MORE);
>    free (ctx);
>    return status;
>  }
> 
> Or perhaps we want to simplify it a bit, as follows:
> 
>  {
>    struct yypvars *ctx = yypvarsinit ();
>    int status;
>    do {
>      YYTOKTYPE token_info;
>      status = yypushparse (ctx, my_lex (&token_info), &token_info);
>    } while (status == YYPUSH_MORE);
>    free (ctx);
>    return status;
>  }

Be careful with the above examples, function parameters can be 
evaluated in either direction, and in the case above, if the compiler
evaluates right to left, you will get undesired results.

> 
> where YYTOKTYPE is defined to be a structure containing a YYSTYPE (and
> an YYLTYPE, if locations are used).
> 
> Then, when yypushparse starts up, it can (if it likes) copy my_lexinfo
> to its local vars.  But I don't see why it would bother; it can simply
> use the address it's passed, and not make copies of the variable in
> question.

Yes, exactly, these are the two choices I had in mind, sorry to take
such a round-about path in explaining myself. OK, I see things much
clearer now.

Those variables should definatly not be global, cause it will make the
push parser not reentrant. Also, yacc.c in pure mode doesn't place those
variables in global scope. That means that putting those variables in
the ctx would not break backwards compatibility. So yes, I should do
away with the global variables.

With this in mind, I have a question. Is it expected by the user that
the data for yylloc and yylval will be created for the user by bison?
(meaning that bison will declare a variable for each of this for you)
or does the user expect to have to do this on there own? From your 
comments below, I'm assuming that the user will think it's there 
responsibility to do this. In that case, I like the idea of having
them declare the data, and passing it into yypushparse. In this case,
the ctx cares nothing about this data.

> > 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?
> 
> I'd say the latter.

I think we agree on this.

> > Does the
> > parser modify either of these variables?
> 
> No, just as it doesn't modify yylloc or yylval.

OK, so the user just has to set the data, not get it. This clearly shows
that having the user pass it into yypushparse is good enough.

> > 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.
> 
> They shouldn't be global, surely.  I thought this stuff was supposed
> to be reentrant.

Agreed.

Thanks for you time,
Bob Rossi