Re: Object-oriented compiler construction: ideas?

Oliver Plohmann wrote:
> When I first looked into a book about compilers I saw a parse tree with
> integers representing the respective keyword. I thought you could
> alternatively make up the parse tree of objects, like Statement,
> ConditionalBlock, Loop, etc. A ConditionalBlock would contain the


Darius Blasbans (darius@phidani.be) wrote:
: You can even take this idea further by having a NonTerminal root
: class, a Statement class derived from NonTerminal, an IfStatement
: class derived from Statement, etc...


poe@theory.lcs.mit.edu (Peter Orbaek) writes:
> I my experience this is not always the case. I did a compiler for the
> Action semantics description language in this OO style with essentially
> a class for each non-terminal in the grammar.
>
> The problems that I saw with this approach is the proliferation of
> lots on non-important classes corresponding to the needs of the
> concrete syntax to be LALR(1) (I was using yacc). I got into a maze
> of lots of little methods all alike, but syntactically dispersed
> because each of them needed to be a method.
[snip]


I am using the polymorphic approach myself, one class for each type of
node occuring in the parse tree. The problem stated by Darius Blasbans
is handled best by using the `Visitor pattern'. The node classes then
need only one method: `accept(Visitor)'. The burden is moved to the
abstract visitor class and its concrete derived classes, but the logic
of the code gets less dispersed.


--

Return to the comp.compilers page.
Search the comp.compilers archives again.