ikarus/doc/ikarus-scheme-users-guide.tex

%!TEX TS-program = xelatex

\documentclass[onecolumn, 12pt, twoside, openright, dvipdfm]{book}

\usepackage{fontspec}
\usepackage{hanging}
\usepackage{xltxtra}

\defaultfontfeatures{Scale=MatchLowercase} 
%\setmainfont[Mapping=tex-text]{Cochin} 
%\setmainfont[Mapping=tex-text]{Palatino}
%\setmainfont[Mapping=tex-text]{Baskerville}
%\setmainfont[Mapping=tex-text]{Perpetua}
%\setmainfont[Mapping=tex-text]{Lido STF}
%\setmainfont[Mapping=tex-text]{Perpetua}
\setmainfont[Mapping=tex-text]{Charis SIL}
%\setmainfont[Mapping=tex-text]{Gentium}
%\setmainfont[Mapping=tex-text]{DejaVu Serif}
%\setmainfont[Mapping=tex-text]{Palatino}
%\setmainfont[Mapping=tex-text]{URWPalladioL}
%\setmainfont[Mapping=tex-text]{GentiumAlt}
\setsansfont[Mapping=tex-text]{Geneva}
%\setmonofont{DejaVu Sans Mono}
%\setmonofont{Monaco}
\setmonofont[Scale=0.95]{Inconsolata}

\usepackage{fancyhdr}
\usepackage{makeidx}
\usepackage{fancyvrb}
\makeindex

\usepackage[dvipdfm,CJKbookmarks,bookmarks=true,bookmarksopen=true]{hyperref}
\hypersetup{
    pdftitle={Ikarus Scheme User's Guide},
    pdfauthor={Abdulaziz Ghuloum},
    pdfkeywords={Scheme, R6RS, Compiler, Ikarus},
    bookmarksnumbered=true,
    pagebackref=true,
    breaklinks=true,
%    pdfview=FitH,       % Or try pdfstartview={FitV}, This lead to uncorrect bookmarks
    urlcolor=blue,
    colorlinks=true,
    citecolor=blue,          %citeref's color
    linkcolor=blue,
}

\usepackage{rotating}
\usepackage{multicol,ragged2e}


\renewcommand{\sectionmark}[1]{\markright{\thesection\ #1}}
\fancyhf{} 
\fancyhead[LE,RO]{\bfseries\thepage}
\fancyhead[LO]{\bfseries\rightmark}
\fancyhead[RE]{\bfseries\leftmark}
\renewcommand{\headrulewidth}{0pt} 
\renewcommand{\footrulewidth}{0pt} 
\renewcommand{\headheight}{15pt} 

\newcommand{\coderefpage}[1]{figure~\ref{#1}, p.~\pageref{#1}}
\newcommand{\figrefpage}[1]{figure~\ref{#1}, p.~\pageref{#1}}
\newcommand{\deflabelref}[2]{\texttt{#1}~(page~\pageref{#2})}
\newcommand{\defref}[1]{\deflabelref{#1}{#1}}

\newcommand{\coderef}[1]{figure~\ref{#1}}
\newcommand{\figref}[1]{figure~\ref{#1}}

\newcommand{\secref}[1]{section~\ref{#1}}
\newcommand{\rnrs}[1]{R$^{\mathrm{#1}}$RS}

\newcommand{\BoxedText}[2]{
  \vspace{.05in}
  \begin{center}
    \begin{tabular}{|p{4.6in}|} {\large \emph{#1}} #2 \end{tabular}
  \end{center}
  \vspace{.05in}
}

\newcommand{\testfile}[2]{\texttt{tests-{\ref{#1}}-{#2}.ss}}

\newcommand{\idxtt}[1]{\index{#1 @ \texttt{#1}}\texttt{#1}}

\newenvironment{Language}
{
  \begin{center}
    \begin{tabular}{|p{4.5in}|} {\large \emph{Input Language:}}
      \begin{center}
        \begin{tabular}{@{}r@{ }c@{ }l@{}}
}{
        \end{tabular}
      \end{center}
    \end{tabular}
  \end{center}
}


\DefineVerbatimEnvironment{CodeInline}{Verbatim}
  {gobble=0,  xleftmargin=2em, xrightmargin=0em,
   %numbers=left, numbersep=2mm,
   frame=lines ,framerule=1pt} 


    
\DefineVerbatimEnvironment{CodeInlineIdx}{Verbatim}
  {gobble=0,  xleftmargin=3em, xrightmargin=0em,
   numbers=left, numbersep=1ex,
   frame=lines ,framerule=1pt} 

\newcommand{\idxlabeldefun}[5]{
\vspace{1ex}
\rule{\textwidth}{2pt}
{\phantomsection\index{#1@\texttt{#2}}\label{#3}{\Large\texttt{#4}}\hfill\textbf{#5}}\\}


\newcommand{\idxdefun}[3]{\idxlabeldefun{#1}{#2}{#1}{#2}{#3}}


\newcommand{\defun}[2]{\idxdefun{#1}{#1}{#2}}

\begin{document}
\frontmatter

\VerbatimFootnotes

\title{Ikarus Scheme User's Guide}

\author{Abdulaziz Ghuloum}

\pagestyle{empty}

\mbox{}
\vspace{3in}

\newcommand{\fstpagefont}[0]
{\fontspec{Charis SIL}}

{ \fontsize{66}{66} \fstpagefont{}
  \noindent Ikarus Scheme\\ User's Guide\\ }
  \noindent \rule{\textwidth}{6pt}
{\fontsize{18}{18} \fstpagefont{}
   \mbox{} \hfill Version~0.0.4 }
\vfill
{ \fontsize{24}{24} \fstpagefont{}
  \hfill{} Abdulaziz Ghuloum}

{ \fontsize{18}{18} \fstpagefont{}
  \hfill{} \today \\}

\newpage
\mbox{}
\vfill{}
%\addcontentsline{toc}{section}{Copyrights}
\noindent
Ikarus Scheme User's Guide \hfill{} (Version 0.0.4)\\
Copyright \copyright{} 2007,2008  Abdulaziz Ghuloum\\

{\small
\noindent
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3 as
published by the Free Software Foundation.
\\ \\
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.
\\ \\
You should have received a copy of the GNU General Public License
along with this program.  If not, see
\url{http://www.gnu.org/licenses/}.
}





% Permission is granted to copy, distribute and/or modify this
% document under the terms of the GNU Free Documentation License,
% Version 1.2 published by the Free Software
% Foundation; with no Invariant Sections, the Front-Cover Texts
% being \emph{``Ikarus Scheme User's Guide''}, and
% no Back-Cover Texts.  A copy of the license is included in the
% section entitled ``GNU Free Documentation License''.

\newpage

\pagestyle{fancy}
\phantomsection
\addcontentsline{toc}{section}{Contents}
\tableofcontents

\newpage

\mainmatter
\setlength{\parindent}{0pt} 
\setlength{\parskip}{2.0ex plus 0ex minus 0ex}
\chapter{Getting Started}
\section{Introduction}

Ikarus Scheme is an implementation of the Scheme programming
language.  The preliminary release of Ikarus implements the majority
of the features found in the current standard, the
Revised$^\mathrm{6}$ report on the algorithmic language
Scheme\cite{r6rs} including full \rnrs{6} library and script syntax,
syntax-case, unicode strings, bytevectors, user-defined record
types, exception handling, conditions, and enumerations.
User-define \rnrs{6} libraries can be compiled in-memory on the fly
or compiled to disk and loaded in subsequent runs.

In addition to supporting \rnrs{6} (and most of the features found
in the the previous \rnrs{n} standards), Ikarus supports powerful
interprocess communication facilities including support for
communication with child processes via pipes and with remote
processes via TCP and UDP sockets.  The facility also allows for
both synchronous and asynchronous communication so that a Scheme
program running in Ikarus can communicate with many processes
concurrently.

Ikarus also supports basic foreign function interface (FFI)
facilities.  This allows the programmer to define accessors and
mutators for native data structures.  It also allows for Scheme
programs to dynamically load any library found on the host machine.
Native procedures and Scheme procedures can call to each other by
the call-out and call-back facilities of Ikarus.

%The main purpose behind releasing Ikarus early is to give Scheme
%programmers the opportunity to experiment with the various new
%features that were newly introduced in \rnrs{6}.  The most important
%of such features is the ability to structure large programs into
%libraries; where each library extends the language through
%procedural and syntactic abstractions.  Many useful libraries can be
%written using the currently supported set of \rnrs{6} features
%including text processing tools, symbolic logic systems,
%interpreters and compilers, and many mathematical and scientific
%packages.  It is my hope that this release will encourage the
%Scheme community to write and to share their most useful \rnrs{6}
%libraries.


\newpage

\section{Technology overview}

Ikarus Scheme provides the programmer with many advantages:

\textbf{Optimizing code generator:}  The compiler's backend employs
state of the art technologies in code generation that produce fast
efficient machine code.  When developing computationally intensive
programs, one is not constrained by using a slow interpreter.

\textbf{Fast incremental compilation:}  Every library and script is
quickly compiled to native machine code.  When developing large
software, one is not constrained by how slow the batch compiler
runs.

\textbf{Robust and fine-tuned standard libraries:}  The standard
libraries are written such that they perform as much error checking
as required to provide a safe and fast runtime environment. 

\textbf{Multi-generational garbage collector:} The
BiBOP\cite{dybvig:sm} based garbage collector used in Ikarus allows
the runtime system to expand its memory footprint as needed.  The
entire 32-bit virtual address space could be used and unneeded
memory is released back to the operating system.

\textbf{32-bit and 64-bit computing:} Ikarus supports both the
Intel-x86 and the AMD-64 architectures.  64-bit computing allows the
programmer to utilize larger address space (larger than 4GB) and
provides a greater range for fixnums (61-bit fixnums).  Running in
32-bit mode, however, makes more efficient utilization of resources
due to the smaller memory footprint for most data structures.\\
(64-bit support is experimental at this stage of development.)

\textbf{Supports many operating systems:} Ikarus runs on the most
popular and widely used operating systems for servers and personal
computers.  The supported systems include Mac~OS~X,
GNU/Linux, FreeBSD, NetBSD, and Microsoft Windows.


\section{System requirements}

This section provides an overview of the hardware and software
requirements needed for running Ikarus.

\subsection{Hardware}

Ikarus Scheme runs in 32-bit mode on the IA-32 (\emph{x86})
architecture supporting SSE2 extensions.  It also runs in 64-bit
mode on platforms supporing the AMD-64 architecture.  This includes
the Athlon 64, Sempron 64, and Turion 64 processors from AMD and the
Pentium 4, Xeon, Celeron, Pentium M, Core, and Core2 processors from
Intel.  Ikarus does not run on Intel Pentium III or earlier
processors.

The Ikarus compiler generates SSE2 instructions to handle Scheme's
IEEE floating point representation (\emph{flonums}) for inexact
numbers. 

\subsection{Operating systems}

Ikarus is tested under the following operating systems:

\begin{itemize}
\item Mac OS X version 10.4 and 10.5.
\item Linux 2.6.18 (Debian, Fedora, Gentoo, and Ubuntu).
\item FreeBSD version 6.2.
\item NetBSD version 3.1.
\item Microsoft Windows XP (using Cygwin 1.5.24).
\end{itemize}

\subsection{Additional software}

\begin{itemize}
\item\textbf{GMP:} Ikarus uses the GNU Multiple Precision Arithmetic
Library (GMP) for some bignum arithmetic operations.  To build
Ikarus from scratch, GMP version 4.2 or better must be installed
along with the required header files.  Pre-built GMP packages  are
available for most operating systems.  Alternatively, GMP can be
downloaded from \\
\url{http://gmplib.org/}.


\item\textbf{FFI:} 
 The \texttt{libffi} library (version \texttt{3.0.6}) can be utilized 
to enable Scheme procedures to call and be called from native
procedure (see Chapter~\ref{chapter:foreign} for details).  
To enable
\texttt{libffi} while building Ikarus, one must pass
\texttt{--enable-libffi} to the \texttt{configure} script along with
the paths to \texttt{libffi}'s include and lib directory.
The \texttt{libffi} library can be obtained from
\url{http://sourceware.org/libffi/}.
FFI support is optional.  It is not required if all one needs is
writing pure Scheme code.




\item\textbf{GCC:} The GNU C Compiler is required to build the Ikarus
executable (e.g. the garbage collector, loader, and OS-related
runtime).  GCC versions 4.1 and 4.2 were successfully used to build
Ikarus.

\item\textbf{Autoconf and Automake:} The GNU Autoconf (version 2.61)
and GNU Automake (version 1.10) tools are required if one
wishes to modify the Ikarus source base.  They are not
required to build the official release of Ikarus.

\item\textbf{\XeLaTeX{}:}  The \XeLaTeX\ typesetting system is
required for building the documentation.  \XeLaTeX\ (and \XeTeX) is
an implementation of the \LaTeX\ (and \TeX) typesetting system.
\XeLaTeX\ can be obtained from \url{http://scripts.sil.org/xetex}
and is included with \TeX-Live\footnote{
\url{http://tug.org/texlive/}} and and
Mac-\TeX\footnote{\url{http://tug.org/mactex/}} distributions.


\end{itemize}

\section{Installation}

If you are familiar with installing Unix software on your system,
then all you need to know is that Ikarus uses the standard
installation method found in most other Unix software.  Simply run
the following commands from the shell:
\begin{verbatim}
  $ tar -zxf ikarus-n.n.n.tar.gz
  $ cd ikarus-n.n.n
  $ ./configure [--prefix=path] [CFLAGS=-I/dir] [LDFLAGS=-L/dir]
  $ make
  $ make install
  $
\end{verbatim}

The rest of this section describes the build process in more
details.  It is targeted to users who are unfamiliar with steps
mentioned above.

\subsection{Installation details}

\begin{enumerate}

\item Download the Ikarus source distribution.  The source is
distributed as a \texttt{gzip}-compressed \texttt{tar} file
(\texttt{ikarus-n.n.n.tar.gz} where \texttt{n.n.n} is a 3-digit
number indicating the current revision).  The latest revision can be
downloaded from the following URL:\\
\url{http://www.cs.indiana.edu/~aghuloum/ikarus/}

\item Unpack the source distribution package.  From your shell
command, type:
\begin{verbatim}
  $ tar -zxf ikarus-n.n.n.tar.gz
  $
\end{verbatim}
This creates the base directory \texttt{ikarus-n.n.n}.

\item Configure the build system by running the \texttt{configure}
script located in the base directory.  To do this, type the
following commands:
\begin{verbatim}
  $ cd ikarus-n.n.n
  $ ./configure
  checking build system type... i386-apple-darwin8.10.1
  checking host system type... i386-apple-darwin8.10.1
  ...
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: creating src/Makefile
  config.status: creating scheme/Makefile
  config.status: creating doc/Makefile
  config.status: executing depfiles commands
  $
\end{verbatim}

This configures the system to be built then installed in the
system-wide location (binaries are installed in
\texttt{/usr/local/bin}) .  If you wish to install it
in another location (e.g. in your home directory), you can supply
a \texttt{--prefix} location to the \texttt{configure} script as
follows:

\begin{verbatim}
  $ ./configure --prefix=/path/to/installation/location
\end{verbatim}

The \texttt{configure} script will fail if it cannot locate the
location where GMP is installed.  If running \texttt{configure}
fails to locate GMP, you should supply the location in which the GMP
header file, \texttt{gmp.h}, and the GMP library file,
\texttt{libgmp.so}, are installed.  This is done by supplying the
two paths in the \texttt{CFLAGS} and \texttt{LDFLAGS} arguments:

\begin{verbatim}
  $ ./configure CFLAGS=-I/path/to/include LDFLAGS=-L/path/to/lib
\end{verbatim}


If you wish to enable support for accessing and calling to/from
foreign libraries, you need to configure Ikarus with the
\texttt{--enable-libffi} option and supply the approriate
\texttt{CFLAGS} and \texttt{LDFLAGS} as needed.

\begin{verbatim}
  $ ./configure --enable-libffi \
       [CFLAGS=/path/to/ffi.h] \
       [LDFLAGS=/path/to/libffi.so|.dylib|.dll]
\end{verbatim}



\item Build the system by running:
\begin{verbatim}
  $ make
\end{verbatim}
This performs two
tasks.  First, it builds the \texttt{ikarus} executable from the C
files located in the \texttt{src} directory.  It then uses the
\texttt{ikarus} executable and the pre-built
\texttt{ikarus.boot.orig} boot file to rebuild the Scheme boot image
file \texttt{ikarus.boot} from the Scheme sources located in the
\texttt{scheme} directory.

\item Install Ikarus by typing:
\begin{verbatim}
  $ make install
\end{verbatim}
If you are installing Ikarus in a system-wide location, you might
need to have administrator privileges (use the \texttt{sudo} or
\texttt{su} commands).

\item Test that Ikarus runs from the command line.
\begin{verbatim}
  $ ikarus
  Ikarus Scheme version 0.0.4
  Copyright (c) 2006-2008 Abdulaziz Ghuloum

  > 
\end{verbatim}
If you get the prompt, then Ikarus was successfully installed on
your system.  You may need to update the \texttt{PATH} variable in
your environment to contain the directory in which the
\texttt{ikarus} executable was installed.

Do not delete the \texttt{ikarus-n.n.n} directory from which you
configured, built, and installed Ikarus.  It will be needed if you
decide at a later time to uninstall Ikarus.

\end{enumerate}

\subsection{Uninstalling Ikarus}

To uninstall Ikarus, use the following steps:

\begin{verbatim}
  $ cd path/to/ikarus-n.n.n
  $ make uninstall
  $
\end{verbatim}


\section{\index{Command-line switches}Command-line switches}

The \texttt{ikarus} executable recognizes a few command-line
switches that influence how Ikarus starts.

\begin{itemize}

\item \texttt{ikarus -h}

The presence of the \texttt{-h} flag causes \texttt{ikarus} to
display a help message then exits.  The help message summarizes the
command-line switches.  No further action is performed.

\item \texttt{ikarus -b path/to/boot/file.boot}

The \texttt{-b} flag (which requires an extra argument) directs
\texttt{ikarus} to use the specified boot file as the initial system
boot file.  \index{Boot files} The boot file is a binary file that
contains all the code and data of the Scheme system.  In the absence
of \texttt{-b} flag, the executable will use the default boot file.
Running \texttt{ikarus~-h} shows the location where the default boot
file was installed.

The rest of the command-line arguments are recognized by the
standard Scheme run time system.   They are processed after the
boot file is loaded.

\item \texttt{ikarus files ... --r6rs-script script-file arguments ...}

\index{R6RS Script@\rnrs{6} Script} The \texttt{--r6rs-script}
argument instructs Ikarus that the supplied file is an \rnrs{6}
script.  The optional list of \texttt{files} must be paths to files,
each containing a set of libraries that Ikarus must load,
sequentially, before running the \rnrs{6} script
\texttt{script-file}.  See Section~\ref{sec:scripts} for a short
introduction to writing \rnrs{6} scripts.  The script file name and
any additional optional \texttt{arguments} can be obtained by
calling the \idxtt{command-line} procedure.

\begin{verbatim}
  $ cat test.ss 
  (import (rnrs))
  (write (command-line))
  (newline)

  $ ikarus --r6rs-script test.ss hi there
  ("test.ss" "hi" "there")
  $
\end{verbatim}

\item \texttt{ikarus files ... [-- arguments ...]}

The lack of an \texttt{--r6rs-script} argument causes Ikarus to
start in interactive mode.  Each of the \texttt{files} is first
loaded, in the interaction environment.  The interaction environment
initially contains all the bindings exported from the
\texttt{(ikarus)} library (see Chapter~\ref{chapter:ikarus}).  The
optional \texttt{arguments} following the \texttt{--} marker can be
obtained by calling the \texttt{command-line} procedure.  In
interactive mode, the first element of the returned list will be the
string \texttt{"*interactive*"}, corresponding to the script name in
\rnrs{6}-script mode.


\BoxedText{Note:}{The interactive mode is intended for quickly
experimenting with the built-in features.  It is intended neither
for developing applications nor for writing any substantial pieces
of code.}

\end{itemize}

\section{Using \texttt{scheme-script}}

Scheme scripts can be executed using the
\texttt{ikarus~--r6rs-script~\textit{script-name}} command as
described in the previous section.  For convenience, Ikarus
follows the \rnrs{6} recommendations and installs a wrapper program
called \texttt{scheme-script}.  Typically, a script you write would
start with a \texttt{\#!}\ line that directs your operating system
to the interpreter used to evaluate the script file.  The following
example shows a very simple script that uses the
\texttt{scheme-script} command.

\begin{CodeInline}
#!/usr/bin/env scheme-script

(import (rnrs))
(display "Hello World\n")
\end{CodeInline}

If the above script was placed in a file called
\texttt{hello-world}, then one can make it executable using the
\texttt{chmod} Unix command.

\begin{verbatim}
   $ cat hello-world
   #!/usr/bin/env scheme-script
   
   (import (rnrs))
   (display "Hello World\n")
   
   $ chmod 755 hello-world
   $ ./hello-world
   Hello World
   $
\end{verbatim}

\BoxedText{Under Mac OS X,}{if a script name ends with the
\texttt{.command} extension, then it can be executed from the Finder
by double-clicking on it.  This brings up a terminal window in which
the script is executed.  The \texttt{.command} extension can be
hidden from the \emph{Get Info} item from the Finder's File menu.}


\section{Mapping library names to file names}

The name of an \rnrs{6} library consists of a non-empty list of
identifiers (symbols), followed by an optional version number.  All
of the standard \rnrs{6} libraries are built into Ikarus, thus
importing any one of them does not require any special action other
than listing the library name in the \texttt{import} part of a
library or a script.  The same holds for the \texttt{(ikarus)}
library (chapter~\ref{chapter:ikarus},
page~\pageref{chapter:ikarus}).

When importing a user library, Ikarus uses a simple mechanism
to map library names to file names.  A library name is converted to
a file path by joining the library identifiers with a path
separator, e.g. \verb|"/"|.

\begin{center}
\begin{tabular}{lcl}
  Library Name & \hspace{2em}$\Rightarrow$\hspace{2em} & File name \\
  \hline
  \verb|(foo)|         & $\Rightarrow$ & \verb|foo| \\
  \verb|(foo bar)|     & $\Rightarrow$ & \verb|foo/bar| \\
  \verb|(foo bar baz)| & $\Rightarrow$ & \verb|foo/bar/baz| 
\end{tabular}
\end{center}


Having mapped a library name to a file path, Ikarus attempts to
locate that file in one of several locations.  The locations
attempted depend on two settings: the search path and the file
extension set (e.g., \verb|.sls|, \verb|.ss|, \verb|.scm|, etc.).
First, Ikarus attempts to locate the file in the current working
directory from which Ikarus was invoked.  In the current working
directory, Ikarus enumerates all file extensions first before
searching other locations.  If the file is not found in the current
directory, Ikarus tries to find it in the Ikarus library directory.
The Ikarus library directory is determined when Ikarus is installed
(based on the \texttt{--prefix} argument that was passed to the
\texttt{configure} script).  If Ikarus failes to locate the library
file, it raises an exception and exits. 
%See
%Chapter~\ref{chapter:contributed} for more details about the library
%locations.


\BoxedText{Tip:}{Use simple library names for the libraries that
you define.  Library names that contain non-printable characters,
complex punctuations, or unicode may pose a challenge for some
operating systems.  If Ikarus cannot find a library, it will raise
an error listing the locations in which it looked, helping you move
the library file to a place where Ikarus can find it.}

\section{Writing cross-implementation libraries}

When searching for a library, Ikarus appends an extension (e.g.,
\verb|.ss|) to the appropriate file name (e.g., \verb|foo/bar|).
The initial set of file extensions are: \\
\verb|/main.ikarus.sls|,
\verb|/main.ikarus.ss|, \verb|/main.ikarus.scm|,
\verb|/main.sls|, \verb|/main.ss|, \verb|/main.scm|,
\verb|.ikarus.sls|,
\verb|.ikarus.ss|, \verb|.ikarus.scm|,
\verb|.sls|, \verb|.ss|, and \verb|.scm|.

The list of file extensions are searched sequentially.  As a
consequence, files ending with the \verb|.ikarus.*| extensions are
given precedence over files that have generic Scheme extensions.
The rationale for this behavior is to facilitate writing
cross-implementation libraries: ones that take advantage of
implementation-specific features, while at the same time 
provide a fail-safe alternative for other \rnrs{6}
implementations.

Consider for example a program which would like to use the
\verb|pretty-print| procedure to format some code, and suppose
further that pretty printing is just a nice add-on (e.g., using
\verb|write| suffices, but pretty-printing is \emph{just prettier})
Ikarus exports a good pretty-printing facility in its
\verb|(ikarus)| library.  However, since \verb|pretty-print| is not
a standard procedure, a program that uses it would be rendered
unportable to other \rnrs{6} Scheme implementations.  

The programmer can put the \verb|.ikarus.*| extensions to use in
this situation.  First, the programmer writes two versions of a
\verb|(pretty-printing)| library: one for use by Ikarus, and one
portable for other implementations.

\begin{CodeInline}
(library (pretty-printing) ;;; this is pretty-printing.ikarus.ss
  (export pretty-print)    ;;; can only be used by Ikarus
  (import (only (ikarus) pretty-print)))
\end{CodeInline}

\begin{CodeInline}
(library (pretty-printing) ;;; this is pretty-printing.sls
  (export pretty-print)    ;;; *portable* though not very pretty.
  (import (rnrs))          ;;; for any other implementation
  (define (pretty-print x port)
    (write x port)
    (newline port)))
\end{CodeInline}

The \verb|/main.*| extensions serve a different purpose.  Often
times, a set of libraries are distributed together as a package and
it is convenient for the programmer to group related files in
directories.  If a package contains the libraries \verb|(foo)|,
\verb|(foo core)|, and \verb|(foo compat)|, then putting all such
library files together in one directory makes it easier to
package, install, and remove these libraries en masse.  The layout
of the package would look like:

\DefineVerbatimEnvironment{Code}{Verbatim} 
 {%baselinestretch=1.1,
  %frame=single,
  %framerule=0.5pt,
  commandchars=\\\{\}}

\begin{Code}
  foo/README              :              {\textrm{ignored by Ikarus}}
  foo/COPYING             :
  foo/main.ss             : (foo)        {\textrm{implementation independent}}
  foo/core.ss             : (foo core) 
  foo/compat.ss           : (foo compat) {\textrm{default \rnrs{6} library}}
  foo/compat.ikarus.ss    :              {\textrm{specific for Ikarus}}
  foo/compat.mzscheme.ss  :              {\textrm{specific for MzScheme}}
\end{Code}


By default, running the \texttt{configure} script
installs a set of contributed libraries into the
\verb|/usr/local/lib/ikarus| directory.  If a \verb|--prefix DIR|
argument was supplied to \texttt{configure}, then the libraries are
installed in the \verb|DIR/ikarus/lib| directory.  

You may install additional libraries into the Ikarus library
directory.  Doing so makes them available for \texttt{import} into
other libraries and script regardless of where the importing code is
located or the current directory in which it is executed.  

\section{Defining \texttt{IKARUS\_LIBRARY\_PATH}}
\index{ikarus library path@\texttt{IKARUS\_LIBRARY\_PATH}}

There may be situations in which you may wish to install your own
libraries into a different location.  For example, you may not have
sufficient administrative privileges to write to the system
directory, or you may wish to keep your own libraries separate from
the standard libraries.  Whatever the reason is, your can store your
library files in any location you want and set up the
\verb|IKARUS_LIBRARY_PATH| environment variable to point to these
locations.  The value of \verb|IKARUS_LIBRARY_PATH| is a
colon-separated list of directories in which Ikarus will search.

For example, suppose your script imports the
\texttt{(streams~derived)} library.  First, Ikarus will map the
library name to the file path \verb|streams/derived.ss|.  Suppose
that Ikarus was installed using the \verb|--prefix /usr/local|
configuration option, and suppose further that the value of
\verb|IKARUS_LIBRARY_PATH| is set by the user to be 
\verb|/home/john/ikarus-libraries:/home/john/srfis|.  Ikarus will
search in the following locations in sequence until it finds the
file it is looking for.

\begin{verbatim}
   ./streams/derived.ss
   /home/john/ikarus-libraries/streams/derived.ss
   /home/john/srfis/streams/derived.ss
   /usr/local/lib/ikarus/streams/derived.ss
\end{verbatim}


The method in which the value of \verb|IKARUS_LIBRARY_PATH| is
defined is typically shell dependant.  If you use GNU Bash, you
typically set the values of environment variables in the
\verb|~/.bash_profile| or \verb|~/.bashrc| file by adding the
following lines:

\begin{verbatim}
   IKARUS_LIBRARY_PATH=/path/to/some/directory:/and/another
   export IKARUS_LIBRARY_PATH
\end{verbatim}


\chapter{\rnrs{6} Crash Course}

The major difference between \rnrs{5} and \rnrs{6} is the way
in which programs are loaded and evaluated.  

In \rnrs{5}, Scheme implementations typically start as an
interactive session (often referred to as the REPL, or
read-eval-print-loop).  Inside the interactive session, the user
enters definitions and expressions one at a time using the keyboard.
Files, which also contain definitions and expressions, can be loaded
and reloaded by calling the \texttt{load} procedure.  The
environment in which the interactive session starts often contains
implementation-specific bindings that are not found \rnrs{5} and
users may redefine any of the initial bindings.  The semantics of 
loading a file depends on the state of the environment at the time
the file contents are evaluated.

\index{R6RS Script@\rnrs{6} Script!Import} 
%
\rnrs{6} differs from \rnrs{5} in that it specifies how \emph{whole
programs}, or scripts, are compiled and evaluated.  An \rnrs{6}
script is closed in the sense that all the identifiers found in the
body of the script must either be defined in the script or imported
from a library.  \rnrs{6} also specifies how \emph{libraries} can be
defined and used.  While files in \rnrs{5} are typically
\emph{loaded} imperatively into the top-level environments, \rnrs{6}
libraries are \emph{imported} declaratively in scripts and in other
\rnrs{6} libraries. 

\section{\label{sec:scripts}Writing a simple script}

An \rnrs{6} script is a set of definitions and expressions preceded
by an \texttt{import} form.  The \texttt{import} form specifies
the language (i.e. the variable and keyword bindings) in which the
library body is written.  A very simple example of an \rnrs{6}
script is listed below.

\index{Examples!Hello World}
\begin{CodeInline}
#!/usr/bin/env scheme-script
(import (rnrs))
(display "Hello World!\n")
\end{CodeInline}

The first line imports the \texttt{(rnrs)} library.  All the
bindings exported from the \texttt{(rnrs)} library are made
available to be used within the body of the script.  
The exports of the \texttt{(rnrs)} library include variables
(e.g. \texttt{cons}, \texttt{car}, \texttt{display}, etc.) and
keywords (e.g.  \texttt{define}, \texttt{lambda}, \texttt{quote},
etc.).  The second line displays the string \texttt{Hello World!}
followed by a new line character.

In addition to expressions, such as the call to \texttt{display} in
the previous example, a script may define some variables.  The
script below defines the variable \texttt{greeting} and calls the
procedure bound to it.

\begin{CodeInline}
#!/usr/bin/env scheme-script
(import (rnrs))

(define greeting
  (lambda ()
    (display "Hello World!\n")))

(greeting)
\end{CodeInline}

Additional keywords may be defined within a script.  In the example
below, we define the \texttt{(do-times n exprs ...)} macro that
evaluates the expressions \texttt{exprs} \texttt{n} times.  Running
the script displays \texttt{Hello World} 3 times.
\newpage

\begin{CodeInline}
#!/usr/bin/env scheme-script
(import (rnrs))

(define greeting
  (lambda ()
    (display "Hello World!\n")))

(define-syntax do-times
  (syntax-rules ()
    [(_ n exprs ...)
     (let f ([i n])
       (unless (zero? i)
         exprs ...
         (f (- i 1))))]))

(do-times 3 (greeting))
\end{CodeInline}


\section{Writing simple libraries}

A script is intended to be a small piece of the program---useful
abstractions belong to libraries.  The \texttt{do-times} macro that
was defined in the previous section may be useful in places other
than printing greeting messages.  So, we can create a small library,
\texttt{(iterations)} that contains common iteration forms.  

An \rnrs{6} library form is made of four essential parts: (1) the
library name, (2) the set of identifiers that the library exports,
(3) the set of libraries that the library imports, and (4) the body
of the library.  


The library name can be any non-empty list of identifiers.
\rnrs{6}-defined libraries includes \texttt{(rnrs)},
\texttt{(rnrs~unicode)}, \texttt{(rnrs~bytevectors)}, and so on.

The library exports are a set of identifiers that are made available
to importing libraries.  Every exported identifier must be bound: it
may either be defined in the library or imported using the
\texttt{import} form.  Library exports include variables, keywords,
record names, and condition names.

Library imports are similar to script imports: they specify the set
of libraries whose exports are made visible within the body of the
library.  

\index{Invoke}
The body of a library contains definitions (variable, keyword,
record, condition, etc.) followed by an optional set of expressions.
The expressions are evaluated for side effect when needed.


The \texttt{(iteration)} library may be written as follows:

\begin{CodeInline}
(library (iteration)
  (export do-times)
  (import (rnrs))

  (define-syntax do-times
    (syntax-rules ()
      [(_ n exprs ...)
       (let f ([i n])
         (unless (zero? i)
           exprs ...
           (f (- i 1))))])))
\end{CodeInline}

To use the \texttt{(iteration)} library in our script, we add the
name of the library to the script's \texttt{import} form.  This
makes all of \texttt{(iteration)}'s exported identifiers, e.g.
\texttt{do-times},  visible in the body of the script.

\begin{CodeInline}
#!/usr/bin/env scheme-script
(import (rnrs) (iteration))

(define greeting
  (lambda ()
    (display "Hello World!\n")))

(do-times 3 (greeting))
\end{CodeInline}

\section{\rnrs{6} record types}

\rnrs{6} provides ways for users to define new types, called record
types.  A record is a fixed-size data structure with a unique type
(called a record type).  A record may have any finite number of
fields that hold arbitrary values.  This section briefly describes
what we expect to be the most commonly used features of the record
system.  Full details are in the \rnrs{6} Standard Libraries
document\cite{r6rs:lib}.

\subsection{Defining new record types}

To define a new record type,  use the \texttt{define-record-type}
form.  For example, suppose we want to define a new record type for
describing points, where a point is a data structure that has two
fields to hold the point's $x$ and $y$ coordinates.  The following
definition achieves just that:

\begin{CodeInline}
(define-record-type point
  (fields x y))
\end{CodeInline}

The above use of \texttt{define-record-type} defines the following
procedures automatically for you:
\begin{itemize}
\item The constructor \texttt{make-point} that takes two arguments,
\texttt{x} and \texttt{y} and returns a new record whose type is
point.
\item The predicate \texttt{point?}\ that takes an arbitrary value
and returns \texttt{\#t} if that value is a point, \texttt{\#f}
otherwise. 
\item The accessors \texttt{point-x} and \texttt{point-y} that,
given a record of type point, return the value stored in the
\texttt{x} and \texttt{y} fields.
\end{itemize}

Both the \texttt{x} and \texttt{y} fields of the \texttt{point}
record type are \emph{immutable}, meaning that once a record is
created with specific \texttt{x} and \texttt{y} values, they cannot
be changed later.  If you want the fields to be \emph{mutable}, then
you need to specify that explicitly as in the following example.
\newpage

\begin{CodeInline}
(define-record-type point
  (fields (mutable x) (mutable y)))
\end{CodeInline}

This definition gives us, in addition to the constructor, predicate,
and accessors, two additional procedures:
\begin{itemize}
\item The mutators \texttt{point-x-set!} and \texttt{point-y-set!} that,
given a record of type point, and a new value, sets the value stored in the
\texttt{x} field or \texttt{y} field to the new value.
\end{itemize}


\BoxedText{Note:}{Records in Ikarus have a printable representation
in order to enable debugging programs that use records.  Records are
printed in the \texttt{\#[type-name field-values ...]} notation.
For example, \texttt{(write (make-point 1 2))} produces 
\texttt{\#[point 1 2]}.}

\subsection{Extending existing record types}

A record type may be extended by defining new variants of a record
with additional fields.  In our running example, suppose we want
to define a \texttt{colored-point} record type that, in addition to
being a \texttt{point}, it has an additional field: a \emph{color}.
A simple way of achieving that is by using the following record 
definition:

\begin{CodeInline}
(define-record-type cpoint
  (parent point)
  (fields color))
\end{CodeInline}

Here, the definition of \texttt{cpoint} gives us:
\begin{itemize}
\item A constructor \texttt{make-cpoint} that takes three arguments
(\texttt{x}, \texttt{y}, and \texttt{color} in that order) and returns a
\texttt{cpoint} record.
\item A predicate \texttt{cpoint?}\ that takes a single argument and
determines whether the argument is a \texttt{cpoint} record.
\item An accessor \texttt{cpoint-color} that returns the value of
the \texttt{color} field of a \texttt{cpoint} object.
\end{itemize}

All procedures that are applicable to records of type
\texttt{point} (\texttt{point?}, \texttt{point-x},
\texttt{point-y}) are also applicable to records of type
\texttt{cpoint} since a \texttt{cpoint} is also a \texttt{point}.

\subsection{Specifying custom constructors}

The record type definitions explained so far use the default
constructor that takes as many arguments as there are fields and
returns a new record type with the values of the fields initialized
to the arguments' values.  It is sometimes necessary or convenient
to provide a constructor that performs more than the default
constructor.  For example, we can modify the definition of our
\texttt{point} record so that the constructor takes either
no arguments, in which case it would return a point located at the
origin, or two arguments specifying the $x$ and $y$ coordinates.  We
use the \texttt{protocol} keyword for specifying such constructor as
in the following example:

\begin{CodeInline}
(define-record-type point
  (fields x y)
  (protocol
    (lambda (new)
      (case-lambda
        [(x y) (new x y)]
        [()    (new 0 0)]))))
\end{CodeInline}

The protocol here is a procedure that takes a constructor procedure
\texttt{new} (\texttt{new} takes as many arguments as there are
fields.) and returns the desired custom constructor that we want
(The actual constructor will be the value of the
\texttt{case-lambda} expression in the example above).
Now the constructor \texttt{make-point} would either take two
arguments which constructs a \texttt{point} record as before, or no
arguments, in which case \texttt{(new 0 0)} is called to construct a
point at the origin. 

Another reason why one might want to use custom constructors is to
precompute the initial values of some fields based on the values of
other fields.  An example of this case is adding a \texttt{distance}
field to the record type which is computed as
$d = \sqrt{x^2+y^2}$.  The protocol in this case may be defined as:

\begin{CodeInline}
(define-record-type point
  (fields x y distance)
  (protocol
    (lambda (new)
      (lambda (x y)
        (new x y (sqrt (+ (expt x 2) (expt y 2))))))))
\end{CodeInline}

Note that derived record types need not be modified when additional
fields are added to the parent record type.  For example, our
\texttt{cpoint} record type still works unmodified even after we
added the new \texttt{distance} field to the parent.  
Calling \texttt{(point-distance (make-cpoint 3 4 \#xFF0000))}
returns \texttt{5.0} as expected.

\subsection{Custom constructors for derived record types}

Just like how base record types (e.g. \texttt{point} in the running
example) may have a custom constructor, derived record types can
also have custom constructors that do other actions.  Suppose that
you want to construct \texttt{cpoint} records using an optional
color that, if not supplied, defaults to the value 0.  To do so, we
supply a \texttt{protocol} argument to \texttt{define-record-type}.
The only difference here is that the procedure \texttt{new} is a
\emph{curried} constructor.  It first takes as many arguments as the
constructor of the parent record type, and returns a procedure that
takes the initial values of the new fields.  

In our example, the constructor for the \texttt{point} record type
takes two arguments.  \texttt{cpoint} extends \texttt{point} with
one new field.  Therefore, \texttt{new} in the definition below
first takes the arguments for \texttt{point}'s constructor, then
takes the initial color value.  The definition below shows how the
custom constructor may be defined.

\newpage
\begin{CodeInline}
(define-record-type cpoint
  (parent point) 
  (fields color) 
  (protocol
    (lambda (new) 
      (case-lambda 
        [(x y c) ((new x y) c)]
        [(x y)   ((new x y) 0)]))))
\end{CodeInline}


\section{Exception handling}

The procedure \texttt{with-exception-handler} allows the programmer
to specify how to handle exceptional situations.  It takes two
procedures as arguments: 
\begin{itemize}
\item An exception handler which is a procedure that takes a
single argument, the object that was raised.
\item A body thunk which is a procedure with no arguments whose body
is evaluated with the exception handler installed.
\end{itemize}

In addition to installing exception handlers, \rnrs{6} provides two
ways of raising exceptions: \texttt{raise} and
\texttt{raise-continuable}.  We describe the 
\texttt{raise-continuable} procedure
first since it's the simpler of the two.  
For the code below, assume that \texttt{print} is defined as:
\begin{CodeInline}
(define (print who obj)
  (display who) 
  (display ": ")
  (display obj)
  (newline))
\end{CodeInline}

The first example, below, shows how a simple exception handler is
installed.  Here, the exception handler prints the object it
receives and returns the symbol \texttt{there}.  The call to
\texttt{raise-continuable} calls the exception handler, passing it
the symbol \texttt{here}.  When the handler returns, the returned
value becomes the value of the call to \texttt{raise-continuable}.

\begin{CodeInline}
(with-exception-handler
  (lambda (obj)                         ;;; prints
    (print "handling" obj)              ;;;   handling: here
    'there)                             ;;;   returned: there
  (lambda ()
    (print "returned" (raise-continuable 'here))))
\end{CodeInline}

Exceptional handlers may nest, and in that case, if an exception is
raised while evaluating an inner handler, the outer handler is
called as the following example illustrates:

\begin{CodeInline}
(with-exception-handler
  (lambda (obj)                         ;;; prints
    (print "outer" obj)                 ;;;   inner: here    
    'outer)                             ;;;   outer: there   
  (lambda ()                            ;;;   returned: outer
    (with-exception-handler
      (lambda (obj)
        (print "inner" obj)
        (raise-continuable 'there))
      (lambda ()
        (print "returned" (raise-continuable 'here))))))
\end{CodeInline}

In short, \texttt{with-exception-handler} binds an exception handler
within the dynamic context of evaluating the thunk, and
\texttt{raise-continuable} calls it.

The procedure \texttt{raise} is similar to
\texttt{raise-continuable} except that if the handler returns, a new
exception is raised, calling the next handler in sequence until the
list of handlers is exhausted.

\begin{CodeInline}
(call/cc                          ;;; prints
  (lambda (escape)                ;;;   inner: here
    (with-exception-handler       ;;;   outer: #[condition ---]
      (lambda (obj)               ;;; returns
        (print "outer" obj)       ;;;   12
        (escape 12))
      (lambda ()                            
        (with-exception-handler            
          (lambda (obj)
            (print "inner" obj)
            'there)
          (lambda ()
            (print "returned" (raise 'here))))))))
\end{CodeInline}

Here, the call to \texttt{raise} calls the inner exception handler,
which returns, causing \texttt{raise} to re-raise a non-continuable 
exception to the outer exception handler.  The outer exception
handler then calls the escape continuation.

The following procedure provides a useful example of using the
exception handling mechanism.  Consider a simple definition of the
procedure \texttt{configuration-option} which returns the value
associated with a key where the key/value pairs are stored in an
association list in a configuration file.

\begin{CodeInline}
(define (configuration-option filename key)
  (cdr (assq key (call-with-input-file filename read))))
\end{CodeInline}

Possible things may go wrong with calling
\texttt{configuration-option} including errors opening the file,
errors reading from the file (file may be corrupt), error in
\texttt{assq} since what's read may not be an association list, and
error in \texttt{cdr} since the key may not be in the association
list.  Handling all error possibilities is tedious and error prone.  
Exceptions provide a clean way of solving the problem.  Instead of
guarding against all possible errors, we install a handler that
suppresses all errors and returns a default value if things go
wrong.  Error handling for \texttt{configuration-option} may be
added as follows:

\begin{CodeInline}
(define (configuration-option filename key default)
  (define (getopt)
    (cdr (assq key (call-with-input-file filename read))))
  (call/cc
    (lambda (k)
      (with-exception-handler 
        (lambda (_) (k default))
        getopt))))
\end{CodeInline}


\chapter{\label{chapter:ikarus}The \texttt{(ikarus)} library}

In addition to the libraries listed in the \rnrs{6} standard, Ikarus
contains the \texttt{(ikarus)} library which provides additional
useful features.  The \texttt{(ikarus)} library is a composite
library---it exports a superset of all the supported bindings of
\rnrs{6}.  While not all of the exports of \texttt{(ikarus)} are
documented at this time, this chapter attempts to describe a few of
these useful extensions.  Extensions to Scheme's lexical syntax are
also documented.

\idxlabeldefun{\#"!ikarus}{\#"!ikarus}{shebang-ikarus}{\#!ikarus}{reader syntax}

Ikarus extends Scheme's lexical syntax (\rnrs{6}~Chapter~4) in a
variety of ways including:\\
$\bullet$ end-of-file marker, \deflabelref{\#!eof}{shebang-eof}\\
$\bullet$ gensym syntax, \deflabelref{\#\{gensym\}}{gensym syntax}\\
$\bullet$ graph syntax, \deflabelref{\#nn= \#nn\#}{graph-syntax}

The syntax extensions are made available by default on all input
ports, until the \texttt{\#!r6rs} token is read.  Thus, reading the
\texttt{\#!r6rs} token disables all extensions to the lexical syntax
on the specific port, and the \texttt{\#!ikarus} enables them again.

If you are writing code that is intended to be portable across
different Scheme implementations, we recommend adding the
\texttt{\#!r6rs} token to the top of every script and library that
you write.  This allows Ikarus to alert you when using non-portable
features.  If you're writing code that's intended to be
Ikarus-specific, we recommend adding the \texttt{\#!ikarus} token in
order to get an immediate error when your code is run under other
implementations.

\defun{port-mode}{procedure}
\texttt{(port-mode ip)} 

The \texttt{port-mode} procedure accepts an input port as an
argument and returns one of \texttt{r6rs-mode} or
\texttt{ikarus-mode} as a result.  All input ports initially start
in the \texttt{ikarus-mode} and thus accept Ikarus-specific reader
extensions.  When the \texttt{\#!r6rs} token is read from a port,
its mode changes to \texttt{ikarus-mode}.

\begin{verbatim}
   > (port-mode (current-input-port))
   ikarus-mode
   > #!r6rs (port-mode (current-input-port))
   r6rs-mode
   > #!ikarus (port-mode (current-input-port))
   ikarus-mode
\end{verbatim}

\idxlabeldefun{set-port-mode"!}{set-port-mode"!}{set-port-mode-bang}{set-port-mode!}{procedure}
%\defun{set-port-mode!}{procedure}
%\index{set-port-mode@\texttt{set-port-mode"!}}
\texttt{(set-port-mode!\ ip mode)} 

The \texttt{set-port-mode!} procedure modifies the lexical syntax
accepted by subsequent calls to \texttt{read} on the input port.
The mode is a symbol which should be one of \texttt{r6rs-mode} or
\texttt{ikarus-mode}.  The effect of setting the port mode is
similar to that of reading the \texttt{\#!r6rs} or \texttt{\#ikarus}
from that port.

\begin{verbatim}
   > (set-port-mode! (current-input-port) 'r6rs-mode)
   > (port-mode (current-input-port))
   r6rs-mode
\end{verbatim}

\newpage
\idxlabeldefun{\#"!eof}{\#"!eof}{shebang-eof}{\#!eof}{reader syntax}

The end-of-file marker, \texttt{\#!eof}, is an extension to the
\rnrs{6} syntax.  The primary utility of the \texttt{\#!eof} marker
is to stop the reader (e.g. \texttt{read} and \texttt{get-datum})
from reading the rest of the file.  
\begin{verbatim}
   #!/usr/bin/env scheme-script
   (import (ikarus))
   <some code>
   (display "goodbye\n")

   #!eof
   <some junk>
\end{verbatim}


The \texttt{\#!eof} marker also serves as a datum in Ikarus, much
like \texttt{\#t} and \texttt{\#f}, when it is found inside other
expressions.

\begin{verbatim}
   > (eof-object)
   #!eof
   > (read (open-input-string ""))
   #!eof
   > (read (open-input-string "#!eof"))
   #!eof
   > (quote #!eof)
   #!eof
   > (eof-object? '#!eof)
   #t
   > #!r6rs #!eof
   Unhandled exception
    Condition components:
      1. &error
      2. &who: tokenize
      3. &message: "invalid syntax: #!e"
   > #!ikarus #!eof
   $ 
\end{verbatim}

\newpage
\section{Parameters}

Parameters in Ikarus\footnote{Parameters are found in many Scheme
implementations such as Chez Scheme and MzScheme.} are intended for
customizing the behavior of a procedure during the dynamic execution
of some piece of code.  Parameters are first class entities
(represented as procedures) that hold the parameter value.  A
parameter procedure accepts either zero or one argument.  If given
no arguments, it returns the current value of the parameter.  If
given a single argument, it must set the state to the value of the
argument.  Parameters replace the older concept of using starred
\texttt{*global*} customization variables.  For example, instead of
writing:
\begin{verbatim}
   (define *screen-width* 72)
\end{verbatim}
and then mutating the variable \texttt{*screen-width*} with
\texttt{set!}, we could wrap the variable \texttt{*screen-width*} with a 
\texttt{screen-width} parameter as follows:
\begin{verbatim}
   (define *screen-width* 72)
   (define screen-width 
     (case-lambda
       [()  *screen-width*]
       [(x) (set! *screen-width* x)]))
\end{verbatim}

The value of \texttt{screen-width} can now be passed as argument,
returned as a value, and exported from libraries.

\defun{make-parameter}{procedure}
\texttt{
(make-parameter x)\\
(make-parameter x f)
}

As parameters are common in Ikarus, the procedure
\texttt{make-parameter} is defined to model the common usage pattern
of parameter construction. 

\paragraph{\texttt{(make-parameter x)}} constructs a parameter
with \texttt{x} as the initial value.  For example, the code above
could be written succinctly as:
\begin{verbatim}
   (define screen-width (make-parameter 72))
\end{verbatim}

\paragraph{\texttt{(make-parameter x f)}} constructs a parameter
which filters the assigned values through the procedure \texttt{f}.
The initial value of the parameter is the result of calling
\texttt{(f~x)}.  Typical uses of the filter procedure include
checking some constraints on the passed argument or converting it to
a different data type.  The \texttt{screen-width} parameter may be
constructed more robustly as:
\begin{verbatim}
   (define screen-width 
     (make-parameter 72
       (lambda (w)
         (assert (and (integer? w) (exact? w)))
         (max w 1))))
\end{verbatim}
This definition ensures, through \texttt{assert}, that the argument
passed is an exact integer.  It also ensures, through \texttt{max}
that the assigned value is always positive.


\defun{parameterize}{syntax}
\texttt{(parameterize ([lhs* rhs*] ...) body body* ...)}

Parameters can be assigned to by simply calling the parameter
procedure with a single argument.  The \texttt{parameterize} syntax
is used to set the value of a parameter within the dynamic extent of
the \texttt{body~body*~...} expressions.  

The \texttt{lhs* ...} are expressions, each of which must evaluate
to a parameter.  Such parameters are not necessarily constructed by
\texttt{make-parameter}---any procedure that follows the parameters
protocol works.  

The advantage of using \texttt{parameterize} over explicitly
assigning to parameters (same argument applies to global variables)
is that you're guaranteed that whenever control exits the body of a
\texttt{parameterize} expression, the value of the parameter is
reset back to what it was before the body expressions were entered.
This is true even in the presence of \texttt{call/cc}, errors, and
exceptions.

The following example shows how to set the text property of a
terminal window.  The parameter \texttt{terminal-property} sends an
ANSI escape sequence to the terminal whenever the parameter value is
changed.  The use of \texttt{terminal-property} within
\texttt{parameterize} changes the property before
\texttt{(display~"RED!")} is called and resets it back to normal
when the body returns.

\begin{CodeInline}
(define terminal-property
  (make-parameter "0"
    (lambda (x)
      (display "\x1b;[")
      (display x)
      (display "m")
      x)))

(display "Normal and ")
(parameterize ([terminal-property "41;37"])
  (display "RED!"))
(newline)
\end{CodeInline}

\newpage
\section{Local library imports}
\defun{import}{syntax}
\texttt{(import import-spec* ...)}

The \texttt{import} keyword which is exported from the
\texttt{(ikarus)} library can be used anywhere definitions can
occur: at a script body, library's top-level, or in internal
definitions context.  The syntax of the local \texttt{import} form
is similar to the \texttt{import} that appears at the top of a
library or a script form, and carries with it the same restrictions:
no identifier name may be imported twice unless it denotes the same
identifier; no identifier may be both imported and defined; and
imported identifiers are immutable.

Local \texttt{import} forms are useful for two reasons: (1) they
minimize the namespace clutter that usually occurs when many
libraries are imported at the top level, and (2) they limit the
scope of the import and thus help modularize a library's
dependencies.

Suppose you are constructing a large library and at some point you
realize that one of your procedures needs to make use of some other
library for performing a specific task.  Importing that library at
top level makes it available for the entire library.  Consequently,
even if that library is no longer used anywhere in the code (say
when the code that uses it is deleted), it becomes very hard to
delete the import without first examiniming the entire library body
for potential usage leaks.  By locally importing a library into the
appropriate scope, we gain the ability to delete the \texttt{import}
form when the procedure that was using it is deleted.


\newpage
\section{Local modules}

This section is not documented yet.
Please refer to Section~10.5 of Chez Scheme
User's Guide~\cite{csug7}, Chapter~3 of Oscar Waddel's Ph.D
Thesis~\cite{waddell-thesis}, and its POPL99
paper~\cite{waddell-extending} for details on using the
\texttt{module} and \texttt{import} keywords.  Ikarus's internal
module system is similar in spirit to that of Chez Scheme.


\defun{module}{syntax}
\texttt{(module M definitions ... expressions ...)}\\
\texttt{(module definitions ... expressions ...)}

\defun{import}{syntax}
\texttt{(import M)}


\newpage

\section{\label{sec:gensyms}Gensyms}

Gensym stands for a \emph{generated symbol}---a fresh symbol that is
generated at run time and is guaranteed to be \emph{not}
\texttt{eq?} to any other symbol present in the system.  Gensyms are
useful in many applications including expanders, compilers, and
interpreters when generating an arbitrary number of unique names is
needed.

Ikarus is similar to Chez Scheme in that the readers (including the
\texttt{read} procedure) and writers (including \texttt{write} and
\texttt{pretty-print}) maintain the read/write invariance on
gensyms.  When a gensym is written to an output port, the system
automatically generates a random unique identifier for the gensym.
When the gensym is read back though the \verb|#{gensym}| read
syntax, a new gensym is \emph{not} regenerated, but instead, it is
looked up in the global symbol table. 

A gensym's name is composed of two parts: a \emph{pretty} string and
a \emph{unique} string.  The Scheme procedure
\texttt{symbol->string} returns the pretty string of the gensym and
not its unique string.  Gensyms are printed by default as \\
\verb|#{pretty-string unique-string}|.

\defun{gensym}{procedure}
\texttt{(gensym)}\\
\texttt{(gensym string)}\\
\texttt{(gensym symbol)}

The procedure \texttt{gensym} constructs a new gensym.  If passed no
arguments, it constructs a gensym with no pretty name.  The pretty
name is constructed when and if the pretty name of the resulting
gensym is needed.  If \texttt{gensym} is passed a string, that
string is used as the pretty name.  If \texttt{gensym} is passed a
symbol, the pretty name of the symbol is used as the pretty name of
the returned gensym.
See \defref{gensym-prefix} and \defref{gensym-count} for details. 

\begin{verbatim}
   > (gensym)
   #{g0 |y0zf>GlFvcTJE0xw|}
   > (gensym)
   #{g1 |U%X&sF6kX!YC8LW=|}
   > (eq? (gensym) (gensym))
   #f
\end{verbatim}

\texttt{(gensym string)} constructs a new gensym with
\texttt{string} as its pretty name.   Similarly,
\texttt{(gensym~symbol)} constructs a new gensym with the pretty
name of \texttt{symbol}, if it has one, as its pretty name.

\begin{verbatim}
   > (gensym "foo")
   #{foo |>VgOllCM&$dSvRN=|}
   > (gensym 'foo)
   #{foo |!TqQLmtw2hoEYfU>|}
   > (gensym (gensym 'foo))
   #{foo |N2C>5O0>C?OROUBU|}
\end{verbatim}



\defun{gensym?}{procedure}
\texttt{(gensym? x)}

The \texttt{gensym?}\ predicate returns \texttt{\#t} if its argument
is a gensym, and returns \texttt{\#f} otherwise.

\begin{verbatim}
   > (gensym? (gensym))
   #t
   > (gensym? 'foo)
   #f
   > (gensym? 12)
   #f
\end{verbatim}

\defun{gensym->unique-string}{procedure}
\texttt{(gensym->unique-string gensym)}

The \texttt{gensym->unique-string} procedure returns the unique name
associated with the gensym argument.

\begin{verbatim}
   > (gensym->unique-string (gensym))
   "YukrolLMgP?%ElcR"
\end{verbatim}


\idxdefun{gensym syntax}{\#\{gensym\}}{reader syntax}
\texttt{\#\{unique-name\}}
\index{\#\{pretty unique\}@\texttt{\#\{pretty unique\}} reader syntax}
\\
\texttt{\#\{pretty-name unique-name\}}
\index{\#\{unique\}@\texttt{\#\{unique\}} reader syntax}
\\
\texttt{\#:pretty-name}
\index{\#:pretty@\texttt{\#:pretty} reader syntax}

Ikarus's \texttt{read} and \texttt{write} procedures extend the
lexical syntax of Scheme by the ability to read and write gensyms
using one of the three forms listed above.

\verb|#{unique-name}| constructs, at read time, a gensym whose
unique name is the one specified.   If a gensym with the same unique
name already exists in the system's symbol table, that gensym is
returned.
\begin{verbatim}
   > '#{some-long-name}
   #{g0 |some-long-name|}
   > (gensym? '#{some-long-unique-name})
   #t
   > (eq? '#{another-unique-name} '#{another-unique-name})
   #t
\end{verbatim}

The two-part \verb|#{pretty-name unique-name}| gensym syntax is
similar to the syntax shown above with the exception that if a new
gensym is constructed (that is, if the gensym did not already exist
in the symbol table), the pretty name of the constructed gensym is
set to \texttt{pretty-name}.

\begin{verbatim}
   > '#{foo unique-identifier} 
   #{foo |unique-identifier|}
   > '#{unique-identifier}
   #{foo |unique-identifier|}
   > '#{bar unique-identifier} 
   #{foo |unique-identifier|}
\end{verbatim}

The \texttt{\#:pretty-name} form constructs, at read time, a gensym
whose pretty name is \texttt{pretty-name} and whose unique name is
fresh.  This form guarantees that the resulting gensym is not
\texttt{eq?}\ to any other symbol in the system.

\begin{verbatim}
   > '#:foo
   #{foo |j=qTGlEwS/Zlp2Dj|}
   > (eq? '#:foo '#:foo)
   #f
\end{verbatim}

\defun{generate-temporaries}{example}
\index{Examples!generate-temporaries@\texttt{generate-temporaries}}

The \texttt{(rnrs syntax-case)} library provides a
\texttt{generate-temporaries} procedure, which takes a syntax object
(representing a list of things) and returns a list of fresh
identifiers.  Using \texttt{gensym}, that procedure can be defined
as follows:

\begin{CodeInline}
(define (generate-temporaries* stx)
  (syntax-case stx ()
    [(x* ...) 
     (map (lambda (x)
            (datum->syntax #'unimportant 
              (gensym
                (if (identifier? x) 
                    (syntax->datum x)
                    't))))
          #'(x* ...))]))
\end{CodeInline}

The above definition works by taking the input \texttt{stx} and
destructuring it into the list of syntax objects \texttt{x*~...}.
The inner procedure maps each \texttt{x} into a new syntax object
(constructed with \texttt{datum->syntax}).  The datum is a gensym,
whose name is the same name as \texttt{x} if \texttt{x} is an
identifier, or the symbol \texttt{t} if \texttt{x} is not an
identifier.  The output of \texttt{generate-temporaries*} generates
names similar to their input counterpart:

\begin{verbatim}
   > (print-gensym #f) 
   > (generate-temporaries* #'(x y z 1 2))
   (#<syntax x> #<syntax y> #<syntax z> #<syntax t> #<syntax t>)
\end{verbatim}

\newpage
\section{Printing}

\defun{pretty-print}{procedure}
\texttt{(pretty-print datum)}\\
\texttt{(pretty-print datum output-port)}

The procedure \texttt{pretty-print} is intended for printing Scheme
data, typically Scheme programs, in a format close to how a Scheme
programmer would write it.  Unlike \texttt{write}, which writes its
input all in one line, \texttt{pretty-print} inserts spaces and new
lines in order to produce more pleasant output.

\begin{verbatim}
  (define fact-code
    '(letrec ([fact (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))])
       (fact 5)))

  > (pretty-print fact-code)
  (letrec ((fact
            (lambda (n) (if (zero? n) 1 (* n (fact (- n 1)))))))
    (fact 5))
\end{verbatim}

The second argument to \texttt{pretty-print}, if supplied, must be 
an output port.  If not supplied, the \texttt{current-output-port}
is used.

\BoxedText{Limitations:}{As shown in the output above, the current
implementation of \texttt{pretty-print} does not handle printing of
square brackets properly.}

\defun{pretty-width}{parameter}
\texttt{(pretty-width)}\\
\texttt{(pretty-width n)}

The parameter \texttt{pretty-width} controls the number of
characters after which the \texttt{pretty-print} starts breaking
long lines into multiple lines.   The initial value of
\texttt{pretty-width} is set to 60 characters, which is suitable for most
terminals and printed material.   

\begin{verbatim}
   > (parameterize ([pretty-width 40])
        (pretty-print fact-code))
   (letrec ((fact
             (lambda (n)
               (if (zero? n)
                   1
                   (* n (fact (- n 1)))))))
     (fact 5))
\end{verbatim}

Note that \texttt{pretty-width} does not guarantee that 
the output will not extend beyond the specified number.  Very long
symbols, for examples, cannot be split into multiple lines and may
force the printer to go beyond the value of \texttt{pretty-width}.

\defun{format}{procedure}
\texttt{(format fmt-string args ...)}

The procedure \texttt{format} produces a string formatted according
to \texttt{fmt-string} and the supplied
arguments.  The format string contains markers in which the string
representation of each argument is placed.  The markers include:


\hangpara{2em}{1}
\verb|"~s"| instructs the formatter to place the next argument
as if the procedure \texttt{write} has printed it.  If the argument
contains a string, the string will be quoted and all quotes and
backslashes in the string will be escaped.  Similarly, characters
will be printed using the \verb|#\x| notation.

\hangpara{2em}{1}
\verb|"~a"| instructs the formatter to place the next argument
as if the procedure \texttt{display} has printed it.  Strings and
characters are placed as they are in the output.

\hangpara{2em}{1}
\verb|"~b"| instructs the formatter to convert the next
argument to its binary (base 2) representation.  The argument must be an
exact number.  Note that the \texttt{\#b} numeric prefix is not
produced in the output.

\hangpara{2em}{1}
\verb|"~o"| is similar to \verb|"~b"|  except that
the number is printed in octal (base 8).

\hangpara{2em}{1}
\verb|"~x"|  is similar to \verb|"~b"|  except that
the number is printed in hexadecimal (base 16).

\hangpara{2em}{1}
\verb|"~d"|  outputs the next argument, which can be an
exact or inexact number, in its decimal (base 10) representation.

\hangpara{2em}{1}
\verb|"~~"|  instructs the formatter to place a tilde
character, \verb|~|, in the output without consuming an
argument.

Note that the \texttt{\#b}, \texttt{\#o}, and \texttt{\#x} numeric
prefixes are not added to the output when \verb|~b|, \verb|~o|, and
\verb|~x| are used.

\begin{verbatim}
   > (format "message: ~s, ~s, and ~s" 'symbol "string" #\c)
   "message: symbol, \"string\", and #\\c"

   > (format "message: ~a, ~a, and ~a" 'symbol "string" #\c)
   "message: symbol, string, and c"
\end{verbatim}

\defun{printf}{procedure}
\texttt{(printf fmt-string args ...)}

The procedure \texttt{printf} is similar to \texttt{format} except
that the output is sent to the \texttt{current-output-port} instead
of being collected in a string.

\begin{verbatim}
   > (let ([n (+ (expt 2 32) #b11001)])
       (printf "~d = #b~b = #x~x\n" n n n))
   4294967321 = #b100000000000000000000000000011001 = #x100000019
\end{verbatim}


\defun{fprintf}{procedure}
\texttt{(fprintf output-port fmt-string args ...)}

The procedure \texttt{fprintf} is similar to \texttt{printf} except
that the output port to which the output is sent is specified as the
first argument.

\defun{print-graph}{parameter}
\texttt{(print-graph)} \\
\texttt{(print-graph \#t)}\\
\texttt{(print-graph \#f)}

\phantomsection
\label{graph-syntax}
The graph notation is a way of marking and referencing parts of a
data structure and, consequently, creating shared and cyclic data
structures at read time instead of resorting to explicit mutation at
run time.  The \texttt{\#$n$=} marks the following data structure with
mark $n$, where $n$ is a nonnegative integer.  The \texttt{\#$n$\#}
references the data structure marked $n$.  Marks can be assigned and
referenced in any order but each mark must be assigned to exactly
once in an expression.

\begin{verbatim}
   > (let ([x '#0=(1 2 3)])
       (eq? x '#0#))
   #t
   > (let ([x '#0#] [y '#0=(1 2 3)])
       (eq? x y))
   #t
   > (eq? (cdr '(12 . #1#)) '#1=(1 2 3))
   #t
   > (let ([x '#1=(#1# . #1#)])
       (and (eq? x (car x)) 
            (eq? x (cdr x))))
   #t
\end{verbatim}

The \texttt{print-graph} parameter controls how the writers (e.g.
\texttt{pretty-print} and \texttt{write}) handle shared and cyclic
data structures.  In Ikarus, all writers detect cyclic data
structures and they all terminate on all input, cyclic or otherwise.

If the value of \texttt{print-graph} is set to \texttt{\#f} (the
default), then the writers does not attempt to detect shared data
structures.  Any part of the input that is shared is printed as if
no sharing is present.
If the value of \texttt{print-graph} is set to \texttt{\#t}, all
sharing of data structures is marked using the \texttt{\#$n$=} and
\texttt{\#$n$\#} notation. 


\begin{verbatim}
   > (parameterize ([print-graph #f])
       (let ([x (list 1 2 3 4)])
         (pretty-print (list x x x))))
   ((1 2 3 4) (1 2 3 4) (1 2 3 4))

   > (parameterize ([print-graph #t])
       (let ([x (list 1 2 3 4)])
         (pretty-print (list x x x))))
   (#0=(1 2 3 4) #0# #0#)

   > (parameterize ([print-graph #f])
       (let ([x (list 1 2)])
         (let ([y (list x x x x)])
           (set-car! (last-pair y) y)
           (pretty-print (list y y)))))
   (#0=((1 2) (1 2) (1 2) #0#) #0#)

   > (parameterize ([print-graph #t])
       (let ([x (list 1 2)])
         (let ([y (list x x x x)])
           (set-car! (last-pair y) y)
           (pretty-print (list y y)))))
   (#0=(#1=(1 2) #1# #1# #0#) #0#)
\end{verbatim}


% \defun{print-unicode}{parameter}
% \texttt{(print-unicode)} \\
% \texttt{(print-unicode \#t)} \\
% \texttt{(print-unicode \#f)}


\defun{print-gensym}{parameter}
\texttt{(print-gensym)}\\
\texttt{(print-gensym \#t)}\\
\texttt{(print-gensym \#f)}\\
\texttt{(print-gensym 'pretty)}

The parameter \texttt{print-gensym} controls how gensyms are printed
by the various writers.  

If the value of \texttt{print-gensym} is \texttt{\#f}, then gensym
syntax is suppressed by the writers and only the gensyms' pretty
names are printed.  If the value of \texttt{print-gensym} is
\texttt{\#t}, then the full \verb|#{pretty unique}| syntax is
printed.  Finally, if the value of \texttt{print-gensym} is the
symbol \texttt{pretty}, then gensyms are printed using the
\texttt{\#:pretty} notation.  

\begin{verbatim}
   > (parameterize ([print-gensym #f])
       (pretty-print (list (gensym) (gensym))))
   (g0 g1)

   > (parameterize ([print-gensym #t])
       (pretty-print (list (gensym) (gensym))))
   (#{g2 |KR1M2&CTt1<B0n/m|} #{g3 |FBAb&7NC6&=c82!O|})

   > (parameterize ([print-gensym 'pretty])
       (pretty-print (list (gensym) (gensym))))
   (#:g4 #:g5)
\end{verbatim}

The initial value of \texttt{print-gensym} is \texttt{\#t}.


\defun{gensym-prefix}{parameter}
\texttt{(gensym-prefix)}\\
\texttt{(gensym-prefix string)}

The parameter \texttt{gensym-prefix} specifies the string to be used
as the prefix to generated pretty names.  The default value of
\texttt{gensym-prefix} is the string \texttt{"g"}, which causes
generated strings to have pretty names in the sequence \texttt{g0},
\texttt{g1}, \texttt{g2}, etc. 

\begin{verbatim}
   > (parameterize ([gensym-prefix "var"]
                    [print-gensym #f])
        (pretty-print (list (gensym) (gensym) (gensym))))
   (var0 var1 var2)
\end{verbatim}

Beware that the \texttt{gensym-prefix} controls how pretty names are
generated, and has nothing to do with how \texttt{gensym} constructs
a new gensym.  In particular, notice the difference between the
output in the first example with the output of the examples below:

\begin{verbatim}
   > (pretty-print
       (parameterize ([gensym-prefix "var"] [print-gensym #f])
         (list (gensym) (gensym) (gensym))))
   (g3 g4 g5)

   > (let ([ls (list (gensym) (gensym) (gensym))])
       (parameterize ([gensym-prefix "var"] [print-gensym #f])
         (pretty-print ls)))
   (var5 var6 var7)
\end{verbatim}



\defun{gensym-count}{parameter}
\texttt{(gensym-count)}\\
\texttt{(gensym-count n)}

The parameter \texttt{gensym-count} determines the number 
which is attached to the \texttt{gensym-prefix} when gensyms'
pretty names are generated.  The initial value of \texttt{gensym-count}
is 0 and is incremented every time a
pretty name is generated.  It might be set to any non-negative
integer value. 

\begin{verbatim}
   > (let ([x (gensym)])
       (parameterize ([gensym-count 100] [print-gensym #f])
         (pretty-print (list (gensym) x (gensym)))))
   (g100 g101 g102)
\end{verbatim}

Notice from all the examples so far that pretty names are generated
in the order at which the gensyms are printed, not in the order in
which gensyms were created.

\newpage
\section{Tracing}

\defun{trace-define}{syntax}
\texttt{(trace-define (name . args) body body* ...)}\\
\texttt{(trace-define name expression)}

The \texttt{trace-define} syntax is similar to \texttt{define}
except that the bound value, which must be a procedure, becomes a
traced procedure.  A traced procedure prints its arguments when it
is called and prints its values when it returns.  

\begin{verbatim}
   > (trace-define (fact n)
       (if (zero? n) 1 (* n (fact (- n 1)))))
   > (fact 5)
   |(fact 5)
   | (fact 4)
   | |(fact 3)
   | | (fact 2)
   | | |(fact 1)
   | | | (fact 0)
   | | | 1
   | | |1
   | | 2
   | |6
   | 24
   |120
   120
\end{verbatim}

The tracing facility in Ikarus preserves and shows tail recursion
and distinguishes it from non-tail recursion by showing tail calls
starting at the same line in which their parent was called.  

\begin{verbatim}
   > (trace-define (fact n)
       (trace-define (fact-aux n m)
         (if (zero? n) m (fact-aux (- n 1) (* n m))))
       (fact-aux n 1))
   > (fact 5)
   |(fact 5)
   |(fact-aux 5 1)
   |(fact-aux 4 5)
   |(fact-aux 3 20)
   |(fact-aux 2 60)
   |(fact-aux 1 120)
   |(fact-aux 0 120)
   |120
   120
\end{verbatim}

Moreover, the tracing facility interacts well with continuations and
exceptions.

\begin{verbatim}
   > (call/cc
       (lambda (k) 
         (trace-define (loop n)
           (if (zero? n) 
               (k 'done)
               (+ (loop (- n 1)) 1)))
         (loop 5)))
   |(loop 5)
   | (loop 4)
   | |(loop 3)
   | | (loop 2)
   | | |(loop 1)
   | | | (loop 0)
   done
\end{verbatim}


\defun{trace-lambda}{syntax}
\texttt{(trace-lambda name args body body* ...)}

The \texttt{trace-lambda} macro is similar to \texttt{lambda} except
that the resulting procedure is traced: it prints the arguments it
receives and the results it returns.

\newpage

\defun{make-traced-procedure}{procedure}
\texttt{(make-traced-procedure name proc)}

The procedure \texttt{make-traced-procedure} takes a name (typically
a symbol) and a procedure.  It returns a procedure similar to
\texttt{proc} except that it traces its arguments and values.

\begin{verbatim}
   > (define (fact n)
       (if (zero? n)
           (lambda (k) (k 1))
           (lambda (k)
             ((fact (- n 1))
              (make-traced-procedure `(k ,n)
                (lambda (v) 
                  (k (* v n))))))))
   > (call/cc
       (lambda (k) 
         ((fact 5) (make-traced-procedure 'K k))))
   |((k 1) 1)
   |((k 2) 1)
   |((k 3) 2)
   |((k 4) 6)
   |((k 5) 24)
   |(K 120)
   120
\end{verbatim}


\newpage
\section{Timing}

This section describes some of Ikarus's timing facilities which may
be useful for benchmarking and performance tuning.

\defun{time}{syntax}
\texttt{(time expression)}

The \texttt{time} macro performs the following:  it evaluates
\texttt{expression}, then prints a summary of the run time
statistics, then returns the values returned by \texttt{expression}.
The run-time summary includes the number of bytes allocated, the
number of garbage collection runs, and the time spent in both the
mutator and the collector.


\begin{verbatim}
   > (let ()                                   ;;; 10 million
       (define ls (time (vector->list (make-vector 10000000))))
       (time (append ls ls))
       (values))
   running stats for (vector->list (make-vector 10000000)):
       3 collections
       672 ms elapsed cpu time, including 547 ms collecting
       674 ms elapsed real time, including 549 ms collecting
       120012328 bytes allocated
   running stats for (append ls ls):
       4 collections
       1536 ms elapsed cpu time, including 1336 ms collecting
       1538 ms elapsed real time, including 1337 ms collecting
       160000040 bytes allocated
\end{verbatim}

Note: The  output listed above is \emph{just a sample} that was
taken at some point on some machine.  The output on your
machine at the time you read this may vary.

\newpage
\defun{time-it}{procedure}
\texttt{(time-it who thunk)}

The procedure \texttt{time-it} takes a datum denoting the name of
the computation and a thunk (i.e. a
procedure with no arguments), invokes the thunk, prints the stats,
and returns the values obtained from invoking the thunk.  
If the value of \texttt{who} is non-false, \texttt{who}
is used when displaying the run-time statistics.  If the value of
\texttt{who} is \texttt{\#f}, then no name for the computation is
displayed.

\begin{verbatim}
   > (time-it "a very fast computation"
       (lambda () (values 1 2 3)))
   running stats for a very fast computation:
       no collections
       0 ms elapsed cpu time, including 0 ms collecting
       0 ms elapsed real time, including 0 ms collecting
       24 bytes allocated
   1
   2
   3

   > (time-it #f (lambda () 12))
   running stats:
       no collections
       0 ms elapsed cpu time, including 0 ms collecting
       0 ms elapsed real time, including 0 ms collecting
       0 bytes allocated
   12
\end{verbatim}

\chapter{The \texttt{(ikarus ipc)} library}

\ref{sec:environment-variables}
\ref{sec:subprocess}
\ref{sec:sockets}

\newpage

\section{\label{sec:environment-variables}Environment variables}

When the operating system starts a process, it starts the process in
some environment that maps environment variables to values.  Typical
keys found in the environment are \texttt{HOME} (pointing to the
home directory of the user), \texttt{PATH} (containing a
colon-separated list of directories to be searched when running a
command from the shell), \texttt{SHELL}, \texttt{EDITOR}, and
\texttt{PAGER}.  This section describes the procedures provided by
Ikarus for manipulating this environment. 

The environment procedures are placed in the \texttt{(ikarus~ipc)}
library because they provide a (limited) way for one process to
communicate to a subprocess, akin to parameter passing.

\defun{getenv}{procedure}
\texttt{(getenv key)}

The procedure \texttt{getenv} retrieves the value associated with
\texttt{key} (which must be a string) in the environment.  The value
returned is a (utf8-decoded) string, or \texttt{\#f} if there is no
mapping for \texttt{key} in the environment.


\defun{setenv}{procedure}
\texttt{(setenv key value)}\\
\texttt{(setenv key value overwrite?)}

The procedure \texttt{setenv} sets the mapping of \texttt{key} to
\texttt{value} in the environment.  Both \texttt{key} and
\texttt{value} must be strings.  If the \texttt{overwrite?} argument
is provided and is \texttt{\#f}, \texttt{setenv} does not overwrite 
a value associated with \texttt{key} if one already exists.  The
procedure \texttt{setenv} may raise an exception if the operating
system cannot allocate enough memory to hold the new mapping.

\defun{unsetenv}{procedure}
\texttt{(unsetenv key)}

The procedure \texttt{unsetenv} removes \texttt{key} and its
associated value (if one exists) from the environment.


\BoxedText{Caveat:}{The underlying system procedure \texttt{setenv}
may leak some memory in some operating systems when passed some
values.  Ikarus has no way of getting around this system limitation
and thus may leak some memory for some calls to \texttt{setenv}.
Use sparingly.}


\newpage
\section{\label{sec:subprocess}Subprocess communication}

This section describes the facilities that Ikarus provides for
starting subprocesses and sending and receiving data through the
subprocesses' standard input, output, and error ports. 

\defun{system}{procedure}
\texttt{(system string)}

The \texttt{system} procedure takes a string represeting an external
shell command and arguments and invokes the shell (typically
\texttt{sh} on Unix systems) on this command.  The returned value
from \texttt{system} is the exit status of the external command.

Ikarus's \texttt{system} procedure is a thin wrapper around the
\texttt{system} procedure in the Standard C Library \texttt{libc}.

\begin{verbatim}
  > (system "ls M*")
  Makefile        Makefile.am     Makefile.in
  0
\end{verbatim}

\defun{process}{procedure}
\texttt{(process program-name args ...)}

The \texttt{process} procedure takes as input a string representing
the path to an external program and a set of strings that are the
arguments to the external program.  It invokes the program with the
given arguments, and returns four values: (1) a process identifier
(\texttt{pid}),
(2) an output port which pipes to the process's \texttt{stdin}, (3)
an input port wired to the process's \texttt{stdout}, and (4) an
input port wired to the process's \texttt{stderr}.  All three ports
are blocking: reading and writing to any one of them blocks Ikarus
until the some bytes are available for reading or writing.
Attempting to read from the process's \texttt{stdout} port may block
indefinitely if the external program does not write anything
(e.g.,~if it attempts to read from \texttt{stdin} instead).
Communicating with an external process must therefore be done
according to the protocol in which the external process
communicates.

\defun{process-nonblocking}{procedure}
\texttt{(process-nonblocking program-name args ...)}

The procedure \texttt{process-nonblocking} is similar to the
\texttt{process} procedure except that the three returned ports are
put in nonblocking mode.  Attempting to perform a read or write
operation on a nonblocking port in which bytes are not available for
reading or writing causes Ikarus to enqueue the port with the
continuation in which the read/write operation occurs and attempt to
dispatch previously enqueued ports on which some bytes are ready for
read or write.  See Section~\ref{sec:sockets} for more details on
blocking and nonblocking operations.




\defun{waitpid}{procedure}
\texttt{(waitpid)}\\
\texttt{(waitpid pid)}\\
\texttt{(waitpid pid block?)}\\
\texttt{(waitpid pid block? want-error?)}

The \texttt{waitpid} procedure waits for the process with the given
\texttt{pid} to terminate and, if successful, returns a
\texttt{wstatus} object encapsulating the wait status of the
process.  Without arguments, \texttt{waitpid} defaults the
\texttt{pid} to \texttt{-1} which allows one to wait for any child
process to exit.  If the \texttt{block?} argument is true (the
default), \texttt{waitpid} blocks indefinitely waiting for a child
process to exit.  When \texttt{block?} is false, \texttt{waitpid}
returns immediately regardless of whether or not a child process has
exited.  The \texttt{want-error?} controls what happens if
\texttt{block?} was specified to be \texttt{\#f} and no child had
exited.  If \texttt{want-error?} is true (the default), an error is
signaled.  Otherwise, \texttt{waitpid} returns \texttt{\#f} if no
process has exited.  Operations on the wait status result are listed
below.

\defun{wstatus-pid}{procedure}
\texttt{(wstatus-pid wstatus)}

The \texttt{wstatus-pid} returns the \texttt{pid} of the process
whose status is recorded in the \texttt{wstatus} object.  This
\texttt{pid} is most useful when the default \texttt{pid} of
\texttt{-1} is given to \texttt{waitpid} and thus the pid of the
exiting process is not known beforehand.


\defun{wstatus-exit-status}{procedure}
\texttt{(wstatus-exit-status wstatus)}

The procedure \texttt{wstatus-exit-status} returns the exit status
of the child process.  It is typically \texttt{0} if the child
exited normally and has other numeric values if the child process
encountered an error.

\defun{wstatus-received-signal}{procedure}
\texttt{(wstatus-received-signal wstatus)}

The procedure \texttt{wstatus-received-signal} returns the 
name  of the signal (or the number of the signal if the name is not
known) that caused the child process to exit.

The signal name is one of the following symbols:
\begin{verbatim}
  SIGABRT  SIGALRM  SIGBUS   SIGCHLD  SIGCONT    SIGFPE   SIGHUP 
  SIGILL   SIGINT   SIGKILL  SIGPIPE  SIGQUIT    SIGSEGV  SIGSTOP
  SIGTERM  SIGTSTP  SIGTTIN  SIGTTOU  SIGUSR1    SIGUSR2  SIGPOLL 
  SIGPROF  SIGSYS   SIGTRAP  SIGURG   SIGVTALRM  SIGXCPU  SIGXFSZ
\end{verbatim}
 
\defun{kill}{procedure}
\texttt{(kill pid signal-name)}

The \texttt{kill} procedure takes a \texttt{pid} and a signal name 
(a symbol from the list above) and asks the operating system to send
the signal to the given process.




\newpage 
\section{\label{sec:sockets}TCP and UDP sockets}

Ikarus supports synchronous (blocking) and asynchronous
(multiplexing) communication facilities over both TCP/IP and UDP/IP
channels.  It facilitates writing client and server applications
that serve a variety of purposes, e.g., web servers,
char clients, mail, news, et cetera.

The synchronous model is simple and is ideal for noninteractive
command-line applications that communicate with a single host at a
time.  FTP clients, HTTP spiders, and off-line netnews caching
programs typically use synchronous communication.  The basic
operations start with connecting (via \texttt{tcp-connect}) to an
internet service (identified by a port number or a service name)
located on some host (identified by its host name or IP number).  By
connecting to a server, we obtain an input port and an output port
forming bidirectional channel of communication.  Depending on the
service protocol, the client exchanges information with the server
by reading and writing to the designated ports.  Read and write
operations in this model may block indefinitely until appropriate
number of bytes are read/written, or until the operation times out.
Communication ends when the client closes both ports.

The asynchronous model allows for communicating with many hosts
simultaneously.  Ikarus maintains a queue of pending ports, the
blocking operation performed on these ports, and their respective
continuations.  Whenever the operating system indicates that a
read/write operation may block, Ikarus schedules the port and  a
restarting continuation into the queue and then dispatches one of
the \emph{ready} operations.   This is reminiscent of how
multitasking operating systems schedule I/O-bound threads, except
that in Ikarus, threads are lightweight, represented by ordinary
continuations.  Thus, reading or writing to a nonblocking port
causes Ikarus to transparently capture a continuation, enlist it in
the queue, and dispatch another continuation captured earlier.
Multiple read and write operations from multiple connections are
fulfilled concurrently, dispatching whichever one is ready and
without one operation blocking the rest.

Because asynchronous scheduling and dispatching involves switching
continuations, winders that maintain the dynamic environment
(e.g.,~those established by \texttt{dynamic-wind},
\texttt{parameterize}, \texttt{with-output-to-file},
\texttt{with-exception-handler}, etc.) are properly invoked when
leaving a dynamic context and entering another.  Care must be taken
when using winders that perform externally-visible side effects upon
entering/leaving a dynamic context.


\defun{tcp-connect}{procedure}
\texttt{(tcp-connect host service)}

The procedure \texttt{tcp-connect} attempts to connect to the
\texttt{service} located on the remote \texttt{host} through the
TCP/IP protocol.  The \texttt{host} argument is a string
representing either the IP address (e.g., \texttt{"127.0.0.1"}) or a
fully-qualified domain name (e.g., \texttt{"www.example.com"}), in
which case name to address resolution is performed automatically.
The \texttt{service} argument is also a string which can be either a
port number (e.g., \texttt{"80"}) or a service name (e.g.,
\texttt{"http"}) in which case the service name is mapped to the
canonical port number for the service.

Upon success, \texttt{tcp-connect} returns two values: a binary
\emph{input} port and a binary \emph{output} port.  Writing and
reading from the obtained ports may block indefinitely until an
appropriate number of bytes is read/written.   Closing both ports
closes the communication channel and frees the underlying
operating-system resources.


\defun{tcp-connect-nonblocking}{procedure}
\texttt{(tcp-connect-nonblocking host service)}

The procedure \texttt{tcp-connect-nonblocking} is similar to
\texttt{tcp-connect} except that the two returned ports are put in
\emph{nonblocking} mode.  If an attempt to perform a read (write)
operation on the input (output) port may block, a restart
continuation is captured and scheduled in the I/O queue and a
perviously blocked operation may be restarted (when its blocking
operation can progress).

\defun{udp-connect}{procedure}
\texttt{(udp-connect host service)}

The procedure \texttt{udp-connect} is similar to
\texttt{tcp-connect} except that it connects to the remote server
through the UDP protocol (as implied by the name).

\defun{udp-connect-nonblocking}{procedure}
\texttt{(udp-connect-nonblocking host-name service-name)}

The procedure \texttt{udp-connect-nonblocking} is similar to
\texttt{tcp-connect-nonblocking} except that it connects to the
remote server through the UDP protocol.


\defun{tcp-server-socket}{procedure}
\texttt{(tcp-server-socket port-number)}

The procedure \texttt{tcp-server-socket} attempts to \emph{listen}
on the given port number for incoming connections.  On success,
\texttt{tcp-server-socket} returns an abstract \emph{tcp-server}
object encapsulating the underlying operating-system server socket.
The server socket is placed in \emph{blocking} mode: an attempt to
accept a connection on such server blocks indefinitely
until a remote client attempts to establish a connection.

\defun{tcp-server-socket-nonblocking}{procedure}
\texttt{(tcp-server-socket-nonblocking port-number)}

This procedure is similar to \texttt{tcp-server-socket} except that
the returned server socket is placed in \emph{nonblocking} mode.  An
attempt to accept a connection from a nonblocking server socket does
not block the entire process, instead, a restarting continuation is
scheduled and is invoked when an incoming connection is available
(and another I/O-bound operation blocks).


\defun{accept-connection}{procedure}
\texttt{(accept-connection tcp-server)}

The procedure \texttt{accept-connection} takes a tcp-server socket
(e.g., one obtained from \texttt{tcp-server-socket}) and returns two
values: a binary \emph{input} port and a binary \emph{output} port
through which the server communicates with the connecting client.
If the \texttt{tcp-server} object is in blocking mode,
\texttt{accept-connection} may block the entire process until an
incoming connection is obtained.  If the server is in nonblocking
mode, an (otherwise) blocking operation would be rescheduled and
invoked later when a connection occurs.

The input and output ports that \texttt{accept-connection} returns
are put in blocking mode. .

\newpage

\defun{accept-connection-nonblocking}{procedure}
\texttt{(accept-connection-nonblocking tcp-server)}

The procedure \texttt{accept-connection-nonblocking} is similar to
\texttt{accept-connection} except that the two returned ports are
put in nonblocking mode.

\defun{close-tcp-server-socket}{procedure}
\texttt{(close-tcp-server-socket tcp-server)}

This procedure closing the server socket (so that no more incoming
connections can be accepted) and frees the underlying
operating-system resources associated with the socket.


\defun{register-callback}{procedure}
\texttt{(register-callback input-port thunk)}\\
\texttt{(register-callback output-port thunk)}\\
\texttt{(register-callback tcp-server thunk)}


The procedure \texttt{register-callback} takes a nonblocking port or
server socket and a callback procedure.  It enqueues the port/socket
and the thunk into the event queue.  The given procedure is called
when another I/O operation blocks and data is ready to be read (for
an input port argument), written (for an output port argument), or
an incoming connection is available (for a tcp-server argument).
The \texttt{register-callback} procedure returns immediately.  It
does not block and does not attempt to perform any read, write, or
accept operation on the given argument.




\chapter{\label{chapter:foreign}The \texttt{(ikarus foreign)} library}


This chapter describes the facilities through which Ikarus
interfaces with the host operating system and other external
libraries.  The facilities of the \texttt{(ikarus~foreign)}
library give the Scheme program unrestricted access to the computer
memory, allowing one to allocate, access, modify, and free memory as
needed.  The facilities also allow the Scheme program to \emph{call
out} to system procedures as well as allow the native procedures to
\emph{call back} into Scheme.  

This chapter is organized as follows: Section~\ref{sec:ffi-overview}
gives an overview of the basic concepts such as shared libraries,
external symbols, foreign data types, pointers, and procedures.
Section~\ref{sec:ffi-memory} describes the primitives that
\texttt{(ikarus~foreign)} provides for direct manipulation of
memory.  Section~\ref{sec:ffi-procedures} deals with loading
external libraries and calling out to native library procedures and
calling back into Scheme.  To demonstrate the usefulness of the
foreign facilities, Ikarus ships with two libraries that also serve
as extended examples for using the system.
Section~\ref{sec:ffi-opengl} describes The OpenGL library
\texttt{(ikarus~opengl)} which allows the programmer to produce 2D
and 3D computer graphics.  Section~\ref{sec:ffi-objc} describes the
\texttt{(ikarus~objc)} which allows the programmer to access
libraries and frameworks written in the Objective-C programming
language and thus provides full access to the Mac OS X system
(e.g.,~making graphical user interfaces with Cocoa and drawing
graphics with Quartz all from Scheme).

Ikarus version \texttt{0.0.4} is the first version of Ikarus to
support the described foreign interfaces.
\newpage

\section{\label{sec:ffi-overview}Overview}

In order to make full use of the computer, it is important for a
programming environment (e.g., Ikarus Scheme) to facilitate access
to the underlying architecture on which it runs.  The underlying
architecture includes the API provided by the host operating system
kernel (e.g., Linux), the system libraries (e.g., \texttt{libc}),
and other site-installed libraries (e.g., \texttt{sqlite3}).
Providing direct access to such API from within Scheme allows the
programmer to write Scheme libraries that have few or no
dependencies on external programs (such as \texttt{C} development
toolchain).  When dealing with system libraries, the programmer
must have a thorough understanding of many aspects of the targetted 
system.  This section attempts to provide answers to many questions
that are frequently encountered when interfacing to external
libraries.


\section{Memory management}

Ikarus Scheme is a managed environment.  Like in many programming
environments, Ikarus manages its own memory.  Scheme objects are
allocated in a special memory region (the Scheme heap) and have
type-specific object layout that allows the run time system to
distinguish object types and allows the garbage collector to locate
all potentially live objects and reclaim the memory of dead objects.
Scheme objects are also \emph{opaque} in the sense that the data
structures used to represent Scheme objects (e.g., pairs) are not
exposed to the programmer, who can only interact with objects
through an interface (e.g., \texttt{car}, \texttt{cdr}).  

Unmanaged environments, such as the operating system on which Ikarus
runs, require that the programmer manages the allocation and
deallocation of system resources herself.  Memory regions, file
handles, external devices, the screen, etc., are all examples of
resources whose management must be coordinated among the different
parts of the system, and this becomes the responsibility of the
programmer who is wiring the different subsystems together.

Memory, from a system's point of view, is \emph{transparent}.  A
pointer is an integer denoting an address of memory.  This memory
address may contain a value that requires interpretation.  At the
lowest-level, each byte of memory contains eight bits, each of which
may be toggled on or off.  A level higher, contiguous sequences of
bytes are grouped together and are interpreted as integers, floating
point numbers, or pointers to other memory addresses.  These are the
basic data types that are often interpreted atomically.  Yet a level
higher, groups of basic types form data structures such as arrays,
linked lists, trees, and so on.  Objects, as found in
object-oriented programming languages, are at an even higher level
of abstraction since they are treated as opaque references that
retain state and know how to respond to messages.

The procedures in the \texttt{(ikarus~foreign)} library are meant to
provide a way to interface with the low level memory operations such
as setting and getting bytes from specific locations in memory.
Although they do not provide high-level operations, the basic
procdures make implementing high-level operations (such as the
Objective-C system presented in Chapter~\ref{chapter:objc})
possible.  Programmers are encouraged to define their own
abstractions that are most suitable for the specific target library
rather than using the low-level operations directly.  This results
in writing more robust and more easily maintainable libraries.  To
put it more boldly: \textbf{Do not sprinkle your code with low-level
memory operations}.


\section{\label{sec:ffi-memory}Memory operations}

\defun{malloc}{procedure}
\texttt{(malloc n)}

The \texttt{malloc} procedure allocates \texttt{n} bytes of memory
and returns a pointer to the allocated memory.  The \texttt{malloc}
Scheme procedure is implemented using the host-provided
\texttt{malloc} system procedure (often found in \texttt{libc}).
The number of bytes, \texttt{n}, must be a positive exact integer.  

\begin{verbatim}
   > (malloc 10)
   #<pointer #x00300320>
   > (malloc 10000)
   #<pointer #x01800400>
\end{verbatim}

\newpage
\defun{free}{procedure}
\texttt{(free p)}

The \texttt{free} procedure takes a pointer and frees the memory
region at the given address.  The memory region must be allocated
with \texttt{malloc}, \texttt{calloc}, or a similar system
procedure.  Once freed, memory operations on the given address are
invalid and may cause the system to crash at unpredictable times.
Ikarus cannot check for such errors since the memory may be freed by
procedures that are external to Ikarus.



\defun{pointer->integer}{procedure}
\texttt{(pointer->integer p)}

The procedure \texttt{pointer->integer} converts the value of the
pointer \texttt{p} to an exact integer value.  The result may be a
fixnum or a bignum depending on the pointer.

\defun{integer->pointer}{procedure}
\texttt{(integer->pointer n)}

The procedure \texttt{integer->pointer} converts the exact integer
\texttt{n} to a pointer value.  The lower 32 bits (or 64 bits on
64-bit systems) of the value of \texttt{n} are significant in
computing the pointer value.  It is guaranteed that 
\texttt{(integer->pointer (pointer->integer p))} points to the same
address as \texttt{p}.

\defun{pointer?}{procedure}
\texttt{(pointer? x)}

The predicate \texttt{pointer?} returns \texttt{\#t} if the value
of \texttt{x} is a pointer, and returns \texttt{\#f} otherwise.

\BoxedText{Note:}{The result of calling the procedures
\texttt{eq?}, \texttt{eqv?} and \texttt{equal?} on pointer values is
unspecified.}


\newpage

\defun{pointer-set-c-char!}{procedure}
\texttt{(pointer-set-c-char! p i n)}

The procedure \texttt{pointer-set-c-char!} sets a single byte of memory
located at offset \texttt{i} from the pointer \texttt{p} to the
value of \texttt{n}.  The pointer \texttt{p} must be a valid
pointer.  The index \texttt{i} must be an exact integer.  The value
of \texttt{n} must be an exact integer.  Only the 8 lowermost
bits of \texttt{n} are used in the operation and the remaining bits
are ignored.

\defun{pointer-set-c-short!}{procedure}
\texttt{(pointer-set-c-short! p i n)}

The procedure \texttt{pointer-set-c-char!!} sets two bytes located at
offset \texttt{i} and \texttt{(+ i 1)} to the 16 lowermost bits of
the exact integer \texttt{n}.  Note that the offset \texttt{i} is a
byte offset; \texttt{pointer-set-c-short!} does not perform any pointer
arithmetic such as scaling the offset by the size of the memory
location.


\defun{pointer-set-c-int!}{procedure}
\texttt{(pointer-set-c-int! p i n)}

The procedure \texttt{pointer-set-c-int!} sets four bytes located at
offset \texttt{i} to \texttt{(+ i 3)} to the 32 lowermost bits of
the exact integer \texttt{n}.  Like \texttt{pointer-set-c-short!},
\texttt{pointer-set-c-int!} does not scale the offset \texttt{i}.


\defun{pointer-set-c-long!}{procedure}
\texttt{(pointer-set-c-long! p i n)}
 
On 64-bit systems, the procedure \texttt{pointer-set-c-long!} sets
eight bytes located at offset \texttt{i} to \texttt{(+ i 7)} to the
64 lowermost bits of the exact integer \texttt{n}.  Like the
previous procedures, \texttt{pointer-set-c-long!} does not scale the
offset \texttt{i}.  On 32-bit systems, \texttt{pointer-set-c-long!}
performs the same task as \texttt{pointer-set-c-int!}.


\defun{pointer-set-c-float!}{procedure}
\texttt{(pointer-set-c-float! p i fl)}

The procedure \texttt{pointer-set-c-float!} converts the Scheme
floating point number \texttt{fl} (represented in Ikarus as an
IEEE-754 double precision floating point number) to a float (an
IEEE-754 single precision floating point number) and stores the
result in the four bytes at offset \texttt{i} of the pointer
\texttt{p}.

\defun{pointer-set-c-double!}{procedure}
\texttt{(pointer-set-c-double! p i fl)}

The procedure \texttt{pointer-set-c-double!} stores the double
precision IEEE-754 floating point value of the Scheme flonum
\texttt{fl} in the eight bytes at offset \texttt{i} of the pointer
\texttt{p}.

\defun{pointer-set-c-pointer!}{procedure}
\texttt{(pointer-set-c-pointer! p i pv)}
 
On 64-bit systems, the procedure \texttt{pointer-set-c-pointer!} sets
eight bytes located at offset \texttt{i} to \texttt{(+ i 7)} to the
64-bit pointer value of \texttt{pv}.  On 32-bit systems, the
procedure \texttt{pointer-set-c-pointer!} sets four bytes located at
offset \texttt{i} to \texttt{(+ i 3)} to the 32-bit pointer value of
\texttt{pv}.  Like the previous procedures,
\texttt{pointer-set-c-pointer!} does not scale the offset \texttt{i}. 



\defun{pointer-ref-c-signed-char}{procedure}
\texttt{(pointer-ref-c-signed-char p i)}

The procedure \texttt{pointer-ref-c-signed-char} loads a single byte located
at offset \texttt{i} from the pointer \texttt{p} and returns an
exact integer representing the sign-extended integer value of that
byte. The resulting value is in the range of $[-128, 127]$ inclusive.

\defun{pointer-ref-c-unsigned-char}{procedure}
\texttt{(pointer-ref-c-unsigned-char p i)}

The procedure \texttt{pointer-ref-c-unsigned-char} loads a single byte
located at offset \texttt{i} from the pointer \texttt{p} and returns
an exact integer representing the unsigned integer value of that
byte.  The resulting value is in the range $[0, 255]$ inclusive.


The following example shows the difference between
\texttt{pointer-ref-c-signed-char} and
\texttt{pointer-ref-c-unsigned-char}.


\begin{verbatim}
   > (let ([p (malloc 3)])
       (pointer-set-c-char! p 0 #b01111111)
       (pointer-set-c-char! p 1 #b10000000)
       (pointer-set-c-char! p 2 #b11111111)
       (let ([result
              (list (pointer-ref-c-signed-char p 0)
                    (pointer-ref-c-signed-char p 1)
                    (pointer-ref-c-signed-char p 2)
                    (pointer-ref-c-unsigned-char p 0)
                    (pointer-ref-c-unsigned-char p 1)
                    (pointer-ref-c-unsigned-char p 2))])
         (free p)
         result))
   (127 -128 -1 127 128 255)
\end{verbatim}

\defun{pointer-ref-c-signed-short}{procedure}
\texttt{(pointer-ref-c-signed-short p i)}

The procedure \texttt{pointer-ref-c-signed-short} loads two bytes
located at offsets \texttt{i} and \texttt{(+ i 1)} from the pointer
\texttt{p} and returns an exact integer representing the
sign-extended
integer value of the sequence.  The resulting value is in the range
$[-32768, 32767]$ inclusive.

\defun{pointer-ref-c-unsigned-short}{procedure}
\texttt{(pointer-ref-c-unsigned-short p i)}

The procedure \texttt{pointer-ref-c-unsigned-short} loads two bytes
located at offsets \texttt{i} and \texttt{(+ i 1)} from the pointer
\texttt{p} and returns an exact integer representing the unsigned
integer value of the sequence.  The resulting value is in the range
$[0, 65535]$ inclusive.

\newpage
\defun{pointer-ref-c-signed-int}{procedure}
\texttt{(pointer-ref-c-signed-int p i)}

The procedure \texttt{pointer-ref-c-signed-int} loads four bytes
starting at offset \texttt{i} of pointer \texttt{p} and returns an
exact integer in the range of $[-2^{31},2^{31}-1]$ inclusive.


\defun{pointer-ref-c-unsigned-int}{procedure}
\texttt{(pointer-ref-c-unsigned-int p i)}

The procedure \texttt{pointer-ref-c-unsigned-int} loads four bytes
starting at offset \texttt{i} of pointer \texttt{p} and returns an
exact integer in the range of $[0,2^{32}-1]$ inclusive.


\defun{pointer-ref-c-signed-long}{procedure}
\texttt{(pointer-ref-c-signed-long p i)}

On 64-bit systems, the procedure \texttt{pointer-ref-c-signed-long}
loads eight bytes starting at offset \texttt{i} of pointer
\texttt{p} and returns an integer in the range of
$[-2^{63},2^{63}-1]$ inclusive.  On 32-bit systems, the procedure
\texttt{pointer-ref-c-signed-long} performs the same task as
\texttt{pointer-ref-c-signed-int}. 


\defun{pointer-ref-c-unsigned-long}{procedure}
\texttt{(pointer-ref-c-unsigned-long p i)}

On 64-bit systems, the procedure \texttt{pointer-ref-c-unsigned-long}
loads eight bytes starting at offset \texttt{i} of pointer
\texttt{p} and returns an integer in the range of
$[0,2^{64}-1]$ inclusive.  On 32-bit systems, the procedure
\texttt{pointer-ref-c-unsigned-long} performs the same task as
\texttt{pointer-ref-c-unsigned-int}. 


\defun{pointer-ref-c-float}{procedure}
\texttt{(pointer-ref-c-float p i)}

The procedure \texttt{pointer-ref-c-float} returns the four-byte
float (represented as IEEE-754 single precision floating point
number) stored at offset \texttt{i} of the pointer \texttt{p}.
The value is extended to an IEEE-754 double precision floating
point number that Ikarus uses to represent inexact numbers.

\defun{pointer-ref-c-double}{procedure}
\texttt{(pointer-ref-c-double p i)}

The procedure \texttt{pointer-ref-c-double} returns the eight-byte
float (represented as IEEE-754 double precision floating point
number) stored at offset \texttt{i} of the pointer \texttt{p}.


\defun{pointer-ref-c-pointer}{procedure}
\texttt{(pointer-ref-c-pointer p i)}

The procedure \texttt{pointer-ref-c-pointer} returns the pointer
stored at offset \texttt{i} from the pointer \texttt{p}.  The size
of the pointer (also the number of bytes loaded) depends on the
architecture: it is 4 bytes on 32-bit systems and 8 bytes on 64-bit
systems.
 
\section{\label{sec:foreign-objects}Accessing foreign objects from
Scheme}


\defun{dlopen}{procedure}
\texttt{(dlopen)}\\
\texttt{(dlopen library-name)}\\
\texttt{(dlopen library-name lazy? global?)}

The procedure \texttt{dlopen} takes a string \texttt{library-name}
represented a system library and calls the system procedure
\texttt{dlopen} which dynamically loads the given library into the
running process.  The name of the library is system-dependent and
must include the appropriate suffix (e.g., \texttt{*.so} on Linux,
\texttt{*.dylib} on Darwin and \texttt{*.dll} on Cygwin).  The
\texttt{library-name} may include a full path which identifies the
location of the library, or may be just the name of the library in
which case the system will lookup the library name using the
\texttt{LD\_LIBRARY\_PATH} environment variable.

The argument \texttt{lazy?} specifies how library dependencies are
loaded.  If true, \texttt{dlopen} delays the resolution and loading
of dependent libraries until they are actually used.  If false, all
library dependencies are loaded before the call to \texttt{dlopen}
returns.

The argument \texttt{global?} specifies how the scope of the symbols
exported from the loaded library.  If true, all exported symbols
become part of the running image, and subsequent \texttt{dlsym}
calls may not need to specify the library from which the symbol is
loaded.  If false, the exported symbols are not global and the
library pointer needs to be specified for \texttt{dlsym}.

Calling \texttt{(dlopen library-name)} is equivalent to
\texttt{(dlopen library-name \#f \#f)}.  Calling \texttt{(dlopen)}
without arguments returns a pointer to the current process.

If succesful, \texttt{dlopen} returns a pointer to the external
library which can be used subsequently by \texttt{dlsym} and
\texttt{dlclose}.  If the library cannot be loaded, \texttt{dlopen}
returns \texttt{\#f} and the procedure \texttt{dlerror} can be used
to obtain the cause of the failure.

Consult the \texttt{dlopen(3)} page in your system manual for
further details.

\defun{dlclose}{procedure}
\texttt{(dlclose library-pointer)}

The procedure \texttt{dlclose} is a wrapped around the system
procedure with the same name.  It receives a library pointer
(e.g.,~one obtained from \texttt{dlopen}) and releases the resources
loaded from that library.  Closing a library renders all symbols and
static data structures that the library exports invalid and the
program may crash or corrupt its memory if such symbols are used
after a library is closed.

Most system implementations of dynamic loading  employ reference
counting for \texttt{dlopen} and \texttt{dlclose} in that library
resources are not freed until the number of calls to
\texttt{dlclose} matches the number of calls to \texttt{dlopen}.

The procedure \texttt{dlclose} returns a boolean value indicating
whether the success status of the operation.  If \texttt{dlclose}
returns \texttt{\#f}, the procedure \texttt{dlerror} can be used to
obtain the cause of the error.

Consult the \texttt{dlclose(3)} page in your system manual for
further details.

\defun{dlerror}{procedure}
\texttt{(dlerror)}

If any of the dynamic loading operations (i.e., \texttt{dlopen},
\texttt{dlclose}, \texttt{dlsym}) fails, the cause of the error can
be obtained by calling \texttt{dlerror} which returns a string
describing the error.  The procedure \texttt{dlerror} returns
\texttt{\#f} if there was no dynamic loading error.

Consult the \texttt{dlerror(3)} page in your system manual for
further details.

\defun{dlsym}{procedure}
\texttt{(dlsym library-pointer string)}

The procedure \texttt{dlsym} takes a library pointer (e.g., one
obtained by a call to \texttt{dlopen}) and a string representing the
name of a symbol that the library exports and returns a pointer to
the location of that symbol in memory.  If \texttt{dlsym} fails, it
returns \texttt{\#f} and the cause of the error can be obtained
using the procedure \texttt{dlerror}.

Consult the \texttt{dlsym(3)} page in your system manual for
further details.


\section{\label{sec:callout}Calling out to foreign procedures}

Ikarus provides the means to call out from Scheme to foreign
procedures.  This allows the programmers to extend Ikarus to access
system-specific facilities that is available on the host machine.  

In order to call out to a foreign procedure, one must provide two
pieces of information: the signature of the foreign procedure (e.g.,
its type declaration if it is a \texttt{C} procedure) and the
address of the procedure in memory.  The address of the procedure
can be easily obtained using \texttt{dlsym} if the name of the
procedure and its exporting library are known.  The signature of the
procedure cannot, in general, be obtained dynamically, and therefore
must be hard coded into the program.

The signature of the foreign procedure is required for proper
linkeage between the Scheme system and the foreign system.  Using
the signature, Ikarus determines how Scheme values are converted
into native values, and where (e.g., in which registers and stack
slots) to put these arguments.  The signature also determines where
the returned values are placed and how they are converted from the
system data types to the corresponding Scheme data types.

A procedure's signature is composed of two parts: the return type
and the parameter types.  The return type is a symbol that can be
any one of the type specifiers listed in
Figure~\ref{fig:foreign-types}, page~\pageref{fig:foreign-types}.
The parameter types is a list of type specifier symbols.  The symbol
\texttt{void} can appear as a return type but cannot appear as a
parameter type.



\defun{make-c-callout}{procedure}
\texttt{((make-c-callout return-type parameter-types) native-pointer)}

The procedure \texttt{make-c-callout} is the primary facility for
making foreign procedures callable from Scheme.  It works as
follows.  First, \texttt{make-c-callout} receives two arguments
denoting the signature of the procedure to be called.  It prepares a
bridge that converts from Scheme's calling conventions and data
structures to their foreign counterparts.  It returns a procedure
$p_1$.  Second, the procedure $p_1$ accepts a pointer to a foreign
procedure (e.g., one obtained from \texttt{dlsym}) and returns a
Scheme procedure $p_2$ that encapsulates the foreign procedure.  The
final procedure $p_2$ can be called with as many arguments as the
ones specified in the \texttt{parameter-types}.  The parameters
supplies to $p_2$ must match the types supplied as the
\texttt{parameter-types} according to the ``Valid Scheme types''
column in the table in Figure~\ref{fig:foreign-types}.  The
procedure $p_2$ converts the parameters from Scheme types to native
types, calls the foreign procedure, obtains the result, and converts
it to the appropriate Scheme value (depending on the
\texttt{return-type}).

The interface of \texttt{make-c-callout} is broken down into three
stages in order to accomodate common usage patterns.  Often types, a
function signature can be used by many foreign procedures and
therefore, \texttt{make-c-callout} can be called once per signature
and each signature can be used multiple times.  Similarly,
separating the foreign procedure preparation from parameter passing
allows for preparing the foreign procedure once and calling it many
times. 

The types listed in Figure~\ref{fig:foreign-types} are restricted to
basic types and provide no automatic conversion from composite
Scheme data structures (such as strings, symbols, vectors, and
lists) to native types.  The restriction is intentional in order for
Ikarus to avoid making invalid assumptions about the memory
management of the targeted library.  For example, while Ikarus
\emph{can} convert a Scheme string to a native byte array (e.g.,
using \texttt{string->bytevector} to decode the string, then using
\texttt{malloc} to allocate a temporary buffer, and copying the
bytes from the bytevector to the allocated memory), it cannot decide
when this allocated byte array is no longer needed and should be
freed.  This knowledge is library-dependent and is often
procedure-dependent.  Therefore, Ikarus leaves it to the programmer
to manage all memory related issues.

Outgoing parameters to foreign procedures are checked against the
declared types.  For example, if a callback is prepared to expect a
parameter of type \texttt{signed-int}, only exact integers are
allowed to be passed out.  For integer types, only a fixed number of
bits is used and the remaining bits are ignored.  For floating point
types, the argument is checked to be a Scheme flonum.  No implicit
conversion between exact and inexact numbers is performed.
{
\begin{figure}[b!]
\begin{center}
\begin{tabular}{@{}llll@{}}
\hline
Type specifier & Size  & Valid Scheme types & Corresponding \texttt{C} types\\
\hline 
\texttt{signed-char} & 1 byte & exact integer & \texttt{char}\\
\texttt{unsigned-char} & 1 byte & exact integer & \texttt{unsigned char}\\
\texttt{signed-short} & 2 bytes & exact integer & \texttt{short}\\
\texttt{unsigned-short} & 2 bytes & exact integer & \texttt{unsigned short}\\
\texttt{signed-int} & 4 bytes & exact integer & \texttt{int}\\
\texttt{unsigned-int} & 4 bytes & exact integer & \texttt{unsigned int}\\
\texttt{signed-long} & 4/8 bytes & exact integer & \texttt{long}\\
\texttt{unsigned-long} & 4/8 bytes & exact integer & \texttt{unsigned long}\\
\texttt{float} & 4 bytes & flonum & \texttt{float}\\
\texttt{double} & 8 bytes & flonum & \texttt{double}\\
\texttt{pointer} & 4/8 bytes & pointer & 
\texttt{void*}, \texttt{char*}, \texttt{int*}, \texttt{int**}, \\
&&& \texttt{int(*)(int,int,int)}, etc. \\
\texttt{void} & -- & -- & \texttt{void}\\
\hline
\end{tabular}
\end{center}
\caption{\label{fig:foreign-types}The above table lists valid type
specifiers that can be used in callout and callback signatures.  
Specifiers with ``4/8 bytes'' have size that depends on the system:
it is 4 bytes on 32-bit systems and 8 bytes on 64-bit systems.  The
\texttt{void} specifier can only be used as a return value
specifier to mean ``no useful value is returned''.}
\end{figure}
}


The following example illustrates the use of the
\texttt{make-c-callout} procedure in combination with \texttt{dlopen}
and \texttt{dlsym}.  The session was run on a 32-bit Ikarus running
under Mac OS X 10.4.  First, the \texttt{libc.dylib} foreign library
is loaded and is bound to the variable \texttt{libc}.  Next, we
obtain a pointer to the \texttt{atan} foreign procedure that is
defined in \texttt{libc}.  The native procedure \texttt{atan} takes
a \texttt{double} as an argument and returns a \texttt{double} and
that's the signature that we use for \texttt{make-c-callout}.
Finally, we call the foreign procedure interface with one argument,
\texttt{1.0}, which is a flonum and thus matches the required
parameter type.  The native procedure returns a \texttt{double}
value which is converted to the Scheme flonum with value
\texttt{0.7853981633974483}.

\begin{verbatim}
   > (import (ikarus foreign))
   > (define libc (dlopen "libc.dylib"))
   > libc
   #<pointer #x00100770>
   > (define libc-atan-ptr (dlsym libc "atan"))
   > libc-atan-ptr
   #<pointer #x9006CB1F>
   > (define libc-atan 
       ((make-c-callout 'double '(double)) libc-atan-ptr))
   > libc-atan
   #<procedure>
   > (libc-atan 1.0)
   0.7853981633974483
   > (libc-atan 1)
   Unhandled exception
    Condition components:
       1. &assertion
       2. &who: callout-procedure
       3. &message: "argument does not match type double"
       4. &irritants: (1)
\end{verbatim}


\section{\label{sec:callback}Calling back to Scheme}

In order to provide full interoperability with native procedures,
Ikarus allows native procedures to call back into Scheme just as it
allows Scheme to call out to native procedures.  This is important
for many system libraries that provide graphical user interfaces
with event handling (e.g., Cocoa, GTK+, GLUT, etc.), database
engines (e.g., libsqlite, libmysql, etc.), among others.

The native calling site for the call back is compiled with a
specific callback signature encoding the expected parameter types
and return type.  Therefore, a Scheme procedure used for a call back
must be wrapped with a proper adapter that converts the incoming
parameters from native format to Scheme values as well as convert
the value that the Scheme procedure returns back to native format.
The signature format is similar to the one used for call outs (see
Figure~\ref{fig:foreign-types} on page~\pageref{fig:foreign-types} for
details).


\defun{make-c-callback}{procedure}
\texttt{((make-c-callback return-type parameter-types) scheme-procedure)}

The procedure \texttt{make-c-callback} is similar to the procedure
\texttt{make-c-callout} except that it provides a bridge from native
procedures back into Scheme.  While the procedure
\texttt{make-c-callout} takes a native pointer and returns a Scheme
procedure, \texttt{make-c-callback} takes a Scheme procedure and
returns a native pointer.  The native pointer can be called by
foreign procedures.  The native parameters are converted to Scheme
data (according to \texttt{parameter-types}), the Scheme procedure
is called with these parameters, and the returned value is converted
back into native format (according to \texttt{return-type}) before
control returns to the native call site.


Note that the native procedure pointer obtained from
\texttt{make-c-callback} is indistinguishable from other native
procedures that are obtained using \texttt{dlsym} or similar means.
In particular, such native pointers can be passed to
\texttt{make-c-callout} resulting in a Scheme procedure that calls out
to the native procedure that in turn calls back into Scheme.  The
following segment illustrates a very inefficient way of extracting
the lowermost 32 bits from an exact integer.

\begin{verbatim}
   > (format "~x"
       (((make-c-callout 'unsigned-int '(unsigned-int))
         ((make-c-callback 'unsigned-int '(unsigned-int)) 
          values))
        #xfedcba09876543210fedcba09876543210))
   "76543210"
\end{verbatim}

\BoxedText{Caveat emptor:}{Preparing each call out and call back
procedure leaks a small amount of memory.  This is because the
system cannot track such pointers that go into native code
(which may retain such pointers indefinitely).  Use judiciously.}


\nocite{ghuloum-implicit}
\nocite{ghuloum-generation}




\appendix
\chapter{Missing Features}

Ikarus does not fully conform to \rnrs{6} yet.  Although it
implements most of \rnrs{6}'s macros and procedures, some are still
missing.  This section summarizes the set of missing features and
procedures.


\begin{itemize}
\item \texttt{number->string} does not accept the third argument
(precision).  Similarly, \texttt{string->number} and the reader do
not recognize the \texttt{|p} notation. 


\item The following procedures are missing from \texttt{(rnrs arithmetic
bitwise)}:
\begin{Verbatim}
bitwise-reverse-bit-field bitwise-rotate-bit-field 
\end{Verbatim}

\item The following procedures are missing from \texttt{(rnrs arithmetic
fixnum)}:
\begin{Verbatim}
fxreverse-bit-field   fxrotate-bit-field   
\end{Verbatim}


\item The following procedures are missing from \texttt{(rnrs hashtables)}:
\begin{Verbatim}
equal-hash
\end{Verbatim}

\item The following procedures are missing from \texttt{(rnrs io ports)}:
\begin{Verbatim}
make-custom-binary-input/output-port    
make-custom-textual-input/output-port 
open-file-input/output-port
\end{Verbatim}

\end{itemize}

\newpage

\backmatter
%\appendix
\phantomsection
%\addcontentsline{toc}{chapter}{Bibliogaraphy}
\addcontentsline{toc}{chapter}{\bibname}
\bibliographystyle{plain}
\bibliography{ikarus-scheme-users-guide}
\newpage
\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
\end{document}