Re: push parser implemenation

[Bob Rossi]

On Wed, Apr 05, 2006 at 12:04:11PM +0000, Frans Englich wrote:
> On Wednesday 05 April 2006 11:31, Bob Rossi wrote:
> > On Wed, Apr 05, 2006 at 09:35:46AM +0000, Frans Englich wrote:
> > > On Wednesday 05 April 2006 00:48, Paul Eggert wrote:
> > > > Bob Rossi <address@hidden> writes:
> > >
> > > [...]
> > >
> > > > Is there some way that we can fix that?  For example, is there someone
> > > > who needs push parsers, but doesn't yet know that they need them?
> > >
> > > Heh, I might be one of them.
> > >
> > > I googled around a bit, but I still wonder: what advantages does this
> > > push-parser patch add to Bison? What does it do?
> > >
> > > To me it seems like it makes it possible to call the parser instead of
> > > that the parser calls you.. possibly solving problems wrt. blocking.
> > > Correct? Something else or in addition?
> >
> > Hi Frans,
> >
> > Before I knew what I wanted, I was calling it an asynchronous parser.
> > Once I brought the discussion here, the word was quickly changed to push
> > parsing.
> >
> > Yes, the pull parser is a parser which asks for the tokens, and
> > doesn't return until it's done. This is a less desirable approach when
> > the parser has to read a large amount of data from a GUI application.
> > Also, the pull parser doesn't work at all in an application that wants
> > to write a parser that using streaming data, over a network socket or
> > unix pipe. In this case, the data is never "fully ready". So, either you
> > have to call your main_loop function from within bison, or you need
> > another solution.
> 
> That surely sounds interesting to me as well; I'm writing XQuery/XSL-T/XPath 
> implemetations to be used in GUI apps such as a web browser.

Yes, then this could defiantly be helpful. Are you using bison to
implement this? If so, do you call your main loop function from within
the bison grammar file? If not, do you block while parsing?

> > The push parser is just that solution. You feed the tokens to bison.
> > This allows me to write a grammar that represents data that will be
> > coming over a stream from another application. I create the parser once
> > at the beggining, and feed it tokens until the other application dies.
> > In this particular instance, CGDB is the program using the push parser,
> > and GDB is the program streaming the GDB/MI protocol over stdout. This
> > patch will greatly improve the design and usability of CGDB.
> >
> > There is 1 other potential gain of the push parser approach. For every
> > yyparse or xxparse grammar that you have generated,
> 
> What's the difference between yyparse and xxparse? Or you use the two terms 
> for referring to when the user have multiple grammars with different name 
> prefixes?

Yes, sorry.

> > you can have more 
> > than one parser instance working at the same time on the same grammar.
> 
> Doesn't %pure-parser achieve this?

Maybe it does. At first thought, I was thinking it didn't. But now I
realize it probably does. So sorry, that's not a real benefit of the
push parser.

> > That's because all of the data associated with the parser is located
> > inside a single struct. I'm pretty sure this isn't possible with the
> > %pure-parser.
> 
> Are you saying that:
> 
> * %pure-parser doesn't really create a reentrant parser?

I was, but I'm wrong, sorry.

> * that a %push-parser also is a fully reentrant/thread safe parser?

Yes, the push-parser is reentrant and thread safe. The obvious
difference is, you have N parser instances, and can call yyparse
(instance) with them whenever you want. Instead of having N potentially
blocking parsers. This allows you to use N parsers at the same time in a
single thread of execution.

Thanks,
Bob Rossi