Module 2:
A Parser for Klein: Accepting Programs
Stage 2 of the Klein compiler project
Out: Friday, September 19
Due: Friday, October 3, at 11:59 PM
STATUS CHECK DUE: Friday, September 26
Tasks
This stage consists of the first part of the second component of your Klein compiler, two auxiliary programs, and five short test programs.
1. A Parser that Recognizes Programs
Your primary task is:
Write a table-driven parser that accepts legal Klein programs.
This parser is a function or object that examines a sequence of Klein tokens to produce a true/false answer: Is the input a legal Klein program?
When created, your parser should either:
- either receive a scanner as an argument
- or receive a source program as an argument and create a scanner on it.
It should provide at least one public function, named
parse.
Your parser should implement a table-driven algorithm using a parse table and a stack of states being processed. Your parse table may be implemented in code or in data.
Be sure that your parser detects and reports any syntactic error that prevents it from processing the rest of the program.
- At the bare minimum, the parser can report the combination of non-terminal and token that caused the error. It will be more helpful to the programmer if the parser also reports the next few tokens in the stream.
- Bonus points will be awarded if the parser's error messages report the line and character on which the error occurs, or if the messages provide custom messages for common error states.
- Your parser must catch all error messages generated by your implementation language and report errors as Klein errors. Ideally, the user of your Klein compiler will not know the compiler's implementing language.
Notes on Documentation
In order to implement your parse table, you need to construct a FIRST set and a FOLLOW set for the refactored grammar, and then use these to build a parse table.
Include all three of these items in the documentation for your project.
You can document these as text files, PDFs, or even graphics. Having them in an editable plaintext form is handy even if you also submit a PDF or a graphic.
If you have any of these done by the time the status check is due — and you probably should — you may submit them with your status check in order to get early feedback.
2. Klein Programs to Test the Parser
In order to test your parser,
Create five short test programs that are nearly legal but which your program correctly rejects.
Each of these programs should test one interesting cases that your parser ought to recognize as invalid. A nonsense program is less interesting than a program that does something but contains a subtle syntax error.
You should, of course, produce as many tests as you think necessary to ensure that your parser works correctly. You are also encouraged to use any test programs available on the project home page.
3. A Program Validator
Once your parser successfully processes a sequences of tokens:
Write a program that uses your parser to validate a candidate Klein program.
The validator should invoke your parser on the program, and print one of two answers:
- the string
valid program - an error message indicating the one or more errors found by your parser
4. The kleinf Command
Finally,
Create an executable or a Unix command-line script named
kleinf that takes the name of a Klein
program as an argument and runs your validation program
on it.
For example:
$ ./kleinf programs/print-one.kln valid program
This is the second in a series of tools that makes up the command-line suite of your Klein compiler.
Deliverables
As before, submit only one copy of each assignment per team. The team captain or a designated team member can be responsible for the submission.
Status Check
You will need to refactor Klein's grammar in order to make it unambiguous before you build your parse table.
Submit:
- your refactored grammar, and
- a list of the changes you made to the grammar.
Make these documents a part of the ongoing documentation of your compiler.
Record your answers in a single file, plaintext or PDF, and email the file to the instructor by the status check due date.
Final Deliverable
By the due time and date, use
the course submission system
to submit
your project directory
electronically as a zip file named project02.zip
or project02.tar.gz.