Milestone 1 : Scanning and Parsing

Your task in this milestone is to extend the StaticJava ANTLR specification, provided in the course SVN repository, to support
ExtendedStaticJava programs. The differences between StaticJava and ExtendedStaticJava are highlighted in the EBNF for ExtendedStaticJava.

You must submit your assignment through the course Project Upload site by 11:59pm CDT on Friday September 28, 2007.

Download the file myname-milestone1.zip

This contains a skeletal implementation of the first milestone with a JUnit testing framework for your use.

In order to import the projects into your workspace, do the following:

Goto the "File" menu, select "Import". Expand "General" and select "Existing Projects into Workspace". Click "Next". Select "Select archive file:" and click the "Browse" button associated with it. In the file browser, points to the milestone1.zip that you downloaded.

You should see "myname-milestone1" and "compiler-sjc" ("compiler-sjc" is only available if you don't already have the project in your workspace). Check both (or just the milestone) and click "Finish".

If you run Eclipse appropriately (i.e., using Java 5.0 and the right versions of plugins and by following the instructions in the course quick notes website), your workspace should be set.

Make sure you rename "myname" in the project's name into your CSE user id by right clicking the project, select "Refactor" -> "Rename...".

Your assignment is to implement the language extensions required for ESJ. You will do this by adding to the file ExtendedStaticJava.g, in directory myname-milestone1/src/sjc/parser/extended, which contains the rules for the basic SJ lexer and parser; ANTLR has no inheritence mechanism for parser rules so we've just copied the SJ rules here for you.

You will need to systematically look at each difference in the ESJ and SJ language descriptions and decide how to change the ANTLR rules.

You can tell if you are making progress by running the JUnit test suite. This is done by highlighting the class sjc.test.extended.ExtendedParserTest (which is located in the src-esjc-test project), right clicking and selecting "Run As" -> "JUnit Test". The results will be shown in total and on a per test case basis.

You can see the source of the test cases in src-examples directory of the milestone.

Note that currently the test suite only includes "passing" test cases. Part of your job will be to extend the JUnit test driver with the ability to support "failing" test cases, i.e., inputs for which the expected behavior is that a parse error is detected, and to write some test programs that demonstrate your parser can catch errors.

You are done when all of the test cases pass (note that a test program that has a parse error in it "passes" when the parser detects the error).

Note that you are not expected to modify the ExtendedParserTestGenerator.java program. You can simply modify ExtendedParserTest.java directly. If you would like to modify the generator then by all means do so.

In some cases, it is easier to define a "weaker" grammar rather than trying to enforce the precise constraints in your language and catching violations of those constraints in latter phases of your compiler. Problematic constraints often arise when one wants to enforce a ordering on the occurrence of parts of the program input where those parts may be separated by arbitrary syntax. A classic example of this is the constraint that one can only reference variables that have been previously defined.

With ANTLR v3 a good strategy is to start with the most direct encoding of the EBNF as you can and let the power of LL(*) and backtracking work for you. Only restructure the grammar when you really need to.

Your solution should consist of the following :

• a modified version of ExtendedStaticJava.g that handles ExtendedStaticJava
• a modified version of ExtendedParserTest.java to handle failing tests
• 10 ESJ programs with syntax errors in the "extended" portions of the language, i.e., don't insert errors that the SJ parser could catch by itself
• a single text file that describe your implementation including any limitations and anything special you had to do to handle the extensions

As with all programming, I expect that you provide reasonable internal documentation describing tricky/subtle parts of your implementation. If you have any limitations in your implementation you should include documentation describing those as well, since if we find them we will assume that you did not.

Your grade will be based on your solution (80%), your failing tests (10%), your in code documentation (5%), and the description file you provide (5%).