Friday, September 13, 2013

Encoder/Translator – Design Considerations

In preparing for implementation of the next Encoder step of actually encoding the RPN list of tokens into program code, I realized that were some design issues.  The first minor issue was that assigning codes and assigning program code word indexes with word counting can't be in the same loop because later for arrays, integer conversion codes may need to be inserted after subscripts, which will trip up the indexes already sett and the words counted.  These indexes and word count could be adjusted as items are inserted, but it would more efficient to have two loops.

In further consideration of the design, I realized that the these first steps should really be in the translator and not the encoder.  The code for these steps were moved to the translator (executed after successfully getting the commands for the line).  A new test mode option was needed so that this call would not be made when just testing the translator so the expected translator test results would not change.

However, I realized that the translator could assign the codes before waiting until the end of the translation.  The codes could be assigned when the tokens are first processed, specifically in the get operand routine.  Also, the translator cannot work in a vacuum, meaning it will need access to the existing program, specifically the various dictionaries so that the types of tokens can be determined (variables, arrays, or functions).

Therefore, the translator will be changed to this new scheme of assigned codes to tokens in the get operand routine, but over the next several commits, with the exception that the dictionaries are not implemented yet.  The first change made was to move the first two encoder steps into the translator and two separate loops, though this is a temporary step (and the encoder class is now empty, but this is also temporary).

The second change in this transition was to add a temporary check to determine if an identifier with parentheses is an array or function.  Eventually this will be accomplished with the array and function dictionaries.  To make this determination simple, if the identifier starts with the 'F' letter, then it is considered a function, otherwise it is considered an array.  This affected the expected results because array subscripts are checked for integers with integer conversions added as needed.

[commit f9f0cd3de7] [commit 9111d8e0f8]