1. 1 Languages and Compilers (SProg og Oversættere) Bent Thomsen Department of Computer Science Aalborg University With acknowledgement to Wei-Tek Tsai who’s slides this lecture is based on.

2. 2 Some Issues in language and compiler design Simple syntax => simple semantics => simple implementation Syntax vs types Single pass vs multi pass compiler Use of CC tools vs by-hand JavaCC, JLex/CUP and SableCC AST as intermediate representation Visitors pattern

3. 3 Multi Pass Compiler Compiler Driver Syntactic Analyzer calls Contextual AnalyzerCode Generator calls Dependency diagram of a typical Multi Pass Compiler: A multi pass compiler makes several passes over the program. The output of a preceding phase is stored in a data structure and used by subsequent phases. input Source Text output AST input output Decorated AST input output Object Code

4. 4 JLex/CUP vs. SableCC

5. 5 JavaCC and JJTree

6. 6 Design Patterns Classes and objects are useful organizing concepts Culture of design patterns has developed around object- oriented programming –Shows value of OOP for program organization and problem solving

7. 7 What is a design pattern? General solution that has developed from repeatedly addressing similar problems. Example: singleton –Restrict programs so that only one instance of a class can be created –Singleton design pattern provides standard solution Not a class template –Using most patterns will require some thought –Pattern is meant to capture experience in useful form

8. 8 Visitors pattern Represent operations to be performed on an object structure Define new operations without changing the classes of the elements on which they operate

9. 9 Motivation Compiler represents programs as abstract syntax trees (AST) Need to perform operations on AST for semantic analysis, code- generation, pretty-printing and so on AST has different types of nodes for variable reference, assignment, operator, etc. Code for an operation is specific to the node type Node TypeCheck() GenerateCode() PrettyPrint() AssignmentNode TypeCheck() GenerateCode() PrettyPrint() VariableRefNode TypeCheck() GenerateCode() PrettyPrint()

10. 10 Motivation (contd.) Adding operation code to each node type has the following drawbacks that makes it hard to understand and maintain: –Code for each operation is distributed across multiple classes (AssignmentNode, VariableRefNode, etc) –Code for different unrelated operations are mixed together as methods on a single node –Adding a new operation would mean changing and recompiling all the node classes Better Approach: –Node classes independent of the operations that apply to them –Can be achieved using a visitor design pattern

11. 11 Visitor Solution using Visitor: –Visitor is an abstract class that has a different method for each type of object on which it operates –Each operation is a subclass of Visitor and overloads the type-specific methods –Objects that are operated on, accept a Visitor and call back their type-specific method passing themselves as operands –Object types are independent of the operations that apply to them –New operations can be added without modifying the object types

12. 12 Visitor Solution NodeVisitor VisitAssignment( AssignmentNode ) VisitVariableRef( VariableRefNode ) TypeCheckingVisitor VisitAssignment( AssignmentNode ) VisitVariableRef( VariableRefNode ) CodeGeneratingVisitor VisitAssignment( AssignmentNode ) VisitVariableRef( VariableRefNode ) Node Accept( NodeVisitor v ) VariableRefNode Accept(NodeVisitor v) {v->VisitVariableRef(this)} AssignmentNode Accept(NodeVisitor v) {v->VisitAssignment(this)} Nodes accept visitors and call appropriate method of the visitor Visitors implement the operations and have one method for each type of node they visit

13. 13 Applicability Use the Visitor pattern when: When an object structure contains different classes of objects with different interfaces and operations on these objects depend on their concrete classes Many unrelated operations need to be performed on the objects and you want to keep related operations together The classes defining the object structure rarely change, but you want to define new operations over the structure If the object structure classes change often, it is better to define the operations in those classes

14. 14 Consequences of using Visitor Addition of new operations is easy –New operations can be created by simply adding a new visitor Gathers related operations together –All operation related code is in the visitor – Code for different operations are in different sub-classes of visitor – Unrelated operations are not mixed together in the object classes Adding a new concrete type in the object structure is hard –Each Visitor has to be recompiled with an appropriate method for the new type

15. 15 Reference E. Gamma, and others, Design Patterns: Elements of Reusable Object- Oriented Software, Addison-Wesley, 1994.