|Object Oriented Compiler Construction email@example.com (1994-01-04)|
|Re: Object Oriented Compiler Construction firstname.lastname@example.org (1994-01-05)|
|Re: Object Oriented Compiler Construction email@example.com (1994-01-05)|
|Re: Object Oriented Compiler Construction chase@Think.COM (1994-01-05)|
|Re: Object Oriented Compiler Construction firstname.lastname@example.org (1994-01-06)|
|Object Oriented Compiler Construction email@example.com (Chris Clark USG) (1994-01-06)|
|(fwd) Re: Object Oriented Compiler Construction firstname.lastname@example.org (chris (c.d.) donawa) (1994-01-08)|
|From:||email@example.com (Preston Briggs)|
|Organization:||Rice University, Houston|
|Date:||Thu, 6 Jan 1994 00:55:10 GMT|
>|> It occurs to me that inheritance should be especially useful in the
>|> construction of a parse tree. ...
Sure, no question. But is this an interesting problem?
>|> 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.
firstname.lastname@example.org (James Litsios) writes:
>I have a feeling this only works well for simple compilers. On my current
>project I am writing a compiler that does so many transformation of the
>original parse tree that the idea of storing each different type of node
>in a different class (the work is in C++) is simply not practical.
>Instead I use the OO properties of C++ to manipulate generic LISP like
I agree, generally. Parse trees just aren't a great representation for
optimization (an exception might be if you have to perform
source-to-source transformations). If you want to do optimization, I
believe it's better to transform the parse tree into a flexible and
efficient internal form (perhaps like Litsios' data structures).
Consider an optimization like moving loop-invariant code outside a loop.
Using a parse tree, loops can have many explicit representations and
perhaps a few hidden ones (especially if your source language allows gotos
or recursion). It seems easier to translate all these parse tree forms to
a low-level form (something like assembly, with only unconditional jumps
and conditional branches for control flow) and use a single version of the
optimization to handle all kinds of loops.
Return to the
Search the comp.compilers archives again.