New Translator – Data Type Checking

Up until now, the data type passed to the new get expression and get operand routines was only used to the return the appropriate error when a problem was detected.  The intention was that this data type be used to check that the resulting expression before returning to the caller of the get expression routine.  This simplifies the design in that the callers don't have to check if the expression is the correct type - the checking is done in one place.  Also part of this, any hidden conversion codes are added (to convert from integer to double or double to integer).

The get operand routine cannot check the data type of the operand obtained against the data type passed.  Consider the valid expression A%+(B$=C$).  After the open parentheses, the expected data type for the second operand of the add operator would be a number.  An error can't be reported against the B$ operand.  This checking will be handled when the operator is processed.  However, when the caller of the get operand routine requests a reference, the data type of the reference operand can be checked.

These routines were modified to check the data type.  The get expression required a new level argument, which is incremented for each level of parentheses recursively calls the get expression routine.  A simple flag could have been used instead of a level value, but having an actual level value could be useful for debugging.  Only at the end of the expression at the first level can the data type be checked.  For the Any data type, no checking is done, and for the Number data type, the data type can either be Double or Integer (no conversion code is added).  Otherwise, hidden conversion codes are added to the RPN output list as needed or an error is reported.

Callers of these routines no longer need to check the resulting expression or reference operand.  Previously for internal functions and tokens with parentheses, the find code routine was called for each argument (internal function at each comma) and the process final operand routine was called for the final argument or sub-script (at the closing parentheses).  These routines no long need to be called (but are still used for processing operators).

All of the translator tests that only contain assignment statements (though three have a single PRINT statement) still pass successfully.  One statement in test #8 contained an array assignment with a string sub-script.  The old translator did not catch this error (capability was not implemented).  The new translator without these latest data type checking also did not even though a numeric expression was requested, the data type was not actually checked.  The expected results for test #8 were updated for this (and the old results saved).  For more details of all the changes needed, see the commit log.

[commit b4a908b60d]