Next: Inference system interpretation
Up: Partial constructions
Previous: Compositional closure
State machine interpretation
A quadruple can be used to model a very common kind of state
machine, that moves from state to state in response to inputs,
at each step consuming one input, and emitting one output.
- A - a set of states
- B - a family of sets B(a), one for each state a,
B(a) represents the set of inputs legal in state a.
- C - a family of sets C(a,b), one for each state a and input b which is legal in state a.
C(a,b) represents the set of possible responses to
a legal input b in state a.
- d - a function which assigns to each triple:
(a : A, b : B(a), c : C(a,b)) a state, representing the next state of the
machine.
The operation of such a machine can be depicted as follows:
Note that it can happen that in some states, there are no legal
inputs, so that the user is stymied, or deadlocked; also it can happen
that there are inputs - effectively `stop' commands for which there is
no legal response.
A morphism between quadruples, under the state-machine interpretation, is a
simulation of one machine (the virtual machine) by another
(the real machine). The state of the virtual machine is a function
of the state of the real machine, and there are functions to translate
between the inputs and outputs in the right way. The inputs to the
real machine might be programs, if the real machine
is the compositional closure of a basic instruction set;
the outputs from the real machine are then traces of the execution of
these programs.
In general such a machine need not be deterministic, in the sense that
the response of the machine is not necessarily predictable from its
present state and input. A deterministic machine is one for which the
outputs can be predicted given the inputs and start state. So for a
deterministic machine, C(a,b) is always either empty or a singleton.)
For a deterministic user, B(a) is always either empty or a singleton,
and the machine has all the choice.
The interpretation of the `star' operator is as follows.
- B* - the elements of B*(a), for state a, are partial strategies
for issuing inputs to the machine, starting from initial state a.
Strategy b ensures that if the machine keeps responding, it will
reach a state at a leaf in b. If
the tree has no leaves, then eventually the machine has no response,
and interaction ceases.
- C* - the elements of C(a,b), for state a and strategy b are sequences of machine outputs that lead to undetermined points in
the strategy b.
- d* - the function which assigns to each triple:
(a : A, b :
B*(a), c : C*(a,b)) the final state of the machine when the user
has followed the strategy b, and the machine has responded with
output sequence c.
The interpretation of the dual of the above construction is as follows.
- the elements of
,
for state a, are partial
implementations, or partially determined strategies for the machine
to respond to inputs, starting from initial state a. Strategy b ensures that if the user keeps issuing inputs, the machine will
reach a state at some leaf in b. If the tree has no leaves, then
eventually there are no more inputs the user can make, and interaction
ceases.
- the elements of
,
for state a and strategy b are sequences of user inputs that lead to an undetermined, or
failure point in the strategy b.
- the function which assigns to each triple:
the final state of the machine when it
has followed the strategy b, and the user has issued the
sequence of inputs c.
I'm fond of this interpretation. Perhaps
programming is after all only an application of the theory of
ordinals? Ordinals are just the purest possible paradigms of
well-founded structures, and here we have a broad class of well
founded structures that serve as very apt modelling material when
describing and designing clients and implementations of state
machines. This is a very broad class of programs - a program that
uses the services of an operating system or makes network calls to a
remote resource is `just' such a client; the system which responds
to those calls is just such an implementation. The client's
primitive for invoking an action is essentially the
constructor. On the server side, decoding a command and dispatching
to give the appropriate response and next-state is essentially
the
constructor.
Next: Inference system interpretation
Up: Partial constructions
Previous: Compositional closure
Peter Hancock
1998-04-08