Re: Questions about recursive or multiple instances of parser

After cogent comments on bison and flex, and specific questions about PCCTS,


Clint Olsen,olsenc@kodiak.ee.washington.edu asks
<<
If there's something I'm glossing over, please let me know.
>>


I am not sure, but maybe. It is not clear from your brief note that
you actually want multiple instantiations of the lexer functions. I
have minimum experience, but I can tell your that multiple parsers
could be presents in a design that legitimately has only one lexer.


The various parsers are likely to be made available in such a design
when some input token (or sequence of tokens) designates a change in
context. Even if the exact meaning of the new context is that a
completely different input stream is to be processed for some
duration, that does not mean that you necessarily need a distinct
lexer to do that.


In such a context switch there is a need to preserve the state of the
lexer, and when the other context ends (by intention, by error, or by
some end-of-input), the previous lexer state probably must be
restored. Having distinct lexers might be the hardest way to achieve
that state push/pop effect.


The sophistication of your inquiry and the source of your post reveal
that you probably have a firm grasp of the difference between the
lexer function conceptually, and the parser function(s)
conceptually. Yet you have not revealed why your application would
need distinct lexers for some of or each of your parsers.


Some lexers have %s and %x state syntax available, in case that is not
known to you yet.


And a lot of context-like transitions can occur in the lexer by
designing numerous lower level feeder functions. The basic idea would
be to associate a file state with each file processed by the lexer's
collection of feeders. These file states survive in some block in
memory as long as the lexer keeps them around. Here you are saving
file state rather than lexer state in detail. (Although the lexer
state changes atleast minimally to track the proper current file
service to use).


Others might comment on the PCCTS question better than I. I would
mention in passing that PRECC, from reading the documentation, is much
more modular than other approaches, so that if your application is
that unusual, the modularity could allow the asynchronous lexer
functionality you suggest.


But, if there is anything you are glossing over in your planning,
maybe it is that a need for multiple parsers does not imply a need for
multiple lexers. And there are several easy ways to stack lexer
states: 1) use the tools %s or %x state facility, 2) hand craft lexer
state preservation / restore, and 3) reduce the requirement to
multiple feeder file state transitions.


Best Wishes


Robert Rayhawk
RKRayhawk@aol.com

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