This is gambit.info, produced by makeinfo version 4.8 from gambit.txi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* Gambit: (gambit).		A portable implementation of Scheme.
* gsi: (gambit) interpreter.	Gambit interpreter.
* gsc: (gambit) compiler.	Gambit compiler.
END-INFO-DIR-ENTRY

   This file documents Gambit, a portable implementation of Scheme.

   Copyright (C) 1994-2016 Marc Feeley.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the copyright holder.


File: gambit.info,  Node: Top,  Prev: (dir),  Up: (dir)

Gambit
******

This manual documents Gambit.  It covers release v4.9.3.

* Menu:

* The Gambit system::               The Gambit system
* Accessing the system files::      Accessing the system files
* GSI::                             The Gambit Scheme interpreter
* GSC::                             The Gambit Scheme compiler
* Runtime options::                 Runtime options
* Debugging::                       Debugging
* Scheme extensions::               Scheme extensions
* Namespaces::                      Namespaces
* Characters and strings::          Characters and strings
* Numbers::                         Numbers
* Homogeneous vectors::             Homogeneous vectors
* Hashing and weak references::     Hashing and weak references
* Records::                         Records
* Threads::                         Threads
* Dynamic environment::             Dynamic environment
* Exceptions::                      Exceptions
* Host environment::                Host environment
* I/O and ports::                   I/O and ports
* Lexical syntax and readtables::   Lexical syntax and readtables
* C-interface::                     C-interface
* System limitations::              System limitations
* Copyright and license::           Copyright and license
* General index::                   General index


File: gambit.info,  Node: The Gambit system,  Next: GSI,  Prev: Top,  Up: Top

1 The Gambit system
*******************

The Gambit programming system is a full implementation of the Scheme
language which conforms to the R4RS, R5RS and IEEE Scheme standards.  It
consists of two main programs: `gsi', the Gambit Scheme interpreter,
and `gsc', the Gambit Scheme compiler.

   The Gambit compiler generates portable C code, making the whole
Gambit system and the programs compiled with it easily portable to many
computer architectures for which a C compiler is available.  With
appropriate declarations in the source code the executable programs
generated by the compiler run roughly as fast as equivalent C programs.

   For the most up to date information on Gambit and add-on packages
please check the Gambit web page at `http://gambitscheme.org'.  The web
page has links to the Gambit mailing list, the bug reporting system,
and the source code repository.

* Menu:

* Accessing the system files::      Accessing the system files


File: gambit.info,  Node: Accessing the system files,  Prev: The Gambit system,  Up: The Gambit system

1.1 Accessing the system files
==============================

Files related to Gambit, such as executables, libraries and header
files, are stored in multiple "Gambit installation directories".
Gambit may be installed on a system according to two different
installation models.

   In the first model there is a single directory where all the Gambit
installation directories are stored.  This "central installation
directory" is typically `/usr/local/Gambit' under UNIX,
`/Library/Gambit' under Mac OS X and `C:/Program Files/Gambit' under
Microsoft Windows.  This may have been overridden when the system was
built with the command `configure --prefix=/my/Gambit'.  If the system
was built with the command `configure --enable-multiple-versions' then
the central installation directory is `prefix/version', where `version'
is the system version string (e.g. `v4.9.3' for Gambit v4.9.3).
Moreover, `prefix/current' will be a symbolic link which points to the
central installation directory.  In this model, the Gambit installation
directory named X is simply the subdirectory X of the central
installation directory.

   In the second model some or all of the Gambit installation
directories are stored in installation specific directories.  The
location of these directories is assigned when the system is built
using the command `configure --bindir=/my/bin --includedir=/my/include
--libdir=/my/lib'.

   The advantage of the first model is that it is easy to have multiple
versions of Gambit coexist and to remove all the files of a given
version.  However, the second model may be necessary to conform to the
package installation conventions of some operating systems.

   Executable programs such as the interpreter `gsi' and compiler `gsc'
can be found in the `bin' installation directory.  Adding this
directory to the `PATH' environment variable allows these programs to
be started by simply entering their name.  This is done automatically
by the Mac OS X and Microsoft Windows installers.

   The runtime library is located in the `lib' installation directory.
When the system's runtime library is built as a shared-library (with
the command `configure --enable-shared') all programs built with
Gambit, including the interpreter and compiler, need to find this
library when they are executed and consequently this directory must be
in the path searched by the system for shared-libraries.  This path is
normally specified through an environment variable which is
`LD_LIBRARY_PATH' on most versions of UNIX, `LIBPATH' on AIX,
`SHLIB_PATH' on HPUX, `DYLD_LIBRARY_PATH' on Mac OS X, and `PATH' on
Microsoft Windows.  If the shell is `sh', the setting of the path can be
made for a single execution by prefixing the program name with the
environment variable assignment, as in:

     $ LD_LIBRARY_PATH=/usr/local/Gambit/lib gsi

   A similar problem exists with the Gambit header file `gambit.h',
located in the `include' installation directory.  This header file is
needed for compiling Scheme programs with the Gambit compiler.  When
the C compiler is being called explicitly it may be necessary to use a
`-I<DIR>' command line option to indicate where to find header files
and a `-L<DIR>' command line option to indicate where to find libraries.

   Access to both of these files can be simplified by creating a link to
them in the appropriate system directories (special privileges may
however be required):

     $ ln -s /usr/local/Gambit/lib/libgambit.a /usr/lib # name may vary
     $ ln -s /usr/local/Gambit/include/gambit.h /usr/include

   Alternatively these files can be copied or linked in the directory
where the C compiler is invoked (this requires no special privileges).

   Another approach is to set some environment variables which are used
to tell the C compiler where to find header files and libraries.  For
example, the following settings can be used for the `gcc' C compiler:

     $ export LIBRARY_PATH=/usr/local/Gambit/lib
     $ export CPATH=/usr/local/Gambit/include

   Note that this may have been done by the installation process.  In
particular, the Mac OS X and Microsoft Windows prebuilt installers set
up the environment so that the `gcc' compiler finds these files
automatically.

* Menu:

* GSI::                             The Gambit Scheme interpreter
* GSC::                             The Gambit Scheme compiler
* Runtime options::                 Runtime options
* Debugging::                       Debugging
* Scheme extensions::               Scheme extensions
* Namespaces::                      Namespaces
* Characters and strings::          Characters and strings
* Numbers::                         Numbers
* Homogeneous vectors::             Homogeneous vectors
* Hashing and weak references::     Hashing and weak references
* Records::                         Records
* Threads::                         Threads
* Dynamic environment::             Dynamic environment
* Exceptions::                      Exceptions
* Host environment::                Host environment
* I/O and ports::                   I/O and ports
* Lexical syntax and readtables::   Lexical syntax and readtables
* C-interface::                     C-interface
* System limitations::              System limitations
* Copyright and license::           Copyright and license


File: gambit.info,  Node: GSI,  Next: GSC,  Prev: The Gambit system,  Up: Top

2 The Gambit Scheme interpreter
*******************************

Synopsis:

     gsi [-:RUNTIMEOPTION,...] [-i] [-f] [-v] [[-] [-e EXPRESSIONS] [FILE]]...

   The interpreter is executed in "interactive mode" when no file or
`-' or `-e' option is given on the command line.  Otherwise the
interpreter is executed in "batch mode".  The `-i' option is ignored by
the interpreter.  The initialization file will be examined unless the
`-f' option is present (*note GSI customization::).  The `-v' option
prints the system version string, system time stamp, operating system
type, and configure script options on standard output and exits.
Runtime options are explained in *Note Runtime options::.

* Menu:

* GSI interactive mode::            Interactive mode
* GSI batch mode::                  Batch mode
* GSI customization::               Customization
* GSI exit status::                 Process exit status
* Scheme scripts::                  Scheme scripts


File: gambit.info,  Node: GSI interactive mode,  Next: GSI batch mode,  Prev: GSI,  Up: GSI

2.1 Interactive mode
====================

In interactive mode a read-eval-print loop (REPL) is started for the
user to interact with the interpreter.  At each iteration of this loop
the interpreter displays a prompt, reads a command and executes it.
The commands can be expressions to evaluate (the typical case) or
special commands related to debugging, for example `,q' to terminate
the process (for a complete list of commands see *Note Debugging::).
Most commands produce some output, such as the value or error message
resulting from an evaluation.

   The input and output of the interaction is done on the "interaction
channel".  The interaction channel can be specified through the runtime
options but if none is specified the system uses a reasonable default
that depends on the system's configuration.  When the system's runtime
library was built with support for GUIDE, the Gambit Universal IDE
(with the command `configure --enable-guide') the interaction channel
corresponds to the "console window" of the primordial thread (for
details see *Note GUIDE::), otherwise the interaction channel is the
user's "console", also known as the "controlling terminal" in the UNIX
world.  When the REPL starts, the ports associated with
`(current-input-port)', `(current-output-port)' and
`(current-error-port)' all refer to the interaction channel.

   Expressions are evaluated in the global "interaction environment".
The interpreter adds to this environment any definition entered using
the `define' and `define-macro' special forms.  Once the evaluation of
an expression is completed, the value or values resulting from the
evaluation are output to the interaction channel by the pretty printer.
The special "void" object is not output.  This object is returned by
most procedures and special forms which the Scheme standard defines as
returning an unspecified value (e.g. `write', `set!', `define').

   Here is a sample interaction with `gsi':

     $ gsi
     Gambit v4.9.3

     > (define (fact n) (if (< n 2) 1 (* n (fact (- n 1)))))
     > (map fact '(1 2 3 4 5 6))
     (1 2 6 24 120 720)
     > (values (fact 10) (fact 40))
     3628800
     815915283247897734345611269596115894272000000000
     > ,q

   What happens when errors occur is explained in *Note Debugging::.


File: gambit.info,  Node: GSI batch mode,  Next: GSI customization,  Prev: GSI interactive mode,  Up: GSI

2.2 Batch mode
==============

In batch mode the command line arguments denote files to be loaded,
REPL interactions to start (`-' option), and expressions to be
evaluated (`-e' option).  Note that the `-' and `-e' options can be
interspersed with the files on the command line and can occur multiple
times.  The interpreter processes the command line arguments from left
to right, loading files with the `load' procedure and evaluating
expressions with the `eval' procedure in the global interaction
environment.  After this processing the interpreter exits.

   When the file name has no extension the `load' procedure first
attempts to load the file with no extension as a Scheme source file.
If that file doesn't exist it will search for both a source file and an
object file.  The object file's name is obtained by adding to the file
name a `.oN' extension with the highest consecutive version number
starting with 1.  The source file's name is obtained by adding to the
file name the file extensions `.scm' and `.six' (the first found is the
source file).  If both a source file and an object file exist, then the
one with the latest modification time is loaded.  Otherwise the file
that is found is loaded.  When the file name has an extension, the
`load' procedure will only attempt to load the file with that specific
name.

   When the extension of the file loaded is `.scm' the content of the
file will be parsed using the normal Scheme prefix syntax.  When the
extension of the file loaded is `.six' the content of the file will be
parsed using the Scheme infix syntax extension (see *Note Scheme infix
syntax extension::).  Otherwise, `gsi' will parse the file using the
normal Scheme prefix syntax.

   The ports associated with `(current-input-port)',
`(current-output-port)' and `(current-error-port)' initially refer
respectively to the standard input (`stdin'), standard output
(`stdout') and the standard error (`stderr') of the interpreter.  This
is true even in REPLs started with the `-' option.  The usual
interaction channel (console or IDE's console window) is still used to
read expressions and commands and to display results.  This makes it
possible to use REPLs to debug programs which read the standard input
and write to the standard output, even when these have been redirected.

   Here is a sample use of the interpreter in batch mode, under UNIX:

     $ cat h.scm
     (display "hello") (newline)
     $ cat w.six
     display("world"); newline();
     $ gsi h.scm - w.six -e "(pretty-print 1)(pretty-print 2)"
     hello
     > (define (display x) (write (reverse (string->list x))))
     > ,(c 0)
     (#\d #\l #\r #\o #\w)
     1
     2


File: gambit.info,  Node: GSI customization,  Next: GSI exit status,  Prev: GSI batch mode,  Up: GSI

2.3 Customization
=================

There are two ways to customize the interpreter.  When the interpreter
starts off it tries to execute a `(load "~~lib/gambext")' (for an
explanation of how file names are interpreted see *Note Host
environment::).  An error is not signaled when the file does not exist.
Interpreter extensions and patches that are meant to apply to all
users and all modes should go in that file.

   Extensions which are meant to apply to a single user or to a specific
working directory are best placed in the "initialization file", which
is a file containing Scheme code.  In all modes, the interpreter first
tries to locate the initialization file by searching the following
locations: `.gambini' and `~/.gambini' (with no extension, a `.scm'
extension, and a `.six' extension in that order).  The first file that
is found is examined as though the expression `(include
INITIALIZATION-FILE)' had been entered at the read-eval-print loop
where INITIALIZATION-FILE is the file that was found.  Note that by
using an `include' the macros defined in the initialization file will
be visible from the read-eval-print loop (this would not have been the
case if `load' had been used).  The initialization file is not searched
for or examined when the `-f' option is specified.


File: gambit.info,  Node: GSI exit status,  Next: Scheme scripts,  Prev: GSI customization,  Up: GSI

2.4 Process exit status
=======================

The status is zero when the interpreter exits normally and is nonzero
when the interpreter exits due to an error.  Here is the meaning of the
exit statuses:

`0'
     The execution of the primordial thread (i.e. the main thread) did
     not encounter any error.  It is however possible that other threads
     terminated abnormally (by default threads other than the primordial
     thread terminate silently when they raise an exception that is not
     handled).

`64'
     The runtime options or the environment variable `GAMBOPT'
     contained a syntax error or were invalid.

`70'
     This normally indicates that an exception was raised in the
     primordial thread and the exception was not handled.

`71'
     There was a problem initializing the runtime system, for example
     insufficient memory to allocate critical tables.


   For example, if the shell is `sh':

     $ gsi -:d0 -e "(pretty-print (expt 2 100))"
     1267650600228229401496703205376
     $ echo $?
     0
     $ gsi -:d0,unknown # try to use an unknown runtime option
     $ echo $?
     64
     $ gsi -:d0 nonexistent.scm # try to load a file that does not exist
     $ echo $?
     70
     $ gsi nonexistent.scm
     *** ERROR IN ##main -- No such file or directory
     (load "nonexistent.scm")
     $ echo $?
     70

     $ gsi -:m4000000 # ask for a 4 gigabyte heap
     *** malloc: vm_allocate(size=528384) failed (error code=3)
     *** malloc[15068]: error: Can't allocate region
     $ echo $?
     71

   Note the use of the runtime option `-:d0' that prevents error
messages from being output, and the runtime option `-:m4000000' which
sets the minimum heap size to 4 gigabytes.


File: gambit.info,  Node: Scheme scripts,  Prev: GSI exit status,  Up: GSI

2.5 Scheme scripts
==================

The `load' procedure treats specially files that begin with the two
characters `#!' and `@;'.  Such files are called "script files" and the
first line is called the "script line".  In addition to indicating that
the file is a script, the script line provides information about the
source code language to be used by the `load' procedure.  After the two
characters `#!' and `@;' the system will search for the first substring
matching one of the following language specifying tokens:

`scheme-r4rs'
     R4RS language with prefix syntax, case-insensitivity, keyword
     syntax not supported

`scheme-r5rs'
     R5RS language with prefix syntax, case-insensitivity, keyword
     syntax not supported

`scheme-ieee-1178-1990'
     IEEE 1178-1990 language with prefix syntax, case-insensitivity,
     keyword syntax not supported

`scheme-srfi-0'
     R5RS language with prefix syntax and SRFI 0 support (i.e.
     `cond-expand' special form), case-insensitivity, keyword syntax
     not supported

`gsi-script'
     Full Gambit Scheme language with prefix syntax, case-sensitivity,
     keyword syntax supported

`gsc-script'
     Full Gambit Scheme language with prefix syntax, case-sensitivity,
     keyword syntax supported

`six-script'
     Full Gambit Scheme language with infix syntax, case-sensitivity,
     keyword syntax supported


   If a language specifying token is not found, `load' will use the
same language as a nonscript file (i.e. it uses the file extension and
runtime system options to determine the language).

   After processing the script line, `load' will parse the rest of the
file (using the syntax of the language indicated) and then execute it.
When the file is being loaded because it is an argument on the
interpreter's command line, the interpreter will:

   * Setup the `command-line' procedure so that it returns a list
     containing the expanded file name of the script file and the
     arguments following the script file on the command line.  This is
     done before the script is executed.  The expanded file name of the
     script file can be used to determine the directory that contains
     the script (i.e. `(path-directory (car (command-line)))').

   * After the script is loaded the procedure `main' is called with the
     command-line arguments.  The way this is done depends on the
     language specifying token.  For `scheme-r4rs', `scheme-r5rs',
     `scheme-ieee-1178-1990', and `scheme-srfi-0', the `main' procedure
     is called with the equivalent of `(main (cdr (command-line)))' and
     `main' is expected to return a process exit status code in the
     range 0 to 255.  This conforms to the "Running Scheme Scripts on
     Unix SRFI" (SRFI 22).  For `gsi-script' and `six-script' the `main'
     procedure is called with the equivalent of `(apply main (cdr
     (command-line)))' and the process exit status code is 0 (`main''s
     result is ignored).  The Gambit system has a predefined `main'
     procedure which accepts any number of arguments and returns 0, so
     it is perfectly valid for a script to not define `main' and to do
     all its processing with top-level expressions (examples are given
     in the next section).

   * When `main' returns, the interpreter exits.  The command-line
     arguments after a script file are consequently not processed
     (however they do appear in the list returned by the `command-line'
     procedure, after the script file's expanded file name, so it is up
     to the script to process them).


* Menu:

* Scripts under UNIX and Mac OS X:: Scripts under UNIX and Mac OS X
* Scripts under Microsoft Windows:: Scripts under Microsoft Windows
* Compiling scripts::               Compiling scripts


File: gambit.info,  Node: Scripts under UNIX and Mac OS X,  Next: Scripts under Microsoft Windows,  Prev: Scheme scripts,  Up: Scheme scripts

2.5.1 Scripts under UNIX and Mac OS X
-------------------------------------

Under UNIX and Mac OS X, the Gambit installation process creates the
executable `gsi' and also the executables `six', `gsi-script',
`six-script', `scheme-r5rs', `scheme-srfi-0', etc as links to `gsi'.  A
Scheme script need only start with the name of the desired Scheme
language variant prefixed with `#!' and the directory where the Gambit
executables are stored.  This script should be made executable by
setting the execute permission bits (with a `chmod +x SCRIPT').  Here
is an example of a script which lists on standard output the files in
the current directory:

     #!/usr/local/Gambit/bin/gsi-script
     (for-each pretty-print (directory-files))

   Here is another UNIX script, using the Scheme infix syntax extension,
which takes a single integer argument and prints on standard output the
numbers from 1 to that integer:

     #!/usr/local/Gambit/bin/six-script

     void main (obj n_str)
     {
       int n = \string->number(n_str);
       for (int i=1; i<=n; i++)
         \pretty-print(i);
     }

   For maximal portability it is a good idea to start scripts indirectly
through the `/usr/bin/env' program, so that the executable of the
interpreter will be searched in the user's `PATH'.  This is what SRFI
22 recommends.  For example here is a script that mimics the UNIX `cat'
utility for text files:

     #!/usr/bin/env gsi-script

     (define (display-file filename)
       (display (call-with-input-file filename
                  (lambda (port)
                    (read-line port #f)))))

     (for-each display-file (cdr (command-line)))


File: gambit.info,  Node: Scripts under Microsoft Windows,  Next: Compiling scripts,  Prev: Scripts under UNIX and Mac OS X,  Up: Scheme scripts

2.5.2 Scripts under Microsoft Windows
-------------------------------------

Under Microsoft Windows, the Gambit installation process creates the
executable `gsi.exe' and `six.exe' and also the batch files
`gsi-script.bat', `six-script.bat', `scheme-r5rs.bat',
`scheme-srfi-0.bat', etc which simply invoke `gsi.exe' with the same
command line arguments.  A Scheme script need only start with the name
of the desired Scheme language variant prefixed with `@;'.  A UNIX
script can be converted to a Microsoft Windows script simply by
changing the script line and storing the script in a file whose name
has a `.bat' or `.cmd' extension:

     @;gsi-script %~f0 %*
     (display "files:\n")
     (pretty-print (directory-files))

   Note that Microsoft Windows always searches executables in the user's
`PATH', so there is no need for an indirection such as the UNIX
`/usr/bin/env'.  However the script line must end with `%~f0 %*' to
pass the expanded filename of the script and command line arguments to
the interpreter.


File: gambit.info,  Node: Compiling scripts,  Prev: Scripts under Microsoft Windows,  Up: Scheme scripts

2.5.3 Compiling scripts
-----------------------

A script file can be compiled using the Gambit Scheme compiler (*note
GSC::) into a standalone executable.  The script line will provide
information to the compiler on which language to use.  The script line
also provides information on which runtime options to use when
executing the compiled script.  This is useful to set the default
runtime options of an executable program.

   The compiled script will be executed similarly to an interpreted
script (i.e. the list of command line arguments returned by the
`command-line' procedure and the invocation of the `main' procedure).

   For example:

     $ cat square.scm
     #!/usr/local/Gambit/bin/gsi-script -:d0
     (define (main arg)
       (pretty-print (expt (string->number arg) 2)))
     $ gsi square 30        # gsi will load square.scm
     900
     $ gsc -exe square      # compile the script to a standalone program
     $ ./square 30
     900
     $ ./square 1 2 3       # too many arguments to main
     $ echo $?
     70
     $ ./square -:d1 1 2 3  # ask for error message
     *** ERROR -- Wrong number of arguments passed to procedure
     (main "1" "2" "3")


File: gambit.info,  Node: GSC,  Next: Runtime options,  Prev: GSI,  Up: Top

3 The Gambit Scheme compiler
****************************

Synopsis:

     gsc [-:RUNTIMEOPTION,...] [-i] [-f] [-v]
         [-prelude EXPRESSIONS] [-postlude EXPRESSIONS]
         [-dynamic] [-exe] [-obj] [-cc-options OPTIONS]
         [-ld-options-prelude OPTIONS] [-ld-options OPTIONS]
         [-warnings] [-verbose] [-report] [-expansion] [-gvm] [-cfg] [-dg]
         [-debug] [-debug-location] [-debug-source]
         [-debug-environments] [-track-scheme]
         [-o OUTPUT] [-c] [-keep-c] [-link] [-flat] [-l BASE]
         [-module-name MODULE-NAME] [-linker-name LINKER-NAME]
         [[-] [-e EXPRESSIONS] [FILE]]...

* Menu:

* GSC interactive mode::            Interactive mode
* GSC customization::               Customization
* GSC batch mode::                  Batch mode
* Link files::                      Link files
* Procedures specific to compiler:: Procedures specific to compiler


File: gambit.info,  Node: GSC interactive mode,  Next: GSC customization,  Prev: GSC,  Up: GSC

3.1 Interactive mode
====================

When no command line argument is present other than options the
compiler behaves like the interpreter in interactive mode.  The only
difference with the interpreter is that the compilation related
procedures listed in this chapter are also available (i.e.
`compile-file', `compile-file-to-target', etc).


File: gambit.info,  Node: GSC customization,  Next: GSC batch mode,  Prev: GSC interactive mode,  Up: GSC

3.2 Customization
=================

Like the interpreter, the compiler will examine the initialization file
unless the `-f' option is specified.


File: gambit.info,  Node: GSC batch mode,  Next: Link files,  Prev: GSC customization,  Up: GSC

3.3 Batch mode
==============

In batch mode `gsc' takes a set of file names (with either no
extension, or a C file extension, or some other extension) on the
command line and compiles each Scheme file into a C file.  The
recognized C file extensions are `.c', `.C', `.cc', `.cp', `.cpp',
`.CPP', `.cxx', `.c++', `.m', `.M', and `.mm'.  The extension can be
omitted from FILE when the Scheme file has a `.scm' or `.six'
extension.  When the extension of the Scheme file is `.six' the content
of the file will be parsed using the Scheme infix syntax extension (see
*Note Scheme infix syntax extension::). Otherwise, `gsc' will parse the
Scheme file using the normal Scheme prefix syntax.  Files with a C file
extension must have been previously produced by `gsc', with the `-c'
option, and are used by Gambit's linker.

   For each Scheme file a C file `FILE.c' will be produced.  The C
file's name is the same as the Scheme file, but the extension is
changed to `.c'.  By default the C file is created in the same
directory as the Scheme file.  This default can be overridden with the
compiler's `-o' option.

   The C files produced by the compiler serve two purposes.  They will
be processed by a C compiler to generate object files, and they also
contain information to be read by Gambit's linker to generate a "link
file".  The link file is a C file that collects various linking
information for a group of modules, such as the set of all symbols and
global variables used by the modules.  The linker is only invoked when
the `-link' or `-exe' options appear on the command line.

   Compiler options must be specified before the first file name and
after the `-:' runtime option (*note Runtime options::).  If present,
the `-i', `-f', and `-v' compiler options must come first.  The
available options are:

`-i'
     Force interpreter mode.

`-f'
     Do not examine the initialization file.

`-v'
     Print the system version string, system time stamp, operating
     system type, and configure script options on standard output and
     exit.

`-prelude EXPRESSIONS'
     Add expressions to the top of the source code being compiled.

`-postlude EXPRESSIONS'
     Add expressions to the bottom of the source code being compiled.

`-cc-options OPTIONS'
     Add options to the command that invokes the C compiler.

`-ld-options-prelude OPTIONS'
     Add options to the command that invokes the C linker.

`-ld-options OPTIONS'
     Add options to the command that invokes the C linker.

`-warnings'
     Display warnings.

`-verbose'
     Display a trace of the compiler's activity.

`-report'
     Display a global variable usage report.

`-expansion'
     Display the source code after expansion.

`-gvm'
     Generate a listing of the GVM code.

`-cfg'
     Generate a control flow graph of the GVM code.

`-dg'
     Generate a dependency graph.

`-debug'
     Include all debugging information in the code generated.

`-debug-location'
     Include source code location debugging information in the code
     generated.

`-debug-source'
     Include the source code debugging information in the code
     generated.

`-debug-environments'
     Include environment debugging information in the code generated.

`-track-scheme'
     Generate `#line' directives referring back to the Scheme code.

`-o OUTPUT'
     Set name of output file or directory where output file(s) are
     written.

`-dynamic'
     Compile Scheme source files to dynamically loadable object files
     (this is the default).

`-exe'
     Compile Scheme source files into an executable program.

`-obj'
     Compile Scheme source files to object files.

`-keep-c'
     Keep any intermediate `.c' files that are generated.

`-c'
     Compile Scheme source files to C without generating link file.

`-link'
     Compile Scheme source files to C and generate a link file.

`-flat'
     Generate a flat link file instead of the default incremental link
     file.

`-l BASE'
     Specify the link file of the base library to use for the link.

`-module-name MODULE-NAME'
     Specify the name of the generated module.

`-linker-name LINKER-NAME'
     Specify the name of the low-level initialization function exported
     by the module.

`-'
     Start REPL interaction.

`-e EXPRESSIONS'
     Evaluate expressions in the interaction environment.

   The `-i' option forces the compiler to process the remaining command
line arguments like the interpreter.

   The `-prelude' option adds the specified expressions to the top of
the source code being compiled.  The main use of this option is to
supply declarations on the command line.  For example the following
invocation of the compiler will compile the file `bench.scm' in unsafe
mode:

     $ gsc -prelude "(declare (not safe))" bench.scm

   The `-postlude' option adds the specified expressions to the bottom
of the source code being compiled.  The main use of this option is to
supply the expression that will start the execution of the program.  For
example:

     $ gsc -postlude "(start-bench)" bench.scm

   The `-cc-options' option is only meaningful when a dynamically
loadable object file is being generated (neither the `-c' or `-link'
options are used).  The `-cc-options' option adds the specified options
to the command that invokes the C compiler.  The main use of this
option is to specify the include path, some symbols to define or
undefine, the optimization level, or any C compiler option that is
different from the default.  For example:

     $ gsc -cc-options "-U___SINGLE_HOST -O2 -I../include" bench.scm

   The `-ld-options-prelude' and `-ld-options' options are only
meaningful when a dynamically loadable object file is being generated
(neither the `-c' or `-link' options are used).  The
`-ld-options-prelude' and `-ld-options' options add the specified
options to the command that invokes the C linker (the options in
LD-OPTIONS-PRELUDE are passed to the C linker before the input file and
the options in LD-OPTIONS are passed after).  The main use of this
option is to specify additional object files or libraries that need to
be linked, or any C linker option that is different from the default
(such as the library search path and flags to select between static and
dynamic linking).  For example:

     $ gsc -ld-options "-L/usr/X11R6/lib -lX11 -dynamic" bench.scm

   The `-warnings' option displays on standard output all warnings that
the compiler may have.

   The `-verbose' option displays on standard output a trace of the
compiler's activity.

   The `-report' option displays on standard output a global variable
usage report.  Each global variable used in the program is listed with
4 flags that indicate whether the global variable is defined,
referenced, mutated and called.

   The `-expansion' option displays on standard output the source code
after expansion and inlining by the front end.

   The `-gvm' option generates a listing of the intermediate code for
the "Gambit Virtual Machine" (GVM) of each Scheme file on `FILE.gvm'.

   The `-cfg' option generates a visual representation of the control
flow graph of the intermediate code for the "Gambit Virtual Machine"
(GVM) of each Scheme file on `FILE.cfg'.  The file is suitable for
processing with the "dot" program.  For example, to generate the PDF
file `FILE.cfg.pdf' from `FILE.cfg' the following command can be used:

     $ dot -O -Tpdf FILE.cfg

   The `-dg' option generates a visual representation of the dependency
graph of each Scheme file on `FILE.dg'.  The file is suitable for
processing with the "dot" program.  For example, to generate the PDF
file `FILE.dg.pdf' from `FILE.dg' the following command can be used:

     $ dot -O -Tpdf FILE.dg

   The `-debug' option causes all kinds of debugging information to be
saved in the code generated.  See the documentation of the `debug'
declaration for details.

   The `-debug-location' option causes source code location debugging
information to be saved in the code generated.  See the documentation
of the `debug-location' declaration for details.

   The `-debug-source' option causes source code debugging information
to be saved in the code generated.  See the documentation of the
`debug-source' declaration for details.

   The `-debug-environments' option causes environment debugging
information to be saved in the code generated.  See the documentation
of the `debug-environments' declaration for details.

   The `-track-scheme' options causes the generation of `#line'
directives that refer back to the Scheme source code.  This allows the
use of a C debugger or profiler to debug Scheme code.

   The `-o' option sets the filename of the output file, or the
directory in which the output file(s) generated by the compiler are
written.

   If the `-link' or `-exe' options appear on the command line, the
Gambit linker is invoked to generate the link file from the set of C
files specified on the command line or produced by the Gambit compiler.
By default the link file is `LAST_.c', where `LAST.c' is the last file
in the set of C files.  When the `-c' option is specified, the Scheme
source files are compiled to C files.  When the `-exe' option is
specified, the generated C files and link file are compiled and linked
using the C compiler to produce an executable program whose name
defaults to `LAST.exe'.  When the `-obj' option is specified, the
generated C files are compiled using the C compiler to produce object
files (`.o' or `.obj' extensions).  If neither the `-link', `-c',
`-exe', `-obj' options appear on the command line, the Scheme source
files are compiled to dynamically loadable object files (`.oN'
extension).  The `-keep-c' option will prevent the deletion of any
intermediate `.c' file that is generated.  Note that in this case the
intermediate `.c' file will be generated in the same directory as the
Scheme source file even if the `-o' option is used.

   The `-flat' option is only meaningful when a link file is being
generated (i.e. the `-link' or `-exe' options also appear on the
command line).  The `-flat' option directs the Gambit linker to
generate a flat link file.  By default, the linker generates an
incremental link file (see the next section for a description of the
two types of link files).

   The `-l' option is only meaningful when an incremental link file is
being generated (i.e. the `-link' or `-exe' options appear on the
command line and the `-flat' option is absent).  The `-l' option
specifies the link file (without the `.c' extension) of the base
library to use for the incremental link.  By default the link file of
the Gambit runtime library is used (i.e. `~~lib/_gambit.c').

   The `-' option starts a REPL interaction.

   The `-e' option evaluates the specified expressions in the
interaction environment.


File: gambit.info,  Node: Link files,  Next: Procedures specific to compiler,  Prev: GSC batch mode,  Up: GSC

3.4 Link files
==============

Gambit can be used to create programs and libraries of Scheme modules.
This section explains the steps required to do so and the role played
by the link files.

   In general, a program is composed of a set of Scheme modules and C
modules.  Some of the modules are part of the Gambit runtime library and
the other modules are supplied by the user.  When the program is
started it must setup various global tables (including the symbol table
and the global variable table) and then sequentially execute the Scheme
modules (more or less as though they were being loaded one after
another).  The information required for this is contained in one or
more "link files" generated by the Gambit linker from the C files
produced by the Gambit compiler.

   The order of execution of the Scheme modules corresponds to the
order of the modules on the command line which produced the link file.
The order is usually important because most modules define variables and
procedures which are used by other modules (for this reason the
program's main computation is normally started by the last module).

   When a single link file is used to contain the linking information of
all the Scheme modules it is called a "flat link file".  Thus a program
built with a flat link file contains in its link file both information
on the user modules and on the runtime library.  This is fine if the
program is to be statically linked but is wasteful in a shared-library
context because the linking information of the runtime library can't be
shared and will be duplicated in all programs (this linking information
typically takes hundreds of kilobytes).

   Flat link files are mainly useful to bundle multiple Scheme modules
to make a runtime library (such as the Gambit runtime library) or to
make a single file that can be loaded with the `load' procedure.

   An "incremental link file" contains only the linking information
that is not already contained in a second link file (the "base" link
file).  Assuming that a flat link file was produced when the runtime
library was linked, a program can be built by linking the user modules
with the runtime library's link file, producing an incremental link
file.  This allows the creation of a shared-library which contains the
modules of the runtime library and its flat link file.  The program is
dynamically linked with this shared-library and only contains the user
modules and the incremental link file.  For small programs this
approach greatly reduces the size of the program because the
incremental link file is small.  A "hello world" program built this way
can be as small as 5 Kbytes.  Note that it is perfectly fine to use an
incremental link file for statically linked programs (there is very
little loss compared to a single flat link file).

   Incremental link files may be built from other incremental link
files.  This allows the creation of shared-libraries which extend the
functionality of the Gambit runtime library.

* Menu:

* Building an executable program::  Building an executable program
* Building a loadable library::     Building a loadable library
* Building a shared-library::       Building a shared-library
* Other compilation options::       Other compilation options


File: gambit.info,  Node: Building an executable program,  Next: Building a loadable library,  Prev: Link files,  Up: Link files

3.4.1 Building an executable program
------------------------------------

The simplest way to create an executable program is to invoke `gsc'
with the `-exe' option.  The compiler will transparently perform all
the steps necessary, including compiling Scheme source files to C
files, generating the link file, compiling the C files generated to
object files, and creating the final executable file using the C
linker.  The following example shows how to build the executable
program `hello.exe' which contains the two Scheme modules `h.scm' and
`w.six'.

     $ cat h.scm
     (display "hello") (newline)
     $ cat w.six
     display("world"); newline();
     $ gsc -o hello.exe -exe h.scm w.six
     h.scm:
     /Users/feeley/gambit/doc/h.c:
     w.six:
     /Users/feeley/gambit/doc/w.c:
     /Users/feeley/gambit/doc/w_.c:
     $ ./hello.exe
     hello
     world

   The detailed steps which are performed can be viewed by setting the
`GAMBCOMP_VERBOSE' environment variable to a nonnull value.  For
example:

     $ export GAMBCOMP_VERBOSE=yes
     $ gsc -o hello.exe -exe h.scm w.six
     h.scm:
     /Users/feeley/gambit/doc/h.c:
     gcc -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2
      -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer
      -fPIC -fno-common -I"/usr/local/Gambit/include" -c -o "h.o" h.c
     w.six:
     /Users/feeley/gambit/doc/w.c:
     gcc -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2
      -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer
      -fPIC -fno-common -I"/usr/local/Gambit/include" -c -o "w.o" w.c
     /Users/feeley/gambit/doc/w_.c:
     gcc -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2
      -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer
      -fPIC -fno-common -I"/usr/local/Gambit/include" -c -o "w_.o" w_.c
     gcc  -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2
      -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer
      -fPIC -fno-common -I"/usr/local/Gambit/include"
      -o "hello.exe" h.o w.o w_.o "/usr/local/Gambit/lib/libgambit.a"

   Using a single invocation of `gsc' with the `-exe' option is
sometimes inappropriate when the build process is more complex, for
example when the program is composed of several seperately compiled
modules.  In such a case it is useful to decompose the build process
into smaller compilation steps.  The `hello.exe' executable program
could have been built by seperating the generation of C files from the
C compilation and linking:

     $ gsc -c h.scm
     $ gsc -c w.six
     $ gsc -o hello.exe -exe h.c w.c

   When even finer control is desired the build process can be
decomposed into smaller steps that invoke the C compiler and linker
explicitly.  This is described in the rest of this section.

   The `gsc' compiler can be invoked to compile each Scheme module into
a C file and to create an incremental link file.  The C files and the
link file must then be compiled with a C compiler and linked (at the
object file level) with the Gambit runtime library and possibly other
libraries (such as the math library and the dynamic loading library).

   Here is for example how a program with three modules (one in C and
two in Scheme) can be built.  The content of the three source files
(`m1.c', `m2.scm' and `m3.scm') is:

     /* File: "m1.c" */
     int power_of_2 (int x) { return 1<<x; }

     ; File: "m2.scm"
     (c-declare "extern int power_of_2 ();")
     (define pow2 (c-lambda (int) int "power_of_2"))
     (define (twice x) (cons x x))

     ; File: "m3.scm"
     (write (map twice (map pow2 '(1 2 3 4)))) (newline)

   The compilation of the two Scheme source files can be done with
three invocations of `gsc':

     $ gsc -c m2.scm        # create m2.c (note: .scm is optional)
     $ gsc -c m3.scm        # create m3.c (note: .scm is optional)
     $ gsc -link m2.c m3.c  # create the incremental link file m3_.c

   Alternatively, the three invocations of `gsc' can be replaced by a
single invocation:

     $ gsc -link m2 m3
     m2:
     m3:

   At this point there will be 4 C files: `m1.c', `m2.c', `m3.c', and
`m3_.c'.  To produce an executable program these files must be compiled
with a C compiler and linked with the Gambit runtime library.  The C
compiler options needed will depend on the C compiler and the operating
system (in particular it may be necessary to add the options
`-I/usr/local/Gambit/include -L/usr/local/Gambit/lib' to access the
`gambit.h' header file and the Gambit runtime library).

   Here is an example under Mac OS X:

     $ uname -srmp
     Darwin 8.1.0 Power Macintosh powerpc
     $ gsc -obj m1.c m2.c m3.c m3_.c
     m1.c:
     m2.c:
     m3.c:
     m3_.c:
     $ gcc m1.o m2.o m3.o m3_.o -lgambit
     $ ./a.out
     ((2 . 2) (4 . 4) (8 . 8) (16 . 16))

   Here is an example under Linux:

     $ uname -srmp
     Linux 2.6.8-1.521 i686 athlon
     $ gsc -obj m1.c m2.c m3.c m3_.c
     m1.c:
     m2.c:
     m3.c:
     m3_.c:
     $ gcc m1.o m2.o m3.o m3_.o -lgambit -lm -ldl -lutil
     $ ./a.out
     ((2 . 2) (4 . 4) (8 . 8) (16 . 16))


File: gambit.info,  Node: Building a loadable library,  Next: Building a shared-library,  Prev: Building an executable program,  Up: Link files

3.4.2 Building a loadable library
---------------------------------

To bundle multiple modules into a single object file that can be
dynamically loaded with the `load' procedure, a flat link file is
needed.  The compiler's `-o' option must be used to name the C file
generated as follows.  If the dynamically loadable object file is to be
named `MYFILE.oN' then the `-o' option must set the name of the link
file generated to `MYFILE.oN.c' (note that the `.c' extension could
also be `.cc', `.cpp' or whatever extension is appropriate for C/C++
source files).  The three modules of the previous example can be
bundled by generating a link file in this way:

     $ gsc -link -flat -o foo.o1.c m2 m3
     m2:
     m3:
     *** WARNING -- "cons" is not defined,
     ***            referenced in: ("m2.c")
     *** WARNING -- "map" is not defined,
     ***            referenced in: ("m3.c")
     *** WARNING -- "newline" is not defined,
     ***            referenced in: ("m3.c")
     *** WARNING -- "write" is not defined,
     ***            referenced in: ("m3.c")

   The warnings indicate that there are no definitions (`define's or
`set!'s) of the variables `cons', `map', `newline' and `write' in the
set of modules being linked.  Before `foo.o1' is loaded, these
variables will have to be bound; either implicitly (by the runtime
library) or explicitly.

   When compiling the C files and link file generated, the flag
`-D___DYNAMIC' must be passed to the C compiler and the C compiler and
linker must be told to generate a dynamically loadable shared library.

   Here is an example under Mac OS X:

     $ uname -srmp
     Darwin 10.5.0 i386 i386
     $ gsc -link -flat -o foo.o1.c m2 m3 > /dev/null
     m2:
     m3:
     $ gsc -cc-options "-D___DYNAMIC" -obj m1.c m2.c m3.c foo.o1.c
     m1.c:
     m2.c:
     m3.c:
     foo.o1.c:
     $ gcc -bundle m1.o m2.o m3.o foo.o1.o -o foo.o1
     $ gsi foo.o1
     ((2 . 2) (4 . 4) (8 . 8) (16 . 16))

   Here is an example under Linux:

     $ uname -srmp
     Linux 2.6.8-1.521 i686 athlon
     $ gsc -link -flat -o foo.o1.c m2 m3 > /dev/null
     m2:
     m3:
     $ gsc -cc-options "-D___DYNAMIC" -obj m1.c m2.c m3.c foo.o1.c
     m1.c:
     m2.c:
     m3.c:
     foo.o1.c:
     $ gcc -shared m1.o m2.o m3.o foo.o1.o -o foo.o1
     $ gsi foo.o1
     ((2 . 2) (4 . 4) (8 . 8) (16 . 16))

   Here is a more complex example, under Solaris, which shows how to
build a loadable library `mymod.o1' composed of the files `m4.scm',
`m5.scm' and `x.c' that links to system shared libraries (for
X-windows):

     $ uname -srmp
     SunOS ungava 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-20
     $ gsc -link -flat -o mymod.o1.c m4 m5
     m4:
     m5:
     *** WARNING -- "*" is not defined,
     ***            referenced in: ("m4.c")
     *** WARNING -- "+" is not defined,
     ***            referenced in: ("m5.c")
     *** WARNING -- "display" is not defined,
     ***            referenced in: ("m5.c" "m4.c")
     *** WARNING -- "newline" is not defined,
     ***            referenced in: ("m5.c" "m4.c")
     *** WARNING -- "write" is not defined,
     ***            referenced in: ("m5.c")
     $ gsc -cc-options "-D___DYNAMIC" -obj m4.c m5.c x.c mymod.o1.c
     m4.c:
     m5.c:
     x.c:
     mymod.o1.c:
     $ /usr/ccs/bin/ld -G -o mymod.o1 mymod.o1.o m4.o m5.o x.o -lX11 -lsocket
     $ gsi mymod.o1
     hello from m4
     hello from m5
     (f1 10) = 22
     $ cat m4.scm
     (define (f1 x) (* 2 (f2 x)))
     (display "hello from m4")
     (newline)

     (c-declare #<<c-declare-end
     #include "x.h"
     c-declare-end
     )
     (define x-initialize (c-lambda (char-string) bool "x_initialize"))
     (define x-display-name (c-lambda () char-string "x_display_name"))
     (define x-bell (c-lambda (int) void "x_bell"))
     $ cat m5.scm
     (define (f2 x) (+ x 1))
     (display "hello from m5")
     (newline)

     (display "(f1 10) = ")
     (write (f1 10))
     (newline)

     (x-initialize (x-display-name))
     (x-bell 50) ; sound the bell at 50%
     $ cat x.c
     #include <X11/Xlib.h>

     static Display *display;

     int x_initialize (char *display_name)
     {
       display = XOpenDisplay (display_name);
       return display != NULL;
     }

     char *x_display_name (void)
     {
       return XDisplayName (NULL);
     }

     void x_bell (int volume)
     {
       XBell (display, volume);
       XFlush (display);
     }
     $ cat x.h
     int x_initialize (char *display_name);
     char *x_display_name (void);
     void x_bell (int);


File: gambit.info,  Node: Building a shared-library,  Next: Other compilation options,  Prev: Building a loadable library,  Up: Link files

3.4.3 Building a shared-library
-------------------------------

A shared-library can be built using an incremental link file or a flat
link file.  An incremental link file is normally used when the Gambit
runtime library (or some other library) is to be extended with new
procedures.  A flat link file is mainly useful when building a "primal"
runtime library, which is a library (such as the Gambit runtime
library) that does not extend another library.  When compiling the C
files and link file generated, the flags `-D___LIBRARY' and
`-D___SHARED' must be passed to the C compiler.  The flag `-D___PRIMAL'
must also be passed to the C compiler when a primal library is being
built.

   A shared-library `mylib.so' containing the two first modules of the
previous example can be built this way:

     $ uname -srmp
     Linux bailey 1.2.13 #2 Wed Aug 28 16:29:41 GMT 1996 i586
     $ gsc -link -o mylib.c m2
     $ gsc -obj -cc-options "-D___SHARED" m1.c m2.c mylib.c
     m1.c:
     m2.c:
     mylib.c:
     $ gcc -shared  m1.o m2.o mylib.o -o mylib.so

   Note that this shared-library is built using an incremental link file
(it extends the Gambit runtime library with the procedures `pow2' and
`twice').  This shared-library can in turn be used to build an
executable program from the third module of the previous example:

     $ gsc -link -l mylib m3
     $ gsc -obj m3.c m3_.c
     m3.c:
     m3_.c:
     $ gcc m3.o m3_.o mylib.so -lgambit
     $ LD_LIBRARY_PATH=.:/usr/local/lib ./a.out
     ((2 . 2) (4 . 4) (8 . 8) (16 . 16))


File: gambit.info,  Node: Other compilation options,  Prev: Building a shared-library,  Up: Link files

3.4.4 Other compilation options
-------------------------------

The performance of the code can be increased by passing the
`-D___SINGLE_HOST' flag to the C compiler.  This will merge all the
procedures of a module into a single C procedure, which reduces the
cost of intra-module procedure calls.  In addition the `-O' option can
be passed to the C compiler.  For large modules, it will not be
practical to specify both `-O' and `-D___SINGLE_HOST' for typical C
compilers because the compile time will be high and the C compiler
might even fail to compile the program for lack of memory.  It has been
observed that lower levels of optimization (e.g. `-O1') often give
faster compilation and also generate faster code.  It is a good idea to
experiment.

   Normally C compilers will not automatically search
`/usr/local/Gambit/include' for header files so the flag
`-I/usr/local/Gambit/include' should be passed to the C compiler.
Similarly, C compilers/linkers will not automatically search
`/usr/local/Gambit/lib' for libraries so the flag
`-L/usr/local/Gambit/lib' should be passed to the C compiler/linker.
Alternatives are given in *Note Accessing the system files::.

   A variety of flags are needed by some C compilers when compiling a
shared-library or a dynamically loadable library.  Some of these flags
are: `-shared', `-call_shared', `-rdynamic', `-fpic', `-fPIC', `-Kpic',
`-KPIC', `-pic', `+z', `-G'.  Check your compiler's documentation to see
which flag you need.


File: gambit.info,  Node: Procedures specific to compiler,  Prev: Link files,  Up: GSC

3.5 Procedures specific to compiler
===================================

The Gambit Scheme compiler features the following procedures that are
not available in the Gambit Scheme interpreter.

 -- procedure: compile-file-to-target FILE [`options:' OPTIONS]
          [`output:' OUTPUT] [`module-name:' MODULE-NAME]
          [`linker-name:' LINKER-NAME] [`expression:' EXPRESSION]
     The FILE parameter must be a string.  If EXPRESSION is not
     specified, FILE must name an existing file containing Scheme
     source code.  The extension can be omitted from FILE when the
     Scheme file has a `.scm' or `.six' extension.  By default, this
     procedure compiles the source file into a file containing C code.
     A different target language can be selected in the OPTIONS.  The
     generated file is named after FILE with the extension replaced
     with `.c', or an appropriate extension for the target selected.
     The name of the generated file can also be specified directly with
     the OUTPUT parameter.  If OUTPUT is a string naming a directory
     then the generated file is created in that directory.  Otherwise
     the name of the generated file is OUTPUT.

     The name of the generated module can be specified with the
     MODULE-NAME parameter.  If MODULE-NAME is `#f' or is not
     specified, then the name of the module is derived from the name of
     the file generated, without the extension.

     The name of the low-level initialization function exported by the
     module can be specified with the LINKER-NAME parameter.  If
     LINKER-NAME is `#f' or is not specified, then the name of the
     function is derived from the name of the module.

     Compilation options are specified through the OPTIONS parameter
     which must be a list of symbols.  Any combination of the following
     options can be used: `target', `verbose', `report', `expansion',
     `gvm', and `debug'.

     When EXPRESSION is specified, the FILE parameter is not open or
     read.  Instead, EXPRESSION is used as though it was the content of
     the file.  This makes it possible to compile source code without
     having to create a file to contain the code.  Note that FILE is
     used in error messages and to determine the output file name if
     OUTPUT is not specified.

     When the compilation is successful, `compile-file-to-target'
     returns the name of the file generated.  When there is a
     compilation error, `#f' is returned.

          $ cat h.scm
          (display "hello") (newline)
          $ gsc
          Gambit v4.9.3

          > (compile-file-to-target "h")
          "/Users/feeley/gambit/doc/h.c"

 -- procedure: compile-file FILE [`options:' OPTIONS] [`output:'
          OUTPUT] [`module-name:' MODULE-NAME] [`linker-name:'
          LINKER-NAME] [`expression:' EXPRESSION] [`cc-options:'
          CC-OPTIONS] [`ld-options-prelude:' LD-OPTIONS-PRELUDE]
          [`ld-options:' LD-OPTIONS]
     The FILE, OPTIONS, OUTPUT, MODULE-NAME, LINKER-NAME, and
     EXPRESSION parameters have the same meaning as for the
     `compile-file-to-target' procedure, except that FILE may be a
     Scheme source file or a file possibly generated by the Gambit
     Scheme compiler (for example with the `compile-file-to-target'
     procedure).  The CC-OPTIONS parameter is a string containing the
     options to pass to the C compiler and the LD-OPTIONS-PRELUDE and
     LD-OPTIONS parameters are strings containing the options to pass
     to the C linker (the options in LD-OPTIONS-PRELUDE are passed to
     the C linker before the input file and the options in LD-OPTIONS
     are passed after).

     The `compile-file' procedure compiles the source file FILE into an
     object file, which is either a file dynamically loadable using the
     `load' procedure, or a C linkable object file destined to be
     linked with the C linker (for example to create a standalone
     executable program).  The presence of the `obj' option in OPTIONS
     will cause the creation of a C linkable object file and therefore
     the options LD-OPTIONS-PRELUDE and LD-OPTIONS are ignored,
     otherwise a dynamically loadable file is created.  In both cases,
     if FILE is a Scheme source file, the compiler first compiles FILE
     to a C file which is created in the same directory as FILE
     regardless of the OUTPUT parameter.  Then the C file is compiled
     with the C compiler.

     When the compilation is successful, `compile-file' returns the
     name of the object file generated.  When there is a compilation
     error, `#f' is returned.

     The name of the object file can be specified with the OUTPUT
     parameter.  If OUTPUT is a string naming a directory then the
     object file is created in that directory.  Otherwise the name of
     the object file is OUTPUT.

     In the case of a dynamically loadable object file, by default the
     object file is named after FILE with the extension replaced with
     `.oN', where N is a positive integer that acts as a version
     number.  The next available version number is generated
     automatically by `compile-file'.

     When dynamically loaded object files are loaded using the `load'
     procedure, the `.oN' extension can be specified (to select a
     particular version) or omitted (to load the file with a `.oN'
     extension with the highest N consecutively from 1).  When the
     `.oN' extension is not specified and older versions are no longer
     needed, all versions must be deleted and the compilation must be
     repeated (this is necessary because the file name, including the
     extension, is used to name some of the exported symbols of the
     object file).

     Note that dynamically loadable object files can only be generated
     on host operating systems that support dynamic loading.

          $ cat h.scm
          (display "hello") (newline)
          $ gsc
          Gambit v4.9.3

          > (compile-file "h")
          "/Users/feeley/gambit/doc/h.o1"
          > (load "h")
          hello
          "/Users/feeley/gambit/doc/h.o1"
          > (compile-file-to-target "h" output: "h.o99.c")
          "/Users/feeley/gambit/doc/h.o99.c"
          > (compile-file "h.o99.c")
          "/Users/feeley/gambit/doc/h.o99"
          > (load "h.o99")
          hello
          "/Users/feeley/gambit/doc/h.o99"
          > (compile-file-to-target "h")
          "/Users/feeley/gambit/doc/h.c"
          > (compile-file "h.c" options: '(obj))
          "/Users/feeley/gambit/doc/h.o"


 -- procedure: link-incremental MODULE-LIST [`output:' OUTPUT]
          [`linker-name:' LINKER-NAME] [`base:' BASE] [`warnings?:'
          WARNINGS?]
     The first parameter must be a non empty list of strings naming
     Scheme modules to link (the file extension may be omitted).  An
     incremental link file is generated for the modules specified in
     MODULE-LIST.  By default the link file generated is named
     `LAST_.c', where LAST is the name of the last module, without the
     file extension.  The name of the generated link file can be
     specified with the OUTPUT parameter.  If OUTPUT is a string naming
     a directory then the link file is created in that directory.
     Otherwise the name of the link file is OUTPUT.

     The base link file is specified by the BASE parameter, which must
     be a string.  By default the base link file is the Gambit runtime
     library link file `~~lib/_gambit.c'.  However, when BASE is
     supplied it is the name of the base link file (the file extension
     may be omitted).

     The WARNINGS? parameter controls whether warnings are generated
     for undefined references.

     The following example shows how to build the executable program
     `hello' which contains the two Scheme modules `h.scm' and `w.six'.

          $ uname -srmp
          Darwin 8.1.0 Power Macintosh powerpc
          $ cat h.scm
          (display "hello") (newline)
          $ cat w.six
          display("world"); newline();
          $ gsc
          Gambit v4.9.3

          > (compile-file-to-target "h")
          "/Users/feeley/gambit/doc/h.c"
          > (compile-file-to-target "w")
          "/Users/feeley/gambit/doc/w.c"
          > (link-incremental '("h" "w") output: "hello.c")
          "/Users/feeley/gambit/doc/hello_.c"
          > ,q
          $ gsc -obj h.c w.c hello.c
          h.c:
          w.c:
          hello.c:
          $ gcc h.o w.o hello.o -lgambit -o hello
          $ ./hello
          hello
          world


 -- procedure: link-flat MODULE-LIST [`output:' OUTPUT] [`linker-name:'
          LINKER-NAME] [`warnings?:' WARNINGS?]
     The first parameter must be a non empty list of strings naming
     Scheme modules to link (the file extension may be omitted).  The
     first string must be the name of a Scheme module or the name of a
     link file and the remaining strings must name Scheme modules.  A
     flat link file is generated for the modules specified in
     MODULE-LIST.  By default the link file generated is named
     `LAST_.c', where LAST is the name of the last module.  The name of
     the generated link file can be specified with the OUTPUT
     parameter.  If OUTPUT is a string naming a directory then the link
     file is created in that directory.  Otherwise the name of the link
     file is OUTPUT.  If a dynamically loadable object file is produced
     from the link file `OUTPUT', then the name of the dynamically
     loadable object file must be `OUTPUT' stripped of its file
     extension.

     The WARNINGS? parameter controls whether warnings are generated
     for undefined references.

     The following example shows how to build the dynamically loadable
     object file `lib.o1' which contains the two Scheme modules
     `m6.scm' and `m7.scm'.

          $ uname -srmp
          Darwin 8.1.0 Power Macintosh powerpc
          $ cat m6.scm
          (define (f x) (g (* x x)))
          $ cat m7.scm
          (define (g y) (+ n y))
          $ gsc
          Gambit v4.9.3

          > (compile-file-to-target "m6")
          "/Users/feeley/gambit/doc/m6.c"
          > (compile-file-to-target "m7")
          "/Users/feeley/gambit/doc/m7.c"
          > (link-flat '("m6" "m7") output: "lib.o1.c")
          *** WARNING -- "*" is not defined,
          ***            referenced in: ("m6.c")
          *** WARNING -- "+" is not defined,
          ***            referenced in: ("m7.c")
          *** WARNING -- "n" is not defined,
          ***            referenced in: ("m7.c")
          "/Users/feeley/gambit/doc/lib.o1.c"
          > ,q
          $ gcc -bundle -D___DYNAMIC m6.c m7.c lib.o1.c -o lib.o1
          $ gsc
          Gambit v4.9.3

          > (load "lib")
          *** WARNING -- Variable "n" used in module "m7" is undefined
          "/Users/feeley/gambit/doc/lib.o1"
          > (define n 10)
          > (f 5)
          35
          > ,q

     The warnings indicate that there are no definitions (`define's or
     `set!'s) of the variables `*', `+' and `n' in the modules
     contained in the library.  Before the library is used, these
     variables will have to be bound; either implicitly (by the runtime
     library) or explicitly.



File: gambit.info,  Node: Runtime options,  Next: Debugging,  Prev: GSC,  Up: Top

4 Runtime options
*****************

Both `gsi' and `gsc' as well as executable programs compiled and linked
using `gsc' take a `-:' option which supplies parameters to the runtime
system.  This option must appear first on the command line.  The colon
is followed by a comma separated list of options with no intervening
spaces.  The available options are:

`mHEAPSIZE'
     Set minimum heap size in kilobytes.

`hHEAPSIZE'
     Set maximum heap size in kilobytes.

`lLIVEPERCENT'
     Set heap occupation after garbage collection.

`s'
     Select standard Scheme mode.

`S'
     Select Gambit Scheme mode.

`d[OPT...]'
     Set debugging options.

`@[INTF][:PORT]'
     Override the configuration of the main RPC server.

`=DIRECTORY'
     Override the central installation directory.

`~~DIR=DIRECTORY'
     Override the DIR installation directory.

`+ARGUMENT'
     Add ARGUMENT to the command line before other arguments.

`f[OPT...]'
     Set file options.

`t[OPT...]'
     Set terminal options.

`-[OPT...]'
     Set standard input and output options.

   The `m' option specifies the minimum size of the heap.  The `m' is
immediately followed by an integer indicating the number of kilobytes
of memory.  The heap will not shrink lower than this size.  By default,
the minimum size is 0.

   The `h' option specifies the maximum size of the heap.  The `h' is
immediately followed by an integer indicating the number of kilobytes
of memory.  The heap will not grow larger than this size.  By default,
there is no limit (i.e.  the heap will grow until the virtual memory is
exhausted).

   The `l' option specifies the percentage of the heap that will be
occupied with live objects after the heap is resized at the end of a
garbage collection.  The `l' is immediately followed by an integer
between 1 and 100 inclusively indicating the desired percentage.  The
garbage collector resizes the heap to reach this percentage occupation.
By default, the percentage is 50.

   The `s' option selects standard Scheme mode.  In this mode the
reader is case-insensitive and keywords are not recognized.  The `S'
option selects Gambit Scheme mode (the reader is case-sensitive and
recognizes keywords which end with a colon).  By default Gambit Scheme
mode is used.

   The `d' option sets various debugging options.  The letter `d' is
followed by a sequence of letters indicating suboptions.

`p'
     Uncaught exceptions will be treated as "errors" in the primordial
     thread only.

`a'
     Uncaught exceptions will be treated as "errors" in all threads.

`r'
     When an "error" occurs a new REPL will be started.

`s'
     When an "error" occurs a new REPL will be started.  Moreover the
     program starts in single-stepping mode.

`q'
     When an "error" occurs the program will terminate with a nonzero
     exit status.

`R'
     When a user interrupt occurs a new REPL will be started.  User
     interrupts are typically obtained by typing <^C>.  Note that with
     some system configurations <^C> abruptly terminates the process.
     For example, under Microsoft Windows, <^C> works fine with the
     standard console but with the MSYS terminal window it terminates
     the process.

`D'
     When a user interrupt occurs it will be deferred until the
     parameter `current-user-interrupt-handler' is bound.

`Q'
     When a user interrupt occurs the program will terminate with a
     nonzero exit status.

`LEVEL'
     The verbosity level is set to LEVEL (a digit from 0 to 9).  At
     level 0 the runtime system will not display error messages and
     warnings.

`i'
     The REPL interaction channel will be the IDE REPL window (if the
     IDE is available).

`c'
     The REPL interaction channel will be the console.

`-'
     The REPL interaction channel will be standard input and standard
     output.

`@[HOST][:PORT]'
     The REPL interaction channel will be connected to the remote
     debugger at address HOST:PORT (if there is a remote debugger at
     that address).  The default HOST is 127.0.0.1 and the default PORT
     is 44555.  THIS OPTION IS NOT YET IMPLEMENTED!


   The default debugging options are equivalent to `-:dpqQ1i' (i.e. an
uncaught exception in the primordial thread terminates the program
after displaying an error message).  When the letter `d' is not
followed by suboptions, it is equivalent to `-:dprR1i' (i.e. a new REPL
is started only when an uncaught exception occurs in the primordial
thread).  When `gsi' and `gsc' are running the main REPL, the debugging
options are changed to cause errors in the primordial thread and user
interrupts to start a nested REPL.

   The `@[INTF][:PORT]' option overrides the configuration of the main
RPC server.  The default INTF is 127.0.0.1 and the default PORT is
44556.  THIS OPTION IS NOT YET IMPLEMENTED!

   The `=DIRECTORY' option overrides the setting of the central
installation directory.

   The `~~DIR=DIRECTORY' option overrides the setting of the DIR
installation directory.

   The `+' option adds the text that follows to the command line before
other arguments.

   The `f', `t' and `-' options specify the default settings of the
ports created for files, terminals and standard input and output
respectively.  The default character encoding, end-of-line encoding and
buffering can be set.  Moreover, for terminals the line-editing feature
can be enabled or disabled.  The `f', `t' and `-' must be followed by a
sequence of these options:

`A'
     ASCII character encoding.

`1'
     ISO-8859-1 character encoding.

`2'
     UCS-2 character encoding.

`4'
     UCS-4 character encoding.

`6'
     UTF-16 character encoding.

`8'
     UTF-8 character encoding.

`U'
     UTF character encoding with fallback to UTF-8 on input if no BOM
     is present.

`UA'
     UTF character encoding with fallback to ASCII on input if no BOM
     is present.

`U1'
     UTF character encoding with fallback to ISO-8859-1 on input if no
     BOM is present.

`U6'
     UTF character encoding with fallback to UTF-16 on input if no BOM
     is present.

`U8'
     UTF character encoding with fallback to UTF-8 on input if no BOM
     is present.

`c'
     End-of-line is encoded as CR (carriage-return).

`l'
     End-of-line is encoded as LF (linefeed)

`cl'
     End-of-line is encoded as CR-LF.

`u'
     Unbuffered I/O.

`n'
     Line buffered I/O (`n' for "at newline").

`f'
     Fully buffered I/O.

`r'
     Illegal character encoding is treated as an error (exception
     raised).

`R'
     Silently replace illegal character encodings with Unicode
     character #xfffd (replacement character).

`e'
     Enable line-editing (applies to terminals only).

`E'
     Disable line-editing (applies to terminals only).

   When a program's execution starts, the runtime system obtains the
runtime options by processing in turn various sources of runtime
options: the defaults, the environment variable `GAMBOPT', the script
line of the source code, and, unless the program is an interpreted
script, the first command line argument of the program.  Any runtime
option can be overriden by a subsequent source of runtime options.  It
is sometimes useful to prevent overriding the runtime options of the
script line.  This can be achieved by starting the script line runtime
options with `-::'.  In this case the environment variable `GAMBOPT' is
ignored, and the first command line argument of the program is not used
for runtime options (it is treated like a normal command line argument
even if it starts with `-:').

   For example:

     $ GAMBOPT=d0,=~/my-gambit2
     $ export GAMBOPT
     $ gsi -e '(pretty-print (path-expand "~~")) (/ 1 0)'
     "/Users/feeley/my-gambit2/"
     $ echo $?
     70
     $ gsi -:d1 -e '(pretty-print (path-expand "~~")) (/ 1 0)'
     "/Users/feeley/my-gambit2/"
     *** ERROR IN (string)@1.3 -- Divide by zero
     (/ 1 0)


File: gambit.info,  Node: Debugging,  Next: Scheme extensions,  Prev: Runtime options,  Up: Top

5 Debugging
***********

* Menu:

* Debugging model::                 Debugging model
* Debugging commands::              Debugging commands
* Debugging example::               Debugging example
* Procedures related to debugging:: Procedures related to debugging
* Console line-editing::            Console line-editing
* Emacs interface::                 Emacs interface
* GUIDE::                           GUIDE


File: gambit.info,  Node: Debugging model,  Next: Debugging commands,  Prev: Debugging,  Up: Debugging

5.1 Debugging model
===================

The evaluation of an expression may stop before it is completed for the
following reasons:

  a. An evaluation error has occured, such as attempting to divide by
     zero.

  b. The user has interrupted the evaluation (usually by typing <^C>).

  c. A breakpoint has been reached or `(step)' was evaluated.

  d. Single-stepping mode is enabled.


   When an evaluation stops, a message is displayed indicating the
reason and location where the evaluation was stopped.  The location
information includes, if known, the name of the procedure where the
evaluation was stopped and the source code location in the format
`STREAM@LINE.COLUMN', where STREAM is either a string naming a file or
a symbol within parentheses, such as `(console)'.

   A "nested REPL" is then initiated in the context of the point of
execution where the evaluation was stopped.  The nested REPL's
continuation and evaluation environment are the same as the point where
the evaluation was stopped.  For example when evaluating the expression
`(let ((y (- 1 1))) (* (/ x y) 2))', a "divide by zero" error is
reported and the nested REPL's continuation is the one that takes the
result and multiplies it by two.  The REPL's lexical environment
includes the lexical variable `y'.  This allows the inspection of the
evaluation context (i.e. the lexical and dynamic environments and
continuation), which is particularly useful to determine the exact
location and cause of an error.

   The prompt of nested REPLs includes the nesting level; `1>' is the
prompt at the first nesting level, `2>' at the second nesting level,
and so on.  An end of file (usually <^D>) will cause the current REPL
to be terminated and the enclosing REPL (one nesting level less) to be
resumed.

   At any time the user can examine the frames in the REPL's
continuation, which is useful to determine which chain of procedure
calls lead to an error.  A backtrace that lists the chain of active
continuation frames in the REPL's continuation can be obtained with the
`,b' command.  The frames are numbered from 0, that is frame 0 is the
most recent frame of the continuation where execution stopped, frame 1
is the parent frame of frame 0, and so on.  It is also possible to move
the REPL to a specific parent continuation (i.e. a specific frame of
the continuation where execution stopped) with the `,N', `,N+', `,N-',
`,+', `,-', `,++', and `,--' commands.  When the frame number of the
frame being examined is not zero, it is shown in the prompt after the
nesting level, for example `1\5>' is the prompt when the REPL nesting
level is 1 and the frame number is 5.

   Expressions entered at a nested REPL are evaluated in the environment
(both lexical and dynamic) of the continuation frame currently being
examined if that frame was created by interpreted Scheme code.  If the
frame was created by compiled Scheme code then expressions get evaluated
in the global interaction environment.  This feature may be used in
interpreted code to fetch the value of a variable in the current frame
or to change its value with `set!'.  Note that some special forms
(`define' in particular) can only be evaluated in the global
interaction environment.


File: gambit.info,  Node: Debugging commands,  Next: Debugging example,  Prev: Debugging model,  Up: Debugging

5.2 Debugging commands
======================

In addition to expressions, the REPL accepts the following special
"comma" commands:

`,?'
     Give a summary of the REPL commands.

`,(h SUBJECT)'
     This command will show the section of the Gambit manual with the
     definition of the procedure or special form SUBJECT, which must be
     a symbol.  For example `,(h time)' will show the section
     documenting the `time' special form.  Please see the `help'
     procedure for additional information.

`,h'
     This command will show the section of the Gambit manual with the
     definition of the procedure which raised the exception for which
     this REPL was started.

`,q'
     Terminate the process with exit status 0.  This is equivalent to
     calling `(exit 0)'.

`,qt'
     Terminate the current thread (note that terminating the primordial
     thread terminates the process).

`,t'
     Return to the outermost REPL, also known as the "top-level REPL".

`,d'
     Leave the current REPL and resume the enclosing REPL.  This
     command does nothing in the top-level REPL.

`,(c EXPR)'
     Leave the current REPL and continue the computation that initiated
     the REPL with a specific value.  This command can only be used to
     continue a computation that signaled an error.  The expression
     EXPR is evaluated in the current context and the resulting value
     is returned as the value of the expression which signaled the
     error.  For example, if the evaluation of the expression `(* (/ x
     y) 2)' signaled an error because `y' is zero, then in the nested
     REPL a `,(c (+ 4 y))' will resume the computation of `(* (/ x y)
     2)' as though the value of `(/ x y)' was 4.  This command must be
     used carefully because the context where the error occured may
     rely on the result being of a particular type.  For instance a
     `,(c #f)' in the previous example will cause `*' to signal a type
     error (this problem is the most troublesome when debugging Scheme
     code that was compiled with type checking turned off so be
     careful).

`,c'
     Leave the current REPL and continue the computation that initiated
     the REPL.  This command can only be used to continue a computation
     that was stopped due to a user interrupt, breakpoint or a
     single-step.

`,s'
     Leave the current REPL and continue the computation that initiated
     the REPL in single-stepping mode.  The computation will perform an
     evaluation step (as defined by `step-level-set!') and then stop,
     causing a nested REPL to be entered.  Just before the evaluation
     step is performed, a line is displayed (in the same format as
     `trace') which indicates the expression that is being evaluated.
     If the evaluation step produces a result, the result is also
     displayed on another line.  A nested REPL is then entered after
     displaying a message which describes the next step of the
     computation.  This command can only be used to continue a
     computation that was stopped due to a user interrupt, breakpoint
     or a single-step.

`,l'
     This command is similar to `,s' except that it "leaps" over
     procedure calls, that is procedure calls are treated like a single
     step.  Single-stepping mode will resume when the procedure call
     returns, or if and when the execution of the called procedure
     encounters a breakpoint.

`,N'
     Move to frame number N of the continuation.  After changing the
     current frame, a one-line summary of the frame is displayed as if
     the `,y' command was entered.

`,N+'
     Move forward by N frames in the chain of continuation frames (i.e.
     towards older continuation frames).  After changing the current
     frame, a one-line summary of the frame is displayed as if the `,y'
     command was entered.

`,N-'
     Move backward by N frames in the chain of continuation frames
     (i.e.  towards more recent continuation frames).  After changing
     the current frame, a one-line summary of the frame is displayed as
     if the `,y' command was entered.

`,+'
     Equivalent to `,1+'.

`,-'
     Equivalent to `,1-'.

`,++'
     Equivalent to `,N+' where N is the number of continuation frames
     displayed at the head of a backtrace.

`,--'
     Equivalent to `,N-' where N is the number of continuation frames
     displayed at the head of a backtrace.

`,y'
     Display a one-line summary of the current frame.  The information
     is displayed in four fields.  The first field is the frame number.
     The second field is the procedure that created the frame or
     `(interaction)' if the frame was created by an expression entered
     at the REPL.  The remaining fields describe the subproblem
     associated with the frame, that is the expression whose value is
     being computed.  The third field is the location of the
     subproblem's source code and the fourth field is a reproduction of
     the source code, possibly truncated to fit on the line.  The last
     two fields may be missing if that information is not available.
     In particular, the third field is missing when the frame was
     created by a user call to the `eval' procedure or by a compiled
     procedure not compiled with the declaration `debug-location', and
     the last field is missing when the frame was created by a compiled
     procedure not compiled with the declaration `debug-source'.

`,b'
     Display a backtrace summarizing each frame in the chain of
     continuation frames starting with the current frame.  For each
     frame, the same information as for the `,y' command is displayed
     (except that location information is displayed in the format
     `STREAM@LINE:COLUMN').  If there are more than 15 frames in the
     chain of continuation frames, some of the middle frames will be
     omitted.

`,be'
     Like the `,b' command but also display the environment.

`,bed'
     Like the `,be' command but also display the dynamic environment.

`,(b EXPR)'
     Display the backtrace of EXPR's value, X, which is obtained by
     evaluating EXPR in the current frame.  X must be a continuation or
     a thread.  When X is a continuation, the frames in that
     continuation are displayed.  When X is a thread, the backtrace of
     the current continuation of that thread is displayed.

`,(be EXPR)'
     Like the `,(b EXPR)' command but also display the environment.

`,(bed EXPR)'
     Like the `,(be EXPR)' command but also display the dynamic
     environment.

`,i'
     Pretty print the procedure that created the current frame or
     `(interaction)' if the frame was created by an expression entered
     at the REPL.  Compiled procedures will only be pretty printed when
     they are compiled with the declaration `debug-source'.

`,e'
     Display the environment which is accessible from the current frame.
     The lexical environment is displayed, followed by the dynamic
     environment if the parameter object
     `repl-display-dynamic-environment?' is not false.  Global lexical
     variables are not displayed.  Moreover the frame must have been
     created by interpreted code or code compiled with the declaration
     `debug-environments'.  Due to space safety considerations and
     compiler optimizations, some of the lexical variable bindings may
     be missing.  Lexical variable bindings are displayed using the
     format `VARIABLE = EXPRESSION' (when VARIABLE is mutable) or
     `VARIABLE == EXPRESSION' (when VARIABLE is immutable, which may
     happen in compiled code due to compiler optimization) and
     dynamically-bound parameter bindings are displayed using the
     format `(PARAMETER) = EXPRESSION'.  Note that EXPRESSION can be a
     self-evaluating expression (number, string, boolean, character,
     ...), a quoted expression, a lambda expression or a global
     variable (the last two cases, which are only used when the value
     of the variable or parameter is a procedure, simplifies the
     debugging of higher-order procedures).  A PARAMETER can be a
     quoted expression or a global variable.  Lexical bindings are
     displayed in inverse binding order (most deeply nested first) and
     shadowed variables are included in the list.

`,ed'
     Like the `,e' command but the dynamic environment is always
     displayed.

`,(e EXPR)'
     Display the environment of EXPR's value, X, which is obtained by
     evaluating EXPR in the current frame.  X must be a continuation, a
     thread, a procedure, or a nonnegative integer.  When X is a
     continuation, the environment at that point in the code is
     displayed.  When X is a thread, the environment of the current
     continuation of that thread is displayed. When X is a procedure,
     the lexical environment where X was created is combined with the
     current continuation and this combined environment is displayed.
     When X is an integer, the environment at frame number X of the
     continuation is displayed.

`,(ed EXPR)'
     Like the `,(e EXPR)' command but the dynamic environment is always
     displayed.

`,st'
     Display the state of the threads in the current thread's thread
     group.  A thread can be: uninitialized, initialized, active, and
     terminated (normally or abnormally).  Active threads can be
     running, sleeping and waiting on a synchronization object (mutex,
     condition variable or port) possibly with a timeout.

`,(st EXPR)'
     Display the state of a specific thread or thread group.  The value
     of EXPR must be a thread or thread group.

`,(v EXPR)'
     Start a new REPL visiting EXPR's value, X, which is obtained by
     evaluating EXPR in the current frame.  X must be a continuation, a
     thread, a procedure, or a nonnegative integer.  When X is a
     continuation, the new REPL's continuation is X and evaluations are
     done in the environment at that point in the code.  When X is a
     thread, the thread is interrupted and the new REPL's continuation
     is the point where the thread was interrupted.  When X is a
     procedure, the lexical environment where X was created is combined
     with the current continuation and evaluations are done in this
     combined environment.  When X is an integer, the REPL is started
     in frame number X of the continuation.



File: gambit.info,  Node: Debugging example,  Next: Procedures related to debugging,  Prev: Debugging commands,  Up: Debugging

5.3 Debugging example
=====================

Here is a sample interaction with `gsi':

     $ gsi
     Gambit v4.9.3

     > (define (invsqr x) (/ 1 (expt x 2)))
     > (define (mymap fn lst)
         (define (mm in)
           (if (null? in)
               '()
               (cons (fn (car in)) (mm (cdr in)))))
         (mm lst))
     > (mymap invsqr '(5 2 hello 9 1))
     *** ERROR IN invsqr, (console)@1.25 -- (Argument 1) NUMBER expected
     (expt 'hello 2)
     1> ,i
     #<procedure #2 invsqr> =
     (lambda (x) (/ 1 (expt x 2)))
     1> ,e
     x = 'hello
     1> ,b
     0  invsqr                    (console)@1:25          (expt x 2)
     1  #<procedure #4>           (console)@6:17          (fn (car in))
     2  #<procedure #4>           (console)@6:31          (mm (cdr in))
     3  #<procedure #4>           (console)@6:31          (mm (cdr in))
     4  (interaction)             (console)@8:1           (mymap invsqr '(5 2 hel...
     1> ,+
     1  #<procedure #4>           (console)@6.17          (fn (car in))
     1\1> (pp #4)
     (lambda (in) (if (null? in) '() (cons (fn (car in)) (mm (cdr in)))))
     1\1> ,e
     in = '(hello 9 1)
     mm = (lambda (in) (if (null? in) '() (cons (fn (car in)) (mm (cdr in)))))
     fn = invsqr
     lst = '(5 2 hello 9 1)
     1\1> ,(e mm)
     mm = (lambda (in) (if (null? in) '() (cons (fn (car in)) (mm (cdr in)))))
     fn = invsqr
     lst = '(5 2 hello 9 1)
     1\1> fn
     #<procedure #2 invsqr>
     1\1> (pp fn)
     (lambda (x) (/ 1 (expt x 2)))
     1\1> ,+
     2  #<procedure #4>           (console)@6.31          (mm (cdr in))
     1\2> ,e
     in = '(2 hello 9 1)
     mm = (lambda (in) (if (null? in) '() (cons (fn (car in)) (mm (cdr in)))))
     fn = invsqr
     lst = '(5 2 hello 9 1)
     1\2> ,(c (list 3 4 5))
     (1/25 1/4 3 4 5)
     > ,q


File: gambit.info,  Node: Procedures related to debugging,  Next: Console line-editing,  Prev: Debugging example,  Up: Debugging

5.4 Procedures related to debugging
===================================

 -- procedure: help SUBJECT
 -- procedure: help-browser [NEW-VALUE]
     The `help' procedure displays the section of the Gambit manual
     with the definition of the procedure or special form SUBJECT,
     which must be a procedure or symbol.  For example the call `(help
     gensym)' will show the section documenting the `gensym' procedure
     and the call `(help 'time)' will show the section documenting the
     `time' special form.  The `help' procedure returns the void object.

     The parameter object `help-browser' is bound to a string naming
     the external program that is used by the `help' procedure to view
     the documentation.  Initially it is bound to the empty string.  In
     normal circumstances when `help-browser' is bound to an empty
     string the `help' procedure runs the script `~~bin/gambdoc.bat'
     which searches for a suitable web browser to open the
     documentation in HTML format.  Unless the system was built with
     the command `configure --enable-help-browser=...', the text-only
     browser `lynx' (see `http://lynx.isc.org/') will be used by
     default if it is available.  We highly recommend that you install
     this browser if you are interested in viewing the documentation
     within the console in which the REPL is running.  You can exit
     `lynx' conveniently by typing an end of file (usually <^D>).

     For example:

          > (help-browser "firefox") ; use firefox instead of lynx
          > (help 'gensym)
          > (help gensym) ; OK because gensym is a procedure
          > (help 'time)
          > (help time) ; not OK because time is a special form
          *** ERROR IN (console)@5.7 -- Macro name can't be used as a variable: time
          >


 -- procedure: repl-result-history-ref I
 -- procedure: repl-result-history-max-length-set! N
     The REPL keeps a history of the last few results printed by the
     REPL. The call `(repl-result-history-ref I)' returns the Ith
     previous result (the last for I=0, the next to last for I=1, etc).
     By default the REPL result history remembers up to 3 results.
     The maximal length of the history can be set to N between 0 and 10
     by a call to `(repl-result-history-max-length-set! N)'.

     For convenience the reader defines an abbreviation for calling
     `repl-result-history-ref'.  Tokens formed by a sequence of one or
     more hash signs, such as ``#'', ``##'', etc, are expanded by the
     reader into the list `(repl-result-history-ref I)', where I is the
     number of hash signs minus 1.  In other words, ``#'' will return
     the last result printed by the REPL, ``##'' will return the next
     to last, etc.

     For example:

          > (map (lambda (x) (* x x)) '(1 2 3))
          (1 4 9)
          > (reverse #)
          (9 4 1)
          > (append # ##)
          (9 4 1 1 4 9)
          > 1
          1
          > 1
          1
          > (+ # ##)
          2
          > (+ # ##)
          3
          > (+ # ##)
          5
          > ####
          *** ERROR IN (console)@9.1 -- (Argument 1) Out of range
          (repl-result-history-ref 3)
          1>


 -- procedure: trace PROC...
 -- procedure: untrace PROC...
     The `trace' procedure starts tracing calls to the specified
     procedures.  When a traced procedure is called, a line containing
     the procedure and its arguments is displayed (using the procedure
     call expression syntax).  The line is indented with a sequence of
     vertical bars which indicate the nesting depth of the procedure's
     continuation.  After the vertical bars is a greater-than sign
     which indicates that the evaluation of the call is starting.

     When a traced procedure returns a result, it is displayed with the
     same indentation as the call but without the greater-than sign.
     This makes it easy to match calls and results (the result of a
     given call is the value at the same indentation as the
     greater-than sign).  If a traced procedure P1 performs a tail call
     to a traced procedure P2, then P2 will use the same indentation as
     P1.  This makes it easy to spot tail calls.  The special handling
     for tail calls is needed to preserve the space complexity of the
     program (i.e. tail calls are implemented as required by Scheme
     even when they involve traced procedures).

     The `untrace' procedure stops tracing calls to the specified
     procedures.  When no argument is passed to the `trace' procedure,
     the list of procedures currently being traced is returned.  The
     void object is returned by the `trace' procedure when it is passed
     one or more arguments.  When no argument is passed to the
     `untrace' procedure stops all tracing and returns the void object.
     A compiled procedure may be traced but only if it is bound to a
     global variable.

     For example:

          > (define (fact n) (if (< n 2) 1 (* n (fact (- n 1)))))
          > (trace fact)
          > (fact 5)
          | > (fact 5)
          | | > (fact 4)
          | | | > (fact 3)
          | | | | > (fact 2)
          | | | | | > (fact 1)
          | | | | | 1
          | | | | 2
          | | | 6
          | | 24
          | 120
          120
          > (trace -)
          *** WARNING -- Rebinding global variable "-" to an interpreted procedure
          > (define (fact-iter n r) (if (< n 2) r (fact-iter (- n 1) (* n r))))
          > (trace fact-iter)
          > (fact-iter 5 1)
          | > (fact-iter 5 1)
          | | > (- 5 1)
          | | 4
          | > (fact-iter 4 5)
          | | > (- 4 1)
          | | 3
          | > (fact-iter 3 20)
          | | > (- 3 1)
          | | 2
          | > (fact-iter 2 60)
          | | > (- 2 1)
          | | 1
          | > (fact-iter 1 120)
          | 120
          120
          > (trace)
          (#<procedure #2 fact-iter> #<procedure #3 -> #<procedure #4 fact>)
          > (untrace)
          > (fact 5)
          120


 -- procedure: step
 -- procedure: step-level-set! LEVEL
     The `step' procedure enables single-stepping mode.  After the call
     to `step' the computation will stop just before the interpreter
     executes the next evaluation step (as defined by
     `step-level-set!').  A nested REPL is then started.  Note that
     because single-stepping is stopped by the REPL whenever the prompt
     is displayed it is pointless to enter `(step)' by itself.  On the
     other hand entering `(begin (step) EXPR)' will evaluate EXPR in
     single-stepping mode.

     The procedure `step-level-set!' sets the stepping level which
     determines the granularity of the evaluation steps when
     single-stepping is enabled.  The stepping level LEVEL must be an
     exact integer in the range 0 to 7.  At a level of 0, the
     interpreter ignores single-stepping mode.  At higher levels the
     interpreter stops the computation just before it performs the
     following operations, depending on the stepping level:

       1. procedure call

       2. `delay' special form and operations at lower levels

       3. `lambda' special form and operations at lower levels

       4. `define' special form and operations at lower levels

       5. `set!' special form and operations at lower levels

       6. variable reference and operations at lower levels

       7. constant reference and operations at lower levels


     The default stepping level is 7.

     For example:

          > (define (fact n) (if (< n 2) 1 (* n (fact (- n 1)))))
          > (step-level-set! 1)
          > (begin (step) (fact 5))
          *** STOPPED IN (console)@3.15
          1> ,s
          | > (fact 5)
          *** STOPPED IN fact, (console)@1.22
          1> ,s
          | | > (< n 2)
          | | #f
          *** STOPPED IN fact, (console)@1.43
          1> ,s
          | | > (- n 1)
          | | 4
          *** STOPPED IN fact, (console)@1.37
          1> ,s
          | | > (fact (- n 1))
          *** STOPPED IN fact, (console)@1.22
          1> ,s
          | | | > (< n 2)
          | | | #f
          *** STOPPED IN fact, (console)@1.43
          1> ,s
          | | | > (- n 1)
          | | | 3
          *** STOPPED IN fact, (console)@1.37
          1> ,l
          | | | > (fact (- n 1))
          *** STOPPED IN fact, (console)@1.22
          1> ,l
          | | > (* n (fact (- n 1)))
          | | 24
          *** STOPPED IN fact, (console)@1.32
          1> ,l
          | > (* n (fact (- n 1)))
          | 120
          120


 -- procedure: break PROC...
 -- procedure: unbreak PROC...
     The `break' procedure places a breakpoint on each of the specified
     procedures.  When a procedure is called that has a breakpoint, the
     interpreter will enable single-stepping mode (as if `step' had
     been called).  This typically causes the computation to stop soon
     inside the procedure if the stepping level is high enough.

     The `unbreak' procedure removes the breakpoints on the specified
     procedures.  With no argument, `break' returns the list of
     procedures currently containing breakpoints.  The void object is
     returned by `break' if it is passed one or more arguments.  With
     no argument `unbreak' removes all the breakpoints and returns the
     void object.  A breakpoint can be placed on a compiled procedure
     but only if it is bound to a global variable.

     For example:

          > (define (double x) (+ x x))
          > (define (triple y) (- (double (double y)) y))
          > (define (f z) (* (triple z) 10))
          > (break double)
          > (break -)
          *** WARNING -- Rebinding global variable "-" to an interpreted procedure
          > (f 5)
          *** STOPPED IN double, (console)@1.21
          1> ,b
          0  double                    (console)@1:21          +
          1  triple                    (console)@2:31          (double y)
          2  f                         (console)@3:18          (triple z)
          3  (interaction)             (console)@6:1           (f 5)
          1> ,e
          x = 5
          1> ,c
          *** STOPPED IN double, (console)@1.21
          1> ,c
          *** STOPPED IN f, (console)@3.29
          1> ,c
          150
          > (break)
          (#<procedure #3 -> #<procedure #4 double>)
          > (unbreak)
          > (f 5)
          150


 -- procedure: generate-proper-tail-calls [NEW-VALUE]
     [Note: this procedure is DEPRECATED and will be removed in a
     future version of Gambit.  Use the `proper-tail-calls' declaration
     instead.]

     The parameter object `generate-proper-tail-calls' is bound to a
     boolean value controlling how the interpreter handles tail calls.
     When it is bound to `#f' the interpreter will treat tail calls
     like nontail calls, that is a new continuation will be created for
     the call.  This setting is useful for debugging, because when a
     primitive signals an error the location information will point to
     the call site of the primitive even if this primitive was called
     with a tail call.  The initial value of this parameter object is
     `#t', which means that a tail call will reuse the continuation of
     the calling function.

     This parameter object only affects code that is subsequently
     processed by `load' or `eval', or entered at the REPL.

     For example:

          > (generate-proper-tail-calls)
          #t
          > (let loop ((i 1)) (if (< i 10) (loop (* i 2)) oops))
          *** ERROR IN #<procedure #2>, (console)@2.47 -- Unbound variable: oops
          1> ,b
          0  #<procedure #2>           (console)@2:47          oops
          1  (interaction)             (console)@2:1           ((letrec ((loop (lambda...
          1> ,t
          > (generate-proper-tail-calls #f)
          > (let loop ((i 1)) (if (< i 10) (loop (* i 2)) oops))
          *** ERROR IN #<procedure #3>, (console)@6.47 -- Unbound variable: oops
          1> ,b
          0  #<procedure #3>           (console)@6:47          oops
          1  #<procedure #3>           (console)@6:32          (loop (* i 2))
          2  #<procedure #3>           (console)@6:32          (loop (* i 2))
          3  #<procedure #3>           (console)@6:32          (loop (* i 2))
          4  #<procedure #3>           (console)@6:32          (loop (* i 2))
          5  (interaction)             (console)@6:1           ((letrec ((loop (lambda...


 -- procedure: display-environment-set! DISPLAY?
     [Note: this procedure is DEPRECATED and will be removed in a
     future version of Gambit.  Use the parameter object
     `repl-display-environment?' instead.]

     This procedure sets a flag that controls the automatic display of
     the environment by the REPL.  If DISPLAY? is true, the environment
     is displayed by the REPL before the prompt.  The default setting is
     not to display the environment.


 -- procedure: repl-display-environment? DISPLAY?
     The parameter object `repl-display-environment?' is bound to a
     boolean value that controls the automatic display of the
     environment by the REPL.  If DISPLAY? is true, the environment is
     displayed by the REPL before the prompt.  This is particularly
     useful in single-stepping mode.  The default setting is not to
     display the environment.


 -- procedure: display-dynamic-environment? DISPLAY?
     The parameter object `display-dynamic-environment?' is bound to a
     boolean value that controls wether the dynamic environment is
     displayed when the environment is displayed.  The default setting
     is not to display the dynamic environment.


 -- procedure: pretty-print OBJ [PORT]
     This procedure pretty-prints OBJ on the port PORT.  If it is not
     specified, PORT defaults to the current output-port.

     For example:

          > (pretty-print
              (let* ((x '(1 2 3 4)) (y (list x x x))) (list y y y)))
          (((1 2 3 4) (1 2 3 4) (1 2 3 4))
           ((1 2 3 4) (1 2 3 4) (1 2 3 4))
           ((1 2 3 4) (1 2 3 4) (1 2 3 4)))


 -- procedure: pp OBJ [PORT]
     This procedure pretty-prints OBJ on the port PORT.  When OBJ is a
     procedure created by the interpreter or a procedure created by
     code compiled with the declaration `debug-source', the procedure's
     source code is displayed.  If it is not specified, PORT defaults
     to the interaction channel (i.e. the output will appear at the
     REPL).

     For example:

          > (define (f g) (+ (time (g 100)) (time (g 1000))))
          > (pp f)
          (lambda (g)
            (+ (##time (lambda () (g 100)) '(g 100))
               (##time (lambda () (g 1000)) '(g 1000))))


 -- procedure: gc-report-set! REPORT?
     This procedure controls the generation of reports during garbage
     collections.  If the argument is true, a brief report of memory
     usage is generated after every garbage collection.  It contains:
     the time taken for this garbage collection, the amount of memory
     allocated in megabytes since the program was started, the size of
     the heap in megabytes, the heap memory in megabytes occupied by
     live data, the proportion of the heap occupied by live data, and
     the number of bytes occupied by movable and nonmovable objects.



File: gambit.info,  Node: Console line-editing,  Next: Emacs interface,  Prev: Procedures related to debugging,  Up: Debugging

5.5 Console line-editing
========================

The console implements a simple Scheme-friendly line-editing
user-interface that is enabled by default.  It offers parentheses
balancing, a history of previous commands, symbol completion, and
several emacs-compatible keyboard commands.  The user's input is
displayed in a bold font and the output produced by the system is in a
plain font.  The history of previous commands is saved in the file
`~/.gambit_history'.  It is restored when a REPL is started.

   Symbol completion is triggered with the tab key.  When the cursor is
after a sequence of characters that can form a symbol, typing the tab
key will search the symbol table for the first symbol (in alphabetical
order) that begins with that sequence and insert that symbol.  Typing
the tab key in succession will cycle through all symbols with that
prefix.  When all possible symbols have been shown or there are no
possible completions, the text reverts to the uncompleted symbol and
the bell is rung.

   Here are the keyboard commands available (where the ``M-'' prefix
means the escape key is typed and the ``C-'' prefix means the control
key is pressed):

`C-d'
     Generate an end-of-file when the line is empty, otherwise delete
     character at cursor.

`delete or backspace'
     Delete character before cursor.

`M-C-d'
     Delete word forward and keep a copy of this text on the clipboard.

`M-delete'
     Delete word backward and keep a copy of this text on the clipboard.

`M-backspace'
     Delete S-expression backward and keep a copy of this text on the
     clipboard.

`C-a'
     Move cursor to beginning of line.

`C-e'
     Move cursor to end of line.

`C-b or left-arrow'
     Move cursor left one character.

`M-b'
     Move cursor left one word.

`M-C-b or `M-'left-arrow'
     Move cursor left one S-expression.

`C-f or right-arrow'
     Move cursor right one character.

`M-f'
     Move cursor right one word.

`M-C-f or `M-'right-arrow'
     Move cursor right one S-expression.

`C-p or `M-p' or up-arrow'
     Move to previous line in history.

`C-n or `M-n' or down-arrow'
     Move to next line in history.

`C-t'
     Transpose character at cursor with previous character.

`M-t'
     Transpose word after cursor with previous word.

`M-C-t'
     Transpose S-expression after cursor with previous S-expression.

`C-l'
     Clear console and redraw line being edited.

`C-nul'
     Set the mark to the cursor.

`C-w'
     Delete the text between the cursor and the mark and keep a copy of
     this text on the clipboard.

`C-k'
     Delete the text from the cursor to the end of the line and keep a
     copy of this text on the clipboard.

`C-y'
     Paste the text that is on the clipboard.

`F8'
     Same as typing `#||#,c;' (REPL command to continue the
     computation).

`F9'
     Same as typing `#||#,-;' (REPL command to move to newer frame).

`F10'
     Same as typing `#||#,+;' (REPL command to move to older frame).

`F11'
     Same as typing `#||#,s;' (REPL command to step the computation).

`F12'
     Same as typing `#||#,l;' (REPL command to leap the computation).


   On Mac OS X, depending on your configuration, you may have to press
the `fn' key to access the function key `F12' and the `option' key to
access the other function keys.

   On Microsoft Windows the clipboard is the system clipboard.  This
allows text to be copied and pasted between the program and other
applications.  On other operating systems the clipboard is internal to
the program (it is not integrated with the operating system).


File: gambit.info,  Node: Emacs interface,  Next: GUIDE,  Prev: Console line-editing,  Up: Debugging

5.6 Emacs interface
===================

Gambit comes with the Emacs package `gambit.el' which provides a nice
environment for running Gambit from within the Emacs editor.  This
package filters the standard output of the Gambit process and when it
intercepts a location information (in the format `STREAM@LINE.COLUMN'
where STREAM is either `(stdin)' when the expression was obtained from
standard input, `(console)' when the expression was obtained from the
console, or a string naming a file) it opens a window to highlight the
corresponding expression.

   To use this package, make sure the file `gambit.el' is accessible
from your load-path and that the following lines are in your `.emacs'
file:

     (autoload 'gambit-inferior-mode "gambit" "Hook Gambit mode into cmuscheme.")
     (autoload 'gambit-mode "gambit" "Hook Gambit mode into scheme.")
     (add-hook 'inferior-scheme-mode-hook (function gambit-inferior-mode))
     (add-hook 'scheme-mode-hook (function gambit-mode))
     (setq scheme-program-name "gsi -:d-")

   Alternatively, if you don't mind always loading this package, you
can simply add this line to your `.emacs' file:

     (require 'gambit)

   You can then start an inferior Gambit process by typing `M-x
run-scheme'.  The commands provided in `cmuscheme' mode will be
available in the Gambit interaction buffer (i.e. `*scheme*') and in
buffers attached to Scheme source files.  Here is a list of the most
useful commands (for a complete list type `C-h m' in the Gambit
interaction buffer):
`C-x C-e'
     Evaluate the expression which is before the cursor (the expression
     will be copied to the Gambit interaction buffer).

`C-c C-z'
     Switch to Gambit interaction buffer.

`C-c C-l'
     Load a file (file attached to current buffer is default) using
     `(load FILE)'.

`C-c C-k'
     Compile a file (file attached to current buffer is default) using
     `(compile-file FILE)'.

   The file `gambit.el' provides these additional commands:

`F8 or C-c c'
     Continue the computation (same as typing `#||#,c;' to the REPL).

`F9 or C-c ]'
     Move to newer frame (same as typing `#||#,-;' to the REPL).

`F10 or C-c ['
     Move to older frame (same as typing `#||#,+;' to the REPL).

`F11 or C-c s'
     Step the computation (same as typing `#||#,s;' to the REPL).

`F12 or C-c l'
     Leap the computation (same as typing `#||#,l;' to the REPL).

`C-c _'
     Removes the last window that was opened to highlight an expression.

   The two keystroke version of these commands can be shortened to
`M-c', `M-[', `M-]', `M-s', `M-l', and `M-_' respectively by adding
this line to your `.emacs' file:

     (setq gambit-repl-command-prefix "\e")

   This is more convenient to type than the two keystroke `C-c' based
sequences but the purist may not like this because it does not follow
normal Emacs conventions.

   Here is what a typical `.emacs' file will look like:

     (setq load-path ; add directory containing gambit.el
       (cons "/usr/local/Gambit/share/emacs/site-lisp"
             load-path))
     (setq scheme-program-name "/tmp/gsi -:d-") ; if gsi not in executable path
     (setq gambit-highlight-color "gray") ; if you don't like the default
     (setq gambit-repl-command-prefix "\e") ; if you want M-c, M-s, etc
     (require 'gambit)


File: gambit.info,  Node: GUIDE,  Prev: Emacs interface,  Up: Debugging

5.7 GUIDE
=========

The implementation and documentation for GUIDE, the Gambit Universal
IDE, are not yet complete.


File: gambit.info,  Node: Scheme extensions,  Next: Namespaces,  Prev: Debugging,  Up: Top

6 Scheme extensions
*******************

* Menu:

* Extensions to standard procedures::    Extensions to standard procedures
* Extensions to standard special forms:: Extensions to standard special forms
* Miscellaneous extensions::             Miscellaneous extensions
* Undocumented extensions::              Undocumented extensions


File: gambit.info,  Node: Extensions to standard procedures,  Next: Extensions to standard special forms,  Prev: Scheme extensions,  Up: Scheme extensions

6.1 Extensions to standard procedures
=====================================

 -- procedure: transcript-on FILE
 -- procedure: transcript-off
     These procedures do nothing.


 -- procedure: call-with-current-continuation PROC
 -- procedure: call/cc PROC
     The procedure `call-with-current-continuation' is bound to the
     global variables `call-with-current-continuation' and `call/cc'.



File: gambit.info,  Node: Extensions to standard special forms,  Next: Miscellaneous extensions,  Prev: Extensions to standard procedures,  Up: Scheme extensions

6.2 Extensions to standard special forms
========================================

 -- special form: lambda lambda-formals body
 -- special form: define (variable define-formals) body
          lambda-formals = `(' formal-argument-list `)' |
          r4rs-lambda-formals

          define-formals = formal-argument-list | r4rs-define-formals

          formal-argument-list = dsssl-formal-argument-list |
          rest-at-end-formal-argument-list

          dsssl-formal-argument-list = reqs opts rest keys

          rest-at-end-formal-argument-list = reqs opts keys rest | reqs
          opts keys `.' rest-formal-argument

          reqs = required-formal-argument*

          required-formal-argument = variable

          opts = `#!optional' optional-formal-argument* | empty

          optional-formal-argument = variable | `(' variable
          initializer `)'

          rest = `#!rest' rest-formal-argument | empty

          rest-formal-argument = variable

          keys = `#!key' keyword-formal-argument* | empty

          keyword-formal-argument = variable | `(' variable initializer
          `)'

          initializer = expression

          r4rs-lambda-formals = `(' variable* `)' | `(' variable+ `.'
          variable `)' | variable

          r4rs-define-formals = variable* | variable* `.' variable

     These forms are extended versions of the `lambda' and `define'
     special forms of standard Scheme.  They allow the use of optional
     formal arguments, either positional or named, and support the
     syntax and semantics of the DSSSL standard.

     When the procedure introduced by a `lambda' (or `define') is
     applied to a list of actual arguments, the formal and actual
     arguments are processed as specified in the R4RS if the
     lambda-formals (or define-formals) is a r4rs-lambda-formals (or
     r4rs-define-formals).

     If the formal-argument-list matches dsssl-formal-argument-list or
     extended-formal-argument-list they are processed as follows:

       a. Variables in required-formal-arguments are bound to
          successive actual arguments starting with the first actual
          argument.  It shall be an error if there are fewer actual
          arguments than required-formal-arguments.

       b. Next variables in optional-formal-arguments are bound to
          remaining actual arguments.  If there are fewer remaining
          actual arguments than optional-formal-arguments, then the
          variables are bound to the result of evaluating initializer,
          if one was specified, and otherwise to `#f'.  The initializer
          is evaluated in an environment in which all previous formal
          arguments have been bound.

       c. If `#!key' does not appear in the formal-argument-list and
          there is no rest-formal-argument then it shall be an error if
          there are any remaining actual arguments.

       d. If `#!key' does not appear in the formal-argument-list and
          there is a rest-formal-argument then the rest-formal-argument
          is bound to a list of all remaining actual arguments.

       e. If `#!key' appears in the formal-argument-list and there is
          no rest-formal-argument then there shall be an even number of
          remaining actual arguments.  These are interpreted as a
          series of pairs, where the first member of each pair is a
          keyword specifying the argument name, and the second is the
          corresponding value.  It shall be an error if the first
          member of a pair is not a keyword.  It shall be an error if
          the argument name is not the same as a variable in a
          keyword-formal-argument.  If the same argument name occurs
          more than once in the list of actual arguments, then the
          first value is used.  If there is no actual argument for a
          particular keyword-formal-argument, then the variable is
          bound to the result of evaluating initializer if one was
          specified, and otherwise to `#f'.  The initializer is
          evaluated in an environment in which all previous formal
          arguments have been bound.

       f. If `#!key' appears in the formal-argument-list and there is a
          rest-formal-argument before the `#!key' then there may be an
          even or odd number of remaining actual arguments and the
          rest-formal-argument is bound to a list of all remaining
          actual arguments.  Then, these remaining actual arguments are
          scanned from left to right in pairs, stopping at the first
          pair whose first element is not a keyword.  Each pair whose
          first element is a keyword matching the name of a
          keyword-formal-argument gives the value (i.e. the second
          element of the pair) of the corresponding formal argument.  If
          the same argument name occurs more than once in the list of
          actual arguments, then the first value is used.  If there is
          no actual argument for a particular keyword-formal-argument,
          then the variable is bound to the result of evaluating
          initializer if one was specified, and otherwise to `#f'.  The
          initializer is evaluated in an environment in which all
          previous formal arguments have been bound.

       g. If `#!key' appears in the formal-argument-list and there is a
          rest-formal-argument after the `#!key' then there may be an
          even or odd number of remaining actual arguments.  The
          remaining actual arguments are scanned from left to right in
          pairs, stopping at the first pair whose first element is not
          a keyword.  Each pair shall have as its first element a
          keyword matching the name of a keyword-formal-argument; the
          second element gives the value of the corresponding formal
          argument.  If the same argument name occurs more than once in
          the list of actual arguments, then the first value is used.
          If there is no actual argument for a particular
          keyword-formal-argument, then the variable is bound to the
          result of evaluating initializer if one was specified, and
          otherwise to `#f'.  The initializer is evaluated in an
          environment in which all previous formal arguments have been
          bound.  Finally, the rest-formal-argument is bound to the
          list of the actual arguments that were not scanned (i.e.
          after the last keyword/value pair).

     In all cases it is an error for a variable to appear more than
     once in a formal-argument-list.

     Note that this specification is compatible with the DSSSL language
     standard (i.e. a correct DSSSL program will have the same semantics
     when run with Gambit).

     It is unspecified whether variables receive their value by binding
     or by assignment.  Currently the compiler and interpreter use
     different methods, which can lead to different semantics if
     `call-with-current-continuation' is used in an initializer.  Note
     that this is irrelevant for DSSSL programs because
     `call-with-current-continuation' does not exist in DSSSL.

     For example:

          > ((lambda (#!rest x) x) 1 2 3)
          (1 2 3)
          > (define (f a #!optional b) (list a b))
          > (define (g a #!optional (b a) #!key (k (* a b))) (list a b k))
          > (define (h1 a #!rest r #!key k) (list a k r))
          > (define (h2 a #!key k #!rest r) (list a k r))
          > (f 1)
          (1 #f)
          > (f 1 2)
          (1 2)
          > (g 3)
          (3 3 9)
          > (g 3 4)
          (3 4 12)
          > (g 3 4 k: 5)
          (3 4 5)
          > (g 3 4 k: 5 k: 6)
          (3 4 5)
          > (h1 7)
          (7 #f ())
          > (h1 7 k: 8 9)
          (7 8 (k: 8 9))
          > (h1 7 k: 8 z: 9)
          (7 8 (k: 8 z: 9))
          > (h2 7)
          (7 #f ())
          > (h2 7 k: 8 9)
          (7 8 (9))
          > (h2 7 k: 8 z: 9)
          *** ERROR IN (console)@17.1 -- Unknown keyword argument passed to procedure
          (h2 7 k: 8 z: 9)



File: gambit.info,  Node: Miscellaneous extensions,  Next: Undocumented extensions,  Prev: Extensions to standard special forms,  Up: Scheme extensions

6.3 Miscellaneous extensions
============================

 -- procedure: vector-copy VECTOR
     This procedure returns a newly allocated vector with the same
     content as the vector VECTOR.  Note that the elements are not
     recursively copied.

     For example:

          > (define v1 '#(1 2 3))
          > (define v2 (vector-copy v1))
          > v2
          #(1 2 3)
          > (eq? v1 v2)
          #f


 -- procedure: subvector VECTOR START END
     This procedure is the vector analog of the `substring' procedure.
     It returns a newly allocated vector formed from the elements of
     the vector VECTOR beginning with index START (inclusive) and
     ending with index END (exclusive).

     For example:

          > (subvector '#(a b c d e f) 3 5)
          #(d e)


 -- procedure: vector-append VECTOR...
     This procedure is the vector analog of the `string-append'
     procedure.  It returns a newly allocated vector whose elements
     form the concatenation of the given vectors.

     For example:

          > (define v '#(1 2 3))
          > (vector-append v v v)
          #(1 2 3 1 2 3 1 2 3)


 -- procedure: append-vectors LST
     This procedure returns a newly allocated vector whose elements form
     the concatenation of all the vectors in the list LST. It is
     equivalent to `(apply vector-append LST)'.

     For example:

          > (define v '#(1 2 3))
          > (append-vectors (list v v v))
          #(1 2 3 1 2 3 1 2 3)


 -- procedure: subvector-fill! VECTOR START END FILL
     This procedure is like `vector-fill!', but fills a selected part
     of the given vector. It sets the elements of the vector VECTOR,
     beginning with index START (inclusive) and ending with index END
     (exclusive) to FILL.  The value returned is unspecified.

     For example:

          > (define v (vector 'a 'b 'c 'd 'e 'f))
          > (subvector-fill! v 3 5 'x)
          > v
          #(a b c x x f)


 -- procedure: subvector-move! SRC-VECTOR SRC-START SRC-END DST-VECTOR
          DST-START
     This procedure replaces part of the contents of vector DST-VECTOR
     with part of the contents of vector SRC-VECTOR. It copies elements
     from SRC-VECTOR, beginning with index SRC-START (inclusive) and
     ending with index SRC-END (exclusive) to DST-VECTOR beginning with
     index DST-START (inclusive).  The value returned is unspecified.

     For example:

          > (define v1 '#(1 2 3 4 5 6))
          > (define v2 (vector 'a 'b 'c 'd 'e 'f))
          > (subvector-move! v1 3 5 v2 1)
          > v2
          #(a 4 5 d e f)


 -- procedure: vector-shrink! VECTOR K
     This procedure shortens the vector VECTOR so that its new size is
     K.  The value returned is unspecified.

     For example:

          > (define v (vector 'a 'b 'c 'd 'e 'f))
          > v
          #(a b c d e f)
          > (vector-shrink! v 3)
          > v
          #(a b c)


 -- procedure: append-strings LST
     This procedure returns a newly allocated string whose elements form
     the concatenation of all the strings in the list LST. It is
     equivalent to `(apply string-append LST)'.

     For example:

          > (define s "abc")
          > (append-strings (list s s s))
          "abcabcabc"


 -- procedure: substring-fill! STRING START END FILL
     This procedure is like `string-fill!', but fills a selected part
     of the given string. It sets the elements of the string STRING,
     beginning with index START (inclusive) and ending with index END
     (exclusive) to FILL.  The value returned is unspecified.

     For example:

          > (define s (string #\a #\b #\c #\d #\e #\f))
          > (substring-fill! s 3 5 #\x)
          > s
          "abcxxf"


 -- procedure: substring-move! SRC-STRING SRC-START SRC-END DST-STRING
          DST-START
     This procedure replaces part of the contents of string DST-STRING
     with part of the contents of string SRC-STRING. It copies elements
     from SRC-STRING, beginning with index SRC-START (inclusive) and
     ending with index SRC-END (exclusive) to DST-STRING beginning with
     index DST-START (inclusive).  The value returned is unspecified.

     For example:

          > (define s1 "123456")
          > (define s2 (string #\a #\b #\c #\d #\e #\f))
          > (substring-move! s1 3 5 s2 1)
          > s2
          "a45def"


 -- procedure: string-shrink! STRING K
     This procedure shortens the string STRING so that its new size is
     K.  The value returned is unspecified.

     For example:

          > (define s (string #\a #\b #\c #\d #\e #\f))
          > s
          "abcdef"
          > (string-shrink! s 3)
          > s
          "abc"


 -- procedure: box OBJ
 -- procedure: box? OBJ
 -- procedure: unbox BOX
 -- procedure: set-box! BOX OBJ
     These procedures implement the "box" data type.  A box is a cell
     containing a single mutable field.  The lexical syntax of a box
     containing the object OBJ is `#&OBJ' (*note Box syntax::).

     The procedure `box' returns a new box object whose content is
     initialized to OBJ.  The procedure `box?' returns `#t' if OBJ is a
     box, and otherwise returns `#f'.  The procedure `unbox' returns
     the content of the box BOX.  The procedure `set-box!' changes the
     content of the box BOX to OBJ.  The procedure `set-box!' returns
     an unspecified value.

     For example:

          > (define b (box 0))
          > b
          #&0
          > (define (inc!) (set-box! b (+ (unbox b) 1)))
          > (inc!)
          > b
          #&1
          > (unbox b)
          1


 -- procedure: keyword? OBJ
 -- procedure: keyword->string KEYWORD
 -- procedure: string->keyword STRING
     These procedures implement the "keyword" data type.  Keywords are
     similar to symbols but are self evaluating and distinct from the
     symbol data type.  The lexical syntax of keywords is specified in
     *Note Keyword syntax::.

     The procedure `keyword?' returns `#t' if OBJ is a keyword, and
     otherwise returns `#f'.  The procedure `keyword->string' returns
     the name of KEYWORD as a string.  The procedure `string->keyword'
     returns the keyword whose name is STRING.

     For example:

          > (keyword? 'color)
          #f
          > (keyword? color:)
          #t
          > (keyword->string color:)
          "color"
          > (string->keyword "color")
          color:


 -- procedure: gensym [PREFIX]
     This procedure returns a new "uninterned symbol".  Uninterned
     symbols are guaranteed to be distinct from the symbols generated
     by the procedures `read' and `string->symbol'.  The symbol PREFIX
     is the prefix used to generate the new symbol's name.  If it is
     not specified, the prefix defaults to `g'.

     For example:

          > (gensym)
          #:g0
          > (gensym)
          #:g1
          > (gensym 'star-trek-)
          #:star-trek-2


 -- procedure: string->uninterned-symbol NAME [HASH]
 -- procedure: uninterned-symbol? OBJ
     The procedure `string->uninterned-symbol' returns a new uninterned
     symbol whose name is NAME and hash is HASH.  The name must be a
     string and the hash must be a nonnegative fixnum.

     The procedure `uninterned-symbol?' returns `#t' when OBJ is a
     symbol that is uninterned and `#f' otherwise.

     For example:

          > (uninterned-symbol? (gensym))
          #t
          > (string->uninterned-symbol "foo")
          #:foo:
          > (uninterned-symbol? (string->uninterned-symbol "foo"))
          #t
          > (uninterned-symbol? 'hello)
          #f
          > (uninterned-symbol? 123)
          #f


 -- procedure: string->uninterned-keyword NAME [HASH]
 -- procedure: uninterned-keyword? OBJ
     The procedure `string->uninterned-keyword' returns a new uninterned
     keyword whose name is NAME and hash is HASH.  The name must be a
     string and the hash must be a nonnegative fixnum.

     The procedure `uninterned-keyword?' returns `#t' when OBJ is a
     keyword that is uninterned and `#f' otherwise.

     For example:

          > (string->uninterned-keyword "foo")
          #:foo:
          > (uninterned-keyword? (string->uninterned-keyword "foo"))
          #t
          > (uninterned-keyword? hello:)
          #f
          > (uninterned-keyword? 123)
          #f


 -- procedure: identity OBJ
     This procedure returns OBJ.


 -- procedure: void
     This procedure returns the void object.  The read-eval-print loop
     prints nothing when the result is the void object.


 -- procedure: eval EXPR [ENV]
     The first parameter is a datum representing an expression.  The
     `eval' procedure evaluates this expression in the global
     interaction environment and returns the result.  If present, the
     second parameter is ignored (it is provided for compatibility with
     R5RS).

     For example:

          > (eval '(+ 1 2))
          3
          > ((eval 'car) '(1 2))
          1
          > (eval '(define x 5))
          > x
          5


 -- special form: include file
     The file parameter must be a string naming an existing file
     containing Scheme source code.  The `include' special form splices
     the content of the specified source file.  This form can only
     appear where a `define' form is acceptable.

     For example:

          (include "macros.scm")

          (define (f lst)
            (include "sort.scm")
            (map sqrt (sort lst)))


 -- special form: define-macro (name define-formals) body
     Define name as a macro special form which expands into body.  This
     form can only appear where a `define' form is acceptable.  Macros
     are lexically scoped.  The scope of a local macro definition
     extends from the definition to the end of the body of the
     surrounding binding construct.  Macros defined at the top level of
     a Scheme module are only visible in that module.  To have access
     to the macro definitions contained in a file, that file must be
     included using the `include' special form.  Macros which are
     visible from the REPL are also visible during the compilation of
     Scheme source files.

     For example:

          (define-macro (unless test . body)
            `(if ,test #f (begin ,@body)))

          (define-macro (push var #!optional val)
            `(set! ,var (cons ,val ,var)))

     To examine the code into which a macro expands you can use the
     compiler's `-expansion' option or the `pp' procedure.  For example:

          > (define-macro (push var #!optional val)
              `(set! ,var (cons ,val ,var)))
          > (pp (lambda () (push stack 1) (push stack) (push stack 3)))
          (lambda ()
            (set! stack (cons 1 stack))
            (set! stack (cons #f stack))
            (set! stack (cons 3 stack)))


 -- special form: define-syntax name expander
     Define name as a macro special form whose expansion is specified
     by expander.  This form is available only when the runtime option
     `-:s' is used.  This option causes the loading of the
     `~~lib/syntax-case' support library, which is the Hieb and Dybvig
     portable `syntax-case' implementation which has been ported to the
     Gambit interpreter and compiler.  Note that this implementation of
     `syntax-case' does not support special forms that are specific to
     Gambit.

     For example:

          $ gsi -:s
          Gambit v4.9.3

          > (define-syntax unless
              (syntax-rules ()
                ((unless test body ...)
                 (if test #f (begin body ...)))))
          > (let ((test 111)) (unless (= 1 2) (list test test)))
          (111 111)
          > (pp (lambda () (let ((test 111)) (unless (= 1 2) (list test test)))))
          (lambda () ((lambda (%%test14) (if (= 1 2) #f (list %%test14 %%test14))) 111))
          > (unless #f (pp xxx))
          *** ERROR IN (console)@7.16 -- Unbound variable: xxx


 -- special form: declare declaration...
     This form introduces declarations to be used by the compiler
     (currently the interpreter ignores the declarations).  This form
     can only appear where a `define' form is acceptable.  Declarations
     are lexically scoped in the same way as macros.  The following
     declarations are accepted by the compiler:

    `(DIALECT)'
          Use the given dialect's semantics.  DIALECT can be:
          `ieee-scheme', `r4rs-scheme', `r5rs-scheme' or
          `gambit-scheme'.

    `(STRATEGY)'
          Select block compilation or separate compilation.  In block
          compilation, the compiler assumes that global variables
          defined in the current file that are not mutated in the file
          will never be mutated.  STRATEGY can be: `block' or
          `separate'.

    `([not] inline)'
          Allow (or disallow) inlining of user procedures.

    `([not] inline-primitives PRIMITIVE...)'
          The given primitives should (or should not) be inlined if
          possible (all primitives if none specified).

    `(inlining-limit N)'
          Select the degree to which the compiler inlines user
          procedures.  N is the upper-bound, in percent, on code
          expansion that will result from inlining.  Thus, a value of
          300 indicates that the size of the program will not grow by
          more than 300 percent (i.e. it will be at most 4 times the
          size of the original).  A value of 0 disables inlining.  The
          size of a program is the total number of subexpressions it
          contains (i.e. the size of an expression is one plus the size
          of its immediate subexpressions).  The following conditions
          must hold for a procedure to be inlined: inlining the
          procedure must not cause the size of the call site to grow
          more than specified by the inlining limit, the site of
          definition (the `define' or `lambda') and the call site must
          be declared as `(inline)', and the compiler must be able to
          find the definition of the procedure referred to at the call
          site (if the procedure is bound to a global variable, the
          definition site must have a `(block)' declaration).  Note
          that inlining usually causes much less code expansion than
          specified by the inlining limit (an expansion around 10% is
          common for N=350).

    `([not] lambda-lift)'
          Lambda-lift (or don't lambda-lift) locally defined procedures.

    `([not] constant-fold)'
          Allow (or disallow) constant-folding of primitive procedures.

    `([not] standard-bindings VAR...)'
          The given global variables are known (or not known) to be
          equal to the value defined for them in the dialect (all
          variables defined in the standard if none specified).

    `([not] extended-bindings VAR...)'
          The given global variables are known (or not known) to be
          equal to the value defined for them in the runtime system
          (all variables defined in the runtime if none specified).

    `([not] run-time-bindings VAR...)'
          The given global variables will be tested at run time to see
          if they are equal to the value defined for them in the
          runtime system (all variables defined in the runtime if none
          specified).

    `([not] safe)'
          Generate (or don't generate) code that will prevent fatal
          errors at run time.  Note that in `safe' mode certain
          semantic errors will not be checked as long as they can't
          crash the system.  For example the primitive `char=?' may
          disregard the type of its arguments in `safe' as well as `not
          safe' mode.

    `([not] interrupts-enabled)'
          Generate (or don't generate) interrupt checks.  Interrupt
          checks are used to detect user interrupts and also to check
          for stack overflows.  Interrupt checking should not be turned
          off casually.

    `([not] poll-on-return)'
          Generate (or don't generate) interrupt checks on procedure
          returns (when interrupt checking is enabled).  This
          declaration has no effect on the behavior of interrupt
          checking on procedure calls, which is needed to guarantee
          that stack overflows are handled properly.

    `([not] debug)'
          Enable (or disable) the generation of debugging information.
          The kind of debugging information that is generated depends
          on the declarations `debug-location', `debug-source', and
          `debug-environments'.  If any of the command line options
          `-debug', `-debug-location', `-debug-source' and
          `-debug-environments' are present, the `debug' declaration is
          initially enabled, otherwise it is initially disabled.  When
          all kinds of debugging information are generated there is a
          substantial increase in the C compilation time and the size
          of the generated code.  When compiling a 3000 line Scheme
          file it was observed that the total compilation time is 500%
          longer and the executable code is 150% bigger.

    `([not] debug-location)'
          Select (or deselect) source code location debugging
          information.  When this declaration and the `debug'
          declaration are in effect, run time error messages indicate
          the location of the error in the source code file.  If any of
          the command line options `-debug-source' and
          `-debug-environments' are present and `-debug-location' is
          absent, the `debug-location' declaration is initially
          disabled, otherwise it is initially enabled.  When compiling
          a 3000 line Scheme file it was observed that the total
          compilation time is 200% longer and the executable code is
          60% bigger.

    `([not] debug-source)'
          Select (or deselect) source code debugging information.  When
          this declaration and the `debug' declaration are in effect,
          run time error messages indicate the source code, the
          backtraces are more precise, and the `pp' procedure will
          display the source code of compiled procedures.  If any of
          the command line options `-debug-location' and
          `-debug-environments' are present and `-debug-source' is
          absent, the `debug-source' declaration is initially disabled,
          otherwise it is initially enabled.  When compiling a 3000
          line Scheme file it was observed that the total compilation
          time is 90% longer and the executable code is 90% bigger.

    `([not] debug-environments)'
          Select (or deselect) environment debugging information.  When
          this declaration and the `debug' declaration are in effect,
          the debugger will have access to the environments of the
          continuations.  In other words the local variables defined in
          compiled procedures (and not optimized away by the compiler)
          will be shown by the `,e' REPL command.  If any of the
          command line options `-debug-location' and `-debug-source'
          are present and `-debug-environments' is absent, the
          `debug-environments' declaration is initially disabled,
          otherwise it is initially enabled.  When compiling a 3000
          line Scheme file it was observed that the total compilation
          time is 70% longer and the executable code is 40% bigger.

    `([not] proper-tail-calls)'
          Generate (or don't generate) proper tail calls.  When proper
          tail calls are turned off, tail calls are handled like
          non-tail calls, that is a continuation frame will be created
          for all calls regardless of their kind.  This is useful for
          debugging because the caller of a procedure will be visible
          in the backtrace produced by the REPL's `,b' command even
          when the call is a tail call.  Be advised that this does
          cause stack space to be consumed for tail calls which may
          cause the stack to overflow when performing long iterations
          with tail calls (whether they are expressed with a `letrec',
          named `let', `do', or other form).

    `([not] generative-lambda)'
          Force (or don't force) the creation of fresh closures when
          evaluating lambda-expressions.  A fresh closure is always
          created when a lambda-expression has at least one free
          variable (that has not been eliminated by dead-code
          elimination or other compiler optimization) or when the
          generative-lambda declaration is turned on.  When a
          lambda-expression has no free variables and the
          generative-lambda declaration is turned off, the value of the
          lambda-expression may be the same procedure (in the sense of
          `eq?').

    `([not] optimize-dead-local-variables)'
          Remove (or preserve) the dead local variables in the
          environment.  Preserving the dead local variables is useful
          for debugging because continuations will contain the dead
          variables.  Thus, if the code is also compiled with the
          declaration `debug-environments' the `,e', `,ed', `,be', and
          `,bed' REPL commands will display the dead variables.  On the
          other hand, preserving the dead local variables may change
          the space complexity of the program (i.e. some of the data
          that would normally be reclaimed by the garbage collector
          will not be).  Note that due to other compiler optimizations
          some dead local variables may be removed regardless of this
          declaration.

    `([not] optimize-dead-definitions VAR...)'
          Remove (or preserve) the dead toplevel definitions of the
          given global variables (all global variables if none
          specified).  A toplevel definition is dead if it is not
          referenced by toplevel expressions of the program or toplevel
          definitions that aren't dead (regardless of the evaluation of
          its expression causing a side-effect).  When a module is
          separately compiled and some of its definitions are only used
          by other modules, this declaration must be used with care to
          keep definitions that are used by other modules, for example
          if `foo' is referenced in another module the following
          declaration should be used: `(declare (not
          optimize-dead-definitions foo))'.

    `(NUMBER-TYPE PRIMITIVE...)'
          Numeric arguments and result of the specified primitives are
          known to be of the given type (all primitives if none
          specified).  NUMBER-TYPE can be: `generic', `fixnum', or
          `flonum'.

    `(MOSTLY-NUMBER-TYPE PRIMITIVE...)'
          Numeric arguments and result of the specified primitives are
          expected to be most often of the given type (all primitives
          if none specified).  MOSTLY-NUMBER-TYPE can be:
          `mostly-generic', `mostly-fixnum', `mostly-fixnum-flonum',
          `mostly-flonum', or `mostly-flonum-fixnum'.


     The default declarations used by the compiler are equivalent to:

          (declare
            (gambit-scheme)
            (separate)
            (inline)
            (inline-primitives)
            (inlining-limit 370)
            (constant-fold)
            (lambda-lift)
            (not standard-bindings)
            (not extended-bindings)
            (run-time-bindings)
            (safe)
            (interrupts-enabled)
            (not poll-on-return)
            (not debug)           ;; depends on debugging command line options
            (debug-location)      ;; depends on debugging command line options
            (debug-source)        ;; depends on debugging command line options
            (debug-environments)  ;; depends on debugging command line options
            (proper-tail-calls)
            (not generative-lambda)
            (optimize-dead-local-variables)
            (not optimize-dead-definitions)
            (generic)
            (mostly-fixnum-flonum)
          )

     These declarations are compatible with the semantics of R5RS Scheme
     and includes a few procedures from R6RS (mainly fixnum specific and
     flonum specific procedures).  Typically used declarations that
     enhance performance, at the cost of violating the R5RS Scheme
     semantics, are: `(standard-bindings)', `(block)', `(not safe)' and
     `(fixnum)'.



File: gambit.info,  Node: Undocumented extensions,  Prev: Miscellaneous extensions,  Up: Scheme extensions

6.4 Undocumented extensions
===========================

The procedures in this section are not yet documented.

 -- procedure: continuation? OBJ
 -- procedure: continuation-capture PROC
 -- procedure: continuation-graft CONT PROC OBJ...
 -- procedure: continuation-return CONT OBJ...
     These procedures provide access to internal first-class
     continuations which are represented using continuation objects
     distinct from procedures.

     The procedure `continuation?' returns `#t' when OBJ is a
     continuation object and `#f' otherwise.

     The procedure `continuation-capture' is similar to the `call/cc'
     procedure but it represents the continuation with a continuation
     object.  The PROC parameter must be a procedure accepting a single
     argument.  The procedure `continuation-capture' reifies its
     continuation and calls PROC with the corresponding continuation
     object as its sole argument.  Like for `call/cc', the implicit
     continuation of the call to PROC is the implicit continuation of
     the call to `continuation-capture'.

     The procedure `continuation-graft' performs a procedure call to
     the procedure PROC with arguments OBJ... and the implicit
     continuation corresponding to the continuation object CONT.  The
     current continuation of the call to procedure `continuation-graft'
     is ignored.

     The procedure `continuation-return' invokes the implicit
     continuation corresponding to the continuation object CONT with
     the result(s) OBJ....  This procedure can be easily defined in
     terms of `continuation-graft':

          (define (continuation-return cont . objs)
            (continuation-graft (lambda () (apply values objs))))

     For example:

          > (define x #f)
          > (define p (make-parameter 11))
          > (pp (parameterize ((p 22))
                  (cons 33 (continuation-capture
                            (lambda (c) (set! x c) 44)))))
          (33 . 44)
          > x
          #<continuation #2>
          > (continuation-return x 55)
          (33 . 55)
          > (continuation-graft x (lambda () (expt 2 10)))
          (33 . 1024)
          > (continuation-graft x expt 2 10)
          (33 . 1024)
          > (continuation-graft x (lambda () (p)))
          (33 . 22)
          > (define (map-sqrt1 lst)
              (call/cc
               (lambda (k)
                 (map (lambda (x)
                        (if (< x 0)
                            (k 'error)
                            (sqrt x)))
                      lst))))
          > (map-sqrt1 '(1 4 9))
          (1 2 3)
          > (map-sqrt1 '(1 -1 9))
          error
          > (define (map-sqrt2 lst)
              (continuation-capture
               (lambda (c)
                 (map (lambda (x)
                        (if (< x 0)
                            (continuation-return c 'error)
                            (sqrt x)))
                      lst))))
          > (map-sqrt2 '(1 4 9))
          (1 2 3)
          > (map-sqrt2 '(1 -1 9))
          error


 -- procedure: display-exception EXC [PORT]
 -- procedure: display-exception-in-context EXC CONT [PORT]
 -- procedure: display-procedure-environment PROC [PORT]
 -- procedure: display-continuation-environment CONT [PORT]
 -- procedure: display-continuation-dynamic-environment CONT [PORT]

 -- procedure: display-continuation-backtrace CONT [PORT [ALL-FRAMES?
          [DISPLAY-ENV? [MAX-HEAD [MAX-TAIL [DEPTH]]]]]]
     The procedure `display-continuation-backtrace' displays the frames
     of the continuation corresponding to the continuation object CONT
     on the port PORT.  If it is not specified, PORT defaults to the
     current output-port.  The frames are displayed in the same format
     as the REPL's `,b' command.

     The parameter ALL-FRAMES?, which defaults to `#f', controls which
     frames are displayed.  Some frames of ancillary importance, such
     as internal frames created by the interpreter, are not displayed
     when ALL-FRAMES? is `#f'.  Otherwise all frames are displayed.

     The parameter DISPLAY-ENV?, which defaults to `#f', controls if
     the frames are displayed with its environment (the variables
     accessible and their bindings).

     The parameters MAX-HEAD and MAX-TAIL, which default to 10 and 4
     respectively, control how many frames are displayed at the head
     and tail of the continuation.

     The parameter DEPTH, which defaults to 0, causes the frame numbers
     to be offset by that value.

     For example:

          > (define x #f)
          > (define (fib n)
              (if (< n 2)
                  (continuation-capture
                   (lambda (c) (set! x c) 1))
                  (+ (fib (- n 1))
                     (fib (- n 2)))))
          > (fib 10)
          89
          > (display-continuation-backtrace x)
          0  fib             (console)@7:12     (fib (- n 2))
          1  fib             (console)@7:12     (fib (- n 2))
          2  fib             (console)@7:12     (fib (- n 2))
          3  fib             (console)@7:12     (fib (- n 2))
          4  fib             (console)@7:12     (fib (- n 2))
          5  (interaction)   (console)@8:1      (fib 10)
          #f
          > (display-continuation-backtrace x (current-output-port) #t)
          0  fib             (console)@7:12     (fib (- n 2))
          1  fib             (console)@6:9      (+ (fib (- n 1)) (fib (- ...
          2  fib             (console)@7:12     (fib (- n 2))
          3  fib             (console)@6:9      (+ (fib (- n 1)) (fib (- ...
          4  fib             (console)@7:12     (fib (- n 2))
          5  fib             (console)@6:9      (+ (fib (- n 1)) (fib (- ...
          6  fib             (console)@7:12     (fib (- n 2))
          7  fib             (console)@6:9      (+ (fib (- n 1)) (fib (- ...
          8  fib             (console)@7:12     (fib (- n 2))
          9  fib             (console)@6:9      (+ (fib (- n 1)) (fib (- ...
          ...
          13 ##with-no-result-expected-toplevel
          14 ##repl-debug
          15 ##repl-debug-main
          16 ##kernel-handlers
          #f
          > (display-continuation-backtrace x (current-output-port) #f #t)
          0  fib             (console)@7:12     (fib (- n 2))
                  n = 2
          1  fib             (console)@7:12     (fib (- n 2))
                  n = 4
          2  fib             (console)@7:12     (fib (- n 2))
                  n = 6
          3  fib             (console)@7:12     (fib (- n 2))
                  n = 8
          4  fib             (console)@7:12     (fib (- n 2))
                  n = 10
          5  (interaction)   (console)@8:1      (fib 10)
          #f
          > (display-continuation-backtrace x (current-output-port) #f #f 2 1 100)
          100 fib            (console)@7:12     (fib (- n 2))
          101 fib            (console)@7:12     (fib (- n 2))
          ...
          105 (interaction)  (console)@8:1      (fib 10)
          #f


 -- procedure: make-thread-group [NAME [THREAD-GROUP]]
 -- procedure: thread-group? OBJ
 -- procedure: thread-group-name THREAD-GROUP
 -- procedure: thread-group-parent THREAD-GROUP
 -- procedure: thread-group-resume! THREAD-GROUP
 -- procedure: thread-group-suspend! THREAD-GROUP
 -- procedure: thread-group-terminate! THREAD-GROUP
 -- procedure: thread-group->thread-group-list THREAD-GROUP
 -- procedure: thread-group->thread-group-vector THREAD-GROUP
 -- procedure: thread-group->thread-list THREAD-GROUP
 -- procedure: thread-group->thread-vector THREAD-GROUP

 -- procedure: thread-state THREAD
 -- procedure: thread-state-uninitialized? THREAD-STATE
 -- procedure: thread-state-initialized? THREAD-STATE
 -- procedure: thread-state-running? THREAD-STATE
 -- procedure: thread-state-running-processor THREAD-STATE
 -- procedure: thread-state-waiting? THREAD-STATE
 -- procedure: thread-state-waiting-for THREAD-STATE
 -- procedure: thread-state-waiting-timeout THREAD-STATE
 -- procedure: thread-state-normally-terminated? THREAD-STATE
 -- procedure: thread-state-normally-terminated-result THREAD-STATE
 -- procedure: thread-state-abnormally-terminated? THREAD-STATE
 -- procedure: thread-state-abnormally-terminated-reason THREAD-STATE
 -- procedure: top [TIMEOUT [THREAD-GROUP [PORT]]]

 -- procedure: thread-interrupt! THREAD [THUNK]

 -- procedure: thread-suspend! THREAD
 -- procedure: thread-resume! THREAD

 -- procedure: thread-thread-group THREAD

 -- special form: define-type-of-thread name field...

 -- procedure: thread-init! THREAD THUNK [NAME [THREAD-GROUP]]

 -- procedure: initialized-thread-exception? OBJ
 -- procedure: initialized-thread-exception-procedure EXC
 -- procedure: initialized-thread-exception-arguments EXC

 -- procedure: uninitialized-thread-exception? OBJ
 -- procedure: uninitialized-thread-exception-procedure EXC
 -- procedure: uninitialized-thread-exception-arguments EXC

 -- procedure: inactive-thread-exception? OBJ
 -- procedure: inactive-thread-exception-procedure EXC
 -- procedure: inactive-thread-exception-arguments EXC

 -- procedure: rpc-remote-error-exception? OBJ
 -- procedure: rpc-remote-error-exception-procedure EXC
 -- procedure: rpc-remote-error-exception-arguments EXC
 -- procedure: rpc-remote-error-exception-message EXC

 -- procedure: processor? OBJ
 -- procedure: current-processor
 -- procedure: processor-id PROCESSOR

 -- procedure: timeout->time TIMEOUT

 -- procedure: current-second

 -- procedure: current-jiffy

 -- procedure: jiffies-per-second

 -- procedure: get-environment-variable NAME

 -- procedure: get-environment-variables

 -- procedure: open-dummy

 -- procedure: port-settings-set! PORT SETTINGS

 -- procedure: port-io-exception-handler-set! PORT HANDLER

 -- procedure: input-port-bytes-buffered PORT

 -- procedure: input-port-characters-buffered PORT

 -- procedure: nonempty-input-port-character-buffer-exception? OBJ
 -- procedure: nonempty-input-port-character-buffer-exception-arguments
          EXC
 -- procedure: nonempty-input-port-character-buffer-exception-procedure
          EXC

 -- procedure: repl-input-port
 -- procedure: repl-output-port
 -- procedure: console-port

 -- procedure: current-user-interrupt-handler [HANDLER]
 -- procedure: defer-user-interrupts

 -- procedure: primordial-exception-handler EXC

 -- procedure: err-code->string CODE

 -- procedure: foreign? OBJ
 -- procedure: foreign-tags FOREIGN
 -- procedure: foreign-address FOREIGN
 -- procedure: foreign-release! FOREIGN
 -- procedure: foreign-released? FOREIGN

 -- procedure: invalid-hash-number-exception? OBJ
 -- procedure: invalid-hash-number-exception-procedure EXC
 -- procedure: invalid-hash-number-exception-arguments EXC

 -- procedure: tcp-client-local-socket-info TCP-CLIENT-PORT
 -- procedure: tcp-client-peer-socket-info TCP-CLIENT-PORT

 -- procedure: tcp-server-socket-info TCP-SERVER-PORT

 -- procedure: socket-info? OBJ
 -- procedure: socket-info-address SOCKET-INFO
 -- procedure: socket-info-family SOCKET-INFO
 -- procedure: socket-info-port-number SOCKET-INFO

 -- procedure: system-version
 -- procedure: system-version-string

 -- procedure: system-type
 -- procedure: system-type-string
 -- procedure: configure-command-string

 -- procedure: system-stamp

 -- special form: future EXPR
 -- procedure: touch OBJ

 -- procedure: tty? OBJ
 -- procedure: tty-history TTY
 -- procedure: tty-history-set! TTY HISTORY
 -- procedure: tty-history-max-length-set! TTY N
 -- procedure: tty-paren-balance-duration-set! TTY DURATION
 -- procedure: tty-text-attributes-set! TTY ATTRIBUTES
 -- procedure: tty-mode-set! TTY MODE
 -- procedure: tty-type-set! TTY TYPE

 -- procedure: with-input-from-port PORT THUNK
 -- procedure: with-output-to-port PORT THUNK

 -- procedure: input-port-char-position PORT
 -- procedure: output-port-char-position PORT

 -- procedure: open-event-queue N

 -- procedure: main ...

 -- special form: define-record-type ...
 -- special form: define-type ...

 -- special form: namespace ...

 -- special form: this-source-file

 -- special form: receive ...

 -- special form: cond-expand ...

 -- special form: define-cond-expand-feature IDENT ...

 -- special form: case-lambda ...

 -- procedure: list-set LIST K VAL
 -- procedure: list-set! LIST K VAL

 -- procedure: fold PROC BASE LIST ...
 -- procedure: fold-right PROC BASE LIST ...

 -- procedure: iota COUNT [START [STEP]]

 -- procedure: circular-list X Y...

 -- procedure: cons* X Y...

 -- procedure: list-copy LIST

 -- procedure: list-tabulate N INIT-PROC

 -- procedure: make-list N [FILL]

 -- procedure: reverse! LIST

 -- procedure: xcons D A

 -- procedure: take X I
 -- procedure: drop X I

 -- procedure: last PAIR
 -- procedure: last-pair PAIR

 -- procedure: finite? X
 -- procedure: infinite? X
 -- procedure: nan? X

 -- undefined: six.!
 -- special form: six.!x X
 -- special form: six.&x X
 -- special form: six.*x X
 -- special form: six.++x X
 -- special form: six.+x X
 -- special form: six.-x X
 -- special form: six.-x X
 -- special form: six.arrow EXPR IDENT
 -- undefined: six.break
 -- special form: six.call FUNC ARG...
 -- undefined: six.case
 -- undefined: six.clause
 -- special form: six.compound STATEMENT...
 -- special form: six.cons X Y
 -- undefined: six.continue
 -- special form: six.define-procedure IDENT PROC
 -- special form: six.define-variable IDENT TYPE DIMS INIT
 -- special form: six.do-while STAT EXPR
 -- special form: six.dot EXPR IDENT
 -- special form: six.for STAT1 EXPR2 EXPR3 STAT2
 -- undefined: six.goto
 -- special form: six.identifier IDENT
 -- special form: six.if EXPR STAT1 [STAT2]
 -- special form: six.index EXPR1 EXPR2
 -- undefined: six.label
 -- special form: six.list X Y
 -- special form: six.literal VALUE
 -- procedure: six.make-array INIT DIM...
 -- special form: six.new IDENT ARG...
 -- special form: six.null
 -- special form: six.prefix DATUM
 -- special form: six.procedure TYPE PARAMS STAT
 -- special form: six.procedure-body STAT...
 -- undefined: six.return
 -- undefined: six.switch
 -- special form: six.while EXPR STAT...
 -- special form: six.x!=y X Y
 -- special form: six.x%=y X Y
 -- special form: six.x%y X Y
 -- special form: six.x&&y X Y
 -- special form: six.x&=y X Y
 -- special form: six.x&y X Y
 -- special form: six.x*=y X Y
 -- special form: six.x*y X Y
 -- special form: six.x++ X
 -- special form: six.x+=y X Y
 -- special form: six.x+y X Y
 -- special form: |six.x,y| X Y
 -- special form: six.x- X
 -- special form: six.x-=y X Y
 -- special form: six.x-y X Y
 -- special form: six.x/=y X Y
 -- special form: six.x/y X Y
 -- undefined: six.x:-y X Y
 -- special form: six.x:=y X Y
 -- special form: six.x:y X Y
 -- special form: six.x<<=y X Y
 -- special form: six.x<<y X Y
 -- special form: six.x<=y X Y
 -- special form: six.x<y X Y
 -- special form: six.x==y X Y
 -- special form: six.x=y X Y
 -- special form: six.x>=y X Y
 -- special form: six.x>>=y X Y
 -- special form: six.x>>y X Y
 -- special form: six.x>y X Y
 -- special form: six.x?y:z X Y Z
 -- special form: six.x^=y X Y
 -- special form: six.x^y X Y
 -- special form: |six.x\|=y| X Y
 -- special form: |six.x\|y| X Y
 -- special form: |six.x\|\|y| X Y
 -- special form: six.~x X


File: gambit.info,  Node: Namespaces,  Next: Characters and strings,  Prev: Scheme extensions,  Up: Top

7 Namespaces
************

TO DO!


File: gambit.info,  Node: Characters and strings,  Next: Numbers,  Prev: Namespaces,  Up: Top

8 Characters and strings
************************

Gambit supports the Unicode character encoding standard.  Scheme
characters can be any of the characters whose Unicode encoding is in
the range 0 to #x10ffff (inclusive) but not in the range #xd800 to
#xdfff.  Source code can also contain any Unicode character, however to
read such source code properly `gsi' and `gsc' must be told which
character encoding to use for reading the source code (i.e. ASCII,
ISO-8859-1, UTF-8, etc).  This can be done by specifying the runtime
option `-:f' when `gsi' and `gsc' are started.

* Menu:

* Extensions to character procedures:: Extensions to character procedures
* Extensions to string procedures::    Extensions to string procedures


File: gambit.info,  Node: Extensions to character procedures,  Next: Extensions to string procedures,  Prev: Characters and strings,  Up: Characters and strings

8.1 Extensions to character procedures
======================================

 -- procedure: char->integer CHAR
 -- procedure: integer->char N
     The procedure `char->integer' returns the Unicode encoding of the
     character CHAR.

     The procedure `integer->char' returns the character whose Unicode
     encoding is the exact integer N.

     For example:

          > (char->integer #\!)
          33
          > (integer->char 65)
          #\A
          > (integer->char (char->integer #\u1234))
          #\u1234
          > (integer->char #xd800)
          *** ERROR IN (console)@4.1 -- (Argument 1) Out of range
          (integer->char 55296)


 -- procedure: char=? CHAR1...
 -- procedure: char<? CHAR1...
 -- procedure: char>? CHAR1...
 -- procedure: char<=? CHAR1...
 -- procedure: char>=? CHAR1...
 -- procedure: char-ci=? CHAR1...
 -- procedure: char-ci<? CHAR1...
 -- procedure: char-ci>? CHAR1...
 -- procedure: char-ci<=? CHAR1...
 -- procedure: char-ci>=? CHAR1...
     These procedures take any number of arguments including no
     argument.  This is useful to test if the elements of a list are
     sorted in a particular order.  For example, testing that the list
     of characters `lst' is sorted in nondecreasing order can be done
     with the call `(apply char<? lst)'.



File: gambit.info,  Node: Extensions to string procedures,  Prev: Extensions to character procedures,  Up: Characters and strings

8.2 Extensions to string procedures
===================================

 -- procedure: string=? STRING1...
 -- procedure: string<? STRING1...
 -- procedure: string>? STRING1...
 -- procedure: string<=? STRING1...
 -- procedure: string>=? STRING1...
 -- procedure: string-ci=? STRING1...
 -- procedure: string-ci<? STRING1...
 -- procedure: string-ci>? STRING1...
 -- procedure: string-ci<=? STRING1...
 -- procedure: string-ci>=? STRING1...
     These procedures take any number of arguments including no
     argument.  This is useful to test if the elements of a list are
     sorted in a particular order.  For example, testing that the list
     of strings `lst' is sorted in nondecreasing order can be done with
     the call `(apply string<? lst)'.



File: gambit.info,  Node: Numbers,  Next: Homogeneous vectors,  Prev: Characters and strings,  Up: Top

9 Numbers
*********

* Menu:

* Extensions to numeric procedures::     Extensions to numeric procedures
* IEEE floating point arithmetic::       IEEE floating point arithmetic
* Integer square root and nth root::     Integer square root and nth root
* Bitwise-operations on exact integers:: Bitwise-operations on exact integers
* Fixnum specific operations::           Operations on fixnums
* Flonum specific operations::           Operations on flonums
* Pseudo random numbers::                Pseudo random numbers


File: gambit.info,  Node: Extensions to numeric procedures,  Next: IEEE floating point arithmetic,  Prev: Numbers,  Up: Numbers

9.1 Extensions to numeric procedures
====================================

 -- procedure: = Z1...
 -- procedure: < X1...
 -- procedure: > X1...
 -- procedure: <= X1...
 -- procedure: >= X1...
     These procedures take any number of arguments including no
     argument.  This is useful to test if the elements of a list are
     sorted in a particular order.  For example, testing that the list
     of numbers `lst' is sorted in nondecreasing order can be done with
     the call `(apply < lst)'.



File: gambit.info,  Node: IEEE floating point arithmetic,  Next: Integer square root and nth root,  Prev: Extensions to numeric procedures,  Up: Numbers

9.2 IEEE floating point arithmetic
==================================

To better conform to IEEE floating point arithmetic the standard
numeric tower is extended with these special inexact reals:

`+inf.0'
     positive infinity

`-inf.0'
     negative infinity

`+nan.0'
     "not a number"

`-0.'
     negative zero (`0.' is the positive zero)

   The infinities and "not a number" are reals (i.e. `(real?  +inf.0)'
is `#t') but are not rational (i.e. `(rational?  +inf.0)' is `#f').

   Both zeros are numerically equal (i.e. `(= -0. 0.)' is `#t') but are
not equivalent (i.e. `(eqv? -0. 0.)' and `(equal?  -0. 0.)' are `#f').
All numerical comparisons with "not a number", including `(= +nan.0
+nan.0)', are `#f'.


File: gambit.info,  Node: Integer square root and nth root,  Next: Bitwise-operations on exact integers,  Prev: IEEE floating point arithmetic,  Up: Numbers

9.3 Integer square root and nth root
====================================

 -- procedure: integer-sqrt N
     This procedure returns the integer part of the square root of the
     nonnegative exact integer N.

     For example:

          > (integer-sqrt 123)
          11


 -- procedure: integer-nth-root N1 N2
     This procedure returns the integer part of N1 raised to the power
     1/N2, where N1 is a nonnegative exact integer and N2 is a positive
     exact integer.

     For example:

          > (integer-nth-root 100 3)
          4



File: gambit.info,  Node: Bitwise-operations on exact integers,  Next: Fixnum specific operations,  Prev: Integer square root and nth root,  Up: Numbers

9.4 Bitwise-operations on exact integers
========================================

The procedures defined in this section are compatible with the
withdrawn "Integer Bitwise-operation Library SRFI" (SRFI 33).  Note
that some of the procedures specified in SRFI 33 are not provided.

   Most procedures in this section are specified in terms of the binary
representation of exact integers.  The two's complement representation
is assumed where an integer is composed of an infinite number of bits.
The upper section of an integer (the most significant bits) are either
an infinite sequence of ones when the integer is negative, or they are
an infinite sequence of zeros when the integer is nonnegative.

 -- procedure: arithmetic-shift N1 N2
     This procedure returns N1 shifted to the left by N2 bits, that is
     `(floor (* N1 (expt 2 N2)))'.  Both N1 and N2 must be exact
     integers.

     For example:

          > (arithmetic-shift 1000 7)  ; n1=...0000001111101000
          128000
          > (arithmetic-shift 1000 -6) ; n1=...0000001111101000
          15
          > (arithmetic-shift -23 -3)  ; n1=...1111111111101001
          -3


 -- procedure: bitwise-merge N1 N2 N3
     This procedure returns an exact integer whose bits combine the bits
     from N2 and N3 depending on N1.  The bit at index I of the result
     depends only on the bits at index I in N1, N2 and N3: it is equal
     to the bit in N2 when the bit in N1 is 0 and it is equal to the
     bit in N3 when the bit in N1 is 1.  All arguments must be exact
     integers.

     For example:

          > (bitwise-merge -4 -11 10) ; ...11111100 ...11110101 ...00001010
          9
          > (bitwise-merge 12 -11 10) ; ...00001100 ...11110101 ...00001010
          -7


 -- procedure: bitwise-and N...
     This procedure returns the bitwise "and" of the exact integers
     N....  The value -1 is returned when there are no arguments.

     For example:

          > (bitwise-and 6 12)  ; ...00000110 ...00001100
          4
          > (bitwise-and 6 -4)  ; ...00000110 ...11111100
          4
          > (bitwise-and -6 -4) ; ...11111010 ...11111100
          -8
          > (bitwise-and)
          -1


 -- procedure: bitwise-ior N...
     This procedure returns the bitwise "inclusive-or" of the exact
     integers N....  The value 0 is returned when there are no
     arguments.

     For example:

          > (bitwise-ior 6 12)  ; ...00000110 ...00001100
          14
          > (bitwise-ior 6 -4)  ; ...00000110 ...11111100
          -2
          > (bitwise-ior -6 -4) ; ...11111010 ...11111100
          -2
          > (bitwise-ior)
          0


 -- procedure: bitwise-xor N...
     This procedure returns the bitwise "exclusive-or" of the exact
     integers N....  The value 0 is returned when there are no
     arguments.

     For example:

          > (bitwise-xor 6 12)  ; ...00000110 ...00001100
          10
          > (bitwise-xor 6 -4)  ; ...00000110 ...11111100
          -6
          > (bitwise-xor -6 -4) ; ...11111010 ...11111100
          6
          > (bitwise-xor)
          0


 -- procedure: bitwise-not N
     This procedure returns the bitwise complement of the exact integer
     N.

     For example:

          > (bitwise-not 3)  ; ...00000011
          -4
          > (bitwise-not -1) ; ...11111111
          0


 -- procedure: bit-count N
     This procedure returns the bit count of the exact integer N.  If N
     is nonnegative, the bit count is the number of 1 bits in the two's
     complement representation of N.  If N is negative, the bit count
     is the number of 0 bits in the two's complement representation of
     N.

     For example:

          > (bit-count 0)   ; ...00000000
          0
          > (bit-count 1)   ; ...00000001
          1
          > (bit-count 2)   ; ...00000010
          1
          > (bit-count 3)   ; ...00000011
          2
          > (bit-count 4)   ; ...00000100
          1
          > (bit-count -23) ; ...11101001
          3


 -- procedure: integer-length N
     This procedure returns the bit length of the exact integer N.  If
     N is a positive integer the bit length is one more than the index
     of the highest 1 bit (the least significant bit is at index 0).
     If N is a negative integer the bit length is one more than the
     index of the highest 0 bit.  If N is zero, the bit length is 0.

     For example:

          > (integer-length 0)   ; ...00000000
          0
          > (integer-length 1)   ; ...00000001
          1
          > (integer-length 2)   ; ...00000010
          2
          > (integer-length 3)   ; ...00000011
          2
          > (integer-length 4)   ; ...00000100
          3
          > (integer-length -23) ; ...11101001
          5


 -- procedure: bit-set? N1 N2
     This procedure returns a boolean indicating if the bit at index N1
     of N2 is set (i.e. equal to 1) or not.  Both N1 and N2 must be
     exact integers, and N1 must be nonnegative.

     For example:

          > (map (lambda (i) (bit-set? i -23)) ; ...11101001
                 '(7 6 5 4 3 2 1 0))
          (#t #t #t #f #t #f #f #t)


 -- procedure: any-bits-set? N1 N2
     This procedure returns a boolean indicating if the bitwise and of
     N1 and N2 is different from zero or not.  This procedure is
     implemented more efficiently than the naive definition:

          (define (any-bits-set? n1 n2) (not (zero? (bitwise-and n1 n2))))

     For example:

          > (any-bits-set? 5 10)   ; ...00000101 ...00001010
          #f
          > (any-bits-set? -23 32) ; ...11101001 ...00100000
          #t


 -- procedure: all-bits-set? N1 N2
     This procedure returns a boolean indicating if the bitwise and of
     N1 and N2 is equal to N1 or not.  This procedure is implemented
     more efficiently than the naive definition:

          (define (all-bits-set? n1 n2) (= n1 (bitwise-and n1 n2)))

     For example:

          > (all-bits-set? 1 3) ; ...00000001 ...00000011
          #t
          > (all-bits-set? 7 3) ; ...00000111 ...00000011
          #f


 -- procedure: first-bit-set N
     This procedure returns the bit index of the least significant bit
     of N equal to 1 (which is also the number of 0 bits that are below
     the least significant 1 bit).  This procedure returns `-1' when N
     is zero.

     For example:

          > (first-bit-set 24) ; ...00011000
          3
          > (first-bit-set 0)  ; ...00000000
          -1


 -- procedure: extract-bit-field N1 N2 N3
 -- procedure: test-bit-field? N1 N2 N3
 -- procedure: clear-bit-field N1 N2 N3
 -- procedure: replace-bit-field N1 N2 N3 N4
 -- procedure: copy-bit-field N1 N2 N3 N4
     These procedures operate on a bit-field which is N1 bits wide
     starting at bit index N2.  All arguments must be exact integers
     and N1 and N2 must be nonnegative.

     The procedure `extract-bit-field' returns the bit-field of N3
     shifted to the right so that the least significant bit of the
     bit-field is the least significant bit of the result.

     The procedure `test-bit-field?' returns `#t' if any bit in the
     bit-field of N3 is equal to 1, otherwise `#f' is returned.

     The procedure `clear-bit-field' returns N3 with all bits in the
     bit-field replaced with 0.

     The procedure `replace-bit-field' returns N4 with the bit-field
     replaced with the least-significant N1 bits of N3.

     The procedure `copy-bit-field' returns N4 with the bit-field
     replaced with the (same index and size) bit-field in N3.

     For example:

          > (extract-bit-field 5 2 -37)    ; ...11011011
          22
          > (test-bit-field? 5 2 -37)      ; ...11011011
          #t
          > (test-bit-field? 1 2 -37)      ; ...11011011
          #f
          > (clear-bit-field 5 2 -37)      ; ...11011011
          -125
          > (replace-bit-field 5 2 -6 -37) ; ...11111010 ...11011011
          -21
          > (copy-bit-field 5 2 -6 -37)    ; ...11111010 ...11011011
          -5



File: gambit.info,  Node: Fixnum specific operations,  Next: Flonum specific operations,  Prev: Bitwise-operations on exact integers,  Up: Numbers

9.5 Fixnum specific operations
==============================

 -- procedure: fixnum? OBJ

 -- procedure: fx* N1...

 -- procedure: fx+ N1...

 -- procedure: fx- N1 N2...

 -- procedure: fx< N1...

 -- procedure: fx<= N1...

 -- procedure: fx= N1...

 -- procedure: fx> N1...

 -- procedure: fx>= N1...

 -- procedure: fxabs N

 -- procedure: fxand N1...

 -- procedure: fxarithmetic-shift N1 N2

 -- procedure: fxarithmetic-shift-left N1 N2

 -- procedure: fxarithmetic-shift-right N1 N2

 -- procedure: fxbit-count N

 -- procedure: fxbit-set? N1 N2

 -- procedure: fxeven? N

 -- procedure: fxfirst-bit-set N

 -- procedure: fxif N1 N2 N3

 -- procedure: fxior N1...

 -- procedure: fxlength N

 -- procedure: fxmax N1 N2...

 -- procedure: fxmin N1 N2...

 -- procedure: fxmodulo N1 N2

 -- procedure: fxnegative? N

 -- procedure: fxnot N

 -- procedure: fxodd? N

 -- procedure: fxpositive? N

 -- procedure: fxquotient N1 N2

 -- procedure: fxremainder N1 N2

 -- procedure: fxwrap* N1...

 -- procedure: fxwrap+ N1...

 -- procedure: fxwrap- N1 N2...

 -- procedure: fxwrapabs N

 -- procedure: fxwraparithmetic-shift N1 N2

 -- procedure: fxwraparithmetic-shift-left N1 N2

 -- procedure: fxwraplogical-shift-right N1 N2

 -- procedure: fxwrapquotient N1 N2

 -- procedure: fxxor N1...

 -- procedure: fxzero? N

 -- procedure: fixnum-overflow-exception? OBJ
 -- procedure: fixnum-overflow-exception-procedure EXC
 -- procedure: fixnum-overflow-exception-arguments EXC
     Fixnum-overflow-exception objects are raised by some of the fixnum
     specific procedures when the result is larger than can fit in a
     fixnum.  The parameter EXC must be a fixnum-overflow-exception
     object.

     The procedure `fixnum-overflow-exception?' returns `#t' when OBJ
     is a fixnum-overflow-exception object and `#f' otherwise.

     The procedure `fixnum-overflow-exception-procedure' returns the
     procedure that raised EXC.

     The procedure `fixnum-overflow-exception-arguments' returns the
     list of arguments of the procedure that raised EXC.

     For example:

          > (define (handler exc)
              (if (fixnum-overflow-exception? exc)
                  (list (fixnum-overflow-exception-procedure exc)
                        (fixnum-overflow-exception-arguments exc))
                  'not-fixnum-overflow-exception))
          > (with-exception-catcher
              handler
              (lambda () (fx* 100000 100000)))
          (#<procedure #2 fx*> (100000 100000))



File: gambit.info,  Node: Flonum specific operations,  Next: Pseudo random numbers,  Prev: Fixnum specific operations,  Up: Numbers

9.6 Flonum specific operations
==============================

 -- procedure: flonum? OBJ

 -- procedure: fixnum->flonum N

 -- procedure: fl* X1...

 -- procedure: fl+ X1...

 -- procedure: fl- X1 X2...

 -- procedure: fl/ X1 X2

 -- procedure: fl< X1...

 -- procedure: fl<= X1...

 -- procedure: fl= X1...

 -- procedure: fl> X1...

 -- procedure: fl>= X1...

 -- procedure: flabs X

 -- procedure: flacos X

 -- procedure: flasin X

 -- procedure: flatan X
 -- procedure: flatan Y X

 -- procedure: flceiling X

 -- procedure: flcos X

 -- procedure: fldenominator X

 -- procedure: fleven? X

 -- procedure: flexp X

 -- procedure: flexpt X Y

 -- procedure: flfinite? X

 -- procedure: flfloor X

 -- procedure: flinfinite? X

 -- procedure: flinteger? X

 -- procedure: fllog X

 -- procedure: flmax X1 X2...

 -- procedure: flmin X1 X2...

 -- procedure: flnan? X

 -- procedure: flnegative? X

 -- procedure: flnumerator X

 -- procedure: flodd? X

 -- procedure: flpositive? X

 -- procedure: flround X

 -- procedure: flsin X

 -- procedure: flsqrt X

 -- procedure: fltan X

 -- procedure: fltruncate X

 -- procedure: flzero? X


File: gambit.info,  Node: Pseudo random numbers,  Prev: Flonum specific operations,  Up: Numbers

9.7 Pseudo random numbers
=========================

The procedures and variables defined in this section are compatible
with the "Sources of Random Bits SRFI" (SRFI 27).  The implementation
is based on Pierre L'Ecuyer's MRG32k3a pseudo random number generator.
At the heart of SRFI 27's interface is the random source type which
encapsulates the state of a pseudo random number generator.  The state
of a random source object changes every time a pseudo random number is
generated from this random source object.

 -- variable: default-random-source
     The global variable `default-random-source' is bound to the random
     source object which is used by the `random-integer',
     `random-real', `random-u8vector' and `random-f64vector' procedures.


 -- procedure: random-integer N
     This procedure returns a pseudo random exact integer in the range
     0 to N-1.  The random source object in the global variable
     `default-random-source' is used to generate this number.  The
     parameter N must be a positive exact integer.

     For example:

          > (random-integer 100)
          24
          > (random-integer 100)
          2
          > (random-integer 10000000000000000000000000000000000000000)
          6143360270902284438072426748425263488507


 -- procedure: random-real
     This procedure returns a pseudo random inexact real between, but
     not including, 0 and 1.  The random source object in the global
     variable `default-random-source' is used to generate this number.

     For example:

          > (random-real)
          .24230672079133753
          > (random-real)
          .02317001922506932


 -- procedure: random-u8vector N
     This procedure returns a u8vector of length N containing pseudo
     random exact integers in the range 0 to 255.  The random source
     object in the global variable `default-random-source' is used to
     generate these numbers.  The parameter N must be a nonnegative
     exact integer.

     For example:

          > (random-u8vector 10)
          #u8(200 53 29 202 3 85 208 187 73 219)


 -- procedure: random-f64vector N
     This procedure returns a f64vector of length N containing pseudo
     random inexact reals between, but not including, 0 and 1.  The
     random source object in the global variable
     `default-random-source' is used to generate these numbers.  The
     parameter N must be a nonnegative exact integer.

     For example:

          > (random-f64vector 3)
          #f64(.7145854494613069 .47089632669147946 .5400124875182746)


 -- procedure: make-random-source
     This procedure returns a new random source object initialized to a
     predetermined state (to initialize to a pseudo random state the
     procedure `random-source-randomize!' should be called).

     For example:

          > (define rs (make-random-source))
          > ((random-source-make-integers rs) 10000000)
          8583952


 -- procedure: random-source? OBJ
     This procedure returns `#t' when OBJ is a random source object and
     `#f' otherwise.

     For example:

          > (random-source? default-random-source)
          #t
          > (random-source? 123)
          #f


 -- procedure: random-source-state-ref RANDOM-SOURCE
 -- procedure: random-source-state-set! RANDOM-SOURCE STATE
     The procedure `random-source-state-ref' extracts the state of the
     random source object RANDOM-SOURCE and returns a vector containing
     the state.

     The procedure `random-source-state-set!' restores the state of the
     random source object RANDOM-SOURCE to STATE which must be a vector
     returned from a call to the procedure `random-source-state-ref'.

     For example:

          > (define s (random-source-state-ref default-random-source))
          > (random-integer 10000000000000000000000000000000000000000)
          7583880188903074396261960585615270693321
          > (random-source-state-set! default-random-source s)
          > (random-integer 10000000000000000000000000000000000000000)
          7583880188903074396261960585615270693321


 -- procedure: random-source-randomize! RANDOM-SOURCE
 -- procedure: random-source-pseudo-randomize! RANDOM-SOURCE I J
     These procedures change the state of the random source object
     RANDOM-SOURCE.  The procedure `random-source-randomize!' sets the
     random source object to a state that depends on the current time
     (which for typical uses can be considered to randomly initialize
     the state).  The procedure `random-source-pseudo-randomize!' sets
     the random source object to a state that is determined only by the
     current state and the nonnegative exact integers I and J.  For
     both procedures the value returned is unspecified.

     For example:

          > (define s (random-source-state-ref default-random-source))
          > (random-source-pseudo-randomize! default-random-source 5 99)
          > (random-integer 10000000000000000000000000000000000000000)
          9816755163910623041601722050112674079767
          > (random-source-state-set! default-random-source s)
          > (random-source-pseudo-randomize! default-random-source 5 99)
          > (random-integer 10000000000000000000000000000000000000000)
          9816755163910623041601722050112674079767
          > (random-source-pseudo-randomize! default-random-source 5 99)
          > (random-integer 10000000000000000000000000000000000000000)
          9816755163910623041601722050112674079767
          > (random-source-state-set! default-random-source s)
          > (random-source-randomize! default-random-source)
          > (random-integer 10000000000000000000000000000000000000000)
          2271441220851914333384493143687768110622
          > (random-source-state-set! default-random-source s)
          > (random-source-randomize! default-random-source)
          > (random-integer 10000000000000000000000000000000000000000)
          6247966138948323029033944059178072366895


 -- procedure: random-source-make-integers RANDOM-SOURCE
     This procedure returns a procedure for generating pseudo random
     exact integers using the random source object RANDOM-SOURCE.  The
     returned procedure accepts a single parameter N, a positive exact
     integer, and returns a pseudo random exact integer in the range 0
     to N-1.

     For example:

          > (define rs (make-random-source))
          > (define ri (random-source-make-integers rs))
          > (ri 10000000)
          8583952
          > (ri 10000000)
          2879793


 -- procedure: random-source-make-reals RANDOM-SOURCE [PRECISION]
     This procedure returns a procedure for generating pseudo random
     inexact reals using the random source object RANDOM-SOURCE.  The
     returned procedure accepts no parameters and returns a pseudo
     random inexact real between, but not including, 0 and 1.  The
     optional parameter PRECISION specifies an upper bound on the
     minimum amount by which two generated pseudo-random numbers can be
     separated.

     For example:

          > (define rs (make-random-source))
          > (define rr (random-source-make-reals rs))
          > (rr)
          .857402537562821
          > (rr)
          .2876463473845367


 -- procedure: random-source-make-u8vectors RANDOM-SOURCE
     This procedure returns a procedure for generating pseudo random
     u8vectors using the random source object RANDOM-SOURCE.  The
     returned procedure accepts a single parameter N, a nonnegative
     exact integer, and returns a u8vector of length N containing
     pseudo random exact integers in the range 0 to 255.

     For example:

          > (define rs (make-random-source))
          > (define rv (random-source-make-u8vectors rs))
          > (rv 10)
          #u8(200 53 29 202 3 85 208 187 73 219)
          > (rv 10)
          #u8(113 8 182 120 138 103 53 192 40 176)


 -- procedure: random-source-make-f64vectors RANDOM-SOURCE [PRECISION]
     This procedure returns a procedure for generating pseudo random
     f64vectors using the random source object RANDOM-SOURCE.  The
     returned procedure accepts a single parameter N, a nonnegative
     exact integer, and returns an f64vector of length N containing
     pseudo random inexact reals between, but not including, 0 and 1.
     The optional parameter PRECISION specifies an upper bound on the
     minimum amount by which two generated pseudo-random numbers can be
     separated.

     For example:

          > (define rs (make-random-source))
          > (define rv (random-source-make-f64vectors rs))
          > (rv 3)
          #f64(.7342236104231586 .2876463473845367 .8574025375628211)
          > (rv 3)
          #f64(.013863292728449427 .33449296573515447 .8162050798467028)



File: gambit.info,  Node: Homogeneous vectors,  Next: Hashing and weak references,  Prev: Numbers,  Up: Top

10 Homogeneous vectors
**********************

Homogeneous vectors are vectors containing raw numbers of the same type
(signed or unsigned exact integers or inexact reals).  There are 10
types of homogeneous vectors: `s8vector' (vector of exact integers in
the range -2^7 to 2^7-1), `u8vector' (vector of exact integers in the
range 0 to 2^8-1), `s16vector' (vector of exact integers in the range
-2^15 to 2^15-1), `u16vector' (vector of exact integers in the range 0
to 2^16-1), `s32vector' (vector of exact integers in the range -2^31 to
2^31-1), `u32vector' (vector of exact integers in the range 0 to
2^32-1), `s64vector' (vector of exact integers in the range -2^63 to
2^63-1), `u64vector' (vector of exact integers in the range 0 to
2^64-1), `f32vector' (vector of 32 bit floating point numbers), and
`f64vector' (vector of 64 bit floating point numbers).

   The lexical syntax of homogeneous vectors is specified in *Note
Homogeneous vector syntax::.

   The procedures available for homogeneous vectors, listed below, are
the analog of the normal vector/string procedures for each of the
homogeneous vector types.

 -- procedure: s8vector? OBJ
 -- procedure: make-s8vector K [FILL]
 -- procedure: s8vector EXACT-INT8...
 -- procedure: s8vector-length S8VECTOR
 -- procedure: s8vector-ref S8VECTOR K
 -- procedure: s8vector-set S8VECTOR K EXACT-INT8
 -- procedure: s8vector-set! S8VECTOR K EXACT-INT8
 -- procedure: s8vector->list S8VECTOR
 -- procedure: list->s8vector LIST-OF-EXACT-INT8
 -- procedure: s8vector-fill! S8VECTOR FILL [START [END]]
 -- procedure: subs8vector-fill! VECTOR START END FILL
 -- procedure: append-s8vectors LST
 -- procedure: s8vector-copy S8VECTOR
 -- procedure: s8vector-append S8VECTOR...
 -- procedure: subs8vector S8VECTOR START END
 -- procedure: subs8vector-move! SRC-S8VECTOR SRC-START SRC-END
          DST-S8VECTOR DST-START
 -- procedure: s8vector-shrink! S8VECTOR K

 -- procedure: u8vector? OBJ
 -- procedure: make-u8vector K [FILL]
 -- procedure: u8vector EXACT-INT8...
 -- procedure: u8vector-length U8VECTOR
 -- procedure: u8vector-ref U8VECTOR K
 -- procedure: u8vector-set U8VECTOR K EXACT-INT8
 -- procedure: u8vector-set! U8VECTOR K EXACT-INT8
 -- procedure: u8vector->list U8VECTOR
 -- procedure: list->u8vector LIST-OF-EXACT-INT8
 -- procedure: u8vector-fill! U8VECTOR FILL [START [END]]
 -- procedure: subu8vector-fill! VECTOR START END FILL
 -- procedure: append-u8vectors LST
 -- procedure: u8vector-copy U8VECTOR
 -- procedure: u8vector-append U8VECTOR...
 -- procedure: subu8vector U8VECTOR START END
 -- procedure: subu8vector-move! SRC-U8VECTOR SRC-START SRC-END
          DST-U8VECTOR DST-START
 -- procedure: u8vector-shrink! U8VECTOR K

 -- procedure: s16vector? OBJ
 -- procedure: make-s16vector K [FILL]
 -- procedure: s16vector EXACT-INT16...
 -- procedure: s16vector-length S16VECTOR
 -- procedure: s16vector-ref S16VECTOR K
 -- procedure: s16vector-set S16VECTOR K EXACT-INT16
 -- procedure: s16vector-set! S16VECTOR K EXACT-INT16
 -- procedure: s16vector->list S16VECTOR
 -- procedure: list->s16vector LIST-OF-EXACT-INT16
 -- procedure: s16vector-fill! S16VECTOR FILL [START [END]]
 -- procedure: subs16vector-fill! VECTOR START END FILL
 -- procedure: append-s16vectors LST
 -- procedure: s16vector-copy S16VECTOR
 -- procedure: s16vector-append S16VECTOR...
 -- procedure: subs16vector S16VECTOR START END
 -- procedure: subs16vector-move! SRC-S16VECTOR SRC-START SRC-END
          DST-S16VECTOR DST-START
 -- procedure: s16vector-shrink! S16VECTOR K

 -- procedure: u16vector? OBJ
 -- procedure: make-u16vector K [FILL]
 -- procedure: u16vector EXACT-INT16...
 -- procedure: u16vector-length U16VECTOR
 -- procedure: u16vector-ref U16VECTOR K
 -- procedure: u16vector-set U16VECTOR K EXACT-INT16
 -- procedure: u16vector-set! U16VECTOR K EXACT-INT16
 -- procedure: u16vector->list U16VECTOR
 -- procedure: list->u16vector LIST-OF-EXACT-INT16
 -- procedure: u16vector-fill! U16VECTOR FILL [START [END]]
 -- procedure: subu16vector-fill! VECTOR START END FILL
 -- procedure: append-u16vectors LST
 -- procedure: u16vector-copy U16VECTOR
 -- procedure: u16vector-append U16VECTOR...
 -- procedure: subu16vector U16VECTOR START END
 -- procedure: subu16vector-move! SRC-U16VECTOR SRC-START SRC-END
          DST-U16VECTOR DST-START
 -- procedure: u16vector-shrink! U16VECTOR K

 -- procedure: s32vector? OBJ
 -- procedure: make-s32vector K [FILL]
 -- procedure: s32vector EXACT-INT32...
 -- procedure: s32vector-length S32VECTOR
 -- procedure: s32vector-ref S32VECTOR K
 -- procedure: s32vector-set S32VECTOR K EXACT-INT32
 -- procedure: s32vector-set! S32VECTOR K EXACT-INT32
 -- procedure: s32vector->list S32VECTOR
 -- procedure: list->s32vector LIST-OF-EXACT-INT32
 -- procedure: s32vector-fill! S32VECTOR FILL [START [END]]
 -- procedure: subs32vector-fill! VECTOR START END FILL
 -- procedure: append-s32vectors LST
 -- procedure: s32vector-copy S32VECTOR
 -- procedure: s32vector-append S32VECTOR...
 -- procedure: subs32vector S32VECTOR START END
 -- procedure: subs32vector-move! SRC-S32VECTOR SRC-START SRC-END
          DST-S32VECTOR DST-START
 -- procedure: s32vector-shrink! S32VECTOR K

 -- procedure: u32vector? OBJ
 -- procedure: make-u32vector K [FILL]
 -- procedure: u32vector EXACT-INT32...
 -- procedure: u32vector-length U32VECTOR
 -- procedure: u32vector-ref U32VECTOR K
 -- procedure: u32vector-set U32VECTOR K EXACT-INT32
 -- procedure: u32vector-set! U32VECTOR K EXACT-INT32
 -- procedure: u32vector->list U32VECTOR
 -- procedure: list->u32vector LIST-OF-EXACT-INT32
 -- procedure: u32vector-fill! U32VECTOR FILL [START [END]]
 -- procedure: subu32vector-fill! VECTOR START END FILL
 -- procedure: append-u32vectors LST
 -- procedure: u32vector-copy U32VECTOR
 -- procedure: u32vector-append U32VECTOR...
 -- procedure: subu32vector U32VECTOR START END
 -- procedure: subu32vector-move! SRC-U32VECTOR SRC-START SRC-END
          DST-U32VECTOR DST-START
 -- procedure: u32vector-shrink! U32VECTOR K

 -- procedure: s64vector? OBJ
 -- procedure: make-s64vector K [FILL]
 -- procedure: s64vector EXACT-INT64...
 -- procedure: s64vector-length S64VECTOR
 -- procedure: s64vector-ref S64VECTOR K
 -- procedure: s64vector-set S64VECTOR K EXACT-INT64
 -- procedure: s64vector-set! S64VECTOR K EXACT-INT64
 -- procedure: s64vector->list S64VECTOR
 -- procedure: list->s64vector LIST-OF-EXACT-INT64
 -- procedure: s64vector-fill! S64VECTOR FILL [START [END]]
 -- procedure: subs64vector-fill! VECTOR START END FILL
 -- procedure: append-s64vectors LST
 -- procedure: s64vector-copy S64VECTOR
 -- procedure: s64vector-append S64VECTOR...
 -- procedure: subs64vector S64VECTOR START END
 -- procedure: subs64vector-move! SRC-S64VECTOR SRC-START SRC-END
          DST-S64VECTOR DST-START
 -- procedure: s64vector-shrink! S64VECTOR K

 -- procedure: u64vector? OBJ
 -- procedure: make-u64vector K [FILL]
 -- procedure: u64vector EXACT-INT64...
 -- procedure: u64vector-length U64VECTOR
 -- procedure: u64vector-ref U64VECTOR K
 -- procedure: u64vector-set U64VECTOR K EXACT-INT64
 -- procedure: u64vector-set! U64VECTOR K EXACT-INT64
 -- procedure: u64vector->list U64VECTOR
 -- procedure: list->u64vector LIST-OF-EXACT-INT64
 -- procedure: u64vector-fill! U64VECTOR FILL [START [END]]
 -- procedure: subu64vector-fill! VECTOR START END FILL
 -- procedure: append-u64vectors LST
 -- procedure: u64vector-copy U64VECTOR
 -- procedure: u64vector-append U64VECTOR...
 -- procedure: subu64vector U64VECTOR START END
 -- procedure: subu64vector-move! SRC-U64VECTOR SRC-START SRC-END
          DST-U64VECTOR DST-START
 -- procedure: u64vector-shrink! U64VECTOR K

 -- procedure: f32vector? OBJ
 -- procedure: make-f32vector K [FILL]
 -- procedure: f32vector INEXACT-REAL...
 -- procedure: f32vector-length F32VECTOR
 -- procedure: f32vector-ref F32VECTOR K
 -- procedure: f32vector-set F32VECTOR K INEXACT-REAL
 -- procedure: f32vector-set! F32VECTOR K INEXACT-REAL
 -- procedure: f32vector->list F32VECTOR
 -- procedure: list->f32vector LIST-OF-INEXACT-REAL
 -- procedure: f32vector-fill! F32VECTOR FILL [START [END]]
 -- procedure: subf32vector-fill! VECTOR START END FILL
 -- procedure: append-f32vectors LST
 -- procedure: f32vector-copy F32VECTOR
 -- procedure: f32vector-append F32VECTOR...
 -- procedure: subf32vector F32VECTOR START END
 -- procedure: subf32vector-move! SRC-F32VECTOR SRC-START SRC-END
          DST-F32VECTOR DST-START
 -- procedure: f32vector-shrink! F32VECTOR K

 -- procedure: f64vector? OBJ
 -- procedure: make-f64vector K [FILL]
 -- procedure: f64vector INEXACT-REAL...
 -- procedure: f64vector-length F64VECTOR
 -- procedure: f64vector-ref F64VECTOR K
 -- procedure: f64vector-set F64VECTOR K INEXACT-REAL
 -- procedure: f64vector-set! F64VECTOR K INEXACT-REAL
 -- procedure: f64vector->list F64VECTOR
 -- procedure: list->f64vector LIST-OF-INEXACT-REAL
 -- procedure: f64vector-fill! F64VECTOR FILL [START [END]]
 -- procedure: subf64vector-fill! VECTOR START END FILL
 -- procedure: append-f64vectors LST
 -- procedure: f64vector-copy F64VECTOR
 -- procedure: f64vector-append F64VECTOR...
 -- procedure: subf64vector F64VECTOR START END
 -- procedure: subf64vector-move! SRC-F64VECTOR SRC-START SRC-END
          DST-F64VECTOR DST-START
 -- procedure: f64vector-shrink! F64VECTOR K

   For example:

     > (define v (u8vector 10 255 13))
     > (u8vector-set! v 2 99)
     > v
     #u8(10 255 99)
     > (u8vector-ref v 1)
     255
     > (u8vector->list v)
     (10 255 99)
     > (u8vector-shrink! v 2)
     > (v)
     #u8(10 255)

 -- procedure: object->u8vector OBJ [ENCODER]
 -- procedure: u8vector->object U8VECTOR [DECODER]
     The procedure `object->u8vector' returns a u8vector that contains
     the sequence of bytes that encodes the object OBJ.  The procedure
     `u8vector->object' decodes the sequence of bytes contained in the
     u8vector U8VECTOR, which was produced by the procedure
     `object->u8vector', and reconstructs an object structurally equal
     to the original object.  In other words the procedures
     `object->u8vector' and `u8vector->object' respectively perform
     serialization and deserialization of Scheme objects.  Note that
     some objects are non-serializable (e.g. threads, wills, some types
     of ports, and any object containing a non-serializable object).

     The optional ENCODER and DECODER parameters are single parameter
     procedures which default to the identity function.  The ENCODER
     procedure is called during serialization.  As the serializer walks
     through OBJ, it calls the ENCODER procedure on each sub-object X
     that is encountered.  The ENCODER transforms the object X into an
     object Y that will be serialized instead of X.  Similarly the
     DECODER procedure is called during deserialization.  When an
     object Y is encountered, the DECODER procedure is called to
     transform it into the object X that is the result of
     deserialization.

     The ENCODER and DECODER procedures are useful to customize the
     serialized representation of objects.  In particular, it can be
     used to define the semantics of serializing objects, such as
     threads and ports, that would otherwise not be serializable.  The
     DECODER procedure is typically the inverse of the ENCODER
     procedure, i.e. `(DECODER (ENCODER X))' = `X'.

     For example:

          > (define (make-adder x) (lambda (y) (+ x y)))
          > (define f (make-adder 10))
          > (define a (object->u8vector f))
          > (define b (u8vector->object a))
          > (u8vector-length a)
          1639
          > (f 5)
          15
          > (b 5)
          15
          > (pp b)
          (lambda (y) (+ x y))



File: gambit.info,  Node: Hashing and weak references,  Next: Records,  Prev: Homogeneous vectors,  Up: Top

11 Hashing and weak references
******************************

* Menu:

* Hashing::                         Hashing
* Weak references::                 Weak references


File: gambit.info,  Node: Hashing,  Next: Weak references,  Prev: Hashing and weak references,  Up: Hashing and weak references

11.1 Hashing
============

 -- procedure: object->serial-number OBJ
 -- procedure: serial-number->object N [DEFAULT]
     All Scheme objects are uniquely identified with a serial number
     which is a nonnegative exact integer.  The `object->serial-number'
     procedure returns the serial number of object OBJ.  This serial
     number is only allocated the first time the `object->serial-number'
     procedure is called on that object.  Objects which do not have an
     external textual representation that can be read by the `read'
     procedure, use an external textual representation that includes a
     serial number of the form `#N'.  Consequently, the procedures
     `write', `pretty-print', etc will call the `object->serial-number'
     procedure to get the serial number, and this may cause the serial
     number to be allocated.

     The `serial-number->object' procedure takes an exact integer
     parameter N and returns the object whose serial number is N.  If
     no object currently exists with that serial number, DEFAULT is
     returned if it is specified, otherwise an
     unbound-serial-number-exception object is raised.  The reader
     defines the following abbreviation for calling
     `serial-number->object': the syntax `#N', where N is a sequence of
     decimal digits and it is not followed by ``='' or ``#'', is
     equivalent to the list `(serial-number->object N)'.

     For example:

          > (define z (list (lambda (x) (* x x)) (lambda (y) (/ 1 y))))
          > z
          (#<procedure #2> #<procedure #3>)
          > (#3 10)
          1/10
          > '(#3 10)
          ((serial-number->object 3) 10)
          > car
          #<procedure #4 car>
          > (#4 z)
          #<procedure #2>


 -- procedure: unbound-serial-number-exception? OBJ
 -- procedure: unbound-serial-number-exception-procedure EXC
 -- procedure: unbound-serial-number-exception-arguments EXC
     Unbound-serial-number-exception objects are raised by the procedure
     `serial-number->object' when no object currently exists with that
     serial number.  The parameter EXC must be an
     unbound-serial-number-exception object.

     The procedure `unbound-serial-number-exception?' returns `#t' when
     OBJ is a unbound-serial-number-exception object and `#f' otherwise.

     The procedure `unbound-serial-number-exception-procedure' returns
     the procedure that raised EXC.

     The procedure `unbound-serial-number-exception-arguments' returns
     the list of arguments of the procedure that raised EXC.

     For example:

          > (define (handler exc)
              (if (unbound-serial-number-exception? exc)
                  (list (unbound-serial-number-exception-procedure exc)
                        (unbound-serial-number-exception-arguments exc))
                  'not-unbound-serial-number-exception))
          > (with-exception-catcher
              handler
              (lambda () (serial-number->object 1000)))
          (#<procedure #2 serial-number->object> (1000))


 -- procedure: symbol-hash SYMBOL
     The `symbol-hash' procedure returns the hash number of the symbol
     SYMBOL.  The hash number is a small exact integer (fixnum).  When
     SYMBOL is an interned symbol the value returned is the same as
     `(string=?-hash (symbol->string SYMBOL))'.

     For example:

          > (symbol-hash 'car)
          444471047


 -- procedure: keyword-hash KEYWORD
     The `keyword-hash' procedure returns the hash number of the
     keyword KEYWORD.  The hash number is a small exact integer
     (fixnum).  When KEYWORD is an interned keyword the value returned
     is the same as `(string=?-hash (keyword->string KEYWORD))'.

     For example:

          > (keyword-hash car:)
          444471047


 -- procedure: string=?-hash STRING
     The `string=?-hash' procedure returns the hash number of the
     string STRING.  The hash number is a small exact integer (fixnum).
     For any two strings S1 and S2, `(string=?  S1 S2)' implies `(=
     (string=?-hash S1) (string=?-hash S2))'.

     For example:

          > (string=?-hash "car")
          444471047


 -- procedure: string-ci=?-hash STRING
     The `string-ci=?-hash' procedure returns the hash number of the
     string STRING.  The hash number is a small exact integer (fixnum).
     For any two strings S1 and S2, `(string-ci=?  S1 S2)' implies `(=
     (string-ci=?-hash S1) (string-ci=?-hash S2))'.

     For example:

          > (string-ci=?-hash "CaR")
          444471047


 -- procedure: eq?-hash OBJ
     The `eq?-hash' procedure returns the hash number of the object
     OBJ.  The hash number is a small exact integer (fixnum).  For any
     two objects O1 and O2, `(eq? O1 O2)' implies `(= (eq?-hash O1)
     (eq?-hash O2))'.

     For example:

          > (eq?-hash #t)
          536870910


 -- procedure: eqv?-hash OBJ
     The `eqv?-hash' procedure returns the hash number of the object
     OBJ.  The hash number is a small exact integer (fixnum).  For any
     two objects O1 and O2, `(eqv? O1 O2)' implies `(= (eqv?-hash O1)
     (eqv?-hash O2))'.

     For example:

          > (eqv?-hash 1.5)
          496387656


 -- procedure: equal?-hash OBJ
     The `equal?-hash' procedure returns the hash number of the object
     OBJ.  The hash number is a small exact integer (fixnum).  For any
     two objects O1 and O2, `(equal? O1 O2)' implies `(= (equal?-hash
     O1) (equal?-hash O2))'.

     For example:

          > (equal?-hash (list 1 2 3))
          442438567



File: gambit.info,  Node: Weak references,  Prev: Hashing,  Up: Hashing and weak references

11.2 Weak references
====================

The garbage collector is responsible for reclaiming objects that are no
longer needed by the program.  This is done by analyzing the
reachability graph of all objects from the roots (i.e. the global
variables, the runnable threads, permanently allocated objects such as
procedures defined in a compiled file, nonexecutable wills, etc).  If a
root or a reachable object X contains a reference to an object Y then Y
is reachable.  As a general rule, unreachable objects are reclaimed by
the garbage collector.

   There are two types of references: strong references and weak
references.  Most objects, including pairs, vectors, records and
closures, contain strong references.  An object X is "strongly
reachable" if there is a path from the roots to X that traverses only
strong references.  Weak references only occur in wills and tables.
There are two types of weak references: will-weak references and
table-weak references.  If all paths from the roots to an object Y
traverse at least one table-weak reference, then Y will be reclaimed by
the garbage collector.  The will-weak references are used for
finalization and are explained in the next section.

* Menu:

* Wills::                           Wills
* Tables::                          Tables


File: gambit.info,  Node: Wills,  Next: Tables,  Prev: Weak references,  Up: Weak references

11.2.1 Wills
------------

The following procedures implement the "will" data type.  Will objects
provide support for finalization.  A will is an object that contains a
will-weak reference to a TESTATOR object (the object attached to the
will), and a strong reference to an ACTION procedure which is a one
parameter procedure which is called when the will is executed.

 -- procedure: make-will TESTATOR ACTION
 -- procedure: will? OBJ
 -- procedure: will-testator WILL
 -- procedure: will-execute! WILL
     The `make-will' procedure creates a will object with the given
     TESTATOR object and ACTION procedure.  The `will?' procedure tests
     if OBJ is a will object.  The `will-testator' procedure gets the
     testator object attached to the WILL.  The `will-execute!'
     procedure executes WILL.

     A will becomes "executable" when its TESTATOR object is not
     strongly reachable (i.e. the TESTATOR object is either unreachable
     or only reachable using paths from the roots that traverse at
     least one weak reference).  Some objects, including symbols, small
     exact integers (fixnums), booleans and characters, are considered
     to be always strongly reachable.

     When the runtime system detects that a will has become executable
     the current computation is interrupted, the will's testator is set
     to `#f' and the will's action procedure is called with the will's
     testator as the sole argument.  Currently only the garbage
     collector detects when wills become executable but this may change
     in future versions of Gambit (for example the compiler could
     perform an analysis to infer will executability at compile time).
     The garbage collector builds a list of all executable wills.
     Shortly after a garbage collection, the action procedures of these
     wills will be called.  The link from the will to the action
     procedure is severed when the action procedure is called.

     Note that the testator object will not be reclaimed during the
     garbage collection that determined executability of the will.  It
     is only when an object is not reachable from the roots that it is
     reclaimed by the garbage collector.

     A remarkable feature of wills is that an action procedure can
     "resurrect" an object.  An action procedure could for example
     assign the testator object to a global variable or create a new
     will with the same testator object.

     For example:

          > (define a (list 123))
          > (set-cdr! a a) ; create a circular list
          > (define b (vector a))
          > (define c #f)
          > (define w
              (let ((obj a))
                (make-will obj
                           (lambda (x) ; x will be eq? to obj
                             (display "executing action procedure")
                             (newline)
                             (set! c x)))))
          > (will? w)
          #t
          > (car (will-testator w))
          123
          > (##gc)
          > (set! a #f)
          > (##gc)
          > (set! b #f)
          > (##gc)
          executing action procedure
          > (will-testator w)
          #f
          > (car c)
          123



File: gambit.info,  Node: Tables,  Prev: Wills,  Up: Weak references

11.2.2 Tables
-------------

The following procedures implement the "table" data type.  Tables are
heterogenous structures whose elements are indexed by keys which are
arbitrary objects.  Tables are similar to association lists but are
abstract and the access time for large tables is typically smaller.
Each key contained in the table is bound to a value.  The length of the
table is the number of key/value bindings it contains.  New key/value
bindings can be added to a table, the value bound to a key can be
changed, and existing key/value bindings can be removed.

   The references to the keys can either be all strong or all table-weak
and the references to the values can either be all strong or all
table-weak.  The garbage collector removes key/value bindings from a
table when 1) the key is a table-weak reference and the key is
unreachable or only reachable using paths from the roots that traverse
at least one table-weak reference, or 2) the value is a table-weak
reference and the value is unreachable or only reachable using paths
from the roots that traverse at least one table-weak reference.
Key/value bindings that are removed by the garbage collector are
reclaimed immediately.

   Although there are several possible ways of implementing tables, the
current implementation uses hashing with open-addressing.  This is
space efficient and provides constant-time access.  Hash tables are
automatically resized to maintain the load within specified bounds.
The load is the number of active entries (the length of the table)
divided by the total number of entries in the hash table.

   Tables are parameterized with a key comparison procedure.  By default
the `equal?' procedure is used, but `eq?', `eqv?', `string=?',
`string-ci=?', or a user defined procedure can also be used.  To
support arbitrary key comparison procedures, tables are also
parameterized with a hashing procedure accepting a key as its single
parameter and returning a fixnum result.  The hashing procedure HASH
must be consistent with the key comparison procedure TEST, that is, for
any two keys K1 and K2 in the table, `(TEST K1 K2)' implies `(= (HASH
K1) (HASH K2))'.  A default hashing procedure consistent with the key
comparison procedure is provided by the system.  The default hashing
procedure generally gives good performance when the key comparison
procedure is `eq?', `eqv?', `equal?', `string=?', and `string-ci=?'.
However, for user defined key comparison procedures, the default
hashing procedure always returns 0.  This degrades the performance of
the table to a linear search.

   Tables can be compared for equality using the `equal?' procedure.
Two tables `X' and `Y' are considered equal by `equal?' when they have
the same weakness attributes, the same key comparison procedure, the
same hashing procedure, the same length, and for all the keys `K' in
`X', `(equal?  (table-ref X K) (table-ref Y K))'.

 -- procedure: make-table [`size:' SIZE] [`init:' INIT] [`weak-keys:'
          WEAK-KEYS] [`weak-values:' WEAK-VALUES] [`test:' TEST]
          [`hash:' HASH] [`min-load:' MIN-LOAD] [`max-load:' MAX-LOAD]
     The procedure `make-table' returns a new table.  The optional
     keyword parameters specify various parameters of the table.

     The SIZE parameter is a nonnegative exact integer indicating the
     expected length of the table.  The system uses SIZE to choose an
     appropriate initial size of the hash table so that it does not
     need to be resized too often.

     The INIT parameter indicates a value that is associated to keys
     that are not in the table.  When INIT is not specified, no value
     is associated to keys that are not in the table.

     The WEAK-KEYS and WEAK-VALUES parameters are extended booleans
     indicating respectively whether the keys and values are table-weak
     references (true) or strong references (false).  By default the
     keys and values are strong references.

     The TEST parameter indicates the key comparison procedure.  The
     default key comparison procedure is `equal?'.  The key comparison
     procedures `eq?', `eqv?', `equal?', `string=?', and `string-ci=?'
     are special because the system will use a reasonably good hash
     procedure when none is specified.

     The HASH parameter indicates the hash procedure.  This procedure
     must accept a single key parameter, return a fixnum, and be
     consistent with the key comparison procedure.  When HASH is not
     specified, a default hash procedure is used.  The default hash
     procedure is reasonably good when the key comparison procedure is
     `eq?', `eqv?', `equal?', `string=?', or `string-ci=?'.

     The MIN-LOAD and MAX-LOAD parameters are real numbers that
     indicate the minimum and maximum load of the table respectively.
     The table is resized when adding or deleting a key/value binding
     would bring the table's load outside of this range.  The MIN-LOAD
     parameter must be no less than 0.05 and the MAX-LOAD parameter
     must be no greater than 0.95.  Moreover the difference between
     MIN-LOAD and MAX-LOAD must be at least 0.20.  When MIN-LOAD is not
     specified, the value 0.45 is used.  When MAX-LOAD is not
     specified, the value 0.90 is used.

     For example:

          > (define t (make-table))
          > (table? t)
          #t
          > (table-length t)
          0
          > (table-set! t (list 1 2) 3)
          > (table-set! t (list 4 5) 6)
          > (table-ref t (list 1 2))
          3
          > (table-length t)
          2


 -- procedure: table? OBJ
     The procedure `table?' returns `#t' when OBJ is a table and `#f'
     otherwise.

     For example:

          > (table? (make-table))
          #t
          > (table? 123)
          #f


 -- procedure: table-length TABLE
     The procedure `table-length' returns the number of key/value
     bindings contained in the table TABLE.

     For example:

          > (define t (make-table weak-keys: #t))
          > (define x (list 1 2))
          > (define y (list 3 4))
          > (table-set! t x 111)
          > (table-set! t y 222)
          > (table-length t)
          2
          > (table-set! t x)
          > (table-length t)
          1
          > (##gc)
          > (table-length t)
          1
          > (set! y #f)
          > (##gc)
          > (table-length t)
          0


 -- procedure: table-ref TABLE KEY [DEFAULT]
     The procedure `table-ref' returns the value bound to the object
     KEY in the table TABLE.  When KEY is not bound and DEFAULT is
     specified, DEFAULT is returned.  When DEFAULT is not specified but
     an INIT parameter was specified when TABLE was created, INIT is
     returned.  Otherwise an unbound-table-key-exception object is
     raised.

     For example:

          > (define t1 (make-table init: 999))
          > (table-set! t1 (list 1 2) 3)
          > (table-ref t1 (list 1 2))
          3
          > (table-ref t1 (list 4 5))
          999
          > (table-ref t1 (list 4 5) #f)
          #f
          > (define t2 (make-table))
          > (table-ref t2 (list 4 5))
          *** ERROR IN (console)@7.1 -- Unbound table key
          (table-ref '#<table #2> '(4 5))


 -- procedure: table-set! TABLE KEY [VALUE]
     The procedure `table-set!' binds the object KEY to VALUE in the
     table TABLE.  When VALUE is not specified, if TABLE contains a
     binding for KEY then the binding is removed from TABLE.  The
     procedure `table-set!' returns an unspecified value.

     For example:

          > (define t (make-table))
          > (table-set! t (list 1 2) 3)
          > (table-set! t (list 4 5) 6)
          > (table-set! t (list 4 5))
          > (table-set! t (list 7 8))
          > (table-ref t (list 1 2))
          3
          > (table-ref t (list 4 5))
          *** ERROR IN (console)@7.1 -- Unbound table key
          (table-ref '#<table #2> '(4 5))


 -- procedure: table-search PROC TABLE
     The procedure `table-search' searches the table TABLE for a
     key/value binding for which the two parameter procedure PROC
     returns a non false result.  For each key/value binding visited by
     `table-search' the procedure PROC is called with the key as the
     first parameter and the value as the second parameter.  The
     procedure `table-search' returns the first non false value
     returned by PROC, or `#f' if PROC returned `#f' for all key/value
     bindings in TABLE.

     The order in which the key/value bindings are visited is
     unspecified and may vary from one call of `table-search' to the
     next.  While a call to `table-search' is being performed on TABLE,
     it is an error to call any of the following procedures on TABLE:
     `table-ref', `table-set!', `table-search', `table-for-each',
     `table-copy', `table-merge', `table-merge!', and `table->list'.
     It is also an error to compare with `equal?' (directly or
     indirectly with `member', `assoc', `table-ref', etc.) an object
     that contains TABLE.  All these procedures may cause TABLE to be
     reordered and resized.  This restriction allows a more efficient
     iteration over the key/value bindings.

     For example:

          > (define square (make-table))
          > (table-set! square 2 4)
          > (table-set! square 3 9)
          > (table-search (lambda (k v) (and (odd? k) v)) square)
          9


 -- procedure: table-for-each PROC TABLE
     The procedure `table-for-each' calls the two parameter procedure
     PROC for each key/value binding in the table TABLE.  The procedure
     PROC is called with the key as the first parameter and the value
     as the second parameter.  The procedure `table-for-each' returns
     an unspecified value.

     The order in which the key/value bindings are visited is
     unspecified and may vary from one call of `table-for-each' to the
     next.  While a call to `table-for-each' is being performed on
     TABLE, it is an error to call any of the following procedures on
     TABLE: `table-ref', `table-set!', `table-search',
     `table-for-each', and `table->list'.  It is also an error to
     compare with `equal?' (directly or indirectly with `member',
     `assoc', `table-ref', etc.) an object that contains TABLE.  All
     these procedures may cause TABLE to be reordered and resized.
     This restriction allows a more efficient iteration over the
     key/value bindings.

     For example:

          > (define square (make-table))
          > (table-set! square 2 4)
          > (table-set! square 3 9)
          > (table-for-each (lambda (k v) (write (list k v)) (newline)) square)
          (2 4)
          (3 9)


 -- procedure: table->list TABLE
     The procedure `table->list' returns an association list containing
     the key/value bindings in the table TABLE.  Each key/value binding
     yields a pair whose car field is the key and whose cdr field is
     the value bound to that key.  The order of the bindings in the
     list is unspecified.

     For example:

          > (define square (make-table))
          > (table-set! square 2 4)
          > (table-set! square 3 9)
          > (table->list square)
          ((3 . 9) (2 . 4))


 -- procedure: list->table LIST [`size:' SIZE] [`init:' INIT]
          [`weak-keys:' WEAK-KEYS] [`weak-values:' WEAK-VALUES]
          [`test:' TEST] [`hash:' HASH] [`min-load:' MIN-LOAD]
          [`max-load:' MAX-LOAD]
     The procedure `list->table' returns a new table containing the
     key/value bindings in the association list LIST.  The optional
     keyword parameters specify various parameters of the table and have
     the same meaning as for the `make-table' procedure.

     Each element of LIST is a pair whose car field is a key and whose
     cdr field is the value bound to that key.  If a key appears more
     than once in LIST (tested using the table's key comparison
     procedure) it is the first key/value binding in LIST that has
     precedence.

     For example:

          > (define t (list->table '((b . 2) (a . 1) (c . 3) (a . 4))))
          > (table->list t)
          ((a . 1) (b . 2) (c . 3))


 -- procedure: unbound-table-key-exception? OBJ
 -- procedure: unbound-table-key-exception-procedure EXC
 -- procedure: unbound-table-key-exception-arguments EXC
     Unbound-table-key-exception objects are raised by the procedure
     `table-ref' when the key does not have a binding in the table.
     The parameter EXC must be an unbound-table-key-exception object.

     The procedure `unbound-table-key-exception?' returns `#t' when OBJ
     is a unbound-table-key-exception object and `#f' otherwise.

     The procedure `unbound-table-key-exception-procedure' returns the
     procedure that raised EXC.

     The procedure `unbound-table-key-exception-arguments' returns the
     list of arguments of the procedure that raised EXC.

     For example:

          > (define t (make-table))
          > (define (handler exc)
              (if (unbound-table-key-exception? exc)
                  (list (unbound-table-key-exception-procedure exc)
                        (unbound-table-key-exception-arguments exc))
                  'not-unbound-table-key-exception))
          > (with-exception-catcher
              handler
              (lambda () (table-ref t '(1 2))))
          (#<procedure #2 table-ref> (#<table #3> (1 2)))


 -- procedure: table-copy TABLE
     The procedure `table-copy' returns a new table containing the same
     key/value bindings as TABLE and the same table parameters (i.e.
     hash procedure, key comparison procedure, key and value weakness,
     etc).

     For example:

          > (define t (list->table '((b . 2) (a . 1) (c . 3))))
          > (define x (table-copy t))
          > (table-set! t 'b 99)
          > (table->list t)
          ((a . 1) (b . 99) (c . 3))
          > (table->list x)
          ((a . 1) (b . 2) (c . 3))


 -- procedure: table-merge! TABLE1 TABLE2 [TABLE2-TAKES-PRECEDENCE?]
     The procedure `table-merge!' returns TABLE1 after the key/value
     bindings contained in TABLE2 have been added to it.  When a key
     exists both in TABLE1 and TABLE2, then the parameter
     TABLE2-TAKES-PRECEDENCE? indicates which binding will be kept (the
     one in TABLE1 if TABLE2-TAKES-PRECEDENCE?  is false, and the one
     in TABLE2 otherwise).  If TABLE2-TAKES-PRECEDENCE? is not
     specified the binding in TABLE1 is kept.

     For example:

          > (define t1 (list->table '((a . 1) (b . 2) (c . 3))))
          > (define t2 (list->table '((a . 4) (b . 5) (z . 6))))
          > (table->list (table-merge! t1 t2))
          ((a . 1) (b . 2) (c . 3) (z . 6))
          > (define t1 (list->table '((a . 1) (b . 2) (c . 3))))
          > (define t2 (list->table '((a . 4) (b . 5) (z . 6))))
          > (table->list (table-merge! t1 t2 #t))
          ((a . 4) (b . 5) (c . 3) (z . 6))


 -- procedure: table-merge TABLE1 TABLE2 [TABLE2-TAKES-PRECEDENCE?]
     The procedure `table-merge' returns a copy of TABLE1 (created with
     `table-copy') to which the key/value bindings contained in TABLE2
     have been added using `table-merge!'.  When a key exists both in
     TABLE1 and TABLE2, then the parameter TABLE2-TAKES-PRECEDENCE?
     indicates which binding will be kept (the one in TABLE1 if
     TABLE2-TAKES-PRECEDENCE?  is false, and the one in TABLE2
     otherwise).  If TABLE2-TAKES-PRECEDENCE? is not specified the
     binding in TABLE1 is kept.

     For example:

          > (define t1 (list->table '((a . 1) (b . 2) (c . 3))))
          > (define t2 (list->table '((a . 4) (b . 5) (z . 6))))
          > (table->list (table-merge t1 t2))
          ((a . 1) (b . 2) (c . 3) (z . 6))
          > (table->list (table-merge t1 t2 #t))
          ((a . 4) (b . 5) (c . 3) (z . 6))



File: gambit.info,  Node: Records,  Next: Threads,  Prev: Hashing and weak references,  Up: Top

12 Records
**********

 -- special form: define-structure name field...
     Record data types similar to Pascal records and C `struct' types
     can be defined using the `define-structure' special form.  The
     identifier name specifies the name of the new data type.  The
     structure name is followed by K identifiers naming each field of
     the record.  The `define-structure' expands into a set of
     definitions of the following procedures:

        * `make-name' - A K argument procedure which constructs a new
          record from the value of its K fields.

        * `name?' - A procedure which tests if its single argument is
          of the given record type.

        * `name-field' - For each field, a procedure taking as its
          single argument a value of the given record type and returning
          the content of the corresponding field of the record.

        * `name-field-set!' - For each field, a two argument procedure
          taking as its first argument a value of the given record
          type.  The second argument gets assigned to the corresponding
          field of the record and the void object is returned.


     Record data types have a printed representation that includes the
     name of the type and the name and value of each field.  Record
     data types can not be read by the `read' procedure.

     For example:

          > (define-structure point x y color)
          > (define p (make-point 3 5 'red))
          > p
          #<point #2 x: 3 y: 5 color: red>
          > (point-x p)
          3
          > (point-color p)
          red
          > (point-color-set! p 'black)
          > p
          #<point #2 x: 3 y: 5 color: black>



File: gambit.info,  Node: Threads,  Next: Dynamic environment,  Prev: Records,  Up: Top

13 Threads
**********

Gambit supports the execution of multiple Scheme threads.  These
threads are managed entirely by Gambit's runtime and are not related to
the host operating system's threads.  Gambit's runtime does not
currently take advantage of multiprocessors (i.e. at most one thread is
running).

* Menu:

* Introduction::                  Introduction
* Thread objects::                Thread objects
* Mutex objects::                 Mutex objects
* Condition variable objects::    Condition variable objects
* Fairness::                      Fairness
* Memory coherency::              Memory coherency
* Timeouts::                      Timeouts
* Primordial thread::             Primordial thread
* Procedures::                    Procedures


File: gambit.info,  Node: Introduction,  Next: Thread objects,  Prev: Threads,  Up: Threads

13.1 Introduction
=================

Multithreading is a paradigm that is well suited for building complex
systems such as: servers, GUIs, and high-level operating systems.
Gambit's thread system offers mechanisms for creating threads of
execution and for synchronizing them.  The thread system also supports
features which are useful in a real-time context, such as priorities,
priority inheritance and timeouts.

   The thread system provides the following data types:

   * Thread (a virtual processor which shares object space with all
     other threads)

   * Mutex (a mutual exclusion device, also known as a lock and binary
     semaphore)

   * Condition variable (a set of blocked threads)



File: gambit.info,  Node: Thread objects,  Next: Mutex objects,  Prev: Introduction,  Up: Threads

13.2 Thread objects
===================

A "running thread" is a thread that is currently executing.  A
"runnable thread" is a thread that is ready to execute or running.  A
thread is "blocked" if it is waiting for a mutex to become unlocked, an
I/O operation to become possible, the end of a "sleep" period, etc.  A
"new thread" is a thread that has been allocated but has not yet been
initialized.  An "initialized thread" is a thread that can be made
runnable.  A new thread becomes runnable when it is started by calling
`thread-start!'.  A "terminated thread" is a thread that can no longer
become runnable (but "deadlocked threads" are not considered
terminated).  The only valid transitions between the thread states are
from new to initialized, from initialized to runnable, between runnable
and blocked, and from any state except new to terminated as indicated in
the following diagram:

                                                 unblock
                               start            <-------
     NEW -------> INITIALIZED -------> RUNNABLE -------> BLOCKED
                            \             |      block  /
                             \            v            /
                              +-----> TERMINATED <----+

   Each thread has a "base priority", which is a real number (where a
higher numerical value means a higher priority), a "priority boost",
which is a nonnegative real number representing the priority increase
applied to a thread when it blocks, and a "quantum", which is a
nonnegative real number representing a duration in seconds.

   Each thread has a "specific field" which can be used in an
application specific way to associate data with the thread (some thread
systems call this "thread local storage").

   Each thread has a "mailbox" which is used for inter-thread
communication.


File: gambit.info,  Node: Mutex objects,  Next: Condition variable objects,  Prev: Thread objects,  Up: Threads

13.3 Mutex objects
==================

A mutex can be in one of four states: "locked" (either "owned" or "not
owned") and "unlocked" (either "abandoned" or "not abandoned").

   An attempt to lock a mutex only succeeds if the mutex is in an
unlocked state, otherwise the current thread will wait.  A mutex in the
locked/owned state has an associated "owner thread", which by
convention is the thread that is responsible for unlocking the mutex
(this case is typical of critical sections implemented as "lock mutex,
perform operation, unlock mutex").  A mutex in the locked/not-owned
state is not linked to a particular thread.

   A mutex becomes locked when a thread locks it using the
`mutex-lock!' primitive.  A mutex becomes unlocked/abandoned when the
owner of a locked/owned mutex terminates.  A mutex becomes
unlocked/not-abandoned when a thread unlocks it using the
`mutex-unlock!' primitive.

   The mutex primitives do not implement "recursive mutex semantics".
An attempt to lock a mutex that is locked implies that the current
thread waits even if the mutex is owned by the current thread (this can
lead to a deadlock if no other thread unlocks the mutex).

   Each mutex has a "specific field" which can be used in an
application specific way to associate data with the mutex.


File: gambit.info,  Node: Condition variable objects,  Next: Fairness,  Prev: Mutex objects,  Up: Threads

13.4 Condition variable objects
===============================

A condition variable represents a set of blocked threads.  These blocked
threads are waiting for a certain condition to become true.  When a
thread modifies some program state that might make the condition true,
the thread unblocks some number of threads (one or all depending on the
primitive used) so they can check if the condition is now true.  This
allows complex forms of interthread synchronization to be expressed more
conveniently than with mutexes alone.

   Each condition variable has a "specific field" which can be used in
an application specific way to associate data with the condition
variable.


File: gambit.info,  Node: Fairness,  Next: Memory coherency,  Prev: Condition variable objects,  Up: Threads

13.5 Fairness
=============

In various situations the scheduler must select one thread from a set of
threads (e.g. which thread to run when a running thread blocks or
expires its quantum, which thread to unblock when a mutex becomes
unlocked or a condition variable is signaled).  The constraints on the
selection process determine the scheduler's "fairness".  The selection
depends on the order in which threads become runnable or blocked and on
the "priority" attached to the threads.

   The definition of fairness requires the notion of time ordering,
i.e. "event A occured before event B".  For the purpose of establishing
time ordering, the scheduler uses a clock with a discrete, usually
variable, resolution (a "tick").  Events occuring in a given tick can
be considered to be simultaneous (i.e. if event A occured before event
B in real time, then the scheduler will claim that event A occured
before event B unless both events fall within the same tick, in which
case the scheduler arbitrarily chooses a time ordering).

   Each thread T has three priorities which affect fairness; the "base
priority", the "boosted priority", and the "effective priority".

   * The "base priority" is the value contained in T's "base priority"
     field (which is set with the `thread-base-priority-set!'
     primitive).

   * T's "boosted flag" field contains a boolean that affects T's
     "boosted priority".  When the boosted flag field is false, the
     boosted priority is equal to the base priority, otherwise the
     boosted priority is equal to the base priority plus the value
     contained in T's "priority boost" field (which is set with the
     `thread-priority-boost-set!' primitive).  The boosted flag field is
     set to false when a thread is created, when its quantum expires,
     and when "thread-yield!" is called.  The boosted flag field is set
     to true when a thread blocks.  By carefully choosing the base
     priority and priority boost, relatively to the other threads, it
     is possible to set up an interactive thread so that it has good
     I/O response time without being a CPU hog when it performs long
     computations.

   * The "effective priority" is equal to the maximum of T's boosted
     priority and the effective priority of all the threads that are
     blocked on a mutex owned by T.  This "priority inheritance" avoids
     priority inversion problems that would prevent a high priority
     thread blocked at the entry of a critical section to progress
     because a low priority thread inside the critical section is
     preempted for an arbitrary long time by a medium priority thread.


   Let P(T) be the effective priority of thread T and let R(T) be the
most recent time when one of the following events occurred for thread
T, thus making it runnable: T was started by calling `thread-start!', T
called `thread-yield!', T expired its quantum, or T became unblocked.
Let the relation NL(T1,T2), "T1 no later than T2", be true if
P(T1)<P(T2) or P(T1)=P(T2) and R(T1)>R(T2), and false otherwise.  The
scheduler will schedule the execution of threads in such a way that
whenever there is at least one runnable thread, 1) within a finite time
at least one thread will be running, and 2) there is never a pair of
runnable threads T1 and T2 for which NL(T1,T2) is true and T1 is not
running and T2 is running.

   A thread T expires its quantum when an amount of time equal to T's
quantum has elapsed since T entered the running state and T did not
block, terminate or call `thread-yield!'.  At that point T exits the
running state to allow other threads to run.  A thread's quantum is
thus an indication of the rate of progress of the thread relative to
the other threads of the same priority.  Moreover, the resolution of
the timer measuring the running time may cause a certain deviation from
the quantum, so a thread's quantum should only be viewed as an
approximation of the time it can run before yielding to another thread.

   Threads blocked on a given mutex or condition variable will unblock
in an order which is consistent with decreasing priority and increasing
blocking time (i.e. the highest priority thread unblocks first, and
among equal priority threads the one that blocked first unblocks first).


File: gambit.info,  Node: Memory coherency,  Next: Timeouts,  Prev: Fairness,  Up: Threads

13.6 Memory coherency
=====================

Read and write operations on the store (such as reading and writing a
variable, an element of a vector or a string) are not atomic.  It is an
error for a thread to write a location in the store while some other
thread reads or writes that same location.  It is the responsibility of
the application to avoid write/read and write/write races through
appropriate uses of the synchronization primitives.

   Concurrent reads and writes to ports are allowed.  It is the
responsibility of the implementation to serialize accesses to a given
port using the appropriate synchronization primitives.


File: gambit.info,  Node: Timeouts,  Next: Primordial thread,  Prev: Memory coherency,  Up: Threads

13.7 Timeouts
=============

All synchronization primitives which take a timeout parameter accept
three types of values as a timeout, with the following meaning:

   * a time object represents an absolute point in time

   * an exact or inexact real number represents a relative time in
     seconds from the moment the primitive was called

   * `#f' means that there is no timeout


   When a timeout denotes the current time or a time in the past, the
synchronization primitive claims that the timeout has been reached only
after the other synchronization conditions have been checked.  Moreover
the thread remains running (it does not enter the blocked state).  For
example, `(mutex-lock! m 0)' will lock mutex `m' and return `#t' if `m'
is currently unlocked, otherwise `#f' is returned because the timeout
is reached.


File: gambit.info,  Node: Primordial thread,  Next: Procedures,  Prev: Timeouts,  Up: Threads

13.8 Primordial thread
======================

The execution of a program is initially under the control of a single
thread known as the "primordial thread".  The primordial thread has an
unspecified base priority, priority boost, boosted flag, quantum, name,
specific field, dynamic environment, `dynamic-wind' stack, and
exception-handler.  All threads are terminated when the primordial
thread terminates (normally or not).


File: gambit.info,  Node: Procedures,  Prev: Primordial thread,  Up: Threads

13.9 Procedures
===============

 -- procedure: current-thread
     This procedure returns the current thread.  For example:

          > (current-thread)
          #<thread #1 primordial>
          > (eq? (current-thread) (current-thread))
          #t


 -- procedure: thread? OBJ
     This procedure returns `#t' when OBJ is a thread object and `#f'
     otherwise.

     For example:

          > (thread? (current-thread))
          #t
          > (thread? 'foo)
          #f


 -- procedure: make-thread THUNK [NAME [THREAD-GROUP]]
 -- procedure: make-root-thread THUNK [NAME [THREAD-GROUP [INPUT-PORT
          [OUTPUT-PORT]]]]
     The `make-thread' procedure creates and returns an initialized
     thread.  This thread is not automatically made runnable (the
     procedure `thread-start!' must be used for this).  A thread has the
     following fields: base priority, priority boost, boosted flag,
     quantum, name, specific, end-result, end-exception, and a list of
     locked/owned mutexes it owns.  The thread's execution consists of a
     call to THUNK with the "initial continuation".  This continuation
     causes the (then) current thread to store the result in its
     end-result field, abandon all mutexes it owns, and finally
     terminate.  The `dynamic-wind' stack of the initial continuation
     is empty.  The optional NAME is an arbitrary Scheme object which
     identifies the thread (useful for debugging); it defaults to an
     unspecified value.  The specific field is set to an unspecified
     value.  The optional THREAD-GROUP indicates which thread group this
     thread belongs to; it defaults to the thread group of the current
     thread.  The base priority, priority boost, and quantum of the
     thread are set to the same value as the current thread and the
     boosted flag is set to false.  The thread's mailbox is initially
     empty.  The thread inherits the dynamic environment from the
     current thread. Moreover, in this dynamic environment the
     exception-handler is bound to the "initial exception-handler"
     which is a unary procedure which causes the (then) current thread
     to store in its end-exception field an uncaught-exception object
     whose "reason" is the argument of the handler, abandon all mutexes
     it owns, and finally terminate.

     The `make-root-thread' procedure behaves like the `make-thread'
     procedure except the created thread does not inherit the dynamic
     environment from the current thread and the base priority is set
     to 0, the priority boost is set to 1.0e-6, and the quantum is set
     to 0.02.  The dynamic environment of the thread has the global
     bindings of the parameter objects, except `current-input-port'
     which is bound to INPUT-PORT, `current-output-port' which is bound
     to OUTPUT-PORT, and `current-directory' which is bound to the
     initial current working directory of the current process.  If
     INPUT-PORT is not specified it defaults to a port corresponding to
     the standard input (`stdin').  If OUTPUT-PORT is not specified it
     defaults to a port corresponding to the standard output (`stdout').

     For example:

          > (make-thread (lambda () (write 'hello)))
          #<thread #2>
          > (make-root-thread (lambda () (write 'world)) 'a-name)
          #<thread #3 a-name>


 -- procedure: thread-name THREAD
     This procedure returns the name of the THREAD.  For example:

          > (thread-name (make-thread (lambda () #f) 'foo))
          foo


 -- procedure: thread-specific THREAD
 -- procedure: thread-specific-set! THREAD OBJ
     The `thread-specific' procedure returns the content of the
     THREAD's specific field.

     The `thread-specific-set!' procedure stores OBJ into the THREAD's
     specific field and returns an unspecified value.

     For example:

          > (thread-specific-set! (current-thread) "hello")
          > (thread-specific (current-thread))
          "hello"


 -- procedure: thread-base-priority THREAD
 -- procedure: thread-base-priority-set! THREAD PRIORITY
     The procedure `thread-base-priority' returns a real number which
     corresponds to the base priority of the THREAD.

     The procedure `thread-base-priority-set!' changes the base
     priority of the THREAD to PRIORITY and returns an unspecified
     value.  The PRIORITY must be a real number.

     For example:

          > (thread-base-priority-set! (current-thread) 12.3)
          > (thread-base-priority (current-thread))
          12.3


 -- procedure: thread-priority-boost THREAD
 -- procedure: thread-priority-boost-set! THREAD PRIORITY-BOOST
     The procedure `thread-priority-boost' returns a real number which
     corresponds to the priority boost of the THREAD.

     The procedure `thread-priority-boost-set!' changes the priority
     boost of the THREAD to PRIORITY-BOOST and returns an unspecified
     value.  The PRIORITY-BOOST must be a nonnegative real.

     For example:

          > (thread-priority-boost-set! (current-thread) 2.5)
          > (thread-priority-boost (current-thread))
          2.5


 -- procedure: thread-quantum THREAD
 -- procedure: thread-quantum-set! THREAD QUANTUM
     The procedure `thread-quantum' returns a real number which
     corresponds to the quantum of the THREAD.

     The procedure `thread-quantum-set!' changes the quantum of the
     THREAD to QUANTUM and returns an unspecified value.  The QUANTUM
     must be a nonnegative real.  A value of zero selects the smallest
     quantum supported by the implementation.

     For example:

          > (thread-quantum-set! (current-thread) 1.5)
          > (thread-quantum (current-thread))
          1.5
          > (thread-quantum-set! (current-thread) 0)
          > (thread-quantum (current-thread))
          0.


 -- procedure: thread-start! THREAD
     This procedure makes THREAD runnable and returns the THREAD.  The
     THREAD must be an initialized thread.

     For example:

          > (let ((t (thread-start! (make-thread (lambda () (write 'a))))))
              (write 'b)
              (thread-join! t))
          ab> or ba>

     NOTE: It is useful to separate thread creation and thread
     activation to avoid the race condition that would occur if the
     created thread tries to examine a table in which the current
     thread stores the created thread.  See the last example of the
     `thread-terminate!' procedure which contains mutually recursive
     threads.


 -- procedure: thread-yield!
     This procedure causes the current thread to exit the running state
     as if its quantum had expired and returns an unspecified value.

     For example:

          ; a busy loop that avoids being too wasteful of the CPU

          (let loop ()
            (if (mutex-lock! m 0) ; try to lock m but don't block
                (begin
                  (display "locked mutex m")
                  (mutex-unlock! m))
                (begin
                  (do-something-else)
                  (thread-yield!) ; relinquish rest of quantum
                  (loop))))


 -- procedure: thread-sleep! TIMEOUT
     This procedure causes the current thread to wait until the timeout
     is reached and returns an unspecified value.  This blocks the
     thread only if TIMEOUT represents a point in the future.  It is an
     error for TIMEOUT to be `#f'.

     For example:

          ; a clock with a gradual drift:

          (let loop ((x 1))
            (thread-sleep! 1)
            (write x)
            (loop (+ x 1)))

          ; a clock with no drift:

          (let ((start (time->seconds (current-time)))
            (let loop ((x 1))
              (thread-sleep! (seconds->time (+ x start)))
              (write x)
              (loop (+ x 1))))


 -- procedure: thread-terminate! THREAD
     This procedure causes an abnormal termination of the THREAD.  If
     the THREAD is not already terminated, all mutexes owned by the
     THREAD become unlocked/abandoned and a terminated-thread-exception
     object is stored in the THREAD's end-exception field.  If THREAD
     is the current thread, `thread-terminate!' does not return.
     Otherwise `thread-terminate!' returns an unspecified value; the
     termination of the THREAD will occur at some point between the
     calling of `thread-terminate!'  and a finite time in the future
     (an explicit thread synchronization is needed to detect
     termination, see `thread-join!').

     For example:

          (define (amb thunk1 thunk2)
            (let ((result #f)
                  (result-mutex (make-mutex))
                  (done-mutex (make-mutex)))
              (letrec ((child1
                        (make-thread
                          (lambda ()
                            (let ((x (thunk1)))
                              (mutex-lock! result-mutex #f #f)
                              (set! result x)
                              (thread-terminate! child2)
                              (mutex-unlock! done-mutex)))))
                       (child2
                        (make-thread
                          (lambda ()
                            (let ((x (thunk2)))
                              (mutex-lock! result-mutex #f #f)
                              (set! result x)
                              (thread-terminate! child1)
                              (mutex-unlock! done-mutex))))))
                (mutex-lock! done-mutex #f #f)
                (thread-start! child1)
                (thread-start! child2)
                (mutex-lock! done-mutex #f #f)
                result)))

     NOTE: This operation must be used carefully because it terminates a
     thread abruptly and it is impossible for that thread to perform any
     kind of cleanup.  This may be a problem if the thread is in the
     middle of a critical section where some structure has been put in
     an inconsistent state.  However, another thread attempting to
     enter this critical section will raise an
     abandoned-mutex-exception object because the mutex is
     unlocked/abandoned.  This helps avoid observing an inconsistent
     state.  Clean termination can be obtained by polling, as shown in
     the example below.

     For example:

          (define (spawn thunk)
            (let ((t (make-thread thunk)))
              (thread-specific-set! t #t)
              (thread-start! t)
              t))

          (define (stop! thread)
            (thread-specific-set! thread #f)
            (thread-join! thread))

          (define (keep-going?)
            (thread-specific (current-thread)))

          (define count!
            (let ((m (make-mutex))
                  (i 0))
              (lambda ()
                (mutex-lock! m)
                (let ((x (+ i 1)))
                  (set! i x)
                  (mutex-unlock! m)
                  x))))

          (define (increment-forever!)
            (let loop () (count!) (if (keep-going?) (loop))))

          (let ((t1 (spawn increment-forever!))
                (t2 (spawn increment-forever!)))
            (thread-sleep! 1)
            (stop! t1)
            (stop! t2)
            (count!))  ==>  377290


 -- procedure: thread-join! thread [TIMEOUT [TIMEOUT-VAL]]
     This procedure causes the current thread to wait until the THREAD
     terminates (normally or not) or until the timeout is reached if
     TIMEOUT is supplied.  If the timeout is reached, THREAD-JOIN!
     returns TIMEOUT-VAL if it is supplied, otherwise a
     join-timeout-exception object is raised.  If the THREAD terminated
     normally, the content of the end-result field is returned,
     otherwise the content of the end-exception field is raised.

     For example:

          (let ((t (thread-start! (make-thread (lambda () (expt 2 100))))))
            (do-something-else)
            (thread-join! t))  ==>  1267650600228229401496703205376

          (let ((t (thread-start! (make-thread (lambda () (raise 123))))))
            (do-something-else)
            (with-exception-handler
              (lambda (exc)
                (if (uncaught-exception? exc)
                    (* 10 (uncaught-exception-reason exc))
                    99999))
              (lambda ()
                (+ 1 (thread-join! t)))))  ==>  1231

          (define thread-alive?
            (let ((unique (list 'unique)))
              (lambda (thread)
                ; Note: this procedure raises an exception if
                ; the thread terminated abnormally.
                (eq? (thread-join! thread 0 unique) unique))))

          (define (wait-for-termination! thread)
            (let ((eh (current-exception-handler)))
              (with-exception-handler
                (lambda (exc)
                  (if (not (or (terminated-thread-exception? exc)
                               (uncaught-exception? exc)))
                      (eh exc))) ; unexpected exceptions are handled by eh
                (lambda ()
                  ; The following call to thread-join! will wait until the
                  ; thread terminates.  If the thread terminated normally
                  ; thread-join! will return normally.  If the thread
                  ; terminated abnormally then one of these two exception
                  ; objects is raised by thread-join!:
                  ;   - terminated-thread-exception object
                  ;   - uncaught-exception object
                  (thread-join! thread)
                  #f)))) ; ignore result of thread-join!


 -- procedure: thread-send THREAD MSG
     Each thread has a mailbox which stores messages delivered to the
     thread in the order delivered.

     The procedure `thread-send' adds the message MSG at the end of the
     mailbox of thread THREAD and returns an unspecified value.

     For example:

          > (thread-send (current-thread) 111)
          > (thread-send (current-thread) 222)
          > (thread-receive)
          111
          > (thread-receive)
          222


 -- procedure: thread-receive [TIMEOUT [DEFAULT]]
 -- procedure: thread-mailbox-next [TIMEOUT [DEFAULT]]
 -- procedure: thread-mailbox-rewind
 -- procedure: thread-mailbox-extract-and-rewind
     To allow a thread to examine the messages in its mailbox without
     removing them from the mailbox, each thread has a "mailbox cursor"
     which normally points to the last message accessed in the mailbox.
     When a mailbox cursor is rewound using the procedure
     `thread-mailbox-rewind' or `thread-mailbox-extract-and-rewind' or
     `thread-receive', the cursor does not point to a message, but the
     next call to `thread-receive' and `thread-mailbox-next' will set
     the cursor to the oldest message in the mailbox.

     The procedure `thread-receive' advances the mailbox cursor of the
     current thread to the next message, removes that message from the
     mailbox, rewinds the mailbox cursor, and returns the message.  When
     TIMEOUT is not specified, the current thread will wait until a
     message is available in the mailbox.  When TIMEOUT is specified
     and DEFAULT is not specified, a mailbox-receive-timeout-exception
     object is raised if the timeout is reached before a message is
     available.  When TIMEOUT is specified and DEFAULT is specified,
     DEFAULT is returned if the timeout is reached before a message is
     available.

     The procedure `thread-mailbox-next' behaves like `thread-receive'
     except that the message remains in the mailbox and the mailbox
     cursor is not rewound.

     The procedures `thread-mailbox-rewind' or
     `thread-mailbox-extract-and-rewind' rewind the mailbox cursor of
     the current thread so that the next call to `thread-mailbox-next'
     and `thread-receive' will access the oldest message in the
     mailbox.  Additionally the procedure
     `thread-mailbox-extract-and-rewind' will remove from the mailbox
     the message most recently accessed by a call to
     `thread-mailbox-next'.  When `thread-mailbox-next' has not been
     called since the last call to `thread-receive' or
     `thread-mailbox-rewind' or `thread-mailbox-extract-and-rewind', a
     call to `thread-mailbox-extract-and-rewind' only resets the mailbox
     cursor (no message is removed).

     For example:

          > (thread-send (current-thread) 111)
          > (thread-receive 1 999)
          111
          > (thread-send (current-thread) 222)
          > (thread-send (current-thread) 333)
          > (thread-mailbox-next 1 999)
          222
          > (thread-mailbox-next 1 999)
          333
          > (thread-mailbox-next 1 999)
          999
          > (thread-mailbox-extract-and-rewind)
          > (thread-receive 1 999)
          222
          > (thread-receive 1 999)
          999


 -- procedure: mailbox-receive-timeout-exception? OBJ
 -- procedure: mailbox-receive-timeout-exception-procedure EXC
 -- procedure: mailbox-receive-timeout-exception-arguments EXC
     Mailbox-receive-timeout-exception objects are raised by the
     procedures `thread-receive' and `thread-mailbox-next' when a
     timeout expires before a message is available and no default value
     is specified.  The parameter EXC must be a
     mailbox-receive-timeout-exception object.

     The procedure `mailbox-receive-timeout-exception?' returns `#t'
     when OBJ is a mailbox-receive-timeout-exception object and `#f'
     otherwise.

     The procedure `mailbox-receive-timeout-exception-procedure'
     returns the procedure that raised EXC.

     The procedure `mailbox-receive-timeout-exception-arguments'
     returns the list of arguments of the procedure that raised EXC.

     For example:

          > (define (handler exc)
              (if (mailbox-receive-timeout-exception? exc)
                  (list (mailbox-receive-timeout-exception-procedure exc)
                        (mailbox-receive-timeout-exception-arguments exc))
                  'not-mailbox-receive-timeout-exception))
          > (with-exception-catcher
              handler
              (lambda () (thread-receive 1)))
          (#<procedure #2 thread-receive> (1))


 -- procedure: mutex? OBJ
     This procedure returns `#t' when OBJ is a mutex object and `#f'
     otherwise.

     For example:

          > (mutex? (make-mutex))
          #t
          > (mutex? 'foo)
          #f


 -- procedure: make-mutex [NAME]
     This procedure returns a new mutex in the unlocked/not-abandoned
     state.  The optional NAME is an arbitrary Scheme object which
     identifies the mutex (useful for debugging); it defaults to an
     unspecified value.  The mutex's specific field is set to an
     unspecified value.

     For example:

          > (make-mutex)
          #<mutex #2>
          > (make-mutex 'foo)
          #<mutex #3 foo>


 -- procedure: mutex-name MUTEX
     Returns the name of the MUTEX.  For example:

          > (mutex-name (make-mutex 'foo))
          foo


 -- procedure: mutex-specific MUTEX
 -- procedure: mutex-specific-set! MUTEX OBJ
     The `mutex-specific' procedure returns the content of the MUTEX's
     specific field.

     The `mutex-specific-set!' procedure stores OBJ into the MUTEX's
     specific field and returns an unspecified value.

     For example:

          > (define m (make-mutex))
          > (mutex-specific-set! m "hello")
          > (mutex-specific m)
          "hello"
          > (define (mutex-lock-recursively! mutex)
              (if (eq? (mutex-state mutex) (current-thread))
                  (let ((n (mutex-specific mutex)))
                    (mutex-specific-set! mutex (+ n 1)))
                  (begin
                    (mutex-lock! mutex)
                    (mutex-specific-set! mutex 0))))
          > (define (mutex-unlock-recursively! mutex)
              (let ((n (mutex-specific mutex)))
                (if (= n 0)
                    (mutex-unlock! mutex)
                    (mutex-specific-set! mutex (- n 1)))))
          > (mutex-lock-recursively! m)
          > (mutex-lock-recursively! m)
          > (mutex-lock-recursively! m)
          > (mutex-specific m)
          2


 -- procedure: mutex-state MUTEX
     Thos procedure returns information about the state of the MUTEX.
     The possible results are:

        * thread T: the MUTEX is in the locked/owned state and thread T
          is the owner of the MUTEX

        * symbol `not-owned': the MUTEX is in the locked/not-owned state

        * symbol `abandoned': the MUTEX is in the unlocked/abandoned
          state

        * symbol `not-abandoned': the MUTEX is in the
          unlocked/not-abandoned state


     For example:

          (mutex-state (make-mutex))  ==>  not-abandoned

          (define (thread-alive? thread)
            (let ((mutex (make-mutex)))
              (mutex-lock! mutex #f thread)
              (let ((state (mutex-state mutex)))
                (mutex-unlock! mutex) ; avoid space leak
                (eq? state thread))))


 -- procedure: mutex-lock! MUTEX [TIMEOUT [THREAD]]
     This procedure locks MUTEX.  If the MUTEX is currently locked, the
     current thread waits until the MUTEX is unlocked, or until the
     timeout is reached if TIMEOUT is supplied.  If the timeout is
     reached, `mutex-lock!' returns `#f'.  Otherwise, the state of the
     MUTEX is changed as follows:

        * if THREAD is `#f' the MUTEX becomes locked/not-owned,

        * otherwise, let T be THREAD (or the current thread if THREAD
          is not supplied),

             * if T is terminated the MUTEX becomes unlocked/abandoned,

             * otherwise MUTEX becomes locked/owned with T as the owner.



     After changing the state of the MUTEX, an
     abandoned-mutex-exception object is raised if the MUTEX was
     unlocked/abandoned before the state change, otherwise
     `mutex-lock!' returns `#t'.  It is not an error if the MUTEX is
     owned by the current thread (but the current thread will have to
     wait).

     For example:

          ; an implementation of a mailbox object of depth one; this
          ; implementation does not behave well in the presence of forced
          ; thread terminations using thread-terminate! (deadlock can occur
          ; if a thread is terminated in the middle of a put! or get! operation)

          (define (make-empty-mailbox)
            (let ((put-mutex (make-mutex)) ; allow put! operation
                  (get-mutex (make-mutex))
                  (cell #f))

              (define (put! obj)
                (mutex-lock! put-mutex #f #f) ; prevent put! operation
                (set! cell obj)
                (mutex-unlock! get-mutex)) ; allow get! operation

              (define (get!)
                (mutex-lock! get-mutex #f #f) ; wait until object in mailbox
                (let ((result cell))
                  (set! cell #f) ; prevent space leaks
                  (mutex-unlock! put-mutex) ; allow put! operation
                  result))

              (mutex-lock! get-mutex #f #f) ; prevent get! operation

              (lambda (msg)
                (case msg
                  ((put!) put!)
                  ((get!) get!)
                  (else (error "unknown message"))))))

          (define (mailbox-put! m obj) ((m 'put!) obj))
          (define (mailbox-get! m) ((m 'get!)))

          ; an alternate implementation of thread-sleep!

          (define (sleep! timeout)
            (let ((m (make-mutex)))
              (mutex-lock! m #f #f)
              (mutex-lock! m timeout #f)))

          ; a procedure that waits for one of two mutexes to unlock

          (define (lock-one-of! mutex1 mutex2)
            ; this procedure assumes that neither mutex1 or mutex2
            ; are owned by the current thread
            (let ((ct (current-thread))
                  (done-mutex (make-mutex)))
              (mutex-lock! done-mutex #f #f)
              (let ((t1 (thread-start!
                         (make-thread
                          (lambda ()
                            (mutex-lock! mutex1 #f ct)
                            (mutex-unlock! done-mutex)))))
                    (t2 (thread-start!
                         (make-thread
                          (lambda ()
                            (mutex-lock! mutex2 #f ct)
                            (mutex-unlock! done-mutex))))))
                (mutex-lock! done-mutex #f #f)
                (thread-terminate! t1)
                (thread-terminate! t2)
                (if (eq? (mutex-state mutex1) ct)
                    (begin
                      (if (eq? (mutex-state mutex2) ct)
                          (mutex-unlock! mutex2)) ; don't lock both
                      mutex1)
                    mutex2))))


 -- procedure: mutex-unlock! MUTEX [CONDITION-VARIABLE [TIMEOUT]]
     This procedure unlocks the MUTEX by making it
     unlocked/not-abandoned.  It is not an error to unlock an unlocked
     mutex and a mutex that is owned by any thread.  If
     CONDITION-VARIABLE is supplied, the current thread is blocked and
     added to the CONDITION-VARIABLE before unlocking MUTEX; the thread
     can unblock at any time but no later than when an appropriate call
     to `condition-variable-signal!' or `condition-variable-broadcast!'
     is performed (see below), and no later than the timeout (if
     TIMEOUT is supplied).  If there are threads waiting to lock this
     MUTEX, the scheduler selects a thread, the mutex becomes
     locked/owned or locked/not-owned, and the thread is unblocked.
     `mutex-unlock!' returns `#f' when the timeout is reached,
     otherwise it returns `#t'.

     NOTE: The reason the thread can unblock at any time (when
     CONDITION-VARIABLE is supplied) is that the scheduler, when it
     detects a serious problem such as a deadlock, must interrupt one of
     the blocked threads (such as the primordial thread) so that it can
     perform some appropriate action.  After a thread blocked on a
     condition-variable has handled such an interrupt it would be wrong
     for the scheduler to return the thread to the blocked state,
     because any calls to `condition-variable-broadcast!' during the
     interrupt will have gone unnoticed.  It is necessary for the
     thread to remain runnable and return from the call to
     `mutex-unlock!' with a result of `#t'.

     NOTE: `mutex-unlock!' is related to the "wait" operation on
     condition variables available in other thread systems.  The main
     difference is that "wait" automatically locks MUTEX just after the
     thread is unblocked.  This operation is not performed by
     `mutex-unlock!' and so must be done by an explicit call to
     `mutex-lock!'.  This has the advantages that a different timeout
     and exception-handler can be specified on the `mutex-lock!' and
     `mutex-unlock!' and the location of all the mutex operations is
     clearly apparent.

     For example:

          (let loop ()
            (mutex-lock! m)
            (if (condition-is-true?)
                (begin
                  (do-something-when-condition-is-true)
                  (mutex-unlock! m))
                (begin
                  (mutex-unlock! m cv)
                  (loop))))


 -- procedure: condition-variable? OBJ
     This procedure returns `#t' when OBJ is a condition-variable
     object and `#f' otherwise.

     For example:

          > (condition-variable? (make-condition-variable))
          #t
          > (condition-variable? 'foo)
          #f


 -- procedure: make-condition-variable [NAME]
     This procedure returns a new empty condition variable.  The
     optional NAME is an arbitrary Scheme object which identifies the
     condition variable (useful for debugging); it defaults to an
     unspecified value.  The condition variable's specific field is set
     to an unspecified value.

     For example:

          > (make-condition-variable)
          #<condition-variable #2>


 -- procedure: condition-variable-name CONDITION-VARIABLE
     This procedure returns the name of the CONDITION-VARIABLE.  For
     example:

          > (condition-variable-name (make-condition-variable 'foo))
          foo


 -- procedure: condition-variable-specific CONDITION-VARIABLE
 -- procedure: condition-variable-specific-set! CONDITION-VARIABLE OBJ
     The `condition-variable-specific' procedure returns the content of
     the CONDITION-VARIABLE's specific field.

     The `condition-variable-specific-set!' procedure stores OBJ into
     the CONDITION-VARIABLE's specific field and returns an unspecified
     value.

     For example:

          > (define cv (make-condition-variable))
          > (condition-variable-specific-set! cv "hello")
          > (condition-variable-specific cv)
          "hello"


 -- procedure: condition-variable-signal! CONDITION-VARIABLE
     This procedure unblocks a thread blocked on the CONDITION-VARIABLE
     (if there is at least one) and returns an unspecified value.

     For example:

          ; an implementation of a mailbox object of depth one; this
          ; implementation behaves gracefully when threads are forcibly
          ; terminated using thread-terminate! (an abandoned-mutex-exception
          ; object will be raised when a put! or get! operation is attempted
          ; after a thread is terminated in the middle of a put! or get!
          ; operation)

          (define (make-empty-mailbox)
            (let ((mutex (make-mutex))
                  (put-condvar (make-condition-variable))
                  (get-condvar (make-condition-variable))
                  (full? #f)
                  (cell #f))

              (define (put! obj)
                (mutex-lock! mutex)
                (if full?
                    (begin
                      (mutex-unlock! mutex put-condvar)
                      (put! obj))
                    (begin
                      (set! cell obj)
                      (set! full? #t)
                      (condition-variable-signal! get-condvar)
                      (mutex-unlock! mutex))))

              (define (get!)
                (mutex-lock! mutex)
                (if (not full?)
                    (begin
                      (mutex-unlock! mutex get-condvar)
                      (get!))
                    (let ((result cell))
                      (set! cell #f) ; avoid space leaks
                      (set! full? #f)
                      (condition-variable-signal! put-condvar)
                      (mutex-unlock! mutex)
                      result)))

              (lambda (msg)
                (case msg
                  ((put!) put!)
                  ((get!) get!)
                  (else (error "unknown message"))))))

          (define (mailbox-put! m obj) ((m 'put!) obj))
          (define (mailbox-get! m) ((m 'get!)))


 -- procedure: condition-variable-broadcast! CONDITION-VARIABLE
     This procedure unblocks all the thread blocked on the
     CONDITION-VARIABLE and returns an unspecified value.

     For example:

          (define (make-semaphore n)
            (vector n (make-mutex) (make-condition-variable)))

          (define (semaphore-wait! sema)
            (mutex-lock! (vector-ref sema 1))
            (let ((n (vector-ref sema 0)))
              (if (> n 0)
                  (begin
                    (vector-set! sema 0 (- n 1))
                    (mutex-unlock! (vector-ref sema 1)))
                  (begin
                    (mutex-unlock! (vector-ref sema 1) (vector-ref sema 2))
                    (semaphore-wait! sema))))

          (define (semaphore-signal-by! sema increment)
            (mutex-lock! (vector-ref sema 1))
            (let ((n (+ (vector-ref sema 0) increment)))
              (vector-set! sema 0 n)
              (if (> n 0)
                  (condition-variable-broadcast! (vector-ref sema 2)))
              (mutex-unlock! (vector-ref sema 1))))



File: gambit.info,  Node: Dynamic environment,  Next: Exceptions,  Prev: Threads,  Up: Top

14 Dynamic environment
**********************

The "dynamic environment" is the structure which allows the system to
find the value returned by the standard procedures `current-input-port'
and `current-output-port'.  The standard procedures
`with-input-from-file' and `with-output-to-file' extend the dynamic
environment to produce a new dynamic environment which is in effect for
the dynamic extent of the call to the thunk passed as their last
argument.  These procedures are essentially special purpose dynamic
binding operations on hidden dynamic variables (one for
`current-input-port' and one for `current-output-port').  Gambit
generalizes this dynamic binding mechanism to allow the user to
introduce new dynamic variables, called "parameter objects", and
dynamically bind them.  The parameter objects implemented by Gambit are
compatible with the specification of the "Parameter objects SRFI" (SRFI
39).

   One important issue is the relationship between the dynamic
environments of the parent and child threads when a thread is created.
Each thread has its own dynamic environment that is accessed when
looking up the value bound to a parameter object by that thread.  When
a thread's dynamic environment is extended it does not affect the
dynamic environment of other threads.  When a thread is created it is
given a dynamic environment whose bindings are inherited from the
parent thread.  In this inherited dynamic environment the parameter
objects are bound to the same cells as the parent's dynamic environment
(in other words an assignment of a new value to a parameter object is
visible in the other thread).

   Another important issue is the interaction between the
`dynamic-wind' procedure and dynamic environments.  When a thread
creates a continuation, the thread's dynamic environment and the
`dynamic-wind' stack are saved within the continuation (an alternate
but equivalent point of view is that the `dynamic-wind' stack is part
of the dynamic environment).  When this continuation is invoked the
required `dynamic-wind' before and after thunks are called and the
saved dynamic environment is reinstated as the dynamic environment of
the current thread.  During the call to each required `dynamic-wind'
before and after thunk, the dynamic environment and the `dynamic-wind'
stack in effect when the corresponding `dynamic-wind' was executed are
reinstated.  Note that this specification precisely defines the
semantics of calling `call-with-current-continuation' or invoking a
continuation within a before or after thunk.  The semantics are well
defined even when a continuation created by another thread is invoked.
Below is an example exercising the subtleties of this semantics.

     (with-output-to-file
      "foo"
      (lambda ()
        (let ((k (call-with-current-continuation
                  (lambda (exit)
                    (with-output-to-file
                     "bar"
                     (lambda ()
                       (dynamic-wind
                        (lambda ()
                          (write '(b1))
                          (force-output))
                        (lambda ()
                          (let ((x (call-with-current-continuation
                                    (lambda (cont) (exit cont)))))
                            (write '(t1))
                            (force-output)
                            x))
                        (lambda ()
                          (write '(a1))
                          (force-output)))))))))
          (if k
              (dynamic-wind
               (lambda ()
                 (write '(b2))
                 (force-output))
               (lambda ()
                 (with-output-to-file
                  "baz"
                  (lambda ()
                    (write '(t2))
                    (force-output)
                    ; go back inside (with-output-to-file "bar" ...)
                    (k #f))))
               (lambda ()
                 (write '(a2))
                 (force-output)))))))

   The following actions will occur when this code is executed:
`(b1)(a1)' is written to "bar", `(b2)' is then written to "foo", `(t2)'
is then written to "baz", `(a2)' is then written to "foo", and finally
`(b1)(t1)(a1)' is written to "bar".

 -- procedure: make-parameter OBJ [FILTER]
     The dynamic environment is composed of two parts: the "local
     dynamic environment" and the "global dynamic environment".  There
     is a single global dynamic environment, and it is used to lookup
     parameter objects that can't be found in the local dynamic
     environment.

     The `make-parameter' procedure returns a new "parameter object".
     The FILTER argument is a one argument conversion procedure.  If it
     is not specified, FILTER defaults to the identity function.

     The global dynamic environment is updated to associate the
     parameter object to a new cell.  The initial content of the cell
     is the result of applying the conversion procedure to OBJ.

     A parameter object is a procedure which accepts zero or one
     argument.  The cell bound to a particular parameter object in the
     dynamic environment is accessed by calling the parameter object.
     When no argument is passed, the content of the cell is returned.
     When one argument is passed the content of the cell is updated
     with the result of applying the parameter object's conversion
     procedure to the argument.  Note that the conversion procedure can
     be used for guaranteeing the type of the parameter object's
     binding and/or to perform some conversion of the value.

     For example:

          > (define radix (make-parameter 10))
          > (radix)
          10
          > (radix 2)
          > (radix)
          2
          > (define prompt
              (make-parameter
                123
                (lambda (x)
                  (if (string? x)
                      x
                      (object->string x)))))
          > (prompt)
          "123"
          > (prompt "$")
          > (prompt)
          "$"
          > (define write-shared
              (make-parameter
                #f
                (lambda (x)
                  (if (boolean? x)
                      x
                      (error "only booleans are accepted by write-shared")))))
          > (write-shared 123)
          *** ERROR IN ##make-parameter -- only booleans are accepted by write-shared


 -- special form: parameterize ((procedure value)...) body
     The `parameterize' form, evaluates all procedure and value
     expressions in an unspecified order.  All the procedure
     expressions must evaluate to procedures, either parameter objects
     or procedures accepting zero and one argument.  Then, for each
     procedure p and in an unspecified order:

        * If p is a parameter object a new cell is created,
          initialized, and bound to the parameter object in the local
          dynamic environment.  The value contained in the cell is the
          result of applying the parameter object's conversion
          procedure to value.  The resulting dynamic environment is
          then used for processing the remaining bindings (or the
          evaluation of body if there are no other bindings).

        * Otherwise p will be used according to the following protocol:
          we say that the call `(p)' "gets p's value" and that the call
          `(p x)' "sets p's value to x".  First, the `parameterize'
          form gets p's value and saves it in a local variable.  It
          then sets p's value to value.  It then processes the
          remaining bindings (or evaluates body if there are no other
          bindings).  Then it sets p's value to the saved value.  These
          steps are performed in a `dynamic-wind' so that it is
          possible to use continuations to jump into and out of the body
          (i.e. the `dynamic-wind''s before thunk sets p's value to
          value and the after thunk sets p's value to the saved value).


     The result(s) of the `parameterize' form are the result(s) of the
     body.

     Note that using procedures instead of parameter objects may lead to
     unexpected results in multithreaded programs because the before and
     after thunks of the `dynamic-wind' are not called when control
     switches between threads.

     For example:

          > (define radix (make-parameter 2))
          > (define prompt
              (make-parameter
                123
                (lambda (x)
                  (if (string? x)
                      x
                      (object->string x)))))
          > (radix)
          2
          > (parameterize ((radix 16)) (radix))
          16
          > (radix)
          2
          > (define (f n) (number->string n (radix)))
          > (f 10)
          "1010"
          > (parameterize ((radix 8)) (f 10))
          "12"
          > (parameterize ((radix 8) (prompt (f 10))) (prompt))
          "1010"
          > (define p
              (let ((x 1))
                (lambda args
                  (if (null? args) x (set! x (car args))))))
          > (let* ((a (p))
                   (b (parameterize ((p 2)) (list (p))))
                   (c (p)))
              (list a b c))
          (1 (2) 1)



File: gambit.info,  Node: Exceptions,  Next: Host environment,  Prev: Dynamic environment,  Up: Top

15 Exceptions
*************

* Menu:

* Exception-handling::                                      Exception-handling
* Exception objects related to memory management::          Exception objects related to memory management
* Exception objects related to the host environment::       Exception objects related to the host environment
* Exception objects related to threads::                    Exception objects related to threads
* Exception objects related to C-interface::                Exception objects related to C-interface
* Exception objects related to the reader::                 Exception objects related to the reader
* Exception objects related to evaluation and compilation:: Exception objects related to evaluation and compilation
* Exception objects related to type checking::              Exception objects related to type checking
* Exception objects related to procedure call::             Exception objects related to procedure call
* Other exception objects::                                 Other exception objects


File: gambit.info,  Node: Exception-handling,  Next: Exception objects related to memory management,  Prev: Exceptions,  Up: Exceptions

15.1 Exception-handling
=======================

Gambit's exception-handling model is inspired from the withdrawn
"Exception Handling SRFI" (SRFI 12), the "Multithreading support SRFI"
(SRFI 18), and the "Exception Handling for Programs SRFI" (SRFI 34).
The two fundamental operations are the dynamic binding of an exception
handler (i.e. the procedure `with-exception-handler') and the
invocation of the exception handler (i.e. the procedure `raise').

   All predefined procedures which check for errors (including type
errors, memory allocation errors, host operating-system errors, etc)
report these errors using the exception-handling system (i.e. they
"raise" an exception that can be handled in a user-defined exception
handler).  When an exception is raised and the exception is not handled
by a user-defined exception handler, the predefined exception handler
will display an error message (if the primordial thread raised the
exception) or the thread will silently terminate with no error message
(if it is not the primordial thread that raised the exception).  This
default behavior can be changed through the `-:d' runtime option (*note
Runtime options::).

   Predefined procedures normally raise exceptions by performing a
tail-call to the exception handler (the exceptions are "complex"
procedures such as `eval', `compile-file', `read', `write', etc).  This
means that the continuation of the exception handler and of the REPL
that may be started due to this is normally the continuation of the
predefined procedure that raised the exception.  By exiting the REPL
with the `,(c EXPRESSION)' command it is thus possible to resume the
program as though the call to the predefined procedure returned the
value of EXPRESSION.  For example:

     > (define (f x) (+ (car x) 1))
     > (f 2) ; typo... we meant to say (f '(2))
     *** ERROR IN f, (console)@1.18 -- (Argument 1) PAIR expected
     (car 2)
     1> ,(c 2)
     3

 -- procedure: current-exception-handler [NEW-EXCEPTION-HANDLER]
     The parameter object `current-exception-handler' is bound to the
     current exception-handler.  Calling this procedure with no argument
     returns the current exception-handler and calling this procedure
     with one argument sets the current exception-handler to
     NEW-EXCEPTION-HANDLER.

     For example:

          > (current-exception-handler)
          #<procedure #2 primordial-exception-handler>
          > (current-exception-handler (lambda (exc) (pp exc) 999))
          > (/ 1 0)
          #<divide-by-zero-exception #3>
          999


 -- procedure: with-exception-handler HANDLER THUNK
     Returns the result(s) of calling THUNK with no arguments.  The
     HANDLER, which must be a procedure, is installed as the current
     exception-handler in the dynamic environment in effect during the
     call to THUNK.  Note that the dynamic environment in effect during
     the call to HANDLER has HANDLER as the exception-handler.
     Consequently, an exception raised during the call to HANDLER may
     lead to an infinite loop.

     For example:

          > (with-exception-handler
              (lambda (e) (write e) 5)
              (lambda () (+ 1 (* 2 3) 4)))
          11
          > (with-exception-handler
              (lambda (e) (write e) 5)
              (lambda () (+ 1 (* 'foo 3) 4)))
          #<type-exception #2>10
          > (with-exception-handler
              (lambda (e) (write e 9))
              (lambda () (+ 1 (* 'foo 3) 4)))
          INFINITE LOOP


 -- procedure: with-exception-catcher HANDLER THUNK
     Returns the result(s) of calling THUNK with no arguments.  A new
     exception-handler is installed as the current exception-handler in
     the dynamic environment in effect during the call to THUNK.  This
     new exception-handler will call the HANDLER, which must be a
     procedure, with the exception object as an argument and with the
     same continuation as the call to `with-exception-catcher'.  This
     implies that the dynamic environment in effect during the call to
     HANDLER is the same as the one in effect at the call to
     `with-exception-catcher'.  Consequently, an exception raised
     during the call to HANDLER will not lead to an infinite loop.

     For example:

          > (with-exception-catcher
              (lambda (e) (write e) 5)
              (lambda () (+ 1 (* 2 3) 4)))
          11
          > (with-exception-catcher
              (lambda (e) (write e) 5)
              (lambda () (+ 1 (* 'foo 3) 4)))
          #<type-exception #2>5
          > (with-exception-catcher
              (lambda (e) (write e 9))
              (lambda () (+ 1 (* 'foo 3) 4)))
          *** ERROR IN (console)@7.1 -- (Argument 2) OUTPUT PORT expected
          (write '#<type-exception #3> 9)


 -- procedure: raise OBJ
     This procedure tail-calls the current exception-handler with OBJ
     as the sole argument.  If the exception-handler returns, the
     continuation of the call to `raise' is invoked.

     For example:

          > (with-exception-handler
              (lambda (exc)
                (pp exc)
                100)
              (lambda ()
                (+ 1 (raise "hello"))))
          "hello"
          101


 -- procedure: abort OBJ
 -- procedure: noncontinuable-exception? OBJ
 -- procedure: noncontinuable-exception-reason EXC
     The procedure `abort' calls the current exception-handler with OBJ
     as the sole argument.  If the exception-handler returns, the
     procedure `abort' will be tail-called with a
     noncontinuable-exception object, whose reason field is OBJ, as
     sole argument.

     Noncontinuable-exception objects are raised by the `abort'
     procedure when the exception-handler returns.  The parameter EXC
     must be a noncontinuable-exception object.

     The procedure `noncontinuable-exception?' returns `#t' when OBJ is
     a noncontinuable-exception object and `#f' otherwise.

     The procedure `noncontinuable-exception-reason' returns the
     argument of the call to `abort' that raised EXC.

     For example:

          > (call-with-current-continuation
              (lambda (k)
                (with-exception-handler
                  (lambda (exc)
                    (pp exc)
                    (if (noncontinuable-exception? exc)
                        (k (list (noncontinuable-exception-reason exc)))
                        100))
                  (lambda ()
                    (+ 1 (abort "hello"))))))
          "hello"
          #<noncontinuable-exception #2>
          ("hello")



File: gambit.info,  Node: Exception objects related to memory management,  Next: Exception objects related to the host environment,  Prev: Exception-handling,  Up: Exceptions

15.2 Exception objects related to memory management
===================================================

 -- procedure: heap-overflow-exception? OBJ
     Heap-overflow-exception objects are raised when the allocation of
     an object would cause the heap to use more memory space than is
     available.

     The procedure `heap-overflow-exception?' returns `#t' when OBJ is
     a heap-overflow-exception object and `#f' otherwise.

     For example:

          > (define (handler exc)
              (if (heap-overflow-exception? exc)
                  exc
                  'not-heap-overflow-exception))
          > (with-exception-catcher
              handler
              (lambda ()
                (define (f x) (f (cons 1 x)))
                (f '())))
          #<heap-overflow-exception #2>


 -- procedure: stack-overflow-exception? OBJ
     Stack-overflow-exception objects are raised when the allocation of
     a continuation frame would cause the heap to use more memory space
     than is available.

     The procedure `stack-overflow-exception?' returns `#t' when OBJ is
     a stack-overflow-exception object and `#f' otherwise.

     For example:

          > (define (handler exc)
              (if (stack-overflow-exception? exc)
                  exc
                  'not-stack-overflow-exception))
          > (with-exception-catcher
              handler
              (lambda ()
                (define (f) (+ 1 (f)))
                (f)))
          #<stack-overflow-exception #2>



File: gambit.info,  Node: Exception objects related to the host environment,  Next: Exception objects related to threads,  Prev: Exception objects related to memory management,  Up: Exceptions

15.3 Exception objects related to the host environment
======================================================

 -- procedure: os-exception? OBJ
 -- procedure: os-exception-procedure EXC
 -- procedure: os-exception-arguments EXC
 -- procedure: os-exception-code EXC
 -- procedure: os-exception-message EXC
     Os-exception objects are raised by procedures which access the host
     operating-system's services when the requested operation fails.
     The parameter EXC must be a os-exception object.

     The procedure `os-exception?' returns `#t' when OBJ is a
     os-exception object and `#f' otherwise.

     The procedure `os-exception-procedure' returns the procedure that
     raised EXC.

     The procedure `os-exception-arguments' returns the list of
     arguments of the procedure that raised EXC.

     The procedure `os-exception-code' returns an exact integer error
     code that can be converted to a string by the `err-code->string'
     procedure.  Note that the error code is operating-system dependent.

     The procedure `os-exception-message' returns `#f' or a string
     giving details of the exception in a human-readable form.

     For example:

          > (define (handler exc)
              (if (os-exception? exc)
                  (list (os-exception-procedure exc)
                        (os-exception-arguments exc)
                        (err-code->string (os-exception-code exc))
                        (os-exception-message exc))
                  'not-os-exception))
          > (with-exception-catcher
              handler
              (lambda () (host-info "x.y.z")))
          (#<procedure #2 host-info> ("x.y.z") "Unknown host" #f)


 -- procedure: no-such-file-or-directory-exception? OBJ
 -- procedure: no-such-file-or-directory-exception-procedure EXC
 -- procedure: no-such-file-or-directory-exception-arguments EXC
     No-such-file-or-directory-exception objects are raised by
     procedures which access the filesystem (such as `open-input-file'
     and `directory-files') when the path specified can't be found on
     the filesystem.  The parameter EXC must be a
     no-such-file-or-directory-exception object.

     The procedure `no-such-file-or-directory-exception?' returns `#t'
     when OBJ is a no-such-file-or-directory-exception object and `#f'
     otherwise.

     The procedure `no-such-file-or-directory-exception-procedure'
     returns the procedure that raised EXC.

     The procedure `no-such-file-or-directory-exception-arguments'
     returns the list of arguments of the procedure that raised EXC.

     For example:

          > (define (handler exc)
              (if (no-such-file-or-directory-exception? exc)
                  (list (no-such-file-or-directory-exception-procedure exc)
                        (no-such-file-or-directory-exception-arguments exc))
                  'not-no-such-file-or-directory-exception))
          > (with-exception-catcher
              handler
              (lambda () (with-input-from-file "nofile" read)))
          (#<procedure #2 with-input-from-file> ("nofile" #<procedure #3 read>))


 -- procedure: unbound-os-environment-variable-exception? OBJ
 -- procedure: unbound-os-environment-variable-exception-procedure EXC
 -- procedure: unbound-os-environment-variable-exception-arguments EXC
     Unbound-os-environment-variable-exception objects are raised when
     an unbound operating-system environment variable is accessed by the
     procedures `getenv' and `setenv'.  The parameter EXC must be an
     unbound-os-environment-variable-exception object.

     The procedure `unbound-os-environment-variable-exception?' returns
     `#t' when OBJ is an unbound-os-environment-variable-exception
     object and `#f' otherwise.

     The procedure `unbound-os-environment-variable-exception-procedure'
     returns the procedure that raised EXC.

     The procedure `unbound-os-environment-variable-exception-arguments'
     returns the list of arguments of the procedure that raised EXC.

     For example:

          > (define (handler exc)
              (if (unbound-os-environment-variable-exception? exc)
                  (list (unbound-os-environment-variable-exception-procedure exc)
                        (unbound-os-environment-variable-exception-arguments exc))
                  'not-unbound-os-environment-variable-exception))
          > (with-exception-catcher
              handler
              (lambda () (getenv "DOES_NOT_EXIST")))
          (#<procedure #2 getenv> ("DOES_NOT_EXIST"))


