Thinking ahead to assignment operator…
Right now, the expression parsing is something like
- if current token is variable, integer or function call, is next token an operator?
- then call the operator’s grammar.
- else end the expression
This is where I need to get the PLUS operator’s grammar to check whether or not there is an ASSIGN operator nested higher up (to the left in the statement). Eg, the nesting of the expression:
a + b + c + d
… would look like (d + (c + (b + a))) in the syntax tree. This means that (d + whatever) contains (c + whatever) which contains (a + b). … eep. I might have this backward, but I’m pretty sure my recursion goes from right to left. Reading the sample code, the left operand ‘a’ is 'bundled with the right, ‘b’, and then nested within the next left operand (a + b) against the next right operand, ‘c’, etc.
Now let me look at variations on this nesting structure using the assignment operator.
a = b + c + d
Here’s the nesting structure I’ll need (a = (d + (c + b))) for that one.
These next two should result in syntax errors.
a + b = c + d a + b + c = d
Now I need to figure out an algorithm to nest these statements so that the error is reliably detected.
First example nesting
(((a + b) = c) + d)
Basically, the case for the assignment operator, ‘=’, should check the object/production type of the left side of the expression. If the production is an arithmetic (ie ‘+’, ‘*’, ‘-’ or ‘/’), the parser’s expression grammar should raise a syntax error. I think this error should be detected three expression calls deep: single expr, plus, assignment
Second example nesting
(((a + b) + c) = d)
This is similar to the above, but it should take four expression calls to detect the error: single expr, plus, plus, assignment
That is how I will begin solving the assignment operator.