New Translator – Array Assignments

The next problem occurred in an incomplete array assignment statement (a single identifier with parentheses at the beginning of the line).  This type of token at the beginning of the line implies that the identifier is an array as opposed to a function, since these (function names with parentheses) can't be at the beginning of the line (can't be assigned).  An array at the beginning of the line also implies that the operands are subscripts and must be numeric.

The first change to correct this issue was made in the get operand routine.  The reference flag of the token was set after calling the get parentheses token routine.  This was moved to before the call so that the get parentheses token routine, that gets the operands (subscripts in this case) knows when the token is an array being assigned (as opposed to not knowing whether it is an array of a function).

The second change was made in the get parentheses token routine.  Previously the Any data type was passed to the get expression routine, since the translator is not aware of whether the identifier with parentheses is an array or a function (and if a function doesn't know the types of the arguments, at least not right now).  However, for an array assignment, it knows that the subscripts must be integers.  So if the reference flag of the token is set, it will pass the Number data type (a double can be converted to an integer).

In making this change, I realized there was another issue.  The get expression routine doesn't do all it should with the passed data type.  It gets passed to to sub-expression of parentheses, but generally it is only being used when an error is detected to report the correct "expected XX expression" error.  This issue will be addressed shortly

[commit 688816adb9]

New Translator – Additional Issues

As it so happens, translator test #5 was not the last of the LET tests.  There is also test #7 (Error Tests), #8 (More Errors), #9 (Semicolon Errors), #10 (Expression Errors), #11 (Temporary Strings), #13 (Negative Constants), and #14 (Parser Errors, but also contains PRINT and INPUT statements).  Unfortunately, all of these tests fail, three with glibc double free or corruption errors and one with a segmentation fault.

The first problem in test #7 was caused when handling the expression inside parentheses.  When an error occurred, the get expression routine just continued on to the next token.  The rest of the parentheses processing was skipped (popping the open parentheses token off of the hold stack, replacing the first and last operands of the done item on top of the done stack, setting the last precedence, and saving the pending parentheses token).  This problem was corrected by returning when get expression returns an error for the sub-expression.

[commit 9d87ab2c03]