Re: push parser

[Joel E. Denny]

On Mon, 18 Dec 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> >> >   #define yyparse() yypull_parse (NULL, &yylex)
> >> 
> >> This will break a lot of code, I'm afraid, since many apps assume
> >> yyparse is a true function and is not a macro.
> >
> > No apps assume that for %push-parser since no apps use %push-parser yet.
> 
> OK, but I want push.c to go away; I want its contents to replace
> yacc.c.  Otherwise it's too much of a maintenance hassle.  (Hence
> I want to get rid of the by-hand steps one must currently use after
> "cp push.c yacc.c".)

I agree, but as far as I can tell that's possible with my patch.....

> Adding this "#define" unconditionally makes this goal harder to
> achieve.  It should be fairly easy to put in the #define only for the
> cases where it's harmless to use a #define, and stick with the
> traditional approach otherwise.  (The problem with yylex being a macro
> could be treated similarly.)

One thing that may not be clear: the #define only happens if you declare 
%push-parser.  push.c generates the normal function yyparse if you don't. 
If I had documented my changes like I should have, this might be more 
obvious.  Sorry.

> > We could add another Bison declaration to enable a yyparse function.
> 
> That's extra user complexity.  I'd rather have Bison do the right
> thing without bothering the user.

Assuming the right thing is for Bison to generate a Yacc-compatible 
interface without yylex-dependence even when %push-parser is declared, I 
don't think that's possible.  yyparse depends on yylex.  Either the user 
is forced to define yylex, or he's forced to declare when he wants a 
yyparse, or we use macros to prevent calls on yylex when yyparse isn't 
referenced in the code.  I can't think of any other alternative.  You?