Re: References to object oriented design of compilers?

johno@lucinda.lat.oz.au (John Ophel)
Fri, 22 Oct 1993 07:32:33 GMT

          From comp.compilers

Related articles
References to object oriented design of compilers? newton@cs.utexas.edu (1993-10-16)
Re: References to object oriented design of compilers? jones%pyrite@uunet.UU.NET (1993-10-18)
Re: References to object oriented design of compilers? johnson@cs.uiuc.edu (1993-10-19)
Re: References to object oriented design of compilers? johno@lucinda.lat.oz.au (1993-10-22)
Re: References to object oriented design of compilers? wjw@eb.ele.tue.nl (1993-10-25)
Re: References to object oriented design of compilers? johnson@cs.uiuc.edu (1993-10-26)
Re: References to object oriented design of compilers? bertrand@eiffel.com (1993-10-26)
Re: References to object oriented design of compilers? rlsitav@actcom.co.il (1993-10-29)
| List of all articles for this month |

Newsgroups: comp.compilers
From: johno@lucinda.lat.oz.au (John Ophel)
Keywords: design, OOP
Organization: Comp Sci, La Trobe Uni, Australia
References: 93-10-072 93-10-082
Date: Fri, 22 Oct 1993 07:32:33 GMT

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?
--


Post a followup to this message

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