10 2. Using Chez Scheme
The interaction described above uses just a few of the expeditor’s feat ures. The exped i t or’ s
remaining features are described in the following section.
Running programs may be inter r up t ed by typing the interrupt ch arac t er (typically ^C).
In response, the system enters a debug handler, which prompts for input with a break>
prompt. One of several commands may be issu ed to the break handler (followed by a
newline), including
“e” or end-of-file to exit from the han dl e r and continue,
“r” to stop execution and reset to t he current caf´e,
“a” to abort Chez Scheme,
“n” to enter a new caf´e (see bel ow),
“i” to inspect the current continuation,
“s” to display statistics about the interrupted program, and
“?” to display a list of these options.
When an exception ot h er than a warning occurs, the default exception handler prints a
message that describes the exception to the console error port. If a REPL is running, the
exception handler then returns to the REPL, where the programmer can call the debug
procedure to start up the debug handle r, if desired. The debug handler i s similar to the
break handler and allows the p r ogram mer to inspect the continuation ( control stack) of
the exception to he l p determine the cause of the problem. If no REPL is running, as is
the case for a script or top-level program run via the --script or --program command-line
options, the default except i on handler exits from the scr ip t or program after printing t h e
message. To allow scripts and top-level programs to be debugged, the default exception
handler can be forced via the debug-on-exception p ar amet e r or the --debug-on-exception
command-line option to invoke debug directly.
Developing a large program entirely in the REPL is unmanageable, and we usually even
want to store small er programs in a file f or future use. (The expeditor’s history is saved
across Scheme sessions, but there is a limit on the number of item s, so it is not a good idea
to count on a program remaini n g in the history indefinitely. ) Thus, a Scheme programmer
typically creates a file containing Scheme source code using a text editor, su ch as vi, and
loads the file into Chez Scheme to test them. The conventional filename extension for
Chez Scheme source files is “.ss,” bu t the file can have any extension or even no extension
at all. A source file can be loaded during an interactive session by typi n g (load "path ").
Files to be loaded can also be named on the command line when the system is st ar t ed .
Any form that can be typed interactively can be placed in a file to be loaded.
Chez Scheme compiles source forms as it sees the m to machine code before evalu at ing
them, i.e., “just in time.” In order to speed loading of a large file or group of files, each
file can be compiled ahead of time via compile-file, which puts the compiled code into
a separate object file. For example, (compile-file "path ") compiles t he forms in the file
path .ss and places the resulting obje ct code in the file path .so. Loading a pre-compiled file
is essentially no di↵erent from loadi ng the source file, except that loading is faster since
compilation has already been done.