5A First Sample World

5.1Understanding a Door

Say we want to represent a door with an automatic door closer. If this kind
of door is locked, you can unlock it. While this doesn’t open the door per
se, it is now possible to do so. That is, an unlocked door is closed and
pushing at the door opens it. Once you have passed through the door and
you let go, the automatic door closer takes over and closes the door
again. Of course, at this point you could lock it again.

Here is a picture that translates our words into a graphical
representation:

The picture displays a so-called "state machine". The three circled words
are the states that our informal description of the door identified:
locked, closed (and unlocked), and open. The arrows specify how the door
can go from one state into another. For example, when the door is open,
the automatic door closer shuts the door as time passes. This transition
is indicated by the arrow labeled "time passes." The other arrows
represent transitions in a similar manner:

"push" means a person pushes the door open (and let’s go);

"lock" refers to the act of inserting a key into the lock and turning
it to the locked position; and

"unlock" is the opposite of "lock".

5.2Simulations of the World

Simulating any dynamic behavior via a program demands two different
activities. First, we must tease out those portions of our "world" that
change over time or in reaction to actions, and we must develop a data
representation D for this information. Keep in mind that a good data
definition makes it easy for readers to map data to information in the
real world and vice versa. For all others aspects of the world, we use
global constants, including graphical or visual constants that are used in
conjunction with the rendering operations.

Second, we must translate the "world" actions – the arrows in the above
diagram – into interactions with the computer that the world teachpack can
deal with. Once we have decided to use the passing of time for one aspect
and mouse movements for another, we must develop functions that map the
current state of the world – represented as data – into the next state of
the world. Since the data definition D describes the class of data
that represents the world, these functions have the following general
contract and purpose statements:

That is, the contracts of the various hooks dictate what the contracts of
these functions are once we have defined how to represent the world in
data.

A typical program does not use all three of these actions and functions but
often just one or two. Furthermore, the design of these functions provides
only the top-level, initial design goal. It often demands the design of
many auxiliary functions.

5.3Simulating a Door: Data

Our first and immediate goal is to represent the world as data. In this
specific example, the world consists of our door and what changes about
the door is whether it is locked, unlocked but closed, or open. We use
three symbols to represent the three states:

SD

; DATADEF.

; Thestateofthedoor(SD)isoneof:

; --'locked

; --'closed

; --'open

Symbols are particularly well-suited here because they directly express
the state of the door.

Now that we have a data definition, we must also decide which computer
actions and interactions should model the various actions on the door.
Our pictorial representation of the door’s states and transitions,
specifically the arrow from "open" to "closed" suggests the use of a
function that simulates time. For the other three arrows, we could use
either keyboard events or mouse clicks or both. Our solution uses three
keystrokes:
"#\\u" for unlocking the door,
"#\\l" for locking it, and
"#\\space" for pushing it open.
We can express these choices graphically by translating the above "state
machine" from the world of information into the world of data:

5.4Simulating a Door: Functions

Our analysis and data definition leaves us with three functions to design:

"automatic-closer", which closes the time during one tick;

"door-actions", which manipulates the time in response to
pressing a key; and

"render", which translates the current state of the door into
a visible scene.

Let’s start with "automatic-closer". We know its contract and it is
easy to refine the purpose statement, too:

For the remaining three arrows of the diagram, we design a function that
reacts to the three chosen keyboard events. As mentioned, functions that
deal with keyboard events consume both a world and a keyevent:

The function "symbol->string" translates a symbol into a string,
which is needed because "text" can deal only with the latter, not
the former. A look into the language documentation revealed that this
conversion function exists, and so we use it.

Once everything is properly designed, it is time to run the
program. In the case of the world teachpack, this means we must specify
which function takes care of tick events, key events, and redraws: