bison-patches
[Top][All Lists]
Advanced

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

Re: push parser


From: Bob Rossi
Subject: Re: push parser
Date: Mon, 13 Feb 2006 20:49:08 -0500
User-agent: Mutt/1.5.9i

On Tue, Feb 07, 2006 at 08:54:55AM +0100, Akim Demaille wrote:
> >>> "Bob" == Bob Rossi <address@hidden> writes:
> 
>  > Hi All,
>  > I found here: http://savannah.gnu.org/mail/?group=bison,
>  > that this list is the appropriately place to post proposed changes to
>  > bison. Well, did this simply mean patches only?
> 
>  > I'm interested in added support for bison to act asynchronously.
>  > However, I've received no good response from the bison developers in
>  > what the best way to do this would be. I could really use some help in
>  > deciding what approach would be the best to take.
> 
>  > That is, have an entirely new skeleton, or modify either yacc.c or glr.c
>  > to support this functionality. Any ideas?
> 
> I would the first step would be to have some means to measure the
> performance of our parsers, especially yacc.c.  Then I would try to
> modify yacc.c so that the traditional yyparse is provided in terms of
> a push parser.  If there is no notable performance loss, then that's
> the way to go IMHO.  Otherwise, it will be m4 fun time.

Hi Akim,

OK, I've got much more experience working with bison, although I'm sure
I still have further to go. Here's what I've accomplished.

I added the %push-parser option, so that a bison input grammar file can
ask for itself to be a push-parser. This simple enhancement to bison
already raises questions. A %push-parse and %pure-parser don't make
sense together. The local variables store in %pure-parser are already
stored in the context that is used when %push-parser is used. Is it OK
to have to competing options like this? They make sense by themselves,
but not together. Is there a precedent in bison that I can simply
follow? Possibly it should be an error to declare both of these?

Next, I'm going down the path of using Odd's patch, and trying to generate
what he had from yacc.c. This is going well, but, it really does seem kind
of ugly. There are several options:
  - Take all locals in yacc.c and put them into a data structure. Then
    have yypushparse (and all of yacc.c) operate on the data structure.
    Build the traditional yyparse function on top of yypushparse by
    declaring the data structure once, and then calling yypushparse
    over and over. This would be pretty clean. However, there would be
    no such thing as a non pure parser. Are non-pure parsers valuable
    in any way?
  - Add lot's of m4 into yacc.c which would allow me to generate what we
    have now, but conditionally generate the yyparse function that would
    be acceptable in push mode. This is currently what I'm doing, but
    quickly get's ugly with lots of m4_push_if([..

What do you think of these 2 solutions? Am I missing a possible
solution? Basically, I'm working on the second approach now. I think
it's ugly and would prefer the first approach.

I'll show you an very unfinished patch that demonstrates the second
approach, just so you can get the feel of what I'm doing.

Thanks,
Bob Rossi

Attachment: bison.diff
Description: Text document


reply via email to

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