xref: /dports/lang/guile/guile-3.0.7/doc/ref/guile.info-1

This is guile.info, produced by makeinfo version 6.7 from guile.texi.

This manual documents Guile version 3.0.7.

   Copyright (C) 1996-1997, 2000-2005, 2009-2021 Free Software
Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
copy of the license is included in the section entitled “GNU Free
Documentation License.”
INFO-DIR-SECTION The Algorithmic Language Scheme
START-INFO-DIR-ENTRY
* Guile Reference: (guile).     The Guile reference manual.
END-INFO-DIR-ENTRY


File: guile.info,  Node: Top,  Next: Preface,  Prev: (dir),  Up: (dir)

The Guile Reference Manual
**************************

This manual documents Guile version 3.0.7.

   Copyright (C) 1996-1997, 2000-2005, 2009-2021 Free Software
Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
copy of the license is included in the section entitled “GNU Free
Documentation License.”

* Menu:


* Preface::
* Introduction::

* Hello Guile!::
* Hello Scheme!::

* Programming in Scheme::
* Programming in C::

* API Reference::

* Guile Modules::

* GOOPS::

* Guile Implementation::

Appendices

* GNU Free Documentation License::  The license of this manual.

Indices

* Concept Index::
* Procedure Index::
* Variable Index::
* Type Index::
* R5RS Index::


File: guile.info,  Node: Preface,  Next: Introduction,  Up: Top

Preface
*******

This manual describes how to use Guile, GNU’s Ubiquitous Intelligent
Language for Extensions.  It relates particularly to Guile version
3.0.7.

* Menu:

* Contributors::
* Guile License::


File: guile.info,  Node: Contributors,  Next: Guile License,  Up: Preface

Contributors to this Manual
===========================

Like Guile itself, the Guile reference manual is a living entity, cared
for by many people over a long period of time.  As such, it is hard to
identify individuals of whom to say “yes, this single person wrote the
manual.”

   Still, among the many contributions, some caretakers stand out.
First among them is Neil Jerram, who has worked on this document for
over ten years.  Neil’s attention both to detail and to the big picture
have made a real difference in the understanding of a generation of
Guile hackers.

   Next we should note Marius Vollmer’s effect on this document.  Marius
maintained Guile during a period in which Guile’s API was clarified—put
to the fire, so to speak—and he had the good sense to effect the same
change on the manual.

   Martin Grabmueller made substantial contributions throughout the
manual in preparation for the Guile 1.6 release, including filling out a
lot of the documentation of Scheme data types, control mechanisms and
procedures.  In addition, he wrote the documentation for Guile’s SRFI
modules and modules associated with the Guile REPL.

   Ludovic Courtès and Andy Wingo, who co-maintain Guile since 2010,
along with Mark Weaver, have also made their dent in the manual, writing
documentation for new modules and subsystems that arrived with Guile
2.0.  Ludovic, Andy, and Mark are also responsible for ensuring that the
existing text retains its relevance as Guile evolves.  *Note Reporting
Bugs::, for more information on reporting problems in this manual.

   The content for the first versions of this manual incorporated and
was inspired by documents from Aubrey Jaffer, author of the SCM system
on which Guile was based, and from Tom Lord, Guile’s first maintainer.
Although most of this text has been rewritten, all of it was important,
and some of the structure remains.

   The manual for the first versions of Guile were largely written,
edited, and compiled by Mark Galassi and Jim Blandy.  In particular, Jim
wrote the original tutorial on Guile’s data representation and the C API
for accessing Guile objects.

   Significant portions were also contributed by Thien-Thi Nguyen, Kevin
Ryde, Mikael Djurfeldt, Christian Lynbech, Julian Graham, Gary Houston,
Tim Pierce, and a few dozen more.  You, reader, are most welcome to join
their esteemed ranks.  Visit Guile’s web site at
<http://www.gnu.org/software/guile/> to find out how to get involved.


File: guile.info,  Node: Guile License,  Prev: Contributors,  Up: Preface

The Guile License
=================

Guile is Free Software.  Guile is copyrighted, not public domain, and
there are restrictions on its distribution or redistribution, but these
restrictions are designed to permit everything a cooperating person
would want to do.

   • The Guile library (libguile) and supporting files are published
     under the terms of the GNU Lesser General Public License version 3
     or later.  See the files ‘COPYING.LESSER’ and ‘COPYING’.

   • The Guile readline module is published under the terms of the GNU
     General Public License version 3 or later.  See the file ‘COPYING’.

   • The manual you’re now reading is published under the terms of the
     GNU Free Documentation License (*note GNU Free Documentation
     License::).

   C code linking to the Guile library is subject to terms of that
library.  Basically such code may be published on any terms, provided
users can re-link against a new or modified version of Guile.

   C code linking to the Guile readline module is subject to the terms
of that module.  Basically such code must be published on Free terms.

   Scheme level code written to be run by Guile (but not derived from
Guile itself) is not restricted in any way, and may be published on any
terms.  We encourage authors to publish on Free terms.

   You must be aware there is no warranty whatsoever for Guile.  This is
described in full in the licenses.


File: guile.info,  Node: Introduction,  Next: Hello Guile!,  Prev: Preface,  Up: Top

1 Introduction
**************

Guile is an implementation of the Scheme programming language.  Scheme
(<http://schemers.org/>) is an elegant and conceptually simple dialect
of Lisp, originated by Guy Steele and Gerald Sussman, and since evolved
by the series of reports known as RnRS (the Revised^n Reports on
Scheme).

   Unlike, for example, Python or Perl, Scheme has no benevolent
dictator.  There are many Scheme implementations, with different
characteristics and with communities and academic activities around
them, and the language develops as a result of the interplay between
these.  Guile’s particular characteristics are that

   • it is easy to combine with other code written in C
   • it has a historical and continuing connection with the GNU Project
   • it emphasizes interactive and incremental programming
   • it actually supports several languages, not just Scheme.

The next few sections explain what we mean by these points.  The
sections after that cover how you can obtain and install Guile, and the
typographical conventions that we use in this manual.

* Menu:

* Guile and Scheme::
* Combining with C::
* Guile and the GNU Project::
* Interactive Programming::
* Supporting Multiple Languages::
* Obtaining and Installing Guile::
* Organisation of this Manual::
* Typographical Conventions::


File: guile.info,  Node: Guile and Scheme,  Next: Combining with C,  Up: Introduction

1.1 Guile and Scheme
====================

Guile implements Scheme as described in the Revised^5 Report on the
Algorithmic Language Scheme (usually known as R5RS), providing clean and
general data and control structures.  Guile goes beyond the rather
austere language presented in R5RS, extending it with a module system,
full access to POSIX system calls, networking support, multiple threads,
dynamic linking, a foreign function call interface, powerful string
processing, and many other features needed for programming in the real
world.

   In 2007, the Scheme community agreed upon and published R6RS, a
significant installment in the RnRS series.  R6RS expands the core
Scheme language, and standardises many non-core functions that
implementations—including Guile—have previously done in different ways.
Over time, Guile has been updated to incorporate almost all of the
features of R6RS, and to adjust some existing features to conform to the
R6RS specification.  *Note R6RS Support::, for full details.

   In parallel to official standardization efforts, the SRFI process
(<http://srfi.schemers.org/>) standardises interfaces for many practical
needs, such as multithreaded programming and multidimensional arrays.
Guile supports many SRFIs, as documented in detail in *note SRFI
Support::.

   The process that led to the R6RS standard brought a split in the
Scheme community to the surface.  The implementors that wrote R6RS
considered that it was impossible to write useful, portable programs in
R5RS, and that only an ambitious standard could solve this problem.
However, part of the Scheme world saw the R6RS effort as too broad, and
as having included some components that would never be adopted by more
minimalistic Scheme implementations.  This second group succeeded in
taking control of the official Scheme standardization track and in 2013
released a more limited R7RS, essentially consisting of R5RS, plus a
module system.  Guile supports R7RS also.  *Note R7RS Support::.

   With R6RS and R7RS, the unified Scheme standardization process
appears to have more or less run its course.  There will continue to be
more code written in terms of both systems, and modules defined using
the SRFI process, and Guile will support both.  However for future
directions, Guile takes inspiration from other related language
communities: Racket, Clojure, Concurrent ML, and so on.

   In summary, Guile supports writing and running code written to the
R5RS, R6RS, and R7RS Scheme standards, and also supports a number of
SRFI modules.  However for most users, until a need for
cross-implementation portability has been identified, we recommend using
the parts of Guile that are useful in solving the problem at hand,
regardless of whether they proceed from a standard or whether they are
Guile-specific.


File: guile.info,  Node: Combining with C,  Next: Guile and the GNU Project,  Prev: Guile and Scheme,  Up: Introduction

1.2 Combining with C Code
=========================

Like a shell, Guile can run interactively—reading expressions from the
user, evaluating them, and displaying the results—or as a script
interpreter, reading and executing Scheme code from a file.  Guile also
provides an object library, “libguile”, that allows other applications
to easily incorporate a complete Scheme interpreter.  An application can
then use Guile as an extension language, a clean and powerful
configuration language, or as multi-purpose “glue”, connecting
primitives provided by the application.  It is easy to call Scheme code
from C code and vice versa, giving the application designer full control
of how and when to invoke the interpreter.  Applications can add new
functions, data types, control structures, and even syntax to Guile,
creating a domain-specific language tailored to the task at hand, but
based on a robust language design.

   This kind of combination is helped by four aspects of Guile’s design
and history.  First is that Guile has always been targeted as an
extension language.  Hence its C API has always been of great
importance, and has been developed accordingly.  Second and third are
rather technical points—that Guile uses conservative garbage collection,
and that it implements the Scheme concept of continuations by copying
and reinstating the C stack—but whose practical consequence is that most
existing C code can be glued into Guile as is, without needing
modifications to cope with strange Scheme execution flows.  Last is the
module system, which helps extensions to coexist without stepping on
each others’ toes.

   Guile’s module system allows one to break up a large program into
manageable sections with well-defined interfaces between them.  Modules
may contain a mixture of interpreted and compiled code; Guile can use
either static or dynamic linking to incorporate compiled code.  Modules
also encourage developers to package up useful collections of routines
for general distribution; as of this writing, one can find Emacs
interfaces, database access routines, compilers, GUI toolkit interfaces,
and HTTP client functions, among others.


File: guile.info,  Node: Guile and the GNU Project,  Next: Interactive Programming,  Prev: Combining with C,  Up: Introduction

1.3 Guile and the GNU Project
=============================

Guile was conceived by the GNU Project following the fantastic success
of Emacs Lisp as an extension language within Emacs.  Just as Emacs Lisp
allowed complete and unanticipated applications to be written within the
Emacs environment, the idea was that Guile should do the same for other
GNU Project applications.  This remains true today.

   The idea of extensibility is closely related to the GNU project’s
primary goal, that of promoting software freedom.  Software freedom
means that people receiving a software package can modify or enhance it
to their own desires, including in ways that may not have occurred at
all to the software’s original developers.  For programs written in a
compiled language like C, this freedom covers modifying and rebuilding
the C code; but if the program also provides an extension language, that
is usually a much friendlier and lower-barrier-of-entry way for the user
to start making their own changes.

   Guile is now used by GNU project applications such as AutoGen,
Lilypond, Denemo, Mailutils, TeXmacs and Gnucash, and we hope that there
will be many more in future.


File: guile.info,  Node: Interactive Programming,  Next: Supporting Multiple Languages,  Prev: Guile and the GNU Project,  Up: Introduction

1.4 Interactive Programming
===========================

Non-free software has no interest in its users being able to see how it
works.  They are supposed to just accept it, or to report problems and
hope that the source code owners will choose to work on them.

   Free software aims to work reliably just as much as non-free software
does, but it should also empower its users by making its workings
available.  This is useful for many reasons, including education,
auditing and enhancements, as well as for debugging problems.

   The ideal free software system achieves this by making it easy for
interested users to see the source code for a feature that they are
using, and to follow through that source code step-by-step, as it runs.
In Emacs, good examples of this are the source code hyperlinks in the
help system, and ‘edebug’.  Then, for bonus points and maximising the
ability for the user to experiment quickly with code changes, the system
should allow parts of the source code to be modified and reloaded into
the running program, to take immediate effect.

   Guile is designed for this kind of interactive programming, and this
distinguishes it from many Scheme implementations that instead
prioritise running a fixed Scheme program as fast as possible—because
there are tradeoffs between performance and the ability to modify parts
of an already running program.  There are faster Schemes than Guile, but
Guile is a GNU project and so prioritises the GNU vision of programming
freedom and experimentation.


File: guile.info,  Node: Supporting Multiple Languages,  Next: Obtaining and Installing Guile,  Prev: Interactive Programming,  Up: Introduction

1.5 Supporting Multiple Languages
=================================

Since the 2.0 release, Guile’s architecture supports compiling any
language to its core virtual machine bytecode, and Scheme is just one of
the supported languages.  Other supported languages are Emacs Lisp,
ECMAScript (commonly known as Javascript) and Brainfuck, and work is
under discussion for Lua, Ruby and Python.

   This means that users can program applications which use Guile in the
language of their choice, rather than having the tastes of the
application’s author imposed on them.


File: guile.info,  Node: Obtaining and Installing Guile,  Next: Organisation of this Manual,  Prev: Supporting Multiple Languages,  Up: Introduction

1.6 Obtaining and Installing Guile
==================================

Guile can be obtained from the main GNU archive site <ftp://ftp.gnu.org>
or any of its mirrors.  The file will be named guile-VERSION.tar.gz.
The current version is 3.0.7, so the file you should grab is:

   <ftp://ftp.gnu.org/gnu/guile/guile-3.0.7.tar.gz>

   To unbundle Guile use the instruction

     zcat guile-3.0.7.tar.gz | tar xvf -

which will create a directory called ‘guile-3.0.7’ with all the sources.
You can look at the file ‘INSTALL’ for detailed instructions on how to
build and install Guile, but you should be able to just do

     cd guile-3.0.7
     ./configure
     make
     make install

   This will install the Guile executable ‘guile’, the Guile library
‘libguile’ and various associated header files and support libraries.
It will also install the Guile reference manual.

   Since this manual frequently refers to the Scheme “standard”, also
known as R5RS, or the “Revised^5 Report on the Algorithmic Language
Scheme”, we have included the report in the Guile distribution; see
*note Introduction: (r5rs)Top.  This will also be installed in your info
directory.


File: guile.info,  Node: Organisation of this Manual,  Next: Typographical Conventions,  Prev: Obtaining and Installing Guile,  Up: Introduction

1.7 Organisation of this Manual
===============================

The rest of this manual is organised into the following chapters.

*Chapter 2: Hello Guile!*
     A whirlwind tour shows how Guile can be used interactively and as a
     script interpreter, how to link Guile into your own applications,
     and how to write modules of interpreted and compiled code for use
     with Guile.  Everything introduced here is documented again and in
     full by the later parts of the manual.

*Chapter 3: Hello Scheme!*
     For readers new to Scheme, this chapter provides an introduction to
     the basic ideas of the Scheme language.  This material would apply
     to any Scheme implementation and so does not make reference to
     anything Guile-specific.

*Chapter 4: Programming in Scheme*
     Provides an overview of programming in Scheme with Guile.  It
     covers how to invoke the ‘guile’ program from the command-line and
     how to write scripts in Scheme.  It also introduces the extensions
     that Guile offers beyond standard Scheme.

*Chapter 5: Programming in C*
     Provides an overview of how to use Guile in a C program.  It
     discusses the fundamental concepts that you need to understand to
     access the features of Guile, such as dynamic types and the garbage
     collector.  It explains in a tutorial like manner how to define new
     data types and functions for the use by Scheme programs.

*Chapter 6: Guile API Reference*
     This part of the manual documents the Guile API in
     functionality-based groups with the Scheme and C interfaces
     presented side by side.

*Chapter 7: Guile Modules*
     Describes some important modules, distributed as part of the Guile
     distribution, that extend the functionality provided by the Guile
     Scheme core.

*Chapter 8: GOOPS*
     Describes GOOPS, an object oriented extension to Guile that
     provides classes, multiple inheritance and generic functions.


File: guile.info,  Node: Typographical Conventions,  Prev: Organisation of this Manual,  Up: Introduction

1.8 Typographical Conventions
=============================

In examples and procedure descriptions and all other places where the
evaluation of Scheme expression is shown, we use some notation for
denoting the output and evaluation results of expressions.

   The symbol ‘⇒’ is used to tell which value is returned by an
evaluation:

     (+ 1 2)
     ⇒ 3

   Some procedures produce some output besides returning a value.  This
is denoted by the symbol ‘⊣’.

     (begin (display 1) (newline) 'hooray)
     ⊣ 1
     ⇒ hooray

   As you can see, this code prints ‘1’ (denoted by ‘⊣’), and returns
‘hooray’ (denoted by ‘⇒’).


File: guile.info,  Node: Hello Guile!,  Next: Hello Scheme!,  Prev: Introduction,  Up: Top

2 Hello Guile!
**************

This chapter presents a quick tour of all the ways that Guile can be
used.  There are additional examples in the ‘examples/’ directory in the
Guile source distribution.  It also explains how best to report any
problems that you find.

   The following examples assume that Guile has been installed in
‘/usr/local/’.

* Menu:

* Running Guile Interactively::
* Running Guile Scripts::
* Linking Guile into Programs::
* Writing Guile Extensions::
* Using the Guile Module System::
* Reporting Bugs::


File: guile.info,  Node: Running Guile Interactively,  Next: Running Guile Scripts,  Up: Hello Guile!

2.1 Running Guile Interactively
===============================

In its simplest form, Guile acts as an interactive interpreter for the
Scheme programming language, reading and evaluating Scheme expressions
the user enters from the terminal.  Here is a sample interaction between
Guile and a user; the user’s input appears after the ‘$’ and
‘scheme@(guile-user)>’ prompts:

     $ guile
     scheme@(guile-user)> (+ 1 2 3)                ; add some numbers
     $1 = 6
     scheme@(guile-user)> (define (factorial n)    ; define a function
                            (if (zero? n) 1 (* n (factorial (- n 1)))))
     scheme@(guile-user)> (factorial 20)
     $2 = 2432902008176640000
     scheme@(guile-user)> (getpwnam "root")        ; look in /etc/passwd
     $3 = #("root" "x" 0 0 "root" "/root" "/bin/bash")
     scheme@(guile-user)> C-d
     $


File: guile.info,  Node: Running Guile Scripts,  Next: Linking Guile into Programs,  Prev: Running Guile Interactively,  Up: Hello Guile!

2.2 Running Guile Scripts
=========================

Like AWK, Perl, or any shell, Guile can interpret script files.  A Guile
script is simply a file of Scheme code with some extra information at
the beginning which tells the operating system how to invoke Guile, and
then tells Guile how to handle the Scheme code.

   Here is a trivial Guile script.  *Note Guile Scripting::, for more
details.

     #!/usr/local/bin/guile -s
     !#
     (display "Hello, world!")
     (newline)


File: guile.info,  Node: Linking Guile into Programs,  Next: Writing Guile Extensions,  Prev: Running Guile Scripts,  Up: Hello Guile!

2.3 Linking Guile into Programs
===============================

The Guile interpreter is available as an object library, to be linked
into applications using Scheme as a configuration or extension language.

   Here is ‘simple-guile.c’, source code for a program that will produce
a complete Guile interpreter.  In addition to all usual functions
provided by Guile, it will also offer the function ‘my-hostname’.

     #include <stdlib.h>
     #include <libguile.h>

     static SCM
     my_hostname (void)
     {
       char *s = getenv ("HOSTNAME");
       if (s == NULL)
         return SCM_BOOL_F;
       else
         return scm_from_locale_string (s);
     }

     static void
     inner_main (void *data, int argc, char **argv)
     {
       scm_c_define_gsubr ("my-hostname", 0, 0, 0, my_hostname);
       scm_shell (argc, argv);
     }

     int
     main (int argc, char **argv)
     {
       scm_boot_guile (argc, argv, inner_main, 0);
       return 0; /* never reached */
     }

   When Guile is correctly installed on your system, the above program
can be compiled and linked like this:

     $ gcc -o simple-guile simple-guile.c \
         `pkg-config --cflags --libs guile-3.0`

   When it is run, it behaves just like the ‘guile’ program except that
you can also call the new ‘my-hostname’ function.

     $ ./simple-guile
     scheme@(guile-user)> (+ 1 2 3)
     $1 = 6
     scheme@(guile-user)> (my-hostname)
     "burns"


File: guile.info,  Node: Writing Guile Extensions,  Next: Using the Guile Module System,  Prev: Linking Guile into Programs,  Up: Hello Guile!

2.4 Writing Guile Extensions
============================

You can link Guile into your program and make Scheme available to the
users of your program.  You can also link your library into Guile and
make its functionality available to all users of Guile.

   A library that is linked into Guile is called an “extension”, but it
really just is an ordinary object library.

   The following example shows how to write a simple extension for Guile
that makes the ‘j0’ function available to Scheme code.

     #include <math.h>
     #include <libguile.h>

     SCM
     j0_wrapper (SCM x)
     {
       return scm_from_double (j0 (scm_to_double (x)));
     }

     void
     init_bessel ()
     {
       scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper);
     }

   This C source file needs to be compiled into a shared library.  Here
is how to do it on GNU/Linux:

     gcc `pkg-config --cflags guile-3.0` \
       -shared -o libguile-bessel.so -fPIC bessel.c

   For creating shared libraries portably, we recommend the use of GNU
Libtool (*note Introduction: (libtool)Top.).

   A shared library can be loaded into a running Guile process with the
function ‘load-extension’.  The ‘j0’ is then immediately available:

     $ guile
     scheme@(guile-user)> (load-extension "./libguile-bessel" "init_bessel")
     scheme@(guile-user)> (j0 2)
     $1 = 0.223890779141236

   For more on how to install your extension, *note Installing Site
Packages::.


File: guile.info,  Node: Using the Guile Module System,  Next: Reporting Bugs,  Prev: Writing Guile Extensions,  Up: Hello Guile!

2.5 Using the Guile Module System
=================================

Guile has support for dividing a program into “modules”.  By using
modules, you can group related code together and manage the composition
of complete programs from largely independent parts.

   For more details on the module system beyond this introductory
material, *Note Modules::.

* Menu:

* Using Modules::
* Writing new Modules::
* Putting Extensions into Modules::


File: guile.info,  Node: Using Modules,  Next: Writing new Modules,  Up: Using the Guile Module System

2.5.1 Using Modules
-------------------

Guile comes with a lot of useful modules, for example for string
processing or command line parsing.  Additionally, there exist many
Guile modules written by other Guile hackers, but which have to be
installed manually.

   Here is a sample interactive session that shows how to use the
‘(ice-9 popen)’ module which provides the means for communicating with
other processes over pipes together with the ‘(ice-9 rdelim)’ module
that provides the function ‘read-line’.

     $ guile
     scheme@(guile-user)> (use-modules (ice-9 popen))
     scheme@(guile-user)> (use-modules (ice-9 rdelim))
     scheme@(guile-user)> (define p (open-input-pipe "ls -l"))
     scheme@(guile-user)> (read-line p)
     $1 = "total 30"
     scheme@(guile-user)> (read-line p)
     $2 = "drwxr-sr-x    2 mgrabmue mgrabmue     1024 Mar 29 19:57 CVS"


File: guile.info,  Node: Writing new Modules,  Next: Putting Extensions into Modules,  Prev: Using Modules,  Up: Using the Guile Module System

2.5.2 Writing new Modules
-------------------------

You can create new modules using the syntactic form ‘define-module’.
All definitions following this form until the next ‘define-module’ are
placed into the new module.

   One module is usually placed into one file, and that file is
installed in a location where Guile can automatically find it.  The
following session shows a simple example.

     $ cat /usr/local/share/guile/site/foo/bar.scm

     (define-module (foo bar)
       #:export (frob))

     (define (frob x) (* 2 x))

     $ guile
     scheme@(guile-user)> (use-modules (foo bar))
     scheme@(guile-user)> (frob 12)
     $1 = 24

   For more on how to install your module, *note Installing Site
Packages::.


File: guile.info,  Node: Putting Extensions into Modules,  Prev: Writing new Modules,  Up: Using the Guile Module System

2.5.3 Putting Extensions into Modules
-------------------------------------

In addition to Scheme code you can also put things that are defined in C
into a module.

   You do this by writing a small Scheme file that defines the module
and call ‘load-extension’ directly in the body of the module.

     $ cat /usr/local/share/guile/site/math/bessel.scm

     (define-module (math bessel)
       #:export (j0))

     (load-extension "libguile-bessel" "init_bessel")

     $ file /usr/local/lib/guile/3.0/extensions/libguile-bessel.so
     ... ELF 32-bit LSB shared object ...
     $ guile
     scheme@(guile-user)> (use-modules (math bessel))
     scheme@(guile-user)> (j0 2)
     $1 = 0.223890779141236

   *Note Foreign Extensions::, for more information.


File: guile.info,  Node: Reporting Bugs,  Prev: Using the Guile Module System,  Up: Hello Guile!

2.6 Reporting Bugs
==================

Any problems with the installation should be reported to
<bug-guile@gnu.org>.

   If you find a bug in Guile, please report it to the Guile developers,
so they can fix it.  They may also be able to suggest workarounds when
it is not possible for you to apply the bug-fix or install a new version
of Guile yourself.

   Before sending in bug reports, please check with the following list
that you really have found a bug.

   • Whenever documentation and actual behavior differ, you have
     certainly found a bug, either in the documentation or in the
     program.

   • When Guile crashes, it is a bug.

   • When Guile hangs or takes forever to complete a task, it is a bug.

   • When calculations produce wrong results, it is a bug.

   • When Guile signals an error for valid Scheme programs, it is a bug.

   • When Guile does not signal an error for invalid Scheme programs, it
     may be a bug, unless this is explicitly documented.

   • When some part of the documentation is not clear and does not make
     sense to you even after re-reading the section, it is a bug.

   Before reporting the bug, check whether any programs you have loaded
into Guile, including your ‘.guile’ file, set any variables that may
affect the functioning of Guile.  Also, see whether the problem happens
in a freshly started Guile without loading your ‘.guile’ file (start
Guile with the ‘-q’ switch to prevent loading the init file).  If the
problem does _not_ occur then, you must report the precise contents of
any programs that you must load into Guile in order to cause the problem
to occur.

   When you write a bug report, please make sure to include as much of
the information described below in the report.  If you can’t figure out
some of the items, it is not a problem, but the more information we get,
the more likely we can diagnose and fix the bug.

   • The version number of Guile.  You can get this information from
     invoking ‘guile --version’ at your shell, or calling ‘(version)’
     from within Guile.

   • Your machine type, as determined by the ‘config.guess’ shell
     script.  If you have a Guile checkout, this file is located in
     ‘build-aux’; otherwise you can fetch the latest version from
     <http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD>.

          $ build-aux/config.guess
          x86_64-unknown-linux-gnu

   • If you installed Guile from a binary package, the version of that
     package.  On systems that use RPM, use ‘rpm -qa | grep guile’.  On
     systems that use DPKG, ‘dpkg -l | grep guile’.

   • If you built Guile yourself, the build configuration that you used:

          $ ./config.status --config
          '--enable-error-on-warning' '--disable-deprecated'...

   • A complete description of how to reproduce the bug.

     If you have a Scheme program that produces the bug, please include
     it in the bug report.  If your program is too big to include,
     please try to reduce your code to a minimal test case.

     If you can reproduce your problem at the REPL, that is best.  Give
     a transcript of the expressions you typed at the REPL.

   • A description of the incorrect behavior.  For example, "The Guile
     process gets a fatal signal," or, "The resulting output is as
     follows, which I think is wrong."

     If the manifestation of the bug is a Guile error message, it is
     important to report the precise text of the error message, and a
     backtrace showing how the Scheme program arrived at the error.
     This can be done using the ‘,backtrace’ command in Guile’s
     debugger.

   If your bug causes Guile to crash, additional information from a
low-level debugger such as GDB might be helpful.  If you have built
Guile yourself, you can run Guile under GDB via the
‘meta/gdb-uninstalled-guile’ script.  Instead of invoking Guile as
usual, invoke the wrapper script, type ‘run’ to start the process, then
‘backtrace’ when the crash comes.  Include that backtrace in your
report.


File: guile.info,  Node: Hello Scheme!,  Next: Programming in Scheme,  Prev: Hello Guile!,  Up: Top

3 Hello Scheme!
***************

In this chapter, we introduce the basic concepts that underpin the
elegance and power of the Scheme language.

   Readers who already possess a background knowledge of Scheme may
happily skip this chapter.  For the reader who is new to the language,
however, the following discussions on data, procedures, expressions and
closure are designed to provide a minimum level of Scheme understanding
that is more or less assumed by the chapters that follow.

   The style of this introductory material aims about halfway between
the terse precision of R5RS and the discursiveness of existing Scheme
tutorials.  For pointers to useful Scheme resources on the web, please
see *note Further Reading::.

* Menu:

* About Data::                  Latent typing, types, values and variables.
* About Procedures::            The representation and use of procedures.
* About Expressions::           All kinds of expressions and their meaning.
* About Closure::               Closure, scoping and environments.
* Further Reading::             Where to find out more about Scheme.


File: guile.info,  Node: About Data,  Next: About Procedures,  Up: Hello Scheme!

3.1 Data Types, Values and Variables
====================================

This section discusses the representation of data types and values, what
it means for Scheme to be a “latently typed” language, and the role of
variables.  We conclude by introducing the Scheme syntaxes for defining
a new variable, and for changing the value of an existing variable.

* Menu:

* Latent Typing::               Scheme as a "latently typed" language.
* Values and Variables::        About data types, values and variables.
* Definition::                  Defining variables and setting their values.


File: guile.info,  Node: Latent Typing,  Next: Values and Variables,  Up: About Data

3.1.1 Latent Typing
-------------------

The term “latent typing” is used to describe a computer language, such
as Scheme, for which you cannot, _in general_, simply look at a
program’s source code and determine what type of data will be associated
with a particular variable, or with the result of a particular
expression.

   Sometimes, of course, you _can_ tell from the code what the type of
an expression will be.  If you have a line in your program that sets the
variable ‘x’ to the numeric value 1, you can be certain that,
immediately after that line has executed (and in the absence of multiple
threads), ‘x’ has the numeric value 1.  Or if you write a procedure that
is designed to concatenate two strings, it is likely that the rest of
your application will always invoke this procedure with two string
parameters, and quite probable that the procedure would go wrong in some
way if it was ever invoked with parameters that were not both strings.

   Nevertheless, the point is that there is nothing in Scheme which
requires the procedure parameters always to be strings, or ‘x’ always to
hold a numeric value, and there is no way of declaring in your program
that such constraints should always be obeyed.  In the same vein, there
is no way to declare the expected type of a procedure’s return value.

   Instead, the types of variables and expressions are only known – in
general – at run time.  If you _need_ to check at some point that a
value has the expected type, Scheme provides run time procedures that
you can invoke to do so.  But equally, it can be perfectly valid for two
separate invocations of the same procedure to specify arguments with
different types, and to return values with different types.

   The next subsection explains what this means in practice, for the
ways that Scheme programs use data types, values and variables.


File: guile.info,  Node: Values and Variables,  Next: Definition,  Prev: Latent Typing,  Up: About Data

3.1.2 Values and Variables
--------------------------

Scheme provides many data types that you can use to represent your data.
Primitive types include characters, strings, numbers and procedures.
Compound types, which allow a group of primitive and compound values to
be stored together, include lists, pairs, vectors and multi-dimensional
arrays.  In addition, Guile allows applications to define their own data
types, with the same status as the built-in standard Scheme types.

   As a Scheme program runs, values of all types pop in and out of
existence.  Sometimes values are stored in variables, but more commonly
they pass seamlessly from being the result of one computation to being
one of the parameters for the next.

   Consider an example.  A string value is created because the
interpreter reads in a literal string from your program’s source code.
Then a numeric value is created as the result of calculating the length
of the string.  A second numeric value is created by doubling the
calculated length.  Finally the program creates a list with two elements
– the doubled length and the original string itself – and stores this
list in a program variable.

   All of the values involved here – in fact, all values in Scheme –
carry their type with them.  In other words, every value “knows,” at
runtime, what kind of value it is.  A number, a string, a list,
whatever.

   A variable, on the other hand, has no fixed type.  A variable – ‘x’,
say – is simply the name of a location – a box – in which you can store
any kind of Scheme value.  So the same variable in a program may hold a
number at one moment, a list of procedures the next, and later a pair of
strings.  The “type” of a variable – insofar as the idea is meaningful
at all – is simply the type of whatever value the variable happens to be
storing at a particular moment.


File: guile.info,  Node: Definition,  Prev: Values and Variables,  Up: About Data

3.1.3 Defining and Setting Variables
------------------------------------

To define a new variable, you use Scheme’s ‘define’ syntax like this:

     (define VARIABLE-NAME VALUE)

   This makes a new variable called VARIABLE-NAME and stores VALUE in it
as the variable’s initial value.  For example:

     ;; Make a variable `x' with initial numeric value 1.
     (define x 1)

     ;; Make a variable `organization' with an initial string value.
     (define organization "Free Software Foundation")

   (In Scheme, a semicolon marks the beginning of a comment that
continues until the end of the line.  So the lines beginning ‘;;’ are
comments.)

   Changing the value of an already existing variable is very similar,
except that ‘define’ is replaced by the Scheme syntax ‘set!’, like this:

     (set! VARIABLE-NAME NEW-VALUE)

   Remember that variables do not have fixed types, so NEW-VALUE may
have a completely different type from whatever was previously stored in
the location named by VARIABLE-NAME.  Both of the following examples are
therefore correct.

     ;; Change the value of `x' to 5.
     (set! x 5)

     ;; Change the value of `organization' to the FSF's street number.
     (set! organization 545)

   In these examples, VALUE and NEW-VALUE are literal numeric or string
values.  In general, however, VALUE and NEW-VALUE can be any Scheme
expression.  Even though we have not yet covered the forms that Scheme
expressions can take (*note About Expressions::), you can probably guess
what the following ‘set!’ example does...

     (set! x (+ x 1))

   (Note: this is not a complete description of ‘define’ and ‘set!’,
because we need to introduce some other aspects of Scheme before the
missing pieces can be filled in.  If, however, you are already familiar
with the structure of Scheme, you may like to read about those missing
pieces immediately by jumping ahead to the following references.

   • *note Lambda Alternatives::, to read about an alternative form of
     the ‘define’ syntax that can be used when defining new procedures.

   • *note Procedures with Setters::, to read about an alternative form
     of the ‘set!’ syntax that helps with changing a single value in the
     depths of a compound data structure.)

   • *Note Internal Definitions::, to read about using ‘define’ other
     than at top level in a Scheme program, including a discussion of
     when it works to use ‘define’ rather than ‘set!’ to change the
     value of an existing variable.


File: guile.info,  Node: About Procedures,  Next: About Expressions,  Prev: About Data,  Up: Hello Scheme!

3.2 The Representation and Use of Procedures
============================================

This section introduces the basics of using and creating Scheme
procedures.  It discusses the representation of procedures as just
another kind of Scheme value, and shows how procedure invocation
expressions are constructed.  We then explain how ‘lambda’ is used to
create new procedures, and conclude by presenting the various shorthand
forms of ‘define’ that can be used instead of writing an explicit
‘lambda’ expression.

* Menu:

* Procedures as Values::        Procedures are values like everything else.
* Simple Invocation::           How to write a simple procedure invocation.
* Creating a Procedure::        How to create your own procedures.
* Lambda Alternatives::         Other ways of writing procedure definitions.


File: guile.info,  Node: Procedures as Values,  Next: Simple Invocation,  Up: About Procedures

3.2.1 Procedures as Values
--------------------------

One of the great simplifications of Scheme is that a procedure is just
another type of value, and that procedure values can be passed around
and stored in variables in exactly the same way as, for example, strings
and lists.  When we talk about a built-in standard Scheme procedure such
as ‘open-input-file’, what we actually mean is that there is a
pre-defined top level variable called ‘open-input-file’, whose value is
a procedure that implements what R5RS says that ‘open-input-file’ should
do.

   Note that this is quite different from many dialects of Lisp —
including Emacs Lisp — in which a program can use the same name with two
quite separate meanings: one meaning identifies a Lisp function, while
the other meaning identifies a Lisp variable, whose value need have
nothing to do with the function that is associated with the first
meaning.  In these dialects, functions and variables are said to live in
different “namespaces”.

   In Scheme, on the other hand, all names belong to a single unified
namespace, and the variables that these names identify can hold any kind
of Scheme value, including procedure values.

   One consequence of the “procedures as values” idea is that, if you
don’t happen to like the standard name for a Scheme procedure, you can
change it.

   For example, ‘call-with-current-continuation’ is a very important
standard Scheme procedure, but it also has a very long name!  So, many
programmers use the following definition to assign the same procedure
value to the more convenient name ‘call/cc’.

     (define call/cc call-with-current-continuation)

   Let’s understand exactly how this works.  The definition creates a
new variable ‘call/cc’, and then sets its value to the value of the
variable ‘call-with-current-continuation’; the latter value is a
procedure that implements the behaviour that R5RS specifies under the
name “call-with-current-continuation”.  So ‘call/cc’ ends up holding
this value as well.

   Now that ‘call/cc’ holds the required procedure value, you could
choose to use ‘call-with-current-continuation’ for a completely
different purpose, or just change its value so that you will get an
error if you accidentally use ‘call-with-current-continuation’ as a
procedure in your program rather than ‘call/cc’.  For example:

     (set! call-with-current-continuation "Not a procedure any more!")

   Or you could just leave ‘call-with-current-continuation’ as it was.
It’s perfectly fine for more than one variable to hold the same
procedure value.


File: guile.info,  Node: Simple Invocation,  Next: Creating a Procedure,  Prev: Procedures as Values,  Up: About Procedures

3.2.2 Simple Procedure Invocation
---------------------------------

A procedure invocation in Scheme is written like this:

     (PROCEDURE [ARG1 [ARG2 ...]])

   In this expression, PROCEDURE can be any Scheme expression whose
value is a procedure.  Most commonly, however, PROCEDURE is simply the
name of a variable whose value is a procedure.

   For example, ‘string-append’ is a standard Scheme procedure whose
behaviour is to concatenate together all the arguments, which are
expected to be strings, that it is given.  So the expression

     (string-append "/home" "/" "andrew")

is a procedure invocation whose result is the string value
‘"/home/andrew"’.

   Similarly, ‘string-length’ is a standard Scheme procedure that
returns the length of a single string argument, so

     (string-length "abc")

is a procedure invocation whose result is the numeric value 3.

   Each of the parameters in a procedure invocation can itself be any
Scheme expression.  Since a procedure invocation is itself a type of
expression, we can put these two examples together to get

     (string-length (string-append "/home" "/" "andrew"))

— a procedure invocation whose result is the numeric value 12.

   (You may be wondering what happens if the two examples are combined
the other way round.  If we do this, we can make a procedure invocation
expression that is _syntactically_ correct:

     (string-append "/home" (string-length "abc"))

but when this expression is executed, it will cause an error, because
the result of ‘(string-length "abc")’ is a numeric value, and
‘string-append’ is not designed to accept a numeric value as one of its
arguments.)


File: guile.info,  Node: Creating a Procedure,  Next: Lambda Alternatives,  Prev: Simple Invocation,  Up: About Procedures

3.2.3 Creating and Using a New Procedure
----------------------------------------

Scheme has lots of standard procedures, and Guile provides all of these
via predefined top level variables.  All of these standard procedures
are documented in the later chapters of this reference manual.

   Before very long, though, you will want to create new procedures that
encapsulate aspects of your own applications’ functionality.  To do
this, you can use the famous ‘lambda’ syntax.

   For example, the value of the following Scheme expression

     (lambda (name address) BODY ...)

is a newly created procedure that takes two arguments: ‘name’ and
‘address’.  The behaviour of the new procedure is determined by the
sequence of expressions and definitions in the BODY of the procedure
definition.  (Typically, BODY would use the arguments in some way, or
else there wouldn’t be any point in giving them to the procedure.)  When
invoked, the new procedure returns a value that is the value of the last
expression in the BODY.

   To make things more concrete, let’s suppose that the two arguments
are both strings, and that the purpose of this procedure is to form a
combined string that includes these arguments.  Then the full lambda
expression might look like this:

     (lambda (name address)
       (string-append "Name=" name ":Address=" address))

   We noted in the previous subsection that the PROCEDURE part of a
procedure invocation expression can be any Scheme expression whose value
is a procedure.  But that’s exactly what a lambda expression is!  So we
can use a lambda expression directly in a procedure invocation, like
this:

     ((lambda (name address)
        (string-append "Name=" name ":Address=" address))
      "FSF"
      "Cambridge")

This is a valid procedure invocation expression, and its result is the
string:

     "Name=FSF:Address=Cambridge"

   It is more common, though, to store the procedure value in a variable
—

     (define make-combined-string
       (lambda (name address)
         (string-append "Name=" name ":Address=" address)))

— and then to use the variable name in the procedure invocation:

     (make-combined-string "FSF" "Cambridge")

Which has exactly the same result.

   It’s important to note that procedures created using ‘lambda’ have
exactly the same status as the standard built in Scheme procedures, and
can be invoked, passed around, and stored in variables in exactly the
same ways.


File: guile.info,  Node: Lambda Alternatives,  Prev: Creating a Procedure,  Up: About Procedures

3.2.4 Lambda Alternatives
-------------------------

Since it is so common in Scheme programs to want to create a procedure
and then store it in a variable, there is an alternative form of the
‘define’ syntax that allows you to do just that.

   A ‘define’ expression of the form

     (define (NAME [ARG1 [ARG2 ...]])
       BODY ...)

is exactly equivalent to the longer form

     (define NAME
       (lambda ([ARG1 [ARG2 ...]])
         BODY ...))

   So, for example, the definition of ‘make-combined-string’ in the
previous subsection could equally be written:

     (define (make-combined-string name address)
       (string-append "Name=" name ":Address=" address))

   This kind of procedure definition creates a procedure that requires
exactly the expected number of arguments.  There are two further forms
of the ‘lambda’ expression, which create a procedure that can accept a
variable number of arguments:

     (lambda (ARG1 ... . ARGS) BODY ...)

     (lambda ARGS BODY ...)

The corresponding forms of the alternative ‘define’ syntax are:

     (define (NAME ARG1 ... . ARGS) BODY ...)

     (define (NAME . ARGS) BODY ...)

For details on how these forms work, see *Note Lambda::.

   Prior to Guile 2.0, Guile provided an extension to ‘define’ syntax
that allowed you to nest the previous extension up to an arbitrary
depth.  These are no longer provided by default, and instead have been
moved to *note Curried Definitions::.

   (It could be argued that the alternative ‘define’ forms are rather
confusing, especially for newcomers to the Scheme language, as they hide
both the role of ‘lambda’ and the fact that procedures are values that
are stored in variables in the same way as any other kind of value.  On
the other hand, they are very convenient, and they are also a good
example of another of Scheme’s powerful features: the ability to specify
arbitrary syntactic transformations at run time, which can be applied to
subsequently read input.)


File: guile.info,  Node: About Expressions,  Next: About Closure,  Prev: About Procedures,  Up: Hello Scheme!

3.3 Expressions and Evaluation
==============================

So far, we have met expressions that _do_ things, such as the ‘define’
expressions that create and initialize new variables, and we have also
talked about expressions that have _values_, for example the value of
the procedure invocation expression:

     (string-append "/home" "/" "andrew")

but we haven’t yet been precise about what causes an expression like
this procedure invocation to be reduced to its “value”, or how the
processing of such expressions relates to the execution of a Scheme
program as a whole.

   This section clarifies what we mean by an expression’s value, by
introducing the idea of “evaluation”.  It discusses the side effects
that evaluation can have, explains how each of the various types of
Scheme expression is evaluated, and describes the behaviour and use of
the Guile REPL as a mechanism for exploring evaluation.  The section
concludes with a very brief summary of Scheme’s common syntactic
expressions.

* Menu:

* Evaluating::                  How a Scheme program is executed.
* Tail Calls::                  Space-safe recursion.
* The REPL::                    Interacting with the Guile interpreter.
* Syntax Summary::              Common syntactic expressions – in brief.


File: guile.info,  Node: Evaluating,  Next: Tail Calls,  Up: About Expressions

3.3.1 Evaluating Expressions and Executing Programs
---------------------------------------------------

In Scheme, the process of executing an expression is known as
“evaluation”.  Evaluation has two kinds of result:

   • the “value” of the evaluated expression

   • the “side effects” of the evaluation, which consist of any effects
     of evaluating the expression that are not represented by the value.

   Of the expressions that we have met so far, ‘define’ and ‘set!’
expressions have side effects — the creation or modification of a
variable — but no value; ‘lambda’ expressions have values — the newly
constructed procedures — but no side effects; and procedure invocation
expressions, in general, have either values, or side effects, or both.

   It is tempting to try to define more intuitively what we mean by
“value” and “side effects”, and what the difference between them is.  In
general, though, this is extremely difficult.  It is also unnecessary;
instead, we can quite happily define the behaviour of a Scheme program
by specifying how Scheme executes a program as a whole, and then by
describing the value and side effects of evaluation for each type of
expression individually.

So, some(1) definitions...

   • A Scheme program consists of a sequence of expressions.

   • A Scheme interpreter executes the program by evaluating these
     expressions in order, one by one.

   • An expression can be

        • a piece of literal data, such as a number ‘2.3’ or a string
          ‘"Hello world!"’
        • a variable name
        • a procedure invocation expression
        • one of Scheme’s special syntactic expressions.

The following subsections describe how each of these types of expression
is evaluated.

* Menu:

* Eval Literal::                Evaluating literal data.
* Eval Variable::               Evaluating variable references.
* Eval Procedure::              Evaluating procedure invocation expressions.
* Eval Special::                Evaluating special syntactic expressions.

   ---------- Footnotes ----------

   (1) These definitions are approximate.  For the whole and detailed
truth, see *note R5RS syntax: (r5rs)Formal syntax and semantics.


File: guile.info,  Node: Eval Literal,  Next: Eval Variable,  Up: Evaluating

3.3.1.1 Evaluating Literal Data
...............................

When a literal data expression is evaluated, the value of the expression
is simply the value that the expression describes.  The evaluation of a
literal data expression has no side effects.

So, for example,

   • the value of the expression ‘"abc"’ is the string value ‘"abc"’

   • the value of the expression ‘3+4i’ is the complex number 3 + 4i

   • the value of the expression ‘#(1 2 3)’ is a three-element vector
     containing the numeric values 1, 2 and 3.

   For any data type which can be expressed literally like this, the
syntax of the literal data expression for that data type — in other
words, what you need to write in your code to indicate a literal value
of that type — is known as the data type’s “read syntax”.  This manual
specifies the read syntax for each such data type in the section that
describes that data type.

   Some data types do not have a read syntax.  Procedures, for example,
cannot be expressed as literal data; they must be created using a
‘lambda’ expression (*note Creating a Procedure::) or implicitly using
the shorthand form of ‘define’ (*note Lambda Alternatives::).


File: guile.info,  Node: Eval Variable,  Next: Eval Procedure,  Prev: Eval Literal,  Up: Evaluating

3.3.1.2 Evaluating a Variable Reference
.......................................

When an expression that consists simply of a variable name is evaluated,
the value of the expression is the value of the named variable.  The
evaluation of a variable reference expression has no side effects.

   So, after

     (define key "Paul Evans")

the value of the expression ‘key’ is the string value ‘"Paul Evans"’.
If KEY is then modified by

     (set! key 3.74)

the value of the expression ‘key’ is the numeric value 3.74.

   If there is no variable with the specified name, evaluation of the
variable reference expression signals an error.


File: guile.info,  Node: Eval Procedure,  Next: Eval Special,  Prev: Eval Variable,  Up: Evaluating

3.3.1.3 Evaluating a Procedure Invocation Expression
....................................................

This is where evaluation starts getting interesting!  As already noted,
a procedure invocation expression has the form

     (PROCEDURE [ARG1 [ARG2 ...]])

where PROCEDURE must be an expression whose value, when evaluated, is a
procedure.

   The evaluation of a procedure invocation expression like this
proceeds by

   • evaluating individually the expressions PROCEDURE, ARG1, ARG2, and
     so on

   • calling the procedure that is the value of the PROCEDURE expression
     with the list of values obtained from the evaluations of ARG1, ARG2
     etc.  as its parameters.

   For a procedure defined in Scheme, “calling the procedure with the
list of values as its parameters” means binding the values to the
procedure’s formal parameters and then evaluating the sequence of
expressions that make up the body of the procedure definition.  The
value of the procedure invocation expression is the value of the last
evaluated expression in the procedure body.  The side effects of calling
the procedure are the combination of the side effects of the sequence of
evaluations of expressions in the procedure body.

   For a built-in procedure, the value and side-effects of calling the
procedure are best described by that procedure’s documentation.

   Note that the complete side effects of evaluating a procedure
invocation expression consist not only of the side effects of the
procedure call, but also of any side effects of the preceding evaluation
of the expressions PROCEDURE, ARG1, ARG2, and so on.

   To illustrate this, let’s look again at the procedure invocation
expression:

     (string-length (string-append "/home" "/" "andrew"))

   In the outermost expression, PROCEDURE is ‘string-length’ and ARG1 is
‘(string-append "/home" "/" "andrew")’.

   • Evaluation of ‘string-length’, which is a variable, gives a
     procedure value that implements the expected behaviour for
     “string-length”.

   • Evaluation of ‘(string-append "/home" "/" "andrew")’, which is
     another procedure invocation expression, means evaluating each of

        • ‘string-append’, which gives a procedure value that implements
          the expected behaviour for “string-append”

        • ‘"/home"’, which gives the string value ‘"/home"’

        • ‘"/"’, which gives the string value ‘"/"’

        • ‘"andrew"’, which gives the string value ‘"andrew"’

     and then invoking the procedure value with this list of string
     values as its arguments.  The resulting value is a single string
     value that is the concatenation of all the arguments, namely
     ‘"/home/andrew"’.

   In the evaluation of the outermost expression, the interpreter can
now invoke the procedure value obtained from PROCEDURE with the value
obtained from ARG1 as its arguments.  The resulting value is a numeric
value that is the length of the argument string, which is 12.


File: guile.info,  Node: Eval Special,  Prev: Eval Procedure,  Up: Evaluating

3.3.1.4 Evaluating Special Syntactic Expressions
................................................

When a procedure invocation expression is evaluated, the procedure and
_all_ the argument expressions must be evaluated before the procedure
can be invoked.  Special syntactic expressions are special because they
are able to manipulate their arguments in an unevaluated form, and can
choose whether to evaluate any or all of the argument expressions.

   Why is this needed?  Consider a program fragment that asks the user
whether or not to delete a file, and then deletes the file if the user
answers yes.

     (if (string=? (read-answer "Should I delete this file?")
                   "yes")
         (delete-file file))

   If the outermost ‘(if ...)’ expression here was a procedure
invocation expression, the expression ‘(delete-file file)’, whose side
effect is to actually delete a file, would already have been evaluated
before the ‘if’ procedure even got invoked!  Clearly this is no use —
the whole point of an ‘if’ expression is that the “consequent”
expression is only evaluated if the condition of the ‘if’ expression is
“true”.

   Therefore ‘if’ must be special syntax, not a procedure.  Other
special syntaxes that we have already met are ‘define’, ‘set!’ and
‘lambda’.  ‘define’ and ‘set!’ are syntax because they need to know the
variable _name_ that is given as the first argument in a ‘define’ or
‘set!’ expression, not that variable’s value.  ‘lambda’ is syntax
because it does not immediately evaluate the expressions that define the
procedure body; instead it creates a procedure object that incorporates
these expressions so that they can be evaluated in the future, when that
procedure is invoked.

   The rules for evaluating each special syntactic expression are
specified individually for each special syntax.  For a summary of
standard special syntax, see *Note Syntax Summary::.


File: guile.info,  Node: Tail Calls,  Next: The REPL,  Prev: Evaluating,  Up: About Expressions

3.3.2 Tail calls
----------------

Scheme is “properly tail recursive”, meaning that tail calls or
recursions from certain contexts do not consume stack space or other
resources and can therefore be used on arbitrarily large data or for an
arbitrarily long calculation.  Consider for example,

     (define (foo n)
       (display n)
       (newline)
       (foo (1+ n)))

     (foo 1)
     ⊣
     1
     2
     3
     ...

   ‘foo’ prints numbers infinitely, starting from the given N.  It’s
implemented by printing N then recursing to itself to print N+1 and so
on.  This recursion is a tail call, it’s the last thing done, and in
Scheme such tail calls can be made without limit.

   Or consider a case where a value is returned, a version of the SRFI-1
‘last’ function (*note SRFI-1 Selectors::) returning the last element of
a list,

     (define (my-last lst)
       (if (null? (cdr lst))
           (car lst)
           (my-last (cdr lst))))

     (my-last '(1 2 3)) ⇒ 3

   If the list has more than one element, ‘my-last’ applies itself to
the ‘cdr’.  This recursion is a tail call, there’s no code after it, and
the return value is the return value from that call.  In Scheme this can
be used on an arbitrarily long list argument.


   A proper tail call is only available from certain contexts, namely
the following special form positions,

   • ‘and’ — last expression

   • ‘begin’ — last expression

   • ‘case’ — last expression in each clause

   • ‘cond’ — last expression in each clause, and the call to a ‘=>’
     procedure is a tail call

   • ‘do’ — last result expression

   • ‘if’ — “true” and “false” leg expressions

   • ‘lambda’ — last expression in body

   • ‘let’, ‘let*’, ‘letrec’, ‘let-syntax’, ‘letrec-syntax’ — last
     expression in body

   • ‘or’ — last expression

The following core functions make tail calls,

   • ‘apply’ — tail call to given procedure

   • ‘call-with-current-continuation’ — tail call to the procedure
     receiving the new continuation

   • ‘call-with-values’ — tail call to the values-receiving procedure

   • ‘eval’ — tail call to evaluate the form

   • ‘string-any’, ‘string-every’ — tail call to predicate on the last
     character (if that point is reached)


   The above are just core functions and special forms.  Tail calls in
other modules are described with the relevant documentation, for example
SRFI-1 ‘any’ and ‘every’ (*note SRFI-1 Searching::).

   It will be noted there are a lot of places which could potentially be
tail calls, for instance the last call in a ‘for-each’, but only those
explicitly described are guaranteed.


File: guile.info,  Node: The REPL,  Next: Syntax Summary,  Prev: Tail Calls,  Up: About Expressions

3.3.3 Using the Guile REPL
--------------------------

If you start Guile without specifying a particular program for it to
execute, Guile enters its standard Read Evaluate Print Loop — or “REPL”
for short.  In this mode, Guile repeatedly reads in the next Scheme
expression that the user types, evaluates it, and prints the resulting
value.

   The REPL is a useful mechanism for exploring the evaluation behaviour
described in the previous subsection.  If you type ‘string-append’, for
example, the REPL replies ‘#<primitive-procedure string-append>’,
illustrating the relationship between the variable ‘string-append’ and
the procedure value stored in that variable.

   In this manual, the notation ⇒ is used to mean “evaluates to”.
Wherever you see an example of the form

     EXPRESSION
     ⇒
     RESULT

feel free to try it out yourself by typing EXPRESSION into the REPL and
checking that it gives the expected RESULT.


File: guile.info,  Node: Syntax Summary,  Prev: The REPL,  Up: About Expressions

3.3.4 Summary of Common Syntax
------------------------------

This subsection lists the most commonly used Scheme syntactic
expressions, simply so that you will recognize common special syntax
when you see it.  For a full description of each of these syntaxes,
follow the appropriate reference.

   ‘lambda’ (*note Lambda::) is used to construct procedure objects.

   ‘define’ (*note Top Level::) is used to create a new variable and set
its initial value.

   ‘set!’ (*note Top Level::) is used to modify an existing variable’s
value.

   ‘let’, ‘let*’ and ‘letrec’ (*note Local Bindings::) create an inner
lexical environment for the evaluation of a sequence of expressions, in
which a specified set of local variables is bound to the values of a
corresponding set of expressions.  For an introduction to environments,
see *Note About Closure::.

   ‘begin’ (*note begin::) executes a sequence of expressions in order
and returns the value of the last expression.  Note that this is not the
same as a procedure which returns its last argument, because the
evaluation of a procedure invocation expression does not guarantee to
evaluate the arguments in order.

   ‘if’ and ‘cond’ (*note Conditionals::) provide conditional evaluation
of argument expressions depending on whether one or more conditions
evaluate to “true” or “false”.

   ‘case’ (*note Conditionals::) provides conditional evaluation of
argument expressions depending on whether a variable has one of a
specified group of values.

   ‘and’ (*note and or::) executes a sequence of expressions in order
until either there are no expressions left, or one of them evaluates to
“false”.

   ‘or’ (*note and or::) executes a sequence of expressions in order
until either there are no expressions left, or one of them evaluates to
“true”.


File: guile.info,  Node: About Closure,  Next: Further Reading,  Prev: About Expressions,  Up: Hello Scheme!

3.4 The Concept of Closure
==========================

The concept of “closure” is the idea that a lambda expression “captures”
the variable bindings that are in lexical scope at the point where the
lambda expression occurs.  The procedure created by the lambda
expression can refer to and mutate the captured bindings, and the values
of those bindings persist between procedure calls.

   This section explains and explores the various parts of this idea in
more detail.

* Menu:

* About Environments::          Names, locations, values and environments.
* Local Variables::             Local variables and local environments.
* Chaining::                    Environment chaining.
* Lexical Scope::               The meaning of lexical scoping.
* Closure::                     Explaining the concept of closure.
* Serial Number::               Example 1: a serial number generator.
* Shared Variable::             Example 2: a shared persistent variable.
* Callback Closure::            Example 3: the callback closure problem.
* OO Closure::                  Example 4: object orientation.


File: guile.info,  Node: About Environments,  Next: Local Variables,  Up: About Closure

3.4.1 Names, Locations, Values and Environments
-----------------------------------------------

We said earlier that a variable name in a Scheme program is associated
with a location in which any kind of Scheme value may be stored.
(Incidentally, the term “vcell” is often used in Lisp and Scheme circles
as an alternative to “location”.)  Thus part of what we mean when we
talk about “creating a variable” is in fact establishing an association
between a name, or identifier, that is used by the Scheme program code,
and the variable location to which that name refers.  Although the value
that is stored in that location may change, the location to which a
given name refers is always the same.

   We can illustrate this by breaking down the operation of the ‘define’
syntax into three parts: ‘define’

   • creates a new location

   • establishes an association between that location and the name
     specified as the first argument of the ‘define’ expression

   • stores in that location the value obtained by evaluating the second
     argument of the ‘define’ expression.

   A collection of associations between names and locations is called an
“environment”.  When you create a top level variable in a program using
‘define’, the name-location association for that variable is added to
the “top level” environment.  The “top level” environment also includes
name-location associations for all the procedures that are supplied by
standard Scheme.

   It is also possible to create environments other than the top level
one, and to create variable bindings, or name-location associations, in
those environments.  This ability is a key ingredient in the concept of
closure; the next subsection shows how it is done.


File: guile.info,  Node: Local Variables,  Next: Chaining,  Prev: About Environments,  Up: About Closure

3.4.2 Local Variables and Environments
--------------------------------------

We have seen how to create top level variables using the ‘define’ syntax
(*note Definition::).  It is often useful to create variables that are
more limited in their scope, typically as part of a procedure body.  In
Scheme, this is done using the ‘let’ syntax, or one of its modified
forms ‘let*’ and ‘letrec’.  These syntaxes are described in full later
in the manual (*note Local Bindings::).  Here our purpose is to
illustrate their use just enough that we can see how local variables
work.

   For example, the following code uses a local variable ‘s’ to simplify
the computation of the area of a triangle given the lengths of its three
sides.

     (define a 5.3)
     (define b 4.7)
     (define c 2.8)

     (define area
       (let ((s (/ (+ a b c) 2)))
         (sqrt (* s (- s a) (- s b) (- s c)))))

   The effect of the ‘let’ expression is to create a new environment
and, within this environment, an association between the name ‘s’ and a
new location whose initial value is obtained by evaluating ‘(/ (+ a b c)
2)’.  The expressions in the body of the ‘let’, namely ‘(sqrt (* s (- s
a) (- s b) (- s c)))’, are then evaluated in the context of the new
environment, and the value of the last expression evaluated becomes the
value of the whole ‘let’ expression, and therefore the value of the
variable ‘area’.


File: guile.info,  Node: Chaining,  Next: Lexical Scope,  Prev: Local Variables,  Up: About Closure

3.4.3 Environment Chaining
--------------------------

In the example of the previous subsection, we glossed over an important
point.  The body of the ‘let’ expression in that example refers not only
to the local variable ‘s’, but also to the top level variables ‘a’, ‘b’,
‘c’ and ‘sqrt’.  (‘sqrt’ is the standard Scheme procedure for
calculating a square root.)  If the body of the ‘let’ expression is
evaluated in the context of the _local_ ‘let’ environment, how does the
evaluation get at the values of these top level variables?

   The answer is that the local environment created by a ‘let’
expression automatically has a reference to its containing environment —
in this case the top level environment — and that the Scheme interpreter
automatically looks for a variable binding in the containing environment
if it doesn’t find one in the local environment.  More generally, every
environment except for the top level one has a reference to its
containing environment, and the interpreter keeps searching back up the
chain of environments — from most local to top level — until it either
finds a variable binding for the required identifier or exhausts the
chain.

   This description also determines what happens when there is more than
one variable binding with the same name.  Suppose, continuing the
example of the previous subsection, that there was also a pre-existing
top level variable ‘s’ created by the expression:

     (define s "Some beans, my lord!")

   Then both the top level environment and the local ‘let’ environment
would contain bindings for the name ‘s’.  When evaluating code within
the ‘let’ body, the interpreter looks first in the local ‘let’
environment, and so finds the binding for ‘s’ created by the ‘let’
syntax.  Even though this environment has a reference to the top level
environment, which also has a binding for ‘s’, the interpreter doesn’t
get as far as looking there.  When evaluating code outside the ‘let’
body, the interpreter looks up variable names in the top level
environment, so the name ‘s’ refers to the top level variable.

   Within the ‘let’ body, the binding for ‘s’ in the local environment
is said to “shadow” the binding for ‘s’ in the top level environment.


File: guile.info,  Node: Lexical Scope,  Next: Closure,  Prev: Chaining,  Up: About Closure

3.4.4 Lexical Scope
-------------------

The rules that we have just been describing are the details of how
Scheme implements “lexical scoping”.  This subsection takes a brief
diversion to explain what lexical scope means in general and to present
an example of non-lexical scoping.

   “Lexical scope” in general is the idea that

   • an identifier at a particular place in a program always refers to
     the same variable location — where “always” means “every time that
     the containing expression is executed”, and that

   • the variable location to which it refers can be determined by
     static examination of the source code context in which that
     identifier appears, without having to consider the flow of
     execution through the program as a whole.

   In practice, lexical scoping is the norm for most programming
languages, and probably corresponds to what you would intuitively
consider to be “normal”.  You may even be wondering how the situation
could possibly — and usefully — be otherwise.  To demonstrate that
another kind of scoping is possible, therefore, and to compare it
against lexical scoping, the following subsection presents an example of
non-lexical scoping and examines in detail how its behavior differs from
the corresponding lexically scoped code.

* Menu:

* Scoping Example::             An example of non-lexical scoping.


File: guile.info,  Node: Scoping Example,  Up: Lexical Scope

3.4.4.1 An Example of Non-Lexical Scoping
.........................................

To demonstrate that non-lexical scoping does exist and can be useful, we
present the following example from Emacs Lisp, which is a “dynamically
scoped” language.

     (defvar currency-abbreviation "USD")

     (defun currency-string (units hundredths)
       (concat currency-abbreviation
               (number-to-string units)
               "."
               (number-to-string hundredths)))

     (defun french-currency-string (units hundredths)
       (let ((currency-abbreviation "FRF"))
         (currency-string units hundredths)))

   The question to focus on here is: what does the identifier
‘currency-abbreviation’ refer to in the ‘currency-string’ function?  The
answer, in Emacs Lisp, is that all variable bindings go onto a single
stack, and that ‘currency-abbreviation’ refers to the topmost binding
from that stack which has the name “currency-abbreviation”.  The binding
that is created by the ‘defvar’ form, to the value ‘"USD"’, is only
relevant if none of the code that calls ‘currency-string’ rebinds the
name “currency-abbreviation” in the meanwhile.

   The second function ‘french-currency-string’ works precisely by
taking advantage of this behaviour.  It creates a new binding for the
name “currency-abbreviation” which overrides the one established by the
‘defvar’ form.

     ;; Note!  This is Emacs Lisp evaluation, not Scheme!
     (french-currency-string 33 44)
     ⇒
     "FRF33.44"

   Now let’s look at the corresponding, _lexically scoped_ Scheme code:

     (define currency-abbreviation "USD")

     (define (currency-string units hundredths)
       (string-append currency-abbreviation
                      (number->string units)
                      "."
                      (number->string hundredths)))

     (define (french-currency-string units hundredths)
       (let ((currency-abbreviation "FRF"))
         (currency-string units hundredths)))

   According to the rules of lexical scoping, the
‘currency-abbreviation’ in ‘currency-string’ refers to the variable
location in the innermost environment at that point in the code which
has a binding for ‘currency-abbreviation’, which is the variable
location in the top level environment created by the preceding ‘(define
currency-abbreviation ...)’ expression.

   In Scheme, therefore, the ‘french-currency-string’ procedure does not
work as intended.  The variable binding that it creates for
“currency-abbreviation” is purely local to the code that forms the body
of the ‘let’ expression.  Since this code doesn’t directly use the name
“currency-abbreviation” at all, the binding is pointless.

     (french-currency-string 33 44)
     ⇒
     "USD33.44"

   This begs the question of how the Emacs Lisp behaviour can be
implemented in Scheme.  In general, this is a design question whose
answer depends upon the problem that is being addressed.  In this case,
the best answer may be that ‘currency-string’ should be redesigned so
that it can take an optional third argument.  This third argument, if
supplied, is interpreted as a currency abbreviation that overrides the
default.

   It is possible to change ‘french-currency-string’ so that it mostly
works without changing ‘currency-string’, but the fix is inelegant, and
susceptible to interrupts that could leave the ‘currency-abbreviation’
variable in the wrong state:

     (define (french-currency-string units hundredths)
       (set! currency-abbreviation "FRF")
       (let ((result (currency-string units hundredths)))
         (set! currency-abbreviation "USD")
         result))

   The key point here is that the code does not create any local binding
for the identifier ‘currency-abbreviation’, so all occurrences of this
identifier refer to the top level variable.


File: guile.info,  Node: Closure,  Next: Serial Number,  Prev: Lexical Scope,  Up: About Closure

3.4.5 Closure
-------------

Consider a ‘let’ expression that doesn’t contain any ‘lambda’s:

     (let ((s (/ (+ a b c) 2)))
       (sqrt (* s (- s a) (- s b) (- s c))))

When the Scheme interpreter evaluates this, it

   • creates a new environment with a reference to the environment that
     was current when it encountered the ‘let’

   • creates a variable binding for ‘s’ in the new environment, with
     value given by ‘(/ (+ a b c) 2)’

   • evaluates the expression in the body of the ‘let’ in the context of
     the new local environment, and remembers the value ‘V’

   • forgets the local environment

   • continues evaluating the expression that contained the ‘let’, using
     the value ‘V’ as the value of the ‘let’ expression, in the context
     of the containing environment.

   After the ‘let’ expression has been evaluated, the local environment
that was created is simply forgotten, and there is no longer any way to
access the binding that was created in this environment.  If the same
code is evaluated again, it will follow the same steps again, creating a
second new local environment that has no connection with the first, and
then forgetting this one as well.

   If the ‘let’ body contains a ‘lambda’ expression, however, the local
environment is _not_ forgotten.  Instead, it becomes associated with the
procedure that is created by the ‘lambda’ expression, and is reinstated
every time that that procedure is called.  In detail, this works as
follows.

   • When the Scheme interpreter evaluates a ‘lambda’ expression, to
     create a procedure object, it stores the current environment as
     part of the procedure definition.

   • Then, whenever that procedure is called, the interpreter reinstates
     the environment that is stored in the procedure definition and
     evaluates the procedure body within the context of that
     environment.

   The result is that the procedure body is always evaluated in the
context of the environment that was current when the procedure was
created.

   This is what is meant by “closure”.  The next few subsections present
examples that explore the usefulness of this concept.


File: guile.info,  Node: Serial Number,  Next: Shared Variable,  Prev: Closure,  Up: About Closure

3.4.6 Example 1: A Serial Number Generator
------------------------------------------

This example uses closure to create a procedure with a variable binding
that is private to the procedure, like a local variable, but whose value
persists between procedure calls.

     (define (make-serial-number-generator)
       (let ((current-serial-number 0))
         (lambda ()
           (set! current-serial-number (+ current-serial-number 1))
           current-serial-number)))

     (define entry-sn-generator (make-serial-number-generator))

     (entry-sn-generator)
     ⇒
     1

     (entry-sn-generator)
     ⇒
     2

   When ‘make-serial-number-generator’ is called, it creates a local
environment with a binding for ‘current-serial-number’ whose initial
value is 0, then, within this environment, creates a procedure.  The
local environment is stored within the created procedure object and so
persists for the lifetime of the created procedure.

   Every time the created procedure is invoked, it increments the value
of the ‘current-serial-number’ binding in the captured environment and
then returns the current value.

   Note that ‘make-serial-number-generator’ can be called again to
create a second serial number generator that is independent of the
first.  Every new invocation of ‘make-serial-number-generator’ creates a
new local ‘let’ environment and returns a new procedure object with an
association to this environment.


File: guile.info,  Node: Shared Variable,  Next: Callback Closure,  Prev: Serial Number,  Up: About Closure

3.4.7 Example 2: A Shared Persistent Variable
---------------------------------------------

This example uses closure to create two procedures, ‘get-balance’ and
‘deposit’, that both refer to the same captured local environment so
that they can both access the ‘balance’ variable binding inside that
environment.  The value of this variable binding persists between calls
to either procedure.

   Note that the captured ‘balance’ variable binding is private to these
two procedures: it is not directly accessible to any other code.  It can
only be accessed indirectly via ‘get-balance’ or ‘deposit’, as
illustrated by the ‘withdraw’ procedure.

     (define get-balance #f)
     (define deposit #f)

     (let ((balance 0))
       (set! get-balance
             (lambda ()
               balance))
       (set! deposit
             (lambda (amount)
               (set! balance (+ balance amount))
               balance)))

     (define (withdraw amount)
       (deposit (- amount)))

     (get-balance)
     ⇒
     0

     (deposit 50)
     ⇒
     50

     (withdraw 75)
     ⇒
     -25

   An important detail here is that the ‘get-balance’ and ‘deposit’
variables must be set up by ‘define’ing them at top level and then
‘set!’ing their values inside the ‘let’ body.  Using ‘define’ within the
‘let’ body would not work: this would create variable bindings within
the local ‘let’ environment that would not be accessible at top level.


File: guile.info,  Node: Callback Closure,  Next: OO Closure,  Prev: Shared Variable,  Up: About Closure

3.4.8 Example 3: The Callback Closure Problem
---------------------------------------------

A frequently used programming model for library code is to allow an
application to register a callback function for the library to call when
some particular event occurs.  It is often useful for the application to
make several such registrations using the same callback function, for
example if several similar library events can be handled using the same
application code, but the need then arises to distinguish the callback
function calls that are associated with one callback registration from
those that are associated with different callback registrations.

   In languages without the ability to create functions dynamically,
this problem is usually solved by passing a ‘user_data’ parameter on the
registration call, and including the value of this parameter as one of
the parameters on the callback function.  Here is an example of
declarations using this solution in C:

     typedef void (event_handler_t) (int event_type,
                                     void *user_data);

     void register_callback (int event_type,
                             event_handler_t *handler,
                             void *user_data);

   In Scheme, closure can be used to achieve the same functionality
without requiring the library code to store a ‘user-data’ for each
callback registration.

     ;; In the library:

     (define (register-callback event-type handler-proc)
       ...)

     ;; In the application:

     (define (make-handler event-type user-data)
       (lambda ()
         ...
         <code referencing event-type and user-data>
         ...))

     (register-callback event-type
                        (make-handler event-type ...))

   As far as the library is concerned, ‘handler-proc’ is a procedure
with no arguments, and all the library has to do is call it when the
appropriate event occurs.  From the application’s point of view, though,
the handler procedure has used closure to capture an environment that
includes all the context that the handler code needs — ‘event-type’ and
‘user-data’ — to handle the event correctly.


File: guile.info,  Node: OO Closure,  Prev: Callback Closure,  Up: About Closure

3.4.9 Example 4: Object Orientation
-----------------------------------

Closure is the capture of an environment, containing persistent variable
bindings, within the definition of a procedure or a set of related
procedures.  This is rather similar to the idea in some object oriented
languages of encapsulating a set of related data variables inside an
“object”, together with a set of “methods” that operate on the
encapsulated data.  The following example shows how closure can be used
to emulate the ideas of objects, methods and encapsulation in Scheme.

     (define (make-account)
       (let ((balance 0))
         (define (get-balance)
           balance)
         (define (deposit amount)
           (set! balance (+ balance amount))
           balance)
         (define (withdraw amount)
           (deposit (- amount)))

         (lambda args
           (apply
             (case (car args)
               ((get-balance) get-balance)
               ((deposit) deposit)
               ((withdraw) withdraw)
               (else (error "Invalid method!")))
             (cdr args)))))

   Each call to ‘make-account’ creates and returns a new procedure,
created by the expression in the example code that begins “(lambda
args”.

     (define my-account (make-account))

     my-account
     ⇒
     #<procedure args>

   This procedure acts as an account object with methods ‘get-balance’,
‘deposit’ and ‘withdraw’.  To apply one of the methods to the account,
you call the procedure with a symbol indicating the required method as
the first parameter, followed by any other parameters that are required
by that method.

     (my-account 'get-balance)
     ⇒
     0

     (my-account 'withdraw 5)
     ⇒
     -5

     (my-account 'deposit 396)
     ⇒
     391

     (my-account 'get-balance)
     ⇒
     391

   Note how, in this example, both the current balance and the helper
procedures ‘get-balance’, ‘deposit’ and ‘withdraw’, used to implement
the guts of the account object’s methods, are all stored in variable
bindings within the private local environment captured by the ‘lambda’
expression that creates the account object procedure.


File: guile.info,  Node: Further Reading,  Prev: About Closure,  Up: Hello Scheme!

3.5 Further Reading
===================

   • The website <http://www.schemers.org/> is a good starting point for
     all things Scheme.

   • Dorai Sitaram’s online Scheme tutorial, “Teach Yourself Scheme in
     Fixnum Days”, at
     <http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html>.
     Includes a nice explanation of continuations.

   • The complete text of “Structure and Interpretation of Computer
     Programs”, the classic introduction to computer science and Scheme
     by Hal Abelson, Jerry Sussman and Julie Sussman, is now available
     online at <http://mitpress.mit.edu/sicp/sicp.html>.  This site also
     provides teaching materials related to the book, and all the source
     code used in the book, in a form suitable for loading and running.


File: guile.info,  Node: Programming in Scheme,  Next: Programming in C,  Prev: Hello Scheme!,  Up: Top

4 Programming in Scheme
***********************

Guile’s core language is Scheme, and a lot can be achieved simply by
using Guile to write and run Scheme programs — as opposed to having to
dive into C code.  In this part of the manual, we explain how to use
Guile in this mode, and describe the tools that Guile provides to help
you with script writing, debugging, and packaging your programs for
distribution.

   For detailed reference information on the variables, functions, and
so on that make up Guile’s application programming interface (API), see
*note API Reference::.

* Menu:

* Guile Scheme::                Guile’s implementation of Scheme.
* Invoking Guile::              Selecting optional features when starting Guile.
* Guile Scripting::             How to write Guile scripts.
* Using Guile Interactively::   Guile’s REPL features.
* Using Guile in Emacs::        Guile and Emacs.
* Using Guile Tools::           A guild of scheming wizards.
* Installing Site Packages::    Installing Scheme code.
* Distributing Guile Code::     Building and distributing your code.


File: guile.info,  Node: Guile Scheme,  Next: Invoking Guile,  Up: Programming in Scheme

4.1 Guile’s Implementation of Scheme
====================================

Guile’s core language is Scheme, which is specified and described in the
series of reports known as “RnRS”. “RnRS” is shorthand for the
“Revised^n Report on the Algorithmic Language Scheme”.  Guile complies
fully with R5RS (*note Introduction: (r5rs)Top.), and is largely
compliant with R6RS and R7RS.

   Guile also has many extensions that go beyond these reports.  Some of
the areas where Guile extends standard Scheme are:

   • Guile’s interactive documentation system

   • Guile’s support for POSIX-compliant network programming

   • GOOPS – Guile’s framework for object oriented programming.


File: guile.info,  Node: Invoking Guile,  Next: Guile Scripting,  Prev: Guile Scheme,  Up: Programming in Scheme

4.2 Invoking Guile
==================

Many features of Guile depend on and can be changed by information that
the user provides either before or when Guile is started.  Below is a
description of what information to provide and how to provide it.

* Menu:

* Command-line Options::        Command-line options understood by Guile.
* Environment Variables::       Variables that affect Guile’s behavior.


File: guile.info,  Node: Command-line Options,  Next: Environment Variables,  Up: Invoking Guile

4.2.1 Command-line Options
--------------------------

Here we describe Guile’s command-line processing in detail.  Guile
processes its arguments from left to right, recognizing the switches
described below.  For examples, see *note Scripting Examples::.

‘SCRIPT ARG...’
‘-s SCRIPT ARG...’
     By default, Guile will read a file named on the command line as a
     script.  Any command-line arguments ARG... following SCRIPT become
     the script’s arguments; the ‘command-line’ function returns a list
     of strings of the form ‘(SCRIPT ARG...)’.

     It is possible to name a file using a leading hyphen, for example,
     ‘-myfile.scm’.  In this case, the file name must be preceded by
     ‘-s’ to tell Guile that a (script) file is being named.

     Scripts are read and evaluated as Scheme source code just as the
     ‘load’ function would.  After loading SCRIPT, Guile exits.

‘-c EXPR ARG...’
     Evaluate EXPR as Scheme code, and then exit.  Any command-line
     arguments ARG... following EXPR become command-line arguments; the
     ‘command-line’ function returns a list of strings of the form
     ‘(GUILE ARG...)’, where GUILE is the path of the Guile executable.

‘-- ARG...’
     Run interactively, prompting the user for expressions and
     evaluating them.  Any command-line arguments ARG... following the
     ‘--’ become command-line arguments for the interactive session; the
     ‘command-line’ function returns a list of strings of the form
     ‘(GUILE ARG...)’, where GUILE is the path of the Guile executable.

‘-L DIRECTORY’
     Add DIRECTORY to the front of Guile’s module load path.  The given
     directories are searched in the order given on the command line and
     before any directories in the ‘GUILE_LOAD_PATH’ environment
     variable.  Paths added here are _not_ in effect during execution of
     the user’s ‘.guile’ file.

‘-C DIRECTORY’
     Like ‘-L’, but adjusts the load path for _compiled_ files.

‘-x EXTENSION’
     Add EXTENSION to the front of Guile’s load extension list (*note
     ‘%load-extensions’: Load Paths.).  The specified extensions are
     tried in the order given on the command line, and before the
     default load extensions.  Extensions added here are _not_ in effect
     during execution of the user’s ‘.guile’ file.

‘-l FILE’
     Load Scheme source code from FILE, and continue processing the
     command line.

‘-e FUNCTION’
     Make FUNCTION the “entry point” of the script.  After loading the
     script file (with ‘-s’) or evaluating the expression (with ‘-c’),
     apply FUNCTION to a list containing the program name and the
     command-line arguments—the list provided by the ‘command-line’
     function.

     A ‘-e’ switch can appear anywhere in the argument list, but Guile
     always invokes the FUNCTION as the _last_ action it performs.  This
     is weird, but because of the way script invocation works under
     POSIX, the ‘-s’ option must always come last in the list.

     The FUNCTION is most often a simple symbol that names a function
     that is defined in the script.  It can also be of the form ‘(@
     MODULE-NAME SYMBOL)’, and in that case, the symbol is looked up in
     the module named MODULE-NAME.

     As a shorthand you can use the form ‘(symbol ...)’, that is, a list
     of only symbols that doesn’t start with ‘@’.  It is equivalent to
     ‘(@ MODULE-NAME main)’, where MODULE-NAME is ‘(symbol ...)’ form.
     *Note Using Guile Modules:: and *note Scripting Examples::.

‘-ds’
     Treat a final ‘-s’ option as if it occurred at this point in the
     command line; load the script here.

     This switch is necessary because, although the POSIX script
     invocation mechanism effectively requires the ‘-s’ option to appear
     last, the programmer may well want to run the script before other
     actions requested on the command line.  For examples, see *note
     Scripting Examples::.

‘\’
     Read more command-line arguments, starting from the second line of
     the script file.  *Note The Meta Switch::.

‘--use-srfi=LIST’
     The option ‘--use-srfi’ expects a comma-separated list of numbers,
     each representing a SRFI module to be loaded into the interpreter
     before evaluating a script file or starting the REPL. Additionally,
     the feature identifier for the loaded SRFIs is recognized by the
     procedure ‘cond-expand’ when this option is used.

     Here is an example that loads the modules SRFI-8 (’receive’) and
     SRFI-13 (’string library’) before the GUILE interpreter is started:

          guile --use-srfi=8,13

‘--r6rs’
     Adapt Guile’s initial environment to better support R6RS. *Note
     R6RS Incompatibilities::, for some caveats.

‘--r7rs’
     Adapt Guile’s initial environment to better support R7RS. *Note
     R7RS Incompatibilities::, for some caveats.

‘--debug’
     Start with the debugging virtual machine (VM) engine.  Using the
     debugging VM will enable support for VM hooks, which are needed for
     tracing, breakpoints, and accurate call counts when profiling.  The
     debugging VM is slower than the regular VM, though, by about ten
     percent.  *Note VM Hooks::, for more information.

     By default, the debugging VM engine is only used when entering an
     interactive session.  When executing a script with ‘-s’ or ‘-c’,
     the normal, faster VM is used by default.

‘--no-debug’
     Do not use the debugging VM engine, even when entering an
     interactive session.

     Note that, despite the name, Guile running with ‘--no-debug’ _does_
     support the usual debugging facilities, such as printing a detailed
     backtrace upon error.  The only difference with ‘--debug’ is lack
     of support for VM hooks and the facilities that build upon it (see
     above).

‘-q’
     Do not load the initialization file, ‘.guile’.  This option only
     has an effect when running interactively; running scripts does not
     load the ‘.guile’ file.  *Note Init File::.

‘--listen[=P]’
     While this program runs, listen on a local port or a path for REPL
     clients.  If P starts with a number, it is assumed to be a local
     port on which to listen.  If it starts with a forward slash, it is
     assumed to be the file name of a UNIX domain socket on which to
     listen.

     If P is not given, the default is local port 37146.  If you look at
     it upside down, it almost spells “Guile”.  If you have netcat
     installed, you should be able to ‘nc localhost 37146’ and get a
     Guile prompt.  Alternately you can fire up Emacs and connect to the
     process; see *note Using Guile in Emacs:: for more details.

          Note: Opening a port allows anyone who can connect to that
          port to do anything Guile can do, as the user that the Guile
          process is running as.  Do not use ‘--listen’ on multi-user
          machines.  Of course, if you do not pass ‘--listen’ to Guile,
          no port will be opened.

          Guile protects against the “HTTP inter-protocol exploitation
          attack”
          (https://en.wikipedia.org/wiki/Inter-protocol_exploitation), a
          scenario whereby an attacker can, via an HTML page, cause a
          web browser to send data to TCP servers listening on a
          loopback interface or private network.  Nevertheless, you are
          advised to use UNIX domain sockets, as in
          ‘--listen=/some/local/file’, whenever possible.

     That said, ‘--listen’ is great for interactive debugging and
     development.

‘--auto-compile’
     Compile source files automatically (default behavior).

‘--fresh-auto-compile’
     Treat the auto-compilation cache as invalid, forcing recompilation.

‘--no-auto-compile’
     Disable automatic source file compilation.

‘--language=LANG’
     For the remainder of the command line arguments, assume that files
     mentioned with ‘-l’ and expressions passed with ‘-c’ are written in
     LANG.  LANG must be the name of one of the languages supported by
     the compiler (*note Compiler Tower::).  When run interactively, set
     the REPL’s language to LANG (*note Using Guile Interactively::).

     The default language is ‘scheme’; other interesting values include
     ‘elisp’ (for Emacs Lisp), and ‘ecmascript’.

     The example below shows the evaluation of expressions in Scheme,
     Emacs Lisp, and ECMAScript:

          guile -c "(apply + '(1 2))"
          guile --language=elisp -c "(= (funcall (symbol-function '+) 1 2) 3)"
          guile --language=ecmascript -c '(function (x) { return x * x; })(2);'

     To load a file written in Scheme and one written in Emacs Lisp, and
     then start a Scheme REPL, type:

          guile -l foo.scm --language=elisp -l foo.el --language=scheme

‘-h, --help’
     Display help on invoking Guile, and then exit.

‘-v, --version’
     Display the current version of Guile, and then exit.


File: guile.info,  Node: Environment Variables,  Prev: Command-line Options,  Up: Invoking Guile

4.2.2 Environment Variables
---------------------------

The “environment” is a feature of the operating system; it consists of a
collection of variables with names and values.  Each variable is called
an “environment variable” (or, sometimes, a “shell variable”);
environment variable names are case-sensitive, and it is conventional to
use upper-case letters only.  The values are all text strings, even
those that are written as numerals.  (Note that here we are referring to
names and values that are defined in the operating system shell from
which Guile is invoked.  This is not the same as a Scheme environment
that is defined within a running instance of Guile.  For a description
of Scheme environments, *note About Environments::.)

   How to set environment variables before starting Guile depends on the
operating system and, especially, the shell that you are using.  For
example, here is how to tell Guile to provide detailed warning messages
about deprecated features by setting ‘GUILE_WARN_DEPRECATED’ using Bash:

     $ export GUILE_WARN_DEPRECATED="detailed"
     $ guile

Or, detailed warnings can be turned on for a single invocation using:

     $ env GUILE_WARN_DEPRECATED="detailed" guile

   If you wish to retrieve or change the value of the shell environment
variables that affect the run-time behavior of Guile from within a
running instance of Guile, see *note Runtime Environment::.

   Here are the environment variables that affect the run-time behavior
of Guile:

‘GUILE_AUTO_COMPILE’
     This is a flag that can be used to tell Guile whether or not to
     compile Scheme source files automatically.  Starting with Guile
     2.0, Scheme source files will be compiled automatically, by
     default.

     If a compiled (‘.go’) file corresponding to a ‘.scm’ file is not
     found or is not newer than the ‘.scm’ file, the ‘.scm’ file will be
     compiled on the fly, and the resulting ‘.go’ file stored away.  An
     advisory note will be printed on the console.

     Compiled files will be stored in the directory
     ‘$XDG_CACHE_HOME/guile/ccache’, where ‘XDG_CACHE_HOME’ defaults to
     the directory ‘$HOME/.cache’.  This directory will be created if it
     does not already exist.

     Note that this mechanism depends on the timestamp of the ‘.go’ file
     being newer than that of the ‘.scm’ file; if the ‘.scm’ or ‘.go’
     files are moved after installation, care should be taken to
     preserve their original timestamps.

     Set ‘GUILE_AUTO_COMPILE’ to zero (0), to prevent Scheme files from
     being compiled automatically.  Set this variable to “fresh” to tell
     Guile to compile Scheme files whether they are newer than the
     compiled files or not.

     *Note Compilation::.

‘GUILE_HISTORY’
     This variable names the file that holds the Guile REPL command
     history.  You can specify a different history file by setting this
     environment variable.  By default, the history file is
     ‘$HOME/.guile_history’.

‘GUILE_INSTALL_LOCALE’
     This is a flag that can be used to tell Guile whether or not to
     install the current locale at startup, via a call to ‘(setlocale
     LC_ALL "")’(1).  *Note Locales::, for more information on locales.

     You may explicitly indicate that you do not want to install the
     locale by setting ‘GUILE_INSTALL_LOCALE’ to ‘0’, or explicitly
     enable it by setting the variable to ‘1’.

     Usually, installing the current locale is the right thing to do.
     It allows Guile to correctly parse and print strings with non-ASCII
     characters.  Therefore, this option is on by default.

‘GUILE_LOAD_COMPILED_PATH’
     This variable may be used to augment the path that is searched for
     compiled Scheme files (‘.go’ files) when loading.  Its value should
     be a colon-separated list of directories.  If it contains the
     special path component ‘...’ (ellipsis), then the default path is
     put in place of the ellipsis, otherwise the default path is placed
     at the end.  The result is stored in ‘%load-compiled-path’ (*note
     Load Paths::).

     Here is an example using the Bash shell that adds the current
     directory, ‘.’, and the relative directory ‘../my-library’ to
     ‘%load-compiled-path’:

          $ export GUILE_LOAD_COMPILED_PATH=".:../my-library"
          $ guile -c '(display %load-compiled-path) (newline)'
          (. ../my-library /usr/local/lib/guile/3.0/ccache)

‘GUILE_LOAD_PATH’
     This variable may be used to augment the path that is searched for
     Scheme files when loading.  Its value should be a colon-separated
     list of directories.  If it contains the special path component
     ‘...’ (ellipsis), then the default path is put in place of the
     ellipsis, otherwise the default path is placed at the end.  The
     result is stored in ‘%load-path’ (*note Load Paths::).

     Here is an example using the Bash shell that prepends the current
     directory to ‘%load-path’, and adds the relative directory
     ‘../srfi’ to the end:

          $ env GUILE_LOAD_PATH=".:...:../srfi" \
          guile -c '(display %load-path) (newline)'
          (. /usr/local/share/guile/3.0 \
          /usr/local/share/guile/site/3.0 \
          /usr/local/share/guile/site \
          /usr/local/share/guile \
          ../srfi)

     (Note: The line breaks, above, are for documentation purposes only,
     and not required in the actual example.)

‘GUILE_EXTENSIONS_PATH’
     This variable may be used to augment the path that is searched for
     foreign libraries via ‘load-extension’, ‘dynamic-link’,
     ‘load-foreign-library’, or the like.  Its value should be a
     colon-separated (semicolon on Windows) list of directories.  *Note
     Foreign Libraries::.

‘GUILE_WARN_DEPRECATED’
     As Guile evolves, some features will be eliminated or replaced by
     newer features.  To help users migrate their code as this evolution
     occurs, Guile will issue warning messages about code that uses
     features that have been marked for eventual elimination.
     ‘GUILE_WARN_DEPRECATED’ can be set to “no” to tell Guile not to
     display these warning messages, or set to “detailed” to tell Guile
     to display more lengthy messages describing the warning.  *Note
     Deprecation::.

‘HOME’
     Guile uses the environment variable ‘HOME’, the name of your home
     directory, to locate various files, such as ‘.guile’ or
     ‘.guile_history’.

‘GUILE_INSTALL_GMP_MEMORY_FUNCTIONS’
     Guile uses the GNU multi-precision (GMP) library to implement its
     bigint support.  It can use an included minimal version of GMP, or
     the system version, which may be more optimal.  If Guile is the
     sole user of GMP in the process, Guile can tell GMP to allocate its
     digits using garbage-collected memory.  This can be significantly
     faster.  However this approach is unsafe if there are other
     libraries loaded that use libgmp, such as the GnuTLS library.  The
     default is for Guile to do the fastest safe thing: use the garbage
     collector for GMP when using the included “mini-GMP”, but not
     otherwise.  Set this variable to nonzero to force GMP to use
     garbage-collected memory, even when using system GC.

‘GUILE_JIT_THRESHOLD’
     Guile has a just-in-time (JIT) code generator that makes running
     Guile code fast.  *Note Just-In-Time Native Code::, for more.  The
     unit of code generation is the function.  Each function has its own
     counter that gets incremented when the function is called and at
     each loop iteration in the function.  When the counter exceeds the
     ‘GUILE_JIT_THRESHOLD’, the function will get JIT-compiled.  Set
     ‘GUILE_JIT_THRESHOLD’ to ‘-1’ to disable JIT compilation, or ‘0’ to
     eagerly JIT-compile each function as it’s first seen.

‘GUILE_JIT_LOG’
     Set to ‘1’, ‘2’, or ‘3’ to give increasing amounts of logging for
     JIT compilation events.  Used for debugging.

‘GUILE_JIT_STOP_AFTER’
     Though we have tested the JIT compiler as well as we can, it’s
     possible that it has bugs.  If you suspect that Guile’s JIT
     compiler is causing your program to fail, set
     ‘GUILE_JIT_STOP_AFTER’ to a positive integer indicating the maximum
     number of functions to JIT-compile.  By bisecting over the value of
     ‘GUILE_JIT_STOP_AFTER’, you can pinpoint the precise function that
     is being miscompiled.

   ---------- Footnotes ----------

   (1) The ‘GUILE_INSTALL_LOCALE’ environment variable was ignored in
Guile versions prior to 2.0.9.


File: guile.info,  Node: Guile Scripting,  Next: Using Guile Interactively,  Prev: Invoking Guile,  Up: Programming in Scheme

4.3 Guile Scripting
===================

Like AWK, Perl, or any shell, Guile can interpret script files.  A Guile
script is simply a file of Scheme code with some extra information at
the beginning which tells the operating system how to invoke Guile, and
then tells Guile how to handle the Scheme code.

* Menu:

* The Top of a Script File::    How to start a Guile script.
* The Meta Switch::             Passing complex argument lists to Guile
                                from shell scripts.
* Command Line Handling::       Accessing the command line from a script.
* Scripting Examples::


File: guile.info,  Node: The Top of a Script File,  Next: The Meta Switch,  Up: Guile Scripting

4.3.1 The Top of a Script File
------------------------------

The first line of a Guile script must tell the operating system to use
Guile to evaluate the script, and then tell Guile how to go about doing
that.  Here is the simplest case:

   • The first two characters of the file must be ‘#!’.

     The operating system interprets this to mean that the rest of the
     line is the name of an executable that can interpret the script.
     Guile, however, interprets these characters as the beginning of a
     multi-line comment, terminated by the characters ‘!#’ on a line by
     themselves.  (This is an extension to the syntax described in R5RS,
     added to support shell scripts.)

   • Immediately after those two characters must come the full pathname
     to the Guile interpreter.  On most systems, this would be
     ‘/usr/local/bin/guile’.

   • Then must come a space, followed by a command-line argument to pass
     to Guile; this should be ‘-s’.  This switch tells Guile to run a
     script, instead of soliciting the user for input from the terminal.
     There are more elaborate things one can do here; see *note The Meta
     Switch::.

   • Follow this with a newline.

   • The second line of the script should contain only the characters
     ‘!#’ — just like the top of the file, but reversed.  The operating
     system never reads this far, but Guile treats this as the end of
     the comment begun on the first line by the ‘#!’ characters.

   • If this source code file is not ASCII or ISO-8859-1 encoded, a
     coding declaration such as ‘coding: utf-8’ should appear in a
     comment somewhere in the first five lines of the file: see *note
     Character Encoding of Source Files::.

   • The rest of the file should be a Scheme program.

   Guile reads the program, evaluating expressions in the order that
they appear.  Upon reaching the end of the file, Guile exits.


File: guile.info,  Node: The Meta Switch,  Next: Command Line Handling,  Prev: The Top of a Script File,  Up: Guile Scripting

4.3.2 The Meta Switch
---------------------

Guile’s command-line switches allow the programmer to describe
reasonably complicated actions in scripts.  Unfortunately, the POSIX
script invocation mechanism only allows one argument to appear on the
‘#!’ line after the path to the Guile executable, and imposes arbitrary
limits on that argument’s length.  Suppose you wrote a script starting
like this:
     #!/usr/local/bin/guile -e main -s
     !#
     (define (main args)
       (map (lambda (arg) (display arg) (display " "))
            (cdr args))
       (newline))
   The intended meaning is clear: load the file, and then call ‘main’ on
the command-line arguments.  However, the system will treat everything
after the Guile path as a single argument — the string ‘"-e main -s"’ —
which is not what we want.

   As a workaround, the meta switch ‘\’ allows the Guile programmer to
specify an arbitrary number of options without patching the kernel.  If
the first argument to Guile is ‘\’, Guile will open the script file
whose name follows the ‘\’, parse arguments starting from the file’s
second line (according to rules described below), and substitute them
for the ‘\’ switch.

   Working in concert with the meta switch, Guile treats the characters
‘#!’ as the beginning of a comment which extends through the next line
containing only the characters ‘!#’.  This sort of comment may appear
anywhere in a Guile program, but it is most useful at the top of a file,
meshing magically with the POSIX script invocation mechanism.

   Thus, consider a script named ‘/u/jimb/ekko’ which starts like this:
     #!/usr/local/bin/guile \
     -e main -s
     !#
     (define (main args)
             (map (lambda (arg) (display arg) (display " "))
                  (cdr args))
             (newline))

   Suppose a user invokes this script as follows:
     $ /u/jimb/ekko a b c

   Here’s what happens:

   • the operating system recognizes the ‘#!’ token at the top of the
     file, and rewrites the command line to:
          /usr/local/bin/guile \ /u/jimb/ekko a b c
     This is the usual behavior, prescribed by POSIX.

   • When Guile sees the first two arguments, ‘\ /u/jimb/ekko’, it opens
     ‘/u/jimb/ekko’, parses the three arguments ‘-e’, ‘main’, and ‘-s’
     from it, and substitutes them for the ‘\’ switch.  Thus, Guile’s
     command line now reads:
          /usr/local/bin/guile -e main -s /u/jimb/ekko a b c

   • Guile then processes these switches: it loads ‘/u/jimb/ekko’ as a
     file of Scheme code (treating the first three lines as a comment),
     and then performs the application ‘(main "/u/jimb/ekko" "a" "b"
     "c")’.

   When Guile sees the meta switch ‘\’, it parses command-line argument
from the script file according to the following rules:

   • Each space character terminates an argument.  This means that two
     spaces in a row introduce an argument ‘""’.

   • The tab character is not permitted (unless you quote it with the
     backslash character, as described below), to avoid confusion.

   • The newline character terminates the sequence of arguments, and
     will also terminate a final non-empty argument.  (However, a
     newline following a space will not introduce a final empty-string
     argument; it only terminates the argument list.)

   • The backslash character is the escape character.  It escapes
     backslash, space, tab, and newline.  The ANSI C escape sequences
     like ‘\n’ and ‘\t’ are also supported.  These produce argument
     constituents; the two-character combination ‘\n’ doesn’t act like a
     terminating newline.  The escape sequence ‘\NNN’ for exactly three
     octal digits reads as the character whose ASCII code is NNN.  As
     above, characters produced this way are argument constituents.
     Backslash followed by other characters is not allowed.


File: guile.info,  Node: Command Line Handling,  Next: Scripting Examples,  Prev: The Meta Switch,  Up: Guile Scripting

4.3.3 Command Line Handling
---------------------------

The ability to accept and handle command line arguments is very
important when writing Guile scripts to solve particular problems, such
as extracting information from text files or interfacing with existing
command line applications.  This chapter describes how Guile makes
command line arguments available to a Guile script, and the utilities
that Guile provides to help with the processing of command line
arguments.

   When a Guile script is invoked, Guile makes the command line
arguments accessible via the procedure ‘command-line’, which returns the
arguments as a list of strings.

   For example, if the script

     #! /usr/local/bin/guile -s
     !#
     (write (command-line))
     (newline)

is saved in a file ‘cmdline-test.scm’ and invoked using the command line
‘./cmdline-test.scm bar.txt -o foo -frumple grob’, the output is

     ("./cmdline-test.scm" "bar.txt" "-o" "foo" "-frumple" "grob")

   If the script invocation includes a ‘-e’ option, specifying a
procedure to call after loading the script, Guile will call that
procedure with ‘(command-line)’ as its argument.  So a script that uses
‘-e’ doesn’t need to refer explicitly to ‘command-line’ in its code.
For example, the script above would have identical behaviour if it was
written instead like this:

     #! /usr/local/bin/guile \
     -e main -s
     !#
     (define (main args)
       (write args)
       (newline))

   (Note the use of the meta switch ‘\’ so that the script invocation
can include more than one Guile option: *Note The Meta Switch::.)

   These scripts use the ‘#!’ POSIX convention so that they can be
executed using their own file names directly, as in the example command
line ‘./cmdline-test.scm bar.txt -o foo -frumple grob’.  But they can
also be executed by typing out the implied Guile command line in full,
as in:

     $ guile -s ./cmdline-test.scm bar.txt -o foo -frumple grob

or

     $ guile -e main -s ./cmdline-test2.scm bar.txt -o foo -frumple grob

   Even when a script is invoked using this longer form, the arguments
that the script receives are the same as if it had been invoked using
the short form.  Guile ensures that the ‘(command-line)’ or ‘-e’
arguments are independent of how the script is invoked, by stripping off
the arguments that Guile itself processes.

   A script is free to parse and handle its command line arguments in
any way that it chooses.  Where the set of possible options and
arguments is complex, however, it can get tricky to extract all the
options, check the validity of given arguments, and so on.  This task
can be greatly simplified by taking advantage of the module ‘(ice-9
getopt-long)’, which is distributed with Guile, *Note getopt-long::.


File: guile.info,  Node: Scripting Examples,  Prev: Command Line Handling,  Up: Guile Scripting

4.3.4 Scripting Examples
------------------------

To start with, here are some examples of invoking Guile directly:

‘guile -- a b c’
     Run Guile interactively; ‘(command-line)’ will return
     ‘("/usr/local/bin/guile" "a" "b" "c")’.

‘guile -s /u/jimb/ex2 a b c’
     Load the file ‘/u/jimb/ex2’; ‘(command-line)’ will return
     ‘("/u/jimb/ex2" "a" "b" "c")’.

‘guile -c '(write %load-path) (newline)'’
     Write the value of the variable ‘%load-path’, print a newline, and
     exit.

‘guile -e main -s /u/jimb/ex4 foo’
     Load the file ‘/u/jimb/ex4’, and then call the function ‘main’,
     passing it the list ‘("/u/jimb/ex4" "foo")’.

‘guile -e '(ex4)' -s /u/jimb/ex4.scm foo’
     Load the file ‘/u/jimb/ex4.scm’, and then call the function ‘main’
     from the module ’(ex4)’, passing it the list ‘("/u/jimb/ex4"
     "foo")’.

‘guile -l first -ds -l last -s script’
     Load the files ‘first’, ‘script’, and ‘last’, in that order.  The
     ‘-ds’ switch says when to process the ‘-s’ switch.  For a more
     motivated example, see the scripts below.

   Here is a very simple Guile script:
     #!/usr/local/bin/guile -s
     !#
     (display "Hello, world!")
     (newline)
   The first line marks the file as a Guile script.  When the user
invokes it, the system runs ‘/usr/local/bin/guile’ to interpret the
script, passing ‘-s’, the script’s filename, and any arguments given to
the script as command-line arguments.  When Guile sees ‘-s SCRIPT’, it
loads SCRIPT.  Thus, running this program produces the output:
     Hello, world!

   Here is a script which prints the factorial of its argument:
     #!/usr/local/bin/guile -s
     !#
     (define (fact n)
       (if (zero? n) 1
         (* n (fact (- n 1)))))

     (display (fact (string->number (cadr (command-line)))))
     (newline)
   In action:
     $ ./fact 5
     120
     $

   However, suppose we want to use the definition of ‘fact’ in this file
from another script.  We can’t simply ‘load’ the script file, and then
use ‘fact’’s definition, because the script will try to compute and
display a factorial when we load it.  To avoid this problem, we might
write the script this way:

     #!/usr/local/bin/guile \
     -e main -s
     !#
     (define (fact n)
       (if (zero? n) 1
         (* n (fact (- n 1)))))

     (define (main args)
       (display (fact (string->number (cadr args))))
       (newline))
   This version packages the actions the script should perform in a
function, ‘main’.  This allows us to load the file purely for its
definitions, without any extraneous computation taking place.  Then we
used the meta switch ‘\’ and the entry point switch ‘-e’ to tell Guile
to call ‘main’ after loading the script.
     $ ./fact 50
     30414093201713378043612608166064768844377641568960512000000000000

   Suppose that we now want to write a script which computes the
‘choose’ function: given a set of M distinct objects, ‘(choose N M)’ is
the number of distinct subsets containing N objects each.  It’s easy to
write ‘choose’ given ‘fact’, so we might write the script this way:

     #!/usr/local/bin/guile \
     -l fact -e main -s
     !#
     (define (choose n m)
       (/ (fact m) (* (fact (- m n)) (fact n))))

     (define (main args)
       (let ((n (string->number (cadr args)))
             (m (string->number (caddr args))))
         (display (choose n m))
         (newline)))

   The command-line arguments here tell Guile to first load the file
‘fact’, and then run the script, with ‘main’ as the entry point.  In
other words, the ‘choose’ script can use definitions made in the ‘fact’
script.  Here are some sample runs:
     $ ./choose 0 4
     1
     $ ./choose 1 4
     4
     $ ./choose 2 4
     6
     $ ./choose 3 4
     4
     $ ./choose 4 4
     1
     $ ./choose 50 100
     100891344545564193334812497256

   To call a specific procedure from a given module, we can use the
special form ‘(@ (MODULE) PROCEDURE)’:

     #!/usr/local/bin/guile \
     -l fact -e (@ (fac) main) -s
     !#
     (define-module (fac)
       #:export (main))

     (define (choose n m)
       (/ (fact m) (* (fact (- m n)) (fact n))))

     (define (main args)
       (let ((n (string->number (cadr args)))
             (m (string->number (caddr args))))
         (display (choose n m))
         (newline)))

   We can use ‘@@’ to invoke non-exported procedures.  For exported
procedures, we can simplify this call with the shorthand ‘(MODULE)’:

     #!/usr/local/bin/guile \
     -l fact -e (fac) -s
     !#
     (define-module (fac)
       #:export (main))

     (define (choose n m)
       (/ (fact m) (* (fact (- m n)) (fact n))))

     (define (main args)
       (let ((n (string->number (cadr args)))
             (m (string->number (caddr args))))
         (display (choose n m))
         (newline)))

   For maximum portability, we can instead use the shell to execute
‘guile’ with specified command line arguments.  Here we need to take
care to quote the command arguments correctly:

     #!/usr/bin/env sh
     exec guile -l fact -e '(@ (fac) main)' -s "$0" "$@"
     !#
     (define-module (fac)
       #:export (main))

     (define (choose n m)
       (/ (fact m) (* (fact (- m n)) (fact n))))

     (define (main args)
       (let ((n (string->number (cadr args)))
             (m (string->number (caddr args))))
         (display (choose n m))
         (newline)))

   Finally, seasoned scripters are probably missing a mention of
subprocesses.  In Bash, for example, most shell scripts run other
programs like ‘sed’ or the like to do the actual work.

   In Guile it’s often possible get everything done within Guile itself,
so do give that a try first.  But if you just need to run a program and
wait for it to finish, use ‘system*’.  If you need to run a sub-program
and capture its output, or give it input, use ‘open-pipe’.  *Note
Processes::, and *Note Pipes::, for more information.


File: guile.info,  Node: Using Guile Interactively,  Next: Using Guile in Emacs,  Prev: Guile Scripting,  Up: Programming in Scheme

4.4 Using Guile Interactively
=============================

When you start up Guile by typing just ‘guile’, without a ‘-c’ argument
or the name of a script to execute, you get an interactive interpreter
where you can enter Scheme expressions, and Guile will evaluate them and
print the results for you.  Here are some simple examples.

     scheme@(guile-user)> (+ 3 4 5)
     $1 = 12
     scheme@(guile-user)> (display "Hello world!\n")
     Hello world!
     scheme@(guile-user)> (values 'a 'b)
     $2 = a
     $3 = b

This mode of use is called a “REPL”, which is short for “Read-Eval-Print
Loop”, because the Guile interpreter first reads the expression that you
have typed, then evaluates it, and then prints the result.

   The prompt shows you what language and module you are in.  In this
case, the current language is ‘scheme’, and the current module is
‘(guile-user)’.  *Note Other Languages::, for more information on
Guile’s support for languages other than Scheme.

* Menu:

* Init File::
* Readline::
* Value History::
* REPL Commands::
* Error Handling::
* Interactive Debugging::


File: guile.info,  Node: Init File,  Next: Readline,  Up: Using Guile Interactively

4.4.1 The Init File, ‘~/.guile’
-------------------------------

When run interactively, Guile will load a local initialization file from
‘~/.guile’.  This file should contain Scheme expressions for evaluation.

   This facility lets the user customize their interactive Guile
environment, pulling in extra modules or parameterizing the REPL
implementation.

   To run Guile without loading the init file, use the ‘-q’ command-line
option.


File: guile.info,  Node: Readline,  Next: Value History,  Prev: Init File,  Up: Using Guile Interactively

4.4.2 Readline
--------------

To make it easier for you to repeat and vary previously entered
expressions, or to edit the expression that you’re typing in, Guile can
use the GNU Readline library.  This is not enabled by default because of
licensing reasons, but all you need to activate Readline is the
following pair of lines.

     scheme@(guile-user)> (use-modules (ice-9 readline))
     scheme@(guile-user)> (activate-readline)

   It’s a good idea to put these two lines (without the
‘scheme@(guile-user)>’ prompts) in your ‘.guile’ file.  *Note Init
File::, for more on ‘.guile’.


File: guile.info,  Node: Value History,  Next: REPL Commands,  Prev: Readline,  Up: Using Guile Interactively

4.4.3 Value History
-------------------

Just as Readline helps you to reuse a previous input line, “value
history” allows you to use the _result_ of a previous evaluation in a
new expression.  When value history is enabled, each evaluation result
is automatically assigned to the next in the sequence of variables ‘$1’,
‘$2’, ....  You can then use these variables in subsequent expressions.

     scheme@(guile-user)> (iota 10)
     $1 = (0 1 2 3 4 5 6 7 8 9)
     scheme@(guile-user)> (apply * (cdr $1))
     $2 = 362880
     scheme@(guile-user)> (sqrt $2)
     $3 = 602.3952191045344
     scheme@(guile-user)> (cons $2 $1)
     $4 = (362880 0 1 2 3 4 5 6 7 8 9)

   Value history is enabled by default, because Guile’s REPL imports the
‘(ice-9 history)’ module.  Value history may be turned off or on within
the repl, using the options interface:

     scheme@(guile-user)> ,option value-history #f
     scheme@(guile-user)> 'foo
     foo
     scheme@(guile-user)> ,option value-history #t
     scheme@(guile-user)> 'bar
     $5 = bar

   Note that previously recorded values are still accessible, even if
value history is off.  In rare cases, these references to past
computations can cause Guile to use too much memory.  One may clear
these values, possibly enabling garbage collection, via the
‘clear-value-history!’ procedure, described below.

   The programmatic interface to value history is in a module:

     (use-modules (ice-9 history))

 -- Scheme Procedure: value-history-enabled?
     Return true if value history is enabled, or false otherwise.

 -- Scheme Procedure: enable-value-history!
     Turn on value history, if it was off.

 -- Scheme Procedure: disable-value-history!
     Turn off value history, if it was on.

 -- Scheme Procedure: clear-value-history!
     Clear the value history.  If the stored values are not captured by
     some other data structure or closure, they may then be reclaimed by
     the garbage collector.


File: guile.info,  Node: REPL Commands,  Next: Error Handling,  Prev: Value History,  Up: Using Guile Interactively

4.4.4 REPL Commands
-------------------

The REPL exists to read expressions, evaluate them, and then print their
results.  But sometimes one wants to tell the REPL to evaluate an
expression in a different way, or to do something else altogether.  A
user can affect the way the REPL works with a “REPL command”.

   The previous section had an example of a command, in the form of
‘,option’.

     scheme@(guile-user)> ,option value-history #t

Commands are distinguished from expressions by their initial comma
(‘,’).  Since a comma cannot begin an expression in most languages, it
is an effective indicator to the REPL that the following text forms a
command, not an expression.

   REPL commands are convenient because they are always there.  Even if
the current module doesn’t have a binding for ‘pretty-print’, one can
always ‘,pretty-print’.

   The following sections document the various commands, grouped
together by functionality.  Many of the commands have abbreviations; see
the online help (‘,help’) for more information.

* Menu:

* Help Commands::
* Module Commands::
* Language Commands::
* Compile Commands::
* Profile Commands::
* Debug Commands::
* Inspect Commands::
* System Commands::


File: guile.info,  Node: Help Commands,  Next: Module Commands,  Up: REPL Commands

4.4.4.1 Help Commands
.....................

When Guile starts interactively, it notifies the user that help can be
had by typing ‘,help’.  Indeed, ‘help’ is a command, and a particularly
useful one, as it allows the user to discover the rest of the commands.

 -- REPL Command: help [‘all’ | group | ‘[-c]’ command]
     Show help.

     With one argument, tries to look up the argument as a group name,
     giving help on that group if successful.  Otherwise tries to look
     up the argument as a command, giving help on the command.

     If there is a command whose name is also a group name, use the ‘-c
     COMMAND’ form to give help on the command instead of the group.

     Without any argument, a list of help commands and command groups
     are displayed.

 -- REPL Command: show [topic]
     Gives information about Guile.

     With one argument, tries to show a particular piece of information;
     currently supported topics are ‘warranty’ (or ‘w’), ‘copying’ (or
     ‘c’), and ‘version’ (or ‘v’).

     Without any argument, a list of topics is displayed.

 -- REPL Command: apropos regexp
     Find bindings/modules/packages.

 -- REPL Command: describe obj
     Show description/documentation.


File: guile.info,  Node: Module Commands,  Next: Language Commands,  Prev: Help Commands,  Up: REPL Commands

4.4.4.2 Module Commands
.......................

 -- REPL Command: module [module]
     Change modules / Show current module.

 -- REPL Command: import module ...
     Import modules / List those imported.

 -- REPL Command: load file
     Load a file in the current module.

 -- REPL Command: reload [module]
     Reload the given module, or the current module if none was given.

 -- REPL Command: binding
     List current bindings.

 -- REPL Command: in module expression
 -- REPL Command: in module command arg ...
     Evaluate an expression, or alternatively, execute another
     meta-command in the context of a module.  For example, ‘,in (foo
     bar) ,binding’ will show the bindings in the module ‘(foo bar)’.


File: guile.info,  Node: Language Commands,  Next: Compile Commands,  Prev: Module Commands,  Up: REPL Commands

4.4.4.3 Language Commands
.........................

 -- REPL Command: language language
     Change languages.


File: guile.info,  Node: Compile Commands,  Next: Profile Commands,  Prev: Language Commands,  Up: REPL Commands

4.4.4.4 Compile Commands
........................

 -- REPL Command: compile exp
     Generate compiled code.

 -- REPL Command: compile-file file
     Compile a file.

 -- REPL Command: expand exp
     Expand any macros in a form.

 -- REPL Command: optimize exp
     Run the optimizer on a piece of code and print the result.

 -- REPL Command: disassemble exp
     Disassemble a compiled procedure.

 -- REPL Command: disassemble-file file
     Disassemble a file.


File: guile.info,  Node: Profile Commands,  Next: Debug Commands,  Prev: Compile Commands,  Up: REPL Commands

4.4.4.5 Profile Commands
........................

 -- REPL Command: time exp
     Time execution.

 -- REPL Command: profile exp [#:hz hz=100] [#:count-calls?
          count-calls?=#f] [#:display-style display-style=list]
     Profile execution of an expression.  This command compiled EXP and
     then runs it within the statprof profiler, passing all keyword
     options to the ‘statprof’ procedure.  For more on statprof and on
     the the options available to this command, *Note Statprof::.

 -- REPL Command: trace exp [#:width w] [#:max-indent i]
     Trace execution.

     By default, the trace will limit its width to the width of your
     terminal, or WIDTH if specified.  Nested procedure invocations will
     be printed farther to the right, though if the width of the
     indentation passes the MAX-INDENT, the indentation is abbreviated.

   These REPL commands can also be called as regular functions in scheme
code on including the ‘(ice-9 time)’ module.


File: guile.info,  Node: Debug Commands,  Next: Inspect Commands,  Prev: Profile Commands,  Up: REPL Commands

4.4.4.6 Debug Commands
......................

These debugging commands are only available within a recursive REPL;
they do not work at the top level.

 -- REPL Command: backtrace [count] [#:width w] [#:full? f]
     Print a backtrace.

     Print a backtrace of all stack frames, or innermost COUNT frames.
     If COUNT is negative, the last COUNT frames will be shown.

 -- REPL Command: up [count]
     Select a calling stack frame.

     Select and print stack frames that called this one.  An argument
     says how many frames up to go.

 -- REPL Command: down [count]
     Select a called stack frame.

     Select and print stack frames called by this one.  An argument says
     how many frames down to go.

 -- REPL Command: frame [idx]
     Show a frame.

     Show the selected frame.  With an argument, select a frame by
     index, then show it.

 -- REPL Command: locals
     Show local variables.

     Show locally-bound variables in the selected frame.

 -- REPL Command: error-message
 -- REPL Command: error
     Show error message.

     Display the message associated with the error that started the
     current debugging REPL.

 -- REPL Command: registers
     Show the VM registers associated with the current frame.

     *Note Stack Layout::, for more information on VM stack frames.

 -- REPL Command: width [cols]
     Sets the number of display columns in the output of ‘,backtrace’
     and ‘,locals’ to COLS.  If COLS is not given, the width of the
     terminal is used.

   The next 3 commands work at any REPL.

 -- REPL Command: break proc
     Set a breakpoint at PROC.

 -- REPL Command: break-at-source file line
     Set a breakpoint at the given source location.

 -- REPL Command: tracepoint proc
     Set a tracepoint on the given procedure.  This will cause all calls
     to the procedure to print out a tracing message.  *Note Tracing
     Traps::, for more information.

   The rest of the commands in this subsection all apply only when the
stack is “continuable” — in other words when it makes sense for the
program that the stack comes from to continue running.  Usually this
means that the program stopped because of a trap or a breakpoint.

 -- REPL Command: step
     Tell the debugged program to step to the next source location.

 -- REPL Command: next
     Tell the debugged program to step to the next source location in
     the same frame.  (See *note Traps:: for the details of how this
     works.)

 -- REPL Command: finish
     Tell the program being debugged to continue running until the
     completion of the current stack frame, and at that time to print
     the result and reenter the REPL.


File: guile.info,  Node: Inspect Commands,  Next: System Commands,  Prev: Debug Commands,  Up: REPL Commands

4.4.4.7 Inspect Commands
........................

 -- REPL Command: inspect exp
     Inspect the result(s) of evaluating EXP.

 -- REPL Command: pretty-print exp
     Pretty-print the result(s) of evaluating EXP.


File: guile.info,  Node: System Commands,  Prev: Inspect Commands,  Up: REPL Commands

4.4.4.8 System Commands
.......................

 -- REPL Command: gc
     Garbage collection.

 -- REPL Command: statistics
     Display statistics.

 -- REPL Command: option [name] [exp]
     With no arguments, lists all options.  With one argument, shows the
     current value of the NAME option.  With two arguments, sets the
     NAME option to the result of evaluating the Scheme expression EXP.

 -- REPL Command: quit
     Quit this session.

   Current REPL options include:

‘compile-options’
     The options used when compiling expressions entered at the REPL.
     *Note Compilation::, for more on compilation options.
‘interp’
     Whether to interpret or compile expressions given at the REPL, if
     such a choice is available.  Off by default (indicating
     compilation).
‘prompt’
     A customized REPL prompt.  ‘#f’ by default, indicating the default
     prompt.
‘print’
     A procedure of two arguments used to print the result of evaluating
     each expression.  The arguments are the current REPL and the value
     to print.  By default, ‘#f’, to use the default procedure.
‘value-history’
     Whether value history is on or not.  *Note Value History::.
‘on-error’
     What to do when an error happens.  By default, ‘debug’, meaning to
     enter the debugger.  Other values include ‘backtrace’, to show a
     backtrace without entering the debugger, or ‘report’, to simply
     show a short error printout.

   Default values for REPL options may be set using
‘repl-default-option-set!’ from ‘(system repl common)’:

 -- Scheme Procedure: repl-default-option-set! key value
     Set the default value of a REPL option.  This function is
     particularly useful in a user’s init file.  *Note Init File::.


File: guile.info,  Node: Error Handling,  Next: Interactive Debugging,  Prev: REPL Commands,  Up: Using Guile Interactively

4.4.5 Error Handling
--------------------

When code being evaluated from the REPL hits an error, Guile enters a
new prompt, allowing you to inspect the context of the error.

     scheme@(guile-user)> (map string-append '("a" "b") '("c" #\d))
     ERROR: In procedure string-append:
     ERROR: Wrong type (expecting string): #\d
     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
     scheme@(guile-user) [1]>

   The new prompt runs inside the old one, in the dynamic context of the
error.  It is a recursive REPL, augmented with a reified representation
of the stack, ready for debugging.

   ‘,backtrace’ (abbreviated ‘,bt’) displays the Scheme call stack at
the point where the error occurred:

     scheme@(guile-user) [1]> ,bt
                1 (map #<procedure string-append _> ("a" "b") ("c" #\d))
                0 (string-append "b" #\d)

   In the above example, the backtrace doesn’t have much source
information, as ‘map’ and ‘string-append’ are both primitives.  But in
the general case, the space on the left of the backtrace indicates the
line and column in which a given procedure calls another.

   You can exit a recursive REPL in the same way that you exit any REPL:
via ‘(quit)’, ‘,quit’ (abbreviated ‘,q’), or ‘C-d’, among other options.


File: guile.info,  Node: Interactive Debugging,  Prev: Error Handling,  Up: Using Guile Interactively

4.4.6 Interactive Debugging
---------------------------

A recursive debugging REPL exposes a number of other meta-commands that
inspect the state of the computation at the time of the error.  These
commands allow you to

   • display the Scheme call stack at the point where the error
     occurred;

   • move up and down the call stack, to see in detail the expression
     being evaluated, or the procedure being applied, in each “frame”;
     and

   • examine the values of variables and expressions in the context of
     each frame.

*Note Debug Commands::, for documentation of the individual commands.
This section aims to give more of a walkthrough of a typical debugging
session.

   First, we’re going to need a good error.  Let’s try to macroexpand
the expression ‘(unquote foo)’, outside of a ‘quasiquote’ form, and see
how the macroexpander reports this error.

     scheme@(guile-user)> (macroexpand '(unquote foo))
     ERROR: In procedure macroexpand:
     ERROR: unquote: expression not valid outside of quasiquote in (unquote foo)
     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
     scheme@(guile-user) [1]>

   The ‘backtrace’ command, which can also be invoked as ‘bt’, displays
the call stack (aka backtrace) at the point where the debugger was
entered:

     scheme@(guile-user) [1]> ,bt
     In ice-9/psyntax.scm:
       1130:21  3 (chi-top (unquote foo) () ((top)) e (eval) (hygiene #))
       1071:30  2 (syntax-type (unquote foo) () ((top)) #f #f (# #) #f)
       1368:28  1 (chi-macro #<procedure de9360 at ice-9/psyntax.scm...> ...)
     In unknown file:
                0 (scm-error syntax-error macroexpand "~a: ~a in ~a" # #f)

   A call stack consists of a sequence of stack “frames”, with each
frame describing one procedure which is waiting to do something with the
values returned by another.  Here we see that there are four frames on
the stack.

   Note that ‘macroexpand’ is not on the stack – it must have made a
tail call to ‘chi-top’, as indeed we would find if we searched
‘ice-9/psyntax.scm’ for its definition.

   When you enter the debugger, the innermost frame is selected, which
means that the commands for getting information about the “current”
frame, or for evaluating expressions in the context of the current
frame, will do so by default with respect to the innermost frame.  To
select a different frame, so that these operations will apply to it
instead, use the ‘up’, ‘down’ and ‘frame’ commands like this:

     scheme@(guile-user) [1]> ,up
     In ice-9/psyntax.scm:
       1368:28  1 (chi-macro #<procedure de9360 at ice-9/psyntax.scm...> ...)
     scheme@(guile-user) [1]> ,frame 3
     In ice-9/psyntax.scm:
       1130:21  3 (chi-top (unquote foo) () ((top)) e (eval) (hygiene #))
     scheme@(guile-user) [1]> ,down
     In ice-9/psyntax.scm:
       1071:30  2 (syntax-type (unquote foo) () ((top)) #f #f (# #) #f)

   Perhaps we’re interested in what’s going on in frame 2, so we take a
look at its local variables:

     scheme@(guile-user) [1]> ,locals
       Local variables:
       $1 = e = (unquote foo)
       $2 = r = ()
       $3 = w = ((top))
       $4 = s = #f
       $5 = rib = #f
       $6 = mod = (hygiene guile-user)
       $7 = for-car? = #f
       $8 = first = unquote
       $9 = ftype = macro
       $10 = fval = #<procedure de9360 at ice-9/psyntax.scm:2817:2 (x)>
       $11 = fe = unquote
       $12 = fw = ((top))
       $13 = fs = #f
       $14 = fmod = (hygiene guile-user)

   All of the values are accessible by their value-history names (‘$N’):

     scheme@(guile-user) [1]> $10
     $15 = #<procedure de9360 at ice-9/psyntax.scm:2817:2 (x)>

   We can even invoke the procedure at the REPL directly:

     scheme@(guile-user) [1]> ($10 'not-going-to-work)
     ERROR: In procedure macroexpand:
     ERROR: source expression failed to match any pattern in not-going-to-work
     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

   Well at this point we’ve caused an error within an error.  Let’s just
quit back to the top level:

     scheme@(guile-user) [2]> ,q
     scheme@(guile-user) [1]> ,q
     scheme@(guile-user)>

   Finally, as a word to the wise: hackers close their REPL prompts with
‘C-d’.


File: guile.info,  Node: Using Guile in Emacs,  Next: Using Guile Tools,  Prev: Using Guile Interactively,  Up: Programming in Scheme

4.5 Using Guile in Emacs
========================

Any text editor can edit Scheme, but some are better than others.  Emacs
is the best, of course, and not just because it is a fine text editor.
Emacs has good support for Scheme out of the box, with sensible
indentation rules, parenthesis-matching, syntax highlighting, and even a
set of keybindings for structural editing, allowing navigation,
cut-and-paste, and transposition operations that work on balanced
S-expressions.

   As good as it is, though, two things will vastly improve your
experience with Emacs and Guile.

   The first is Taylor Campbell’s Paredit
(http://www.emacswiki.org/emacs/ParEdit).  You should not code in any
dialect of Lisp without Paredit.  (They say that unopinionated writing
is boring—hence this tone—but it’s the truth, regardless.)  Paredit is
the bee’s knees.

   The second is José Antonio Ortega Ruiz’s Geiser
(http://www.nongnu.org/geiser/).  Geiser complements Emacs’
‘scheme-mode’ with tight integration to running Guile processes via a
‘comint-mode’ REPL buffer.

   Of course there are keybindings to switch to the REPL, and a good
REPL environment, but Geiser goes beyond that, providing:

   • Form evaluation in the context of the current file’s module.
   • Macro expansion.
   • File/module loading and/or compilation.
   • Namespace-aware identifier completion (including local bindings,
     names visible in the current module, and module names).
   • Autodoc: the echo area shows information about the signature of the
     procedure/macro around point automatically.
   • Jump to definition of identifier at point.
   • Access to documentation (including docstrings when the
     implementation provides it).
   • Listings of identifiers exported by a given module.
   • Listings of callers/callees of procedures.
   • Rudimentary support for debugging and error navigation.
   • Support for multiple, simultaneous REPLs.

   See Geiser’s web page at <http://www.nongnu.org/geiser/>, for more
information.


File: guile.info,  Node: Using Guile Tools,  Next: Installing Site Packages,  Prev: Using Guile in Emacs,  Up: Programming in Scheme

4.6 Using Guile Tools
=====================

Guile also comes with a growing number of command-line utilities: a
compiler, a disassembler, some module inspectors, and in the future, a
system to install Guile packages from the internet.  These tools may be
invoked using the ‘guild’ program.

     $ guild compile -o foo.go foo.scm
     wrote `foo.go'

   This program used to be called ‘guile-tools’ up to Guile version
2.0.1, and for backward compatibility it still may be called as such.
However we changed the name to ‘guild’, not only because it is
pleasantly shorter and easier to read, but also because this tool will
serve to bind Guile wizards together, by allowing hackers to share code
with each other using a CPAN-like system.

   *Note Compilation::, for more on ‘guild compile’.

   A complete list of guild scripts can be had by invoking ‘guild list’,
or simply ‘guild’.


File: guile.info,  Node: Installing Site Packages,  Next: Distributing Guile Code,  Prev: Using Guile Tools,  Up: Programming in Scheme

4.7 Installing Site Packages
============================

At some point, you will probably want to share your code with other
people.  To do so effectively, it is important to follow a set of common
conventions, to make it easy for the user to install and use your
package.

   The first thing to do is to install your Scheme files where Guile can
find them.  When Guile goes to find a Scheme file, it will search a
“load path” to find the file: first in Guile’s own path, then in paths
for “site packages”.  A site package is any Scheme code that is
installed and not part of Guile itself.  *Note Load Paths::, for more on
load paths.

   There are several site paths, for historical reasons, but the one
that should generally be used can be obtained by invoking the
‘%site-dir’ procedure.  *Note Build Config::.  If Guile 3.0 is installed
on your system in ‘/usr/’, then ‘(%site-dir)’ will be
‘/usr/share/guile/site/3.0’.  Scheme files should be installed there.

   If you do not install compiled ‘.go’ files, Guile will compile your
modules and programs when they are first used, and cache them in the
user’s home directory.  *Note Compilation::, for more on
auto-compilation.  However, it is better to compile the files before
they are installed, and to just copy the files to a place that Guile can
find them.

   As with Scheme files, Guile searches a path to find compiled ‘.go’
files, the ‘%load-compiled-path’.  By default, this path has two
entries: a path for Guile’s files, and a path for site packages.  You
should install your ‘.go’ files into the latter directory, whose value
is returned by invoking the ‘%site-ccache-dir’ procedure.  As in the
previous example, if Guile 3.0 is installed on your system in ‘/usr/’,
then ‘(%site-ccache-dir)’ site packages will be
‘/usr/lib/guile/3.0/site-ccache’.

   Note that a ‘.go’ file will only be loaded in preference to a ‘.scm’
file if it is newer.  For that reason, you should install your Scheme
files first, and your compiled files second.  *Note Load Paths::, for
more on the loading process.

   Finally, although this section is only about Scheme, sometimes you
need to install C extensions too.  Shared libraries should be installed
in the “extensions dir”.  This value can be had from the build config
(*note Build Config::).  Again, if Guile 3.0 is installed on your system
in ‘/usr/’, then the extensions dir will be
‘/usr/lib/guile/3.0/extensions’.


File: guile.info,  Node: Distributing Guile Code,  Prev: Installing Site Packages,  Up: Programming in Scheme

4.8 Distributing Guile Code
===========================

There’s a tool that doesn’t come bundled with Guile and yet can be very
useful in your day to day experience with it.  This tool is Hall
(https://gitlab.com/a-sassmannshausen/guile-hall).

   Hall helps you create, manage, and package your Guile projects
through a simple command-line interface.  When you start a new project,
Hall creates a folder containing a scaffold of your new project.  It
contains a directory for your tests, for your libraries, for your
scripts and for your documentation.  This means you immediately know
where to put the files you are hacking on.

   In addition, the scaffold will include your basic “Autotools” setup,
so you don’t have to take care of that yourself (*note (autoconf)The GNU
Build System::, for more information on the GNU “Autotools”).  Having
Autotools set up with your project means you can immediately start
hacking on your project without worrying about whether your code will
work on other people’s computers.  Hall can also generate package
definitions for the GNU Guix package manager, making it easy for Guix
users to install it.


File: guile.info,  Node: Programming in C,  Next: API Reference,  Prev: Programming in Scheme,  Up: Top

5 Programming in C
******************

This part of the manual explains the general concepts that you need to
understand when interfacing to Guile from C. You will learn about how
the latent typing of Scheme is embedded into the static typing of C, how
the garbage collection of Guile is made available to C code, and how
continuations influence the control flow in a C program.

   This knowledge should make it straightforward to add new functions to
Guile that can be called from Scheme.  Adding new data types is also
possible and is done by defining “foreign objects”.

   The *note Programming Overview:: section of this part contains
general musings and guidelines about programming with Guile.  It
explores different ways to design a program around Guile, or how to
embed Guile into existing programs.

   For a pedagogical yet detailed explanation of how the data
representation of Guile is implemented, *Note Data Representation::.
You don’t need to know the details given there to use Guile from C, but
they are useful when you want to modify Guile itself or when you are
just curious about how it is all done.

   For detailed reference information on the variables, functions etc.
that make up Guile’s application programming interface (API), *Note API
Reference::.

* Menu:

* Parallel Installations::      Finding the right Guile.
* Linking Programs With Guile:: More precisely, with the libguile library.
* Linking Guile with Libraries::  To extend Guile itself.
* General Libguile Concepts::   General concepts for using libguile.
* Defining New Foreign Object Types::  Adding new types to Guile.
* Function Snarfing::           A way to define new functions.
* Programming Overview::        An overview of Guile programming.
* Autoconf Support::            Putting m4 to good use.


File: guile.info,  Node: Parallel Installations,  Next: Linking Programs With Guile,  Up: Programming in C

5.1 Parallel Installations
==========================

Guile provides strong API and ABI stability guarantees during stable
series, so that if a user writes a program against Guile version 2.2.3,
it will be compatible with some future version 2.2.7.  We say in this
case that 2.2 is the “effective version”, composed of the major and
minor versions, in this case 2 and 2.

   Users may install multiple effective versions of Guile, with each
version’s headers, libraries, and Scheme files under their own
directories.  This provides the necessary stability guarantee for users,
while also allowing Guile developers to evolve the language and its
implementation.

   However, parallel installability does have a down-side, in that users
need to know which version of Guile to ask for, when they build against
Guile.  Guile solves this problem by installing a file to be read by the
‘pkg-config’ utility, a tool to query installed packages by name.  Guile
encodes the version into its pkg-config name, so that users can ask for
‘guile-2.2’ or ‘guile-3.0’, as appropriate.

   For effective version 3.0, for example, you would invoke ‘pkg-config
--cflags --libs guile-3.0’ to get the compilation and linking flags
necessary to link to version 3.0 of Guile.  You would typically run
‘pkg-config’ during the configuration phase of your program and use the
obtained information in the Makefile.

   Guile’s ‘pkg-config’ file, ‘guile-3.0.pc’, defines additional useful
variables:

‘sitedir’
     The default directory where Guile looks for Scheme source and
     compiled files (*note %site-dir: Installing Site Packages.).  Run
     ‘pkg-config guile-3.0 --variable=sitedir’ to see its value.  *Note
     GUILE_SITE_DIR: Autoconf Macros, for more on how to use it from
     Autoconf.

‘extensiondir’
     The default directory where Guile looks for extensions—i.e., shared
     libraries providing additional features (*note Foreign
     Extensions::).  Run ‘pkg-config guile-3.0 --variable=extensiondir’
     to see its value.

‘guile’
‘guild’
     The absolute file name of the ‘guile’ and ‘guild’ commands(1).  Run
     ‘pkg-config guile-3.0 --variable=guile’ or ‘--variable=guild’ to
     see their value.

     These variables allow users to deal with program name
     transformations that may be specified when configuring Guile with
     ‘--program-transform-name’, ‘--program-suffix’, or
     ‘--program-prefix’ (*note (autoconf)Transformation Options::).

See the ‘pkg-config’ man page, for more information, or its web site,
<http://pkg-config.freedesktop.org/>.  *Note Autoconf Support::, for
more on checking for Guile from within a ‘configure.ac’ file.

   ---------- Footnotes ----------

   (1) The ‘guile’ and ‘guild’ variables defined starting from Guile
version 2.0.12.


File: guile.info,  Node: Linking Programs With Guile,  Next: Linking Guile with Libraries,  Prev: Parallel Installations,  Up: Programming in C

5.2 Linking Programs With Guile
===============================

This section covers the mechanics of linking your program with Guile on
a typical POSIX system.

   The header file ‘<libguile.h>’ provides declarations for all of
Guile’s functions and constants.  You should ‘#include’ it at the head
of any C source file that uses identifiers described in this manual.
Once you’ve compiled your source files, you need to link them against
the Guile object code library, ‘libguile’.

   As noted in the previous section, ‘<libguile.h>’ is not in the
default search path for headers.  The following command lines give
respectively the C compilation and link flags needed to build programs
using Guile 3.0:

     pkg-config guile-3.0 --cflags
     pkg-config guile-3.0 --libs

* Menu:

* Guile Initialization Functions::  What to call first.
* A Sample Guile Main Program::  Sources and makefiles.


File: guile.info,  Node: Guile Initialization Functions,  Next: A Sample Guile Main Program,  Up: Linking Programs With Guile

5.2.1 Guile Initialization Functions
------------------------------------

To initialize Guile, you can use one of several functions.  The first,
‘scm_with_guile’, is the most portable way to initialize Guile.  It will
initialize Guile when necessary and then call a function that you can
specify.  Multiple threads can call ‘scm_with_guile’ concurrently and it
can also be called more than once in a given thread.  The global state
of Guile will survive from one call of ‘scm_with_guile’ to the next.
Your function is called from within ‘scm_with_guile’ since the garbage
collector of Guile needs to know where the stack of each thread is.

   A second function, ‘scm_init_guile’, initializes Guile for the
current thread.  When it returns, you can use the Guile API in the
current thread.  This function employs some non-portable magic to learn
about stack bounds and might thus not be available on all platforms.

   One common way to use Guile is to write a set of C functions which
perform some useful task, make them callable from Scheme, and then link
the program with Guile.  This yields a Scheme interpreter just like
‘guile’, but augmented with extra functions for some specific
application — a special-purpose scripting language.

   In this situation, the application should probably process its
command-line arguments in the same manner as the stock Guile
interpreter.  To make that straightforward, Guile provides the
‘scm_boot_guile’ and ‘scm_shell’ function.

   For more about these functions, see *note Initialization::.


File: guile.info,  Node: A Sample Guile Main Program,  Prev: Guile Initialization Functions,  Up: Linking Programs With Guile

5.2.2 A Sample Guile Main Program
---------------------------------

Here is ‘simple-guile.c’, source code for a ‘main’ and an ‘inner_main’
function that will produce a complete Guile interpreter.

     /* simple-guile.c --- Start Guile from C.  */

     #include <libguile.h>

     static void
     inner_main (void *closure, int argc, char **argv)
     {
       /* preparation */
       scm_shell (argc, argv);
       /* after exit */
     }

     int
     main (int argc, char **argv)
     {
       scm_boot_guile (argc, argv, inner_main, 0);
       return 0; /* never reached, see inner_main */
     }

   The ‘main’ function calls ‘scm_boot_guile’ to initialize Guile,
passing it ‘inner_main’.  Once ‘scm_boot_guile’ is ready, it invokes
‘inner_main’, which calls ‘scm_shell’ to process the command-line
arguments in the usual way.

5.2.3 Building the Example with Make
------------------------------------

Here is a Makefile which you can use to compile the example program.  It
uses ‘pkg-config’ to learn about the necessary compiler and linker
flags.
     # Use GCC, if you have it installed.
     CC=gcc

     # Tell the C compiler where to find <libguile.h>
     CFLAGS=`pkg-config --cflags guile-3.0`

     # Tell the linker what libraries to use and where to find them.
     LIBS=`pkg-config --libs guile-3.0`

     simple-guile: simple-guile.o
             ${CC} simple-guile.o ${LIBS} -o simple-guile

     simple-guile.o: simple-guile.c
             ${CC} -c ${CFLAGS} simple-guile.c

5.2.4 Building the Example with Autoconf
----------------------------------------

If you are using the GNU Autoconf package to make your application more
portable, Autoconf will settle many of the details in the Makefile
automatically, making it much simpler and more portable; we recommend
using Autoconf with Guile.  Here is a ‘configure.ac’ file for
‘simple-guile’ that uses the standard ‘PKG_CHECK_MODULES’ macro to check
for Guile.  Autoconf will process this file into a ‘configure’ script.
We recommend invoking Autoconf via the ‘autoreconf’ utility.

     AC_INIT(simple-guile.c)

     # Find a C compiler.
     AC_PROG_CC

     # Check for Guile
     PKG_CHECK_MODULES([GUILE], [guile-3.0])

     # Generate a Makefile, based on the results.
     AC_OUTPUT(Makefile)

   Run ‘autoreconf -vif’ to generate ‘configure’.

   Here is a ‘Makefile.in’ template, from which the ‘configure’ script
produces a Makefile customized for the host system:
     # The configure script fills in these values.
     CC=@CC@
     CFLAGS=@GUILE_CFLAGS@
     LIBS=@GUILE_LIBS@

     simple-guile: simple-guile.o
             ${CC} simple-guile.o ${LIBS} -o simple-guile
     simple-guile.o: simple-guile.c
             ${CC} -c ${CFLAGS} simple-guile.c

   The developer should use Autoconf to generate the ‘configure’ script
from the ‘configure.ac’ template, and distribute ‘configure’ with the
application.  Here’s how a user might go about building the application:

     $ ls
     Makefile.in     configure*      configure.ac    simple-guile.c
     $ ./configure
     checking for gcc... ccache gcc
     checking whether the C compiler works... yes
     checking for C compiler default output file name... a.out
     checking for suffix of executables...
     checking whether we are cross compiling... no
     checking for suffix of object files... o
     checking whether we are using the GNU C compiler... yes
     checking whether ccache gcc accepts -g... yes
     checking for ccache gcc option to accept ISO C89... none needed
     checking for pkg-config... /usr/bin/pkg-config
     checking pkg-config is at least version 0.9.0... yes
     checking for GUILE... yes
     configure: creating ./config.status
     config.status: creating Makefile
     $ make
     [...]
     $ ./simple-guile
     guile> (+ 1 2 3)
     6
     guile> (getpwnam "jimb")
     #("jimb" "83Z7d75W2tyJQ" 4008 10 "Jim Blandy" "/u/jimb"
       "/usr/local/bin/bash")
     guile> (exit)
     $


File: guile.info,  Node: Linking Guile with Libraries,  Next: General Libguile Concepts,  Prev: Linking Programs With Guile,  Up: Programming in C

5.3 Linking Guile with Libraries
================================

The previous section has briefly explained how to write programs that
make use of an embedded Guile interpreter.  But sometimes, all you want
to do is make new primitive procedures and data types available to the
Scheme programmer.  Writing a new version of ‘guile’ is inconvenient in
this case and it would in fact make the life of the users of your new
features needlessly hard.

   For example, suppose that there is a program ‘guile-db’ that is a
version of Guile with additional features for accessing a database.
People who want to write Scheme programs that use these features would
have to use ‘guile-db’ instead of the usual ‘guile’ program.  Now
suppose that there is also a program ‘guile-gtk’ that extends Guile with
access to the popular Gtk+ toolkit for graphical user interfaces.
People who want to write GUIs in Scheme would have to use ‘guile-gtk’.
Now, what happens when you want to write a Scheme application that uses
a GUI to let the user access a database?  You would have to write a
_third_ program that incorporates both the database stuff and the GUI
stuff.  This might not be easy (because ‘guile-gtk’ might be a quite
obscure program, say) and taking this example further makes it easy to
see that this approach can not work in practice.

   It would have been much better if both the database features and the
GUI feature had been provided as libraries that can just be linked with
‘guile’.  Guile makes it easy to do just this, and we encourage you to
make your extensions to Guile available as libraries whenever possible.

   You write the new primitive procedures and data types in the normal
fashion, and link them into a shared library instead of into a
stand-alone program.  The shared library can then be loaded dynamically
by Guile.

* Menu:

* A Sample Guile Extension::


File: guile.info,  Node: A Sample Guile Extension,  Up: Linking Guile with Libraries

5.3.1 A Sample Guile Extension
------------------------------

This section explains how to make the Bessel functions of the C library
available to Scheme.  First we need to write the appropriate glue code
to convert the arguments and return values of the functions from Scheme
to C and back.  Additionally, we need a function that will add them to
the set of Guile primitives.  Because this is just an example, we will
only implement this for the ‘j0’ function.

   Consider the following file ‘bessel.c’.

     #include <math.h>
     #include <libguile.h>

     SCM
     j0_wrapper (SCM x)
     {
       return scm_from_double (j0 (scm_to_double (x)));
     }

     void
     init_bessel ()
     {
       scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper);
     }

   This C source file needs to be compiled into a shared library.  Here
is how to do it on GNU/Linux:

     gcc `pkg-config --cflags guile-3.0` \
       -shared -o libguile-bessel.so -fPIC bessel.c

   For creating shared libraries portably, we recommend the use of GNU
Libtool (*note Introduction: (libtool)Top.).

   A shared library can be loaded into a running Guile process with the
function ‘load-extension’.  In addition to the name of the library to
load, this function also expects the name of a function from that
library that will be called to initialize it.  For our example, we are
going to call the function ‘init_bessel’ which will make ‘j0_wrapper’
available to Scheme programs with the name ‘j0’.  Note that we do not
specify a filename extension such as ‘.so’ when invoking
‘load-extension’.  The right extension for the host platform will be
provided automatically.

     (load-extension "libguile-bessel" "init_bessel")
     (j0 2)
     ⇒ 0.223890779141236

   For this to work, ‘load-extension’ must be able to find
‘libguile-bessel’, of course.  It will look in the places that are usual
for your operating system, and it will additionally look into the
directories listed in the ‘LTDL_LIBRARY_PATH’ environment variable.

   To see how these Guile extensions via shared libraries relate to the
module system, *Note Putting Extensions into Modules::.


File: guile.info,  Node: General Libguile Concepts,  Next: Defining New Foreign Object Types,  Prev: Linking Guile with Libraries,  Up: Programming in C

5.4 General concepts for using libguile
=======================================

When you want to embed the Guile Scheme interpreter into your program or
library, you need to link it against the ‘libguile’ library (*note
Linking Programs With Guile::).  Once you have done this, your C code
has access to a number of data types and functions that can be used to
invoke the interpreter, or make new functions that you have written in C
available to be called from Scheme code, among other things.

   Scheme is different from C in a number of significant ways, and Guile
tries to make the advantages of Scheme available to C as well.  Thus, in
addition to a Scheme interpreter, libguile also offers dynamic types,
garbage collection, continuations, arithmetic on arbitrary sized
numbers, and other things.

   The two fundamental concepts are dynamic types and garbage
collection.  You need to understand how libguile offers them to C
programs in order to use the rest of libguile.  Also, the more general
control flow of Scheme caused by continuations needs to be dealt with.

   Running asynchronous signal handlers and multi-threading is known to
C code already, but there are of course a few additional rules when
using them together with libguile.

* Menu:

* Dynamic Types::               Dynamic Types.
* Garbage Collection::          Garbage Collection.
* Control Flow::                Control Flow.
* Asynchronous Signals::        Asynchronous Signals
* Multi-Threading::             Multi-Threading


File: guile.info,  Node: Dynamic Types,  Next: Garbage Collection,  Up: General Libguile Concepts

5.4.1 Dynamic Types
-------------------

Scheme is a dynamically-typed language; this means that the system
cannot, in general, determine the type of a given expression at compile
time.  Types only become apparent at run time.  Variables do not have
fixed types; a variable may hold a pair at one point, an integer at the
next, and a thousand-element vector later.  Instead, values, not
variables, have fixed types.

   In order to implement standard Scheme functions like ‘pair?’ and
‘string?’ and provide garbage collection, the representation of every
value must contain enough information to accurately determine its type
at run time.  Often, Scheme systems also use this information to
determine whether a program has attempted to apply an operation to an
inappropriately typed value (such as taking the ‘car’ of a string).

   Because variables, pairs, and vectors may hold values of any type,
Scheme implementations use a uniform representation for values — a
single type large enough to hold either a complete value or a pointer to
a complete value, along with the necessary typing information.

   In Guile, this uniform representation of all Scheme values is the C
type ‘SCM’.  This is an opaque type and its size is typically equivalent
to that of a pointer to ‘void’.  Thus, ‘SCM’ values can be passed around
efficiently and they take up reasonably little storage on their own.

   The most important rule is: You never access a ‘SCM’ value directly;
you only pass it to functions or macros defined in libguile.

   As an obvious example, although a ‘SCM’ variable can contain
integers, you can of course not compute the sum of two ‘SCM’ values by
adding them with the C ‘+’ operator.  You must use the libguile function
‘scm_sum’.

   Less obvious and therefore more important to keep in mind is that you
also cannot directly test ‘SCM’ values for trueness.  In Scheme, the
value ‘#f’ is considered false and of course a ‘SCM’ variable can
represent that value.  But there is no guarantee that the ‘SCM’
representation of ‘#f’ looks false to C code as well.  You need to use
‘scm_is_true’ or ‘scm_is_false’ to test a ‘SCM’ value for trueness or
falseness, respectively.

   You also can not directly compare two ‘SCM’ values to find out
whether they are identical (that is, whether they are ‘eq?’ in Scheme
terms).  You need to use ‘scm_is_eq’ for this.

   The one exception is that you can directly assign a ‘SCM’ value to a
‘SCM’ variable by using the C ‘=’ operator.

   The following (contrived) example shows how to do it right.  It
implements a function of two arguments (A and FLAG) that returns A+1 if
FLAG is true, else it returns A unchanged.

     SCM
     my_incrementing_function (SCM a, SCM flag)
     {
       SCM result;

       if (scm_is_true (flag))
         result = scm_sum (a, scm_from_int (1));
       else
         result = a;

       return result;
     }

   Often, you need to convert between ‘SCM’ values and appropriate C
values.  For example, we needed to convert the integer ‘1’ to its ‘SCM’
representation in order to add it to A.  Libguile provides many function
to do these conversions, both from C to ‘SCM’ and from ‘SCM’ to C.

   The conversion functions follow a common naming pattern: those that
make a ‘SCM’ value from a C value have names of the form ‘scm_from_TYPE
(...)’ and those that convert a ‘SCM’ value to a C value use the form
‘scm_to_TYPE (...)’.

   However, it is best to avoid converting values when you can.  When
you must combine C values and ‘SCM’ values in a computation, it is often
better to convert the C values to ‘SCM’ values and do the computation by
using libguile functions than to the other way around (converting ‘SCM’
to C and doing the computation some other way).

   As a simple example, consider this version of
‘my_incrementing_function’ from above:

     SCM
     my_other_incrementing_function (SCM a, SCM flag)
     {
       int result;

       if (scm_is_true (flag))
         result = scm_to_int (a) + 1;
       else
         result = scm_to_int (a);

       return scm_from_int (result);
     }

   This version is much less general than the original one: it will only
work for values A that can fit into a ‘int’.  The original function will
work for all values that Guile can represent and that ‘scm_sum’ can
understand, including integers bigger than ‘long long’, floating point
numbers, complex numbers, and new numerical types that have been added
to Guile by third-party libraries.

   Also, computing with ‘SCM’ is not necessarily inefficient.  Small
integers will be encoded directly in the ‘SCM’ value, for example, and
do not need any additional memory on the heap.  See *note Data
Representation:: to find out the details.

   Some special ‘SCM’ values are available to C code without needing to
convert them from C values:

Scheme value   C representation
#f             SCM_BOOL_F
#t             SCM_BOOL_T
()             SCM_EOL

   In addition to ‘SCM’, Guile also defines the related type
‘scm_t_bits’.  This is an unsigned integral type of sufficient size to
hold all information that is directly contained in a ‘SCM’ value.  The
‘scm_t_bits’ type is used internally by Guile to do all the bit
twiddling explained in *note Data Representation::, but you will
encounter it occasionally in low-level user code as well.


File: guile.info,  Node: Garbage Collection,  Next: Control Flow,  Prev: Dynamic Types,  Up: General Libguile Concepts

5.4.2 Garbage Collection
------------------------

As explained above, the ‘SCM’ type can represent all Scheme values.
Some values fit entirely into a ‘SCM’ value (such as small integers),
but other values require additional storage in the heap (such as strings
and vectors).  This additional storage is managed automatically by
Guile.  You don’t need to explicitly deallocate it when a ‘SCM’ value is
no longer used.

   Two things must be guaranteed so that Guile is able to manage the
storage automatically: it must know about all blocks of memory that have
ever been allocated for Scheme values, and it must know about all Scheme
values that are still being used.  Given this knowledge, Guile can
periodically free all blocks that have been allocated but are not used
by any active Scheme values.  This activity is called “garbage
collection”.

   Guile’s garbage collector will automatically discover references to
‘SCM’ objects that originate in global variables, static data sections,
function arguments or local variables on the C and Scheme stacks, and
values in machine registers.  Other references to ‘SCM’ objects, such as
those in other random data structures in the C heap that contain fields
of type ‘SCM’, can be made visible to the garbage collector by calling
the functions ‘scm_gc_protect_object’ or ‘scm_permanent_object’.
Collectively, these values form the “root set” of garbage collection;
any value on the heap that is referenced directly or indirectly by a
member of the root set is preserved, and all other objects are eligible
for reclamation.

   In Guile, garbage collection has two logical phases: the “mark
phase”, in which the collector discovers the set of all live objects,
and the “sweep phase”, in which the collector reclaims the resources
associated with dead objects.  The mark phase pauses the program and
traces all ‘SCM’ object references, starting with the root set.  The
sweep phase actually runs concurrently with the main program,
incrementally reclaiming memory as needed by allocation.

   In the mark phase, the garbage collector traces the Scheme stack and
heap “precisely”.  Because the Scheme stack and heap are managed by
Guile, Guile can know precisely where in those data structures it might
find references to other heap objects.  This is not the case,
unfortunately, for pointers on the C stack and static data segment.
Instead of requiring the user to inform Guile about all variables in C
that might point to heap objects, Guile traces the C stack and static
data segment “conservatively”.  That is to say, Guile just treats every
word on the C stack and every C global variable as a potential reference
in to the Scheme heap(1).  Any value that looks like a pointer to a
GC-managed object is treated as such, whether it actually is a reference
or not.  Thus, scanning the C stack and static data segment is
guaranteed to find all actual references, but it might also find words
that only accidentally look like references.  These “false positives”
might keep ‘SCM’ objects alive that would otherwise be considered dead.
While this might waste memory, keeping an object around longer than it
strictly needs to is harmless.  This is why this technique is called
“conservative garbage collection”.  In practice, the wasted memory seems
to be no problem, as the static C root set is almost always finite and
small, given that the Scheme stack is separate from the C stack.

   The stack of every thread is scanned in this way and the registers of
the CPU and all other memory locations where local variables or function
parameters might show up are included in this scan as well.

   The consequence of the conservative scanning is that you can just
declare local variables and function parameters of type ‘SCM’ and be
sure that the garbage collector will not free the corresponding objects.

   However, a local variable or function parameter is only protected as
long as it is really on the stack (or in some register).  As an
optimization, the C compiler might reuse its location for some other
value and the ‘SCM’ object would no longer be protected.  Normally, this
leads to exactly the right behavior: the compiler will only overwrite a
reference when it is no longer needed and thus the object becomes
unprotected precisely when the reference disappears, just as wanted.

   There are situations, however, where a ‘SCM’ object needs to be
around longer than its reference from a local variable or function
parameter.  This happens, for example, when you retrieve some pointer
from a foreign object and work with that pointer directly.  The
reference to the ‘SCM’ foreign object might be dead after the pointer
has been retrieved, but the pointer itself (and the memory pointed to)
is still in use and thus the foreign object must be protected.  The
compiler does not know about this connection and might overwrite the
‘SCM’ reference too early.

   To get around this problem, you can use ‘scm_remember_upto_here_1’
and its cousins.  It will keep the compiler from overwriting the
reference.  *Note Foreign Object Memory Management::.

   ---------- Footnotes ----------

   (1) Note that Guile does not scan the C heap for references, so a
reference to a ‘SCM’ object from a memory segment allocated with
‘malloc’ will have to use some other means to keep the ‘SCM’ object
alive.  *Note Garbage Collection Functions::.


File: guile.info,  Node: Control Flow,  Next: Asynchronous Signals,  Prev: Garbage Collection,  Up: General Libguile Concepts

5.4.3 Control Flow
------------------

Scheme has a more general view of program flow than C, both locally and
non-locally.

   Controlling the local flow of control involves things like gotos,
loops, calling functions and returning from them.  Non-local control
flow refers to situations where the program jumps across one or more
levels of function activations without using the normal call or return
operations.

   The primitive means of C for local control flow is the ‘goto’
statement, together with ‘if’.  Loops done with ‘for’, ‘while’ or ‘do’
could in principle be rewritten with just ‘goto’ and ‘if’.  In Scheme,
the primitive means for local control flow is the _function call_
(together with ‘if’).  Thus, the repetition of some computation in a
loop is ultimately implemented by a function that calls itself, that is,
by recursion.

   This approach is theoretically very powerful since it is easier to
reason formally about recursion than about gotos.  In C, using recursion
exclusively would not be practical, though, since it would eat up the
stack very quickly.  In Scheme, however, it is practical: function calls
that appear in a “tail position” do not use any additional stack space
(*note Tail Calls::).

   A function call is in a tail position when it is the last thing the
calling function does.  The value returned by the called function is
immediately returned from the calling function.  In the following
example, the call to ‘bar-1’ is in a tail position, while the call to
‘bar-2’ is not.  (The call to ‘1-’ in ‘foo-2’ is in a tail position,
though.)

     (define (foo-1 x)
       (bar-1 (1- x)))

     (define (foo-2 x)
       (1- (bar-2 x)))

   Thus, when you take care to recurse only in tail positions, the
recursion will only use constant stack space and will be as good as a
loop constructed from gotos.

   Scheme offers a few syntactic abstractions (‘do’ and “named” ‘let’)
that make writing loops slightly easier.

   But only Scheme functions can call other functions in a tail
position: C functions can not.  This matters when you have, say, two
functions that call each other recursively to form a common loop.  The
following (unrealistic) example shows how one might go about determining
whether a non-negative integer N is even or odd.

     (define (my-even? n)
       (cond ((zero? n) #t)
             (else (my-odd? (1- n)))))

     (define (my-odd? n)
       (cond ((zero? n) #f)
             (else (my-even? (1- n)))))

   Because the calls to ‘my-even?’ and ‘my-odd?’ are in tail positions,
these two procedures can be applied to arbitrary large integers without
overflowing the stack.  (They will still take a lot of time, of course.)

   However, when one or both of the two procedures would be rewritten in
C, it could no longer call its companion in a tail position (since C
does not have this concept).  You might need to take this consideration
into account when deciding which parts of your program to write in
Scheme and which in C.

   In addition to calling functions and returning from them, a Scheme
program can also exit non-locally from a function so that the control
flow returns directly to an outer level.  This means that some functions
might not return at all.

   Even more, it is not only possible to jump to some outer level of
control, a Scheme program can also jump back into the middle of a
function that has already exited.  This might cause some functions to
return more than once.

   In general, these non-local jumps are done by invoking
“continuations” that have previously been captured using
‘call-with-current-continuation’.  Guile also offers a slightly
restricted set of functions, ‘catch’ and ‘throw’, that can only be used
for non-local exits.  This restriction makes them more efficient.  Error
reporting (with the function ‘error’) is implemented by invoking
‘throw’, for example.  The functions ‘catch’ and ‘throw’ belong to the
topic of “exceptions”.

   Since Scheme functions can call C functions and vice versa, C code
can experience the more general control flow of Scheme as well.  It is
possible that a C function will not return at all, or will return more
than once.  While C does offer ‘setjmp’ and ‘longjmp’ for non-local
exits, it is still an unusual thing for C code.  In contrast, non-local
exits are very common in Scheme, mostly to report errors.

   You need to be prepared for the non-local jumps in the control flow
whenever you use a function from ‘libguile’: it is best to assume that
any ‘libguile’ function might signal an error or run a pending signal
handler (which in turn can do arbitrary things).

   It is often necessary to take cleanup actions when the control leaves
a function non-locally.  Also, when the control returns non-locally,
some setup actions might be called for.  For example, the Scheme
function ‘with-output-to-port’ needs to modify the global state so that
‘current-output-port’ returns the port passed to ‘with-output-to-port’.
The global output port needs to be reset to its previous value when
‘with-output-to-port’ returns normally or when it is exited non-locally.
Likewise, the port needs to be set again when control enters
non-locally.

   Scheme code can use the ‘dynamic-wind’ function to arrange for the
setting and resetting of the global state.  C code can use the
corresponding ‘scm_internal_dynamic_wind’ function, or a
‘scm_dynwind_begin’/‘scm_dynwind_end’ pair together with suitable
’dynwind actions’ (*note Dynamic Wind::).

   Instead of coping with non-local control flow, you can also prevent
it by erecting a _continuation barrier_, *Note Continuation Barriers::.
The function ‘scm_c_with_continuation_barrier’, for example, is
guaranteed to return exactly once.


File: guile.info,  Node: Asynchronous Signals,  Next: Multi-Threading,  Prev: Control Flow,  Up: General Libguile Concepts

5.4.4 Asynchronous Signals
--------------------------

You can not call libguile functions from handlers for POSIX signals, but
you can register Scheme handlers for POSIX signals such as ‘SIGINT’.
These handlers do not run during the actual signal delivery.  Instead,
they are run when the program (more precisely, the thread that the
handler has been registered for) reaches the next _safe point_.

   The libguile functions themselves have many such safe points.
Consequently, you must be prepared for arbitrary actions anytime you
call a libguile function.  For example, even ‘scm_cons’ can contain a
safe point and when a signal handler is pending for your thread, calling
‘scm_cons’ will run this handler and anything might happen, including a
non-local exit although ‘scm_cons’ would not ordinarily do such a thing
on its own.

   If you do not want to allow the running of asynchronous signal
handlers, you can block them temporarily with
‘scm_dynwind_block_asyncs’, for example.  *Note Asyncs::.

   Since signal handling in Guile relies on safe points, you need to
make sure that your functions do offer enough of them.  Normally,
calling libguile functions in the normal course of action is all that is
needed.  But when a thread might spent a long time in a code section
that calls no libguile function, it is good to include explicit safe
points.  This can allow the user to interrupt your code with <C-c>, for
example.

   You can do this with the macro ‘SCM_TICK’.  This macro is
syntactically a statement.  That is, you could use it like this:

     while (1)
       {
         SCM_TICK;
         do_some_work ();
       }

   Frequent execution of a safe point is even more important in multi
threaded programs, *Note Multi-Threading::.


File: guile.info,  Node: Multi-Threading,  Prev: Asynchronous Signals,  Up: General Libguile Concepts

5.4.5 Multi-Threading
---------------------

Guile can be used in multi-threaded programs just as well as in
single-threaded ones.

   Each thread that wants to use functions from libguile must put itself
into _guile mode_ and must then follow a few rules.  If it doesn’t want
to honor these rules in certain situations, a thread can temporarily
leave guile mode (but can no longer use libguile functions during that
time, of course).

   Threads enter guile mode by calling ‘scm_with_guile’,
‘scm_boot_guile’, or ‘scm_init_guile’.  As explained in the reference
documentation for these functions, Guile will then learn about the stack
bounds of the thread and can protect the ‘SCM’ values that are stored in
local variables.  When a thread puts itself into guile mode for the
first time, it gets a Scheme representation and is listed by
‘all-threads’, for example.

   Threads in guile mode can block (e.g., do blocking I/O) without
causing any problems(1); temporarily leaving guile mode with
‘scm_without_guile’ before blocking slightly improves GC performance,
though.  For some common blocking operations, Guile provides convenience
functions.  For example, if you want to lock a pthread mutex while in
guile mode, you might want to use ‘scm_pthread_mutex_lock’ which is just
like ‘pthread_mutex_lock’ except that it leaves guile mode while
blocking.

   All libguile functions are (intended to be) robust in the face of
multiple threads using them concurrently.  This means that there is no
risk of the internal data structures of libguile becoming corrupted in
such a way that the process crashes.

   A program might still produce nonsensical results, though.  Taking
hashtables as an example, Guile guarantees that you can use them from
multiple threads concurrently and a hashtable will always remain a valid
hashtable and Guile will not crash when you access it.  It does not
guarantee, however, that inserting into it concurrently from two threads
will give useful results: only one insertion might actually happen, none
might happen, or the table might in general be modified in a totally
arbitrary manner.  (It will still be a valid hashtable, but not the one
that you might have expected.)  Guile might also signal an error when it
detects a harmful race condition.

   Thus, you need to put in additional synchronizations when multiple
threads want to use a single hashtable, or any other mutable Scheme
object.

   When writing C code for use with libguile, you should try to make it
robust as well.  An example that converts a list into a vector will help
to illustrate.  Here is a correct version:

     SCM
     my_list_to_vector (SCM list)
     {
       SCM vector = scm_make_vector (scm_length (list), SCM_UNDEFINED);
       size_t len, i;

       len = scm_c_vector_length (vector);
       i = 0;
       while (i < len && scm_is_pair (list))
         {
           scm_c_vector_set_x (vector, i, scm_car (list));
           list = scm_cdr (list);
           i++;
         }

       return vector;
     }

   The first thing to note is that storing into a ‘SCM’ location
concurrently from multiple threads is guaranteed to be robust: you don’t
know which value wins but it will in any case be a valid ‘SCM’ value.

   But there is no guarantee that the list referenced by LIST is not
modified in another thread while the loop iterates over it.  Thus, while
copying its elements into the vector, the list might get longer or
shorter.  For this reason, the loop must check both that it doesn’t
overrun the vector and that it doesn’t overrun the list.  Otherwise,
‘scm_c_vector_set_x’ would raise an error if the index is out of range,
and ‘scm_car’ and ‘scm_cdr’ would raise an error if the value is not a
pair.

   It is safe to use ‘scm_car’ and ‘scm_cdr’ on the local variable LIST
once it is known that the variable contains a pair.  The contents of the
pair might change spontaneously, but it will always stay a valid pair
(and a local variable will of course not spontaneously point to a
different Scheme object).

   Likewise, a vector such as the one returned by ‘scm_make_vector’ is
guaranteed to always stay the same length so that it is safe to only use
scm_c_vector_length once and store the result.  (In the example, VECTOR
is safe anyway since it is a fresh object that no other thread can
possibly know about until it is returned from ‘my_list_to_vector’.)

   Of course the behavior of ‘my_list_to_vector’ is suboptimal when LIST
does indeed get asynchronously lengthened or shortened in another
thread.  But it is robust: it will always return a valid vector.  That
vector might be shorter than expected, or its last elements might be
unspecified, but it is a valid vector and if a program wants to rule out
these cases, it must avoid modifying the list asynchronously.

   Here is another version that is also correct:

     SCM
     my_pedantic_list_to_vector (SCM list)
     {
       SCM vector = scm_make_vector (scm_length (list), SCM_UNDEFINED);
       size_t len, i;

       len = scm_c_vector_length (vector);
       i = 0;
       while (i < len)
         {
           scm_c_vector_set_x (vector, i, scm_car (list));
           list = scm_cdr (list);
           i++;
         }

       return vector;
     }

   This version relies on the error-checking behavior of ‘scm_car’ and
‘scm_cdr’.  When the list is shortened (that is, when LIST holds a
non-pair), ‘scm_car’ will throw an error.  This might be preferable to
just returning a half-initialized vector.

   The API for accessing vectors and arrays of various kinds from C
takes a slightly different approach to thread-robustness.  In order to
get at the raw memory that stores the elements of an array, you need to
_reserve_ that array as long as you need the raw memory.  During the
time an array is reserved, its elements can still spontaneously change
their values, but the memory itself and other things like the size of
the array are guaranteed to stay fixed.  Any operation that would change
these parameters of an array that is currently reserved will signal an
error.  In order to avoid these errors, a program should of course put
suitable synchronization mechanisms in place.  As you can see, Guile
itself is again only concerned about robustness, not about correctness:
without proper synchronization, your program will likely not be correct,
but the worst consequence is an error message.

   Real thread-safety often requires that a critical section of code is
executed in a certain restricted manner.  A common requirement is that
the code section is not entered a second time when it is already being
executed.  Locking a mutex while in that section ensures that no other
thread will start executing it, blocking asyncs ensures that no
asynchronous code enters the section again from the current thread, and
the error checking of Guile mutexes guarantees that an error is
signalled when the current thread accidentally reenters the critical
section via recursive function calls.

   Guile provides two mechanisms to support critical sections as
outlined above.  You can either use the macros
‘SCM_CRITICAL_SECTION_START’ and ‘SCM_CRITICAL_SECTION_END’ for very
simple sections; or use a dynwind context together with a call to
‘scm_dynwind_critical_section’.

   The macros only work reliably for critical sections that are
guaranteed to not cause a non-local exit.  They also do not detect an
accidental reentry by the current thread.  Thus, you should probably
only use them to delimit critical sections that do not contain calls to
libguile functions or to other external functions that might do
complicated things.

   The function ‘scm_dynwind_critical_section’, on the other hand, will
correctly deal with non-local exits because it requires a dynwind
context.  Also, by using a separate mutex for each critical section, it
can detect accidental reentries.

   ---------- Footnotes ----------

   (1) In Guile 1.8, a thread blocking in guile mode would prevent
garbage collection to occur.  Thus, threads had to leave guile mode
whenever they could block.  This is no longer needed with Guile 2.X.


File: guile.info,  Node: Defining New Foreign Object Types,  Next: Function Snarfing,  Prev: General Libguile Concepts,  Up: Programming in C

5.5 Defining New Foreign Object Types
=====================================

The “foreign object type” facility is Guile’s mechanism for importing
object and types from C or other languages into Guile’s system.  If you
have a C ‘struct foo’ type, for example, you can define a corresponding
Guile foreign object type that allows Scheme code to handle ‘struct foo
*’ objects.

   To define a new foreign object type, the programmer provides Guile
with some essential information about the type — what its name is, how
many fields it has, and its finalizer (if any) — and Guile allocates a
fresh type for it.  Foreign objects can be accessed from Scheme or from
C.

* Menu:

* Defining Foreign Object Types::
* Creating Foreign Objects::
* Type Checking of Foreign Objects::
* Foreign Object Memory Management::
* Foreign Objects and Scheme::


File: guile.info,  Node: Defining Foreign Object Types,  Next: Creating Foreign Objects,  Up: Defining New Foreign Object Types

5.5.1 Defining Foreign Object Types
-----------------------------------

To create a new foreign object type from C, call
‘scm_make_foreign_object_type’.  It returns a value of type ‘SCM’ which
identifies the new type.

   Here is how one might declare a new type representing eight-bit
gray-scale images:

     #include <libguile.h>

     struct image {
       int width, height;
       char *pixels;

       /* The name of this image */
       SCM name;

       /* A function to call when this image is
          modified, e.g., to update the screen,
          or SCM_BOOL_F if no action necessary */
       SCM update_func;
     };

     static SCM image_type;

     void
     init_image_type (void)
     {
       SCM name, slots;
       scm_t_struct_finalize finalizer;

       name = scm_from_utf8_symbol ("image");
       slots = scm_list_1 (scm_from_utf8_symbol ("data"));
       finalizer = NULL;

       image_type =
         scm_make_foreign_object_type (name, slots, finalizer);
     }

   The result is an initialized ‘image_type’ value that identifies the
new foreign object type.  The next section describes how to create
foreign objects and how to access their slots.


File: guile.info,  Node: Creating Foreign Objects,  Next: Type Checking of Foreign Objects,  Prev: Defining Foreign Object Types,  Up: Defining New Foreign Object Types

5.5.2 Creating Foreign Objects
------------------------------

Foreign objects contain zero or more “slots” of data.  A slot can hold a
pointer, an integer that fits into a ‘size_t’ or ‘ssize_t’, or a ‘SCM’
value.

   All objects of a given foreign type have the same number of slots.
In the example from the previous section, the ‘image’ type has one slot,
because the slots list passed to ‘scm_make_foreign_object_type’ is of
length one.  (The actual names given to slots are unimportant for most
users of the C interface, but can be used on the Scheme side to
introspect on the foreign object.)

   To construct a foreign object and initialize its first slot, call
‘scm_make_foreign_object_1 (TYPE, FIRST_SLOT_VALUE)’.  There are
similarly named constructors for initializing 0, 1, 2, or 3 slots, or
initializing N slots via an array.  *Note Foreign Objects::, for full
details.  Any fields that are not explicitly initialized are set to 0.

   To get or set the value of a slot by index, you can use the
‘scm_foreign_object_ref’ and ‘scm_foreign_object_set_x’ functions.
These functions take and return values as ‘void *’ pointers; there are
corresponding convenience procedures like ‘_signed_ref’,
‘_unsigned_set_x’ and so on for dealing with slots as signed or unsigned
integers.

   Foreign objects fields that are pointers can be tricky to manage.  If
possible, it is best that all memory that is referenced by a foreign
object be managed by the garbage collector.  That way, the GC can
automatically ensure that memory is accessible when it is needed, and
freed when it becomes inaccessible.  If this is not the case for your
program – for example, if you are exposing an object to Scheme that was
allocated by some other, Guile-unaware part of your program – then you
will probably need to implement a finalizer.  *Note Foreign Object
Memory Management::, for more.

   Continuing the example from the previous section, if the global
variable ‘image_type’ contains the type returned by
‘scm_make_foreign_object_type’, here is how we could construct a foreign
object whose “data” field contains a pointer to a freshly allocated
‘struct image’:

     SCM
     make_image (SCM name, SCM s_width, SCM s_height)
     {
       struct image *image;
       int width = scm_to_int (s_width);
       int height = scm_to_int (s_height);

       /* Allocate the `struct image'.  Because we
          use scm_gc_malloc, this memory block will
          be automatically reclaimed when it becomes
          inaccessible, and its members will be traced
          by the garbage collector.  */
       image = (struct image *)
         scm_gc_malloc (sizeof (struct image), "image");

       image->width = width;
       image->height = height;

       /* Allocating the pixels with
          scm_gc_malloc_pointerless means that the
          pixels data is collectable by GC, but
          that GC shouldn't spend time tracing its
          contents for nested pointers because there
          aren't any.  */
       image->pixels =
         scm_gc_malloc_pointerless (width * height, "image pixels");

       image->name = name;
       image->update_func = SCM_BOOL_F;

       /* Now wrap the struct image* in a new foreign
          object, and return that object.  */
       return scm_make_foreign_object_1 (image_type, image);
     }

   We use ‘scm_gc_malloc_pointerless’ for the pixel buffer to tell the
garbage collector not to scan it for pointers.  Calls to
‘scm_gc_malloc’, ‘scm_make_foreign_object_1’, and
‘scm_gc_malloc_pointerless’ raise an exception in out-of-memory
conditions; the garbage collector is able to reclaim previously
allocated memory if that happens.


File: guile.info,  Node: Type Checking of Foreign Objects,  Next: Foreign Object Memory Management,  Prev: Creating Foreign Objects,  Up: Defining New Foreign Object Types

5.5.3 Type Checking of Foreign Objects
--------------------------------------

Functions that operate on foreign objects should check that the passed
‘SCM’ value indeed is of the correct type before accessing its data.
They can do this with ‘scm_assert_foreign_object_type’.

   For example, here is a simple function that operates on an image
object, and checks the type of its argument.

     SCM
     clear_image (SCM image_obj)
     {
       int area;
       struct image *image;

       scm_assert_foreign_object_type (image_type, image_obj);

       image = scm_foreign_object_ref (image_obj, 0);
       area = image->width * image->height;
       memset (image->pixels, 0, area);

       /* Invoke the image's update function.  */
       if (scm_is_true (image->update_func))
         scm_call_0 (image->update_func);

       return SCM_UNSPECIFIED;
     }


File: guile.info,  Node: Foreign Object Memory Management,  Next: Foreign Objects and Scheme,  Prev: Type Checking of Foreign Objects,  Up: Defining New Foreign Object Types

5.5.4 Foreign Object Memory Management
--------------------------------------

Once a foreign object has been released to the tender mercies of the
Scheme system, it must be prepared to survive garbage collection.  In
the example above, all the memory associated with the foreign object is
managed by the garbage collector because we used the ‘scm_gc_’
allocation functions.  Thus, no special care must be taken: the garbage
collector automatically scans them and reclaims any unused memory.

   However, when data associated with a foreign object is managed in
some other way—e.g., ‘malloc’’d memory or file descriptors—it is
possible to specify a “finalizer” function to release those resources
when the foreign object is reclaimed.

   As discussed in *note Garbage Collection::, Guile’s garbage collector
will reclaim inaccessible memory as needed.  This reclamation process
runs concurrently with the main program.  When Guile analyzes the heap
and determines that an object’s memory can be reclaimed, that memory is
put on a “free list” of objects that can be reclaimed.  Usually that’s
the end of it—the object is available for immediate re-use.  However
some objects can have “finalizers” associated with them—functions that
are called on reclaimable objects to effect any external cleanup
actions.

   Finalizers are tricky business and it is best to avoid them.  They
can be invoked at unexpected times, or not at all—for example, they are
not invoked on process exit.  They don’t help the garbage collector do
its job; in fact, they are a hindrance.  Furthermore, they perturb the
garbage collector’s internal accounting.  The GC decides to scan the
heap when it thinks that it is necessary, after some amount of
allocation.  Finalizable objects almost always represent an amount of
allocation that is invisible to the garbage collector.  The effect can
be that the actual resource usage of a system with finalizable objects
is higher than what the GC thinks it should be.

   All those caveats aside, some foreign object types will need
finalizers.  For example, if we had a foreign object type that wrapped
file descriptors—and we aren’t suggesting this, as Guile already has
ports —then you might define the type like this:

     static SCM file_type;

     static void
     finalize_file (SCM file)
     {
       int fd = scm_foreign_object_signed_ref (file, 0);
       if (fd >= 0)
         {
           scm_foreign_object_signed_set_x (file, 0, -1);
           close (fd);
         }
     }

     static void
     init_file_type (void)
     {
       SCM name, slots;
       scm_t_struct_finalize finalizer;

       name = scm_from_utf8_symbol ("file");
       slots = scm_list_1 (scm_from_utf8_symbol ("fd"));
       finalizer = finalize_file;

       image_type =
         scm_make_foreign_object_type (name, slots, finalizer);
     }

     static SCM
     make_file (int fd)
     {
       return scm_make_foreign_object_1 (file_type, (void *) fd);
     }

   Note that the finalizer may be invoked in ways and at times you might
not expect.  In a Guile built without threading support, finalizers are
invoked via “asyncs”, which interleaves them with running Scheme code;
*note Asyncs::.  If the user’s Guile is built with support for threads,
the finalizer will probably be called by a dedicated finalization
thread, unless the user invokes ‘scm_run_finalizers ()’ explicitly.

   In either case, finalizers run concurrently with the main program,
and so they need to be async-safe and thread-safe.  If for some reason
this is impossible, perhaps because you are embedding Guile in some
application that is not itself thread-safe, you have a few options.  One
is to use guardians instead of finalizers, and arrange to pump the
guardians for finalizable objects.  *Note Guardians::, for more
information.  The other option is to disable automatic finalization
entirely, and arrange to call ‘scm_run_finalizers ()’ at appropriate
points.  *Note Foreign Objects::, for more on these interfaces.

   Finalizers are allowed to allocate memory, access GC-managed memory,
and in general can do anything any Guile user code can do.  This was not
the case in Guile 1.8, where finalizers were much more restricted.  In
particular, in Guile 2.0, finalizers can resuscitate objects.  We do not
recommend that users avail themselves of this possibility, however, as a
resuscitated object can re-expose other finalizable objects that have
been already finalized back to Scheme.  These objects will not be
finalized again, but they could cause use-after-free problems to code
that handles objects of that particular foreign object type.  To guard
against this possibility, robust finalization routines should clear
state from the foreign object, as in the above ‘free_file’ example.

   One final caveat.  Foreign object finalizers are associated with the
lifetime of a foreign object, not of its fields.  If you access a field
of a finalizable foreign object, and do not arrange to keep a reference
on the foreign object itself, it could be that the outer foreign object
gets finalized while you are working with its field.

   For example, consider a procedure to read some data from a file, from
our example above.

     SCM
     read_bytes (SCM file, SCM n)
     {
       int fd;
       SCM buf;
       size_t len, pos;

       scm_assert_foreign_object_type (file_type, file);

       fd = scm_foreign_object_signed_ref (file, 0);
       if (fd < 0)
         scm_wrong_type_arg_msg ("read-bytes", SCM_ARG1,
                                 file, "open file");

       len = scm_to_size_t (n);
       SCM buf = scm_c_make_bytevector (scm_to_size_t (n));

       pos = 0;
       while (pos < len)
         {
           char *bytes = SCM_BYTEVECTOR_CONTENTS (buf);
           ssize_t count = read (fd, bytes + pos, len - pos);
           if (count < 0)
             scm_syserror ("read-bytes");
           if (count == 0)
             break;
           pos += count;
         }

       scm_remember_upto_here_1 (file);

       return scm_values (scm_list_2 (buf, scm_from_size_t (pos)));
     }

   After the prelude, only the ‘fd’ value is used and the C compiler has
no reason to keep the ‘file’ object around.  If ‘scm_c_make_bytevector’
results in a garbage collection, ‘file’ might not be on the stack or
anywhere else and could be finalized, leaving ‘read’ to read a closed
(or, in a multi-threaded program, possibly re-used) file descriptor.
The use of ‘scm_remember_upto_here_1’ prevents this, by creating a
reference to ‘file’ after all data accesses.  *Note Garbage Collection
Functions::.

   ‘scm_remember_upto_here_1’ is only needed on finalizable objects,
because garbage collection of other values is invisible to the program –
it happens when needed, and is not observable.  But if you can, save
yourself the headache and build your program in such a way that it
doesn’t need finalization.


File: guile.info,  Node: Foreign Objects and Scheme,  Prev: Foreign Object Memory Management,  Up: Defining New Foreign Object Types

5.5.5 Foreign Objects and Scheme
--------------------------------

It is also possible to create foreign objects and object types from
Scheme, and to access fields of foreign objects from Scheme.  For
example, the file example from the last section could be equivalently
expressed as:

     (define-module (my-file)
       #:use-module (system foreign-object)
       #:use-module ((oop goops) #:select (make))
       #:export (make-file))

     (define (finalize-file file)
       (let ((fd (struct-ref file 0)))
         (unless (< fd 0)
           (struct-set! file 0 -1)
           (close-fdes fd))))

     (define <file>
       (make-foreign-object-type '<file> '(fd)
                                 #:finalizer finalize-file))

     (define (make-file fd)
       (make <file> #:fd fd))

   Here we see that the result of ‘make-foreign-object-type’, which is
the equivalent of ‘scm_make_foreign_object_type’, is a struct vtable.
*Note Vtables::, for more information.  To instantiate the foreign
object, which is really a Guile struct, we use ‘make’.  (We could have
used ‘make-struct/no-tail’, but as an implementation detail, finalizers
are attached in the ‘initialize’ method called by ‘make’).  To access
the fields, we use ‘struct-ref’ and ‘struct-set!’.  *Note Structure
Basics::.

   There is a convenience syntax, ‘define-foreign-object-type’, that
defines a type along with a constructor, and getters for the fields.  An
appropriate invocation of ‘define-foreign-object-type’ for the file
object type could look like this:

     (use-modules (system foreign-object))

     (define-foreign-object-type <file>
       make-file
       (fd)
       #:finalizer finalize-file)

   This defines the ‘<file>’ type with one field, a ‘make-file’
constructor, and a getter for the ‘fd’ field, bound to ‘fd’.

   Foreign object types are not only vtables but are actually GOOPS
classes, as hinted at above.  *Note GOOPS::, for more on Guile’s
object-oriented programming system.  Thus one can define print and
equality methods using GOOPS:

     (use-modules (oop goops))

     (define-method (write (file <file>) port)
       ;; Assuming existence of the `fd' getter
       (format port "#<<file> ~a>" (fd file)))

     (define-method (equal? (a <file>) (b <file>))
       (eqv? (fd a) (fd b)))

   One can even sub-class foreign types.

     (define-class <named-file> (<file>)
       (name #:init-keyword #:name #:init-value #f #:accessor name))

   The question arises of how to construct these values, given that
‘make-file’ returns a plain old ‘<file>’ object.  It turns out that you
can use the GOOPS construction interface, where every field of the
foreign object has an associated initialization keyword argument.

     (define* (my-open-file name #:optional (flags O_RDONLY))
       (make <named-file> #:fd (open-fdes name flags) #:name name))

     (define-method (write (file <named-file>) port)
       (format port "#<<file> ~s ~a>" (name file) (fd file)))

   *Note Foreign Objects::, for full documentation on the Scheme
interface to foreign objects.  *Note GOOPS::, for more on GOOPS.

   As a final note, you might wonder how this system supports
encapsulation of sensitive values.  First, we have to recognize that
some facilities are essentially unsafe and have global scope.  For
example, in C, the integrity and confidentiality of a part of a program
is at the mercy of every other part of that program – because any part
of the program can read and write anything in its address space.  At the
same time, principled access to structured data is organized in C on
lexical boundaries; if you don’t expose accessors for your object, you
trust other parts of the program not to work around that barrier.

   The situation is not dissimilar in Scheme.  Although Scheme’s unsafe
constructs are fewer in number than in C, they do exist.  The ‘(system
foreign)’ module can be used to violate confidentiality and integrity,
and shouldn’t be exposed to untrusted code.  Although ‘struct-ref’ and
‘struct-set!’ are less unsafe, they still have a cross-cutting
capability of drilling through abstractions.  Performing a ‘struct-set!’
on a foreign object slot could cause unsafe foreign code to crash.
Ultimately, structures in Scheme are capabilities for abstraction, and
not abstractions themselves.

   That leaves us with the lexical capabilities, like constructors and
accessors.  Here is where encapsulation lies: the practical degree to
which the innards of your foreign objects are exposed is the degree to
which their accessors are lexically available in user code.  If you want
to allow users to reference fields of your foreign object, provide them
with a getter.  Otherwise you should assume that the only access to your
object may come from your code, which has the relevant authority, or via
code with access to cross-cutting ‘struct-ref’ and such, which also has
the cross-cutting authority.


File: guile.info,  Node: Function Snarfing,  Next: Programming Overview,  Prev: Defining New Foreign Object Types,  Up: Programming in C

5.6 Function Snarfing
=====================

When writing C code for use with Guile, you typically define a set of C
functions, and then make some of them visible to the Scheme world by
calling ‘scm_c_define_gsubr’ or related functions.  If you have many
functions to publish, it can sometimes be annoying to keep the list of
calls to ‘scm_c_define_gsubr’ in sync with the list of function
definitions.

   Guile provides the ‘guile-snarf’ program to manage this problem.
Using this tool, you can keep all the information needed to define the
function alongside the function definition itself; ‘guile-snarf’ will
extract this information from your source code, and automatically
generate a file of calls to ‘scm_c_define_gsubr’ which you can
‘#include’ into an initialization function.

   The snarfing mechanism works for many kind of initialization actions,
not just for collecting calls to ‘scm_c_define_gsubr’.  For a full list
of what can be done, *Note Snarfing Macros::.

   The ‘guile-snarf’ program is invoked like this:

     guile-snarf [-o OUTFILE] [CPP-ARGS ...]

   This command will extract initialization actions to OUTFILE.  When no
OUTFILE has been specified or when OUTFILE is ‘-’, standard output will
be used.  The C preprocessor is called with CPP-ARGS (which usually
include an input file) and the output is filtered to extract the
initialization actions.

   If there are errors during processing, OUTFILE is deleted and the
program exits with non-zero status.

   During snarfing, the pre-processor macro ‘SCM_MAGIC_SNARFER’ is
defined.  You could use this to avoid including snarfer output files
that don’t yet exist by writing code like this:

     #ifndef SCM_MAGIC_SNARFER
     #include "foo.x"
     #endif

   Here is how you might define the Scheme function ‘clear-image’,
implemented by the C function ‘clear_image’:

     #include <libguile.h>

     SCM_DEFINE (clear_image, "clear-image", 1, 0, 0,
                 (SCM image),
                 "Clear the image.")
     {
       /* C code to clear the image in image... */
     }

     void
     init_image_type ()
     {
     #include "image-type.x"
     }

   The ‘SCM_DEFINE’ declaration says that the C function ‘clear_image’
implements a Scheme function called ‘clear-image’, which takes one
required argument (of type ‘SCM’ and named ‘image’), no optional
arguments, and no rest argument.  The string ‘"Clear the image."’
provides a short help text for the function, it is called a “docstring”.

   ‘SCM_DEFINE’ macro also defines a static array of characters
initialized to the Scheme name of the function.  In this case,
‘s_clear_image’ is set to the C string, "clear-image".  You might want
to use this symbol when generating error messages.

   Assuming the text above lives in a file named ‘image-type.c’, you
will need to execute the following command to prepare this file for
compilation:

     guile-snarf -o image-type.x image-type.c

   This scans ‘image-type.c’ for ‘SCM_DEFINE’ declarations, and writes
to ‘image-type.x’ the output:

     scm_c_define_gsubr ("clear-image", 1, 0, 0, (SCM (*)() ) clear_image);

   When compiled normally, ‘SCM_DEFINE’ is a macro which expands to the
function header for ‘clear_image’.

   Note that the output file name matches the ‘#include’ from the input
file.  Also, you still need to provide all the same information you
would if you were using ‘scm_c_define_gsubr’ yourself, but you can place
the information near the function definition itself, so it is less
likely to become incorrect or out-of-date.

   If you have many files that ‘guile-snarf’ must process, you should
consider using a fragment like the following in your Makefile:

     snarfcppopts = $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)
     .SUFFIXES: .x
     .c.x:
     	guile-snarf -o $@ $< $(snarfcppopts)

   This tells make to run ‘guile-snarf’ to produce each needed ‘.x’ file
from the corresponding ‘.c’ file.

   The program ‘guile-snarf’ passes its command-line arguments directly
to the C preprocessor, which it uses to extract the information it needs
from the source code.  this means you can pass normal compilation flags
to ‘guile-snarf’ to define preprocessor symbols, add header file
directories, and so on.


File: guile.info,  Node: Programming Overview,  Next: Autoconf Support,  Prev: Function Snarfing,  Up: Programming in C

5.7 An Overview of Guile Programming
====================================

Guile is designed as an extension language interpreter that is
straightforward to integrate with applications written in C (and C++).
The big win here for the application developer is that Guile
integration, as the Guile web page says, “lowers your project’s
hacktivation energy.” Lowering the hacktivation energy means that you,
as the application developer, _and your users_, reap the benefits that
flow from being able to extend the application in a high level extension
language rather than in plain old C.

   In abstract terms, it’s difficult to explain what this really means
and what the integration process involves, so instead let’s begin by
jumping straight into an example of how you might integrate Guile into
an existing program, and what you could expect to gain by so doing.
With that example under our belts, we’ll then return to a more general
analysis of the arguments involved and the range of programming options
available.

* Menu:

* Extending Dia::               How one might extend Dia using Guile.
* Scheme vs C::                 Why Scheme is more hackable than C.
* Testbed Example::             Example: using Guile in a testbed.
* Programming Options::         Options for Guile programming.
* User Programming::            How about application users?


File: guile.info,  Node: Extending Dia,  Next: Scheme vs C,  Up: Programming Overview

5.7.1 How One Might Extend Dia Using Guile
------------------------------------------

Dia is a free software program for drawing schematic diagrams like flow
charts and floor plans (<http://www.gnome.org/projects/dia/>).  This
section conducts the thought experiment of adding Guile to Dia.  In so
doing, it aims to illustrate several of the steps and considerations
involved in adding Guile to applications in general.

* Menu:

* Dia Objective::               Deciding why you want to add Guile.
* Dia Steps::                   Four steps required to add Guile.
* Dia Objects::                 How to represent Dia data in Scheme.
* Dia Primitives::              Writing Guile primitives for Dia.
* Dia Hook::                    Providing a hook for Scheme evaluation.
* Dia Structure::               Overall structure for adding Guile.
* Dia Advanced::                Going further with Dia and Guile.


File: guile.info,  Node: Dia Objective,  Next: Dia Steps,  Up: Extending Dia

5.7.1.1 Deciding Why You Want to Add Guile
..........................................

First off, you should understand why you want to add Guile to Dia at
all, and that means forming a picture of what Dia does and how it does
it.  So, what are the constituents of the Dia application?

   • Most importantly, the “application domain objects” — in other
     words, the concepts that differentiate Dia from another application
     such as a word processor or spreadsheet: shapes, templates,
     connectors, pages, plus the properties of all these things.

   • The code that manages the graphical face of the application,
     including the layout and display of the objects above.

   • The code that handles input events, which indicate that the
     application user is wanting to do something.

(In other words, a textbook example of the “model - view - controller”
paradigm.)

   Next question: how will Dia benefit once the Guile integration is
complete?  Several (positive!)  answers are possible here, and the
choice is obviously up to the application developers.  Still, one answer
is that the main benefit will be the ability to manipulate Dia’s
application domain objects from Scheme.

   Suppose that Dia made a set of procedures available in Scheme,
representing the most basic operations on objects such as shapes,
connectors, and so on.  Using Scheme, the application user could then
write code that builds upon these basic operations to create more
complex procedures.  For example, given basic procedures to enumerate
the objects on a page, to determine whether an object is a square, and
to change the fill pattern of a single shape, the user can write a
Scheme procedure to change the fill pattern of all squares on the
current page:

     (define (change-squares'-fill-pattern new-pattern)
       (for-each-shape current-page
         (lambda (shape)
           (if (square? shape)
               (change-fill-pattern shape new-pattern)))))


File: guile.info,  Node: Dia Steps,  Next: Dia Objects,  Prev: Dia Objective,  Up: Extending Dia

5.7.1.2 Four Steps Required to Add Guile
........................................

Assuming this objective, four steps are needed to achieve it.

   First, you need a way of representing your application-specific
objects — such as ‘shape’ in the previous example — when they are passed
into the Scheme world.  Unless your objects are so simple that they map
naturally into builtin Scheme data types like numbers and strings, you
will probably want to use Guile’s “foreign object” interface to create a
new Scheme data type for your objects.

   Second, you need to write code for the basic operations like
‘for-each-shape’ and ‘square?’ such that they access and manipulate your
existing data structures correctly, and then make these operations
available as “primitives” on the Scheme level.

   Third, you need to provide some mechanism within the Dia application
that a user can hook into to cause arbitrary Scheme code to be
evaluated.

   Finally, you need to restructure your top-level application C code a
little so that it initializes the Guile interpreter correctly and
declares your “foreign objects” and “primitives” to the Scheme world.

   The following subsections expand on these four points in turn.


File: guile.info,  Node: Dia Objects,  Next: Dia Primitives,  Prev: Dia Steps,  Up: Extending Dia

5.7.1.3 How to Represent Dia Data in Scheme
...........................................

For all but the most trivial applications, you will probably want to
allow some representation of your domain objects to exist on the Scheme
level.  This is where foreign objects come in, and with them issues of
lifetime management and garbage collection.

   To get more concrete about this, let’s look again at the example we
gave earlier of how application users can use Guile to build
higher-level functions from the primitives that Dia itself provides.

     (define (change-squares'-fill-pattern new-pattern)
       (for-each-shape current-page
         (lambda (shape)
           (if (square? shape)
               (change-fill-pattern shape new-pattern)))))

   Consider what is stored here in the variable ‘shape’.  For each shape
on the current page, the ‘for-each-shape’ primitive calls ‘(lambda
(shape) ...)’ with an argument representing that shape.  Question is:
how is that argument represented on the Scheme level?  The issues are as
follows.

   • Whatever the representation, it has to be decodable again by the C
     code for the ‘square?’ and ‘change-fill-pattern’ primitives.  In
     other words, a primitive like ‘square?’ has somehow to be able to
     turn the value that it receives back into something that points to
     the underlying C structure describing a shape.

   • The representation must also cope with Scheme code holding on to
     the value for later use.  What happens if the Scheme code stores
     ‘shape’ in a global variable, but then that shape is deleted (in a
     way that the Scheme code is not aware of), and later on some other
     Scheme code uses that global variable again in a call to, say,
     ‘square?’?

   • The lifetime and memory allocation of objects that exist _only_ in
     the Scheme world is managed automatically by Guile’s garbage
     collector using one simple rule: when there are no remaining
     references to an object, the object is considered dead and so its
     memory is freed.  But for objects that exist in both C and Scheme,
     the picture is more complicated; in the case of Dia, where the
     ‘shape’ argument passes transiently in and out of the Scheme world,
     it would be quite wrong the *delete* the underlying C shape just
     because the Scheme code has finished evaluation.  How do we avoid
     this happening?

   One resolution of these issues is for the Scheme-level representation
of a shape to be a new, Scheme-specific C structure wrapped up as a
foreign object.  The foreign object is what is passed into and out of
Scheme code, and the Scheme-specific C structure inside the foreign
object points to Dia’s underlying C structure so that the code for
primitives like ‘square?’ can get at it.

   To cope with an underlying shape being deleted while Scheme code is
still holding onto a Scheme shape value, the underlying C structure
should have a new field that points to the Scheme-specific foreign
object.  When a shape is deleted, the relevant code chains through to
the Scheme-specific structure and sets its pointer back to the
underlying structure to NULL. Thus the foreign object value for the
shape continues to exist, but any primitive code that tries to use it
will detect that the underlying shape has been deleted because the
underlying structure pointer is NULL.

   So, to summarize the steps involved in this resolution of the problem
(and assuming that the underlying C structure for a shape is ‘struct
dia_shape’):

   • Define a new Scheme-specific structure that _points_ to the
     underlying C structure:

          struct dia_guile_shape
          {
            struct dia_shape * c_shape;   /* NULL => deleted */
          }

   • Add a field to ‘struct dia_shape’ that points to its ‘struct
     dia_guile_shape’ if it has one —

          struct dia_shape
          {
            ...
            struct dia_guile_shape * guile_shape;
          }

     — so that C code can set ‘guile_shape->c_shape’ to NULL when the
     underlying shape is deleted.

   • Wrap ‘struct dia_guile_shape’ as a foreign object type.

   • Whenever you need to represent a C shape onto the Scheme level,
     create a foreign object instance for it, and pass that.

   • In primitive code that receives a shape foreign object instance,
     check the ‘c_shape’ field when decoding it, to find out whether the
     underlying C shape is still there.

   As far as memory management is concerned, the foreign object values
and their Scheme-specific structures are under the control of the
garbage collector, whereas the underlying C structures are explicitly
managed in exactly the same way that Dia managed them before we thought
of adding Guile.

   When the garbage collector decides to free a shape foreign object
value, it calls the “finalizer” function that was specified when
defining the shape foreign object type.  To maintain the correctness of
the ‘guile_shape’ field in the underlying C structure, this function
should chain through to the underlying C structure (if it still exists)
and set its ‘guile_shape’ field to NULL.

   For full documentation on defining and using foreign object types,
see *note Defining New Foreign Object Types::.


File: guile.info,  Node: Dia Primitives,  Next: Dia Hook,  Prev: Dia Objects,  Up: Extending Dia

5.7.1.4 Writing Guile Primitives for Dia
........................................

Once the details of object representation are decided, writing the
primitive function code that you need is usually straightforward.

   A primitive is simply a C function whose arguments and return value
are all of type ‘SCM’, and whose body does whatever you want it to do.
As an example, here is a possible implementation of the ‘square?’
primitive:

     static SCM square_p (SCM shape)
     {
       struct dia_guile_shape * guile_shape;

       /* Check that arg is really a shape object. */
       scm_assert_foreign_object_type (shape_type, shape);

       /* Access Scheme-specific shape structure. */
       guile_shape = scm_foreign_object_ref (shape, 0);

       /* Find out if underlying shape exists and is a
          square; return answer as a Scheme boolean. */
       return scm_from_bool (guile_shape->c_shape &&
                             (guile_shape->c_shape->type == DIA_SQUARE));
     }

   Notice how easy it is to chain through from the ‘SCM shape’ parameter
that ‘square_p’ receives — which is a foreign object — to the
Scheme-specific structure inside the foreign object, and thence to the
underlying C structure for the shape.

   In this code, ‘scm_assert_foreign_object_type’,
‘scm_foreign_object_ref’, and ‘scm_from_bool’ are from the standard
Guile API. We assume that ‘shape_type’ was given to us when we made the
shape foreign object type, using ‘scm_make_foreign_object_type’.  The
call to ‘scm_assert_foreign_object_type’ ensures that SHAPE is indeed a
shape.  This is needed to guard against Scheme code using the ‘square?’
procedure incorrectly, as in ‘(square? "hello")’; Scheme’s latent typing
means that usage errors like this must be caught at run time.

   Having written the C code for your primitives, you need to make them
available as Scheme procedures by calling the ‘scm_c_define_gsubr’
function.  ‘scm_c_define_gsubr’ (*note Primitive Procedures::) takes
arguments that specify the Scheme-level name for the primitive and how
many required, optional and rest arguments it can accept.  The ‘square?’
primitive always requires exactly one argument, so the call to make it
available in Scheme reads like this:

     scm_c_define_gsubr ("square?", 1, 0, 0, square_p);

   For where to put this call, see the subsection after next on the
structure of Guile-enabled code (*note Dia Structure::).


File: guile.info,  Node: Dia Hook,  Next: Dia Structure,  Prev: Dia Primitives,  Up: Extending Dia

5.7.1.5 Providing a Hook for the Evaluation of Scheme Code
..........................................................

To make the Guile integration useful, you have to design some kind of
hook into your application that application users can use to cause their
Scheme code to be evaluated.

   Technically, this is straightforward; you just have to decide on a
mechanism that is appropriate for your application.  Think of Emacs, for
example: when you type ‘<ESC> :’, you get a prompt where you can type in
any Elisp code, which Emacs will then evaluate.  Or, again like Emacs,
you could provide a mechanism (such as an init file) to allow Scheme
code to be associated with a particular key sequence, and evaluate the
code when that key sequence is entered.

   In either case, once you have the Scheme code that you want to
evaluate, as a null terminated string, you can tell Guile to evaluate it
by calling the ‘scm_c_eval_string’ function.


File: guile.info,  Node: Dia Structure,  Next: Dia Advanced,  Prev: Dia Hook,  Up: Extending Dia

5.7.1.6 Top-level Structure of Guile-enabled Dia
................................................

Let’s assume that the pre-Guile Dia code looks structurally like this:

   • ‘main ()’

        • do lots of initialization and setup stuff
        • enter Gtk main loop

   When you add Guile to a program, one (rather technical) requirement
is that Guile’s garbage collector needs to know where the bottom of the
C stack is.  The easiest way to ensure this is to use ‘scm_boot_guile’
like this:

   • ‘main ()’

        • do lots of initialization and setup stuff
        • ‘scm_boot_guile (argc, argv, inner_main, NULL)’

   • ‘inner_main ()’

        • define all foreign object types
        • export primitives to Scheme using ‘scm_c_define_gsubr’
        • enter Gtk main loop

   In other words, you move the guts of what was previously in your
‘main’ function into a new function called ‘inner_main’, and then add a
‘scm_boot_guile’ call, with ‘inner_main’ as a parameter, to the end of
‘main’.

   Assuming that you are using foreign objects and have written
primitive code as described in the preceding subsections, you also need
to insert calls to declare your new foreign objects and export the
primitives to Scheme.  These declarations must happen _inside_ the
dynamic scope of the ‘scm_boot_guile’ call, but also _before_ any code
is run that could possibly use them — the beginning of ‘inner_main’ is
an ideal place for this.


File: guile.info,  Node: Dia Advanced,  Prev: Dia Structure,  Up: Extending Dia

5.7.1.7 Going Further with Dia and Guile
........................................

The steps described so far implement an initial Guile integration that
already gives a lot of additional power to Dia application users.  But
there are further steps that you could take, and it’s interesting to
consider a few of these.

   In general, you could progressively move more of Dia’s source code
from C into Scheme.  This might make the code more maintainable and
extensible, and it could open the door to new programming paradigms that
are tricky to effect in C but straightforward in Scheme.

   A specific example of this is that you could use the guile-gtk
package, which provides Scheme-level procedures for most of the Gtk+
library, to move the code that lays out and displays Dia objects from C
to Scheme.

   As you follow this path, it naturally becomes less useful to maintain
a distinction between Dia’s original non-Guile-related source code, and
its later code implementing foreign objects and primitives for the
Scheme world.

   For example, suppose that the original source code had a
‘dia_change_fill_pattern’ function:

     void dia_change_fill_pattern (struct dia_shape * shape,
                                   struct dia_pattern * pattern)
     {
       /* real pattern change work */
     }

   During initial Guile integration, you add a ‘change_fill_pattern’
primitive for Scheme purposes, which accesses the underlying structures
from its foreign object values and uses ‘dia_change_fill_pattern’ to do
the real work:

     SCM change_fill_pattern (SCM shape, SCM pattern)
     {
       struct dia_shape * d_shape;
       struct dia_pattern * d_pattern;

       ...

       dia_change_fill_pattern (d_shape, d_pattern);

       return SCM_UNSPECIFIED;
     }

   At this point, it makes sense to keep ‘dia_change_fill_pattern’ and
‘change_fill_pattern’ separate, because ‘dia_change_fill_pattern’ can
also be called without going through Scheme at all, say because the user
clicks a button which causes a C-registered Gtk+ callback to be called.

   But, if the code for creating buttons and registering their callbacks
is moved into Scheme (using guile-gtk), it may become true that
‘dia_change_fill_pattern’ can no longer be called other than through
Scheme.  In which case, it makes sense to abolish it and move its
contents directly into ‘change_fill_pattern’, like this:

     SCM change_fill_pattern (SCM shape, SCM pattern)
     {
       struct dia_shape * d_shape;
       struct dia_pattern * d_pattern;

       ...

       /* real pattern change work */

       return SCM_UNSPECIFIED;
     }

   So further Guile integration progressively _reduces_ the amount of
functional C code that you have to maintain over the long term.

   A similar argument applies to data representation.  In the discussion
of foreign objects earlier, issues arose because of the different memory
management and lifetime models that normally apply to data structures in
C and in Scheme.  However, with further Guile integration, you can
resolve this issue in a more radical way by allowing all your data
structures to be under the control of the garbage collector, and kept
alive by references from the Scheme world.  Instead of maintaining an
array or linked list of shapes in C, you would instead maintain a list
in Scheme.

   Rather like the coalescing of ‘dia_change_fill_pattern’ and
‘change_fill_pattern’, the practical upshot of such a change is that you
would no longer have to keep the ‘dia_shape’ and ‘dia_guile_shape’
structures separate, and so wouldn’t need to worry about the pointers
between them.  Instead, you could change the foreign object definition
to wrap the ‘dia_shape’ structure directly, and send ‘dia_guile_shape’
off to the scrap yard.  Cut out the middle man!

   Finally, we come to the holy grail of Guile’s free software /
extension language approach.  Once you have a Scheme representation for
interesting Dia data types like shapes, and a handy bunch of primitives
for manipulating them, it suddenly becomes clear that you have a bundle
of functionality that could have far-ranging use beyond Dia itself.  In
other words, the data types and primitives could now become a library,
and Dia becomes just one of the many possible applications using that
library — albeit, at this early stage, a rather important one!

   In this model, Guile becomes just the glue that binds everything
together.  Imagine an application that usefully combined functionality
from Dia, Gnumeric and GnuCash — it’s tricky right now, because no such
application yet exists; but it’ll happen some day ...


File: guile.info,  Node: Scheme vs C,  Next: Testbed Example,  Prev: Extending Dia,  Up: Programming Overview

5.7.2 Why Scheme is More Hackable Than C
----------------------------------------

Underlying Guile’s value proposition is the assumption that programming
in a high level language, specifically Guile’s implementation of Scheme,
is necessarily better in some way than programming in C. What do we mean
by this claim, and how can we be so sure?

   One class of advantages applies not only to Scheme, but more
generally to any interpretable, high level, scripting language, such as
Emacs Lisp, Python, Ruby, or TeX’s macro language.  Common features of
all such languages, when compared to C, are that:

   • They lend themselves to rapid and experimental development cycles,
     owing usually to a combination of their interpretability and the
     integrated development environment in which they are used.

   • They free developers from some of the low level bookkeeping tasks
     associated with C programming, notably memory management.

   • They provide high level features such as container objects and
     exception handling that make common programming tasks easier.

   In the case of Scheme, particular features that make programming
easier — and more fun!  — are its powerful mechanisms for abstracting
parts of programs (closures — *note About Closure::) and for iteration
(*note while do::).

   The evidence in support of this argument is empirical: the huge
amount of code that has been written in extension languages for
applications that support this mechanism.  Most notable are extensions
written in Emacs Lisp for GNU Emacs, in TeX’s macro language for TeX,
and in Script-Fu for the Gimp, but there is increasingly now a
significant code eco-system for Guile-based applications as well, such
as Lilypond and GnuCash.  It is close to inconceivable that similar
amounts of functionality could have been added to these applications
just by writing new code in their base implementation languages.


File: guile.info,  Node: Testbed Example,  Next: Programming Options,  Prev: Scheme vs C,  Up: Programming Overview

5.7.3 Example: Using Guile for an Application Testbed
-----------------------------------------------------

As an example of what this means in practice, imagine writing a testbed
for an application that is tested by submitting various requests (via a
C interface) and validating the output received.  Suppose further that
the application keeps an idea of its current state, and that the
“correct” output for a given request may depend on the current
application state.  A complete “white box”(1) test plan for this
application would aim to submit all possible requests in each
distinguishable state, and validate the output for all request/state
combinations.

   To write all this test code in C would be very tedious.  Suppose
instead that the testbed code adds a single new C function, to submit an
arbitrary request and return the response, and then uses Guile to export
this function as a Scheme procedure.  The rest of the testbed can then
be written in Scheme, and so benefits from all the advantages of
programming in Scheme that were described in the previous section.

   (In this particular example, there is an additional benefit of
writing most of the testbed in Scheme.  A common problem for white box
testing is that mistakes and mistaken assumptions in the application
under test can easily be reproduced in the testbed code.  It is more
difficult to copy mistakes like this when the testbed is written in a
different language from the application.)

   ---------- Footnotes ----------

   (1) A “white box” test plan is one that incorporates knowledge of the
internal design of the application under test.


File: guile.info,  Node: Programming Options,  Next: User Programming,  Prev: Testbed Example,  Up: Programming Overview

5.7.4 A Choice of Programming Options
-------------------------------------

The preceding arguments and example point to a model of Guile
programming that is applicable in many cases.  According to this model,
Guile programming involves a balance between C and Scheme programming,
with the aim being to extract the greatest possible Scheme level benefit
from the least amount of C level work.

   The C level work required in this model usually consists of packaging
and exporting functions and application objects such that they can be
seen and manipulated on the Scheme level.  To help with this, Guile’s C
language interface includes utility features that aim to make this kind
of integration very easy for the application developer.  These features
are documented later in this part of the manual: see REFFIXME.

   This model, though, is really just one of a range of possible
programming options.  If all of the functionality that you need is
available from Scheme, you could choose instead to write your whole
application in Scheme (or one of the other high level languages that
Guile supports through translation), and simply use Guile as an
interpreter for Scheme.  (In the future, we hope that Guile will also be
able to compile Scheme code, so lessening the performance gap between C
and Scheme code.)  Or, at the other end of the C–Scheme scale, you could
write the majority of your application in C, and only call out to Guile
occasionally for specific actions such as reading a configuration file
or executing a user-specified extension.  The choices boil down to two
basic questions:

   • Which parts of the application do you write in C, and which in
     Scheme (or another high level translated language)?

   • How do you design the interface between the C and Scheme parts of
     your application?

   These are of course design questions, and the right design for any
given application will always depend upon the particular requirements
that you are trying to meet.  In the context of Guile, however, there
are some generally applicable considerations that can help you when
designing your answers.

* Menu:

* Available Functionality::     What functionality is already available?
* Basic Constraints::           Functional and performance constraints.
* Style Choices::               Your preferred programming style.
* Program Control::             What controls program execution?


File: guile.info,  Node: Available Functionality,  Next: Basic Constraints,  Up: Programming Options

5.7.4.1 What Functionality is Already Available?
................................................

Suppose, for the sake of argument, that you would prefer to write your
whole application in Scheme.  Then the API available to you consists of:

   • standard Scheme

   • plus the extensions to standard Scheme provided by Guile in its
     core distribution

   • plus any additional functionality that you or others have packaged
     so that it can be loaded as a Guile Scheme module.

   A module in the last category can either be a pure Scheme module — in
other words a collection of utility procedures coded in Scheme — or a
module that provides a Scheme interface to an extension library coded in
C — in other words a nice package where someone else has done the work
of wrapping up some useful C code for you.  The set of available modules
is growing quickly and already includes such useful examples as ‘(gtk
gtk)’, which makes Gtk+ drawing functions available in Scheme, and
‘(database postgres)’, which provides SQL access to a Postgres database.

   Given the growing collection of pre-existing modules, it is quite
feasible that your application could be implemented by combining a
selection of these modules together with new application code written in
Scheme.

   If this approach is not enough, because the functionality that your
application needs is not already available in this form, and it is
impossible to write the new functionality in Scheme, you will need to
write some C code.  If the required function is already available in C
(e.g. in a library), all you need is a little glue to connect it to the
world of Guile.  If not, you need both to write the basic code and to
plumb it into Guile.

   In either case, two general considerations are important.  Firstly,
what is the interface by which the functionality is presented to the
Scheme world?  Does the interface consist only of function calls (for
example, a simple drawing interface), or does it need to include
“objects” of some kind that can be passed between C and Scheme and
manipulated by both worlds.  Secondly, how does the lifetime and memory
management of objects in the C code relate to the garbage collection
governed approach of Scheme objects?  In the case where the basic C code
is not already written, most of the difficulties of memory management
can be avoided by using Guile’s C interface features from the start.

   For the full documentation on writing C code for Guile and connecting
existing C code to the Guile world, see REFFIXME.


File: guile.info,  Node: Basic Constraints,  Next: Style Choices,  Prev: Available Functionality,  Up: Programming Options

5.7.4.2 Functional and Performance Constraints
..............................................


File: guile.info,  Node: Style Choices,  Next: Program Control,  Prev: Basic Constraints,  Up: Programming Options

5.7.4.3 Your Preferred Programming Style
........................................


File: guile.info,  Node: Program Control,  Prev: Style Choices,  Up: Programming Options

5.7.4.4 What Controls Program Execution?
........................................


File: guile.info,  Node: User Programming,  Prev: Programming Options,  Up: Programming Overview

5.7.5 How About Application Users?
----------------------------------

So far we have considered what Guile programming means for an
application developer.  But what if you are instead _using_ an existing
Guile-based application, and want to know what your options are for
programming and extending this application?

   The answer to this question varies from one application to another,
because the options available depend inevitably on whether the
application developer has provided any hooks for you to hang your own
code on and, if there are such hooks, what they allow you to do.(1)  For
example...

   • If the application permits you to load and execute any Guile code,
     the world is your oyster.  You can extend the application in any
     way that you choose.

   • A more cautious application might allow you to load and execute
     Guile code, but only in a “safe” environment, where the interface
     available is restricted by the application from the standard Guile
     API.

   • Or a really fearful application might not provide a hook to really
     execute user code at all, but just use Scheme syntax as a
     convenient way for users to specify application data or
     configuration options.

   In the last two cases, what you can do is, by definition, restricted
by the application, and you should refer to the application’s own manual
to find out your options.

   The most well known example of the first case is Emacs, with its
extension language Emacs Lisp: as well as being a text editor, Emacs
supports the loading and execution of arbitrary Emacs Lisp code.  The
result of such openness has been dramatic: Emacs now benefits from
user-contributed Emacs Lisp libraries that extend the basic editing
function to do everything from reading news to psychoanalysis and
playing adventure games.  The only limitation is that extensions are
restricted to the functionality provided by Emacs’s built-in set of
primitive operations.  For example, you can interact and display data by
manipulating the contents of an Emacs buffer, but you can’t pop-up and
draw a window with a layout that is totally different to the Emacs
standard.

   This situation with a Guile application that supports the loading of
arbitrary user code is similar, except perhaps even more so, because
Guile also supports the loading of extension libraries written in C.
This last point enables user code to add new primitive operations to
Guile, and so to bypass the limitation present in Emacs Lisp.

   At this point, the distinction between an application developer and
an application user becomes rather blurred.  Instead of seeing yourself
as a user extending an application, you could equally well say that you
are developing a new application of your own using some of the primitive
functionality provided by the original application.  As such, all the
discussions of the preceding sections of this chapter are relevant to
how you can proceed with developing your extension.

   ---------- Footnotes ----------

   (1) Of course, in the world of free software, you always have the
freedom to modify the application’s source code to your own
requirements.  Here we are concerned with the extension options that the
application has provided for without your needing to modify its source
code.


File: guile.info,  Node: Autoconf Support,  Prev: Programming Overview,  Up: Programming in C

5.8 Autoconf Support
====================

Autoconf, a part of the GNU build system, makes it easy for users to
build your package.  This section documents Guile’s Autoconf support.

* Menu:

* Autoconf Background::         Why use autoconf?
* Autoconf Macros::             The GUILE_* macros.
* Using Autoconf Macros::       How to use them, plus examples.


File: guile.info,  Node: Autoconf Background,  Next: Autoconf Macros,  Up: Autoconf Support

5.8.1 Autoconf Background
-------------------------

As explained in the ‘GNU Autoconf Manual’, any package needs
configuration at build-time (*note Introduction: (autoconf)Top.).  If
your package uses Guile (or uses a package that in turn uses Guile), you
probably need to know what specific Guile features are available and
details about them.

   The way to do this is to write feature tests and arrange for their
execution by the ‘configure’ script, typically by adding the tests to
‘configure.ac’, and running ‘autoconf’ to create ‘configure’.  Users of
your package then run ‘configure’ in the normal way.

   Macros are a way to make common feature tests easy to express.
Autoconf provides a wide range of macros (*note (autoconf)Existing
Tests::), and Guile installation provides Guile-specific tests in the
areas of: program detection, compilation flags reporting, and Scheme
module checks.


File: guile.info,  Node: Autoconf Macros,  Next: Using Autoconf Macros,  Prev: Autoconf Background,  Up: Autoconf Support

5.8.2 Autoconf Macros
---------------------

As mentioned earlier in this chapter, Guile supports parallel
installation, and uses ‘pkg-config’ to let the user choose which version
of Guile they are interested in.  ‘pkg-config’ has its own set of
Autoconf macros that are probably installed on most every development
system.  The most useful of these macros is ‘PKG_CHECK_MODULES’.

     PKG_CHECK_MODULES([GUILE], [guile-3.0])

   This example looks for Guile and sets the ‘GUILE_CFLAGS’ and
‘GUILE_LIBS’ variables accordingly, or prints an error and exits if
Guile was not found.

   Guile comes with additional Autoconf macros providing more
information, installed as ‘PREFIX/share/aclocal/guile.m4’.  Their names
all begin with ‘GUILE_’.

 -- Autoconf Macro: GUILE_PKG [VERSIONS]

     This macro runs the ‘pkg-config’ tool to find development files for
     an available version of Guile.

     By default, this macro will search for the latest stable version of
     Guile (e.g.  3.0), falling back to the previous stable version
     (e.g.  2.2) if it is available.  If no guile-VERSION.pc file is
     found, an error is signalled.  The found version is stored in
     GUILE_EFFECTIVE_VERSION.

     If ‘GUILE_PROGS’ was already invoked, this macro ensures that the
     development files have the same effective version as the Guile
     program.

     GUILE_EFFECTIVE_VERSION is marked for substitution, as by
     ‘AC_SUBST’.

 -- Autoconf Macro: GUILE_FLAGS

     This macro runs the ‘pkg-config’ tool to find out how to compile
     and link programs against Guile.  It sets four variables:
     GUILE_CFLAGS, GUILE_LDFLAGS, GUILE_LIBS, and GUILE_LTLIBS.

     GUILE_CFLAGS: flags to pass to a C or C++ compiler to build code
     that uses Guile header files.  This is almost always just one or
     more ‘-I’ flags.

     GUILE_LDFLAGS: flags to pass to the compiler to link a program
     against Guile.  This includes ‘-lguile-VERSION’ for the Guile
     library itself, and may also include one or more ‘-L’ flag to tell
     the compiler where to find the libraries.  But it does not include
     flags that influence the program’s runtime search path for
     libraries, and will therefore lead to a program that fails to
     start, unless all necessary libraries are installed in a standard
     location such as ‘/usr/lib’.

     GUILE_LIBS and GUILE_LTLIBS: flags to pass to the compiler or to
     libtool, respectively, to link a program against Guile.  It
     includes flags that augment the program’s runtime search path for
     libraries, so that shared libraries will be found at the location
     where they were during linking, even in non-standard locations.
     GUILE_LIBS is to be used when linking the program directly with the
     compiler, whereas GUILE_LTLIBS is to be used when linking the
     program is done through libtool.

     The variables are marked for substitution, as by ‘AC_SUBST’.

 -- Autoconf Macro: GUILE_SITE_DIR

     This looks for Guile’s "site" directories.  The variable GUILE_SITE
     will be set to Guile’s "site" directory for Scheme source files
     (usually something like PREFIX/share/guile/site).
     GUILE_SITE_CCACHE will be set to the directory for compiled Scheme
     files also known as ‘.go’ files (usually something like
     PREFIX/lib/guile/GUILE_EFFECTIVE_VERSION/site-ccache).
     GUILE_EXTENSION will be set to the directory for compiled C
     extensions (usually something like
     PREFIX/lib/guile/GUILE_EFFECTIVE_VERSION/extensions).  The latter
     two are set to blank if the particular version of Guile does not
     support them.  Note that this macro will run the macros ‘GUILE_PKG’
     and ‘GUILE_PROGS’ if they have not already been run.

     The variables are marked for substitution, as by ‘AC_SUBST’.

 -- Autoconf Macro: GUILE_PROGS [VERSION]

     This macro looks for programs ‘guile’ and ‘guild’, setting
     variables GUILE and GUILD to their paths, respectively.  The macro
     will attempt to find ‘guile’ with the suffix of ‘-X.Y’, followed by
     looking for it with the suffix ‘X.Y’, and then fall back to looking
     for ‘guile’ with no suffix.  If ‘guile’ is still not found, signal
     an error.  The suffix, if any, that was required to find ‘guile’
     will be used for ‘guild’ as well.

     By default, this macro will search for the latest stable version of
     Guile (e.g.  3.0).  x.y or x.y.z versions can be specified.  If an
     older version is found, the macro will signal an error.

     The effective version of the found ‘guile’ is set to
     GUILE_EFFECTIVE_VERSION.  This macro ensures that the effective
     version is compatible with the result of a previous invocation of
     ‘GUILE_FLAGS’, if any.

     As a legacy interface, it also looks for ‘guile-config’ and
     ‘guile-tools’, setting GUILE_CONFIG and GUILE_TOOLS.

     The variables are marked for substitution, as by ‘AC_SUBST’.

 -- Autoconf Macro: GUILE_CHECK_RETVAL var check

     VAR is a shell variable name to be set to the return value.  CHECK
     is a Guile Scheme expression, evaluated with "$GUILE -c", and
     returning either 0 or non-#f to indicate the check passed.  Non-0
     number or #f indicates failure.  Avoid using the character "#"
     since that confuses autoconf.

 -- Autoconf Macro: GUILE_MODULE_CHECK var module featuretest
          description

     VAR is a shell variable name to be set to "yes" or "no".  MODULE is
     a list of symbols, like: (ice-9 common-list).  FEATURETEST is an
     expression acceptable to GUILE_CHECK, q.v.  DESCRIPTION is a
     present-tense verb phrase (passed to AC_MSG_CHECKING).

 -- Autoconf Macro: GUILE_MODULE_AVAILABLE var module

     VAR is a shell variable name to be set to "yes" or "no".  MODULE is
     a list of symbols, like: (ice-9 common-list).

 -- Autoconf Macro: GUILE_MODULE_REQUIRED symlist

     SYMLIST is a list of symbols, WITHOUT surrounding parens, like:
     ice-9 common-list.

 -- Autoconf Macro: GUILE_MODULE_EXPORTS var module modvar

     VAR is a shell variable to be set to "yes" or "no".  MODULE is a
     list of symbols, like: (ice-9 common-list).  MODVAR is the Guile
     Scheme variable to check.

 -- Autoconf Macro: GUILE_MODULE_REQUIRED_EXPORT module modvar

     MODULE is a list of symbols, like: (ice-9 common-list).  MODVAR is
     the Guile Scheme variable to check.


File: guile.info,  Node: Using Autoconf Macros,  Prev: Autoconf Macros,  Up: Autoconf Support

5.8.3 Using Autoconf Macros
---------------------------

Using the autoconf macros is straightforward: Add the macro "calls"
(actually instantiations) to ‘configure.ac’, run ‘aclocal’, and finally,
run ‘autoconf’.  If your system doesn’t have guile.m4 installed, place
the desired macro definitions (‘AC_DEFUN’ forms) in ‘acinclude.m4’, and
‘aclocal’ will do the right thing.

   Some of the macros can be used inside normal shell constructs: ‘if
foo ; then GUILE_BAZ ; fi’, but this is not guaranteed.  It’s probably a
good idea to instantiate macros at top-level.

   We now include two examples, one simple and one complicated.

   The first example is for a package that uses libguile, and thus needs
to know how to compile and link against it.  So we use
‘PKG_CHECK_MODULES’ to set the vars ‘GUILE_CFLAGS’ and ‘GUILE_LIBS’,
which are automatically substituted in the Makefile.

     In configure.ac:

       PKG_CHECK_MODULES([GUILE], [guile-3.0])

     In Makefile.in:

       GUILE_CFLAGS  = @GUILE_CFLAGS@
       GUILE_LIBS = @GUILE_LIBS@

       myprog.o: myprog.c
               $(CC) -o $ $(GUILE_CFLAGS) $<
       myprog: myprog.o
               $(CC) -o $ $< $(GUILE_LIBS)

   The second example is for a package of Guile Scheme modules that uses
an external program and other Guile Scheme modules (some might call this
a "pure scheme" package).  So we use the ‘GUILE_SITE_DIR’ macro, a
regular ‘AC_PATH_PROG’ macro, and the ‘GUILE_MODULE_AVAILABLE’ macro.

     In configure.ac:

       GUILE_SITE_DIR

       probably_wont_work=""

       # pgtype pgtable
       GUILE_MODULE_AVAILABLE(have_guile_pg, (database postgres))
       test $have_guile_pg = no &&
           probably_wont_work="(my pgtype) (my pgtable) $probably_wont_work"

       # gpgutils
       AC_PATH_PROG(GNUPG,gpg)
       test x"$GNUPG" = x &&
           probably_wont_work="(my gpgutils) $probably_wont_work"

       if test ! "$probably_wont_work" = "" ; then
           p="         ***"
           echo
           echo "$p"
           echo "$p NOTE:"
           echo "$p The following modules probably won't work:"
           echo "$p   $probably_wont_work"
           echo "$p They can be installed anyway, and will work if their"
           echo "$p dependencies are installed later.  Please see README."
           echo "$p"
           echo
       fi

     In Makefile.in:

       instdir = @GUILE_SITE@/my

       install:
             $(INSTALL) my/*.scm $(instdir)


File: guile.info,  Node: API Reference,  Next: Guile Modules,  Prev: Programming in C,  Up: Top

6 API Reference
***************

Guile provides an application programming interface (“API”) to
developers in two core languages: Scheme and C. This part of the manual
contains reference documentation for all of the functionality that is
available through both Scheme and C interfaces.

* Menu:

* API Overview::                Overview of the Guile API.
* Deprecation::                 Obsolete back-compatible APIs.
* The SCM Type::                The fundamental data type for C code.
* Initialization::              Initializing Guile.
* Snarfing Macros::             Macros for snarfing initialization actions.
* Data Types::                  Representing values in Guile.
* Procedures::                  Procedures.
* Macros::                      Extending the syntax of Scheme.
* Utility Functions::           General utility functions.
* Binding Constructs::          Definitions and variable bindings.
* Control Mechanisms::          Controlling the flow of program execution.
* Input and Output::            Ports, reading and writing.
* Regular Expressions::         Pattern matching and substitution.
* LALR(1) Parsing::             Generating LALR(1) parsers.
* PEG Parsing::                 Parsing Expression Grammars.
* Read/Load/Eval/Compile::      Reading and evaluating Scheme code.
* Memory Management::           Memory management and garbage collection.
* Modules::                     Designing reusable code libraries.
* Foreign Function Interface::  Interacting with C procedures and data.
* Foreign Objects::             Defining new data types in C.
* Smobs::                       Use foreign objects instead.
* Scheduling::                  Threads, mutexes, asyncs and dynamic roots.
* Options and Config::          Configuration, features and runtime options.
* Other Languages::             Emacs Lisp, ECMAScript, and more.
* Internationalization::        Support for gettext, etc.
* Debugging::                   Debugging infrastructure and Scheme interface.
* Code Coverage::               Gathering code coverage data.


File: guile.info,  Node: API Overview,  Next: Deprecation,  Up: API Reference

6.1 Overview of the Guile API
=============================

Guile’s application programming interface (“API”) makes functionality
available that an application developer can use in either C or Scheme
programming.  The interface consists of “elements” that may be macros,
functions or variables in C, and procedures, variables, syntax or other
types of object in Scheme.

   Many elements are available to both Scheme and C, in a form that is
appropriate.  For example, the ‘assq’ Scheme procedure is also available
as ‘scm_assq’ to C code.  These elements are documented only once,
addressing both the Scheme and C aspects of them.

   The Scheme name of an element is related to its C name in a regular
way.  Also, a C function takes its parameters in a systematic way.

   Normally, the name of a C function can be derived given its Scheme
name, using some simple textual transformations:

   • Replace ‘-’ (hyphen) with ‘_’ (underscore).

   • Replace ‘?’ (question mark) with ‘_p’.

   • Replace ‘!’ (exclamation point) with ‘_x’.

   • Replace internal ‘->’ with ‘_to_’.

   • Replace ‘<=’ (less than or equal) with ‘_leq’.

   • Replace ‘>=’ (greater than or equal) with ‘_geq’.

   • Replace ‘<’ (less than) with ‘_less’.

   • Replace ‘>’ (greater than) with ‘_gr’.

   • Prefix with ‘scm_’.

   A C function always takes a fixed number of arguments of type ‘SCM’,
even when the corresponding Scheme function takes a variable number.

   For some Scheme functions, some last arguments are optional; the
corresponding C function must always be invoked with all optional
arguments specified.  To get the effect as if an argument has not been
specified, pass ‘SCM_UNDEFINED’ as its value.  You can not do this for
an argument in the middle; when one argument is ‘SCM_UNDEFINED’ all the
ones following it must be ‘SCM_UNDEFINED’ as well.

   Some Scheme functions take an arbitrary number of _rest_ arguments;
the corresponding C function must be invoked with a list of all these
arguments.  This list is always the last argument of the C function.

   These two variants can also be combined.

   The type of the return value of a C function that corresponds to a
Scheme function is always ‘SCM’.  In the descriptions below, types are
therefore often omitted but for the return value and for the arguments.


File: guile.info,  Node: Deprecation,  Next: The SCM Type,  Prev: API Overview,  Up: API Reference

6.2 Deprecation
===============

From time to time functions and other features of Guile become obsolete.
Guile’s “deprecation” is a mechanism that can help you cope with this.

   When you use a feature that is deprecated, you will likely get a
warning message at run-time.  Also, if you have a new enough toolchain,
using a deprecated function from ‘libguile’ will cause a link-time
warning.

   The primary source for information about just what interfaces are
deprecated in a given release is the file ‘NEWS’.  That file also
documents what you should use instead of the obsoleted things.

   The file ‘README’ contains instructions on how to control the
inclusion or removal of the deprecated features from the public API of
Guile, and how to control the deprecation warning messages.

   The idea behind this mechanism is that normally all deprecated
interfaces are available, but you get feedback when compiling and
running code that uses them, so that you can migrate to the newer APIs
at your leisure.


File: guile.info,  Node: The SCM Type,  Next: Initialization,  Prev: Deprecation,  Up: API Reference

6.3 The SCM Type
================

Guile represents all Scheme values with the single C type ‘SCM’.  For an
introduction to this topic, *Note Dynamic Types::.

 -- C Type: SCM
     ‘SCM’ is the user level abstract C type that is used to represent
     all of Guile’s Scheme objects, no matter what the Scheme object
     type is.  No C operation except assignment is guaranteed to work
     with variables of type ‘SCM’, so you should only use macros and
     functions to work with ‘SCM’ values.  Values are converted between
     C data types and the ‘SCM’ type with utility functions and macros.

 -- C Type: scm_t_bits
     ‘scm_t_bits’ is an unsigned integral data type that is guaranteed
     to be large enough to hold all information that is required to
     represent any Scheme object.  While this data type is mostly used
     to implement Guile’s internals, the use of this type is also
     necessary to write certain kinds of extensions to Guile.

 -- C Type: scm_t_signed_bits
     This is a signed integral type of the same size as ‘scm_t_bits’.

 -- C Macro: scm_t_bits SCM_UNPACK (SCM X)
     Transforms the ‘SCM’ value X into its representation as an integral
     type.  Only after applying ‘SCM_UNPACK’ it is possible to access
     the bits and contents of the ‘SCM’ value.

 -- C Macro: SCM SCM_PACK (scm_t_bits X)
     Takes a valid integral representation of a Scheme object and
     transforms it into its representation as a ‘SCM’ value.


File: guile.info,  Node: Initialization,  Next: Snarfing Macros,  Prev: The SCM Type,  Up: API Reference

6.4 Initializing Guile
======================

Each thread that wants to use functions from the Guile API needs to put
itself into guile mode with either ‘scm_with_guile’ or ‘scm_init_guile’.
The global state of Guile is initialized automatically when the first
thread enters guile mode.

   When a thread wants to block outside of a Guile API function, it
should leave guile mode temporarily with ‘scm_without_guile’, *Note
Blocking::.

   Threads that are created by ‘call-with-new-thread’ or
‘scm_spawn_thread’ start out in guile mode so you don’t need to
initialize them.

 -- C Function: void * scm_with_guile (void *(*func)(void *), void
          *data)
     Call FUNC, passing it DATA and return what FUNC returns.  While
     FUNC is running, the current thread is in guile mode and can thus
     use the Guile API.

     When ‘scm_with_guile’ is called from guile mode, the thread remains
     in guile mode when ‘scm_with_guile’ returns.

     Otherwise, it puts the current thread into guile mode and, if
     needed, gives it a Scheme representation that is contained in the
     list returned by ‘all-threads’, for example.  This Scheme
     representation is not removed when ‘scm_with_guile’ returns so that
     a given thread is always represented by the same Scheme value
     during its lifetime, if at all.

     When this is the first thread that enters guile mode, the global
     state of Guile is initialized before calling ‘func’.

     The function FUNC is called via ‘scm_with_continuation_barrier’;
     thus, ‘scm_with_guile’ returns exactly once.

     When ‘scm_with_guile’ returns, the thread is no longer in guile
     mode (except when ‘scm_with_guile’ was called from guile mode, see
     above).  Thus, only ‘func’ can store ‘SCM’ variables on the stack
     and be sure that they are protected from the garbage collector.
     See ‘scm_init_guile’ for another approach at initializing Guile
     that does not have this restriction.

     It is OK to call ‘scm_with_guile’ while a thread has temporarily
     left guile mode via ‘scm_without_guile’.  It will then simply
     temporarily enter guile mode again.

 -- C Function: void scm_init_guile ()
     Arrange things so that all of the code in the current thread
     executes as if from within a call to ‘scm_with_guile’.  That is,
     all functions called by the current thread can assume that ‘SCM’
     values on their stack frames are protected from the garbage
     collector (except when the thread has explicitly left guile mode,
     of course).

     When ‘scm_init_guile’ is called from a thread that already has been
     in guile mode once, nothing happens.  This behavior matters when
     you call ‘scm_init_guile’ while the thread has only temporarily
     left guile mode: in that case the thread will not be in guile mode
     after ‘scm_init_guile’ returns.  Thus, you should not use
     ‘scm_init_guile’ in such a scenario.

     When a uncaught throw happens in a thread that has been put into
     guile mode via ‘scm_init_guile’, a short message is printed to the
     current error port and the thread is exited via ‘scm_pthread_exit
     (NULL)’.  No restrictions are placed on continuations.

     The function ‘scm_init_guile’ might not be available on all
     platforms since it requires some stack-bounds-finding magic that
     might not have been ported to all platforms that Guile runs on.
     Thus, if you can, it is better to use ‘scm_with_guile’ or its
     variation ‘scm_boot_guile’ instead of this function.

 -- C Function: void scm_boot_guile (int ARGC, char **ARGV, void
          (*MAIN_FUNC) (void *DATA, int ARGC, char **ARGV), void *DATA)
     Enter guile mode as with ‘scm_with_guile’ and call MAIN_FUNC,
     passing it DATA, ARGC, and ARGV as indicated.  When MAIN_FUNC
     returns, ‘scm_boot_guile’ calls ‘exit (0)’; ‘scm_boot_guile’ never
     returns.  If you want some other exit value, have MAIN_FUNC call
     ‘exit’ itself.  If you don’t want to exit at all, use
     ‘scm_with_guile’ instead of ‘scm_boot_guile’.

     The function ‘scm_boot_guile’ arranges for the Scheme
     ‘command-line’ function to return the strings given by ARGC and
     ARGV.  If MAIN_FUNC modifies ARGC or ARGV, it should call
     ‘scm_set_program_arguments’ with the final list, so Scheme code
     will know which arguments have been processed (*note Runtime
     Environment::).

 -- C Function: void scm_shell (int ARGC, char **ARGV)
     Process command-line arguments in the manner of the ‘guile’
     executable.  This includes loading the normal Guile initialization
     files, interacting with the user or running any scripts or
     expressions specified by ‘-s’ or ‘-e’ options, and then exiting.
     *Note Invoking Guile::, for more details.

     Since this function does not return, you must do all
     application-specific initialization before calling this function.


File: guile.info,  Node: Snarfing Macros,  Next: Data Types,  Prev: Initialization,  Up: API Reference

6.5 Snarfing Macros
===================

The following macros do two different things: when compiled normally,
they expand in one way; when processed during snarfing, they cause the
‘guile-snarf’ program to pick up some initialization code, *Note
Function Snarfing::.

   The descriptions below use the term ‘normally’ to refer to the case
when the code is compiled normally, and ‘while snarfing’ when the code
is processed by ‘guile-snarf’.

 -- C Macro: SCM_SNARF_INIT (code)

     Normally, ‘SCM_SNARF_INIT’ expands to nothing; while snarfing, it
     causes CODE to be included in the initialization action file,
     followed by a semicolon.

     This is the fundamental macro for snarfing initialization actions.
     The more specialized macros below use it internally.

 -- C Macro: SCM_DEFINE (c_name, scheme_name, req, opt, var, arglist,
          docstring)

     Normally, this macro expands into

          static const char s_C_NAME[] = SCHEME_NAME;
          SCM
          C_NAME ARGLIST

     While snarfing, it causes

          scm_c_define_gsubr (s_C_NAME, REQ, OPT, VAR,
                              C_NAME);

     to be added to the initialization actions.  Thus, you can use it to
     declare a C function named C_NAME that will be made available to
     Scheme with the name SCHEME_NAME.

     Note that the ARGLIST argument must have parentheses around it.

 -- C Macro: SCM_SYMBOL (c_name, scheme_name)
 -- C Macro: SCM_GLOBAL_SYMBOL (c_name, scheme_name)
     Normally, these macros expand into

          static SCM C_NAME

     or

          SCM C_NAME

     respectively.  While snarfing, they both expand into the
     initialization code

          C_NAME = scm_permanent_object (scm_from_locale_symbol (SCHEME_NAME));

     Thus, you can use them declare a static or global variable of type
     ‘SCM’ that will be initialized to the symbol named SCHEME_NAME.

 -- C Macro: SCM_KEYWORD (c_name, scheme_name)
 -- C Macro: SCM_GLOBAL_KEYWORD (c_name, scheme_name)
     Normally, these macros expand into

          static SCM C_NAME

     or

          SCM C_NAME

     respectively.  While snarfing, they both expand into the
     initialization code

          C_NAME = scm_permanent_object (scm_c_make_keyword (SCHEME_NAME));

     Thus, you can use them declare a static or global variable of type
     ‘SCM’ that will be initialized to the keyword named SCHEME_NAME.

 -- C Macro: SCM_VARIABLE (c_name, scheme_name)
 -- C Macro: SCM_GLOBAL_VARIABLE (c_name, scheme_name)
     These macros are equivalent to ‘SCM_VARIABLE_INIT’ and
     ‘SCM_GLOBAL_VARIABLE_INIT’, respectively, with a VALUE of
     ‘SCM_BOOL_F’.

 -- C Macro: SCM_VARIABLE_INIT (c_name, scheme_name, value)
 -- C Macro: SCM_GLOBAL_VARIABLE_INIT (c_name, scheme_name, value)

     Normally, these macros expand into

          static SCM C_NAME

     or

          SCM C_NAME

     respectively.  While snarfing, they both expand into the
     initialization code

          C_NAME = scm_permanent_object (scm_c_define (SCHEME_NAME, VALUE));

     Thus, you can use them declare a static or global C variable of
     type ‘SCM’ that will be initialized to the object representing the
     Scheme variable named SCHEME_NAME in the current module.  The
     variable will be defined when it doesn’t already exist.  It is
     always set to VALUE.


File: guile.info,  Node: Data Types,  Next: Procedures,  Prev: Snarfing Macros,  Up: API Reference

6.6 Data Types
==============

Guile’s data types form a powerful built-in library of representations
and functionality that you can apply to your problem domain.  This
chapter surveys the data types built-in to Guile, from the simple to the
complex.

* Menu:

* Booleans::                    True/false values.
* Numbers::                     Numerical data types.
* Characters::                  Single characters.
* Character Sets::              Sets of characters.
* Strings::                     Sequences of characters.
* Symbols::                     Symbols.
* Keywords::                    Self-quoting, customizable display keywords.
* Pairs::                       Scheme’s basic building block.
* Lists::                       Special list functions supported by Guile.
* Vectors::                     One-dimensional arrays of Scheme objects.
* Bit Vectors::                 Vectors of bits.
* Bytevectors::                 Sequences of bytes.
* Arrays::                      Multidimensional matrices.
* VLists::                      Vector-like lists.
* Record Overview::             Walking through the maze of record APIs.
* SRFI-9 Records::              The standard, recommended record API.
* Records::                     Guile’s historical record API.
* Structures::                  Low-level record representation.
* Dictionary Types::            About dictionary types in general.
* Association Lists::           List-based dictionaries.
* VHashes::                     VList-based dictionaries.
* Hash Tables::                 Table-based dictionaries.
* Other Types::                 Other sections describe data types too.


File: guile.info,  Node: Booleans,  Next: Numbers,  Up: Data Types

6.6.1 Booleans
--------------

The two boolean values are ‘#t’ for true and ‘#f’ for false.  They can
also be written as ‘#true’ and ‘#false’, as per R7RS.

   Boolean values are returned by predicate procedures, such as the
general equality predicates ‘eq?’, ‘eqv?’ and ‘equal?’ (*note
Equality::) and numerical and string comparison operators like
‘string=?’ (*note String Comparison::) and ‘<=’ (*note Comparison::).

     (<= 3 8)
     ⇒ #t

     (<= 3 -3)
     ⇒ #f

     (equal? "house" "houses")
     ⇒ #f

     (eq? #f #f)
     ⇒
     #t

   In test condition contexts like ‘if’ and ‘cond’ (*note
Conditionals::), where a group of subexpressions will be evaluated only
if a CONDITION expression evaluates to “true”, “true” means any value at
all except ‘#f’.

     (if #t "yes" "no")
     ⇒ "yes"

     (if 0 "yes" "no")
     ⇒ "yes"

     (if #f "yes" "no")
     ⇒ "no"

   A result of this asymmetry is that typical Scheme source code more
often uses ‘#f’ explicitly than ‘#t’: ‘#f’ is necessary to represent an
‘if’ or ‘cond’ false value, whereas ‘#t’ is not necessary to represent
an ‘if’ or ‘cond’ true value.

   It is important to note that ‘#f’ is *not* equivalent to any other
Scheme value.  In particular, ‘#f’ is not the same as the number 0 (like
in C and C++), and not the same as the “empty list” (like in some Lisp
dialects).

   In C, the two Scheme boolean values are available as the two
constants ‘SCM_BOOL_T’ for ‘#t’ and ‘SCM_BOOL_F’ for ‘#f’.  Care must be
taken with the false value ‘SCM_BOOL_F’: it is not false when used in C
conditionals.  In order to test for it, use ‘scm_is_false’ or
‘scm_is_true’.

 -- Scheme Procedure: not x
 -- C Function: scm_not (x)
     Return ‘#t’ if X is ‘#f’, else return ‘#f’.

 -- Scheme Procedure: boolean? obj
 -- C Function: scm_boolean_p (obj)
     Return ‘#t’ if OBJ is either ‘#t’ or ‘#f’, else return ‘#f’.

 -- C Macro: SCM SCM_BOOL_T
     The ‘SCM’ representation of the Scheme object ‘#t’.

 -- C Macro: SCM SCM_BOOL_F
     The ‘SCM’ representation of the Scheme object ‘#f’.

 -- C Function: int scm_is_true (SCM obj)
     Return ‘0’ if OBJ is ‘#f’, else return ‘1’.

 -- C Function: int scm_is_false (SCM obj)
     Return ‘1’ if OBJ is ‘#f’, else return ‘0’.

 -- C Function: int scm_is_bool (SCM obj)
     Return ‘1’ if OBJ is either ‘#t’ or ‘#f’, else return ‘0’.

 -- C Function: SCM scm_from_bool (int val)
     Return ‘#f’ if VAL is ‘0’, else return ‘#t’.

 -- C Function: int scm_to_bool (SCM val)
     Return ‘1’ if VAL is ‘SCM_BOOL_T’, return ‘0’ when VAL is
     ‘SCM_BOOL_F’, else signal a ‘wrong type’ error.

     You should probably use ‘scm_is_true’ instead of this function when
     you just want to test a ‘SCM’ value for trueness.


File: guile.info,  Node: Numbers,  Next: Characters,  Prev: Booleans,  Up: Data Types

6.6.2 Numerical data types
--------------------------

Guile supports a rich “tower” of numerical types — integer, rational,
real and complex — and provides an extensive set of mathematical and
scientific functions for operating on numerical data.  This section of
the manual documents those types and functions.

   You may also find it illuminating to read R5RS’s presentation of
numbers in Scheme, which is particularly clear and accessible: see *note
(r5rs)Numbers::.

* Menu:

* Numerical Tower::             Scheme’s numerical "tower".
* Integers::                    Whole numbers.
* Reals and Rationals::         Real and rational numbers.
* Complex Numbers::             Complex numbers.
* Exactness::                   Exactness and inexactness.
* Number Syntax::               Read syntax for numerical data.
* Integer Operations::          Operations on integer values.
* Comparison::                  Comparison predicates.
* Conversion::                  Converting numbers to and from strings.
* Complex::                     Complex number operations.
* Arithmetic::                  Arithmetic functions.
* Scientific::                  Scientific functions.
* Bitwise Operations::          Logical AND, OR, NOT, and so on.
* Random::                      Random number generation.


File: guile.info,  Node: Numerical Tower,  Next: Integers,  Up: Numbers

6.6.2.1 Scheme’s Numerical “Tower”
..................................

Scheme’s numerical “tower” consists of the following categories of
numbers:

“integers”
     Whole numbers, positive or negative; e.g. –5, 0, 18.

“rationals”
     The set of numbers that can be expressed as P/Q where P and Q are
     integers; e.g. 9/16 works, but pi (an irrational number) doesn’t.
     These include integers (N/1).

“real numbers”
     The set of numbers that describes all possible positions along a
     one-dimensional line.  This includes rationals as well as
     irrational numbers.

“complex numbers”
     The set of numbers that describes all possible positions in a two
     dimensional space.  This includes real as well as imaginary numbers
     (A+Bi, where A is the “real part”, B is the “imaginary part”, and i
     is the square root of −1.)

   It is called a tower because each category “sits on” the one that
follows it, in the sense that every integer is also a rational, every
rational is also real, and every real number is also a complex number
(but with zero imaginary part).

   In addition to the classification into integers, rationals, reals and
complex numbers, Scheme also distinguishes between whether a number is
represented exactly or not.  For example, the result of 2*sin(pi/4) is
exactly 2^(1/2), but Guile can represent neither pi/4 nor 2^(1/2)
exactly.  Instead, it stores an inexact approximation, using the C type
‘double’.

   Guile can represent exact rationals of any magnitude, inexact
rationals that fit into a C ‘double’, and inexact complex numbers with
‘double’ real and imaginary parts.

   The ‘number?’ predicate may be applied to any Scheme value to
discover whether the value is any of the supported numerical types.

 -- Scheme Procedure: number? obj
 -- C Function: scm_number_p (obj)
     Return ‘#t’ if OBJ is any kind of number, else ‘#f’.

   For example:

     (number? 3)
     ⇒ #t

     (number? "hello there!")
     ⇒ #f

     (define pi 3.141592654)
     (number? pi)
     ⇒ #t

 -- C Function: int scm_is_number (SCM obj)
     This is equivalent to ‘scm_is_true (scm_number_p (obj))’.

   The next few subsections document each of Guile’s numerical data
types in detail.


File: guile.info,  Node: Integers,  Next: Reals and Rationals,  Prev: Numerical Tower,  Up: Numbers

6.6.2.2 Integers
................

Integers are whole numbers, that is numbers with no fractional part,
such as 2, 83, and −3789.

   Integers in Guile can be arbitrarily big, as shown by the following
example.

     (define (factorial n)
       (let loop ((n n) (product 1))
         (if (= n 0)
             product
             (loop (- n 1) (* product n)))))

     (factorial 3)
     ⇒ 6

     (factorial 20)
     ⇒ 2432902008176640000

     (- (factorial 45))
     ⇒ -119622220865480194561963161495657715064383733760000000000

   Readers whose background is in programming languages where integers
are limited by the need to fit into just 4 or 8 bytes of memory may find
this surprising, or suspect that Guile’s representation of integers is
inefficient.  In fact, Guile achieves a near optimal balance of
convenience and efficiency by using the host computer’s native
representation of integers where possible, and a more general
representation where the required number does not fit in the native
form.  Conversion between these two representations is automatic and
completely invisible to the Scheme level programmer.

   C has a host of different integer types, and Guile offers a host of
functions to convert between them and the ‘SCM’ representation.  For
example, a C ‘int’ can be handled with ‘scm_to_int’ and ‘scm_from_int’.
Guile also defines a few C integer types of its own, to help with
differences between systems.

   C integer types that are not covered can be handled with the generic
‘scm_to_signed_integer’ and ‘scm_from_signed_integer’ for signed types,
or with ‘scm_to_unsigned_integer’ and ‘scm_from_unsigned_integer’ for
unsigned types.

   Scheme integers can be exact and inexact.  For example, a number
written as ‘3.0’ with an explicit decimal-point is inexact, but it is
also an integer.  The functions ‘integer?’ and ‘scm_is_integer’ report
true for such a number, but the functions ‘exact-integer?’,
‘scm_is_exact_integer’, ‘scm_is_signed_integer’, and
‘scm_is_unsigned_integer’ only allow exact integers and thus report
false.  Likewise, the conversion functions like ‘scm_to_signed_integer’
only accept exact integers.

   The motivation for this behavior is that the inexactness of a number
should not be lost silently.  If you want to allow inexact integers, you
can explicitly insert a call to ‘inexact->exact’ or to its C equivalent
‘scm_inexact_to_exact’.  (Only inexact integers will be converted by
this call into exact integers; inexact non-integers will become exact
fractions.)

 -- Scheme Procedure: integer? x
 -- C Function: scm_integer_p (x)
     Return ‘#t’ if X is an exact or inexact integer number, else return
     ‘#f’.

          (integer? 487)
          ⇒ #t

          (integer? 3.0)
          ⇒ #t

          (integer? -3.4)
          ⇒ #f

          (integer? +inf.0)
          ⇒ #f

 -- C Function: int scm_is_integer (SCM x)
     This is equivalent to ‘scm_is_true (scm_integer_p (x))’.

 -- Scheme Procedure: exact-integer? x
 -- C Function: scm_exact_integer_p (x)
     Return ‘#t’ if X is an exact integer number, else return ‘#f’.

          (exact-integer? 37)
          ⇒ #t

          (exact-integer? 3.0)
          ⇒ #f

 -- C Function: int scm_is_exact_integer (SCM x)
     This is equivalent to ‘scm_is_true (scm_exact_integer_p (x))’.

 -- C Type: scm_t_int8
 -- C Type: scm_t_uint8
 -- C Type: scm_t_int16
 -- C Type: scm_t_uint16
 -- C Type: scm_t_int32
 -- C Type: scm_t_uint32
 -- C Type: scm_t_int64
 -- C Type: scm_t_uint64
 -- C Type: scm_t_intmax
 -- C Type: scm_t_uintmax
     The C types are equivalent to the corresponding ISO C types but are
     defined on all platforms, with the exception of ‘scm_t_int64’ and
     ‘scm_t_uint64’, which are only defined when a 64-bit type is
     available.  For example, ‘scm_t_int8’ is equivalent to ‘int8_t’.

     You can regard these definitions as a stop-gap measure until all
     platforms provide these types.  If you know that all the platforms
     that you are interested in already provide these types, it is
     better to use them directly instead of the types provided by Guile.

 -- C Function: int scm_is_signed_integer (SCM x, scm_t_intmax min,
          scm_t_intmax max)
 -- C Function: int scm_is_unsigned_integer (SCM x, scm_t_uintmax min,
          scm_t_uintmax max)
     Return ‘1’ when X represents an exact integer that is between MIN
     and MAX, inclusive.

     These functions can be used to check whether a ‘SCM’ value will fit
     into a given range, such as the range of a given C integer type.
     If you just want to convert a ‘SCM’ value to a given C integer
     type, use one of the conversion functions directly.

 -- C Function: scm_t_intmax scm_to_signed_integer (SCM x, scm_t_intmax
          min, scm_t_intmax max)
 -- C Function: scm_t_uintmax scm_to_unsigned_integer (SCM x,
          scm_t_uintmax min, scm_t_uintmax max)
     When X represents an exact integer that is between MIN and MAX
     inclusive, return that integer.  Else signal an error, either a
     ‘wrong-type’ error when X is not an exact integer, or an
     ‘out-of-range’ error when it doesn’t fit the given range.

 -- C Function: SCM scm_from_signed_integer (scm_t_intmax x)
 -- C Function: SCM scm_from_unsigned_integer (scm_t_uintmax x)
     Return the ‘SCM’ value that represents the integer X.  This
     function will always succeed and will always return an exact
     number.

 -- C Function: char scm_to_char (SCM x)
 -- C Function: signed char scm_to_schar (SCM x)
 -- C Function: unsigned char scm_to_uchar (SCM x)
 -- C Function: short scm_to_short (SCM x)
 -- C Function: unsigned short scm_to_ushort (SCM x)
 -- C Function: int scm_to_int (SCM x)
 -- C Function: unsigned int scm_to_uint (SCM x)
 -- C Function: long scm_to_long (SCM x)
 -- C Function: unsigned long scm_to_ulong (SCM x)
 -- C Function: long long scm_to_long_long (SCM x)
 -- C Function: unsigned long long scm_to_ulong_long (SCM x)
 -- C Function: size_t scm_to_size_t (SCM x)
 -- C Function: ssize_t scm_to_ssize_t (SCM x)
 -- C Function: scm_t_uintptr scm_to_uintptr_t (SCM x)
 -- C Function: scm_t_ptrdiff scm_to_ptrdiff_t (SCM x)
 -- C Function: scm_t_int8 scm_to_int8 (SCM x)
 -- C Function: scm_t_uint8 scm_to_uint8 (SCM x)
 -- C Function: scm_t_int16 scm_to_int16 (SCM x)
 -- C Function: scm_t_uint16 scm_to_uint16 (SCM x)
 -- C Function: scm_t_int32 scm_to_int32 (SCM x)
 -- C Function: scm_t_uint32 scm_to_uint32 (SCM x)
 -- C Function: scm_t_int64 scm_to_int64 (SCM x)
 -- C Function: scm_t_uint64 scm_to_uint64 (SCM x)
 -- C Function: scm_t_intmax scm_to_intmax (SCM x)
 -- C Function: scm_t_uintmax scm_to_uintmax (SCM x)
 -- C Function: scm_t_intptr scm_to_intptr_t (SCM x)
 -- C Function: scm_t_uintptr scm_to_uintptr_t (SCM x)
     When X represents an exact integer that fits into the indicated C
     type, return that integer.  Else signal an error, either a
     ‘wrong-type’ error when X is not an exact integer, or an
     ‘out-of-range’ error when it doesn’t fit the given range.

     The functions ‘scm_to_long_long’, ‘scm_to_ulong_long’,
     ‘scm_to_int64’, and ‘scm_to_uint64’ are only available when the
     corresponding types are.

 -- C Function: SCM scm_from_char (char x)
 -- C Function: SCM scm_from_schar (signed char x)
 -- C Function: SCM scm_from_uchar (unsigned char x)
 -- C Function: SCM scm_from_short (short x)
 -- C Function: SCM scm_from_ushort (unsigned short x)
 -- C Function: SCM scm_from_int (int x)
 -- C Function: SCM scm_from_uint (unsigned int x)
 -- C Function: SCM scm_from_long (long x)
 -- C Function: SCM scm_from_ulong (unsigned long x)
 -- C Function: SCM scm_from_long_long (long long x)
 -- C Function: SCM scm_from_ulong_long (unsigned long long x)
 -- C Function: SCM scm_from_size_t (size_t x)
 -- C Function: SCM scm_from_ssize_t (ssize_t x)
 -- C Function: SCM scm_from_uintptr_t (uintptr_t x)
 -- C Function: SCM scm_from_ptrdiff_t (scm_t_ptrdiff x)
 -- C Function: SCM scm_from_int8 (scm_t_int8 x)
 -- C Function: SCM scm_from_uint8 (scm_t_uint8 x)
 -- C Function: SCM scm_from_int16 (scm_t_int16 x)
 -- C Function: SCM scm_from_uint16 (scm_t_uint16 x)
 -- C Function: SCM scm_from_int32 (scm_t_int32 x)
 -- C Function: SCM scm_from_uint32 (scm_t_uint32 x)
 -- C Function: SCM scm_from_int64 (scm_t_int64 x)
 -- C Function: SCM scm_from_uint64 (scm_t_uint64 x)
 -- C Function: SCM scm_from_intmax (scm_t_intmax x)
 -- C Function: SCM scm_from_uintmax (scm_t_uintmax x)
 -- C Function: SCM scm_from_intptr_t (scm_t_intptr x)
 -- C Function: SCM scm_from_uintptr_t (scm_t_uintptr x)
     Return the ‘SCM’ value that represents the integer X.  These
     functions will always succeed and will always return an exact
     number.

 -- C Function: void scm_to_mpz (SCM val, mpz_t rop)
     Assign VAL to the multiple precision integer ROP.  VAL must be an
     exact integer, otherwise an error will be signalled.  ROP must have
     been initialized with ‘mpz_init’ before this function is called.
     When ROP is no longer needed the occupied space must be freed with
     ‘mpz_clear’.  *Note (gmp)Initializing Integers::, for details.

 -- C Function: SCM scm_from_mpz (mpz_t val)
     Return the ‘SCM’ value that represents VAL.