From 7c75c48196f557534a1a616fa2566aaf25fe9dfe Mon Sep 17 00:00:00 2001 From: Henrik Tidefelt Date: Tue, 18 Aug 2009 20:29:25 +0200 Subject: [PATCH] Doc: On continuations. --- doc/parts/dynamic/continuations.sxml | 64 ++++++++++++++++++++++++++++++++++++ doc/parts/dynamic/index.sxml | 1 + doc/parts/syntax/continuations.sxml | 24 +++++++++++--- 3 files changed, 85 insertions(+), 4 deletions(-) create mode 100644 doc/parts/dynamic/continuations.sxml diff --git a/doc/parts/dynamic/continuations.sxml b/doc/parts/dynamic/continuations.sxml new file mode 100644 index 00000000..8480f439 --- /dev/null +++ b/doc/parts/dynamic/continuations.sxml @@ -0,0 +1,64 @@ + + + + + + + + + + + + + + + + + +
+Escape continuations + +

The escape continuations in are not treated as dynamic variables, but they are nevertheless dynamically bound, which is why they are listed among the global dynamic variables. In the non-interactive mode of the compiler, there is only one globally available escape continuation, but there are some more available in the interactive mode.

+

See for more information on escape continuations in general.

+ + + +

General-purpose error-handling.

 + + + +

Abort program evaluation, providing the message and backtrace to the compiler for display.

 + +

By using a dedicated escape continuation rather than an immediatly aborting construct, it is possible to detect and recover in some error situations.

+ +

Historical note. Early versions of had an error core function, causing the evaluation to be aborted immediately, but there was no way to detect and recover.

+ + + + + +

Quit compiler.

 + + + + + + +

Described in . Only available in interactive mode.

+ + + +

The read-evaluate-print loop of the interactive mode.

 + + + +

Described in . Only available in interactive mode.

+ + + +

Resume program after break during interactive debugging.

 + depends on context +

Described in . Only available in debug context in interactive mode.

+ + +
diff --git a/doc/parts/dynamic/index.sxml b/doc/parts/dynamic/index.sxml index 4b4b57ba..6a4a6963 100644 --- a/doc/parts/dynamic/index.sxml +++ b/doc/parts/dynamic/index.sxml @@ -36,6 +36,7 @@ + diff --git a/doc/parts/syntax/continuations.sxml b/doc/parts/syntax/continuations.sxml index a7fc029b..62824a3c 100644 --- a/doc/parts/syntax/continuations.sxml +++ b/doc/parts/syntax/continuations.sxml @@ -20,20 +20,27 @@

is currently implemented using full-scale continuations, but their use is restricted by only allowing them to be bound dynamically. This restriction is enforced using special syntax to handle continuations. Note that a dynamically bound continuation merely provides the same functionality as an escape continuation.

+

It must be admitted that there are several features in that are not orthogonal to the use of continuations. The list below mentions the known problems briefly, but only the first item in the list concerns escape continuations. +

    +
  • Delayed evaluation. Delaying the invocation of a continuation may cause unexpected results. For instance, evaluation may proceed and modify states which were not meant to be modified, or invocation of another continuation may cause the first continuation to never be invoked.
    • +
  • Expression states. (This is not a problem for escape continuations.) A continuation will not capture the current state of expression states. While quite natural from one point of view (imagine capturing and restoring the state of , for instance!), this will require that the expression states are kept alive as long as an expression may be re-entered, basically breaking the local (in syntax and time) nature of expression states.
    • +
  • Code bracket bindings. (This is not a problem for escape continuations.) The semantics of variable bindings in the are similar to the letrec construct in Scheme — both hide imperative assignments, meant to be executed exactly once. As with expression states, the state of variable bindings are not captured and restored by the continuation, and it will be an error if re-entering an expression causes a variable to be bound more than once.
    • +
+ Dealing with these problems comes down to being cautious and careful use of forced evaluation (see ). Despite these warnings, the escape continuations are well suited for error handling, and their use is recommended for this purpose. +

+

The reader is referred to the WWW for details on continuations and continuation passing style evaluation. One place to start would be the documentation for call-with-current-continuation found in R5RS. Here, we only describe the related syntax briefely.

→ "(" escape_continuation ")" → "(" escape_continue ")" + → "(" escape_backtrace ")"

The construct introduces an escape continuation in the dynamic environment (although the identifier does not look like a dynamic variable), and evaluates the expression in the new dynamic environment.

To escape through an escsape continuation, the construct is used. The identifier must refer to an escape continuation in dynamic scope, and evaluation continues by evaluating the new expression with the appropriate continuation.

+

Since a continuation holds the information necessary to generate a backtrace, and backtraces are harmless for the semantics of a program, does provide value-access to continuations disguised as backtraces. Evaluating results in a the referenced continuation, wrapped inside a .

The keywords continuation and continue are reserved for future use.

- -

Even if continuations are presently handled in a way such that it cannot be determined if they are functions or not, I find it really obscuring to hide a continuation inside a function. Hence, if continuations are made available more generally in the future, don't expect them to be wrapped in functions. If a function that behaves like a continuation object in Scheme is needed, such a function will be easy to construct.

- - ]]> @@ -43,5 +50,14 @@ + +

Unlike continuations in Scheme, the escape continuations in are not invoked as if they were functions. The most important reason for this is that this would require the continuation itself to be accessible as a value, which would make it possible to invoke the continuation also in non-escaping contexts. Another good reason not to use the function application syntax is that invoking a continuation is conceptually something very different from function application for someone who doesn't think in terms of the continuation passing transform.

+

However, the importance of the conceptual difference may be questioned, since one can easily define a function that invokes a particular escape continuation when called: +

+
+
+Now, non-escaping continuations — would they be allowed in in the future — would not require special syntax to prevent the access to continuations as values. Hence, if non-escaping continuations are allowed in in the future, it is not obvious if they would be wrapped in functions (and hence invoked using function application) or invoked with special syntax.

+ + -- 2.11.4.GIT