Due Date: Saturday, February 16 at 11:59pm via GitHub.

Introduction

In this assignment your team will be implementing a parser for the CSC488 Source language using the Python Lex-Yacc (PLY) package. You will accomplish this by carefully studying the grammar productions and associated notes from the Source language specification and transforming them into a valid LALR(1) grammar expressed in the PLY-compatible notation. Recall that the specification, as currently written, is highly ambiguous and thus not LALR(1), but that this can be corrected while still being compatible with the specification.

Handling ambiguity

One kind of ambiguity present in the Source language specification reference grammar relates to operator precedence and associativity. While PLY has built-in features for dealing with this kind of ambiguity, for Assignment 2 you may not use them (specifically, you may not add the precedence list or use %prec overrides). Instead you will have to manually create new grammar productions that are faithful to the original specification.

Testing

See a2/csc488/parser/tests/test_parser.py for a few ideas on how to approach testing your parser. At the very least you should incorporate your work from Assignment 1 as a starting point. You can run these tests with the a2/runtests command from the starter code package.

Starter code package

Within your private team repository on GitHub, a a2starter branch has been pushed. Merge that branch into your master branch and follow the Getting started instructions in a2/README.md.

How to submit

Merge in the starter code and modify a2/csc488/parser/parser.py to complete the implementation of a parser for the CSC488 Source language, along with associated tests.

You submission must run correctly on teach.cs.toronto.edu. Failure to correctly run in that environment may result in an overall assignment mark of 0.

While you are free to add new code or modify any other files from the starter code package, you must ensure that parser.py is still compatible with the original starter code definitions, as this portion of the assignment will be evaluated by copying your parser.py into a fresh evaluation repository.

Your testing strategy will be evaluated in the context of your full repository submission, so feel free to add code and files at your own discretion.

Modify a2/README.md by adding the following:

• Your team member names
• Whether or not you are using any grace days (and if so, how many)
• A brief summary of the contributions made by each team member
• 1-4 paragraphs providing a high-level overview of your testing strategy, with justification for the choices you've made and a brief commentary on the relative strengths and/or weaknesses of the approach you've adopted

Push your commits to the master branch of your repository prior to the deadline. Whatever is the most recent commit as of the assignment deadline will be considered to be your teams' submission for the assignment. The master branch will be checked again 24, 48 and 72 hours after the deadline if you choose to submit late and use grace days. If you are using grace day(s), be sure to update the README file to reflect how many.

Submission checklist

• Check that your submission runs correctly on teach.cs.toronto.edu
• Do not modify the lexical analyzer in a2/csc488/parser/lexer.py (but do consult it to understand the available tokens and single-character literals)
• Do not use PLY's disambiguation features
• Do not change the Source language, or implement a variant thereof
• Do not change your parser.py in such a way that it becomes incompatible with the original starter code
• Ensure your parser does not have any shift/reduce or reduce/reduce conflicts
• Choose and implement a strategy for testing, and remember, automated testing is your friend and ally

---