RScheme is a language with modules, and modules form the basis of a program's structure. That is, a program is simply a collection of modules, together with an entry point. Some modules are required because the runtime system and application environment depend on their presence. Most modules, however, are optional, and are only included when necessary.
A module is primarily a name space for variables. That is, a module contains a particular set of mappings from names (identifiers) to variables (program definitions). A module specifies its interface in the form of its set of exported variables. Modules also specify which other modules they depend on, or import.
The content of a module is structured as a set of definitions plus a sequence of top-level expressions.
Definitions are used to create module variables, while top-level expressions are used to provide code to be executed when the module is loaded.
When RScheme starts up, by default it presents an interactive environment known as the read-eval-print loop, or REPL for short. It is so called because the basic behavior of the REPL is to read an expression, evaluate it, print the result of the evaluation (that is, the value returned by the expression), and loop back to the beginning to do it again. Unlike some interactive language environments, RScheme doesn't interpret the expressions in order to evaluate them. Instead, the expressions are compiled to bytecodes and the compile code is executed by the usual bytecode interpreter.
The evaluation of expressions by the REPL is intended to simulate the occurrence of forms in a module.
The system has access to several modules that are suitable for normal interactive use. The default module for interactive use is the user module. Also available is the usual-inlines module.
Note that although we go to great lengths to simulate module semantics in interaction, receiving an expression at a time makes this simulation imperfect. For example, when all the definitions for a module are conceptually seen at once, top-level expressions can reference variables that are defined later in the source of the module. This is impractical in the interactive environment because the user expects the expressions to be executed as soon as they are entered; the user would find it disturbing if the system waited for later definitions to be encountered before the expressions are executed.
Since most definitions are simply means for defining variables whose values are the value returned by evaluating expressions, expressions are the focus of most of this syntax description.
Like most languages, expressions in RScheme return a value. Unlike many, however, (a) most constructs are expressions, including control, block, and binding constructs, and (b) expressions may return more than one value or zero values.
Many expressions return very familiar values, although perhaps in an unfamiliar syntax:
In this book, we use the above typographical convention to indicate that the expression (+ 1 2), when evaluated, returns the value 3. More precisely, the string to the left of the arrow is intended to be a prototypical expression as it might appear in a program, while the string to the right is the print form of the object (value) returned when that expression is evaluated.
Note that the right hand side is the print form of the resulting object(s), and not the expression necessary to create those objects. In other words, the left hand side denotes a program, and the right hand side denotes data. The arrow may be regarded as the "evaluates to" operator.
Like most programming languages, RScheme has a lexical structure which underlies its syntactic structure.
Table 2-1. Token examples
|whitespace; used to seperate tokens. All the ASCII whitespace characters are valid token delimiters (ie, space, newline, carriage return, form feed, vertical tab).|
|#key #rest||syntactic keywords|
RScheme also has an interactive form evalutation interface. This environment, too, is in a module, as we'll see later.