Due 11:59pm Sunday Oct 18
You will first complete semantic analysis for type-checking of Mojo as described in Chapter 5 of the text, by traversing the Abstract Syntax Tree (AST) generated by the parser from Project 2, and checking for various type compatibilities. Note that the parser you will be using is the canonical project version; do not be alarmed if it produces slightly different behavior from the parser that you created in the previous project. Our goal here is to perform semantic analysis.
The code that you need to complete has been marked with TODO comments.
Before starting this project, familiarize yourself with Chapter 5 of the textbook. In addition to the lectures, this will give you a solid foundation for beginning your work.
Source code is available in a tarball in the /homes/cs352 directory, which can be copied into your working directory and expanded by doing the following:
cp /homes/cs352/Fall15/project3.tar.gz ./ tar -xvf
If you wish to integrate the project into an Eclipse project, follow the directions on this blogpost to create an Eclipse project using the included Makefile.
To make the project, type "make" as per usual. To run your project, go into the bin directory and type:
./p3.sh file.mjwhere file.mj is a Mojo source code file. This will print out the types declared in the input program, and should also check for semantic errors in the input program.
A litany of tests have been included in the p3tests directory in the base directory of the project. Run these on your semantic analyzer to check for correct functionality. Each test is a Mojo file that the included canonical Project 3 Parser accepts as gramatically (but not necessarily semantically!) correct.
You should turn in your src/mojo/Semant.java file, using the turnin command available on CS Unix machines. To turn in your project, make sure that you are in the directory that contains your Semant.java file (src/mojo). Then type the following:
turnin -c cs352 -p project3 Semant.java
To verify your turned-in work, do:
turnin -c cs352 -p project3 -v
We will create a set of test cases, and then compare the output of your solution to our reference implementation. Grading test cases are intended to test separable functionality of your type checker. Towards the end of the project period, we may release the results of our own tests to demonstrate what the type checker should produce.
There will be a reconciliation period after initial grading when you will be able to compare outputs of your type checker with those of the reference implementation, and you may then offer simple fixes for the TAs to apply to your implementation to improve your grade. These fixes will be accepted only at the discretion of the TAs and the instructor — we will judge what "simple" means!
The reconciliation period is only intended for you to be able to fix simple problems that you may have mistakenly overlooked. Thus, you must make sure to test your implementation thoroughly.