[Top][All Lists]

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

Re: push parser

From: Joel E. Denny
Subject: Re: push parser
Date: Mon, 18 Dec 2006 15:16:12 -0500 (EST)

On Mon, 18 Dec 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> > Attached is a rather large patch that I believe fixes all the above.
> Thanks for looking into it.  My, there is a lot of clever code here
> without much explanation....  But I'll give some quick feedback anyway.

I should document the push.c changes better.  I got too lazy at the end of 
that coding session.  Maybe later today.

> >   #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.

> It breaks Bison
> itself, for example:

Bison doesn't use %push-parser.

> Perhaps you can come up with a better way of solving the same problem.

We could add another Bison declaration to enable a yyparse function.

> While we're on the subject, the "&yylex" isn't portable either.  yylex
> might be a macro, or it might not have exactly the signature you
> expect (it might return 'wchar_t', say).

Thanks.  Bummer.  Again, we'd need something like %pull-parser.

On the other hand, we could just say that: if someone wants to enable 
%push-parser, they'll have to understand that it actually does change a 
few things.  Maybe that's not as convenient.

> +     YYCOPY (&yyptr->Stack##_alloc, Stack, yysize);                  \
> +     Stack = &yyptr->Stack##_alloc;                                  \
> The current yacc.c doesn't use ##, since ## is not portable to K&R C.

Thanks, I think I can work around that.

reply via email to

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