The configuration language consists of top-level defining forms for modules and interfaces. Its syntax is given in figure 1.
Figure 1: The configuration language.
A define-structure form introduces a binding of a name to a structure. A structure is a view on an underlying package which is created according to the clauses of the define-structure form. Each structure has an interface that specifies which bindings in the structure's underlying package can be seen via that structure in other packages.
An open clause specifies which structures will be opened up for
use inside the new package. At least one package must be specified or
else it will be impossible to write any useful programs inside the
package, since define, lambda, cons,
structure-ref, etc. will be unavailable. Typical packages to list
in the open clause are scheme, which exports all bindings
appropriate to Revised
Scheme, and structure-refs, which
exports the structure-ref operator (see below). For building
structures that export structures, there is a defpackage package
that exports the operators of the configuration language. Many other
structures, such as record and hash table facilities, are also
available in the Scheme 48 implementation.
An access clause specifies which bindings of names to structures will be visible inside the package body for use in structure-ref forms. structure- ref has the following syntax:
The
(structure-ref
-name
)
-name
must be the name of an accessed structure,
and 
must be something that the structure exports. Only
structures listed in an access clause are valid in a
structure-ref. If a package accesses any structures, it should
probably open the structure-refs structure so that the
structure-ref operator itself will be available.
The package's body is specified by begin and/or files clauses. begin and files have the same semantics, except that for begin the text is given directly in the package definition, while for files the text is stored somewhere in the file system. The body consists of a Scheme program, that is, a sequence of definitions and expressions to be evaluated in order. In practice, I always use files in preference to begin; begin exists mainly for expository purposes.
A name's imported binding may be lexically overridden or shadowed by simply defining the name using a defining form such as define or define- syntax. This will create a new binding without having any effect on the binding in the opened package. For example, one can do (define car 'chevy) without affecting the binding of the name car in the scheme package.
Assignments (using set!) to imported and undefined variables
are not allowed. In order to set! a top-level variable, the
package body must contain a define form defining that variable.
Applied to bindings from the scheme structure, this restriction
is compatible with the requirements of the Revised
Scheme report.
It is an error for two of a package's opened structures to export two different bindings for the same name. However, the current implementation does not check for this situation; a name's binding is always taken from the structure that is listed first within the open clause. This may be fixed in the future.
File names in a files clause can be symbols, strings, or lists (Maclisp-style ``namelists''). A ``.scm'' file type suffix is assumed. Symbols are converted to file names by converting to upper or lower case as appropriate for the host operating system. A namelist is an operating-system-indepedent way to specify a file obtained from a subdirectory. For example, the namelist (rts record) specifies the file record.scm in the rts subdirectory.
If the define-structure form was itself obtained from a file, then file names in files clauses are interpreted relative to the directory in which the file containing the define-structure form was found. You can't at present put an absolute path name in the files list.
