The phase of a robot description record.

A unique identifier for a robot.

A value of type RobotR is a record representing the state of a single robot. The f parameter is for tracking whether or not the robot has been assigned a unique ID.

A concrete robot, with a unique ID number and a specific location.

A template robot, i.e. a template robot record without a unique ID number, and possibly without a location.

Enumeration of robot updates. This type is used for changes by e.g. the drill command which must be carried out at a later tick. Using a first-order representation (as opposed to e.g. just a Robot -> Robot function) allows us to serialize and inspect the updates.

Note that this can not be in Robot as it would create a cyclic dependency.

A record that stores the information for all definitions stored in a Robot

Robots are not entities, but they have almost all the characteristics of one (or perhaps we could think of robots as very special sorts of entities), so for convenience each robot carries an Entity record to store all the information it has in common with any Entity.

Note there are various lenses provided for convenience that directly reference fields inside this record; for example, one can use robotName instead of writing robotEntity . entityName.

The name of a robot.

The name of a robot template.

Entities that the robot cannot move onto

The creation date of the robot.

The Display of a robot. This is a special lens that automatically sets the curOrientation to the orientation of the robot every time you do a get operation. Technically this does not satisfy the lens laws---in particular, the get/put law does not hold. But we should think of the curOrientation as being simply a cache of the displayed entity's direction.

The robot's current location, represented as (x,y). This is only a getter, since when changing a robot's location we must remember to update the robotsByLocation map as well. You can use the updateRobotLocation function for this purpose.

Set a robot's location. This is unsafe and should never be called directly except by the updateRobotLocation function. The reason is that we need to make sure the robotsByLocation map stays in sync.

A template robot's location. Unlike robotLocation, this is a lens, since when dealing with robot templates there is as yet no robotsByLocation map to keep up-to-date.

Which way the robot is currently facing.

The robot's inventory.

A separate inventory for equipped devices, which provide the robot with certain capabilities.

Note that every time the inventory of equipped devices is modified, this lens recomputes a cached set of the capabilities the equipped devices provide, to speed up subsequent lookups to see whether the robot has a certain capability (see robotCapabilities)

The robot's own private message log, most recent message last. Messages can be added both by explicit use of the Log command, and by uncaught exceptions. Stored as a Seq so that we can efficiently add to the end and also process from beginning to end. Note that updating via this lens will also set the robotLogUpdated.

Has the robotLog been updated since the last time it was viewed?

A hash of a robot's entity record and equipped devices, to facilitate quickly deciding whether we need to redraw the robot info panel.

Get the set of capabilities this robot possesses. This is only a getter, not a lens, because it is automatically generated from the equippedDevices. The only way to change a robot's capabilities is to modify its equippedDevices.

The robot's context.

The robot's context.

The (unique) ID number of the robot. This is only a Getter since the robot ID is immutable.

The ID number of the robot's parent, that is, the robot that built (or most recently reprogrammed) this robot, if there is one.

Is this robot extra heavy (thus requiring tank treads to move)?

The robot's current CEK machine state.

Is this robot a "system robot"? System robots are generated by the system (as opposed to created by the user) and are not subject to the usual capability restrictions.

Does this robot wish to self destruct?

Is the robot currently running an atomic block?

Diagnostic and operational tracking of CESK steps or other activity

A counter that is decremented upon each step of the robot within the CESK machine. Initially set to robotStepsPerTick at each new tick.

The need for tickStepBudget is a bit technical, and I hope I can eventually find a different, better way to accomplish it. Ideally, we would want each robot to execute a single command at every game tick, so that e.g. two robots executing move;move;move and repeat 3 move (given a suitable definition of repeat) will move in lockstep. However, the second robot actually has to do more computation than the first (it has to look up the definition of repeat, reduce its application to the number 3, etc.), so its CESK machine will take more steps. It won't do to simply let each robot run until executing a command---because robot programs can involve arbitrary recursion, it is very easy to write a program that evaluates forever without ever executing a command, which in this scenario would completely freeze the UI. (It also wouldn't help to ensure all programs are terminating---it would still be possible to effectively do the same thing by making a program that takes a very, very long time to terminate.) So instead, we allocate each robot a certain maximum number of computation steps per tick (defined in evalStepsPerTick), and it suspends computation when it either executes a command or reaches the maximum number of steps, whichever comes first.

It seems like this really isn't something the robot should be keeping track of itself, but that seemed the most technically convenient way to do it at the time. The robot needs some way to signal when it has executed a command, which it currently does by setting tickStepBudget to zero. However, that has the disadvantage that when tickStepBudget becomes zero, we can't tell whether that happened because the robot ran out of steps, or because it executed a command and set it to zero manually.

Perhaps instead, each robot should keep a counter saying how many commands it has executed. The loop stepping the robot can tell when the counter increments.

Total number of tangible commands executed over robot's lifetime

Histogram of commands executed over robot's lifetime

Total number of CESK steps executed over robot's lifetime. This could be thought of as "CPU cycles" consumed, and is labeled as "cycles" in the F2 dialog in the UI.

Sliding window over a span of ticks indicating ratio of activity

A general function for creating robots.

Instantiate a robot template to make it into a concrete robot, by providing a robot ID. Concrete robots also require a location; if the robot template didn't have a location already, just set the location to (0,0) by default. If you want a different location, set it via trobotLocation before calling instantiateRobot.

Does a robot know of an entity's existence?

Is the robot actively in the middle of a computation?

Active robots include robots that are waiting; wantsToStep is true if the robot actually wants to take another step right now (this is a subset of active robots).

The time until which the robot is waiting, if any.

Get the result of the robot's computation if it is finished.