Due: Wednesday, November 2 by 11 pm. Turn in your project using this online turnin form.
For this assignment, construct a parser (recognizer) for MiniJava. You should use a parser generator tool that interfaces with your scanner (probably CUP, assuming you are doing the project in Java). You should use a LALR (bottom-up) parser tool. Be sure that your parser and scanner together can successfully parse legal MiniJava programs.
At this point, don't include any semantic actions in the parser. Feel free to experiment with extensions or syntactic error recovery if you wish, but be sure to get the basic parser working first.
You may need to massage the MiniJava grammar to make it LALR(1) so that CUP can use it to produce a parser. Please keep track of the changes you make and turn in a description of them with this part of the project (see below).
Take advantage of precedence and associativity declarations in the parser specification to keep the overall size of the basic grammar small. (In particular, a production exp ::= exp op exp along with precedence and associativity declarations for the operators will shorten the specification considerably compared to a grammar that embeds that information in separate productions.) CUP's input syntax is a little different from the SableCC/Yacc syntax in section 3.4 of the book (::= instead of = in productions, terminal keyword instead of token, for example), but the meaning is the same. It should be easy enough to pick up the syntactic details from the CUP documentation and example code.
Your grammar should not contain any reduce-reduce conflicts, and should have as few shift-reduce conflicts as possible. You should describe the remaining shift-reduce conflicts in your writeup.
You should test your parser by processing several MiniJava programs, both correct ones and ones with syntax errors. At this point your compiler need only indicate a successful parse or a syntax error.
As part of your testing, you should write at least two new MiniJava programs. Not only will this be useful for testing, but it will also help you be sure that you understand what is included in the MiniJava subset of Java and what is missing.
Turn in at least the following:
You may turn in an archive containing your project if you wish. Be sure the writeup and test programs are easy to find if you do this. Also, be sure that when the archive is unpacked, top-level files (for Java, files not included in subpackages) are unpacked into individual files. The turnin server will have problems trying to compile files (if we do this) if the archive unpacks to yield a new folder with the top-level files hidden inside.
If you are working with others, you should turn in only one copy per group, listing the group members in the same order each time you turn it in. Multiple turnins are fine - we'll grade the last one you give us. In particular, if you plan on adding error handling or other extra features, turn in a copy of the working, basic assignment first before you add these, then turn in the enhanced parser later once you have it working.