The term continuation is as important as the term environment in determining the fate of a program. "Real" environments, modeled as association lists or some other data structure, can be made explicit in programs and can prove their usefulness by clarifying tricky binding issues. Similarly, once we define continuation, several different models will be identified, each associated with a different style of programming, and we will find them useful in helpimg us understand control issues.
A continuation, like an environment, is always defined relative to a program in execution. Recall that we speak always of "the current environment" or "the environment that was current when ...", identifying each environment with the subexpression that is being executed. Similarly, a continuation will always be specified relative to the executing subexpression, as though we had taken a "snapshot" of the executing program.
Suppose program P contains some subexpression E that is either currently executing or about to begin executing. The continuation of E in P describes the steps required to finish the program after E returns. That is, the subprogram of P which corresponds to the "rest of the program", from the point of E's return, to the point at which the final result is delivered to the user.
In every executing program there is always a notion of "current continuation", which is constantly changing as the program progresses. However, this continuation is seldom manifest as an actual Scheme procedure. (The one notable exception occurs when using continuation passing style (CPS), which we shall get to soon enough.) Rather, the current continuation is often described informally.