commit e98db346b0636e11e9b8ec2efd2b567f216d45a0
parent a6eea356c4d51b5f50f72439e0cf671aa3e30845
Author: Wolfgang Corcoran-Mathe <wcm@sigwinch.xyz>
Date: Tue, 30 Jan 2024 21:14:31 -0500
Use @svar in more places.
Diffstat:
1 file changed, 278 insertions(+), 278 deletions(-)
diff --git a/doc/r7rs-small/r7rs-small.texinfo b/doc/r7rs-small/r7rs-small.texinfo
@@ -622,7 +622,7 @@ Alternatively, an identifier can be represented by a sequence
of zero or more characters enclosed within vertical lines (@samp{|}), analogous to string literals.
Any character, including whitespace characters, but excluding the backslash and vertical
line characters, can appear verbatim in such an identifier. In addition, characters can be
-specified using either an <inline hex escape> or the same escapes available in strings.
+specified using either an @svar{inline hex escape} or the same escapes available in strings.
For example, the identifier @code{|H\x65;llo|} is the same identifier as @code{Hello}, and in an
implementation that supports the appropriate Unicode character the identifier @code{|\x3BB;|}
@@ -781,7 +781,7 @@ For a description of the notations used for numbers, see section 6.2.
@item @samp{#e #i #b #o #d #x}
These are used in the notation for numbers (section 6.2.5).
-@item @samp{#<n>= #<n>#}
+@item @samp{#@svar{n}= #@svar{n}#}
These are used for labeling and referencing other literal data (section 2.4).
@end table
@@ -1067,67 +1067,67 @@ bodies of @code{case-lambda} expressions.
@example
(lambda @svar{formals}
- @svar{definition}* @svar{expression}* <tail expression>)
+ @svar{definition}* @svar{expression}* @svar{tail expression})
-(case-lambda (@svar{formals} <tail body>)*)
+(case-lambda (@svar{formals} @svar{tail body})*)
@end example
@item
If one of the following expressions is in a tail context, then the
-subexpressions shown as <tail expression> are in a tail context. These were
+subexpressions shown as @svar{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 @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
+by replacing some occurrences of @svar{body} with @svar{tail body}, some occurrences
+of @svar{expression} with @svar{tail expression}, and some occurrences of @svar{sequence}
+with @svar{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} @svar{expression} <tail expression> <tail expression>)
-(@code{if} @svar{expression} <tail expression>)
+(@code{if} @svar{expression} @svar{tail expression} @svar{tail expression})
+(@code{if} @svar{expression} @svar{tail expression})
-(@code{cond} <cond clause>+)
-(@code{cond} <cond clause>* (else <tail sequence>))
+(@code{cond} @svar{cond clause}+)
+(@code{cond} @svar{cond clause}* (else @svar{tail sequence}))
(@code{case} @svar{expression}
- <case clause>+)
+ @svar{case clause}+)
(@code{case} @svar{expression}
- <case clause>*
- (else <tail sequence>))
+ @svar{case clause}*
+ (else @svar{tail sequence}))
-(@code{and} @svar{expression}* <tail expression>)
-(@code{or} @svar{expression}* <tail expression>)
+(@code{and} @svar{expression}* @svar{tail expression})
+(@code{or} @svar{expression}* @svar{tail expression})
-(@code{when} @svar{test} <tail sequence>)
-(@code{unless} @svar{test} <tail sequence>)
+(@code{when} @svar{test} @svar{tail sequence})
+(@code{unless} @svar{test} @svar{tail sequence})
-(@code{let} (<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>)
-(@code{let-values} (<mv binding spec>*) <tail body>)
-(@code{let*-values} (<mv binding spec>*) <tail body>)
+(@code{let} (@svar{binding spec}*) @svar{tail body})
+(@code{let} @svar{variable} (@svar{binding spec}*) @svar{tail body})
+(@code{let*} (@svar{binding spec}*) @svar{tail body})
+(@code{letrec} (@svar{binding spec}*) @svar{tail body})
+(@code{letrec*} (@svar{binding spec}*) @svar{tail body})
+(@code{let-values} (@svar{mv binding spec}*) @svar{tail body})
+(@code{let*-values} (@svar{mv binding spec}*) @svar{tail body})
-(@code{let-syntax} (<syntax spec>*) <tail body>)
-(@code{letrec-syntax} (<syntax spec>*) <tail body>)
+(@code{let-syntax} (@svar{syntax spec}*) @svar{tail body})
+(@code{letrec-syntax} (@svar{syntax spec}*) @svar{tail body})
-(@code{begin} <tail sequence>)
+(@code{begin} @svar{tail sequence})
-(@code{do} (<iteration spec>*)
- (@svar{test} <tail sequence>)
+(@code{do} (@svar{iteration spec}*)
+ (@svar{test} @svar{tail sequence})
@svar{expression}*)
@end display
where
@display
-<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>
+@svar{cond clause} @expansion{} (@svar{test} @svar{tail sequence})
+@svar{case clause} @expansion{} ((@svar{datum}*) @svar{tail sequence})
+@svar{tail body} @expansion{} @svar{definition}* @svar{tail sequence}
+@svar{tail sequence} @expansion{} @svar{expression}* @svar{tail expression}
@end display
@@ -1625,43 +1625,43 @@ 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 @svar{ce-clause} takes the following form:
-(<feature requirement> @svar{expression} @dots{})
+(@svar{feature requirement} @svar{expression} @dots{})
The last clause can be an ``else clause,'' which has the form
(else @svar{expression} @dots{})
-A <feature requirement> takes one of the following forms:
+A @svar{feature requirement} takes one of the following forms:
@itemize
@item
-<feature identifier>
+@svar{feature identifier}
@item
-(library <library name>)
+(library @svar{library name})
@item
-(and <feature requirement> @dots{})
+(and @svar{feature requirement} @dots{})
@item
-(or <feature requirement> @dots{})
+(or @svar{feature requirement} @dots{})
@item
-(not <feature requirement>)
+(not @svar{feature requirement})
@end itemize
Semantics: Each implementation maintains a list of feature identifiers which are present,
-as well as a list of libraries which can be imported. The value of a <feature requirement> is
-determined by replacing each <feature identifier> and (library <library name>) on the
+as well as a list of libraries which can be imported. The value of a @svar{feature requirement} is
+determined by replacing each @svar{feature identifier} and (library @svar{library name}) on the
implementation's lists with #t, and all other feature identifiers and library names with #f,
then evaluating the resulting expression as a Scheme boolean expression under the
normal interpretation of and, or, and not.
-A cond-expand is then expanded by evaluating the <feature requirement>s of successive
+A cond-expand is then expanded by evaluating the @svar{feature requirement}s of successive
@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
+ignored. If none of the @svar{feature requirement}s evaluate to #t, then if there is an else
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.
@@ -1814,9 +1814,9 @@ continuation of an @svar{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> @svar{body})
+syntax: (let-values @svar{mv binding spec} @svar{body})
-Syntax: <Mv binding spec> has the form
+Syntax: @svar{Mv binding spec} has the form
((@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
@@ -1840,9 +1840,9 @@ corresponding @svar{init}.
@end example
-syntax: (let*-values <mv binding spec> @svar{body})
+syntax: (let*-values @svar{mv binding spec} @svar{body})
-Syntax: <Mv binding spec> has the form
+Syntax: @svar{Mv binding spec} has the form
((@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
@@ -1869,7 +1869,7 @@ and so on.
Both of Scheme's sequencing constructs are named begin, but the two have slightly
different forms and uses:
-syntax: (begin <expression or definition> @dots{})
+syntax: (begin @svar{expression or definition} @dots{})
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
@@ -2207,16 +2207,16 @@ without the need to pass the value to every procedure in the call chain explicit
@subsection Exception handling
syntax: (guard (@svar{variable}
- <cond clause1> <cond clause2> @dots{})
+ @svar{cond clause1} @svar{cond clause2} @dots{})
@svar{body})
-Syntax: Each <cond clause> is as in the specification of cond.
+Syntax: Each @svar{cond clause} is as in the specification of cond.
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 @svar{test} evaluates to #f and there is no else clause, then
+every @svar{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.
@@ -2242,8 +2242,8 @@ See section 6.11 for a more complete discussion of exceptions.
@node Quasiquotation
@subsection Quasiquotation
-syntax: (quasiquote <qq template>)
-syntax: `<qq template>
+syntax: (quasiquote @svar{qq template})
+syntax: `@svar{qq template}
auxiliary syntax: unquote
auxiliary syntax: ,
auxiliary syntax: unquote-splicing
@@ -2251,15 +2251,15 @@ auxiliary syntax: ,﹫
``Quasiquote''expressions are useful for constructing a list or vector structure when some
but not all of the desired structure is known in advance. If no commasappear within the
-<qq template>, the result of evaluating `<qq template> is equivalent to the result of
-evaluating '<qq template>. If a commaappears within the <qq template>, however, the
+@svar{qq template}, the result of evaluating `@svar{qq template} is equivalent to the result of
+evaluating '@svar{qq template}. If a commaappears within the @svar{qq template}, however, the
expression following the comma is evaluated (``unquoted'') and its result is inserted into
the structure instead of the comma and the expression. If a comma appears followed
without intervening whitespace by a commercial at-sign (﹫),then it is an error if the
following expression does not evaluate to a list; the opening and closing parentheses of
the list are then ``stripped away'' and the elements of the list are inserted in place of the
comma at-sign expression sequence. A comma at-sign normally appears only within a list
-or vector <qq template>.
+or vector @svar{qq template}.
Note: In order to unquote an identifier beginning with @code{,} it is necessary to use either
an explicit unquote or to put whitespace after the comma, to avoid colliding with the
@@ -2322,7 +2322,7 @@ However, it is not equivalent to this expression:
@end example
-The two notations `<qq template> and (quasiquote <qq
+The two notations `@svar{qq template} and (quasiquote <qq
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.
@@ -2338,7 +2338,7 @@ write procedure may output either format.
@end example
It is an error if any of the identifiers quasiquote, unquote, or unquote-splicing appear in
-positions within a <qq template> otherwise than as described above.
+positions within a @svar{qq template} otherwise than as described above.
@node Case-lambda
@subsection Case-lambda
@@ -2431,7 +2431,7 @@ syntax: (let-syntax @svar{bindings} @svar{body})
Syntax: @svar{Bindings} has the form
-((@svar{keyword} <transformer spec>) @dots{})Each @svar{keyword} is an identifier, each <transformer
+((@svar{keyword} @svar{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.
@@ -2466,7 +2466,7 @@ Syntax: Same as for let-syntax.
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 @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
+has the @svar{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.
@@ -2496,19 +2496,19 @@ expression.
@node Pattern language
@subsection Pattern language
-A <transformer spec> has one of the following forms:
+A @svar{transformer spec} has one of the following forms:
-syntax: (syntax-rules (<pattern literal> @dots{})
- <syntax rule> @dots{})
-syntax: (syntax-rules @svar{ellipsis} (<pattern literal> @dots{})
- <syntax rule> @dots{})
+syntax: (syntax-rules (@svar{pattern literal} @dots{})
+ @svar{syntax rule} @dots{})
+syntax: (syntax-rules @svar{ellipsis} (@svar{pattern literal} @dots{})
+ @svar{syntax rule} @dots{})
auxiliary syntax: _
auxiliary syntax: @dots{}
-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
+Syntax: It is an error if any of the @svar{pattern literal}s, or the @svar{ellipsis} in the second form, is
+not an identifier. It is also an error if @svar{syntax rule} is not of the form
-(@svar{pattern} @svar{template})The @svar{pattern} in a <syntax rule> is a list @svar{pattern} whose first
+(@svar{pattern} @svar{template})The @svar{pattern} in a @svar{syntax rule} is a list @svar{pattern} whose first
element is an identifier.
A @svar{pattern} is either an identifier, a constant, or one of the following
@@ -2530,14 +2530,14 @@ identifier ... (three consecutive periods) otherwise.
Semantics: An instance of syntax-rules produces a new macro transformer by specifying a
sequence of hygienic rewrite rules. A use of a macro whose keyword is associated with a
transformer specified by syntax-rules is matched against the patterns contained in the
-<syntax rule>s, beginning with the leftmost <syntax rule>. When a match is found, the
+@svar{syntax rule}s, beginning with the leftmost @svar{syntax rule}. When a match is found, the
macro use is transcribed hygienically according to the template.
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
+listed in the list of @svar{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
+The keyword at the beginning of the pattern in a @svar{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
@@ -2549,14 +2549,14 @@ cannot be used to refer to those elements. If an underscore appears in the <patt
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
+Identifiers that appear in (@svar{pattern literal} @dots{}) are interpreted as literal identifiers to be
matched against corresponding elements of the input. An element in the input matches
a literal identifier if and only if it is an identifier and either both its occurrence in the
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 @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.
+unless @svar{ellipsis} appears in the @svar{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:
@@ -2715,7 +2715,7 @@ explained in this chapter. They are valid in some, but not all, contexts where e
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
+At the outermost level of a program, (begin @svar{expression or definition1} @dots{}) is equivalent to
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.
@@ -2741,37 +2741,37 @@ An import declaration takes the following form:
(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
+@svar{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>
+* @svar{library name}
-* (only <import set> @svar{identifier} @dots{})
+* (only @svar{import set} @svar{identifier} @dots{})
-* (except <import set> @svar{identifier} @dots{})
+* (except @svar{import set} @svar{identifier} @dots{})
-* (prefix <import set> @svar{identifier})
+* (prefix @svar{import set} @svar{identifier})
-* (rename <import set>
+* (rename @svar{import set}
(@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
-<import set> forms modify this set as follows:
+@svar{import set} forms modify this set as follows:
-* only produces a subset of the given <import set> including only the listed identifiers
+* only produces a subset of the given @svar{import set} including only the listed identifiers
(after any renaming). It is an error if any of the listed identifiers are not found in the
original set.
-* except produces a subset of the given <import set>, excluding the listed identifiers
+* except produces a subset of the given @svar{import set}, excluding the listed identifiers
(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 @svar{identifier1} with
+* rename modifies the given @svar{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
+* prefix automatically renames all identifiers in the given @svar{import set}, prefixing each
with the specified @svar{identifier}.
In a program or library declaration, it is an error to import the same identifier more than
@@ -2913,9 +2913,9 @@ a procedure call.
Syntax definitions have this form:
-(define-syntax @svar{keyword} <transformer spec>)
+(define-syntax @svar{keyword} @svar{transformer spec})
-@svar{Keyword} is an identifier, and the <transformer spec> is an instance of syntax-rules. Like
+@svar{Keyword} is an identifier, and the @svar{transformer spec} is an instance of syntax-rules. Like
variable definitions, syntax definitions can appear at the outermost level or nested within
a body.
@@ -2981,8 +2981,8 @@ syntax: (define-record-type @svar{name}
Syntax: @svar{name} and @svar{pred} are identifiers. The @svar{constructor} is of the form
-(<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
+(@svar{constructor name} @svar{field name} @dots{})and each @svar{field} is either of the form (@svar{field name}
+@svar{accessor name})or of the form (@svar{field name} @svar{accessor name} @svar{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.
@@ -2997,21 +2997,21 @@ An instance of define-record-type is equivalent to the following definitions:
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 @svar{name}. Fields whose names are listed with <constructor name> have
+* @svar{constructor name} is bound to a procedure that takes as many arguments as there
+ are @svar{field name}s in the (@svar{constructor name} @dots{}) subexpression and returns a new
+ record of type @svar{name}. Fields whose names are listed with @svar{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 @svar{constructor} but not as a <field
name>.
* @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.
+ procedure bound to @svar{constructor name} and #f for everything else.
-* Each <accessor name> is bound to a procedure that takes a record of type @svar{name} and
+* Each @svar{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 @svar{name} and
+* Each @svar{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.
@@ -3060,23 +3060,23 @@ semantics for libraries.
A library definition takes the following form:
-(define-library <library name>
- <library declaration> @dots{})
-<library name> is a list whose members are identifiers and exact non-negative integers. It
+(define-library @svar{library name}
+ @svar{library declaration} @dots{})
+@svar{library name} is a list whose members are identifiers and exact non-negative integers. It
is used to identify the library uniquely when importing from other programs or libraries.
Libraries whose first identifier is scheme are reserved for use by this report and future
versions of this report. Libraries whose first identifier is srfi are reserved for libraries
implementing Scheme Requests for Implementation. It is inadvisable, but not an error,
-for identifiers in library names to contain any of the characters | \ ? * < " : > + [ ] / or
+for identifiers in library names to contain any of the characters | \ ? * @svar{ " : } + [ ] / or
control characters after escapes are expanded.
-A <library declaration> is any of:
+A @svar{library declaration} is any of:
-* (export <export spec> @dots{})
+* (export @svar{export spec} @dots{})
-* (import <import set> @dots{})
+* (import @svar{import set} @dots{})
-* (begin <command or definition> @dots{})
+* (begin @svar{command or definition} @dots{})
* (include @svar{filename1} @svar{filename2} @dots{})
@@ -3087,13 +3087,13 @@ A <library declaration> is any of:
* (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:
+libraries or programs. An @svar{export spec} takes one of the following forms:
* @svar{identifier}
* (rename @svar{identifier1} @svar{identifier2})
-In an <export spec>, an @svar{identifier} names a single binding defined within or imported
+In an @svar{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 @svar{identifier1} in each (@svar{identifier1} @svar{identifier2}) pairing,
@@ -4410,7 +4410,7 @@ implementations that distinguish minus zero.
∗ y = −0.0 x < 0.0 −π
y < 0.0 x < 0.0 −π< r< −π/2
y < 0.0 x = 0.0 −π/2
- y < 0.0 x > 0.0 −π/2 < r< 0.0
+ y @svar{ 0.0 x } 0.0 −π/2 < r< 0.0
y = 0.0 x = 0.0 undefined
∗ y = + 0.0 x = + 0.0 + 0.0
∗ y = −0.0 x = + 0.0 −0.0
@@ -5351,8 +5351,8 @@ 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 #\@svar{character} or #\<character name> or
-#\x<hex scalar value>.
+Characters are written using the notation #\@svar{character} or #\@svar{character name} or
+#\x@svar{hex scalar value}.
The following character names must be supported by all implementations with the given
values. Implementations may add other names provided they cannot be interpreted as
@@ -5535,14 +5535,14 @@ with a backslash (\):
* \| : vertical line, U+007C
-* \<intraline whitespace>*<line ending> <intraline whitespace>* : nothing
+* \@svar{intraline whitespace}*@svar{line ending} @svar{intraline whitespace}* : nothing
-* \x<hex scalar value>; : specified character (note the terminating semi-colon).
+* \x@svar{hex scalar value}; : specified character (note the terminating semi-colon).
The result is unspecified if any other character in a string occurs after a backslash.
Except for a line ending, any character outside of an escape sequence stands for itself in
-the string literal. A line ending which is preceded by \<intraline whitespace> expands to
+the string literal. A line ending which is preceded by \@svar{intraline whitespace} expands to
nothing (along with any trailing intraline whitespace), and can be used to indent strings
for improved legibility. Any other line ending has the same effect as inserting a \n
character into the string.
@@ -5690,8 +5690,8 @@ lexicographically less than the longer string. However, it is also permitted to
natural ordering imposed by the implementation's internal representation of strings, or
a more complex locale-specific ordering.
-In all cases, a pair of strings must satisfy exactly one of string<?, string=?, and string>?,
-and must satisfy string<=? if and only if they do not satisfy string>? and string>=? if and
+In all cases, a pair of strings must satisfy exactly one of string@svar{?, string=?, and string}?,
+and must satisfy string@svar{=? if and only if they do not satisfy string}? and string>=? if and
only if they do not satisfy string<?.
The ``-ci'' procedures behave as if they applied string-foldcase to their arguments before
@@ -7870,7 +7870,7 @@ 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 @svar{letter}, <character name> and <mnemonic escape>; for example, #x1A and #X1a are
+of @svar{letter}, @svar{character name} and @svar{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.
@@ -7884,7 +7884,7 @@ This section describes how individual tokens(identifiers, numbers, etc.) are for
sequences of characters. The following sections describe how expressions and programs
are formed from sequences of tokens.
-<Intertoken space> can occur on either side of any token, but not within a token.
+@svar{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 @svar{delimiter} or by the
end of the input. So are dot, numbers, characters, and booleans. Identifiers that begin
@@ -7909,106 +7909,106 @@ sequence are equivalent to identifiers containing the corresponding character.
@svar{token} ⟶@svar{identifier} ∣@svar{boolean} ∣@svar{number} ∣@svar{character} ∣@svar{string}
∣( ∣) ∣#( ∣#u8( ∣' ∣` ∣, ∣,@ ∣.
-@svar{delimiter} ⟶@svar{whitespace} ∣<vertical line>
+@svar{delimiter} ⟶@svar{whitespace} ∣@svar{vertical line}
∣( ∣) ∣" ∣;
-<intraline whitespace> ⟶<space or tab>
-@svar{whitespace} ⟶<intraline whitespace> ∣<line ending>
-<vertical line> ⟶|
-<line ending> ⟶@svar{newline} ∣@svar{return} @svar{newline}
+@svar{intraline whitespace} ⟶@svar{space or tab}
+@svar{whitespace} ⟶@svar{intraline whitespace} ∣@svar{line ending}
+@svar{vertical line} ⟶|
+@svar{line ending} ⟶@svar{newline} ∣@svar{return} @svar{newline}
∣@svar{return}
@svar{comment} ⟶; ⟨all subsequent characters up to a
- line ending⟩ ∣<nested comment>
-∣#; <intertoken space> @svar{datum}
-<nested comment> ⟶#| <comment text>
-<comment cont>* |#
-<comment text> ⟶⟨character sequence not containing
+ line ending⟩ ∣@svar{nested comment}
+∣#; @svar{intertoken space} @svar{datum}
+@svar{nested comment} ⟶#| @svar{comment text}
+@svar{comment cont}* |#
+@svar{comment text} ⟶⟨character sequence not containing
#| or |#⟩
-<comment cont> ⟶<nested comment> <comment text>
+@svar{comment cont} ⟶@svar{nested comment} @svar{comment text}
@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.
@svar{atmosphere} ⟶@svar{whitespace} ∣@svar{comment} ∣@svar{directive}
-<intertoken space> ⟶@svar{atmosphere}*
+@svar{intertoken space} ⟶@svar{atmosphere}*
-Note that +i, -i and @svar{infnan} below are exceptions to the <peculiar identifier> rule; they are
+Note that +i, -i and @svar{infnan} below are exceptions to the @svar{peculiar identifier} rule; they are
parsed as numbers, not identifiers.
@svar{identifier} ⟶@svar{initial} @svar{subsequent}*
-∣<vertical line> <symbol element>* <vertical line>
-∣<peculiar identifier>
-@svar{initial} ⟶@svar{letter} ∣<special initial>
+∣@svar{vertical line} @svar{symbol element}* @svar{vertical line}
+∣@svar{peculiar identifier}
+@svar{initial} ⟶@svar{letter} ∣@svar{special initial}
@svar{letter} ⟶a ∣b ∣c ∣... ∣z
∣A ∣B ∣C ∣... ∣Z
-<special initial> ⟶! ∣$ ∣% ∣& ∣* ∣/ ∣: ∣< ∣=
+@svar{special initial} ⟶! ∣$ ∣% ∣& ∣* ∣/ ∣: ∣< ∣=
∣> ∣? ∣@ ∣^ ∣_ ∣~
@svar{subsequent} ⟶@svar{initial} ∣@svar{digit}
-∣<special subsequent>
+∣@svar{special subsequent}
@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> @svar{subsequent}*
-∣<explicit sign> . <dot subsequent> @svar{subsequent}*
-∣. <dot subsequent> @svar{subsequent}*
-<dot subsequent> ⟶<sign subsequent> ∣.
-<sign subsequent> ⟶@svar{initial} ∣<explicit sign> ∣@
-<symbol element> ⟶ <any character other than <vertical line> or \>
-∣<inline hex escape> ∣<mnemonic escape> ∣\|
+@svar{hex digit} ⟶@svar{digit} ∣a ∣b ∣c ∣d ∣e ∣f
+@svar{explicit sign} ⟶+ ∣-
+@svar{special subsequent} ⟶@svar{explicit sign} ∣. ∣@
+@svar{inline hex escape} ⟶\x@svar{hex scalar value};
+@svar{hex scalar value} ⟶@svar{hex digit}+
+@svar{mnemonic escape} ⟶\a ∣\b ∣\t ∣\n ∣\r
+@svar{peculiar identifier} ⟶@svar{explicit sign}
+∣@svar{explicit sign} @svar{sign subsequent} @svar{subsequent}*
+∣@svar{explicit sign} . @svar{dot subsequent} @svar{subsequent}*
+∣. @svar{dot subsequent} @svar{subsequent}*
+@svar{dot subsequent} ⟶@svar{sign subsequent} ∣.
+@svar{sign subsequent} ⟶@svar{initial} ∣@svar{explicit sign} ∣@
+@svar{symbol element} ⟶ @svar{any character other than <vertical line} or \>
+∣@svar{inline hex escape} ∣@svar{mnemonic escape} ∣\|
@svar{boolean} ⟶#t ∣#f ∣#true ∣#false
-@svar{character} ⟶#\ <any character>
-∣#\ <character name>
-∣#\x<hex scalar value>
-<character name> ⟶alarm ∣backspace ∣delete
+@svar{character} ⟶#\ @svar{any character}
+∣#\ @svar{character name}
+∣#\x@svar{hex scalar value}
+@svar{character name} ⟶alarm ∣backspace ∣delete
∣escape ∣newline ∣null ∣return ∣space ∣tab
-@svar{string} ⟶" <string element>* "
-<string element> ⟶<any character other than " or \>
-∣<mnemonic escape> ∣\" ∣\\ ∣\|
-∣\<intraline whitespace>*<line ending>
- <intraline whitespace>*
-∣<inline hex escape>
+@svar{string} ⟶" @svar{string element}* "
+@svar{string element} ⟶@svar{any character other than " or \}
+∣@svar{mnemonic escape} ∣\" ∣\\ ∣\|
+∣\@svar{intraline whitespace}*@svar{line ending}
+ @svar{intraline whitespace}*
+∣@svar{inline hex escape}
@svar{bytevector} ⟶#u8(@svar{byte}*)
-@svar{byte} ⟶<any exact integer between 0 and 255>
+@svar{byte} ⟶@svar{any exact integer between 0 and 255}
-@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
-2>, <decimal 8>, and <decimal 16>, which means that numbers containing decimal points
+@svar{number} ⟶@svar{num 2} ∣@svar{num 8}
+∣@svar{num 10} ∣@svar{num 16}
+The following rules for @svar{num R}, @svar{complex R}, @svar{real R}, @svar{ureal R}, @svar{uinteger R}, and
+@svar{prefix R} are implicitly replicated for R = 2, 8, 10, and 16. There are no rules for <decimal
+2>, @svar{decimal 8}, and @svar{decimal 16}, which means that numbers containing decimal points
or exponents are always in decimal radix. Although not shown below, all alphabetic
characters used in the grammar of numbers can appear in either upper or lower case.
-<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> @svar{infnan} i
-∣+ <ureal R> i ∣- <ureal R> i
+@svar{num R} ⟶@svar{prefix R} @svar{complex R}
+@svar{complex R} ⟶@svar{real R} ∣@svar{real R} @ @svar{real R}
+∣@svar{real R} + @svar{ureal R} i ∣@svar{real R} - @svar{ureal R} i
+∣@svar{real R} + i ∣@svar{real R} - i ∣@svar{real R} @svar{infnan} i
+∣+ @svar{ureal R} i ∣- @svar{ureal R} i
∣@svar{infnan} i ∣+ i ∣- i
-<real R> ⟶@svar{sign} <ureal R>
+@svar{real R} ⟶@svar{sign} @svar{ureal R}
∣@svar{infnan}
-<ureal R> ⟶<uinteger R>
-∣<uinteger R> / <uinteger R>
-∣<decimal R>
-<decimal 10> ⟶<uinteger 10> @svar{suffix}
-∣. <digit 10>+ @svar{suffix}
-∣<digit 10>+ . <digit 10>* @svar{suffix}
-<uinteger R> ⟶<digit R>+
-<prefix R> ⟶<radix R> @svar{exactness}
-∣@svar{exactness} <radix R>
+@svar{ureal R} ⟶@svar{uinteger R}
+∣@svar{uinteger R} / @svar{uinteger R}
+∣@svar{decimal R}
+@svar{decimal 10} ⟶@svar{uinteger 10} @svar{suffix}
+∣. @svar{digit 10}+ @svar{suffix}
+∣@svar{digit 10}+ . @svar{digit 10}* @svar{suffix}
+@svar{uinteger R} ⟶@svar{digit R}+
+@svar{prefix R} ⟶@svar{radix R} @svar{exactness}
+∣@svar{exactness} @svar{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
+∣@svar{exponent marker} @svar{sign} @svar{digit 10}+
+@svar{exponent marker} ⟶e
@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> ⟶@svar{digit}
-<digit 16> ⟶<digit 10> ∣a ∣b ∣c ∣d ∣e ∣f
+@svar{exactness} ⟶@svar{empty} ∣#i∣#e@svar{radix 2} ⟶#b@svar{radix 8} ⟶#o@svar{radix 10} ⟶@svar{empty} ∣#d
+@svar{radix 16} ⟶#x@svar{digit 2} ⟶0 ∣1
+@svar{digit 8} ⟶0 ∣1 ∣2 ∣3 ∣4 ∣5 ∣6 ∣7
+@svar{digit 10} ⟶@svar{digit}
+@svar{digit 16} ⟶@svar{digit 10} ∣a ∣b ∣c ∣d ∣e ∣f
@node Expressions (formal)
@subsection Expressions (formal)
@@ -8016,17 +8016,17 @@ characters used in the grammar of numbers can appear in either upper or lower ca
@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{datum} ⟶@svar{simple datum} ∣@svar{compound datum}
∣@svar{label} = @svar{datum} ∣@svar{label} #
-<simple datum> ⟶@svar{boolean} ∣@svar{number}
+@svar{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{compound datum} ⟶@svar{list} ∣@svar{vector} ∣@svar{abbreviation}
@svar{list} ⟶(@svar{datum}*) ∣(@svar{datum}+ . @svar{datum})
-@svar{abbreviation} ⟶<abbrev prefix> @svar{datum}
-<abbrev prefix> ⟶' ∣` ∣, ∣,@
+@svar{abbreviation} ⟶@svar{abbrev prefix} @svar{datum}
+@svar{abbrev prefix} ⟶' ∣` ∣, ∣,@
@svar{vector} ⟶#(@svar{datum}*)
-@svar{label} ⟶# <uinteger 10>
+@svar{label} ⟶# @svar{uinteger 10}
@node Quasiquotations
@subsection Quasiquotations
@@ -8037,22 +8037,22 @@ them have been redefined or shadowed.
@svar{expression} ⟶@svar{identifier}
∣@svar{literal}
-∣<procedure call>
-∣<lambda expression>
+∣@svar{procedure call}
+∣@svar{lambda expression}
∣@svar{conditional}
∣@svar{assignment}
-∣<derived expression>
-∣<macro use>
-∣<macro block>
+∣@svar{derived expression}
+∣@svar{macro use}
+∣@svar{macro block}
∣@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{procedure call} ⟶(@svar{operator} @svar{operand}*)
@svar{operator} ⟶@svar{expression}
@svar{operand} ⟶@svar{expression}
-<lambda expression> ⟶(lambda @svar{formals} @svar{body})
+@svar{lambda expression} ⟶(lambda @svar{formals} @svar{body})
@svar{formals} ⟶(@svar{identifier}*) ∣@svar{identifier}
∣(@svar{identifier}+ . @svar{identifier})
@svar{body} ⟶@svar{definition}* @svar{sequence}
@@ -8063,57 +8063,57 @@ them have been redefined or shadowed.
@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 @svar{sequence}))
+@svar{derived expression} ⟶ (cond @svar{cond clause}+)
+∣(cond @svar{cond clause}* (else @svar{sequence}))
∣(case @svar{expression}
- <case clause>+)
+ @svar{case clause}+)
∣(case @svar{expression}
- <case clause>*
+ @svar{case clause}*
(else @svar{sequence}))
∣(case @svar{expression}
- <case clause>*
+ @svar{case clause}*
(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})
+∣(let (@svar{binding spec}*) @svar{body})
+∣(let @svar{identifier} (@svar{binding spec}*) @svar{body})
+∣(let* (@svar{binding spec}*) @svar{body})
+∣(letrec (@svar{binding spec}*) @svar{body})
+∣(letrec* (@svar{binding spec}*) @svar{body})
+∣(let-values (@svar{mv binding spec}*) @svar{body})
+∣(let*-values (@svar{mv binding spec}*) @svar{body})
∣(begin @svar{sequence})
-∣(do (<iteration spec>*)
- (@svar{test} <do result>)
+∣(do (@svar{iteration spec}*)
+ (@svar{test} @svar{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})
+∣(guard (@svar{identifier} @svar{cond clause}*) @svar{body})
∣@svar{quasiquotation}
-∣(case-lambda <case-lambda clause>*)
-<cond clause> ⟶(@svar{test} @svar{sequence})
+∣(case-lambda @svar{case-lambda clause}*)
+@svar{cond clause} ⟶(@svar{test} @svar{sequence})
∣(@svar{test})
∣(@svar{test} => @svar{recipient})
@svar{recipient} ⟶@svar{expression}
-<case clause> ⟶((@svar{datum}*) @svar{sequence})
+@svar{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{binding spec} ⟶(@svar{identifier} @svar{expression})
+@svar{mv binding spec} ⟶(@svar{formals} @svar{expression})
+@svar{iteration spec} ⟶(@svar{identifier} @svar{init} @svar{step})
∣(@svar{identifier} @svar{init})
-<case-lambda clause> ⟶(@svar{formals} @svar{body})
+@svar{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{do result} ⟶@svar{sequence} ∣@svar{empty}
+@svar{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{macro block} ⟶ (let-syntax (@svar{syntax spec}*) @svar{body})
+∣(letrec-syntax (@svar{syntax spec}*) @svar{body})
+@svar{syntax spec} ⟶(@svar{keyword} @svar{transformer spec})
@svar{includer} ⟶ ∣(include @svar{string}+)
∣(include-ci @svar{string}+)
@@ -8124,27 +8124,27 @@ 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.
-@svar{quasiquotation} ⟶<quasiquotation 1>
-<qq template 0> ⟶@svar{expression}
-<quasiquotation D> ⟶`<qq template D>
-∣(quasiquote <qq template D>)
-<qq template D> ⟶<simple datum>
-∣<list qq template D>
-∣<vector qq template D>
-∣<unquotation D>
-<list qq template D> ⟶(<qq template or splice D>*)
-∣(<qq template or splice D>+ . <qq template D>)
-∣'<qq template D>
-∣<quasiquotation D + 1>
-<vector qq template D> ⟶#(<qq template or splice D>*)
-<unquotation D> ⟶,<qq template D−1>
-∣(unquote <qq template D−1>)
-<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 @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 @svar{unquotation} or <splicing unquotation D> takes precedence.
+@svar{quasiquotation} ⟶@svar{quasiquotation 1}
+@svar{qq template 0} ⟶@svar{expression}
+@svar{quasiquotation D} ⟶`@svar{qq template D}
+∣(quasiquote @svar{qq template D})
+@svar{qq template D} ⟶@svar{simple datum}
+∣@svar{list qq template D}
+∣@svar{vector qq template D}
+∣@svar{unquotation D}
+@svar{list qq template D} ⟶(@svar{qq template or splice D}*)
+∣(@svar{qq template or splice D}+ . @svar{qq template D})
+∣'@svar{qq template D}
+∣@svar{quasiquotation D + 1}
+@svar{vector qq template D} ⟶#(@svar{qq template or splice D}*)
+@svar{unquotation D} ⟶,@svar{qq template D−1}
+∣(unquote @svar{qq template D−1})
+@svar{qq template or splice D} ⟶@svar{qq template D}
+∣@svar{splicing unquotation D}
+@svar{splicing unquotation D} ⟶,@@@svar{qq template D−1}
+∣(unquote-splicing @svar{qq template D−1}) In @svar{quasiquotation}s, a @svar{list qq template D} can
+sometimes be confused with either an @svar{unquotation D} or a @svar{splicing unquotation D}.
+The interpretation as an @svar{unquotation} or @svar{splicing unquotation D} takes precedence.
@node Programs and definitions
@subsection Programs and definitions
@@ -8152,11 +8152,11 @@ The interpretation as an @svar{unquotation} or <splicing unquotation D> takes pr
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 (@svar{identifier}*) <syntax rule>*)
+@svar{transformer spec} ⟶ (syntax-rules (@svar{identifier}*) @svar{syntax rule}*)
∣(syntax-rules @svar{identifier} (@svar{identifier}*)
- <syntax rule>*)
-<syntax rule> ⟶(@svar{pattern} @svar{template})
-@svar{pattern} ⟶<pattern identifier>
+ @svar{syntax rule}*)
+@svar{syntax rule} ⟶(@svar{pattern} @svar{template})
+@svar{pattern} ⟶@svar{pattern identifier}
∣@svar{underscore}
∣(@svar{pattern}*)
∣(@svar{pattern}+ . @svar{pattern})
@@ -8165,47 +8165,47 @@ a list pattern, not a vector pattern or an identifier pattern.
. @svar{pattern})
∣#(@svar{pattern}*)
∣#(@svar{pattern}* @svar{pattern} @svar{ellipsis} @svar{pattern}*)
-∣<pattern datum>
-<pattern datum> ⟶@svar{string}
+∣@svar{pattern datum}
+@svar{pattern datum} ⟶@svar{string}
∣@svar{character}
∣@svar{boolean}
∣@svar{number}
∣@svar{bytevector}
-@svar{template} ⟶<pattern identifier>
-∣(<template element>*)
-∣(<template element>+ . @svar{template})
-∣#(<template element>*)
-∣<template datum>
-<template element> ⟶@svar{template}
+@svar{template} ⟶@svar{pattern identifier}
+∣(@svar{template element}*)
+∣(@svar{template element}+ . @svar{template})
+∣#(@svar{template element}*)
+∣@svar{template datum}
+@svar{template element} ⟶@svar{template}
∣@svar{template} @svar{ellipsis}
-<template datum> ⟶<pattern datum>
-<pattern identifier> ⟶<any identifier except ...>
-@svar{ellipsis} ⟶<an identifier defaulting to ...>
-@svar{underscore} ⟶<the identifier _>
+@svar{template datum} ⟶@svar{pattern datum}
+@svar{pattern identifier} ⟶@svar{any identifier except ...}
+@svar{ellipsis} ⟶@svar{an identifier defaulting to ...}
+@svar{underscore} ⟶@svar{the identifier _}
@node Libraries (formal)
@subsection Libraries (formal)
-@svar{program} ⟶ <import declaration>+
-<command or definition>+
-<command or definition> ⟶@svar{command}
+@svar{program} ⟶ @svar{import declaration}+
+@svar{command or definition}+
+@svar{command or definition} ⟶@svar{command}
∣@svar{definition}
-∣(begin <command or definition>+)
+∣(begin @svar{command or definition}+)
@svar{definition} ⟶(define @svar{identifier} @svar{expression})
-∣(define (@svar{identifier} <def formals>) @svar{body})
-∣<syntax definition>
+∣(define (@svar{identifier} @svar{def formals}) @svar{body})
+∣@svar{syntax definition}
∣(define-values @svar{formals} @svar{body})
∣(define-record-type @svar{identifier}
- @svar{constructor} @svar{identifier} <field spec>*)
+ @svar{constructor} @svar{identifier} @svar{field spec}*)
∣(begin @svar{definition}*)
-<def formals> ⟶@svar{identifier}*
+@svar{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{constructor} ⟶(@svar{identifier} @svar{field name}*)
+@svar{field spec} ⟶(@svar{field name} @svar{accessor})
+∣(@svar{field name} @svar{accessor} @svar{mutator})
+@svar{field name} ⟶@svar{identifier}
@svar{accessor} ⟶@svar{identifier}
@svar{mutator} ⟶@svar{identifier}
-<syntax definition> ⟶ (define-syntax @svar{keyword} <transformer spec>)
+@svar{syntax definition} ⟶ (define-syntax @svar{keyword} @svar{transformer spec})
@node Formal semantics
@section Formal semantics
