Re: push parser implemenation

[Bob Rossi]

On Thu, Sep 07, 2006 at 10:44:10AM -0700, Paul Eggert wrote:
> Bob Rossi <address@hidden> writes:
> 
> > Here is what the user will do in push-parser mode:
> >   struct yypvars *ctx = yypvarsinit ();
> >   do {
> >     set_yychar (ctx, yylex ());
> >     ctx->yylval = yylval;
> >     yyparse (ctx);
> >   } while (get_yyresult (ctx) != 0);
> >   free (ctx);
> 
> There may be some minor namespace issues here: in C, all symbols the
> parser exports should start with yy or YY.

I now have:
  int yyresult_get (void *PVVOID);
  void yychar_set (void *PVVOID, int yychar);
  void yylval_set (void *PVVOID, YYSTYPE yylval);


> I don't quite follow this part:
> 
> >     set_yychar (ctx, yylex ());
> >     ctx->yylval = yylval;
> 
> Why use one method to set yychar, and the other to set yylval?
> Shouldn't the same method be used to set both?

O, I see. Akim actually wrote that part. He was accessing the parser 
variable directly because I didn't have the appropriate set function.
It's been added as displayed above. 

If you are saying "one method" for "one technique of setting data", yes
I agree, we should either use accessor functions or direct access. If
you mean "one method" for "one function should be able to set both
values", I don't think that's the best path to go down.

> > 1. I've Added the %push-parser option
> >    push.c works in both push and pull mode. If you set the %push-parser 
> >    option, it will work in push mode, otherwise pull mode.
> 
> Is it easy to switch between push and pull mode at runtime?  If so,
> it should be a runtime switch.  (If not, then not.  :-)

I could probably add that functionality with a few changes to the
parser, but currently it doesn't do it.

> >    It was mentioned that the pull parser could be implemented be
> >    using the push mode.  Should I do this?
> 
> Sorry, I don't know the technical issues here.  Would it slow down
> pull parsing to implement it in the push context?  Would it change
> the documented (or undocumented :-) API?

Currently, push.c slows down the yacc parsing by between 2-8%, reported
by me and Akim. I'll come up with more results soon. Let me look more 
into timeing issues before we continue on this.

> > 2. struct yypvars and yypvarsinit
> >     Adding the struct yypvars that contains all the data needed to do the
> >     parse. yypvarsinit is a user visible function that inits the struct.
> >     Should I add a yypvarsdestroy? or just let the user do a free ()?
> 
> Is there any reason a destroy op might want to do anything other than
> a simple free any time in the foreseeable future?  If not, then free
> is fine.

No, I don't think there is. I thought the free() would be fine. I was
just wondering if C++ people would use delete. Made me wonder if we
should write a pvvarsdestroy function.

> Is there any reason struct yypvars should be opaque?

The only reason I made it opaque is because it seemed that never before
had any of the variables been visible in the global scope. When using
the pure parser, only 4 variable were made visible. Do you want me to
make them all visible?

> > 3. yychar, yylval, yynerrs, and yylloc (external parser variables)
> >     These variables remain external in the default parser. However, in
> >     the pure and push parser they go in the struct yypvars. So, I'm 
> >     currently making accessor functions to access them. I currently only
> >     have:
> >     int get_yyresult (void *PVVOID);
> >     void set_yychar (void *PVVOID, int yychar);
> >     because they are the only 2 I need. However, should I just generate
> >     all 4 pairs of set/get functions for yychar, yylval, yynerrs, and
> >     yylloc?
> 
> I'd just generate the ones you need for now.  However, their names
> should start with yy to avoid namespace collision.

Got it. that's done.
> 
> > 5. Test suite.
> >     What should I do to modify the test suite?
> 
> It'd be nice if we could try several tests in both push and pull mode.

Yes, I'll run the entire testsuite with the push.c skeleton and report
back.
> 
> > 6. Documentation
> >     New chapter?
> 
> You've saved the hardest part for last.  :-)

> I don't think it should be a new chapter; the text needs to be
> interspersed when needed.  You can start looking for areas by seeing
> where the existing documentation talks about pure parsers.

After we've done everything else, I'll get back to this. Thanks!

Bob Rossi