10.4 Continuations🔗ℹ

Continuations in The Racket Guide introduces continuations.

See Sub-expression Evaluation and Continuations and Prompts, Delimited Continuations, and Barriers for general information about continuations. Racket’s support for prompts and composable continuations [Flatt07] closely resembles Sitaram’s % and fcontrol operator [Sitaram93].

Racket installs a continuation barrier around evaluation in the following contexts, preventing full-continuation jumps into the evaluation context protected by the barrier:

• applying an exception handler, an error escape handler, or an error display handler (see Exceptions);

• applying a macro transformer (see Syntax Transformers), evaluating a compile-time expression, or applying a module name resolver (see Resolving Module Names);

• applying a custom-port procedure (see Custom Ports), an event guard procedure (see Events), or a parameter guard procedure (see Parameters);

• applying a security-guard procedure (see Security Guards);

• applying a will procedure (see Wills and Executors); or

• evaluating or loading code from the stand-alone Racket command line (see Running Racket or GRacket).

In addition, extensions of Racket may install barriers in additional contexts. Finally, call-with-continuation-barrier applies a thunk barrier between the application and the current continuation.

The handler argument specifies a handler procedure to be called in tail position with respect to the call-with-continuation-prompt call when the installed prompt is the target of an abort-current-continuation call with prompt-tag; the remaining arguments of abort-current-continuation are supplied to the handler procedure. If handler is #f, the default handler accepts a single abort-thunk argument and calls (call-with-continuation-prompt abort-thunk prompt-tag #f); that is, the default handler re-installs the prompt and continues with a given thunk.

The protocol for vs supplied to an abort is specific to the prompt-tag. When abort-current-continuation is used with (default-continuation-prompt-tag), generally, a single thunk should be supplied that is suitable for use with the default prompt handler. Similarly, when call-with-continuation-prompt is used with (default-continuation-prompt-tag), the associated handler should generally accept a single thunk argument.

Each thread’s continuation starts with a prompt for (default-continuation-prompt-tag) that uses the default handler, which accepts a single thunk to apply (with the prompt intact).

Changed in version 7.9.0.13 of package base: The name argument gives the name of the prompt tag.

The captured continuation is delivered to proc, which is called in tail position with respect to the call-with-current-continuation call.

If the continuation argument to proc is ever applied, then it removes the portion of the current continuation up to the nearest prompt tagged by prompt-tag (not including the prompt; if no such prompt exists, the exn:fail:contract:continuation exception is raised), or up to the nearest continuation frame (if any) shared by the current and captured continuations—whichever is first. While removing continuation frames, dynamic-wind post-thunks are executed. Finally, the (unshared portion of the) captured continuation is appended to the remaining continuation, applying dynamic-wind pre-thunks.

The arguments supplied to an applied procedure become the result values for the restored continuation. In particular, if multiple arguments are supplied, then the continuation receives multiple results.

If, at application time, a continuation barrier would be introduced by replacing the current continuation with the applied one, then the exn:fail:contract:continuation exception is raised.

A continuation can be invoked from the thread (see Threads) other than the one where it was captured.

When call-with-composable-continuation is called, if a continuation barrier appears in the continuation before the closest prompt tagged by prompt-tag, the exn:fail:contract:continuation exception is raised (because attempting to apply the continuation would always fail).

A continuation obtained from call-with-escape-continuation is actually a kind of prompt. Escape continuations are provided mainly for backwards compatibility, since they pre-date general prompts in Racket. In the BC implementation of Racket, call-with-escape-continuation is implemented more efficiently than call-with-current-continuation, so call-with-escape-continuation can sometimes replace call-with-current-continuation to improve performance in those older Racket variants.

Added in version 7.6.0.17 of package base.

When dynamic-wind calls pre-thunk for normal evaluation of value-thunk, the continuation of the pre-thunk application calls value-thunk (with dynamic-wind’s special jump handling) and then post-thunk. Similarly, the continuation of the post-thunk application returns the value of the preceding value-thunk application to the continuation of the entire dynamic-wind application.

When pre-thunk is called due to a continuation jump, the continuation of the call to pre-thunk

• jumps to a more deeply nested pre-thunk, if any, or jumps to the destination continuation; then

• continues the same as the enclosing dynamic-wind call in the destination continuation (i.e., matching the continuation of the original dynamic-wind call up to the enclosing prompt that delimited capture).

Normally, the second part of this continuation is never reached, due to a jump in the first part. However, the second part is relevant because it enables jumps to escape continuations that are contained in the continuation of the dynamic-wind call within the destination continuation. Furthermore, it means that the continuation marks (see Continuation Marks) and parameterization (see Parameters) for pre-thunk correspond to those of the enclosing dynamic-wind call. The pre-thunk call, however, is parameterize-breaked to disable breaks (see also Breaks).

Similarly, when post-thunk is called due to a continuation jump, the continuation of calling post-thunk jumps to a less deeply nested post-thunk, if any, or jumps to a pre-thunk protecting the destination, if any, or jumps to the destination continuation, then continues the same as the enclosing dynamic-wind call within the originating continuation for the jump. As for pre-thunk, the continuation marks and parameterization of the dynamic-wind call are in place for post-thunk, except that the call is further parameterize-breaked to disable breaks.

In both cases, the destination for a jump is recomputed after each pre-thunk or post-thunk completes. When a prompt-delimited continuation (see Prompts, Delimited Continuations, and Barriers) is captured in a post-thunk, it might be delimited and instantiated in such a way that the destination of a jump turns out to be different when the continuation is applied than when the continuation was captured. There may even be no appropriate destination, if a relevant prompt or escape continuation is not in the continuation after the restore; in that case, the first step in a pre-thunk or post-thunk’s continuation can raise an exception.

10.4.1 Additional Control Operators🔗ℹ

The racket/control library provides various control operators from the research literature on higher-order control operators, plus a few extra convenience forms. These control operators are implemented in terms of call-with-continuation-prompt, call-with-composable-continuation, etc., and they generally work sensibly together. Many are redundant; for example, reset and prompt are interchangeable.

That is, (abort v ...) is equivalent to

(abort-current-continuation

(default-continuation-prompt-tag)

(lambda () (values v ...)))

syntax (% expr) (% expr handler-expr) (% expr handler-expr #:tag tag-expr)

procedure (fcontrol v #:tag prompt-tag) → any   v : any/c   prompt-tag : (default-continuation-prompt-tag)

Sitaram’s operators [Sitaram93].

The essential reduction rules are:

(% val proc) => val

(% E[(fcontrol val)] proc) => (proc val (lambda (x) E[x]))

; where E has no %

When handler-expr is omitted, % is the same as prompt. If prompt-tag is provided, % uses specific prompt tags like prompt-at.

(prompt-at tag val) => val

(prompt-at tag E[(control-at tag k expr)]) => (prompt-at tag

((lambda (k) expr)

(lambda (v) E[v])))

; where E has no prompt-at for tag

The essential reduction rules are:

(reset val) => val

(reset E[(shift k expr)]) => (reset ((lambda (k) expr)

(lambda (v) (reset E[v]))))

; where E has no reset

The reset and prompt forms are interchangeable.

The essential reduction rules are:

(prompt0 val) => val

(prompt0 E[(control0 k expr)]) => ((lambda (k) expr)

(lambda (v) E[v]))

(reset0 val) => val

(reset0 E[(shift0 k expr)]) => ((lambda (k) expr)

(lambda (v) (reset0 E[v])))

The reset0 and prompt0 forms are interchangeable. Furthermore, the following reductions apply:

(prompt E[(control0 k expr)]) => (prompt ((lambda (k) expr)

(lambda (v) E[v])))

(reset E[(shift0 k expr)]) => (reset ((lambda (k) expr)

(lambda (v) (reset0 E[v]))))

(prompt0 E[(control k expr)]) => (prompt0 ((lambda (k) expr)

(lambda (v) E[v])))

(reset0 E[(shift k expr)]) => (reset0 ((lambda (k) expr)

(lambda (v) (reset E[v]))))

That is, both the prompt/reset and control/shift sites must agree for 0-like behavior, otherwise the non-0 behavior applies.

The essential reduction rules are:

(spawn proc)

=> (prompt/spawn tag

(proc (lambda (proc) (abort/spawn tag proc))))

; where tag is a freshly generated prompt tag

(prompt/spawn tag val)

=> val

(prompt/spawn tag E[(abort/spawn tag proc)])

=> (proc (lambda (x) (prompt/spawn tag E[x])))

; where E has no prompt/spawn for tag

In this library, new-prompt is an alias for make-continuation-prompt-tag, set is an alias for prompt0-at, and cupto is an alias for control0-at.

Changed in version 8.10.0.5 of package base: The new-prompt function is now really an alias for make-continuation-prompt-tag.