|C++ parser firstname.lastname@example.org (Henrique Bucher) (2001-01-18)|
|Re: C++ parser email@example.com (Michael Tiomkin) (2001-01-19)|
|Re: C++ parser firstname.lastname@example.org (Joel de Guzman) (2001-01-20)|
|Re: C++ parser email@example.com (Henrique Bucher) (2001-01-20)|
|From:||Henrique Bucher <firstname.lastname@example.org>|
|Date:||20 Jan 2001 16:11:38 -0500|
|Organization:||Brunel University, West London, UK|
|Posted-Date:||20 Jan 2001 16:11:38 EST|
> Well, you'll also need to build the right finite state machines for
> this grammar, for both lexer and parser, etc. etc. I think the
> easiest way is to build a .lex and .yacc file with your nice
> interface, add a makefile, apply yacc, lex, and cc using this
> makefile, and run the parser. If you want to call a parser as a
> function from your program, you can build the parser as a shared
> library (.so/.dll) and (un)load it at runtime.
My first idea was connecting the FSM to the parser using an ordinary
IDispatch supplied by the user (from a typelib?). This is not really
the problem, but the data structure necessary to hold a configurable
grammar. Building a static grammar is "easy" (pardon) but an
all-purpose grammar requires a lot more effort, you know.
> Another possibility is to use a package that allows building and
> compiling simple grammars at runtime, e.g. Python (re package or
> somehting like that). After initial parsing, you can use tree
> transformations in order to obtain the right object structures. You
> can easily find a parser written in Python and see what can be done
The point is that I will stress the possibility of building a
standalone application instead of relying on external calls. This is
for portability and easy installation.
Michael, thanks a lot for your answer, anyway.
> Good luck!
I have been in need of it!
Return to the
Search the comp.compilers archives again.