commit b44f1f5e2cdd52f325ea3475e8291173d7693cb5
parent 805e92a0811bb52307f2b0195a233c565bf9688c
Author: Wolfgang Corcoran-Mathe <wcm@sigwinch.xyz>
Date: Tue, 30 Jan 2024 19:01:11 -0500
3.5: Texify.
Diffstat:
1 file changed, 98 insertions(+), 70 deletions(-)
diff --git a/doc/r7rs-small/r7rs-small.texinfo b/doc/r7rs-small/r7rs-small.texinfo
@@ -1020,16 +1020,20 @@ other systems to distinguish between mutable and immutable objects.
@node Proper tail recursion
@section Proper tail recursion
-Implementations of Scheme are required to be properly tail-recursive. Procedure calls that
-occur in certain syntactic contexts defined below are tail calls. A Scheme implementation is
-properly tail-recursive if it supports an unbounded number of active tail calls. A call is
-active if the called procedure might still return. Note that this includes calls that might be
-returned from either by the current continuation or by continuations captured earlier by
-call-with-current-continuation that are later invoked. In the absence of captured
-continuations, calls could return at most once and the active calls would be those that had
-not yet returned. A formal definition of proper tail recursion can be found in [6].
-
-Rationale: Intuitively, no space is needed for an active tail call because the
+Implementations of Scheme are required to be @dfn{properly tail-recursive}.
+Procedure calls that occur in certain syntactic contexts defined below are
+@dfn{tail calls}. A Scheme implementation is properly tail-recursive if it
+supports an unbounded number of active tail calls. A call is @dfn{active} if
+the called procedure might still return. Note that this includes calls that
+might be returned from either by the current continuation or by
+continuations captured earlier by @code{call-with-current-continuation} that
+are later invoked. In the absence of captured continuations, calls could
+return at most once and the active calls would be those that had not yet
+returned. A formal definition of proper tail recursion can be found in [6].
+
+@subheading Rationale
+
+Intuitively, no space is needed for an active tail call because the
continuation that is used in the tail call has the same semantics as the continuation
passed to the procedure containing the call. Although an improper implementation
might use a new continuation in the call, a return to this new continuation would be
@@ -1046,83 +1050,102 @@ Steele and Sussman later observed that in their interpreter the code for dealing
actors was identical to that for functions and thus there was no need to include both
in the language.
-A tail call is a procedure call that occurs in a tail context. Tail contexts are defined
+A @dfn{tail call} is a procedure call that occurs in a tail context. Tail contexts are defined
inductively. Note that a tail context is always determined with respect to a particular
lambda expression.
@itemize
@item
The last expression within the body of a lambda expression, shown as <tail expression>
- below, occurs in a tail context. The same is true of all the bodies of case-lambda
- expressions.
+below, occurs in a tail context. The same is true of all the bodies of @code{case-lambda}
+expressions.
@example
- (lambda <formals>
- <definition>* <expression>* <tail expression>)
- (case-lambda (<formals> <tail body>)*)
+(lambda <formals>
+ <definition>* <expression>* <tail expression>)
+
+(case-lambda (<formals> <tail body>)*)
@end example
@item
If one of the following expressions is in a tail context, then the subexpressions shown
- as <tail expression> are in a tail context. These were derived from rules in the grammar
- given in chapter 7 by replacing some occurrences of <body> with <tail body>, some
- occurrences of <expression> with <tail expression>, and some occurrences of
- <sequence> with <tail sequence>. Only those rules that contain tail contexts are shown
- here.
-
-@example
-
- (if <expression> <tail expression> <tail expression>)
- (if <expression> <tail expression>)
- (cond <cond clause>+)
- (cond <cond clause>* (else <tail sequence>))
- (case <expression>
- <case clause>+)
- (case <expression>
- <case clause>*
- (else <tail sequence>))
- (and <expression>* <tail expression>)
- (or <expression>* <tail expression>)
- (when <test> <tail sequence>)
- (unless <test> <tail sequence>)
- (let (<binding spec>*) <tail body>)
- (let <variable> (<binding spec>*) <tail body>)
- (let* (<binding spec>*) <tail body>)
- (letrec (<binding spec>*) <tail body>)
- (letrec* (<binding spec>*) <tail body>)
- (let-values (<mv binding spec>*) <tail body>)
- (let*-values (<mv binding spec>*) <tail body>)
- (let-syntax (<syntax spec>*) <tail body>)
- (letrec-syntax (<syntax spec>*) <tail body>)
- (begin <tail sequence>)
- (do (<iteration spec>*)
+as <tail expression> are in a tail context. These were derived from rules in the grammar
+given in @ref{Formal syntax and semantics} by replacing some occurrences of <body> with <tail body>, some
+occurrences of <expression> with <tail expression>, and some occurrences of
+<sequence> with <tail sequence>. Only those rules that contain tail contexts are shown
+here.
+
+@c Maybe @format would be better here. FIXME: We still need markup
+@c for metavariables.
+@display
+(@code{if} <expression> <tail expression> <tail expression>)
+(@code{if} <expression> <tail expression>)
+
+(@code{cond} <cond clause>+)
+(@code{cond} <cond clause>* (else <tail sequence>))
+
+(@code{case} <expression>
+ <case clause>+)
+(@code{case} <expression>
+ <case clause>*
+ (else <tail sequence>))
+
+(@code{and} <expression>* <tail expression>)
+(@code{or} <expression>* <tail expression>)
+
+(@code{when} <test> <tail sequence>)
+(@code{unless} <test> <tail sequence>)
+
+(@code{let} (<binding spec>*) <tail body>)
+(@code{let} <variable> (<binding spec>*) <tail body>)
+(@code{let*} (<binding spec>*) <tail body>)
+(@code{letrec} (<binding spec>*) <tail body>)
+(@code{letrec*} (<binding spec>*) <tail body>)
+(@code{let-values} (<mv binding spec>*) <tail body>)
+(@code{let*-values} (<mv binding spec>*) <tail body>)
+
+(@code{let-syntax} (<syntax spec>*) <tail body>)
+(@code{letrec-syntax} (<syntax spec>*) <tail body>)
+
+(@code{begin} <tail sequence>)
+
+(@code{do} (<iteration spec>*)
(<test> <tail sequence>)
- <expression>*)
- where
- <cond clause> ⟶(<test> <tail sequence>)
- <case clause> ⟶((<datum>*) <tail sequence>)
- <tail body> ⟶<definition>* <tail sequence>
- <tail sequence> ⟶<expression>* <tail expression>
+ <expression>*)
+@end display
-@end example
+where
+
+@display
+<cond clause> @expansion{} (<test> <tail sequence>)
+<case clause> @expansion{} ((<datum>*) <tail sequence>)
+<tail body> @expansion{} <definition>* <tail sequence>
+<tail sequence> @expansion{} <expression>* <tail expression>
+
+@end display
@item
-If a cond or case expression is in a tail context, and has a clause of the form
- (<expression1> => <expression2>) then the (implied) call to the procedure that results
- from the evaluation of <expression2> is in a tail context. <expression2> itself is not in a
- tail context.
+If a @code{cond} or @code{case} expression is in a tail context, and has
+a clause of the form @code{(}<expression> @code{=>} <expression>@code{)}
+then the (implied) call to
+the procedure that results from the evaluation of <expression> is in a
+tail context. <expression> itself is not in a tail context.
@end itemize
-Certain procedures defined in this report are also required to perform tail calls. The first
-argument passed to apply and to call-with-current-continuation, and the second
-argument passed to call-with-values, must be called via a tail call. Similarly, eval must
-evaluate its first argument as if it were in tail position within the eval procedure.
+Certain procedures defined in this report are also required to perform tail calls.
+The first argument passed to @code{apply} and to
+@code{call-with-current-continuation}, and the second argument passed to
+@code{call-with-values}, must be called via a tail call.
+Similarly, @code{eval} must evaluate its first argument as if it
+were in tail position within the @code{eval} procedure.
-In the following example the only tail call is the call to f. None of the calls to g or h are tail
-calls. The reference to x is in a tail context, but it is not a call and thus is not a tail call.
+In the following example the only tail call is the call to @code{f}.
+None of the calls to @code{g} or @code{h} are tail calls. The reference to
+@code{x} is in a tail context, but it is not a call and thus is not a
+tail call.
@example
@@ -1134,11 +1157,16 @@ calls. The reference to x is in a tail context, but it is not a call and thus is
@end example
-Note: Implementations may recognize that some non-tail calls, such as the call to h
-above, can be evaluated as though they were tail calls. In the example above, the let
-expression could be compiled as a tail call to h. (The possibility of h returning an
-unexpected number of values can be ignored, because in that case the effect of the
-let is explicitly unspecified and implementation-dependent.)
+@subheading Note
+
+Implementations may
+recognize that some non-tail calls, such as the call to @code{h}
+above, can be evaluated as though they were tail calls.
+In the example above, the @code{let} expression could be compiled
+as a tail call to @code{h}. (The possibility of @code{h} returning
+an unexpected number of values can be ignored, because in that
+case the effect of the @code{let} is explicitly unspecified and
+implementation-dependent.)
@node Expressions
@chapter Expressions
