|[Q] Encapsulated parsers email@example.com (1998-11-24)|
|Re: [Q] Encapsulated parsers firstname.lastname@example.org (1998-11-30)|
|Re: [Q] Encapsulated parsers email@example.com (Chris F Clark) (1998-11-30)|
|Re: [Q] Encapsulated parsers firstname.lastname@example.org (1998-11-30)|
|Re: [Q] Encapsulated parsers email@example.com (1998-12-01)|
|Date:||30 Nov 1998 02:09:22 -0500|
|Organization:||Deja News - The Leader in Internet Discussion|
firstname.lastname@example.org (Bob Collins) wrote:
> Does anyone know of any research on what I call
> encapsulated parsers, which consists of
> 1. a single parse routine that accepts
> 2. a. a set of parse tables,
> b. a synthesize semantics routine, and
> c. semantic routines to disambiguate
> grammar conflicts at runtime
> as parameters,
> 3. so that the parser can be called multiply
> in code with different parameters to parse
> the same input in different ways.
Do you actually want to parse the data in different ways--meaning
different grammars--or just want different actions to take place
within the parse? If it's the latter, then ANTLR 2 (www.antlr.org)
would be a good candidate. The main thing would be to encapsulate
your behavior as an interface which the parser calls. Then switch the
behavior object to do different things.
If you are doing something that's more like a multi-pass translator,
you can get a lot of mileage out of ANTLR's "grammar inheritence." I
typically define a tree grammar with no actions as a base class. The
parser generates the tree and then I write a specific pass by
subclassing the tree parser and overriding the rules I'm interested in
for that pass.
There's no problem creating multiple instances of the same or
different parsers in ANTLR 2, it uses no global state.
With a more specific example I could tell you more about the ANTLR
approach to it.
Return to the
Search the comp.compilers archives again.