In preparation for the new INPUT translate routine, some minor changes were needed. The first change was add default values to the process final operand routine for the second token and the operand index arguments. The second token argument is used when processing operators where it is given the first token of the operator being processed and this second token is used for binary operators to set its first token when it is pushed on the done stack.
The old translator routines also set the second token to the closing parentheses token for tokens with parentheses, but the new translator routines do not call the process final operand routine for these tokens. Also for the new translator, the operand index will only be used for operators. In addition to operators, the new translator will only use the process final operand routine for special codes like PrintDbl and InputAssignDbl, and these will not require the second operand or operand index arguments.
The other change involved adding a new reference type in additional to None, Variable and All. The new VarDefFn type is to allow variables and defined function references only and not sub-string references (as in sub-string assignments). The Variable reference type was modified to only allow variables and not defined function assignments. The get operand routine was modified to support these changes. The INPUT command will use the Variable reference type since defined functions cannot be input. The get internal function routine was modified to use the new reference type for sub-string assignments (because defined functions of type string will support sub-string assignments, at least this is the current plan).
[commit b670ab38f6] [commit a79f117c52]
Saturday, August 17, 2013
Associated Code Processing Reorganization
During the design of the INPUT statement translation, some code reorganization was needed, specifically in the Translator find code routine, which processes the done stack top item (that was last added to the RPN output list) to check its data type to see if it matches the expected operand data type of the operator or internal function being processed, and if not looks to see if there is an associated code with that expected data type. If no associated code is found, then checks to see if the data type of the operand can be converted (a hidden convert code is added to the output if it can), or else determines the appropriate error. Upon success, the done stack top item is dropped.
The find code routine had evolved into a somewhat complicated function. It is also used to take a base code (for example PrintDbl, and will also be used for InputAssignType) and change it to an associated code for the data type of the operand on top of the done stack. The functionality of looking up an associated code from a base code for a given data type will also be needed in the Encoder (to be implemented soon now), for example, taking the VarDbl code (that pushes a double variable value to the evaluation stack during run-time), and changing it as needed to VarInt or VarStr for the data type of a token with no parentheses.
Since the future Encoder class should not need to call a Translator class function for this, and since this is really the functionality of the Table class (all the associated code and data type information is in the Table), the part of the find code routine that does this was moved into a new find code routine in the Table class. Some unused code was discovered (part of it even containing a bug, but was causing a problem since the code was not used), which was removed when the code was moved.
The Translator find code routine was renamed to the process done stack top routine to more appropriately describe its functionality. The convert code have need table was also moved from the translator to the table source file. As a result, a new Table convert code access function was needed, that takes a token and data type and returns the convert code needed (including a null code for no convert code or invalid if conversion is not possible). Some comments were also added documenting code that needs to be removed when the old translator routines are finally removed.
[commit b5fa514ca9]
The find code routine had evolved into a somewhat complicated function. It is also used to take a base code (for example PrintDbl, and will also be used for InputAssignType) and change it to an associated code for the data type of the operand on top of the done stack. The functionality of looking up an associated code from a base code for a given data type will also be needed in the Encoder (to be implemented soon now), for example, taking the VarDbl code (that pushes a double variable value to the evaluation stack during run-time), and changing it as needed to VarInt or VarStr for the data type of a token with no parentheses.
Since the future Encoder class should not need to call a Translator class function for this, and since this is really the functionality of the Table class (all the associated code and data type information is in the Table), the part of the find code routine that does this was moved into a new find code routine in the Table class. Some unused code was discovered (part of it even containing a bug, but was causing a problem since the code was not used), which was removed when the code was moved.
The Translator find code routine was renamed to the process done stack top routine to more appropriately describe its functionality. The convert code have need table was also moved from the translator to the table source file. As a result, a new Table convert code access function was needed, that takes a token and data type and returns the convert code needed (including a null code for no convert code or invalid if conversion is not possible). Some comments were also added documenting code that needs to be removed when the old translator routines are finally removed.
[commit b5fa514ca9]
Subscribe to:
Posts (Atom)