CSE P 501 Project II - Parser

Due: Wednesday, Oct. 28 by 11 pm. Turn in your project using the assignment drop box (links on the project page).

Overview

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.

Don't include any semantic actions in the parser until you have the parser itself working.  Feel free to experiment with language extensions (additional Java constructs not included in MiniJava) or syntactic error recovery if you wish, but be sure to get the basic parser working first.

Details

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 parser grammar small. (In particular, a production exp ::= exp op exp along with precedence and associativity declarations for various operators will shorten the specification considerably compared to a grammar that embeds that information in separate productions.) CUP's input syntax is basically the same that used by YACC, described in many compiler books. 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. Your compiler need only indicate a successful parse or a syntax error, but, of course, better error reporting is a great extension.

What to Hand In

Turn in at least the following:

• The grammar source file for the parser (input file or equivalent) plus any other files like the scanner definition or others needed to build a working version of your parser.
• A README file explaining how to build and run your parser, including a description of any required software or libraries if you're using your own project setup.
• A brief writeup describing any changes you made to the grammar, and a list of shift-reduce conflicts remaining in the grammar (if any) with a description of why these are not a problem. (Feel free to include this information in the README file.)
• If you include any error handling or extra features in your parser, include a brief description of these features in your writeup.

It is ok to turn in your complete compiler source tree in an archive. If you do that, be sure that it's easy to find the requested items for this assignment, and do the equivalent of a make clean to clear out compiled files and other artifacts from the source tree you hand in.

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.