Read the project specifications. Sketch out a plan for what your code will look like including

• What is the input?
• What is the output?
• What methods will you need in order to read and advance the token stream from project 1?
• What is the design pattern that all non-terminals follow, and how does it relate to managing the rules in the grammar?
• What is the design pattern that all terminals follow, and how does it relate to what symbol is next in the token stream?

After doing this, write things that are confusing about what the lab is asking. This will help you prepare for the lab help sessions that the TA's are giving.

These two things will need to be submitted with this worksheet.

For each of the following production rules, match your planned code with the rule (e.g., by copying the rule and the method you plan to implement for the rule onto the same piece of paper and then drawing lines that link each terminal and non-terminal symbol with the code that either directly checks for it or calls a procedure to process it).

<datalogProgram> --> SCHEMES COLON <scheme> <schemeList>
                     FACTS COLON <fact> <factList>
                     RULES COLON <rule> <ruleList>
                     QUERIES COLON <query> <queryList>
<scheme> -->  ID LEFT_PAREN <idList> RIGHT_PAREN
<schemeList> --> <scheme> <schemeList> | <math> \lambda </math>

As directed below, explain how your planned code will parse the following predicate: a32(‘example’, (x*(y+z))). (Clarification on February 4, 2014 to help you translate the predicate to the stream of tokens.) The token stream for this predicate is the following: ID LEFT_PAREN STRING COMMA LEFT_PAREN ID MULTIPLY LEFT_PAREN ID ADD ID RIGHT_PAREN RIGHT_PAREN RIGHT_PAREN

• Your parser is parsing tokens, not characters. Give the first three tokens parsed for the predicate above.
• For your planned code, create a “call tree” for parsing the predicate above. In your code you should have a method named Predicate or parsePredicate; it is to be the root node of the call tree. Add the names of called procedures as child nodes to parent nodes in the call tree, left to right, in the order called.
• Mark each edge in the call tree that represents a recursive call. If the planned code is truly a recursive descent parser, why must there be recursive calls for this example (even if the ParameterListTail is processed iteratively)?