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]