594 Assignment 8: Robot Interpreter, part 1
Spring 2007, David Matuszek
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
- The argument to this method is a Tree that evaluates to an integer.
- The argument to this method evaluates to a boolean.
- 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.
One definition of
column as additional
definitions, similar to
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.
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
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
I am providing an interface named
RobotBehavior that describes
all the things a robot can do. I will shortly provide a class
"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
There are three "read only" variables:
distance. Assignment to these variables has no effect; to get
their values, use the robot methods
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:
seeing <thing>is true if the named thing is the nearest thing in the direction that the robot is facing.
smelling <thing>is true if the named thing is in the same square as the robot, or in one of the adjacent squares.
facing <direction>is true if the robot is facing in the named direction (which must be one of
To test these conditions, call the robot methods
the same semantics in RoboTalk as they do in Java.
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.
return statement, if executed in the "main program" (that is, not in a
method), causes the robot program to terminate.
The various actions (
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.
For now, test those methods that do not depend on the robot doing what it is told. Other tests can come later.
Zip the complete Eclipse project and submit via Blackboard before midnight Tuesday, April 3.