Re: push parser implemenation

[Bob Rossi]

On Tue, Sep 12, 2006 at 11:25:11AM -0700, Paul Eggert wrote:
> Bob Rossi <address@hidden> writes:
> 
> > This would mean that the user would have to do "%push-parser
> > %parse-param (void *PVVOID)" in order to get a valid push parser,
> > instead of just doing %push-parser.  I think this would cause a lot
> > of user confusion.
> >
> > Plus, the yyparse function internally uses the parameter PVVOID, in
> > order to access the push parser.
> 
> Sorry, I don't know the details of the yyparse function, but I'll
> try to explain my motivation here.
> 
> If there's an opaque type that the user must pass to yyparse no matter
> what, then you're right, this should be built in: %parse-param should
> be used only for extra parameters that the user wants to pass to the
> parser.

OK, this is the case.

> However, all other things being equal I'd rather that the opaque type
> were not void *.  In C, it's better to make it struct yysomething *,
> where struct yysomething is an incomplete type.  That makes it more
> likely that type errors will get caught at compile time, since struct
> yysomething * is compatible only with itself, whereas void * is
> compatible with lots of invalid pointer types.

OK, the actual type being passed into yyparse is 'struct yypvars *'
from seen below.
    struct yypvars *ctx = yypvarsinit ();
    do {
      yychar_set (ctx, yylex ());
      yylval_set (ctx, yylval);
      yylloc_set (ctx, yylloc);
      yyparse (ctx);
      status = yyresult_get (ctx);
    } while (status == 4);
    free (ctx);

I can make yyparse look like:
  void yyparse (struct yypvars *YYPVARS);

However, the type 'struct yypvars' will not be visible in the users
parser if they simply include calc.h (the bison header file). They 
will have to forward reference it themselves, or put the user written
parser code at the bottom of the bison skeleton, like the testsuite
does.

Does this sound good to you?

Thanks,
Bob Rossi