Related articles |
---|
Object Oriented Compiler Construction drh@world.std.com (1994-01-04) |
Re: Object Oriented Compiler Construction litsios@iis.ee.ethz.ch (1994-01-05) |
Re: Object Oriented Compiler Construction knapp@cs.purdue.edu (1994-01-05) |
Re: Object Oriented Compiler Construction chase@Think.COM (1994-01-05) |
Re: Object Oriented Compiler Construction preston@dawn.cs.rice.edu (1994-01-06) |
Object Oriented Compiler Construction clark@zk3.dec.com (Chris Clark USG) (1994-01-06) |
Re: Object-oriented compiler construction (summary) drh@world.std.com (1994-01-07) |
[2 later articles] |
Newsgroups: | comp.compilers |
From: | drh@world.std.com (Richard Hipp) |
Keywords: | OOP, design, question |
Organization: | Compilers Central |
Date: | Tue, 4 Jan 1994 23:39:14 GMT |
I have a need to write a compiler in an OOP style using C++. I have some
ideas of how to proceed, but am interested in first considering the ideas
and experiences of others who have undertaken similar efforts. If you
have ever written a compiler in an object-oriented language or know about
papers, articles, or books which discuss object-oriented compiler
construction, I will be most grateful if you will share your knowledge
with me. Email to this address (drh@world.std.com) will be summarized to
this newsgroup periodically.
The remainder of this posting is a very brief summary of my thoughts on
object-oriented compiler construction. Note that these really are only
thoughts. I have not tried to carry the ideas through on a large project;
there may be (and probably are) unforseen pitfalls.
It occurs to me that inheritance should be especially useful in the
construction of a parse tree. In a traditional compiler (written in C),
each node of a parse tree is usually a structure with a large variant
section which depends upon the type of the node. For example:
struct parse_tree_node {
int type;
union {
struct {}; /* Information when type==1 */
struct {}; /* Information when type==2 */
struct {}; /* Information when type==3 */
/* And so forth... */
} u;
};
A better way to do this, it seems to me, is to define an abstract class
for parse tree nodes, and then subclass specific node types from the
abstract base class. I envision member functions like SanityCheck(),
Optimize(), and GenerateCode() which take very different (though
conceptually identical) actions for each node subclass.
It also seems to me that something other than yacc and lex should be used
for the parser. This venerable old tools have served us well, but their
design is beginning to show its age. Upgrades like yacc++ and lex++ don't
seem to help much since it is the basic design of the tools, not their
implementations, which seems to be at fault.
Again, these are just thoughts. I'm looking for real experience. Please
respond if you have any.
Peace.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.