Design and Implementation of an Abstract Syntax Hierarchy
- CaC, Chapter 7.4–7.6
Abstract Syntax Hierarchies
In this assignment, we're going to jump ahead a few weeks and focus on the goal of parsing: production of an internal representation of concrete source code for exactly the set of syntactically valid programs. In order to facilitate a clean interface between projects in this class, we will ultimately use a standardized set of classes rather than the work you design here. However, the design of an abstract syntax hierarchy is something of an art, and engagement with the design task will help to give intuition to the next few projects.
You are to design and implement a set of classes that represent the nodes of abstract syntax trees sufficient to represent any syntactically valid Tiger program. To be clear, you are not implementing any parsing. The actual translation of concrete source code to these tree structures is the work of the next several weeks. The goal of this project is just to give you some intuition about the eventual goal of parsing.
Most of the specifics are up to you, but a few guidelines apply to all work:
- Program syntax has a natural tree structure, and your classes should reflect this. For example, an expression involving a binary operator (such as "e1+e2") has three parts: the operator and two expressions.
- You should only represent elements of a program that are essential for semantic analysis and translation. For example, in the expression "(3 + 2)", the numbers 3 and 2 as well as the addition operator are essential, while the parentheses are not.
- Conceptual groups within the language should correspond to class hierarchies. For example, there is a hierarchy of expressions, and also one of declarations. There are others, too, and you will not be evaluated on getting the "right" decomposition. I am interested in seeing how you engage this.
- Every class file should be part of the package tigerc.syntax.absyn
This project may be somewhat challenging for a one week time frame, and in light of that, you should work in groups of two or three. If you choose the group option, you'll have to choose a turn in directory.
- Your class files, representing your implementation of an abstract syntax fr Tiger. This should be in a folder structure, tigerc/syntax/absynrepresenting the package structure of the hierarchy.
- A separate document describing the main points of your design choices. In this document, you should explain the hierarchical structure of your code, with a diagram, if possible. You should also include a discussion of the methods that should be implemented with each class (though you only need to implement prototypes for these methods (i.e. just enough code that they compile).