commit a6eea356c4d51b5f50f72439e0cf671aa3e30845
parent 077ac5487d9fe843f2c488906ad8232fc2a8697b
Author: Wolfgang Corcoran-Mathe <wcm@sigwinch.xyz>
Date: Tue, 30 Jan 2024 21:08:19 -0500
Use @svar throughout for syntactic variables (rough).
Diffstat:
1 file changed, 537 insertions(+), 537 deletions(-)
diff --git a/doc/r7rs-small/r7rs-small.texinfo b/doc/r7rs-small/r7rs-small.texinfo
@@ -394,22 +394,22 @@ If
category is ``syntax,'' the entry describes an expression type, and the template gives the
syntax of the expression type. Components of expressions are designated by syntactic
-variables, which are written using angle brackets, for example <expression> and
-<variable>. Syntactic variables are intended to denote segments of program text; for
-example, <expression> stands for any string of characters which is a syntactically valid
+variables, which are written using angle brackets, for example @svar{expression} and
+@svar{variable}. Syntactic variables are intended to denote segments of program text; for
+example, @svar{expression} stands for any string of characters which is a syntactically valid
expression. The notation
@display
-<thing@sub{1}> @dots{}
+@svar{thing@sub{1}} @dots{}
@end display
-indicates zero or more occurrences of a <thing>, and
+indicates zero or more occurrences of a @svar{thing}, and
@display
-<thing@sub{1}> <thing@sub{2}> @dots{}
+@svar{thing@sub{1}} @svar{thing@sub{2}} @dots{}
@end display
-indicates one or more occurrences of a <thing>.
+indicates one or more occurrences of a @svar{thing}.
If
@@ -699,8 +699,8 @@ whitespace.
A semicolon (@samp{;}) indicates the start of a line comment.The comment continues to the end
of the line on which the semicolon appears. Another way to indicate a comment is to
-prefix a <datum> (cf. section 7.1.2) with @code{#;} and optional <whitespace>. The comment
-consists of the comment prefix #;, the space, and the <datum> together. This notation is
+prefix a @svar{datum} (cf. section 7.1.2) with @code{#;} and optional @svar{whitespace}. The comment
+consists of the comment prefix #;, the space, and the @svar{datum} together. This notation is
useful for ``commenting out'' sections of code.
Block comments are indicated with properly nested @code{#|} and @code{|#} pairs.
@@ -1066,10 +1066,10 @@ bodies of @code{case-lambda} expressions.
@example
-(lambda <formals>
- <definition>* <expression>* <tail expression>)
+(lambda @svar{formals}
+ @svar{definition}* @svar{expression}* <tail expression>)
-(case-lambda (<formals> <tail body>)*)
+(case-lambda (@svar{formals} <tail body>)*)
@end example
@@ -1077,34 +1077,34 @@ bodies of @code{case-lambda} expressions.
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 @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>
+by replacing some occurrences of @svar{body} with <tail body>, some occurrences
+of @svar{expression} with <tail expression>, and some occurrences of @svar{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{if} @svar{expression} <tail expression> <tail expression>)
+(@code{if} @svar{expression} <tail expression>)
(@code{cond} <cond clause>+)
(@code{cond} <cond clause>* (else <tail sequence>))
-(@code{case} <expression>
+(@code{case} @svar{expression}
<case clause>+)
-(@code{case} <expression>
+(@code{case} @svar{expression}
<case clause>*
(else <tail sequence>))
-(@code{and} <expression>* <tail expression>)
-(@code{or} <expression>* <tail expression>)
+(@code{and} @svar{expression}* <tail expression>)
+(@code{or} @svar{expression}* <tail expression>)
-(@code{when} <test> <tail sequence>)
-(@code{unless} <test> <tail sequence>)
+(@code{when} @svar{test} <tail sequence>)
+(@code{unless} @svar{test} <tail sequence>)
(@code{let} (<binding spec>*) <tail body>)
-(@code{let} <variable> (<binding spec>*) <tail body>)
+(@code{let} @svar{variable} (<binding spec>*) <tail body>)
(@code{let*} (<binding spec>*) <tail body>)
(@code{letrec} (<binding spec>*) <tail body>)
(@code{letrec*} (<binding spec>*) <tail body>)
@@ -1117,25 +1117,25 @@ here.
(@code{begin} <tail sequence>)
(@code{do} (<iteration spec>*)
- (<test> <tail sequence>)
- <expression>*)
+ (@svar{test} <tail sequence>)
+ @svar{expression}*)
@end display
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>
+<cond clause> @expansion{} (@svar{test} <tail sequence>)
+<case clause> @expansion{} ((@svar{datum}*) <tail sequence>)
+<tail body> @expansion{} @svar{definition}* <tail sequence>
+<tail sequence> @expansion{} @svar{expression}* <tail expression>
@end display
@item
If a @code{cond} or @code{case} expression is in a tail context, and has a
-clause of the form @code{(}<expression@sub{1}> @code{=>} <expression@sub{2}>@code{)} then
+clause of the form @code{(}@svar{expression@sub{1}} @code{=>} @svar{expression@sub{2}}@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
+@svar{expression} is in a tail context. @svar{expression} itself is not in a tail
context.
@end itemize
@@ -1206,7 +1206,7 @@ intimately associated with the @code{delay}, @code{delay-force}, and
@node Variable references
@subsection Variable references
-syntax: <variable>
+syntax: @svar{variable}
An expression consisting of a variable
(@xref{Variables - syntactic keywords - and regions}) is a variable
@@ -1224,11 +1224,11 @@ x @result{} 28
@node Literal expressions
@subsection Literal expressions
-syntax: (quote <datum>)
-syntax: '<datum>
-syntax: <constant>
+syntax: (quote @svar{datum})
+syntax: '@svar{datum}
+syntax: @svar{constant}
-@code{(quote} <datum>@code{)} evaluates to <datum>. <Datum> can be any
+@code{(quote} @svar{datum}@code{)} evaluates to @svar{datum}. @svar{Datum} can be any
external representation of a Scheme object
(@xref{External representations (basic)}). This notation is used to include
literal constants in Scheme code.
@@ -1241,7 +1241,7 @@ literal constants in Scheme code.
@end example
-@code{(quote} <datum>@code{)} can be abbreviated as @code{'}<datum>. The two
+@code{(quote} @svar{datum}@code{)} can be abbreviated as @code{'}@svar{datum}. The two
notations are equivalent in all respects.
@example
@@ -1283,7 +1283,7 @@ procedure like @code{set-car!} or @code{string-set!}.
@node Procedure calls
@subsection Procedure calls
-syntax: (<operator> <operand1> @dots{})
+syntax: (@svar{operator} @svar{operand1} @dots{})
A procedure call is written by enclosing in parentheses an expression for the procedure to
be called followed by expressions for the arguments to be passed to it. The operator and
@@ -1322,9 +1322,9 @@ to itself. In Scheme, it is an error.
@node Procedures
@subsection Procedures
-syntax: (lambda <formals> <body>)
+syntax: (lambda @svar{formals} @svar{body})
-Syntax: <Formals> is a formal arguments list as described below, and <body> is a sequence
+Syntax: @svar{Formals} is a formal arguments list as described below, and @svar{body} is a sequence
of zero or more definitions followed by one or more expressions.
Semantics: A lambda expression evaluates to a procedure. The environment in effect when
@@ -1356,21 +1356,21 @@ will be returned as the results of the procedure call.
@end example
-<Formals> have one of the following forms:
+@svar{Formals} have one of the following forms:
@itemize
@item
-(<variable1> @dots{}): The procedure takes a fixed number of arguments; when the
+(@svar{variable1} @dots{}): The procedure takes a fixed number of arguments; when the
procedure is called, the arguments will be stored in fresh locations that are bound to
the corresponding variables.
@item
-<variable>: The procedure takes any number of arguments; when the procedure is
+@svar{variable}: The procedure takes any number of arguments; when the procedure is
called, the sequence of actual arguments is converted into a newly allocated list, and
-the list is stored in a fresh location that is bound to <variable>.
+the list is stored in a fresh location that is bound to @svar{variable}.
@item
-(<variable1> @dots{} <variablen> . <variablen+1>): If a space-delimited period precedes the last
+(@svar{variable1} @dots{} @svar{variablen} . @svar{variablen+1}): If a space-delimited period precedes the last
variable, then the procedure takes n or more arguments, where n is the number of
formal arguments before the period (it is an error if there is not at least one). The value
stored in the binding of the last variable will be a newly allocated list of the actual
@@ -1379,7 +1379,7 @@ the other formal arguments.
@end itemize
-It is an error for a <variable> to appear more than once in <formals>.
+It is an error for a @svar{variable} to appear more than once in @svar{formals}.
@example
@@ -1396,15 +1396,15 @@ section 6.1).
@node Conditionals (if)
@subsection Conditionals (if)
-syntax: (if <test> <consequent> <alternate>)
-syntax: (if <test> <consequent>)
+syntax: (if @svar{test} @svar{consequent} @svar{alternate})
+syntax: (if @svar{test} @svar{consequent})
-Syntax: <Test>, <consequent>, and <alternate> are expressions.
+Syntax: @svar{Test}, @svar{consequent}, and @svar{alternate} are expressions.
-Semantics: An if expression is evaluated as follows: first, <test> is evaluated. If it yields a
-true value(see section 6.3), then <consequent> is evaluated and its values are returned.
-Otherwise <alternate> is evaluated and its values are returned. If <test> yields a false
-value and no <alternate> is specified, then the result of the expression is unspecified.
+Semantics: An if expression is evaluated as follows: first, @svar{test} is evaluated. If it yields a
+true value(see section 6.3), then @svar{consequent} is evaluated and its values are returned.
+Otherwise @svar{alternate} is evaluated and its values are returned. If @svar{test} yields a false
+value and no @svar{alternate} is specified, then the result of the expression is unspecified.
@example
@@ -1419,10 +1419,10 @@ value and no <alternate> is specified, then the result of the expression is unsp
@node Assignments
@subsection Assignments
-syntax: (set! <variable> <expression>)
+syntax: (set! @svar{variable} @svar{expression})
-Semantics: <Expression> is evaluated, and the resulting value is stored in the location to
-which <variable> is bound. It is an error if <variable> is not bound either in some
+Semantics: @svar{Expression} is evaluated, and the resulting value is stored in the location to
+which @svar{variable} is bound. It is an error if @svar{variable} is not bound either in some
regionenclosing the set! expression or else globally. The result of the set! expression is
unspecified.
@@ -1438,8 +1438,8 @@ unspecified.
@node Inclusion
@subsection Inclusion
-syntax: (include <string1> <string2> @dots{})
-syntax: (include-ci <string1> <string2> @dots{})
+syntax: (include @svar{string1} @svar{string2} @dots{})
+syntax: (include-ci @svar{string1} @svar{string2} @dots{})
Semantics: Both include and include-ci take one or more filenames expressed as string
literals, apply an implementation-specific algorithm to find corresponding files, read the
@@ -1474,30 +1474,30 @@ described in this section into the primitive constructs described in the previou
@node Conditionals (cond)
@subsection Conditionals (cond)
-syntax: (cond <clause1> <clause2> @dots{})
+syntax: (cond @svar{clause1} @svar{clause2} @dots{})
auxiliary syntax: else
auxiliary syntax: =>
-Syntax: <Clauses> take one of two forms, either
+Syntax: @svar{Clauses} take one of two forms, either
-(<test> <expression1> @dots{})where <test> is any expression, or (<test> => <expression>)The
-last <clause> can be an ``else clause,'' which has the form (else <expression1>
-<expression2> @dots{}).
+(@svar{test} @svar{expression1} @dots{})where @svar{test} is any expression, or (@svar{test} => @svar{expression})The
+last @svar{clause} can be an ``else clause,'' which has the form (else @svar{expression1}
+@svar{expression2} @dots{}).
-Semantics: A cond expression is evaluated by evaluating the <test> expressions of
-successive <clause>s in order until one of them evaluates to a true value(see section 6.3).
-When a <test> evaluates to a true value, the remaining <expression>s in its <clause> are
-evaluated in order, and the results of the last <expression> in the <clause> are returned
+Semantics: A cond expression is evaluated by evaluating the @svar{test} expressions of
+successive @svar{clause}s in order until one of them evaluates to a true value(see section 6.3).
+When a @svar{test} evaluates to a true value, the remaining @svar{expression}s in its @svar{clause} are
+evaluated in order, and the results of the last @svar{expression} in the @svar{clause} are returned
as the results of the entire cond expression.
-If the selected <clause> contains only the <test> and no <expression>s, then the value of
-the <test> is returned as the result. If the selected <clause> uses the => alternate form,
-then the <expression> is evaluated. It is an error if its value is not a procedure that
-accepts one argument. This procedure is then called on the value of the <test> and the
+If the selected @svar{clause} contains only the @svar{test} and no @svar{expression}s, then the value of
+the @svar{test} is returned as the result. If the selected @svar{clause} uses the => alternate form,
+then the @svar{expression} is evaluated. It is an error if its value is not a procedure that
+accepts one argument. This procedure is then called on the value of the @svar{test} and the
values returned by this procedure are returned by the cond expression.
-If all <test>s evaluate to #f, and there is no else clause, then the result of the conditional
-expression is unspecified; if there is an else clause, then its <expression>s are evaluated in
+If all @svar{test}s evaluate to #f, and there is no else clause, then the result of the conditional
+expression is unspecified; if there is an else clause, then its @svar{expression}s are evaluated in
order, and the values of the last one are returned.
@example
@@ -1514,30 +1514,30 @@ order, and the values of the last one are returned.
@end example
-syntax: (case <key> <clause1> <clause2> @dots{})
+syntax: (case @svar{key} @svar{clause1} @svar{clause2} @dots{})
-Syntax: <Key> can be any expression. Each <clause> has the form
+Syntax: @svar{Key} can be any expression. Each @svar{clause} has the form
-((<datum1> @dots{}) <expression1> <expression2> @dots{}),where each <datum> is an external
-representation of some object. It is an error if any of the <datum>s are the same
-anywhere in the expression. Alternatively, a <clause> can be of the form ((<datum1> @dots{}) =>
-<expression>)The last <clause> can be an ``else clause,'' which has one of the forms (else
-<expression1> <expression2> @dots{})
-or (else => <expression>).
+((@svar{datum1} @dots{}) @svar{expression1} @svar{expression2} @dots{}),where each @svar{datum} is an external
+representation of some object. It is an error if any of the @svar{datum}s are the same
+anywhere in the expression. Alternatively, a @svar{clause} can be of the form ((@svar{datum1} @dots{}) =>
+@svar{expression})The last @svar{clause} can be an ``else clause,'' which has one of the forms (else
+@svar{expression1} @svar{expression2} @dots{})
+or (else => @svar{expression}).
-Semantics: A case expression is evaluated as follows. <Key> is evaluated and its result is
-compared against each <datum>. If the result of evaluating <key> is the same (in the
-sense of eqv?; see section 6.1) to a <datum>, then the expressions in the corresponding
-<clause> are evaluated in order and the results of the last expression in the <clause> are
+Semantics: A case expression is evaluated as follows. @svar{Key} is evaluated and its result is
+compared against each @svar{datum}. If the result of evaluating @svar{key} is the same (in the
+sense of eqv?; see section 6.1) to a @svar{datum}, then the expressions in the corresponding
+@svar{clause} are evaluated in order and the results of the last expression in the @svar{clause} are
returned as the results of the case expression.
-If the result of evaluating <key> is different from every <datum>, then if there is an else
+If the result of evaluating @svar{key} is different from every @svar{datum}, then if there is an else
clause, its expressions are evaluated and the results of the last are the results of the case
expression; otherwise the result of the case expression is unspecified.
-If the selected <clause> or else clause uses the => alternate form, then the <expression> is
+If the selected @svar{clause} or else clause uses the => alternate form, then the @svar{expression} is
evaluated. It is an error if its value is not a procedure accepting one argument. This
-procedure is then called on the value of the <key> and the values returned by this
+procedure is then called on the value of the @svar{key} and the values returned by this
procedure are returned by the case expression.
@example
@@ -1555,9 +1555,9 @@ procedure are returned by the case expression.
@end example
-syntax: (and <test1> @dots{})
+syntax: (and @svar{test1} @dots{})
-Semantics: The <test> expressions are evaluated from left to right, and if any expression
+Semantics: The @svar{test} expressions are evaluated from left to right, and if any expression
evaluates to #f (see section 6.3), then #f is returned. Any remaining expressions are not
evaluated. If all the expressions evaluate to true values, the values of the last expression
are returned. If there are no expressions, then #t is returned.
@@ -1571,9 +1571,9 @@ are returned. If there are no expressions, then #t is returned.
@end example
-syntax: (or <test1> @dots{})
+syntax: (or @svar{test1} @dots{})
-Semantics: The <test> expressions are evaluated from left to right, and the value of the
+Semantics: The @svar{test} expressions are evaluated from left to right, and the value of the
first expression that evaluates to a true value (see section 6.3) is returned. Any remaining
expressions are not evaluated. If all expressions evaluate to #f or if there are no
expressions, then #f is returned.
@@ -1588,9 +1588,9 @@ expressions, then #f is returned.
@end example
-syntax: (when <test> <expression1> <expression2> @dots{})
+syntax: (when @svar{test} @svar{expression1} @svar{expression2} @dots{})
-Syntax: The <test> is an expression.
+Syntax: The @svar{test} is an expression.
Semantics: The test is evaluated, and if it evaluates to a true value, the expressions are
evaluated in order. The result of the when expression is unspecified.
@@ -1604,9 +1604,9 @@ evaluated in order. The result of the when expression is unspecified.
@end example
-syntax: (unless <test> <expression1> <expression2> @dots{})
+syntax: (unless @svar{test} @svar{expression1} @svar{expression2} @dots{})
-Syntax: The <test> is an expression.
+Syntax: The @svar{test} is an expression.
Semantics: The test is evaluated, and if it evaluates to #f, the expressions are evaluated in
order. The result of the unless expression is unspecified.
@@ -1620,16 +1620,16 @@ order. The result of the unless expression is unspecified.
@end example
-syntax: (cond-expand <ce-clause1> <ce-clause2> @dots{})
+syntax: (cond-expand @svar{ce-clause1} @svar{ce-clause2} @dots{})
Syntax: The cond-expand expression type provides a way to statically expand different
-expressions depending on the implementation. A <ce-clause> takes the following form:
+expressions depending on the implementation. A @svar{ce-clause} takes the following form:
-(<feature requirement> <expression> @dots{})
+(<feature requirement> @svar{expression} @dots{})
The last clause can be an ``else clause,'' which has the form
-(else <expression> @dots{})
+(else @svar{expression} @dots{})
A <feature requirement> takes one of the following forms:
@@ -1659,10 +1659,10 @@ then evaluating the resulting expression as a Scheme boolean expression under th
normal interpretation of and, or, and not.
A cond-expand is then expanded by evaluating the <feature requirement>s of successive
-<ce-clause>s in order until one of them returns #t. When a true clause is found, the
-corresponding <expression>s are expanded to a begin, and the remaining clauses are
+@svar{ce-clause}s in order until one of them returns #t. When a true clause is found, the
+corresponding @svar{expression}s are expanded to a begin, and the remaining clauses are
ignored. If none of the <feature requirement>s evaluate to #t, then if there is an else
-clause, its <expression>s are included. Otherwise, the behavior of the cond-expand is
+clause, its @svar{expression}s are included. Otherwise, the behavior of the cond-expand is
unspecified. Unlike cond, cond-expand does not depend on the value of any variables.
The exact features provided are implementation-defined, but for portability a core set of
@@ -1681,19 +1681,19 @@ computed, thus allowing mutually recursive definitions. The let-values and let*-
constructs are analogous to let and let* respectively, but are designed to handle
multiple-valued expressions, binding different identifiers to the returned values.
-syntax: (let <bindings> <body>)
+syntax: (let @svar{bindings} @svar{body})
-Syntax: <Bindings> has the form
+Syntax: @svar{Bindings} has the form
-((<variable1> <init1>) @dots{}),where each <init> is an expression, and <body> is a sequence of
+((@svar{variable1} @svar{init1}) @dots{}),where each @svar{init} is an expression, and @svar{body} is a sequence of
zero or more definitions followed by a sequence of one or more expressions as described
-in section 4.1.4. It is an error for a <variable> to appear more than once in the list of
+in section 4.1.4. It is an error for a @svar{variable} to appear more than once in the list of
variables being bound.
-Semantics: The <init>s are evaluated in the current environment (in some unspecified
-order), the <variable>s are bound to fresh locations holding the results, the <body> is
-evaluated in the extended environment, and the values of the last expression of <body>
-are returned. Each binding of a <variable> has <body> as its region.
+Semantics: The @svar{init}s are evaluated in the current environment (in some unspecified
+order), the @svar{variable}s are bound to fresh locations holding the results, the @svar{body} is
+evaluated in the extended environment, and the values of the last expression of @svar{body}
+are returned. Each binding of a @svar{variable} has @svar{body} as its region.
@example
@@ -1707,17 +1707,17 @@ are returned. Each binding of a <variable> has <body> as its region.
@end example
-syntax: (let* <bindings> <body>)
+syntax: (let* @svar{bindings} @svar{body})
-Syntax: <Bindings> has the form
+Syntax: @svar{Bindings} has the form
-((<variable1> <init1>) @dots{}),and <body> is a sequence of zero or more definitions followed by
+((@svar{variable1} @svar{init1}) @dots{}),and @svar{body} is a sequence of zero or more definitions followed by
one or more expressions as described in section 4.1.4.
Semantics: The let* binding construct is similar to let, but the bindings are performed
-sequentially from left to right, and the regionof a binding indicated by (<variable> <init>)
+sequentially from left to right, and the regionof a binding indicated by (@svar{variable} @svar{init})
is that part of the let* expression to the right of the binding. Thus the second binding is
-done in an environment in which the first binding is visible, and so on. The <variable>s
+done in an environment in which the first binding is visible, and so on. The @svar{variable}s
need not be distinct.
@example
@@ -1729,19 +1729,19 @@ need not be distinct.
@end example
-syntax: (letrec <bindings> <body>)
+syntax: (letrec @svar{bindings} @svar{body})
-Syntax: <Bindings> has the form
+Syntax: @svar{Bindings} has the form
-((<variable1> <init1>) @dots{}),and <body> is a sequence of zero or more definitions followed by
-one or more expressions as described in section 4.1.4. It is an error for a <variable> to
+((@svar{variable1} @svar{init1}) @dots{}),and @svar{body} is a sequence of zero or more definitions followed by
+one or more expressions as described in section 4.1.4. It is an error for a @svar{variable} to
appear more than once in the list of variables being bound.
-Semantics: The <variable>s are bound to fresh locations holding unspecified values, the
-<init>s are evaluated in the resulting environment (in some unspecified order), each
-<variable> is assigned to the result of the corresponding <init>, the <body> is evaluated in
-the resulting environment, and the values of the last expression in <body> are returned.
-Each binding of a <variable> has the entire letrec expression as its region, making it
+Semantics: The @svar{variable}s are bound to fresh locations holding unspecified values, the
+@svar{init}s are evaluated in the resulting environment (in some unspecified order), each
+@svar{variable} is assigned to the result of the corresponding @svar{init}, the @svar{body} is evaluated in
+the resulting environment, and the values of the last expression in @svar{body} are returned.
+Each binding of a @svar{variable} has the entire letrec expression as its region, making it
possible to define mutually recursive procedures.
@example
@@ -1761,31 +1761,31 @@ possible to define mutually recursive procedures.
@end example
-One restriction on letrec is very important: if it is not possible to evaluate each <init>
-without assigning or referring to the value of any <variable>, it is an error. The restriction
+One restriction on letrec is very important: if it is not possible to evaluate each @svar{init}
+without assigning or referring to the value of any @svar{variable}, it is an error. The restriction
is necessary because letrec is defined in terms of a procedure call where a lambda
-expression binds the <variable>s to the values of the <init>s. In the most common uses of
-letrec, all the <init>s are lambda expressions and the restriction is satisfied automatically.
+expression binds the @svar{variable}s to the values of the @svar{init}s. In the most common uses of
+letrec, all the @svar{init}s are lambda expressions and the restriction is satisfied automatically.
-syntax: (letrec* <bindings> <body>)
+syntax: (letrec* @svar{bindings} @svar{body})
-Syntax: <Bindings> has the form
+Syntax: @svar{Bindings} has the form
-((<variable1> <init1>) @dots{}),and <body>is a sequence of zero or more definitions followed by
-one or more expressions as described in section 4.1.4. It is an error for a <variable> to
+((@svar{variable1} @svar{init1}) @dots{}),and @svar{body}is a sequence of zero or more definitions followed by
+one or more expressions as described in section 4.1.4. It is an error for a @svar{variable} to
appear more than once in the list of variables being bound.
-Semantics: The <variable>s are bound to fresh locations, each <variable> is assigned in
-left-to-right order to the result of evaluating the corresponding <init> (interleaving
-evaluations and assignments), the <body> is evaluated in the resulting environment, and
-the values of the last expression in <body> are returned. Despite the left-to-right
-evaluation and assignment order, each binding of a <variable> has the entire letrec*
+Semantics: The @svar{variable}s are bound to fresh locations, each @svar{variable} is assigned in
+left-to-right order to the result of evaluating the corresponding @svar{init} (interleaving
+evaluations and assignments), the @svar{body} is evaluated in the resulting environment, and
+the values of the last expression in @svar{body} are returned. Despite the left-to-right
+evaluation and assignment order, each binding of a @svar{variable} has the entire letrec*
expression as its region, making it possible to define mutually recursive procedures.
-If it is not possible to evaluate each <init> without assigning or referring to the value of
-the corresponding <variable> or the <variable> of any of the bindings that follow it in
-<bindings>, it is an error. Another restriction is that it is an error to invoke the
-continuation of an <init> more than once.
+If it is not possible to evaluate each @svar{init} without assigning or referring to the value of
+the corresponding @svar{variable} or the @svar{variable} of any of the bindings that follow it in
+@svar{bindings}, it is an error. Another restriction is that it is an error to invoke the
+continuation of an @svar{init} more than once.
@example
@@ -1814,24 +1814,24 @@ continuation of an <init> more than once.
Evaluating (means '(3 (1 4))) returns three values: 8/3, 2.28942848510666 (approximately),
and 36/19.
-syntax: (let-values <mv binding spec> <body>)
+syntax: (let-values <mv binding spec> @svar{body})
Syntax: <Mv binding spec> has the form
-((<formals1> <init1>) @dots{}), where each <init> is an expression, and <body> is zero or more
+((@svar{formals1} @svar{init1}) @dots{}), where each @svar{init} is an expression, and @svar{body} is zero or more
definitions followed by a sequence of one or more expressions as described in section
-4.1.4. It is an error for a variable to appear more than once in the set of <formals>.
+4.1.4. It is an error for a variable to appear more than once in the set of @svar{formals}.
-Semantics: The <init>s are evaluated in the current environment (in some unspecified
-order) as if by invoking call-with-values, and the variables occurring in the <formals> are
-bound to fresh locations holding the values returned by the <init>s, where the <formals>
-are matched to the return values in the same way that the <formals> in a lambda
-expression are matched to the arguments in a procedure call. Then, the <body> is
-evaluated in the extended environment, and the values of the last expression of <body>
-are returned. Each binding of a <variable> has <body> as its region.
+Semantics: The @svar{init}s are evaluated in the current environment (in some unspecified
+order) as if by invoking call-with-values, and the variables occurring in the @svar{formals} are
+bound to fresh locations holding the values returned by the @svar{init}s, where the @svar{formals}
+are matched to the return values in the same way that the @svar{formals} in a lambda
+expression are matched to the arguments in a procedure call. Then, the @svar{body} is
+evaluated in the extended environment, and the values of the last expression of @svar{body}
+are returned. Each binding of a @svar{variable} has @svar{body} as its region.
-It is an error if the <formals> do not match the number of values returned by the
-corresponding <init>.
+It is an error if the @svar{formals} do not match the number of values returned by the
+corresponding @svar{init}.
@example
@@ -1840,17 +1840,17 @@ corresponding <init>.
@end example
-syntax: (let*-values <mv binding spec> <body>)
+syntax: (let*-values <mv binding spec> @svar{body})
Syntax: <Mv binding spec> has the form
-((<formals> <init>) @dots{}),and <body> is a sequence of zero or more definitions followed by
-one or more expressions as described in section 4.1.4. In each <formals>, it is an error if
+((@svar{formals} @svar{init}) @dots{}),and @svar{body} is a sequence of zero or more definitions followed by
+one or more expressions as described in section 4.1.4. In each @svar{formals}, it is an error if
any variable appears more than once.
-Semantics: The let*-values construct is similar to let-values, but the <init>s are evaluated
+Semantics: The let*-values construct is similar to let-values, but the @svar{init}s are evaluated
and bindings created sequentially from left to right, with the region of the bindings of
-each <formals> including the <init>s to its right as well as <body>. Thus the second <init>
+each @svar{formals} including the @svar{init}s to its right as well as @svar{body}. Thus the second @svar{init}
is evaluated in an environment in which the first set of bindings is visible and initialized,
and so on.
@@ -1871,8 +1871,8 @@ different forms and uses:
syntax: (begin <expression or definition> @dots{})
-This form of begin can appear as part of a <body>, or at the outermost level of a
-<program>, or at the REPL, or directly nested in a begin that is itself of this form. It causes
+This form of begin can appear as part of a @svar{body}, or at the outermost level of a
+@svar{program}, or at the REPL, or directly nested in a begin that is itself of this form. It causes
the contained expressions and definitions to be evaluated exactly as if the enclosing begin
construct were not present.
@@ -1880,10 +1880,10 @@ Rationale: This form is commonly used in the output of macros (see section 4.3)
need to generate multiple definitions and splice them into the context in which they
are expanded.
-syntax: (begin <expression1> <expression2> @dots{})
+syntax: (begin @svar{expression1} @svar{expression2} @dots{})
-This form of begin can be used as an ordinary expression. The <expression>s are
-evaluated sequentially from left to right, and the values of the last <expression> are
+This form of begin can be used as an ordinary expression. The @svar{expression}s are
+evaluated sequentially from left to right, and the values of the last @svar{expression} are
returned. This expression type is used to sequence side effects such as assignments or
input and output.
@@ -1905,39 +1905,39 @@ Note that there is a third form of begin used as a library declaration: see sect
@node Iteration
@subsection Iteration
-syntax: (do ((<variable1> <init1> <step1>)
+syntax: (do ((@svar{variable1} @svar{init1} @svar{step1})
@dots{})
-(<test> <expression> @dots{})
-<command> @dots{})
+(@svar{test} @svar{expression} @dots{})
+@svar{command} @dots{})
-Syntax: All of <init>, <step>, <test>, and <command> are expressions.
+Syntax: All of @svar{init}, @svar{step}, @svar{test}, and @svar{command} are expressions.
Semantics: A do expression is an iteration construct. It specifies a set of variables to be
bound, how they are to be initialized at the start, and how they are to be updated on each
iteration. When a termination condition is met, the loop exits after evaluating the
-<expression>s.
+@svar{expression}s.
-A do expression is evaluated as follows: The <init> expressions are evaluated (in some
-unspecified order), the <variable>s are bound to fresh locations, the results of the <init>
-expressions are stored in the bindings of the <variable>s, and then the iteration phase
+A do expression is evaluated as follows: The @svar{init} expressions are evaluated (in some
+unspecified order), the @svar{variable}s are bound to fresh locations, the results of the @svar{init}
+expressions are stored in the bindings of the @svar{variable}s, and then the iteration phase
begins.
-Each iteration begins by evaluating <test>; if the result is false (see section 6.3), then the
-<command> expressions are evaluated in order for effect, the <step> expressions are
-evaluated in some unspecified order, the <variable>s are bound to fresh locations, the
-results of the <step>s are stored in the bindings of the <variable>s, and the next iteration
+Each iteration begins by evaluating @svar{test}; if the result is false (see section 6.3), then the
+@svar{command} expressions are evaluated in order for effect, the @svar{step} expressions are
+evaluated in some unspecified order, the @svar{variable}s are bound to fresh locations, the
+results of the @svar{step}s are stored in the bindings of the @svar{variable}s, and the next iteration
begins.
-If <test> evaluates to a true value, then the <expression>s are evaluated from left to right
-and the values of the last <expression> are returned. If no <expression>s are present,
+If @svar{test} evaluates to a true value, then the @svar{expression}s are evaluated from left to right
+and the values of the last @svar{expression} are returned. If no @svar{expression}s are present,
then the value of the do expression is unspecified.
-The regionof the binding of a <variable> consists of the entire do expression except for
-the <init>s. It is an error for a <variable> to appear more than once in the list of do
+The regionof the binding of a @svar{variable} consists of the entire do expression except for
+the @svar{init}s. It is an error for a @svar{variable} to appear more than once in the list of do
variables.
-A <step> can be omitted, in which case the effect is the same as if (<variable> <init>
-<variable>) had been written instead of (<variable> <init>).
+A @svar{step} can be omitted, in which case the effect is the same as if (@svar{variable} @svar{init}
+@svar{variable}) had been written instead of (@svar{variable} @svar{init}).
@example
@@ -1953,14 +1953,14 @@ A <step> can be omitted, in which case the effect is the same as if (<variable>
@end example
-syntax: (let <variable> <bindings> <body>)
+syntax: (let @svar{variable} @svar{bindings} @svar{body})
Semantics: ``Named let'' is a variant on the syntax of let which provides a more general
looping construct than do and can also be used to express recursion. It has the same
-syntax and semantics as ordinary let except that <variable> is bound within <body> to a
-procedure whose formal arguments are the bound variables and whose body is <body>.
-Thus the execution of <body> can be repeated by invoking the procedure named by
-<variable>.
+syntax and semantics as ordinary let except that @svar{variable} is bound within @svar{body} to a
+procedure whose formal arguments are the bound variables and whose body is @svar{body}.
+Thus the execution of @svar{body} can be repeated by invoking the procedure named by
+@svar{variable}.
@example
@@ -1983,15 +1983,15 @@ Thus the execution of <body> can be repeated by invoking the procedure named by
@node Delayed evaluation
@subsection Delayed evaluation
-lazy library syntax: (delay <expression>)
+lazy library syntax: (delay @svar{expression})
Semantics: The delay construct is used together with the procedure force to implement
-lazy evaluation or call by need. (delay <expression>) returns an object called a promise which
+lazy evaluation or call by need. (delay @svar{expression}) returns an object called a promise which
at some point in the future can be asked (by the force procedure) to evaluate
-<expression>, and deliver the resulting value. The effect of <expression> returning
+@svar{expression}, and deliver the resulting value. The effect of @svar{expression} returning
multiple values is unspecified.
-lazy library syntax: (delay-force <expression>)
+lazy library syntax: (delay-force @svar{expression})
Semantics: The expression (delay-force
@@ -2150,22 +2150,22 @@ parameterize, which is described below.
The effect of passing arguments to a parameter object is implementation-dependent.
@end deffn
-syntax: (parameterize ((<param1> <value1>) @dots{})
- <body>)
+syntax: (parameterize ((@svar{param1} @svar{value1}) @dots{})
+ @svar{body})
-Syntax: Both <param1> and <value1> are expressions.
+Syntax: Both @svar{param1} and @svar{value1} are expressions.
-It is an error if the value of any <param> expression is not a parameter object.
+It is an error if the value of any @svar{param} expression is not a parameter object.
Semantics: A parameterize expression is used to change the values returned by specified
parameter objects during the evaluation of the body.
-The <param> and <value> expressions are evaluated in an unspecified order. The <body>
+The @svar{param} and @svar{value} expressions are evaluated in an unspecified order. The @svar{body}
is evaluated in a dynamic environment in which calls to the parameters return the results
of passing the corresponding values to the conversion procedure specified when the
parameters were created. Then the previous values of the parameters are restored
without passing them to the conversion procedure. The results of the last expression in
-the <body> are returned as the results of the entire parameterize expression.
+the @svar{body} are returned as the results of the entire parameterize expression.
Note: If the conversion procedure is not idempotent, the results of (parameterize ((x
(x))) ...), which appears to bind the parameter
@@ -2174,7 +2174,7 @@ x to its current value, might not be what the user expects.
If an implementation supports multiple threads of execution, then parameterize must not
change the associated values of any parameters in any thread other than the current
-thread and threads created inside <body>.
+thread and threads created inside @svar{body}.
Parameter objects can be used to specify configurable settings for a computation
without the need to pass the value to every procedure in the call chain explicitly.
@@ -2206,17 +2206,17 @@ without the need to pass the value to every procedure in the call chain explicit
@node Exception handling
@subsection Exception handling
-syntax: (guard (<variable>
+syntax: (guard (@svar{variable}
<cond clause1> <cond clause2> @dots{})
- <body>)
+ @svar{body})
Syntax: Each <cond clause> is as in the specification of cond.
-Semantics: The <body> is evaluated with an exception handler that binds the raised object
-(see raise in section 6.11) to <variable> and, within the scope of that binding, evaluates the
+Semantics: The @svar{body} is evaluated with an exception handler that binds the raised object
+(see raise in section 6.11) to @svar{variable} and, within the scope of that binding, evaluates the
clauses as if they were the clauses of a cond expression. That implicit cond expression is
evaluated with the continuation and dynamic environment of the guard expression. If
-every <cond clause>'s <test> evaluates to #f and there is no else clause, then
+every <cond clause>'s @svar{test} evaluates to #f and there is no else clause, then
raise-continuable is invoked on the raised object within the dynamic environment of the
original call to raise or raise-continuable, except that the current exception handler is that
of the guard expression.
@@ -2323,8 +2323,8 @@ However, it is not equivalent to this expression:
@end example
The two notations `<qq template> and (quasiquote <qq
-template>) are identical in all respects. ,<expression> is identical to (unquote
-<expression>), and ,@@<expression> is identical to (unquote-splicing <expression>). The
+template>) are identical in all respects. ,@svar{expression} is identical to (unquote
+@svar{expression}), and ,@@@svar{expression} is identical to (unquote-splicing @svar{expression}). The
write procedure may output either format.
@example
@@ -2343,21 +2343,21 @@ positions within a <qq template> otherwise than as described above.
@node Case-lambda
@subsection Case-lambda
-case-lambda library syntax: (case-lambda <clause> @dots{})
+case-lambda library syntax: (case-lambda @svar{clause} @dots{})
-Syntax: Each <clause> is of the form (<formals> <body>), where <formals> and <body>
+Syntax: Each @svar{clause} is of the form (@svar{formals} @svar{body}), where @svar{formals} and @svar{body}
have the same syntax as in a lambda expression.
Semantics: A case-lambda expression evaluates to a procedure that accepts a variable
number of arguments and is lexically scoped in the same manner as a procedure resulting
-from a lambda expression. When the procedure is called, the first <clause> for which the
-arguments agree with <formals> is selected, where agreement is specified as for the
-<formals> of a lambda expression. The variables of <formals> are bound to fresh
-locations, the values of the arguments are stored in those locations, the <body> is
-evaluated in the extended environment, and the results of <body> are returned as the
+from a lambda expression. When the procedure is called, the first @svar{clause} for which the
+arguments agree with @svar{formals} is selected, where agreement is specified as for the
+@svar{formals} of a lambda expression. The variables of @svar{formals} are bound to fresh
+locations, the values of the arguments are stored in those locations, the @svar{body} is
+evaluated in the extended environment, and the results of @svar{body} are returned as the
results of the procedure call.
-It is an error for the arguments not to agree with the <formals> of any <clause>.
+It is an error for the arguments not to agree with the @svar{formals} of any @svar{clause}.
@example
@@ -2379,9 +2379,9 @@ It is an error for the arguments not to agree with the <formals> of any <clause>
Scheme programs can define and use new derived expression types, called
macros.Program-defined expression types have the syntax
-(<keyword> <datum> ...)where <keyword> is an identifier that uniquely determines the
+(@svar{keyword} @svar{datum} ...)where @svar{keyword} is an identifier that uniquely determines the
expression type. This identifier is called the syntactic keyword, or simply keyword, of the
-macro. The number of the <datum>s, and their syntax, depends on the expression type.
+macro. The number of the @svar{datum}s, and their syntax, depends on the expression type.
Each instance of a macro is called a useof the macro. The set of rules that specifies how a
use of a macro is transcribed into a more primitive expression is called the transformerof
@@ -2427,19 +2427,19 @@ they bind syntactic keywords to macro transformers instead of binding variables
locations that contain values. Syntactic keywords can also be bound globally or locally
with define-syntax; see section 5.4.
-syntax: (let-syntax <bindings> <body>)
+syntax: (let-syntax @svar{bindings} @svar{body})
-Syntax: <Bindings> has the form
+Syntax: @svar{Bindings} has the form
-((<keyword> <transformer spec>) @dots{})Each <keyword> is an identifier, each <transformer
-spec> is an instance of syntax-rules, and <body> is a sequence of zero or more
-definitions followed by one or more expressions. It is an error for a <keyword> to
+((@svar{keyword} <transformer spec>) @dots{})Each @svar{keyword} is an identifier, each <transformer
+spec> is an instance of syntax-rules, and @svar{body} is a sequence of zero or more
+definitions followed by one or more expressions. It is an error for a @svar{keyword} to
appear more than once in the list of keywords being bound.
-Semantics: The <body> is expanded in the syntactic environment obtained by extending
+Semantics: The @svar{body} is expanded in the syntactic environment obtained by extending
the syntactic environment of the let-syntax expression with macros whose keywords are
-the <keyword>s, bound to the specified transformers. Each binding of a <keyword> has
-<body> as its region.
+the @svar{keyword}s, bound to the specified transformers. Each binding of a @svar{keyword} has
+@svar{body} as its region.
@example
@@ -2459,14 +2459,14 @@ the <keyword>s, bound to the specified transformers. Each binding of a <keyword>
@end example
-syntax: (letrec-syntax <bindings> <body>)
+syntax: (letrec-syntax @svar{bindings} @svar{body})
Syntax: Same as for let-syntax.
-Semantics: The <body> is expanded in the syntactic environment obtained by extending
+Semantics: The @svar{body} is expanded in the syntactic environment obtained by extending
the syntactic environment of the letrec-syntax expression with macros whose keywords
-are the <keyword>s, bound to the specified transformers. Each binding of a <keyword>
-has the <transformer spec>s as well as the <body> within its region, so the transformers
+are the @svar{keyword}s, bound to the specified transformers. Each binding of a @svar{keyword}
+has the <transformer spec>s as well as the @svar{body} within its region, so the transformers
can transcribe expressions into uses of the macros introduced by the letrec-syntax
expression.
@@ -2500,31 +2500,31 @@ A <transformer spec> has one of the following forms:
syntax: (syntax-rules (<pattern literal> @dots{})
<syntax rule> @dots{})
-syntax: (syntax-rules <ellipsis> (<pattern literal> @dots{})
+syntax: (syntax-rules @svar{ellipsis} (<pattern literal> @dots{})
<syntax rule> @dots{})
auxiliary syntax: _
auxiliary syntax: @dots{}
-Syntax: It is an error if any of the <pattern literal>s, or the <ellipsis> in the second form, is
+Syntax: It is an error if any of the <pattern literal>s, or the @svar{ellipsis} in the second form, is
not an identifier. It is also an error if <syntax rule> is not of the form
-(<pattern> <template>)The <pattern> in a <syntax rule> is a list <pattern> whose first
+(@svar{pattern} @svar{template})The @svar{pattern} in a <syntax rule> is a list @svar{pattern} whose first
element is an identifier.
-A <pattern> is either an identifier, a constant, or one of the following
-
-(<pattern> @dots{})
-(<pattern> <pattern> @dots{} . <pattern>)
-(<pattern> @dots{} <pattern> <ellipsis> <pattern> @dots{})
-(<pattern> @dots{} <pattern> <ellipsis> <pattern> @dots{}
- . <pattern>)
-#(<pattern> @dots{})
-#(<pattern> @dots{} <pattern> <ellipsis> <pattern> @dots{})and a <template> is either an identifier, a
-constant, or one of the following (<element> @dots{})
-(<element> <element> @dots{} . <template>)
-(<ellipsis> <template>)
-#(<element> @dots{})where an <element> is a <template> optionally followed by an <ellipsis>.
-An <ellipsis> is the identifier specified in the second form of syntax-rules, or the default
+A @svar{pattern} is either an identifier, a constant, or one of the following
+
+(@svar{pattern} @dots{})
+(@svar{pattern} @svar{pattern} @dots{} . @svar{pattern})
+(@svar{pattern} @dots{} @svar{pattern} @svar{ellipsis} @svar{pattern} @dots{})
+(@svar{pattern} @dots{} @svar{pattern} @svar{ellipsis} @svar{pattern} @dots{}
+ . @svar{pattern})
+#(@svar{pattern} @dots{})
+#(@svar{pattern} @dots{} @svar{pattern} @svar{ellipsis} @svar{pattern} @dots{})and a @svar{template} is either an identifier, a
+constant, or one of the following (@svar{element} @dots{})
+(@svar{element} @svar{element} @dots{} . @svar{template})
+(@svar{ellipsis} @svar{template})
+#(@svar{element} @dots{})where an @svar{element} is a @svar{template} optionally followed by an @svar{ellipsis}.
+An @svar{ellipsis} is the identifier specified in the second form of syntax-rules, or the default
identifier ... (three consecutive periods) otherwise.
Semantics: An instance of syntax-rules produces a new macro transformer by specifying a
@@ -2533,21 +2533,21 @@ transformer specified by syntax-rules is matched against the patterns contained
<syntax rule>s, beginning with the leftmost <syntax rule>. When a match is found, the
macro use is transcribed hygienically according to the template.
-An identifier appearing within a <pattern> can be an underscore (_), a literal identifier
-listed in the list of <pattern literal>s, or the <ellipsis>. All other identifiers appearing
-within a <pattern> are pattern variables.
+An identifier appearing within a @svar{pattern} can be an underscore (_), a literal identifier
+listed in the list of <pattern literal>s, or the @svar{ellipsis}. All other identifiers appearing
+within a @svar{pattern} are pattern variables.
The keyword at the beginning of the pattern in a <syntax rule> is not involved in the
matching and is considered neither a pattern variable nor a literal identifier.
Pattern variables match arbitrary input elements and are used to refer to elements of
the input in the template. It is an error for the same pattern variable to appear more
-than once in a <pattern>.
+than once in a @svar{pattern}.
Underscores also match arbitrary input elements but are not pattern variables and so
cannot be used to refer to those elements. If an underscore appears in the <pattern
-literal>s list, then that takes precedence and underscores in the <pattern> match as
-literals. Multiple underscores can appear in a <pattern>.
+literal>s list, then that takes precedence and underscores in the @svar{pattern} match as
+literals. Multiple underscores can appear in a @svar{pattern}.
Identifiers that appear in (<pattern literal> @dots{}) are interpreted as literal identifiers to be
matched against corresponding elements of the input. An element in the input matches
@@ -2555,8 +2555,8 @@ a literal identifier if and only if it is an identifier and either both its occu
macro expression and its occurrence in the macro definition have the same lexical
binding, or the two identifiers are the same and both have no lexical binding.
-A subpattern followed by <ellipsis> can match zero or more elements of the input,
-unless <ellipsis> appears in the <pattern literal>s, in which case it is matched as a literal.
+A subpattern followed by @svar{ellipsis} can match zero or more elements of the input,
+unless @svar{ellipsis} appears in the <pattern literal>s, in which case it is matched as a literal.
More formally, an input expression E matches a pattern P if and only if:
@@ -2572,11 +2572,11 @@ More formally, an input expression E matches a pattern P if and only if:
* P is an improper list (P1P2 @dots{} Pn . Pn+1) and E is a list or improper list of n or more
elements that match P1 through Pn, respectively, and whose nth tail matches Pn+1; or
-* P is of the form (P1 @dots{} PkPe <ellipsis> Pm+1 @dots{} Pn) where E is a proper list of n elements,
+* P is of the form (P1 @dots{} PkPe @svar{ellipsis} Pm+1 @dots{} Pn) where E is a proper list of n elements,
the first k of which match P1 through Pk, respectively, whose next m−k elements each
match Pe, whose remaining n−m elements match Pm+1 through Pn; or
-* P is of the form (P1 @dots{} PkPe <ellipsis> Pm+1 @dots{} Pn . Px) where E is a list or improper list of n
+* P is of the form (P1 @dots{} PkPe @svar{ellipsis} Pm+1 @dots{} Pn . Px) where E is a list or improper list of n
elements, the first k of which match P1 through Pk, whose next m−k elements each
match Pe, whose remaining n−m elements match Pm+1 through Pn, and whose nth and
final cdr matches Px; or
@@ -2584,7 +2584,7 @@ More formally, an input expression E matches a pattern P if and only if:
* P is a vector of the form #(P1 @dots{} Pn) and E is a vector of n elements that match P1
through Pn; or
-* P is of the form #(P1 @dots{} PkPe <ellipsis> Pm+1 @dots{}Pn) where E is a vector of n elements the
+* P is of the form #(P1 @dots{} PkPe @svar{ellipsis} Pm+1 @dots{}Pn) where E is a vector of n elements the
first k of which match P1 through Pk, whose next m−k elements each match Pe, and
whose remaining n−m elements match Pm+1 through Pn; or
@@ -2596,21 +2596,21 @@ that does not match any of the patterns.
When a macro use is transcribed according to the template of the matching <syntax
rule>, pattern variables that occur in the template are replaced by the elements they
match in the input. Pattern variables that occur in subpatterns followed by one or more
-instances of the identifier <ellipsis> are allowed only in subtemplates that are followed
-by as many instances of <ellipsis>. They are replaced in the output by all of the elements
+instances of the identifier @svar{ellipsis} are allowed only in subtemplates that are followed
+by as many instances of @svar{ellipsis}. They are replaced in the output by all of the elements
they match in the input, distributed as indicated. It is an error if the output cannot be
built up as specified.
Identifiers that appear in the template but are not pattern variables or the identifier
-<ellipsis> are inserted into the output as literal identifiers. If a literal identifier is inserted
+@svar{ellipsis} are inserted into the output as literal identifiers. If a literal identifier is inserted
as a free identifier then it refers to the binding of that identifier within whose scope the
instance of syntax-rules appears. If a literal identifier is inserted as a bound identifier
then it is in effect renamed to prevent inadvertent captures of free identifiers.
-A template of the form (<ellipsis> <template>) is identical to <template>, except that
+A template of the form (@svar{ellipsis} @svar{template}) is identical to @svar{template}, except that
ellipses within the template have no special meaning. That is, any ellipses contained
-within <template> are treated as ordinary identifiers. In particular, the template
-(<ellipsis> <ellipsis>) produces a single <ellipsis>. This allows syntactic abstractions to
+within @svar{template} are treated as ordinary identifiers. In particular, the template
+(@svar{ellipsis} @svar{ellipsis}) produces a single @svar{ellipsis}. This allows syntactic abstractions to
expand into code containing ellipses.
@example
@@ -2665,13 +2665,13 @@ which would result in an invalid procedure call.
@node Signaling errors in macro transformers
@subsection Signaling errors in macro transformers
-syntax: (syntax-error <message> <args> @dots{})
+syntax: (syntax-error @svar{message} @svar{args} @dots{})
syntax-error behaves similarly to error (6.11) except that implementations with an
expansion pass separate from evaluation should signal an error as soon as syntax-error
-is expanded. This can be used as a syntax-rules <template> for a <pattern> that is an
+is expanded. This can be used as a syntax-rules @svar{template} for a @svar{pattern} that is an
invalid use of the macro, which can provide more descriptive error messages.
-<message> is a string literal, and <args> arbitrary expressions providing additional
+@svar{message} is a string literal, and @svar{args} arbitrary expressions providing additional
information. Applications cannot count on being able to catch syntax errors with
exception handlers or guards.
@@ -2712,12 +2712,12 @@ program or library depends; a subset of the identifiers exported by the librarie
available to the program. Expressions are described in chapter 4. Definitions are either
variable definitions, syntax definitions, or record-type definitions, all of which are
explained in this chapter. They are valid in some, but not all, contexts where expressions
-are allowed, specifically at the outermost level of a <program> and at the beginning of a
-<body>.
+are allowed, specifically at the outermost level of a @svar{program} and at the beginning of a
+@svar{body}.
At the outermost level of a program, (begin <expression or definition1> @dots{}) is equivalent to
-the sequence of expressions and definitions in the begin. Similarly, in a <body>, (begin
-<definition1> @dots{}) is equivalent to the sequence <definition1> @dots{}. Macros can expand into
+the sequence of expressions and definitions in the begin. Similarly, in a @svar{body}, (begin
+@svar{definition1} @dots{}) is equivalent to the sequence @svar{definition1} @dots{}. Macros can expand into
such begin forms. For the formal definition, see 4.2.3.
Import declarations and definitions cause bindings to be created in the global
@@ -2739,21 +2739,21 @@ from the name of a library to its location in the file system.
An import declaration takes the following form:
-(import <import-set> @dots{})
+(import @svar{import-set} @dots{})
An import declaration provides a way to import identifiers exported by a library. Each
<import set> names a set of bindings from a library and possibly specifies local names for
the imported bindings. It takes one of the following forms:
* <library name>
-* (only <import set> <identifier> @dots{})
+* (only <import set> @svar{identifier} @dots{})
-* (except <import set> <identifier> @dots{})
+* (except <import set> @svar{identifier} @dots{})
-* (prefix <import set> <identifier>)
+* (prefix <import set> @svar{identifier})
* (rename <import set>
- (<identifier1> <identifier2>) @dots{})
+ (@svar{identifier1} @svar{identifier2}) @dots{})
In the first form, all of the identifiers in the named library's export clauses are imported
with the same names (or the exported names if exported with rename). The additional
@@ -2767,12 +2767,12 @@ with the same names (or the exported names if exported with rename). The additio
(after any renaming). It is an error if any of the listed identifiers are not found in the
original set.
-* rename modifies the given <import set>, replacing each instance of <identifier1> with
- <identifier2>. It is an error if any of the listed <identifier1>s are not found in the original
+* rename modifies the given <import set>, replacing each instance of @svar{identifier1} with
+ @svar{identifier2}. It is an error if any of the listed @svar{identifier1}s are not found in the original
set.
* prefix automatically renames all identifiers in the given <import set>, prefixing each
- with the specified <identifier>.
+ with the specified @svar{identifier}.
In a program or library declaration, it is an error to import the same identifier more than
once with different bindings, or to redefine or mutate an imported binding with a
@@ -2785,30 +2785,30 @@ should permit these actions.
A variable definition binds one or more identifiers and specifies an initial value for each of
them. The simplest kind of variable definition takes one of the following forms:
-* (define <variable> <expression>)
+* (define @svar{variable} @svar{expression})
-* (define (<variable> <formals>) <body>)
+* (define (@svar{variable} @svar{formals}) @svar{body})
- <Formals> are either a sequence of zero or more variables, or a sequence of one or
+ @svar{Formals} are either a sequence of zero or more variables, or a sequence of one or
more variables followed by a space-delimited period and another variable (as in a
lambda expression). This form is equivalent to
@example
-(define <variable>
- (lambda (<formals>) <body>)).
+(define @svar{variable}
+ (lambda (@svar{formals}) @svar{body})).
@end example
-* (define (<variable> . <formal>) <body>)
+* (define (@svar{variable} . @svar{formal}) @svar{body})
- <Formal> is a single variable. This form is equivalent to
+ @svar{Formal} is a single variable. This form is equivalent to
@example
-(define <variable>
- (lambda <formal> <body>)).
+(define @svar{variable}
+ (lambda @svar{formal} @svar{body})).
@end example
@@ -2823,10 +2823,10 @@ them. The simplest kind of variable definition takes one of the following forms:
At the outermost level of a program, a definition
-(define <variable> <expression>)has essentially the same effect as the assignment
-expression (set! <variable> <expression>)if <variable> is bound to a non-syntax value.
-However, if <variable> is not bound, or is a syntactic keyword, then the definition will bind
-<variable> to a new location before performing the assignment, whereas it would be an
+(define @svar{variable} @svar{expression})has essentially the same effect as the assignment
+expression (set! @svar{variable} @svar{expression})if @svar{variable} is bound to a non-syntax value.
+However, if @svar{variable} is not bound, or is a syntactic keyword, then the definition will bind
+@svar{variable} to a new location before performing the assignment, whereas it would be an
error to perform a set! on an unboundvariable.
@example
@@ -2842,13 +2842,13 @@ error to perform a set! on an unboundvariable.
@node Internal definitions
@subsection Internal definitions
-Definitions can occur at the beginning of a <body> (that is, the body of a lambda, let, let*,
+Definitions can occur at the beginning of a @svar{body} (that is, the body of a lambda, let, let*,
letrec, letrec*, let-values, let*-values, let-syntax, letrec-syntax, parameterize, guard, or
case-lambda). Note that such a body might not be apparent until after expansion of other
syntax. Such definitions are known as internal definitionsas opposed to the global
definitions described above. The variables defined by internal definitions are local to the
-<body>. That is, <variable> is bound rather than assigned, and the region of the binding is
-the entire <body>. For example,
+@svar{body}. That is, @svar{variable} is bound rather than assigned, and the region of the binding is
+the entire @svar{body}. For example,
@example
@@ -2859,7 +2859,7 @@ the entire <body>. For example,
@end example
-An expanded <body> containing internal definitions can always
+An expanded @svar{body} containing internal definitions can always
be converted into a completely equivalent letrec* expression. For example, the let
expression in the above example is equivalent to
@@ -2873,13 +2873,13 @@ expression in the above example is equivalent to
@end example
Just as for the equivalent letrec* expression, it is an error if it is not
-possible to evaluate each <expression> of every internal definition in a <body> without
-assigning or referring to the value of the corresponding <variable> or the <variable> of
-any of the definitions that follow it in <body>.
+possible to evaluate each @svar{expression} of every internal definition in a @svar{body} without
+assigning or referring to the value of the corresponding @svar{variable} or the @svar{variable} of
+any of the definitions that follow it in @svar{body}.
-It is an error to define the same identifier more than once in the same <body>.
+It is an error to define the same identifier more than once in the same @svar{body}.
-Wherever an internal definition can occur, (begin <definition1> @dots{}) is equivalent to the
+Wherever an internal definition can occur, (begin @svar{definition1} @dots{}) is equivalent to the
sequence of definitions that form the body of the begin.
@node Multiple-value definitions
@@ -2889,12 +2889,12 @@ Another kind of definition is provided by define-values, which creates multiple
from a single expression returning multiple values. It is allowed wherever define is
allowed.
-syntax: (define-values <formals> <expression>)
+syntax: (define-values @svar{formals} @svar{expression})
-It is an error if a variable appears more than once in the set of <formals>.
+It is an error if a variable appears more than once in the set of @svar{formals}.
-Semantics: <Expression> is evaluated, and the <formals> are bound to the return values in
-the same way that the <formals> in a lambda expression are matched to the arguments in
+Semantics: @svar{Expression} is evaluated, and the @svar{formals} are bound to the return values in
+the same way that the @svar{formals} in a lambda expression are matched to the arguments in
a procedure call.
@example
@@ -2913,16 +2913,16 @@ a procedure call.
Syntax definitions have this form:
-(define-syntax <keyword> <transformer spec>)
+(define-syntax @svar{keyword} <transformer spec>)
-<Keyword> is an identifier, and the <transformer spec> is an instance of syntax-rules. Like
+@svar{Keyword} is an identifier, and the <transformer spec> is an instance of syntax-rules. Like
variable definitions, syntax definitions can appear at the outermost level or nested within
a body.
If the define-syntax occurs at the outermost level, then the global syntactic environment
-is extended by binding the <keyword> to the specified transformer, but previous
-expansions of any global binding for <keyword> remain unchanged. Otherwise, it is an
-internal syntax definition, and is local to the <body> in which it is defined. Any use of a
+is extended by binding the @svar{keyword} to the specified transformer, but previous
+expansions of any global binding for @svar{keyword} remain unchanged. Otherwise, it is an
+internal syntax definition, and is local to the @svar{body} in which it is defined. Any use of a
syntax keyword before its corresponding definition is an error. In particular, a use that
precedes an inner definition will not apply an outer definition.
@@ -2976,12 +2976,12 @@ record type are called records and are aggregations of zero or more fields, each
holds a single location. A predicate, a constructor, and field accessors and mutators are
defined for each record type.
-syntax: (define-record-type <name>
- <constructor> <pred> <field> @dots{})
+syntax: (define-record-type @svar{name}
+ @svar{constructor} @svar{pred} @svar{field} @dots{})
-Syntax: <name> and <pred> are identifiers. The <constructor> is of the form
+Syntax: @svar{name} and @svar{pred} are identifiers. The @svar{constructor} is of the form
-(<constructor name> <field name> @dots{})and each <field> is either of the form (<field name>
+(<constructor name> <field name> @dots{})and each @svar{field} is either of the form (<field name>
<accessor name>)or of the form (<field name> <accessor name> <modifier name>) It is an
error for the same identifier to occur more than once as a field name. It is also an error
for the same identifier to occur more than once as an accessor or mutator name.
@@ -2992,26 +2992,26 @@ types---even record types of the same name or structure.
An instance of define-record-type is equivalent to the following definitions:
-* <name> is bound to a representation of the record type itself. This may be a run-time
+* @svar{name} is bound to a representation of the record type itself. This may be a run-time
object or a purely syntactic representation. The representation is not utilized in this
report, but it serves as a means to identify the record type for use by further language
extensions.
* <constructor name> is bound to a procedure that takes as many arguments as there
are <field name>s in the (<constructor name> @dots{}) subexpression and returns a new
- record of type <name>. Fields whose names are listed with <constructor name> have
+ record of type @svar{name}. Fields whose names are listed with <constructor name> have
the corresponding argument as their initial value. The initial values of all other fields are
- unspecified. It is an error for a field name to appear in <constructor> but not as a <field
+ unspecified. It is an error for a field name to appear in @svar{constructor} but not as a <field
name>.
-* <pred> is bound to a predicate that returns #t when given a value returned by the
+* @svar{pred} is bound to a predicate that returns #t when given a value returned by the
procedure bound to <constructor name> and #f for everything else.
-* Each <accessor name> is bound to a procedure that takes a record of type <name> and
+* Each <accessor name> is bound to a procedure that takes a record of type @svar{name} and
returns the current value of the corresponding field. It is an error to pass an accessor a
value which is not a record of the appropriate type.
-* Each <modifier name> is bound to a procedure that takes a record of type <name> and
+* Each <modifier name> is bound to a procedure that takes a record of type @svar{name} and
a value which becomes the new value of the corresponding field; an unspecified value
is returned. It is an error to pass a modifier a first argument which is not a record of
the appropriate type.
@@ -3020,7 +3020,7 @@ For instance, the following record-type definition
@example
-(define-record-type <pare>
+(define-record-type @svar{pare}
(kons x y)
pare?
(x kar set-kar!)
@@ -3029,7 +3029,7 @@ For instance, the following record-type definition
@end example
defines kons to be a constructor, kar and kdr to be accessors, set-kar! to be a modifier,
-and pare? to be a predicate for instances of <pare>.
+and pare? to be a predicate for instances of @svar{pare}.
@example
@@ -3078,26 +3078,26 @@ A <library declaration> is any of:
* (begin <command or definition> @dots{})
-* (include <filename1> <filename2> @dots{})
+* (include @svar{filename1} @svar{filename2} @dots{})
-* (include-ci <filename1> <filename2> @dots{})
+* (include-ci @svar{filename1} @svar{filename2} @dots{})
-* (include-library-declarations <filename1> <filename2> @dots{})
+* (include-library-declarations @svar{filename1} @svar{filename2} @dots{})
-* (cond-expand <ce-clause1> <ce-clause2> @dots{})
+* (cond-expand @svar{ce-clause1} @svar{ce-clause2} @dots{})
An export declaration specifies a list of identifiers which can be made visible to other
libraries or programs. An <export spec> takes one of the following forms:
-* <identifier>
+* @svar{identifier}
-* (rename <identifier1> <identifier2>)
+* (rename @svar{identifier1} @svar{identifier2})
-In an <export spec>, an <identifier> names a single binding defined within or imported
+In an <export spec>, an @svar{identifier} names a single binding defined within or imported
into the library, where the external name for the export is the same as the name of the
binding within the library. A rename spec exports the binding defined within or imported
-into the library and named by <identifier1> in each (<identifier1> <identifier2>) pairing,
-using <identifier2> as the external name.
+into the library and named by @svar{identifier1} in each (@svar{identifier1} @svar{identifier2}) pairing,
+using @svar{identifier2} as the external name.
An import declaration provides a way to import the identifiers exported by another
library. It has the same syntax and semantics as an import declaration used in a program
@@ -4142,7 +4142,7 @@ nq +
nr. For each of the division operators, there are three procedures defined as follows:
-(<operator>/
+(@svar{operator}/
n1
@@ -4151,14 +4151,14 @@ n2) @result{}
nq
nr
-(<operator>-quotient
+(@svar{operator}-quotient
n1
n2) @result{}
nq
-(<operator>-remainder
+(@svar{operator}-remainder
n1
@@ -4205,12 +4205,12 @@ n2 not equal to 0,
n1 (+ (*
-n2 (<operator>-quotient
+n2 (@svar{operator}-quotient
n1
n2))
- (<operator>-remainder
+ (@svar{operator}-remainder
n1
@@ -4812,11 +4812,11 @@ y @result{} (a . 4)
(list? y) @result{} #f
(set-cdr! x x) @result{} unspecified
(list? x) @result{} #f Within literal expressions and representations of objects read by the
-read procedure, the forms '<datum>, `<datum>, ,<datum>, and ,@@<datum> denote
+read procedure, the forms '@svar{datum}, `@svar{datum}, ,@svar{datum}, and ,@@@svar{datum} denote
two-element lists whose first elements are the symbols quote, quasiquote, unquote, and
-unquote-splicing, respectively. The second element in each case is <datum>. This
+unquote-splicing, respectively. The second element in each case is @svar{datum}. This
convention is supported so that arbitrary Scheme programs can be represented as lists.
-That is, according to Scheme's grammar, every <expression> is also a <datum> (see
+That is, according to Scheme's grammar, every @svar{expression} is also a @svar{datum} (see
section 7.1.2). Among other things, this permits the use of the read procedure to parse
Scheme programs. See section 3.3.
@@ -5351,7 +5351,7 @@ Unicode characters they see fit, and may also support non-Unicode characters as
Except as otherwise specified, the result of applying any of the following procedures to a
non-Unicode character is implementation-dependent.
-Characters are written using the notation #\<character> or #\<character name> or
+Characters are written using the notation #\@svar{character} or #\<character name> or
#\x<hex scalar value>.
The following character names must be supported by all implementations with the given
@@ -5401,9 +5401,9 @@ Here are some additional examples:
are
supported)
-Case is significant in #\<character>, and in #\⟨character name⟩, but not in #\x<hex scalar
-value>. If <character> in #\<character> is alphabetic, then any character immediately
-following <character> cannot be one that can appear in an identifier. This rule resolves
+Case is significant in #\@svar{character}, and in #\⟨character name⟩, but not in #\x<hex scalar
+value>. If @svar{character} in #\@svar{character} is alphabetic, then any character immediately
+following @svar{character} cannot be one that can appear in an identifier. This rule resolves
the ambiguous case where, for example, the sequence of characters ``#\space'' could be
taken to be either a representation of the space character or a representation of the
character ``#\s'' followed by a representation of the symbol ``pace.''
@@ -7323,7 +7323,7 @@ port is omitted from any input procedure, it defaults to the value returned by
@deffnx {read library procedure} read port
The read procedure converts external representations of Scheme objects into the
-objects themselves. That is, it is a parser for the non-terminal <datum> (see sections
+objects themselves. That is, it is a parser for the non-terminal @svar{datum} (see sections
7.1.2 and 6.4). It returns the next object parsable from the given textual input
port, updating
@@ -7870,12 +7870,12 @@ in previous chapters of this report.
This section provides a formal syntax for Scheme written in an extended BNF.
All spaces in the grammar are for legibility. Case is not significant except in the definitions
-of <letter>, <character name> and <mnemonic escape>; for example, #x1A and #X1a are
-equivalent, but foo and Foo and #\space and #\Space are distinct. <empty> stands for the
+of @svar{letter}, <character name> and <mnemonic escape>; for example, #x1A and #X1a are
+equivalent, but foo and Foo and #\space and #\Space are distinct. @svar{empty} stands for the
empty string.
-The following extensions to BNF are used to make the description more concise: <thing>*
-means zero or more occurrences of <thing>; and <thing>+ means at least one <thing>.
+The following extensions to BNF are used to make the description more concise: @svar{thing}*
+means zero or more occurrences of @svar{thing}; and @svar{thing}+ means at least one @svar{thing}.
@node External representations (formal)
@subsection External representations (forma)
@@ -7886,7 +7886,7 @@ are formed from sequences of tokens.
<Intertoken space> can occur on either side of any token, but not within a token.
-Identifiers that do not begin with a vertical line are terminated by a <delimiter> or by the
+Identifiers that do not begin with a vertical line are terminated by a @svar{delimiter} or by the
end of the input. So are dot, numbers, characters, and booleans. Identifiers that begin
with a vertical line are terminated by another vertical line.
@@ -7902,80 +7902,80 @@ for correct spelling in Persian, Hindi, and other languages). However, it is an
first character to have a general category of Nd, Mc, or Me. It is also an error to use a
non-Unicode character in symbols or identifiers.
-All Scheme implementations must permit the escape sequence \x<hexdigits>; to appear in
+All Scheme implementations must permit the escape sequence \x@svar{hexdigits}; to appear in
Scheme identifiers that are enclosed in vertical lines. If the character with the given
Unicode scalar value is supported by the implementation, identifiers containing such a
sequence are equivalent to identifiers containing the corresponding character.
-<token> ⟶<identifier> ∣<boolean> ∣<number> ∣<character> ∣<string>
+@svar{token} ⟶@svar{identifier} ∣@svar{boolean} ∣@svar{number} ∣@svar{character} ∣@svar{string}
∣( ∣) ∣#( ∣#u8( ∣' ∣` ∣, ∣,@ ∣.
-<delimiter> ⟶<whitespace> ∣<vertical line>
+@svar{delimiter} ⟶@svar{whitespace} ∣<vertical line>
∣( ∣) ∣" ∣;
<intraline whitespace> ⟶<space or tab>
-<whitespace> ⟶<intraline whitespace> ∣<line ending>
+@svar{whitespace} ⟶<intraline whitespace> ∣<line ending>
<vertical line> ⟶|
-<line ending> ⟶<newline> ∣<return> <newline>
-∣<return>
-<comment> ⟶; ⟨all subsequent characters up to a
+<line ending> ⟶@svar{newline} ∣@svar{return} @svar{newline}
+∣@svar{return}
+@svar{comment} ⟶; ⟨all subsequent characters up to a
line ending⟩ ∣<nested comment>
-∣#; <intertoken space> <datum>
+∣#; <intertoken space> @svar{datum}
<nested comment> ⟶#| <comment text>
<comment cont>* |#
<comment text> ⟶⟨character sequence not containing
#| or |#⟩
<comment cont> ⟶<nested comment> <comment text>
-<directive> ⟶#!fold-case ∣#!no-fold-case Note that it is ungrammatical to follow a
-<directive> with anything but a <delimiter> or the end of file.
+@svar{directive} ⟶#!fold-case ∣#!no-fold-case Note that it is ungrammatical to follow a
+@svar{directive} with anything but a @svar{delimiter} or the end of file.
-<atmosphere> ⟶<whitespace> ∣<comment> ∣<directive>
-<intertoken space> ⟶<atmosphere>*
+@svar{atmosphere} ⟶@svar{whitespace} ∣@svar{comment} ∣@svar{directive}
+<intertoken space> ⟶@svar{atmosphere}*
-Note that +i, -i and <infnan> below are exceptions to the <peculiar identifier> rule; they are
+Note that +i, -i and @svar{infnan} below are exceptions to the <peculiar identifier> rule; they are
parsed as numbers, not identifiers.
-<identifier> ⟶<initial> <subsequent>*
+@svar{identifier} ⟶@svar{initial} @svar{subsequent}*
∣<vertical line> <symbol element>* <vertical line>
∣<peculiar identifier>
-<initial> ⟶<letter> ∣<special initial>
-<letter> ⟶a ∣b ∣c ∣... ∣z
+@svar{initial} ⟶@svar{letter} ∣<special initial>
+@svar{letter} ⟶a ∣b ∣c ∣... ∣z
∣A ∣B ∣C ∣... ∣Z
<special initial> ⟶! ∣$ ∣% ∣& ∣* ∣/ ∣: ∣< ∣=
∣> ∣? ∣@ ∣^ ∣_ ∣~
-<subsequent> ⟶<initial> ∣<digit>
+@svar{subsequent} ⟶@svar{initial} ∣@svar{digit}
∣<special subsequent>
-<digit> ⟶0 ∣1 ∣2 ∣3 ∣4 ∣5 ∣6 ∣7 ∣8 ∣9
-<hex digit> ⟶<digit> ∣a ∣b ∣c ∣d ∣e ∣f
+@svar{digit} ⟶0 ∣1 ∣2 ∣3 ∣4 ∣5 ∣6 ∣7 ∣8 ∣9
+<hex digit> ⟶@svar{digit} ∣a ∣b ∣c ∣d ∣e ∣f
<explicit sign> ⟶+ ∣-
<special subsequent> ⟶<explicit sign> ∣. ∣@
<inline hex escape> ⟶\x<hex scalar value>;
<hex scalar value> ⟶<hex digit>+
<mnemonic escape> ⟶\a ∣\b ∣\t ∣\n ∣\r
<peculiar identifier> ⟶<explicit sign>
-∣<explicit sign> <sign subsequent> <subsequent>*
-∣<explicit sign> . <dot subsequent> <subsequent>*
-∣. <dot subsequent> <subsequent>*
+∣<explicit sign> <sign subsequent> @svar{subsequent}*
+∣<explicit sign> . <dot subsequent> @svar{subsequent}*
+∣. <dot subsequent> @svar{subsequent}*
<dot subsequent> ⟶<sign subsequent> ∣.
-<sign subsequent> ⟶<initial> ∣<explicit sign> ∣@
+<sign subsequent> ⟶@svar{initial} ∣<explicit sign> ∣@
<symbol element> ⟶ <any character other than <vertical line> or \>
∣<inline hex escape> ∣<mnemonic escape> ∣\|
-<boolean> ⟶#t ∣#f ∣#true ∣#false
+@svar{boolean} ⟶#t ∣#f ∣#true ∣#false
-<character> ⟶#\ <any character>
+@svar{character} ⟶#\ <any character>
∣#\ <character name>
∣#\x<hex scalar value>
<character name> ⟶alarm ∣backspace ∣delete
∣escape ∣newline ∣null ∣return ∣space ∣tab
-<string> ⟶" <string element>* "
+@svar{string} ⟶" <string element>* "
<string element> ⟶<any character other than " or \>
∣<mnemonic escape> ∣\" ∣\\ ∣\|
∣\<intraline whitespace>*<line ending>
<intraline whitespace>*
∣<inline hex escape>
-<bytevector> ⟶#u8(<byte>*)
-<byte> ⟶<any exact integer between 0 and 255>
+@svar{bytevector} ⟶#u8(@svar{byte}*)
+@svar{byte} ⟶<any exact integer between 0 and 255>
-<number> ⟶<num 2> ∣<num 8>
+@svar{number} ⟶<num 2> ∣<num 8>
∣<num 10> ∣<num 16>
The following rules for <num R>, <complex R>, <real R>, <ureal R>, <uinteger R>, and
<prefix R> are implicitly replicated for R = 2, 8, 10, and 16. There are no rules for <decimal
@@ -7985,48 +7985,48 @@ characters used in the grammar of numbers can appear in either upper or lower ca
<num R> ⟶<prefix R> <complex R>
<complex R> ⟶<real R> ∣<real R> @ <real R>
∣<real R> + <ureal R> i ∣<real R> - <ureal R> i
-∣<real R> + i ∣<real R> - i ∣<real R> <infnan> i
+∣<real R> + i ∣<real R> - i ∣<real R> @svar{infnan} i
∣+ <ureal R> i ∣- <ureal R> i
-∣<infnan> i ∣+ i ∣- i
-<real R> ⟶<sign> <ureal R>
-∣<infnan>
+∣@svar{infnan} i ∣+ i ∣- i
+<real R> ⟶@svar{sign} <ureal R>
+∣@svar{infnan}
<ureal R> ⟶<uinteger R>
∣<uinteger R> / <uinteger R>
∣<decimal R>
-<decimal 10> ⟶<uinteger 10> <suffix>
-∣. <digit 10>+ <suffix>
-∣<digit 10>+ . <digit 10>* <suffix>
+<decimal 10> ⟶<uinteger 10> @svar{suffix}
+∣. <digit 10>+ @svar{suffix}
+∣<digit 10>+ . <digit 10>* @svar{suffix}
<uinteger R> ⟶<digit R>+
-<prefix R> ⟶<radix R> <exactness>
-∣<exactness> <radix R>
-<infnan> ⟶+inf.0 ∣-inf.0 ∣+nan.0 ∣-nan.0
-<suffix> ⟶<empty>
-∣<exponent marker> <sign> <digit 10>+
+<prefix R> ⟶<radix R> @svar{exactness}
+∣@svar{exactness} <radix R>
+@svar{infnan} ⟶+inf.0 ∣-inf.0 ∣+nan.0 ∣-nan.0
+@svar{suffix} ⟶@svar{empty}
+∣<exponent marker> @svar{sign} <digit 10>+
<exponent marker> ⟶e
-<sign> ⟶<empty> ∣+ ∣-
-<exactness> ⟶<empty> ∣#i∣#e<radix 2> ⟶#b<radix 8> ⟶#o<radix 10> ⟶<empty> ∣#d
+@svar{sign} ⟶@svar{empty} ∣+ ∣-
+@svar{exactness} ⟶@svar{empty} ∣#i∣#e<radix 2> ⟶#b<radix 8> ⟶#o<radix 10> ⟶@svar{empty} ∣#d
<radix 16> ⟶#x<digit 2> ⟶0 ∣1
<digit 8> ⟶0 ∣1 ∣2 ∣3 ∣4 ∣5 ∣6 ∣7
-<digit 10> ⟶<digit>
+<digit 10> ⟶@svar{digit}
<digit 16> ⟶<digit 10> ∣a ∣b ∣c ∣d ∣e ∣f
@node Expressions (formal)
@subsection Expressions (formal)
-<Datum> is what the read procedure (section 6.13.2) successfully parses. Note that any
-string that parses as an <expression> will also parse as a <datum>.
-
-<datum> ⟶<simple datum> ∣<compound datum>
-∣<label> = <datum> ∣<label> #
-<simple datum> ⟶<boolean> ∣<number>
-∣<character> ∣<string> ∣<symbol> ∣<bytevector>
-<symbol> ⟶<identifier>
-<compound datum> ⟶<list> ∣<vector> ∣<abbreviation>
-<list> ⟶(<datum>*) ∣(<datum>+ . <datum>)
-<abbreviation> ⟶<abbrev prefix> <datum>
+@svar{Datum} is what the read procedure (section 6.13.2) successfully parses. Note that any
+string that parses as an @svar{expression} will also parse as a @svar{datum}.
+
+@svar{datum} ⟶<simple datum> ∣<compound datum>
+∣@svar{label} = @svar{datum} ∣@svar{label} #
+<simple datum> ⟶@svar{boolean} ∣@svar{number}
+∣@svar{character} ∣@svar{string} ∣@svar{symbol} ∣@svar{bytevector}
+@svar{symbol} ⟶@svar{identifier}
+<compound datum> ⟶@svar{list} ∣@svar{vector} ∣@svar{abbreviation}
+@svar{list} ⟶(@svar{datum}*) ∣(@svar{datum}+ . @svar{datum})
+@svar{abbreviation} ⟶<abbrev prefix> @svar{datum}
<abbrev prefix> ⟶' ∣` ∣, ∣,@
-<vector> ⟶#(<datum>*)
-<label> ⟶# <uinteger 10>
+@svar{vector} ⟶#(@svar{datum}*)
+@svar{label} ⟶# <uinteger 10>
@node Quasiquotations
@subsection Quasiquotations
@@ -8035,87 +8035,87 @@ The definitions in this and the following subsections assume that all the syntax
defined in this report have been properly imported from their libraries, and that none of
them have been redefined or shadowed.
-<expression> ⟶<identifier>
-∣<literal>
+@svar{expression} ⟶@svar{identifier}
+∣@svar{literal}
∣<procedure call>
∣<lambda expression>
-∣<conditional>
-∣<assignment>
+∣@svar{conditional}
+∣@svar{assignment}
∣<derived expression>
∣<macro use>
∣<macro block>
-∣<includer>
-<literal> ⟶<quotation> ∣<self-evaluating>
-<self-evaluating> ⟶<boolean> ∣<number> ∣<vector>
-∣<character> ∣<string> ∣<bytevector>
-<quotation> ⟶'<datum> ∣(quote <datum>)
-<procedure call> ⟶(<operator> <operand>*)
-<operator> ⟶<expression>
-<operand> ⟶<expression>
-<lambda expression> ⟶(lambda <formals> <body>)
-<formals> ⟶(<identifier>*) ∣<identifier>
-∣(<identifier>+ . <identifier>)
-<body> ⟶<definition>* <sequence>
-<sequence> ⟶<command>* <expression>
-<command> ⟶<expression>
-<conditional> ⟶(if <test> <consequent> <alternate>)
-<test> ⟶<expression>
-<consequent> ⟶<expression>
-<alternate> ⟶<expression> ∣<empty>
-<assignment> ⟶(set! <identifier> <expression>)
+∣@svar{includer}
+@svar{literal} ⟶@svar{quotation} ∣@svar{self-evaluating}
+@svar{self-evaluating} ⟶@svar{boolean} ∣@svar{number} ∣@svar{vector}
+∣@svar{character} ∣@svar{string} ∣@svar{bytevector}
+@svar{quotation} ⟶'@svar{datum} ∣(quote @svar{datum})
+<procedure call> ⟶(@svar{operator} @svar{operand}*)
+@svar{operator} ⟶@svar{expression}
+@svar{operand} ⟶@svar{expression}
+<lambda expression> ⟶(lambda @svar{formals} @svar{body})
+@svar{formals} ⟶(@svar{identifier}*) ∣@svar{identifier}
+∣(@svar{identifier}+ . @svar{identifier})
+@svar{body} ⟶@svar{definition}* @svar{sequence}
+@svar{sequence} ⟶@svar{command}* @svar{expression}
+@svar{command} ⟶@svar{expression}
+@svar{conditional} ⟶(if @svar{test} @svar{consequent} @svar{alternate})
+@svar{test} ⟶@svar{expression}
+@svar{consequent} ⟶@svar{expression}
+@svar{alternate} ⟶@svar{expression} ∣@svar{empty}
+@svar{assignment} ⟶(set! @svar{identifier} @svar{expression})
<derived expression> ⟶ (cond <cond clause>+)
-∣(cond <cond clause>* (else <sequence>))
-∣(case <expression>
+∣(cond <cond clause>* (else @svar{sequence}))
+∣(case @svar{expression}
<case clause>+)
-∣(case <expression>
+∣(case @svar{expression}
<case clause>*
- (else <sequence>))
-∣(case <expression>
+ (else @svar{sequence}))
+∣(case @svar{expression}
<case clause>*
- (else => <recipient>))
-∣(and <test>*)
-∣(or <test>*)
-∣(when <test> <sequence>)
-∣(unless <test> <sequence>)
-∣(let (<binding spec>*) <body>)
-∣(let <identifier> (<binding spec>*) <body>)
-∣(let* (<binding spec>*) <body>)
-∣(letrec (<binding spec>*) <body>)
-∣(letrec* (<binding spec>*) <body>)
-∣(let-values (<mv binding spec>*) <body>)
-∣(let*-values (<mv binding spec>*) <body>)
-∣(begin <sequence>)
+ (else => @svar{recipient}))
+∣(and @svar{test}*)
+∣(or @svar{test}*)
+∣(when @svar{test} @svar{sequence})
+∣(unless @svar{test} @svar{sequence})
+∣(let (<binding spec>*) @svar{body})
+∣(let @svar{identifier} (<binding spec>*) @svar{body})
+∣(let* (<binding spec>*) @svar{body})
+∣(letrec (<binding spec>*) @svar{body})
+∣(letrec* (<binding spec>*) @svar{body})
+∣(let-values (<mv binding spec>*) @svar{body})
+∣(let*-values (<mv binding spec>*) @svar{body})
+∣(begin @svar{sequence})
∣(do (<iteration spec>*)
- (<test> <do result>)
- <command>*)
-∣(delay <expression>)
-∣(delay-force <expression>)
-∣(parameterize ((<expression> <expression>)*)
- <body>)
-∣(guard (<identifier> <cond clause>*) <body>)
-∣<quasiquotation>
+ (@svar{test} <do result>)
+ @svar{command}*)
+∣(delay @svar{expression})
+∣(delay-force @svar{expression})
+∣(parameterize ((@svar{expression} @svar{expression})*)
+ @svar{body})
+∣(guard (@svar{identifier} <cond clause>*) @svar{body})
+∣@svar{quasiquotation}
∣(case-lambda <case-lambda clause>*)
-<cond clause> ⟶(<test> <sequence>)
-∣(<test>)
-∣(<test> => <recipient>)
-<recipient> ⟶<expression>
-<case clause> ⟶((<datum>*) <sequence>)
-∣((<datum>*) => <recipient>)
-<binding spec> ⟶(<identifier> <expression>)
-<mv binding spec> ⟶(<formals> <expression>)
-<iteration spec> ⟶(<identifier> <init> <step>)
-∣(<identifier> <init>)
-<case-lambda clause> ⟶(<formals> <body>)
-<init> ⟶<expression>
-<step> ⟶<expression>
-<do result> ⟶<sequence> ∣<empty>
-<macro use> ⟶(<keyword> <datum>*)
-<keyword> ⟶<identifier>
-<macro block> ⟶ (let-syntax (<syntax spec>*) <body>)
-∣(letrec-syntax (<syntax spec>*) <body>)
-<syntax spec> ⟶(<keyword> <transformer spec>)
-<includer> ⟶ ∣(include <string>+)
-∣(include-ci <string>+)
+<cond clause> ⟶(@svar{test} @svar{sequence})
+∣(@svar{test})
+∣(@svar{test} => @svar{recipient})
+@svar{recipient} ⟶@svar{expression}
+<case clause> ⟶((@svar{datum}*) @svar{sequence})
+∣((@svar{datum}*) => @svar{recipient})
+<binding spec> ⟶(@svar{identifier} @svar{expression})
+<mv binding spec> ⟶(@svar{formals} @svar{expression})
+<iteration spec> ⟶(@svar{identifier} @svar{init} @svar{step})
+∣(@svar{identifier} @svar{init})
+<case-lambda clause> ⟶(@svar{formals} @svar{body})
+@svar{init} ⟶@svar{expression}
+@svar{step} ⟶@svar{expression}
+<do result> ⟶@svar{sequence} ∣@svar{empty}
+<macro use> ⟶(@svar{keyword} @svar{datum}*)
+@svar{keyword} ⟶@svar{identifier}
+<macro block> ⟶ (let-syntax (<syntax spec>*) @svar{body})
+∣(letrec-syntax (<syntax spec>*) @svar{body})
+<syntax spec> ⟶(@svar{keyword} <transformer spec>)
+@svar{includer} ⟶ ∣(include @svar{string}+)
+∣(include-ci @svar{string}+)
@node Transformers
@subsection Transformers
@@ -8124,8 +8124,8 @@ The following grammar for quasiquote expressions is not context-free. It is pres
a recipe for generating an infinite number of production rules. Imagine a copy of the
following rules for D = 1, 2, 3, @dots{}, where D is the nesting depth.
-<quasiquotation> ⟶<quasiquotation 1>
-<qq template 0> ⟶<expression>
+@svar{quasiquotation} ⟶<quasiquotation 1>
+<qq template 0> ⟶@svar{expression}
<quasiquotation D> ⟶`<qq template D>
∣(quasiquote <qq template D>)
<qq template D> ⟶<simple datum>
@@ -8142,9 +8142,9 @@ following rules for D = 1, 2, 3, @dots{}, where D is the nesting depth.
<qq template or splice D> ⟶<qq template D>
∣<splicing unquotation D>
<splicing unquotation D> ⟶,@@<qq template D−1>
-∣(unquote-splicing <qq template D−1>) In <quasiquotation>s, a <list qq template D> can
+∣(unquote-splicing <qq template D−1>) In @svar{quasiquotation}s, a <list qq template D> can
sometimes be confused with either an <unquotation D> or a <splicing unquotation D>.
-The interpretation as an <unquotation> or <splicing unquotation D> takes precedence.
+The interpretation as an @svar{unquotation} or <splicing unquotation D> takes precedence.
@node Programs and definitions
@subsection Programs and definitions
@@ -8152,60 +8152,60 @@ The interpretation as an <unquotation> or <splicing unquotation D> takes precede
Note: Though this grammar does not say so, a top-level syntax-rules pattern must be
a list pattern, not a vector pattern or an identifier pattern.
-<transformer spec> ⟶ (syntax-rules (<identifier>*) <syntax rule>*)
-∣(syntax-rules <identifier> (<identifier>*)
+<transformer spec> ⟶ (syntax-rules (@svar{identifier}*) <syntax rule>*)
+∣(syntax-rules @svar{identifier} (@svar{identifier}*)
<syntax rule>*)
-<syntax rule> ⟶(<pattern> <template>)
-<pattern> ⟶<pattern identifier>
-∣<underscore>
-∣(<pattern>*)
-∣(<pattern>+ . <pattern>)
-∣(<pattern>* <pattern> <ellipsis> <pattern>*)
-∣(<pattern>* <pattern> <ellipsis> <pattern>*
- . <pattern>)
-∣#(<pattern>*)
-∣#(<pattern>* <pattern> <ellipsis> <pattern>*)
+<syntax rule> ⟶(@svar{pattern} @svar{template})
+@svar{pattern} ⟶<pattern identifier>
+∣@svar{underscore}
+∣(@svar{pattern}*)
+∣(@svar{pattern}+ . @svar{pattern})
+∣(@svar{pattern}* @svar{pattern} @svar{ellipsis} @svar{pattern}*)
+∣(@svar{pattern}* @svar{pattern} @svar{ellipsis} @svar{pattern}*
+ . @svar{pattern})
+∣#(@svar{pattern}*)
+∣#(@svar{pattern}* @svar{pattern} @svar{ellipsis} @svar{pattern}*)
∣<pattern datum>
-<pattern datum> ⟶<string>
-∣<character>
-∣<boolean>
-∣<number>
-∣<bytevector>
-<template> ⟶<pattern identifier>
+<pattern datum> ⟶@svar{string}
+∣@svar{character}
+∣@svar{boolean}
+∣@svar{number}
+∣@svar{bytevector}
+@svar{template} ⟶<pattern identifier>
∣(<template element>*)
-∣(<template element>+ . <template>)
+∣(<template element>+ . @svar{template})
∣#(<template element>*)
∣<template datum>
-<template element> ⟶<template>
-∣<template> <ellipsis>
+<template element> ⟶@svar{template}
+∣@svar{template} @svar{ellipsis}
<template datum> ⟶<pattern datum>
<pattern identifier> ⟶<any identifier except ...>
-<ellipsis> ⟶<an identifier defaulting to ...>
-<underscore> ⟶<the identifier _>
+@svar{ellipsis} ⟶<an identifier defaulting to ...>
+@svar{underscore} ⟶<the identifier _>
@node Libraries (formal)
@subsection Libraries (formal)
-<program> ⟶ <import declaration>+
+@svar{program} ⟶ <import declaration>+
<command or definition>+
-<command or definition> ⟶<command>
-∣<definition>
+<command or definition> ⟶@svar{command}
+∣@svar{definition}
∣(begin <command or definition>+)
-<definition> ⟶(define <identifier> <expression>)
-∣(define (<identifier> <def formals>) <body>)
+@svar{definition} ⟶(define @svar{identifier} @svar{expression})
+∣(define (@svar{identifier} <def formals>) @svar{body})
∣<syntax definition>
-∣(define-values <formals> <body>)
-∣(define-record-type <identifier>
- <constructor> <identifier> <field spec>*)
-∣(begin <definition>*)
-<def formals> ⟶<identifier>*
-∣<identifier>* . <identifier>
-<constructor> ⟶(<identifier> <field name>*)
-<field spec> ⟶(<field name> <accessor>)
-∣(<field name> <accessor> <mutator>)
-<field name> ⟶<identifier>
-<accessor> ⟶<identifier>
-<mutator> ⟶<identifier>
-<syntax definition> ⟶ (define-syntax <keyword> <transformer spec>)
+∣(define-values @svar{formals} @svar{body})
+∣(define-record-type @svar{identifier}
+ @svar{constructor} @svar{identifier} <field spec>*)
+∣(begin @svar{definition}*)
+<def formals> ⟶@svar{identifier}*
+∣@svar{identifier}* . @svar{identifier}
+@svar{constructor} ⟶(@svar{identifier} <field name>*)
+<field spec> ⟶(<field name> @svar{accessor})
+∣(<field name> @svar{accessor} @svar{mutator})
+<field name> ⟶@svar{identifier}
+@svar{accessor} ⟶@svar{identifier}
+@svar{mutator} ⟶@svar{identifier}
+<syntax definition> ⟶ (define-syntax @svar{keyword} <transformer spec>)
@node Formal semantics
@section Formal semantics
@@ -8241,11 +8241,11 @@ then the meaning of P is
calE [ [ ((lambda (I*) ] ]
P')
- <undefined>
+ @svar{undefined}
@dots{})
where I* is the sequence of variables defined in P, P′ is the sequence of expressions
-obtained by replacing every definition in P by an assignment, <undefined> is an
+obtained by replacing every definition in P by an assignment, @svar{undefined} is an
expression that evaluates to undefined, and calE is the semantic function that assigns
meaning to expressions.
@@ -8402,7 +8402,7 @@ Binding constructs:
@end example
-The following letrec macro uses the symbol <undefined> in place of an expression which
+The following letrec macro uses the symbol @svar{undefined} in place of an expression which
returns something that when stored in a location makes it an error to try to obtain the
value stored in the location. (No such expression is defined in Scheme.) A trick is used to
generate the temporary names needed to avoid specifying the order in which the values
@@ -8423,7 +8423,7 @@ are evaluated. This could also be accomplished by using an auxiliary macro.
(temp1 ...)
((var1 init1) ...)
body ...)
- (let ((var1 <undefined>) ...)
+ (let ((var1 @svar{undefined}) ...)
(let ((temp1 init1) ...)
(set! var1 temp1)
...
@@ -8442,7 +8442,7 @@ are evaluated. This could also be accomplished by using an auxiliary macro.
(define-syntax letrec*
(syntax-rules ()
((letrec* ((var1 init1) ...) body1 body2 ...)
- (let ((var1 <undefined>) ...)
+ (let ((var1 @svar{undefined}) ...)
(set! var1 init1)
...
(let () body1 body2 ...)))))
@@ -8593,7 +8593,7 @@ define the expression
@example
-(delay-force <expression>)
+(delay-force @svar{expression})
@end example
@@ -8601,7 +8601,7 @@ to have the same meaning as the procedure call
@example
-(make-promise #f (lambda () <expression>))
+(make-promise #f (lambda () @svar{expression}))
@end example
@@ -8620,7 +8620,7 @@ and we define the expression
@example
-(delay <expression>)
+(delay @svar{expression})
@end example
@@ -8628,7 +8628,7 @@ to have the same meaning as:
@example
-(delay-force (make-promise #t <expression>))
+(delay-force (make-promise #t @svar{expression}))
@end example
@@ -8688,8 +8688,8 @@ with the following promise accessors:
The following implementation of make-parameter and
parameterize is suitable for an implementation with no threads. Parameter objects are
-implemented here as procedures, using two arbitrary unique objects <param-set!> and
-<param-convert>:
+implemented here as procedures, using two arbitrary unique objects @svar{param-set!} and
+@svar{param-convert}:
@example
@@ -8701,9 +8701,9 @@ implemented here as procedures, using two arbitrary unique objects <param-set!>
(cond
((null? args)
value)
- ((eq? (car args) <param-set!>)
+ ((eq? (car args) @svar{param-set!})
(set! value (cadr args)))
- ((eq? (car args) <param-convert>)
+ ((eq? (car args) @svar{param-convert})
converter)
(else
(error "bad parameter syntax"))))))
@@ -8723,11 +8723,11 @@ dynamically rebind the associated value:
body)
(let ((p param) ...)
(let ((old (p)) ...
- (new ((p <param-convert>) value)) ...)
+ (new ((p @svar{param-convert}) value)) ...)
(dynamic-wind
- (lambda () (p <param-set!> new) ...)
+ (lambda () (p @svar{param-set!} new) ...)
(lambda () . body)
- (lambda () (p <param-set!> old) ...)))))
+ (lambda () (p @svar{param-set!} old) ...)))))
((parameterize ("step")
args
((param value) . rest)
@@ -9371,9 +9371,9 @@ ilp32, lp64, ilp64, ...C memory model flags.
big-endian, little-endianByte order flags.
-<name>The name of this implementation.
+@svar{name}The name of this implementation.
-<name-version>The name and version of this implementation.
+@svar{name-version}The name and version of this implementation.
@node Language changes
@chapter Language changes
@@ -9562,7 +9562,7 @@ This list is not authoritative, but is believed to be correct and complete.
* There are now two additional comment syntaxes: #; to skip the next datum, and #| ... |#
for nestable block comments.
-* Data prefixed with datum labels #<n>= can be referenced with #<n>#, allowing for
+* Data prefixed with datum labels #@svar{n}= can be referenced with #@svar{n}#, allowing for
reading and writing of data with shared structure.
* Strings and symbols now allow mnemonic and numeric escape sequences, and the list
