bison-patches
[Top][All Lists]
Advanced

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

Re: push parser implemenation


From: Frans Englich
Subject: Re: push parser implemenation
Date: Wed, 5 Apr 2006 12:04:11 +0000
User-agent: KMail/1.8.50

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.

> 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?

> you can have more 
> than one parser instance working at the same time on the same grammar.

Doesn't %pure-parser achieve this?

> 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?
* that a %push-parser also is a fully reentrant/thread safe parser?

Keep up the good work.


Cheers,

                Frans




reply via email to

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