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

PJ Mealy <lmipjmy@eei.ericsson.se>
16 Jul 1997 22:54:10 -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)
[1 later articles]
| List of all articles for this month |

From: PJ Mealy <lmipjmy@eei.ericsson.se>
Newsgroups: comp.compilers
Date: 16 Jul 1997 22:54:10 -0400
Organization: Ericsson
References: 97-07-063
Keywords: parse, question

> [You have to fiddle the lexer yourself. If you just want to parser to be
> recursive, you need only add the extra &yyval argument to yylex. If you
> want a truly recursive lexer that you can recurse into at any time,
> you're out of luck with flex. -John]


Thanks John...
Hmm....it's the fiddling with the lexer itself that I need more info
about...I'm wondering what things I need to preserve or pass in or out
in order to maintain the context....


Could I explain a little more of what I'm trying to do? (As I am
wondering if reentrant parsers are really what I need...) I have a
zApp based GUI which displays a small status window during a parse of
an input file. The status window shows a progress bar and supports a
CANCEL button. The progress bar indicates how much of the i/p file has
been parsed and the CANCEL button provides the opportunity to stop the
parse.


As the GUI is structured around an event processing loop I can't just
go ahead and do the full parse in one go. I need to have the event
loop active peiodically to process progress bar updates and respond to
a click on the CANCEL button.
  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...


Now, I settled on reentrant parsers as a first approach to parsing a
file a bit at a time and not losing the place in the file between each
call of the parser...but this may not be the best way...I wouldn't
really be using a reentrant parser in a way that it was intended would
I? I don't actually need to do multiple simultaneous parses OR to have
the parser call itself....I just need to parse a file a chunk at a
time and not get confused...


Now, if the rentrant parser IS the way to do this then I would like to
work out what information I need to preserve between calls to the
parser...what should the lexer pass out? what should parser pass into
the lexer?


I really appreciate all and any help on this matter...


PJ
[Hmmn, reentrant parser won't help at all here, since yacc restarts the
parse each time you call it. If your input lanuguage is statement
oriented, you could set up your grammar to parse one statement at a time
so you'd keep calling yyparse() until it ran out of input. -John]


--


Post a followup to this message

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