Re: re-entrant parsers, pure_parser, bison, flex

cfc@world.std.com (Chris F Clark)
18 Jul 1997 12:28:34 -0400

          From comp.compilers

Related articles
re-entrant parsers, pure_parser, bison, flex lmipjmy@eei.ericsson.se (PJ Mealy) (1997-07-13)
Re: re-entrant parsers, pure_parser, bison, flex lmipjmy@eei.ericsson.se (PJ Mealy) (1997-07-16)
Re: re-entrant parsers, pure_parser, bison, flex tiggr@ics.ele.tue.nl (1997-07-16)
Re: re-entrant parsers, pure_parser, bison, flex lmipjmy@eei.ericsson.se (PJ Mealy) (1997-07-18)
Re: re-entrant parsers, pure_parser, bison, flex cfc@world.std.com (1997-07-18)
Re: re-entrant parsers, pure_parser, bison, flex 71511.3711@CompuServe.COM (Brian W. Inglis) (1997-07-21)
Re: re-entrant parsers, pure_parser, bison, flex bear@sonic.net (Ray Dillinger) (1997-07-22)
Re: re-entrant parsers, pure_parser, bison, flex vetter@cc.gatech.edu (Jeffrey Vetter) (1997-07-22)
Re: re-entrant parsers, pure_parser, bison, flex jlilley@empathy.com (John Lilley) (1997-08-24)
| List of all articles for this month |

From: cfc@world.std.com (Chris F Clark)
Newsgroups: comp.compilers
Date: 18 Jul 1997 12:28:34 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 97-07-063 97-07-081
Keywords: parse, Windows, OOP

> Now, normally (with VB or something) I would just place everything
> under the control of the parsing loop and just do something to allow
> event processing after each parsed sentence (a call to PeekMessage or
> something). But the zApp folks tell me that this is not the most
> portable approach...(we need to be able to port to all of the
> platforms that zApp supports, which means 16 bit too)...and that it
> won't work in all situations. They suggest that if we want to keep the
> same code across all platforms then the best approach is to leave
> control with the event processing loop and just parse the file a
> chunk/line at a time...


What you need is a parser object (that can be started and stopped) and
a lexer object also. Event driven parsing is one of the problems we
attacked with Yacc++, see Olaf Langmak's regular posting for details.
I believe there are other tools which have adopted similar solutions.
(If a tool supports objects with pause and resume, then they probably
use the same model.)


Part of the solution is similar to the reentrant parser. That is the
parser (and lexer) state(s) are kept in a separate area rather than
local variables. Since our model is object-oriented we call these
separate areas the parser (and lexer) object(s). The second part of
the solution is to have the objects parse in response to events, which
we implement by having the objects parse when the appropriate member
function is called. There is a little more to it having to do with
structing the control loop, but that gets the basic scheme working.


BTW, when you have something like that working, things like
thread-safety fall out. Thus, having multiple parsers comes for free.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.