Related articles |
---|
C++ parser henrique@bucher.com (Henrique Bucher) (2001-01-18) |
Re: C++ parser tmk@netvision.net.il (Michael Tiomkin) (2001-01-19) |
Re: C++ parser joel@interxys.com (Joel de Guzman) (2001-01-20) |
Re: C++ parser henrique@bucher.com (Henrique Bucher) (2001-01-20) |
From: | Henrique Bucher <henrique@bucher.com> |
Newsgroups: | comp.compilers |
Date: | 20 Jan 2001 16:11:38 -0500 |
Organization: | Brunel University, West London, UK |
References: | 01-01-097 01-01-121 |
Keywords: | C++, parse |
Posted-Date: | 20 Jan 2001 16:11:38 EST |
Hi Michael,
> 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
> there.
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!
Henrique Bucher
Return to the
comp.compilers page.
Search the
comp.compilers archives again.