A state in a CEK machine includes a control statement, environment and continuation.
The control statement is the term being evaluated at that moment, the environment is (usually) a map from variable names to values, and the continuation stores another state, or a special halt case.
For example, the CESK machine has the environment map variables to a pointer on the store, which is effectively a heap.
It is sometimes a call stack, where each frame is the rest of the state, i.e. a control statement and an environment.
The control statement was written in postfix notation, and the machine had its own "programming language".
-Calculus", [9] and on page 4 of the technical report with the same name, [10] Matthias Felleisen and Daniel P. Friedman wrote "The [CEK] machine is derived from Reynolds' extended interpreter IV.
[11] [12] To wit, here is an implementation of the CEK machine in OCaml, representing lambda terms with de Bruijn indices: Values are closures, as invented by Peter Landin: This implementation is in defunctionalized form, with cont and continue as the first-order representation of a continuation.
It is the usual Scott-Tarski definitional self-interpreter where the domain of values is reflexive (Scott) and where syntactic functions are defined as semantic functions and syntactic applications are defined as semantic applications (Tarski).
This derivation mimics Danvy's rational deconstruction of Landin's SECD machine.
[14] The converse derivation (closure conversion, CPS transformation, and defunctionalization) is documented in John Reynolds's article "Definitional Interpreters for Higher-Order Programming Languages", which is the origin of the CEK machine and was subsequently identified as a blueprint for transforming compositional evaluators into abstract machines as well as vice versa.