CIT 594 Assignment 8: Robot Interpreter, part 1
Spring 2007, David Matuszek


General Idea:

In previous assignments, you have created a syntax tree representing a program for a robot. In this assignment, you will interpret the program and issue commands to a robot. (I will provide the "robot.")

A future goal is to put your robot in a game with other people's robots, and see which robots do the best. This will involve writing a program in the "RoboTalk" language; and may the robot with the best program win.


In a previous assignment you wrote a class named Interpreter with these methods:

int evaluate(Tree<String>)
The argument to this method is a Tree that evaluates to an integer.

boolean evaluateBoolean(Tree<String>)
The argument to this method evaluates to a boolean.

void interpret(Tree<String>)
The argument to this method has no value.

This time we will be doing something very similar. In fact, you may be able to use a lot of the code from this previous assignment. At the very least, you should be able to look at it for ideas.

In the earlier assignment, you used a quick-and-dirty parser that I wrote in order to construct the trees. This time, you have your own recursive descent parser.

Addition to the grammar

One definition of <factor> is distance. Please add row and column as additional definitions, similar to distance.

The main class

Because your robot will eventually be put in a game with other robots, it is essential that your "main" class have a unique name. You can name your robot after yourself, or just pick an interesting name that other people are unlikely to use.

Your main method will call another method or methods to ask the user for a file containing the robot's program (in the RoboTalk language), read it in, and construct a parse tree. Then it will interpret that tree. Don't put too much logic in the main method itself, because that's really just for testing; when we have multiple robots, I will have to supply a suitable main method.

I am providing an interface named RobotBehavior that describes all the things a robot can do. I will shortly provide a class RobotStandIn that "implements" these behaviors by just printing out what it was asked to do; later, I hope to provide a more interesting class that implements RobotBehavior. Your interpreter should handle all the arithmetic and control logic, and call these methods to make the robot "do something." That is, your interpreter should evaluate expressions, interpret if statements and loops, and so forth, but it should call a robot method to move, turn, see what direction it is facing, etc.


All arithmetic is integer arithmetic.

Variables are "declared" by using them. If the program asks for the value of a variable before that variable has been given a value, it is assumed to have the value zero. You will need to keep a HashMap of variables and their values.

There are three "read only" variables: row, column, and distance. Assignment to these variables has no effect; to get their values, use the robot methods getRow(), getColumn(), and getDistance(), respectively. The first two give the current location of the robot, while the third tells the distance to the nearest "thing" in the direction that the robot is facing.

There are three robot conditions:

To test these conditions, call the robot methods boolean seeing(String), boolean smelling(String), and boolean facing(String).

The while statement and the if statement have the same semantics in RoboTalk as they do in Java.

The repeat statement computes the value of its expression, then executes its block that many times. The expression is only evaluated once, at the beginning of the loop; if variables in the expression are changed within the block, that does not affect how many times the loop is executed. If the expression has a zero or negative value, the block is not executed at all.

The return statement, if executed in the "main program" (that is, not in a method), causes the robot program to terminate.

The various actions (move, turn, take, drop, and zap) are performed by calling robot methods with the obvious names.

Do not implement methods and method calls for this assignment. We will do that later.

Test classes

For now, test those methods that do not depend on the robot doing what it is told. Other tests can come later.

Supplied code:

Due date:

Zip the complete Eclipse project and submit via Blackboard before midnight Tuesday, April 3.