|Object-oriented compiler construction: ideas? firstname.lastname@example.org (Oliver Plohmann) (1996-06-01)|
|Re: Object-oriented compiler construction: ideas? email@example.com (Darius Blasbans) (1996-06-08)|
|Regarding OO Compiler Implementation firstname.lastname@example.org (1996-06-21)|
|From:||email@example.com (Peter Froehlich)|
|Date:||21 Jun 1996 17:05:54 -0400|
|Organization:||AMIGA CITY - Public Amiga-BBS, Munich, Germany|
I've read through the recent thread on implementing compilers in an
object-oriented way and I've noticed that all of the mails favored the
approach of using individual classes for language constructs. Each class
has methods for type-checking and code-generation in this approach.
The way I see it another kind of implementation is preferable, and
hopefully I get some feedback on this (as I plan to apply this design to a
compiler for my "Froderon" variant of Oberon-2 when my thesis is finally
finished and to another language I currently call "ARIEL").
First of all I plan to use a front-end/back-end approach for
portability. The front-end generates an AST and a symbol table, the
back-end generates code from these data structures. Front-end and back-end
will be implemented by several modules (using Oberon-2 for boot-strapping).
The front-end will use a simple (non-OO) scanner and a recursive descent
parser implemented as a class. Individual productions of the grammer will
become methods. This ensures that (minor) language extensions can later be
introduced into the front-end by deriving a new parser class. The parser
uses a seperate class for building the tree abstractly and (of course) also
uses the symbol table class. Elements of the AST *are* classes but they
*don't* have methods for type-checking or code-generation.
The back-end traverses the AST and reads from the symbol table. Tree
traversal is implemented using the "Visitor" pattern (from Gamma et.al.).
This enables me to define e.g. code-generation inside one module by
declaring all code-generation visitor classes there. Another module would
implement all type-checking visitor classes, yet another optimizations on
the AST and so on.
I don't have a detailed design yet, but I look forward to hearing your
opinions on this approach (either here or through mail). Thanks.
Return to the
Search the comp.compilers archives again.