Re: References to object oriented design of compilers?

newton@cs.utexas.edu (Peter Newton):
> Does anybody know of any publications on the subject of object-oriented
> design applied to compilers?


johnson@cs.uiuc.edu (Ralph Johnson) writes:
> The idea that every rule in the abstract syntax becomes a class is a
> classic one, but doesn't seem to be documented anywhere.


> A common problem with this approach is that the classes representing AST
> nodes get cluttered with a lot of code that is very specialized. In
> Smalltalk, for example, there is code for pretty printing, flow analysis,
> and so on. One way to move this code out of the main AST classes and into
> applications is to use a design technique called a Visitor, or tree
> walker, or tree node enumerator. This technique is a form of double
> dispatching. The idea is to give each node a "handle:" method, which a
> node of type Foo implements as:


> handle: aVisitor
> ^aVisitor handleFoo: self


> The Visitor object then implements a handleX: method for each AST node
> class X.


> Thus, an operation on an AST is represented by a Visitor object, and you
> apply an operation to an AST by traversing it, sending the handle: message
> to each node with the Visitor as an argument.


Interesting. The basic argument for object oriented design as been that an
object should contain the methods that relate to that object, thus
encouraging modular design. The above example describes a situation where
we don't want the methods relating to an object contained in the object
but stored separately on a per function basis. By using double dispatching
and complicated structure we can have a solution that would be more
naturally expressed in a function-oriented solution.


That is, the function-oriented approach would be


      procedure AnalyzeStatement(S)
          case S.tag of
            AssignmentStatement => analyze assignment statement
            ForStatement => analyze FOR loop
            ...
          end


    procedure GenerateCodeStatement(S)
          case S.tag of
            AssignmentStatement => generate code for assignment statement
            ForStatement => generate code for FOR loop
            ...
          end


The object-oriented approach would be


      class AssignmentStatement
            Analyze => analyze self
            GenerateCode => generate code for self


But the solution proposed to unclutter the object-oriented approach is


      class AssignmentStatement
            handle (aVisitor) => ^aVisitor handleAssignmentStatement(self)


and the "visitor" tree-walking code is


      class Analyzer
            handleAssignmentStatement(S) => analyze assignment statement S
            handleForStatement(S) => analyze FOR loop S


      class CodeGenerator
            handleAssignmentStatement(S) => generate code for assignment statement S
            handleForStatement(S) => generate code for FOR loop S


Am I missing something? What is the advantage of using object-oriented
design in such a situation?
--

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