Re: Object-oriented compiler construction: ideas?

Robert A Duff wrote:
> 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?


This is a fundamental problem with taking the OO-paradigm too far.
What we need are languages that allow programmers to view the organization
or their programs in different ways in order to support different kinds
of modifications. Ideally, when adding a new kind of primitive to the
AST, the system would present the OO version, so that all I have to
add is one new definition, with appropriate methods. But when I go to
add a new transformation or optimization, I'd rather see the "old-
fashioned" view of my program where I code one big procedure that
switches on the different kinds of AST objects. This way, I don't have
to touch all of the classes to add new methods.


Another problem with the OO-approach is fixing the order of traversal
in the Visitor pattern. In-order? Post-order? Pre-order? Visit
right children first or left children? Depends a lot on the optimization
or transformation you're performing. Perhaps this is the reason why
attribute grammars and other forms of declarative tree/graph-rewriting
seem attractive to compiler writers.


-Greg Morrisett
  jgm@cs.cornell.edu
--

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