commit 6e70c37ccd035a4e0df7b8c33fba8305595f2759
parent 0ced04d836af9067517e0bb55b4973a423107c6c
Author: Wolfgang Corcoran-Mathe <wcm@sigwinch.xyz>
Date: Fri, 2 Feb 2024 00:00:29 -0500
Program structure: Texify.
Diffstat:
1 file changed, 264 insertions(+), 152 deletions(-)
diff --git a/doc/r7rs-small/program-structure.texinfo b/doc/r7rs-small/program-structure.texinfo
@@ -6,7 +6,7 @@
* Import declarations::
* Variable definitions::
* Syntax definitions::
-* Record-type definitions::
+* Record type definitions::
* Libraries::
* The REPL::
@end menu
@@ -17,16 +17,16 @@
A Scheme program consists of one or more import declarations followed by a sequence
of expressions and definitions. Import declarations specify the libraries on which a
program or library depends; a subset of the identifiers exported by the libraries are made
-available to the program. Expressions are described in chapter 4. Definitions are either
+available to the program. Expressions are described in @ref{Expressions}. 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 @svar{program} and at the beginning of a
@svar{body}.
-At the outermost level of a program, (begin @svar{expression or definition1} @dots{}) is equivalent to
+At the outermost level of a program, @code{(begin }@svar{expression or definition@sub{1}} @dots{}@code{)} 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.
+@svar{definition@sub{1}} @dots{}) is equivalent to the sequence @svar{definition@sub{1}} @dots{}. Macros can expand into
+such begin forms. For the formal definition, see @ref{Sequencing}.
Import declarations and definitions cause bindings to be created in the global
environment or modify the value of existing global bindings. The initial environment of a
@@ -47,44 +47,64 @@ from the name of a library to its location in the file system.
An import declaration takes the following form:
-(import @svar{import-set} @dots{})
+@example
+(import @r{@svar{import-set} @dots{}})
+@end example
+
An import declaration provides a way to import identifiers exported by a library. Each
@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:
-* @svar{library name}
+@itemize
+
+@item
+@svar{library name}
+
+@item
+@code{(only }@svar{import set} @svar{identifier} @dots{}@code{)}
-* (only @svar{import set} @svar{identifier} @dots{})
+@item
+@code{(except }@svar{import set} @svar{identifier} @dots{})
-* (except @svar{import set} @svar{identifier} @dots{})
+@item
+@code{(prefix }@svar{import set} @svar{identifier})
-* (prefix @svar{import set} @svar{identifier})
+@item
+@code{(rename }@svar{import set}
+ @code{(}@svar{identifier@sub{1}} @svar{identifier@sub{2}}@code{)} @dots{}@code{)}
-* (rename @svar{import set}
- (@svar{identifier1} @svar{identifier2}) @dots{})
+@end itemize
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
@svar{import set} forms modify this set as follows:
-* only produces a subset of the given @svar{import set} including only the listed identifiers
+@itemize
+
+@item
+@code{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 @svar{import set}, excluding the listed identifiers
+@item
+@code{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 @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
+@item
+@code{rename} modifies the given @svar{import set}, replacing each instance of @svar{identifier@sub{1}} with
+ @svar{identifier@sub{2}}. It is an error if any of the listed @svar{identifier@sub{1}}s are not found in the original
set.
-* prefix automatically renames all identifiers in the given @svar{import set}, prefixing each
+@item
+@code{prefix} automatically renames all identifiers in the given @svar{import set}, prefixing each
with the specified @svar{identifier}.
+@end itemize
+
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
-definition or with set!, or to refer to an identifier before it is imported. However, a REPL
+definition or with @code{set!}, or to refer to an identifier before it is imported. However, a REPL
should permit these actions.
@node Variable definitions
@@ -93,33 +113,39 @@ 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 @svar{variable} @svar{expression})
+@itemize
-* (define (@svar{variable} @svar{formals}) @svar{body})
+@item
+@code{(define }@svar{variable} @svar{expression}@code{)}
+
+@item
+@code{(define }(@svar{variable} @svar{formals}@code{)} @svar{body}@code{)}
@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 @svar{variable}
- (lambda (@svar{formals}) @svar{body})).
+(define @r{@svar{variable}}
+ (lambda (@r{@svar{formals}}) @r{@svar{body}}))@r{.}
@end example
-
-* (define (@svar{variable} . @svar{formal}) @svar{body})
+@item
+@code{(define (}@svar{variable} @code{.} @svar{formal}@code{)} @svar{body}@code{)}
@svar{Formal} is a single variable. This form is equivalent to
@example
-(define @svar{variable}
- (lambda @svar{formal} @svar{body})).
+(define @r{@svar{variable}}
+ (lambda @r{@svar{formal}} @r{@svar{body}}))@r{.}
@end example
+@end itemize
+
@menu
* Top level definitions::
* Internal definitions::
-* Multiple-value definitions::
+* Multiple value definitions::
@end menu
@node Top level definitions
@@ -127,41 +153,57 @@ them. The simplest kind of variable definition takes one of the following forms:
At the outermost level of a program, a definition
-(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.
+@example
+(define @r{@svar{variable} @svar{expression}})
+@end example
+
+has essentially the same effect as the assignment
+expression
+
+@example
+(set! @r{@svar{variable} @svar{expression}})
+@end example
+
+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.
+error to perform a @code{set!} on an unbound variable.
@example
(define add3
(lambda (x) (+ x 3)))
-(add3 3) @result{} 6
+(add3 3) @result{} 6
(define first car)
-(first '(1 2)) @result{} 1
+(first '(1 2)) @result{} 1
@end example
@node Internal definitions
@subsection Internal definitions
-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
-@svar{body}. That is, @svar{variable} is bound rather than assigned, and the region of the binding is
-the entire @svar{body}. For example,
+Definitions can occur at the
+beginning of a @svar{body} (that is, the body of a @code{lambda},
+@code{let}, @code{let*}, @code{letrec}, @code{letrec*},
+@code{let-values}, @code{let*-values}, @code{let-syntax}, @code{letrec-syntax},
+@code{parameterize}, @code{guard}, or @code{case-lambda}). Note that
+such a body might not be apparent until after expansion of other syntax.
+Such definitions are known as @dfn{internal definitions}
+as opposed to the global definitions described above.
+The variables defined by internal definitions are local to the
+@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
(let ((x 5))
(define foo (lambda (y) (bar x y)))
(define bar (lambda (a b) (+ (* a b) a)))
- (foo (+ x 3))) @result{} 45
+ (foo (+ x 3))) @result{} 45
@end example
-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
+An expanded @svar{body} containing internal definitions
+can always be
+converted into a completely equivalent @code{letrec*} expression. For
+example, the @code{let} expression in the above example is equivalent
+to
@example
(let ((x 5))
@@ -170,29 +212,29 @@ expression in the above example is equivalent to
(foo (+ x 3))))
@end example
-Just as for the equivalent letrec* expression, it is an error if it is not
+Just as for the equivalent @code{letrec*} expression, it is an error if it is not
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 @svar{body}.
-Wherever an internal definition can occur, (begin @svar{definition1} @dots{}) is equivalent to the
-sequence of definitions that form the body of the begin.
+Wherever an internal definition can occur, @code{(begin }@svar{definition@sub{1}} @dots{}@code{)} is equivalent to the
+sequence of definitions that form the body of the @code{begin}.
-@node Multiple-value definitions
+@node Multiple value definitions
@subsection Multiple-value definitions
-Another kind of definition is provided by define-values, which creates multiple definitions
+Another kind of definition is provided by @code{define-values}, which creates multiple definitions
from a single expression returning multiple values. It is allowed wherever define is
allowed.
-syntax: (define-values @svar{formals} @svar{expression})
+@deffn syntax define-values @svar{formals} @svar{expression}
It is an error if a variable appears more than once in the set of @svar{formals}.
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
+the same way that the @svar{formals} in a @code{lambda} expression are matched to the arguments in
a procedure call.
@example
@@ -201,24 +243,28 @@ a procedure call.
(let ()
(define-values (x y) (values 1 2))
- (+ x y)) @result{} 3
+ (+ x y)) @result{} 3
@end example
+@end deffn
+
@node Syntax definitions
@section Syntax definitions
Syntax definitions have this form:
-(define-syntax @svar{keyword} @svar{transformer spec})
+@example
+(define-syntax @r{@svar{keyword} @svar{transformer spec}})
+@end example
-@svar{Keyword} is an identifier, and the @svar{transformer spec} is an instance of syntax-rules. Like
+@svar{Keyword} is an identifier, and the @svar{transformer spec} is an instance of @code{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
+If the @code{define-syntax} occurs at the outermost level, then the global syntactic environment
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
+@dfn{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.
@@ -231,7 +277,7 @@ precedes an inner definition will not apply an outer definition.
(set! a b)
(set! b tmp)))))
(swap! x y)
- (list x y)) @result{} (2 1)
+ (list x y)) @result{} (2 1)
@end example
Macros can expand into definitions in any context that permits them. However, it is an
@@ -259,55 +305,80 @@ For example, the following are errors:
(plus foo x)))
@end example
-@node Record-type definitions
+@node Record type definitions
@section Record-type definitions
-Record-type definitions are used to introduce new data types, called record types. Like other
-definitions, they can appear either at the outermost level or in a body. The values of a
-record type are called records and are aggregations of zero or more fields, each of which
-holds a single location. A predicate, a constructor, and field accessors and mutators are
-defined for each record type.
+@dfn{Record-type definitions} are used to introduce new data types, called
+@dfn{record types}.
+Like other definitions, they can appear either at the outermost level or in a body.
+The values of a record type are called @dfn{records} and are
+aggregations of zero or more @dfn{fields}, each of which holds a single location.
+A predicate, a constructor, and field accessors and
+mutators are defined for each record type.
-syntax: (define-record-type @svar{name}
- @svar{constructor} @svar{pred} @svar{field} @dots{})
+@deffn syntax define-record-type @svar{name} @svar{constructor} @svar{pred} @svar{field}@dots{}
Syntax: @svar{name} and @svar{pred} are identifiers. The @svar{constructor} is of the form
-(@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
+@display
+@code{(}@svar{constructor name} @svar{field name} @dots{}@code{)}
+@end display
+
+and each @svar{field} is either of the form
+
+@display
+@code{(}@svar{field name} @svar{accessor name}@code{)}
+@end display
+
+or of the form
+
+@display
+@code{(}@svar{field name} @svar{accessor name} @svar{modifier name}@code{)}
+@end display
+
+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.
-The define-record-type construct is generative: each use creates a new record type that is
+The @code{define-record-type} construct is generative: each use creates a new record type that is
distinct from all existing types, including Scheme's predefined types and other record
types---even record types of the same name or structure.
-An instance of define-record-type is equivalent to the following definitions:
+An instance of @code{define-record-type} is equivalent to the following definitions:
-* @svar{name} is bound to a representation of the record type itself. This may be a run-time
+@itemize
+
+@item
+@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.
-* @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
+@item
+@svar{constructor name} is bound to a procedure that takes as many arguments as there
+ are @svar{field name}s in the @code{(}@svar{constructor name} @dots{}@code{)} 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 @svar{constructor name} and #f for everything else.
+@item
+@svar{pred} is bound to a predicate that returns @code{#t} when given a value returned by the
+ procedure bound to @svar{constructor name} and @code{#f} for everything else.
-* Each @svar{accessor name} is bound to a procedure that takes a record of type @svar{name} and
+@item
+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 @svar{modifier name} is bound to a procedure that takes a record of type @svar{name} and
+@item
+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.
+@end itemize
+
For instance, the following record-type definition
@example
@@ -318,8 +389,9 @@ For instance, the following record-type definition
(y kdr))
@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 @svar{pare}.
+defines @code{kons} to be a constructor, @code{kar} and @code{kdr}
+to be accessors, @code{set-kar!} to be a modifier, and @code{pare?}
+to be a predicate for instances of @code{<pare>}.
@example
(pare? (kons 1 2)) @result{} #t
@@ -331,6 +403,8 @@ and pare? to be a predicate for instances of @svar{pare}.
(kar k)) @result{} 3
@end example
+@end deffn
+
@node Libraries
@section Libraries
@@ -348,85 +422,117 @@ semantics for libraries.
A library definition takes the following form:
-(define-library @svar{library name}
- @svar{library declaration} @dots{})
+@display
+@code{(define-library }@svar{library name}
+ @svar{library declaration} @dots{}@code{)}
+@end display
+
@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
+Libraries whose first identifier is @code{scheme} are reserved for use by this report and future
+versions of this report. Libraries whose first identifier is @code{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 | \ ? * @svar{ " : } + [ ] / or
+for identifiers in library names to contain any of the characters @code{| \ ? * < " : > + [ ] /} or
control characters after escapes are expanded.
A @svar{library declaration} is any of:
-* (export @svar{export spec} @dots{})
+@itemize
-* (import @svar{import set} @dots{})
+@item
+@code{(export }@svar{export spec} @dots{}@code{)}
-* (begin @svar{command or definition} @dots{})
+@item
+@code{(import }@svar{import set} @dots{}@code{)}
-* (include @svar{filename1} @svar{filename2} @dots{})
+@item
+@code{(begin }@svar{command or definition} @dots{}@code{)}
-* (include-ci @svar{filename1} @svar{filename2} @dots{})
+@item
+@code{(include }@svar{filename@sub{1}} @svar{filename@sub{2}} @dots{}@code{)}
-* (include-library-declarations @svar{filename1} @svar{filename2} @dots{})
+@item
+@code{(include-ci }@svar{filename@sub{1}} @svar{filename@sub{2}} @dots{}@code{)}
-* (cond-expand @svar{ce-clause1} @svar{ce-clause2} @dots{})
+@item
+@code{(include-library-declarations }@svar{filename@sub{1}} @svar{filename@sub{2}} @dots{}@code{)}
-An export declaration specifies a list of identifiers which can be made visible to other
+@item
+@code{(cond-expand }@svar{ce-clause@sub{1}} @svar{ce-clause@sub{2}} @dots{}@code{)}
+
+@end itemize
+
+An @code{export} declaration specifies a list of identifiers which can be made visible to other
libraries or programs. An @svar{export spec} takes one of the following forms:
-* @svar{identifier}
+@itemize
+
+@item
+@svar{identifier}
+
+@item
+@code{(rename }@svar{identifier@sub{1}} @svar{identifier@sub{2}}@code{)}
-* (rename @svar{identifier1} @svar{identifier2})
+@end itemize
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,
-using @svar{identifier2} as the external name.
+binding within the library. A @code{rename} spec exports the binding defined within or imported
+into the library and named by @svar{identifier@sub{1}} in each (@svar{identifier@sub{1}} @svar{identifier@sub{2}}) pairing,
+using @svar{identifier@sub{2}} as the external name.
-An import declaration provides a way to import the identifiers exported by another
+An @code{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
-or at the REPL (see section 5.2).
-
-The begin, include, and include-ci declarations are used to specify the body of the library.
-They have the same syntax and semantics as the corresponding expression types. This
-form of begin is analogous to, but not the same as, the two types of begin defined in
-section 4.2.3.
-
-The include-library-declarations declaration is similar to include except that the contents
-of the file are spliced directly into the current library definition. This can be used, for
-example, to share the same export declaration among multiple libraries as a simple form
-of library interface.
-
-The cond-expand declaration has the same syntax and semantics as the cond-expand
-expression type, except that it expands to spliced-in library declarations rather than
-expressions enclosed in begin.
-
-One possible implementation of libraries is as follows: After all cond-expand library
-declarations are expanded, a new environment is constructed for the library consisting of
-all imported bindings. The expressions from all begin, include and include-ci library
-declarations are expanded in that environment in the order in which they occur in the
-library. Alternatively, cond-expand and import declarations may be processed in left to
-right order interspersed with the processing of other declarations, with the environment
-growing as imported bindings are added to it by each import declaration.
-
-When a library is loaded, its expressions are executed in textual order. If a library's
-definitions are referenced in the expanded form of a program or library body, then that
-library must be loaded before the expanded program or library body is evaluated. This
-rule applies transitively. If a library is imported by more than one program or library, it
-may possibly be loaded additional times.
-
-Similarly, during the expansion of a library (foo), if any syntax keywords imported from
-another library (bar) are needed to expand the library, then the library (bar) must be
-expanded and its syntax definitions evaluated before the expansion of (foo).
-
-Regardless of the number of times that a library is loaded, each program or library that
-imports bindings from a library must do so from a single loading of that library,
-regardless of the number of import declarations in which it appears. That is, (import (only
-(foo) a)) followed by (import (only (foo) b)) has the same effect as (import (only (foo) a b)).
+or at the REPL (see @ref{Import declarations}).
+
+The @code{begin}, @code{include}, and @code{include-ci} declarations are
+used to specify the body of
+the library. They have the same syntax and semantics as the corresponding
+expression types.
+This form of @code{begin} is analogous to, but not the same as, the
+two types of @code{begin} defined in @ref{Sequencing}.
+
+The @code{include-library-declarations} declaration is similar to
+@code{include} except that the contents of the file are spliced directly into the
+current library definition. This can be used, for example, to share the
+same @code{export} declaration among multiple libraries as a simple
+form of library interface.
+
+The @code{cond-expand} declaration has the same syntax and semantics as
+the @code{cond-expand} expression type, except that it expands to
+spliced-in library declarations rather than expressions enclosed in @code{begin}.
+
+One possible implementation of libraries is as follows:
+After all @code{cond-expand} library declarations are expanded, a new
+environment is constructed for the library consisting of all
+imported bindings. The expressions
+from all @code{begin}, @code{include} and @code{include-ci}
+library declarations are expanded in that environment in the order in which
+they occur in the library.
+Alternatively, @code{cond-expand} and @code{import} declarations may be processed
+in left to right order interspersed with the processing of other
+declarations, with the environment growing as imported bindings are
+added to it by each @code{import} declaration.
+
+When a library is loaded, its expressions are executed
+in textual order.
+If a library's definitions are referenced in the expanded form of a
+program or library body, then that library must be loaded before the
+expanded program or library body is evaluated. This rule applies
+transitively. If a library is imported by more than one program or
+library, it may possibly be loaded additional times.
+
+Similarly, during the expansion of a library @code{(foo)}, if any syntax
+keywords imported from another library @code{(bar)} are needed to expand
+the library, then the library @code{(bar)} must be expanded and its syntax
+definitions evaluated before the expansion of @code{(foo)}.
+
+Regardless of the number of times that a library is loaded, each
+program or library that imports bindings from a library must do so from a
+single loading of that library, regardless of the number of import
+declarations in which it appears.
+That is, @code{(import (only (foo) a))} followed by @code{(import (only (foo) b))}
+has the same effect as @code{(import (only (foo) a b))}.
@node Library example
@subsection Library example
@@ -528,21 +634,27 @@ import the base library.
@node The REPL
@section The REPL
-Implementations may provide an interactive session called a REPL (Read-Eval-Print Loop),
-where import declarations, expressions and definitions can be entered and evaluated one
-at a time. For convenience and ease of use, the global Scheme environment in a REPL
-must not be empty, but must start out with at least the bindings provided by the base
-library. This library includes the core syntax of Scheme and generally useful procedures
-that manipulate data. For example, the variable abs is bound to a procedure of one
-argument that computes the absolute value of a number, and the variable + is bound to a
-procedure that computes sums. The full list of (scheme base) bindings can be found in
-Appendix A.
-
-Implementations may provide an initial REPL environment which behaves as if all possible
-variables are bound to locations, most of which contain unspecified values. Top level REPL
-definitions in such an implementation are truly equivalent to assignments, unless the
-identifier is defined as a syntax keyword.
-
-An implementation may provide a mode of operation in which the REPL reads its input
-from a file. Such a file is not, in general, the same as a program, because it can contain
-import declarations in places other than the beginning.
+Implementations may provide an interactive session called a
+@dfn{REPL} (Read-Eval-Print Loop), where import declarations,
+expressions and definitions can be
+entered and evaluated one at a time. For convenience and ease of use,
+the global Scheme environment in a REPL
+must not be empty, but must start out with at least the bindings provided by the
+base library. This library includes the core syntax of Scheme
+and generally useful procedures that manipulate data. For example, the
+variable @code{abs} is bound to a
+procedure of one argument that computes the absolute value of a
+number, and the variable @code{+} is bound to a procedure that computes
+sums. The full list of @code{(scheme base)} bindings can be found in
+@ref{Appendix A}.
+
+Implementations may provide an initial REPL environment
+which behaves as if all possible variables are bound to locations, most of
+which contain unspecified values. Top level REPL definitions in
+such an implementation are truly equivalent to assignments,
+unless the identifier is defined as a syntax keyword.
+
+An implementation may provide a mode of operation in which the REPL
+reads its input from a file. Such a file is not, in general, the same
+as a program, because it can contain import declarations in places other than
+the beginning.
