Progress

This week I worked on porting the interpreter from Arduino C to python, and implemented error checking.

I first worked on getting individual commands to work first. Handling commands was straightforward since the only command to implement with the remote, laptop version is print. Handling variables was a little more involved, since I needed to work with evaluating an expression. I changed eval_expression completely, so that it now recursively evaluates expressions. I split up eval (helper function for eval_expression that does all the work) to use three helper functions depending on the type of operator I encountered: num * num -> num, num * num -> bool, and bool * bool -> bool. This would help with error checking down the road. For now, evaluating an expression evaluates left to right. Eric worked on experimenting with pemdas and adding parentheses, which I can add on as an extra feature down the road.

Handing conditionals was the most involved. It seems that the old Build18 code only dealt with while(1) loops, so they were not worried about loop termination. However, after experimentation, I realized that once the loop guard fails, run_code needs to know which line of code to run next. In assembly, this would be kind of like a jump or a goto. I scan the while, if or else, and since this is an indentation based language, the goto points to the next line where the indentation is back to where I started. I return this to run_code, and if the loop guard on while or if fails, it knows which line to execute next (skipping over the lines inside the while loop).

Then I implemented error checking. There are four possible errors:

1. ERROR_INDENT: When the indentation is off. Since this is an indentation based language, the interpreter must be able to evaluate code according to indentation.
2. ERROR_TYPE: Checks types during evaluating expressions based on the operator
3. ERROR_DIVZERO: Checks whether the divisor (second expression) passed in to a division or mod function is not zero.
4. ERROR_SYNTAX: Unexpected syntax.

Though this may not be a comprehensive list of errors, I’ve laid down the foundation of error checking and it is very straightforward to add more types of errors and throw errors in the interpreter. In the interpreter itself, error handling is done using exceptions. When I encounter an error, I throw an InterpreterError with the specified error code and the tile coordinates of where this error happened. If there is an error, I catch it and print out (for now) what the error was and where it occurred. This is useful to the user for debugging. Furthermore, I will use this information in the GUI to create a visual error display.

Schedule

I am on track for the interpreter and error checking, and I am scheduled to start on the GUI today. I will be starting a little later because of exams and projects in other classes, but hope to finish on time.

I am also planning on writing a simple top level program that knows which functions to call. It receives the stream from the master tile (by deserializing), passes it to the translator to translate into CodeBlox code, passes the output to the interpreter, and passes the CodeBlox outline and interpreter output to the GUI. This would make communication between the code components easier. Because of this, I will be pushing deserialization back.

Goals for next week:

1. Write a GUI to simulate CodeBlox input, output and debugging information.