While it is possible to use the Scheme 48 static linker for program development, it is far more convenient to use the development environment, which supports rapid turnaround for program changes. The programmer interacts with the development environment through a command processor. The command processor is like the usual Lisp read-eval-print loop in that it accepts Scheme forms to evaluate. However, all meta-level operations, such as exiting the Scheme system or requests for trace output, are handled by commands, which are lexically distinguished from Scheme forms. This arrangement is borrowed from the Symbolics Lisp Machine system, and is reminiscent of non-Lisp debuggers. Commands are a little easier to type than Scheme forms (no parentheses, so you don't have to shift), but more importantly, making them distinct from Scheme forms ensures that programs' namespaces aren't cluttered with inappropriate bindings. Equivalently, the command set is available for use regardless of what bindings happen to be visible in the current program. This is especially important in conjunction with the module system, which puts strict controls on visibility of bindings.
The Scheme 48 command processor supports the module system with a variety of special commands. For commands that require structure names, these names are resolved in a designated configuration package that is distinct from the current package for evaluating Scheme forms given to the command processor. The command processor interprets Scheme forms in a particular current package, and there are commands that move the command processor between different packages.
Commands are introduced by a comma (,) and end at the end of line. The command processor's prompt consists of the name of the current package followed by a greater-than (>).
,open structure
*
structure
.
As with open clauses the visible names can be modified,
as in
which only makes the,open (subset foo (bar baz))
bar
and baz
bindings from
structure foo
visible.
,config
,config command
interprets configuration language forms from the file foo.scm in the current configuration package.,config ,load foo.scm
,config-package-is struct-name
struct-name
s for other commands such as ,in and
,open. See
below
for information on making new configuration packages.
,in struct-name
In this example the command processor starts in a package called user, but the ,config command moves it into the configuration package, which has the name config. The define-structure form binds, in config, the name foo to a structure that exports a. Finally, the command ,in foo moves the command processor into structure foo's underlying package.user> ,config config> (define-structure foo (export a) (open scheme)) config> ,in foo foo> (define a 13) foo> a 13
A package's body isn't executed (evaluated) until the package is loaded, which is accomplished by the ,load-package command.
,in struct-name
command
,in mumble (cons 1 2) ,in mumble ,trace foo
,user [command
]
,user-package-is name
,load-package struct-name
,reload-package struct-name
,load filespec
...
filespec
is similar
to (load "filespec
")
except that the name load needn't be bound in the current
package to Scheme's load procedure.
,for-syntax [command
]
name
f
) are evaluated.
,new-package
,structure name
interface
name
in the
configuration package to be a structure with interface
interface
based on the current package.
Previous: Semantics of configuration mutation | Next: Configuration packages