Re: Object-oriented compiler construction: ideas?

Henrik Johansson <euahjn@eua.ericsson.se> wrote:
>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.


How is the Visitor pattern any different from the "old fashioned"
(non-OO) way of writing a compiler (or any other program, for that
matter)? That is, define a bunch of variant records to represent the
abstract syntax tree, and write several procedures that do various
things, like Do_Semantic_Analysis, Optimize, Generate_Code, etc -- each
procedure has a giant case statement based on the tag field of the
current tree node.


That is, it seems to me that when you choose to use the Visitor pattern,
you're basically saying that the OOP way is inappropriate in that
particular case. The OOP way organizes keeps classes together, and
scatters the operations all over; the "old fashioned" way keeps each
operation together in one place, as does the Visitor pattern. The "old
fashioned" way requires that the fields of each node type be visible to
the operations, or else accessor functions are needed -- just like the
Visitor pattern.


Which technique is better depends in part on which parts of the system
are likely to change -- are you going to add new classes, or add new
operations? If you're writing a compiler for a stable language, then
adding new classes may not be very common. I'm not sure what you do if
*both* aspects of a program are likely to change -- are there languages
that try to address that issue?


- Bob
--

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