|Relational Database for Symbol Tables? Parsing Tables? firstname.lastname@example.org (2001-10-20)|
|Re: Relational Database for Symbol Tables? Parsing Tables? email@example.com (Carsten Kuckuk) (2001-10-23)|
|Re: Relational Database for Symbol Tables? Parsing Tables? firstname.lastname@example.org (2001-10-27)|
|From:||email@example.com (Richard Leddy)|
|Date:||27 Oct 2001 18:42:27 -0400|
|Posted-Date:||27 Oct 2001 18:42:26 EDT|
I have been programming up something similar to what you are talking
about for over the past year. This has gone through several stages.
What has been stored in the DB is a set of persistant symbols. The
persistant symbols are mostly references to other DB object by index.
I have a lot of C++ code around the DB, not for viewing as my client
needs nondisclosure. But, I used free ODBC++ for setting up C++ forms
for DB access. The symbols are treated by the same code. The use of
the symbols occurs in various ways. They can be accessed in C++ via a
symbol manager wrapper. Or they can be used in a one of a few
languages that I have been constructing in relation to the project.
For the languages, I used YACC (BISON) and LEX (FLEX). These languages
cannot assume that all symbols are of the persistant variety. However,
the way things are set up now, the runtime symbol manager does not
make an immediate distinction between newly introduced symbols and
those in the DB.
Also, most versions of YACC and LEX would not generate the tables to a
DB for you. It might be quite a project to hammer that out - say
starting with some free source. Then, one would have to ask about the
code generated for the action states. These are usually compiled into
the parser. However, it certainly seems doable given that the machine
usually wraps the switch statement in YACC output. I am figuring that
many XML processors do something like this.
Currently, (this morning) I am finishing up a version of one of the
languages that allows the symbol type to be introduced as a template
parameter. This particular part of the code is under my control. I may
put it up on my web site.
Until that time, check out my site www.copious-systems.com for contact
Thats all for now. Thanks.
"Carsten Kuckuk" <firstname.lastname@example.org> wrote in message news:01-10-125...
> I have some experience in both fields - compiler construction and
> databases. If I were in your shoes, I'd go to object-oriented
> databases. This would safe you from writing mapping code for RDBs and
> give you even a performance advantage over RDBs. Look at ObjectStore
> (www.objectdesign.com) or one of their competitors (www.versant.com,
> "Andrew D. Wolfe, Jr." <email@example.com> schrieb im Newsbeitrag
> > I would like to store the symbol tables (at least) and hopefully the
> > parse/lex tables in a database. A downstream goal is supporting
> > dynamic additions or alterations to syntax and symbols. However, my
> > other responsibilities prohibit me from doing an in-depth analysis of
> > the data and perform a thorough data design. So I'm looking for a leg
> > up.
Return to the
Search the comp.compilers archives again.