Translator - Expression Type With Parentheses

Determining the expression type to report the appropriate error within a parenthetical expression without another operator on the hold stack involves a little more work. To accomplish this, the expression type needs to carried from before the opening parentheses.

To prevent having to scan backwards into the expression, when the opening parentheses is pushed on to the hold stack, the opening parentheses token will be assigned a data type, if possible, otherwise the data type will be left at the default data type of none (which will cause the generic “expected expression” error if an error occurs).

Here are several possibility of tokens that will be on the hold stack when an opening parentheses token is about to be pushed onto the hold stack and how to determine the data type to put into the parentheses token:

Operator – get the expected operand data type of operator
Internal function – get the expected argument operand data type of function
Token with parentheses – can not determine data type
Opening parentheses – inherit this token's data type
Null – Look at data type for item on top of command stack

The first four possibilities are the same as before, so a common function will probably be implemented to handle determining the data type for the opening parentheses token. The last possibilities will require looking for the expected data type for the command on the command stack. Here are some examples of commands and expected data types for expressions:

LET A = (  - assign token on command stack will have data type of variable
PRINT (  - PRINT can take any type of expression, therefore none
INPUT PROMT (  - INPUT PROMPT expects string expression
IF (  - IF expects numerical expression

The IF statement has not been defined as of yet, but most likely will expect an integer expression (the result of all logical operators). However, a double expression will be accepted either with a different IF code expecting a double expression or the more likely, a hidden integer conversion code will be inserted. The IF will be defined later. Now on to the implementation of this...

Translator - Expression Type Determination

In the Eleventh (error statements) tests, the are many statements for testing the correct error message in a line that contains something unexpected, like either an unexpected comma or end-of-line. One of these was just corrected (see last post) – the situation when the Translator is not in a parenthetical expression including inside array subscripts or function arguments. This was detected when the count stack is empty.

The situation when in an internal function has also been handled when the operand processing was implemented. The code simply checks for the expected operand type for the current operand. An internal function is detected when the number of expected operands for the item on top of the count stack is non-zero. The current operand number is in the number of operands in top item on the count stack.

For the remaining situation, the code was simply returning an “expected expression” error, since it was assumed that the type of expression could not be determined. Turns out, this is not entirely true. Two sub-conditions to this situation are inside a parentheses and inside an array or non-internal function (a token with a parentheses). Each of these can be further sub-divided into whether this is an operator or not. Here are examples of each of these four conditions (terminated with an unexpected end-of-line):

Z = (  in parentheses, no operator
Z = (A+  in Parentheses, with operator
Z = A(  in token with parentheses, no operator
Z = A(B+  in token with parentheses, with operator

In the third case, the expected expression type can't be determined because the Translator does not know if A is an array (expression must be numeric for a subscript) or a function (expression can be any type), therefore the “expected expression” error is appropriate. In the other cases, the expression type can be determined and in these examples, this would mean an “expected numeric expression” error.

For the two cases with an operator, the data type of the operand or the operator on top of the hold stack can be used to determine the expected type of expression to follow (just like for a non-parenthetical expression just corrected). For the first case, with just a parentheses, determining the expression type is a little more involved...