[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: Wed, 27 Dec 2006 11:38:10 -0500 (EST)

On Wed, 27 Dec 2006, Bob Rossi wrote:

> > At the moment, I'd like to settle the %push-pull-parser issue, which my 
> > recent patch addresses.  If you have no preference in that regard, that's 
> > fine, buy maybe Paul has an opinion.  In any case, I shouldn't make that 
> > decision by myself.
> OK. What exactly is the issue? The names of the options?

There are several issues.  For example, should yypull_parse accept a lexer 
function pointer, or should it be hard-coded to call yylex?  In the former 
case, %push-parser is enough to generate yypull_parse and yyparse without 
forcing the user to define yylex.  However, the function pointer hurts 
performance, the lexer can't be a macro, and there is no flexibility in 
the lexer function return type.  In the latter case, should the user be 
forced to define yylex even though he may not want it, or should he have 
to write a different declaration to instruct Bison to generate yyparse and 
yypull_parse?  If he should write a declaration, what should it be called? 
Are there any other solutions I haven't thought of?  There may be other 
issues as well.

> > In the meantime, I think we should stay away from #1 just to avoid 
> > conflicts.  However, feel free to work on #2, but understand that the 
> > %push-pull-parser stuff is still evolving.  For #3, do you have any use 
> > cases from your own work that could be converted to test cases?
> Well, I have a grammar that implements the gdb/mi protocol. I then use
> flex and bison to parse it. I currently don't do anything interactive
> though, if that's what you are looking for. In fact, I don't plan on
> ever doing anything interactive for this project. 

I'm not sure what you mean by interactive.  Would you explain a bit more?

> The reason I needed the 
> push parser is because gdb/mi is a line oriented protocol 
> (It emits one line at a time). If you've used gdb enough, you'll notice 
> that sometimes when a program crashes by recursion or stack curroption,
> if you do a backtrace in gdb it can print frames for a very long time.
> Without the push parser, I have to wait (5-10 minutes) for the entire 
> response to come back before passing to bison. This gives the user a 
> bad experience. With the push parser I can alert bison after each frame
> is printed. There are other benefits. 
> Would the grammar be useful? or are you thinking of a contrived example
> that is interactive?

It sounds large.  If so, can you think of a reduced example that does 
something similar?  That would probably be easier for other developers to 
maintain later.

reply via email to

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