This is guile.info, produced by makeinfo version 4.13 from guile.texi. This reference manual documents Guile, GNU's Ubiquitous Intelligent Language for Extensions. This is edition 1.1 corresponding to Guile 1.8.8. Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the no Invariant Sections, with the Front-Cover Texts being "A GNU Manual," and with the Back-Cover Text "You are free to copy and modify this GNU Manual.". 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 reference manual documents Guile, GNU's Ubiquitous Intelligent Language for Extensions. This is edition 1.1 corresponding to Guile 1.8.8. Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the no Invariant Sections, with the Front-Cover Texts being "A GNU Manual," and with the Back-Cover Text "You are free to copy and modify this GNU Manual.". A copy of the license is included in the section entitled "GNU Free Documentation License". * Menu: * Preface:: * Introduction to Guile:: * Programming in Scheme:: * Programming in C:: * API Reference:: * Guile Modules:: * Autoconf Support:: Appendices * Data Representation:: All the details. * 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 to Guile, Prev: Top, Up: Top 1 Preface ********* This reference manual documents Guile, GNU's Ubiquitous Intelligent Language for Extensions. It describes how to use Guile in many useful and interesting ways. This is edition 1.1 of the reference manual, and corresponds to Guile version 1.8.8. * Menu: * Manual Layout:: * Manual Conventions:: * Contributors:: * Guile License::  File: guile.info, Node: Manual Layout, Next: Manual Conventions, Up: Preface 1.1 Layout of this Manual ========================= The manual is divided into five chapters. *Chapter 1: Introduction to Guile* This part provides an overview of what Guile is and how you can use it. 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. This part also explains how to obtain and install new versions of Guile, and how to report bugs effectively. *Chapter 2: Programming in Scheme* This part provides an overview over 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 gives an introduction into the basic ideas of Scheme itself and to the various extensions that Guile offers beyond standard Scheme. *Chapter 3: Programming in C* This part 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 4: 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 5: Guile Modules* Describes some important modules, distributed as part of the Guile distribution, that extend the functionality provided by the Guile Scheme core.  File: guile.info, Node: Manual Conventions, Next: Contributors, Prev: Manual Layout, Up: Preface 1.2 Conventions used in this Manual =================================== We use some conventions in this manual. * For some procedures, notably type predicates, we use "iff" to mean "if and only if". The construct is usually something like: `Return VAL iff CONDITION', where VAL is usually "#t" or "non-#f". This typically means that VAL is returned if CONDITION holds, and that `#f' is returned otherwise. To clarify: VAL will *only* be returned when CONDITION is true. * 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 `=>'). Do not confuse the two.  File: guile.info, Node: Contributors, Next: Guile License, Prev: Manual Conventions, Up: Preface 1.3 Contributors to this Manual =============================== The Guile reference and tutorial manuals were written and edited largely 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 contributed by Gary Houston (contributions to POSIX system calls and networking, expect, I/O internals and extensions, slib installation, error handling) and Tim Pierce (sections on script interpreter triggers, alists, function tracing). Tom Lord contributed a great deal of material with early Guile snapshots; although most of this text has been rewritten, all of it was important, and some of the structure remains. Aubrey Jaffer wrote the SCM Scheme implementation and manual upon which the Guile program and manual are based. Some portions of the SCM and SLIB manuals have been included here verbatim. Since Guile 1.4, Neil Jerram has been maintaining and improving the reference manual. Among other contributions, he wrote the Basic Ideas chapter, developed the tools for keeping the manual in sync with snarfed libguile docstrings, and reorganized the structure so as to accommodate docstrings for all Guile's primitives. Martin Grabmueller has made substantial contributions throughout the reference 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.  File: guile.info, Node: Guile License, Prev: Contributors, Up: Preface 1.4 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 2.1. See the file `COPYING.LIB'. * The Guile readline module is published under the terms of the GNU General Public License version 2. 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 resticted 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 to Guile, Next: Programming in Scheme, Prev: Preface, Up: Top 2 Introduction to Guile *********************** * Menu: * What is Guile?:: * Obtaining and Installing Guile:: * Whirlwind Tour:: * Discouraged and Deprecated:: * Reporting Bugs::  File: guile.info, Node: What is Guile?, Next: Obtaining and Installing Guile, Up: Introduction to Guile 2.1 What is Guile? ================== Guile is an interpreter for the Scheme programming language, packaged for use in a wide variety of environments. 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. 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. However, Guile is also packaged as an object library, allowing 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. 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. In the future, we hope to expand Guile to support other languages like Tcl and Perl by translating them to Scheme code. 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: Whirlwind Tour, Prev: What is Guile?, Up: Introduction to Guile 2.2 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 1.8.8, so the file you should grab is: `ftp://ftp.gnu.org/gnu/guile/guile-1.8.8.tar.gz' To unbundle Guile use the instruction zcat guile-1.8.8.tar.gz | tar xvf - which will create a directory called `guile-1.8.8' 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-1.8.8 ./configure make make install This will install the Guile executable `guile', the Guile library `-lguile' and various associated header files and support libraries. It will also install the Guile tutorial and 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; *Note Introduction: (r5rs)Top. This will also be installed in your info directory.  File: guile.info, Node: Whirlwind Tour, Next: Discouraged and Deprecated, Prev: Obtaining and Installing Guile, Up: Introduction to Guile 2.3 A Whirlwind Tour ==================== 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. 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::  File: guile.info, Node: Running Guile Interactively, Next: Running Guile Scripts, Up: Whirlwind Tour 2.3.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 `guile>' prompts: $ guile guile> (+ 1 2 3) ; add some numbers 6 guile> (define (factorial n) ; define a function (if (zero? n) 1 (* n (factorial (- n 1))))) guile> (factorial 20) 2432902008176640000 guile> (getpwnam "jimb") ; find my entry in /etc/passwd #("jimb" ".0krIpK2VqNbU" 4008 10 "Jim Blandy" "/u/jimb" "/usr/local/bin/bash") guile> C-d $  File: guile.info, Node: Running Guile Scripts, Next: Linking Guile into Programs, Prev: Running Guile Interactively, Up: Whirlwind Tour 2.3.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, for more details *Note Guile Scripting::. #!/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: Whirlwind Tour 2.3.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 #include 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 -lguile When it is run, it behaves just like the `guile' program except that you can also call the new `my-hostname' function. $ ./simple-guile guile> (+ 1 2 3) 6 guile> (my-hostname) "burns"  File: guile.info, Node: Writing Guile Extensions, Next: Using the Guile Module System, Prev: Linking Guile into Programs, Up: Whirlwind Tour 2.3.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 "extensions", 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 #include SCM j0_wrapper (SCM x) { return scm_make_real (j0 (scm_num2dbl (x, "j0"))); } 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 -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 guile> (load-extension "./libguile-bessel" "init_bessel") guile> (j0 2) 0.223890779141236  File: guile.info, Node: Using the Guile Module System, Prev: Writing Guile Extensions, Up: Whirlwind Tour 2.3.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. (Although the module system implementation is in flux, feel free to use it anyway. Guile will provide reasonable backwards compatibility.) Details on the module system beyond this introductory material can be found in *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.3.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 guile> (use-modules (ice-9 popen)) guile> (use-modules (ice-9 rdelim)) guile> (define p (open-input-pipe "ls -l")) guile> (read-line p) "total 30" guile> (read-line p) "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.3.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/foo/bar.scm (define-module (foo bar)) (export frob) (define (frob x) (* 2 x)) $ guile guile> (use-modules (foo bar)) guile> (frob 12) 24  File: guile.info, Node: Putting Extensions into Modules, Prev: Writing new Modules, Up: Using the Guile Module System 2.3.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/math/bessel.scm (define-module (math bessel)) (export j0) (load-extension "libguile-bessel" "init_bessel") $ file /usr/local/lib/libguile-bessel.so ... ELF 32-bit LSB shared object ... $ guile guile> (use-modules (math bessel)) guile> (j0 2) 0.223890779141236 There is also a way to manipulate the module system from C but only Scheme files can be autoloaded. Thus, we recommend that you define your modules in Scheme.  File: guile.info, Node: Discouraged and Deprecated, Next: Reporting Bugs, Prev: Whirlwind Tour, Up: Introduction to Guile 2.4 Discouraged and Deprecated ============================== From time to time functions and other features of Guile become obsolete. Guile has some mechanisms in place that can help you cope with this. Guile has two levels of obsoleteness: things can be _deprecated_, meaning that their use is considered harmful and should be avoided, even in old code; or they can be merely _discouraged_, meaning that they are fine in and of themselves, but that there are better alternatives that should be used in new code. When you use a feature that is deprecated, you will likely get a warning message at run-time. Also, deprecated features are not ready for production use: they might be very slow. When something is merely discouraged, it performs normally and you wont get any messages at run-time. The primary source for information about just what things are discouraged or 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 and/or discouraged features from the public API of Guile, and how to control the warning messages for deprecated features. The idea behind those mechanisms is that normally all deprecated and discouraged features are available, but that you can omit them on purpose to check whether your code still relies on them.  File: guile.info, Node: Reporting Bugs, Prev: Discouraged and Deprecated, Up: Introduction to Guile 2.5 Reporting Bugs ================== Any problems with the installation should be reported to . Whenever you have found a bug in Guile you are encouraged to 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. 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. Without this, we won't know whether there is any point in looking for the bug in the current version of Guile. You can get the version number by invoking the command $ guile --version Guile 1.4.1 Copyright (c) 1995, 1996, 1997, 2000, 2006 Free Software Foundation Guile may be distributed under the terms of the GNU General Public License; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. * The type of machine you are using, and the operating system name and version number. On GNU systems, you can get it with `uname'. $ uname -a Linux tortoise 2.2.17 #1 Thu Dec 21 17:29:05 CET 2000 i586 unknown * The operands given to the `configure' command when Guile was installed. It's often useful to augment this with the output of the command `guile-config info'. * A complete list of any modifications you have made to the Guile source. (We may not have time to investigate the bug unless it happens in an unmodified Guile. But if you've made modifications and you don't tell us, you are sending us on a wild goose chase.) Be precise about these changes. A description in English is not enough--send a context diff for them. Adding files of your own, or porting to another machine, is a modification of the source. * Details of any other deviations from the standard procedure for installing Guile. * The complete text of any source files needed to reproduce the bug. If you can tell us a way to cause the problem without loading any source files, please do so. This makes it much easier to debug. If you do need files, make sure you arrange for us to see their exact contents. * The precise Guile invocation command line we need to type to reproduce the bug. * A description of what behavior you observe that you believe is incorrect. For example, "The Guile process gets a fatal signal," or, "The resulting output is as follows, which I think is wrong." Of course, if the bug is that Guile gets a fatal signal, then one can't miss it. But if the bug is incorrect results, the maintainer might fail to notice what is wrong. Why leave it to chance? 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 procedure `backtrace' in the REPL. * 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. * If the problem does depend on an init file or other Scheme programs that are not part of the standard Guile distribution, then you should make sure it is not a bug in those programs by complaining to their maintainers first. After they verify that they are using Guile in a way that is supposed to work, they should report the bug. * If you wish to mention something in the Guile source, show the line of code with a few lines of context. Don't just give a line number. The line numbers in the development sources might not match those in your sources. It would take extra work for the maintainers to determine what code is in your version at a given line number, and we could not be certain. * Additional information from a C debugger such as GDB might enable someone to find a problem on a machine which he does not have available. If you don't know how to use GDB, please read the GDB manual--it is not very long, and using GDB is easy. You can find the GDB distribution, including the GDB manual in online form, in most of the same places you can find the Guile distribution. To run Guile under GDB, you should switch to the `libguile' subdirectory in which Guile was compiled, then do `gdb guile' or `gdb .libs/guile' (if using GNU Libtool). However, you need to think when you collect the additional information if you want it to show what causes the bug. For example, many people send just a backtrace, but that is not very useful by itself. A simple backtrace with arguments often conveys little about what is happening inside Guile, because most of the arguments listed in the backtrace are pointers to Scheme objects. The numeric values of these pointers have no significance whatever; all that matters is the contents of the objects they point to (and most of the contents are themselves pointers).  File: guile.info, Node: Programming in Scheme, Next: Programming in C, Prev: Introduction to Guile, Up: Top 3 Programming in Scheme *********************** Guile's core language is Scheme, and an awful lot can be achieved simply by using Guile to write and run Scheme programs. 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 readers who are not yet familiar with the Scheme language, this part includes a chapter that presents the basic concepts of the language, and gives references to freely available Scheme tutorial material on the web. For detailed reference information on the variables, functions etc. that make up Guile's application programming interface (API), *Note API Reference::. * Menu: * Basic Ideas:: Basic ideas in Scheme. * Guile Scheme:: Guile's implementation of Scheme. * Guile Scripting:: How to write Guile scripts. * Using Guile Interactively:: Guile's REPL features. * Using Guile in Emacs:: Guile and Emacs. * Further Reading:: Where to find out more about Scheme.  File: guile.info, Node: Basic Ideas, Next: Guile Scheme, Up: Programming in Scheme 3.1 Basic Ideas in 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 reference chapters that follow. The style of this introductory material aims about halfway between the terse precision of R5RS and the discursive randomness of a Scheme tutorial. * 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.  File: guile.info, Node: About Data, Next: About Procedures, Up: Basic Ideas 3.1.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.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.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.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: Basic Ideas 3.1.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.1.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.1.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.1.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) EXPRESSION ...) 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 in the "body" of the procedure definition. (Typically, these EXPRESSIONs 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 procedure 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.1.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 ...]]) EXPRESSION ...) is exactly equivalent to the longer form (define NAME (lambda ([ARG1 [ARG2 ...]]) EXPRESSION ...)) 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) EXPRESSION ...) (lambda ARGS EXPRESSION ...) The corresponding forms of the alternative `define' syntax are: (define (NAME ARG1 ... . ARGS) EXPRESSION ...) (define (NAME . ARGS) EXPRESSION ...) For details on how these forms work, see *Note Lambda::. (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 some 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: Basic Ideas 3.1.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.1.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. 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::). 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. 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. 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::. ---------- 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: Tail Calls, Next: The REPL, Prev: Evaluating, Up: About Expressions 3.1.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.1.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 `#', 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.1.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 if cond case::) provide conditional evaluation of argument expressions depending on whether one or more conditions evaluate to "true" or "false". `case' (*note if cond case::) 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, Prev: About Expressions, Up: Basic Ideas 3.1.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.1.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.1.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.1.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.1.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. 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.1.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.1.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.1.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.1.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 () ... ...)) (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.1.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 => # 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: Guile Scheme, Next: Guile Scripting, Prev: Basic Ideas, Up: Programming in Scheme 3.2 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". The current latest revision of RnRS is version 5 (*note R5RS: (r5rs)Top.), and Guile 1.4 is fully compliant with the Scheme specification in this revision. But Guile, like most Scheme implementations, also goes beyond R5RS in many ways, because R5RS does not give specifications (or even recommendations) regarding many issues that are important in practical programming. Some of the areas where Guile extends R5RS 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: Guile Scripting, Next: Using Guile Interactively, Prev: Guile Scheme, Up: Programming in Scheme 3.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. * Invoking Guile:: Command line options understood by Guile. * 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: Invoking Guile, Up: Guile Scripting 3.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. * 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: Invoking Guile, Next: The Meta Switch, Prev: The Top of a Script File, Up: Guile Scripting 3.3.2 Invoking Guile -------------------- 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::. `-s SCRIPT ARG...' Read and evaluate Scheme source code from the file SCRIPT, as the `load' function would. After loading SCRIPT, exit. 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...)'. `-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. `-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. For compatibility with some versions of Guile 1.4, you can also use the form `(symbol ...)' (that is, a list of only symbols that doesn't start with `@'), which is equivalent to `(@ (symbol ...) main)', or `(symbol ...) symbol' (that is, a list of only symbols followed by a symbol), which is equivalent to `(@ (symbol ...) symbol)'. We recommend to use the equivalent forms directly since they corresponf to the `(@ ...)' read syntax that can be used in normal code, *Note Using Guile Modules::. *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::. `--emacs' Assume Guile is running as an inferior process of Emacs, and use a special protocol to communicate with Emacs's Guile interaction mode. This switch sets the global variable use-emacs-interface to `#t'. This switch is still experimental. `--use-srfi=LIST' The option `--use-srfi' expects a comma-separated list of numbers, each representing a SRFI number to be loaded into the interpreter before starting evaluating a script file or the REPL. Additionally, the feature identifier for the loaded SRFIs is recognized by `cond-expand' when using this option. guile --use-srfi=8,13 `--debug' Start with the debugging evaluator and enable backtraces. Using the debugging evaluator will give you better error messages but it will slow down execution. By default, the debugging evaluator is only used when entering an interactive session. When executing a script with `-s' or `-c', the normal, faster evaluator is used by default. `--no-debug' Do not use the debugging evaluator, even when entering an interactive session. `-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: The Meta Switch, Next: Command Line Handling, Prev: Invoking Guile, Up: Guile Scripting 3.3.3 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 3.3.4 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 3.3.5 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 -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  File: guile.info, Node: Using Guile Interactively, Next: Using Guile in Emacs, Prev: Guile Scripting, Up: Programming in Scheme 3.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. guile> (+ 3 4 5) 12 guile> (display "Hello world!\n") Hello world! guile> (values 'a 'b) a 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. * Menu: * Readline:: * Value Historyx:: * Error Handling:: * Interactive Debugger:: Using the interactive debugger.  File: guile.info, Node: Readline, Next: Value Historyx, Up: Using Guile Interactively 3.4.1 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. guile> (use-modules (ice-9 readline)) guile> (activate-readline) It's a good idea to put these two lines (without the "guile>" prompts) in your `.guile' file. Guile reads this file when it starts up interactively, so anything in this file has the same effect as if you type it in by hand at the "guile>" prompt.  File: guile.info, Node: Value Historyx, Next: Error Handling, Prev: Readline, Up: Using Guile Interactively 3.4.2 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', ..., and you can then use these variables in subsequent expressions. guile> (iota 10) $1 = (0 1 2 3 4 5 6 7 8 9) guile> (apply * (cdr $1)) $2 = 362880 guile> (sqrt $2) $3 = 602.3952191045344 guile> (cons $2 $1) $4 = (362880 0 1 2 3 4 5 6 7 8 9) To enable value history, type `(use-modules (ice-9 history))' at the Guile prompt, or add this to your `.guile' file. (It is not enabled by default, to avoid the possibility of conflicting with some other use you may have for the variables `$1', `$2', ..., and also because it prevents the stored evaluation results from being garbage collected, which some people may not want.)  File: guile.info, Node: Error Handling, Next: Interactive Debugger, Prev: Value Historyx, Up: Using Guile Interactively 3.4.3 Error Handling -------------------- When code being evaluated from the REPL hits an error, Guile remembers the execution context where the error occurred and can give you three levels of information about what the error was and exactly where it occurred. By default, Guile displays only the first level, which is the most immediate information about where and why the error occurred, for example: (make-string (* 4 (+ 3 #\s)) #\space) -| standard input:2:19: In procedure + in expression (+ 3 #\s): standard input:2:19: Wrong type argument: #\s ABORT: (wrong-type-arg) Type "(backtrace)" to get more information or "(debug)" to enter the debugger. However, as the message above says, you can obtain more information about the context of the error by typing `(backtrace)' or `(debug)'. `(backtrace)' displays the Scheme call stack at the point where the error occurred: (backtrace) -| Backtrace: In standard input: 2: 0* [make-string ... 2: 1* [* 4 ... 2: 2* [+ 3 #\s] Type "(debug-enable 'backtrace)" if you would like a backtrace automatically if an error occurs in the future. In a more complex scenario than this one, this can be extremely useful for understanding where and why the error occurred. You can make Guile show the backtrace automatically by adding `(debug-enable 'backtrace)' to your `.guile'. `(debug)' takes you into Guile's interactive debugger, which provides commands that allow you to * display the Scheme call stack at the point where the error occurred (the `backtrace' command -- see *note Display Backtrace::) * move up and down the call stack, to see in detail the expression being evaluated, or the procedure being applied, in each "frame" (the `up', `down', `frame', `position', `info args' and `info frame' commands -- see *note Frame Selection:: and *note Frame Information::) * examine the values of variables and expressions in the context of each frame (the `evaluate' command -- see *note Frame Evaluation::). The interactive debugger is documented further in the following section.  File: guile.info, Node: Interactive Debugger, Prev: Error Handling, Up: Using Guile Interactively 3.4.4 Using the Interactive Debugger ------------------------------------ Guile's interactive debugger is a command line application that accepts commands from you for examining the stack and, if stopped at a trap, for continuing program execution in various ways. Unlike in the normal Guile REPL, commands are typed mostly without parentheses. When you first enter the debugger, it introduces itself with a message like this: This is the Guile debugger -- for help, type `help'. There are 3 frames on the stack. Frame 2 at standard input:36:19 [+ 3 #\s] debug> "debug>" is the debugger's prompt, and a reminder that you are not in the normal Guile REPL. In case you find yourself in the debugger by mistake, the `quit' command will return you to the REPL. -- Debugger Command: quit Exit the debugger. The other available commands are described in the following subsections. * Menu: * Display Backtrace:: backtrace. * Frame Selection:: up, down, frame. * Frame Information:: info args, info frame, position. * Frame Evaluation:: evaluate. * Stepping and Continuing:: step, next, (trace-)finish, continue.  File: guile.info, Node: Display Backtrace, Next: Frame Selection, Up: Interactive Debugger 3.4.4.1 Display Backtrace ......................... The `backtrace' command, which can also be invoked as `bt' or `where', displays the call stack (aka backtrace) at the point where the debugger was entered: debug> bt In standard input: 36: 0* [make-string ... 36: 1* [* 4 ... 36: 2* [+ 3 #\s] -- Debugger Command: backtrace [count] -- Debugger Command: bt [count] -- Debugger Command: where [count] Print backtrace of all stack frames, or of the innermost COUNT frames. With a negative argument, print the outermost -COUNT frames. If the number of frames isn't explicitly given, the debug option `depth' determines the maximum number of frames printed. The format of the displayed backtrace is the same as for the `display-backtrace' procedure (*note Examining the Stack::).  File: guile.info, Node: Frame Selection, Next: Frame Information, Prev: Display Backtrace, Up: Interactive Debugger 3.4.4.2 Frame Selection ....................... A call stack consists of a sequence of stack "frames", with each frame describing one level of the nested evaluations and applications that the program was executing when it hit a breakpoint or an error. Frames are numbered such that frame 0 is the outermost -- i.e. the operation on the call stack that began least recently -- and frame N-1 the innermost (where N is the total number of frames on the stack). 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: debug> up Frame 1 at standard input:36:14 [* 4 ... debug> frame 0 Frame 0 at standard input:36:1 [make-string ... debug> down Frame 1 at standard input:36:14 [* 4 ... -- Debugger Command: up [n] Move N frames up the stack. For positive N, this advances toward the outermost frame, to lower frame numbers, to frames that have existed longer. N defaults to one. -- Debugger Command: down [n] Move N frames down the stack. For positive N, this advances toward the innermost frame, to higher frame numbers, to frames that were created more recently. N defaults to one. -- Debugger Command: frame [n] Select and print a stack frame. With no argument, print the selected stack frame. (See also "info frame".) An argument specifies the frame to select; it must be a stack-frame number.  File: guile.info, Node: Frame Information, Next: Frame Evaluation, Prev: Frame Selection, Up: Interactive Debugger 3.4.4.3 Frame Information ......................... The following commands return detailed information about the currently selected frame. -- Debugger Command: info frame Display a verbose description of the selected frame. The information that this command provides is equivalent to what can be deduced from the one line summary for the frame that appears in a backtrace, but is presented and explained more clearly. -- Debugger Command: info args Display the argument variables of the current stack frame. Arguments can also be seen in the backtrace, but are presented more clearly by this command. -- Debugger Command: position Display the name of the source file that the current expression comes from, and the line and column number of the expression's opening parenthesis within that file. This information is only available when the `positions' read option is enabled (*note Reader options::).  File: guile.info, Node: Frame Evaluation, Next: Stepping and Continuing, Prev: Frame Information, Up: Interactive Debugger 3.4.4.4 Frame Evaluation ........................ The `evaluate' command is most useful for querying the value of a variable, either global or local, in the environment of the selected stack frame, but it can be used more generally to evaluate any expression. -- Debugger Command: evaluate expression Evaluate an expression in the environment of the selected stack frame. The expression must appear on the same line as the command, however it may be continued over multiple lines.  File: guile.info, Node: Stepping and Continuing, Prev: Frame Evaluation, Up: Interactive Debugger 3.4.4.5 Single Stepping and Continuing Execution ................................................ 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. -- Debugger Command: step [n] Tell the debugged program to do N more steps from its current position. One "step" means executing until the next frame entry or exit of any kind. N defaults to 1. -- Debugger Command: next [n] Tell the debugged program to do N more steps from its current position, but only counting frame entries and exits where the corresponding source code comes from the same file as the current stack frame. (See *note Step Traps:: for the details of how this works.) If the current stack frame has no source code, the effect of this command is the same as of `step'. N defaults to 1. -- Debugger 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 command line debugger. -- Debugger Command: continue Tell the program being debugged to continue running. (In fact this is the same as the `quit' command, because it exits the debugger command loop and so allows whatever code it was that invoked the debugger to continue.)  File: guile.info, Node: Using Guile in Emacs, Next: Further Reading, Prev: Using Guile Interactively, Up: Programming in Scheme 3.5 Using Guile in Emacs ======================== There are several options for working on Guile Scheme code in Emacs. The simplest are to use Emacs's standard `scheme-mode' for editing code, and to run the interpreter when you need it by typing "guile" at the prompt of a `*shell*' buffer, but there are Emacs libraries available which add various bells and whistles to this. The following diagram shows these libraries and how they relate to each other, with the arrows indicating "builds on" or "extends". For example, the Quack library builds on cmuscheme, which in turn builds on the standard scheme mode. scheme ^ | .-----+-----. | | cmuscheme xscheme ^ | .-----+-----. | | Quack GDS "scheme", written by Bill Rozas and Dave Love, is Emacs's standard mode for Scheme code files. It provides Scheme-sensitive syntax highlighting, parenthesis matching, indentation and so on. "cmuscheme", written by Olin Shivers, provides a comint-based Scheme interaction buffer, so that you can run an interpreter more directly than with the `*shell*' buffer approach by typing `M-x run-scheme'. It also extends `scheme-mode' so that there are key presses for sending selected bits of code from a Scheme buffer to this interpreter. This means that when you are writing some code and want to check what an expression evaluates to, you can easily select that code and send it to the interpreter for evaluation, then switch to the interpreter to see what the result is. cmuscheme is included in the standard Emacs distribution. "Quack", written by Neil Van Dyke, adds a number of incremental improvements to the scheme/cmuscheme combination: convenient menu entries for looking up Scheme-related references (such as the SRFIs); enhanced indentation rules that are customized for particular Scheme interpreters, including Guile; an enhanced version of the `run-scheme' command that knows the names of the common Scheme interpreters and remembers which one you used last time; and so on. Quack is available from `http://www.neilvandyke.org/quack'. "GDS", written by Neil Jerram, also builds on the scheme/cmuscheme combination, but with a change to the way that Scheme code fragments are sent to the interpreter for evaluation. cmuscheme and Quack send code fragments to the interpreter's standard input, on the assumption that the interpreter is expecting to read Scheme expressions there, and then monitor the interpreter's standard output to infer what the result of the evaluation is. GDS doesn't use standard input and output like this. Instead, it sets up a socket connection between the Scheme interpreter and Emacs, and sends and receives messages using a simple protocol through this socket. The messages include requests to evaluate Scheme code, and responses conveying the results of an evaluation, thus providing similar function to cmuscheme or Quack. They also include requests for stack exploration and debugging, which go beyond what cmuscheme or Quack can do. The price of this extra power, however, is that GDS is Guile-specific. GDS requires the Scheme interpreter to run some GDS-specific library code; currently this code is written as a Guile module and uses features that are specific to Guile. GDS is now included in the Guile distribution; for previous Guile releases (1.8.4 and earlier) it can be obtained as part of the `guile-debugging' package from `http://www.ossau.uklinux.net/guile'. Finally, "xscheme" is similar to cmuscheme -- in that it starts up a Scheme interaction process and sends commands to that process's standard input -- and to GDS -- in that it has support beyond cmuscheme or Quack for exploring the Scheme stack when an error has occurred -- but is implemented specifically for MIT/GNU Scheme. Hence it isn't really relevant to Guile work in Emacs, except as a reference for useful features that could be implemented in one of the other libraries mentioned here. In summary, the best current choice for working on Guile code in Emacs is either Quack or GDS, depending on which of these libraries' features you find most important. For more information on Quack, please see the website referenced above. GDS is documented further in the rest of this section. * Menu: * GDS Introduction:: * GDS Architecture:: * GDS Getting Started:: * Working with GDS in Scheme Buffers:: * Displaying the Scheme Stack:: * Continuing Execution:: * Associating Buffers with Clients:: * An Example GDS Session::  File: guile.info, Node: GDS Introduction, Next: GDS Architecture, Up: Using Guile in Emacs 3.5.1 GDS Introduction ---------------------- GDS aims to allow you to work on Guile Scheme code in the same kind of way that Emacs allows you to work on Emacs Lisp code: providing easy access to help, evaluating arbitrary fragments of code, a nice debugging interface, and so on. The thinking behind the GDS library is that you will usually be doing one of two things. 1. Writing or editing code. The code will be in a normal Emacs Scheme mode buffer, and GDS extends Scheme mode to add keystrokes and menu items for the things that are likely to be useful to you when working on code: * completing the identifier at point, with respect to the set of variable names that are known to the associated Guile process * accessing Guile's built in "help" and "apropos" commands * evaluating fragments of code to check what they do, with the results popping up in a temporary Emacs window. 2. Debugging a Guile Scheme program. When your program hits an error or stops at a trap, GDS shows you the relevant code and the Scheme stack, and makes it easy to * look at the values of local variables * see what is happening at all levels of the Scheme stack * continue execution, either normally or step by step. The presentation makes it very easy to move up and down the stack, showing whenever possible the source code for each frame in another Emacs buffer. It also provides convenient keystrokes for telling Guile what to do next; for example, you can select a stack frame and tell Guile to run until that frame completes, at which point GDS will display the frame's return value. GDS can provide these facilities for any number of Guile Scheme programs (which we often refer to as "clients") at once, and these programs can be started either independently of GDS, including outside Emacs, or specifically _by_ GDS. Communication between each Guile client program and GDS uses a TCP socket, which means that it is orthogonal to any other interfaces that the client program has. In particular GDS does not interfere with a program's standard input and output.  File: guile.info, Node: GDS Architecture, Next: GDS Getting Started, Prev: GDS Introduction, Up: Using Guile in Emacs 3.5.2 GDS Architecture ---------------------- In order to understand the following documentation fully it will help to have a picture in mind of how GDS works, so we briefly describe that here. GDS consists of three components. * The GDS "interface" code is written in Emacs Lisp and runs inside Emacs. This code, consisting of the installed files `gds.el' and `gds-server.el', is responsible for displaying information from Guile in Emacs windows, and for responding to Emacs commands and keystrokes by sending instructions back to the Guile program being worked on. * The GDS "server" code is written in Scheme and runs as an Emacs inferior process. It acts as a multiplexer between the (possibly multiple) Guile programs being debugged and the interface code running in Emacs. The server code is the installed file `gds-server.scm'. * The GDS "client" code is written in Scheme (installed file `gds-client.scm'), and must be loaded as a module by each Guile program that wants to use GDS in any way. The following diagram shows how these components are connected to each other. +----------------+ | Program #1 | | | | +------------+ | | | GDS Client |-_ | +------------+ |-_ +-------------------+ +----------------+ -_TCP | Emacs | -_ | | -_+------------+ | +---------------+ | _| GDS Server |-----| GDS Interface | | +----------------+ _- +------------+ | +---------------+ | | Program #2 | _- +-------------------+ | | _- TCP | +------------+ _- | | GDS Client |-| | +------------+ | +----------------+ The data exchanged between client and server components, and between server and interface, is a sequence of sexps (parenthesised expressions) that are designed so as to be directly readable by both Scheme and Emacs Lisp. The use of a TCP connection means that the server and Emacs interface can theoretically be on a different computer from the client programs, but in practice there are currently two problems with this. Firstly the GDS API doesn't provide any way of specifying a non-local server to connect to, and secondly there is no security or authentication mechanism in the GDS protocol. These are issues that should be addressed in the future.  File: guile.info, Node: GDS Getting Started, Next: Working with GDS in Scheme Buffers, Prev: GDS Architecture, Up: Using Guile in Emacs 3.5.3 Getting Started with GDS ------------------------------ To enable the use of GDS in your own Emacs sessions, simply add (require 'gds) somewhere in your `.emacs' file. This will cause Emacs to load the GDS Emacs Lisp code when starting up, and to start the inferior GDS server process so that it is ready and waiting for any Guile programs that want to use GDS. The Scheme side of GDS is systematically installed with Guile, whereas the Emacs Lisp side (the `gds-server.el', `gds-scheme.el', and `gds.el' files) is only installed if Emacs was detected at `configure'-time. Before using GDS, make sure these files are installed and are in Emacs' load path (*note `load-path': (emacs)Lisp Libraries.). (If GDS's Scheme code is not installed in one of the locations in Guile's load path, you may find that the server process fails to start. When this happens you will see an error message from Emacs: error in process filter: Wrong type argument: listp, Backtrace: and the `gds-debug' buffer will contain a Scheme backtrace ending with the message: no code for module (ice-9 gds-server) The solution for this is to customize the Emacs variable `gds-scheme-directory' so that it specifies where the GDS Scheme code is installed. Then either restart Emacs or type `M-x gds-run-debug-server' to try starting the GDS server process again.) For evaluations, help and completion from Scheme code buffers that you are working on, this is all you need. The first time you do any of these things, GDS will automatically start a new Guile client program as an Emacs subprocess. This Guile program does nothing but wait for and act on instructions from GDS, and we refer to it as a "utility" Guile client. Over time this utility client will accumulate the code that you ask it to evaluate, and you can also tell it to load complete files or modules by sending it `load' or `use-modules' expressions. When you want to use GDS to work on an independent Guile application, you need to add something to that application's Scheme code to cause it to connect to and interact with GDS at the right times. The following subsections describe the ways of doing this. 3.5.3.1 Invoking GDS when an Exception Occurs ............................................. One option is to use GDS to catch and display any exceptions that are thrown by the application's code. If you already have a `lazy-catch' or `with-throw-handler' around the area of code that you want to monitor, you just need to add the following to the handler code: (gds-debug-trap (throw->trap-context key args)) where `key' and `args' are the first and rest arguments that Guile passes to the handler. (In other words, they assume the handler signature `(lambda (key . args) ...)'.) With Guile 1.8 or later, you can also do this with a `catch', by adding this same code to the catch's pre-unwind handler. If you don't already have any of these, insert a whole `with-throw-handler' expression (or `lazy-catch' if your Guile is pre-1.8) around the code of interest like this: (with-throw-handler #t (lambda () ;; Protected code here. ) (lambda (key . args) (gds-debug-trap (throw->trap-context key args)))) Either way, you will need to use the `(ice-9 gds-client)' and `(ice-9 debugging traps)' modules. Two special cases of this are the lazy-catch that the Guile REPL code uses to catch exceptions in user code, and the lazy-catch inside the `stack-catch' utility procedure that is provided by the `(ice-9 stack-catch)' module. Both of these use a handler called `lazy-handler-dispatch' (defined in `boot-9.scm'), which you can hook into such that it calls GDS to display the stack when an exception occurs. To do this, use the `on-lazy-handler-dispatch' procedure as follows. (use-modules (ice-9 gds-client) (ice-9 debugging traps)) (on-lazy-handler-dispatch gds-debug-trap) After this the program will use GDS to display the stack whenever it hits an exception that is protected by a `lazy-catch' using `lazy-handler-dispatch'. 3.5.3.2 Accepting GDS Instructions at Any Time .............................................. In addition to setting an exception handler as described above, a Guile program can in principle set itself up to accept new instructions from GDS at any time, not just when it has stopped at an exception. This would allow the GDS user to evaluate code in the context of the running program, without having to wait for the program to stop first. (use-modules (ice-9 gds-client)) (gds-accept-input #t) `gds-accept-input' causes the calling program to loop processing instructions from GDS, until GDS sends the `continue' instruction. This blocks the thread that calls it, however, so it will normally be more practical for the program to set up a dedicated GDS thread and call `gds-accept-input' from that thread. For `select'-driven applications, an alternative approach would be for the GDS client code to provide an API which allowed the application to * discover the file descriptors (or Scheme ports) that are used for receiving instruction from the GDS front end, so that it could include these in its `select' call * call the GDS instruction handler when `select' indicated data available for reading on those descriptors/ports. This approach is not yet implemented, though. 3.5.3.3 Utility Guile Implementation .................................... The "utility" Guile client mentioned above is a simple combination of the mechanisms that we have just described. In fact the code for the utility Guile client is essentially just this: (use-modules (ice-9 gds-client)) (named-module-use! '(guile-user) '(ice-9 session)) (gds-accept-input #f)) The `named-module-use!' line ensures that the client can process `help' and `apropos' expressions, to implement lookups in Guile's online help. The `#f' parameter to `gds-accept-input' means that the `continue' instruction will not cause the instruction loop to exit, which makes sense here because the utility client has nothing to do except to process GDS instructions. The utility client does not use `on-lazy-handler-dispatch' at its top level, because it has its own mechanism for catching and reporting exceptions in the code that it is asked to evaluate. This mechanism summarizes the exception and gives the user a button they can click to see the full stack, so the end result is very similar to what `on-lazy-handler-dispatch' provides. Deep inside `gds-accept-input', in the part that handles evaluating expressions from Emacs, the GDS client code uses `throw->trap-context' and `gds-debug-trap' to implement this.  File: guile.info, Node: Working with GDS in Scheme Buffers, Next: Displaying the Scheme Stack, Prev: GDS Getting Started, Up: Using Guile in Emacs 3.5.4 Working with GDS in Scheme Buffers ---------------------------------------- The following subsections describe the facilities and key sequences that GDS provides for working on code in `scheme-mode' buffers. * Menu: * Access to Guile Help and Completion:: * Evaluating Scheme Code::  File: guile.info, Node: Access to Guile Help and Completion, Next: Evaluating Scheme Code, Up: Working with GDS in Scheme Buffers 3.5.4.1 Access to Guile Help and Completion ........................................... The following keystrokes provide fast and convenient access to Guile's built in help, and to completion with respect to the set of defined and accessible symbols. `C-h g' Get Guile help for a particular symbol, with the same results as if you had typed `(help SYMBOL)' into the Guile REPL (`gds-help-symbol'). The symbol to query defaults to the word at or before the cursor but can also be entered or edited in the minibuffer. The available help is popped up in a temporary Emacs window. `C-h G' List all accessible Guile symbols matching a given regular expression, with the same results as if you had typed `(apropos REGEXP)' into the Guile REPL (`gds-apropos'). The regexp to query defaults to the word at or before the cursor but can also be entered or edited in the minibuffer. The list of matching symbols is popped up in a temporary Emacs window. `M-' Try to complete the symbol at the cursor by matching it against the set of all defined and accessible bindings in the associated Guile process (`gds-complete-symbol'). If there are any extra characters that can be definitively added to the symbol at point, they are inserted. Otherwise, if there are any completions available, they are popped up in a temporary Emacs window, where one of them can be selected using either `' or the mouse.  File: guile.info, Node: Evaluating Scheme Code, Prev: Access to Guile Help and Completion, Up: Working with GDS in Scheme Buffers 3.5.4.2 Evaluating Scheme Code .............................. The following keystrokes and commands provide various ways of sending code to a Guile client process for evaluation. `M-C-x' Evaluate the "top level defun" that the cursor is in, in other words the smallest balanced expression which includes the cursor and whose opening parenthesis is in column 0 (`gds-eval-defun'). `C-x C-e' Evaluate the expression that ends just before the cursor (`gds-eval-last-sexp'). This is designed so that it is easy to evaluate an expression that you have just finished typing. `C-c C-e' Read a Scheme expression using the minibuffer, and evaluate that expression (`gds-eval-expression'). `C-c C-r' Evaluate the Scheme code in the marked region of the current buffer (`gds-eval-region'). Note that GDS does not check whether the region contains a balanced expression, or try to expand the region so that it does; it uses the region exactly as it is. If you type `C-u' before one of these commands, GDS will immediately pop up a Scheme stack buffer, showing the requested evaluation, so that you can single step through it. (This is achieved by setting a `' trap at the start of the requested evaluation; see *note Source Traps:: for more on how those work.) The Scheme stack display, and the options for continuing through the code, are described in the next two sections.  File: guile.info, Node: Displaying the Scheme Stack, Next: Continuing Execution, Prev: Working with GDS in Scheme Buffers, Up: Using Guile in Emacs 3.5.5 Displaying the Scheme Stack --------------------------------- When you specify `gds-debug-trap' as the behaviour for a trap and the Guile program concerned hits that trap, GDS displays the stack and the relevant Scheme source code in Emacs, allowing you to explore the state of the program and then decide what to do next. The same applies if the program calls `(on-lazy-handler-dispatch gds-debug-trap)' and then throws an exception that passes through `lazy-handler-dispatch', except that in this case you can only explore; it isn't possible to continue normal execution after an exception. The following commands are available in the stack buffer for exploring the state of the program. `u', `C-p', `' Select the stack frame one up from the currently selected frame (`gds-up'). GDS displays stack frames with the innermost at the top, so moving "up" means selecting a more "inner" frame. `d', `C-n', `' Select the stack frame one down from the currently selected frame (`gds-down'). GDS displays stack frames with the innermost at the top, so moving "down" means selecting a more "outer" frame. `' Select the stack frame at point (`gds-select-stack-frame'). This is useful after clicking somewhere in the stack trace with the mouse. Selecting a frame means that GDS will display the source code corresponding to that frame in the adjacent window, and that subsequent frame-sensitive commands, such as `gds-evaluate' (see below) and `gds-step-over' (*note Continuing Execution::), will refer to that frame. `e' Evaluate a variable or expression in the local environment of the selected stack frame (`gds-evaluate'). The result is displayed in the echo area. `I' Show summary information about the selected stack frame (`gds-frame-info'). This includes what type of frame it is, the associated expression, and the frame's source location, if any. `A' For an application frame, display the frame's arguments (`gds-frame-args'). `S' For an application frame, show the Scheme source code of the procedure being called (`gds-proc-source'). The source code (where available) is displayed in the echo area. `S' (`gds-proc-source') is useful when the procedure being called was created by an anonymous `(lambda ...)' expression. Such procedures appear in the stack trace as `', which doesn't give you much clue as to what will happen next. `S' will show you the procedure's code, which is usually enough for you to identify it.  File: guile.info, Node: Continuing Execution, Next: Associating Buffers with Clients, Prev: Displaying the Scheme Stack, Up: Using Guile in Emacs 3.5.6 Continuing Execution -------------------------- If it makes sense to continue execution from the stack which is being displayed, GDS provides the following further commands in the stack buffer. `g', `c', `q' Tell the program to continue running (`gds-go'). It may of course stop again if it hits another trap, or another occurrence of the same trap. The multiple keystrokes reflect that you can think of this as "going", "continuing" or "quitting" (in the sense of quitting the GDS display). `' Tell the program to do a single-step to the next entry or exit of a frame whose code comes from the same source file as the selected stack frame (`gds-step-file'). In other words, you can hit `' repeatedly to step through the code in a given file, automatically stepping _over_ any evaluations or procedure calls that use code from other files (or from no file). If the selected stack frame has no source, the effect of this command is the same as that of `i', described next. `i' Tell the debugged program to do a single-step to the next frame entry or exit of any kind (`gds-step-into'). `i' therefore steps through code at the most detailed level possible. `o' Tell the debugged program to continue running until the selected stack frame completes, and then to display its result (`gds-step-over'). Note that the program may stop before then if it hits another trap; in this case the trap telling it to stop when the marked frame completes remains in place and so will still fire at the appropriate point.  File: guile.info, Node: Associating Buffers with Clients, Next: An Example GDS Session, Prev: Continuing Execution, Up: Using Guile in Emacs 3.5.7 Associating Buffers with Clients -------------------------------------- The first time that you use one of GDS's evaluation, help or completion commands from a given Scheme mode buffer, GDS will ask which Guile client program you want to use for the operation, or if you want to start up a new "utility" client. After that GDS considers the buffer to be "associated" with the selected client, and so sends all further requests to that client, but you can override this by explicitly associating the buffer with a different client, or by removing the default association. `M-x gds-associate-buffer' Associate (or re-associate) the current buffer with a particular Guile client program. The available clients are listed, and you can also choose to start up a new "utility" client for this buffer to associate with. `M-x gds-dissociate-buffer' Dissociate the current buffer from its client, if any. This means that the next time you use an evaluation, help or completion command, GDS will ask you again which client to send the request to. When a buffer is associated with a client program, the buffer's modeline shows whether the client is currently able to accept instruction from GDS. This is done by adding one of the following suffixes to the "Scheme" major mode indicator: :ready The client program (or one of its threads, if multithreaded) is currently ready to accept instruction from GDS. In other words, if you send it a help or evaluation request, you should see the result pretty much immediately. :running The client program is not currently able to accept instruction from GDS. This means that it (or all of its threads, if multithreaded) is busy, or waiting for input other than from GDS. :debug The client program (or one of its threads, if multithreaded) is stopped in "debugging mode" with GDS displaying the stack for a trap or exception. It is waiting for instruction from GDS on what to do next.  File: guile.info, Node: An Example GDS Session, Prev: Associating Buffers with Clients, Up: Using Guile in Emacs 3.5.8 An Example GDS Session ---------------------------- Create a file, `testgds.scm' say, for experimenting with GDS and Scheme code, and type this into it: (use-modules (ice-9 debugging traps) (ice-9 gds-client) (ice-9 debugging example-fns)) (install-trap (make #:behaviour gds-debug-trap #:procedure fact1)) Now select all of this code and type `C-c C-r' to send the selected region to Guile for evaluation. GDS will ask you which Guile process to use; unless you know that you already have another Guile application running and connected to GDS, choose the "Start a new Guile" option, which starts one of the "utility" processes described in *note GDS Getting Started::. The results of the evaluation pop up in a window like this: (use-modules (ice-9 debugging traps)\n ... ;;; Evaluating subexpression 1 in current module (guile-user) => no (or unspecified) value ;;; Evaluating subexpression 2 in current module (guile-user) => no (or unspecified) value --:** *Guile Evaluation* (Scheme:ready)--All------------ this tells you that the evaluation was successful but that the return values were unspecified. Its effect was to load a module of example functions and set a trap on one of these functions, `fact1', that calculates the factorial of its argument. If you now call `fact1', you can see the trap and GDS's stack display in action. To do this add (fact1 4) to your `testgds.scm' buffer and type `C-x C-e' (which evaluates the expression that the cursor is just after the end of). The result should be that a GDS stack window like the following appears: Calling procedure: => s [fact1 4] s [primitive-eval (fact1 4)] --:** PID 28729 (Guile-Debug)--All------------ This stack tells you that Guile is about to call the `fact1' procedure, with argument 4, and you can step through this call in detail by pressing `i' once and then `' (*note Continuing Execution::). (`i' is needed as the first keystroke rather than `', because the aim here is to step through code in the `(ice-9 debugging example-fns)' module, whose source file is `.../ice-9/debugging/example-fns.scm', but the initial `(fact1 4)' call comes from the Guile session, whose "source file" Guile presents as `standard input'. If the user starts by pressing `' instead of `i', the effect is that the program runs until it hits the first recursive call `(fact1 (- n 1))', where it stops because of the trap on `fact1' firing again. At this point, the source file _is_ `.../ice-9/debugging/example-fns.scm', because the recursive `(fact1 (- n 1))' call comes from code in that file, so further pressing of `' successfully single-steps through this file.)  File: guile.info, Node: Further Reading, Prev: Using Guile in Emacs, Up: Programming in Scheme 3.6 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 C, Next: API Reference, Prev: Programming in Scheme, Up: Top 4 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 "smobs". 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. There is also 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: * 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 Types (Smobs):: Adding new types to Guile. * Function Snarfing:: A way to define new functions. * Programming Overview:: An overview of Guile programming.  File: guile.info, Node: Linking Programs With Guile, Next: Linking Guile with Libraries, Up: Programming in C 4.1 Linking Programs With Guile =============================== This section covers the mechanics of linking your program with Guile on a typical POSIX system. The header file `' 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'. On most systems, you should not need to tell the compiler and linker explicitly where they can find `libguile.h' and `libguile'. When Guile has been installed in a peculiar way, or when you are on a peculiar system, things might not be so easy and you might need to pass additional `-I' or `-L' options to the compiler. Guile provides the utility program `guile-config' to help you find the right values for these options. You would typically run `guile-config' during the configuration phase of your program and use the obtained information in the Makefile. * 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 4.1.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.  File: guile.info, Node: A Sample Guile Main Program, Prev: Guile Initialization Functions, Up: Linking Programs With Guile 4.1.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 --- how to start up the Guile interpreter from C code. */ /* Get declarations for all the scm_ functions. */ #include static void inner_main (void *closure, int argc, char **argv) { /* module initializations would go here */ scm_shell (argc, argv); } int main (int argc, char **argv) { scm_boot_guile (argc, argv, inner_main, 0); return 0; /* never reached */ } 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. Here is a Makefile which you can use to compile the above program. It uses `guile-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 CFLAGS=`guile-config compile` # Tell the linker what libraries to use and where to find them. LIBS=`guile-config link` 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 If you are using the GNU Autoconf package to make your application more portable, Autoconf will settle many of the details in the Makefile above automatically, making it much simpler and more portable; we recommend using Autoconf with Guile. Guile also provides the `GUILE_FLAGS' macro for autoconf that performs all necessary checks. Here is a `configure.in' file for `simple-guile' that uses this macro. Autoconf can use this file as a template to generate a `configure' script. In order for Autoconf to find the `GUILE_FLAGS' macro, you will need to run `aclocal' first (*note Invoking aclocal: (automake)Invoking aclocal.). AC_INIT(simple-guile.c) # Find a C compiler. AC_PROG_CC # Check for Guile GUILE_FLAGS # Generate a Makefile, based on the results. AC_OUTPUT(Makefile) 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_LDFLAGS@ 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.in' template, and distribute `configure' with the application. Here's how a user might go about building the application: $ ls Makefile.in configure* configure.in simple-guile.c $ ./configure creating cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for Guile... yes creating ./config.status creating Makefile $ make gcc -c -I/usr/local/include simple-guile.c gcc simple-guile.o -L/usr/local/lib -lguile -lqthreads -lpthread -lm -o simple-guile $ ./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 4.2 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 4.2.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 #include SCM j0_wrapper (SCM x) { return scm_make_real (j0 (scm_num2dbl (x, "j0"))); } 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 -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 Types (Smobs), Prev: Linking Guile with Libraries, Up: Programming in C 4.3 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 4.3.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 approriate 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 4.3.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". It is easy for Guile to remember all blocks of memory that it has allocated for use by Scheme values, but you need to help it with finding all Scheme values that are in use by C code. You do this when writing a SMOB mark function, for example (*note Garbage Collecting Smobs::). By calling this function, the garbage collector learns about all references that your SMOB has to other `SCM' values. Other references to `SCM' objects, such as global variables of type `SCM' or other random data structures in the heap that contain fields of type `SCM', can be made visible to the garbage collector by calling the functions `scm_gc_protect' or `scm_permanent_object'. You normally use these funtions for long lived objects such as a hash table that is stored in a global variable. For temporary references in local variables or function arguments, using these functions would be too expensive. These references are handled differently: Local variables (and function arguments) of type `SCM' are automatically visible to the garbage collector. This works because the collector scans the stack for potential references to `SCM' objects and considers all referenced objects to be alive. The scanning considers each and every word of the stack, regardless of what it is actually used for, and then decides whether it could possibly be a reference to a `SCM' object. Thus, the scanning 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. 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 behabvior: 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 smob and work with that pointer directly. The reference to the `SCM' smob 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 smob 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. For a typical example of its use, see *note Remembering During Operations::.  File: guile.info, Node: Control Flow, Next: Asynchronous Signals, Prev: Garbage Collection, Up: General Libguile Concepts 4.3.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 determing 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 4.3.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. See *Note System 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 , 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 4.3.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. While in guile mode, a thread promises to reach a safe point reasonably frequently (*note Asynchronous Signals::). In addition to running signal handlers, these points are also potential rendezvous points of all guile mode threads where Guile can orchestrate global things like garbage collection. Consequently, when a thread in guile mode blocks and does no longer frequent safe points, it might cause all other guile mode threads to block as well. To prevent this from happening, a guile mode thread should either only block in libguile functions (who know how to do it right), or should temporarily leave guile mode with `scm_without_guile'. 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 non-sensical 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_SIMPLE_VECTOR_LENGTH (vector); i = 0; while (i < len && scm_is_pair (list)) { SCM_SIMPLE_VECTOR_SET (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 (`SCM_SIMPLE_VECTOR_SET' does no range-checking) and that it doesn't overrung the list (`SCM_CAR' and `SCM_CDR' likewise do no type checking). 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 simple 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_SIMPLE_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_SIMPLE_VECTOR_LENGTH (vector); i = 0; while (i < len) { SCM_SIMPLE_VECTOR_SET (vector, i, scm_car (list)); list = scm_cdr (list); i++; } return vector; } This version uses the type-checking and thread-robust functions `scm_car' and `scm_cdr' instead of the faster, but less robust macros `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-safeness 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.  File: guile.info, Node: Defining New Types (Smobs), Next: Function Snarfing, Prev: General Libguile Concepts, Up: Programming in C 4.4 Defining New Types (Smobs) ============================== "Smobs" are Guile's mechanism for adding new primitive types to the system. The term "smob" was coined by Aubrey Jaffer, who says it comes from "small object", referring to the fact that they are quite limited in size: they can hold just one pointer to a larger memory block plus 16 extra bits. To define a new smob type, the programmer provides Guile with some essential information about the type -- how to print it, how to garbage collect it, and so on -- and Guile allocates a fresh type tag for it. The programmer can then use `scm_c_define_gsubr' to make a set of C functions visible to Scheme code that create and operate on these objects. (You can find a complete version of the example code used in this section in the Guile distribution, in `doc/example-smob'. That directory includes a makefile and a suitable `main' function, so you can build a complete interactive Guile shell, extended with the datatypes described here.) * Menu: * Describing a New Type:: * Creating Instances:: * Type checking:: * Garbage Collecting Smobs:: * Garbage Collecting Simple Smobs:: * Remembering During Operations:: * Double Smobs:: * The Complete Example::  File: guile.info, Node: Describing a New Type, Next: Creating Instances, Up: Defining New Types (Smobs) 4.4.1 Describing a New Type --------------------------- To define a new type, the programmer must write four functions to manage instances of the type: `mark' Guile will apply this function to each instance of the new type it encounters during garbage collection. This function is responsible for telling the collector about any other `SCM' values that the object has stored. The default smob mark function does nothing. *Note Garbage Collecting Smobs::, for more details. `free' Guile will apply this function to each instance of the new type that is to be deallocated. The function should release all resources held by the object. This is analogous to the Java finalization method- it is invoked at an unspecified time (when garbage collection occurs) after the object is dead. The default free function frees the smob data (if the size of the struct passed to `scm_make_smob_type' is non-zero) using `scm_gc_free'. *Note Garbage Collecting Smobs::, for more details. This function operates while the heap is in an inconsistent state and must therefore be careful. *Note Smobs::, for details about what this function is allowed to do. `print' Guile will apply this function to each instance of the new type to print the value, as for `display' or `write'. The default print function prints `#' where `NAME' is the first argument passed to `scm_make_smob_type'. For more information on printing, see *note Port Data::. `equalp' If Scheme code asks the `equal?' function to compare two instances of the same smob type, Guile calls this function. It should return `SCM_BOOL_T' if A and B should be considered `equal?', or `SCM_BOOL_F' otherwise. If `equalp' is `NULL', `equal?' will assume that two instances of this type are never `equal?' unless they are `eq?'. To actually register the new smob type, call `scm_make_smob_type'. It returns a value of type `scm_t_bits' which identifies the new smob type. The four special functions described above are registered by calling one of `scm_set_smob_mark', `scm_set_smob_free', `scm_set_smob_print', or `scm_set_smob_equalp', as appropriate. Each function is intended to be used at most once per type, and the call should be placed immediately following the call to `scm_make_smob_type'. There can only be at most 256 different smob types in the system. Instead of registering a huge number of smob types (for example, one for each relevant C struct in your application), it is sometimes better to register just one and implement a second layer of type dispatching on top of it. This second layer might use the 16 extra bits to extend its type, for example. Here is how one might declare and register a new type representing eight-bit gray-scale images: #include 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_t_bits image_tag; void init_image_type (void) { image_tag = scm_make_smob_type ("image", sizeof (struct image)); scm_set_smob_mark (image_tag, mark_image); scm_set_smob_free (image_tag, free_image); scm_set_smob_print (image_tag, print_image); }  File: guile.info, Node: Creating Instances, Next: Type checking, Prev: Describing a New Type, Up: Defining New Types (Smobs) 4.4.2 Creating Instances ------------------------ Normally, smobs can have one _immediate_ word of data. This word stores either a pointer to an additional memory block that holds the real data, or it might hold the data itself when it fits. The word is large enough for a `SCM' value, a pointer to `void', or an integer that fits into a `size_t' or `ssize_t'. You can also create smobs that have two or three immediate words, and when these words suffice to store all data, it is more efficient to use these super-sized smobs instead of using a normal smob plus a memory block. *Note Double Smobs::, for their discussion. Guile provides functions for managing memory which are often helpful when implementing smobs. *Note Memory Blocks::. To retrieve the immediate word of a smob, you use the macro `SCM_SMOB_DATA'. It can be set with `SCM_SET_SMOB_DATA'. The 16 extra bits can be accessed with `SCM_SMOB_FLAGS' and `SCM_SET_SMOB_FLAGS'. The two macros `SCM_SMOB_DATA' and `SCM_SET_SMOB_DATA' treat the immediate word as if it were of type `scm_t_bits', which is an unsigned integer type large enough to hold a pointer to `void'. Thus you can use these macros to store arbitrary pointers in the smob word. When you want to store a `SCM' value directly in the immediate word of a smob, you should use the macros `SCM_SMOB_OBJECT' and `SCM_SET_SMOB_OBJECT' to access it. Creating a smob instance can be tricky when it consists of multiple steps that allocate resources and might fail. It is recommended that you go about creating a smob in the following way: * Allocate the memory block for holding the data with `scm_gc_malloc'. * Initialize it to a valid state without calling any functions that might cause a non-local exits. For example, initialize pointers to NULL. Also, do not store `SCM' values in it that must be protected. Initialize these fields with `SCM_BOOL_F'. A valid state is one that can be safely acted upon by the _mark_ and _free_ functions of your smob type. * Create the smob using `SCM_NEWSMOB', passing it the initialized memory block. (This step will always succeed.) * Complete the initialization of the memory block by, for example, allocating additional resources and making it point to them. This procedure ensures that the smob is in a valid state as soon as it exists, that all resources that are allocated for the smob are properly associated with it so that they can be properly freed, and that no `SCM' values that need to be protected are stored in it while the smob does not yet competely exist and thus can not protect them. Continuing the example from above, if the global variable `image_tag' contains a tag returned by `scm_make_smob_type', here is how we could construct a smob whose immediate word contains a pointer to a freshly allocated `struct image': SCM make_image (SCM name, SCM s_width, SCM s_height) { SCM smob; struct image *image; int width = scm_to_int (s_width); int height = scm_to_int (s_height); /* Step 1: Allocate the memory block. */ image = (struct image *) scm_gc_malloc (sizeof (struct image), "image"); /* Step 2: Initialize it with straight code. */ image->width = width; image->height = height; image->pixels = NULL; image->name = SCM_BOOL_F; image->update_func = SCM_BOOL_F; /* Step 3: Create the smob. */ SCM_NEWSMOB (smob, image_tag, image); /* Step 4: Finish the initialization. */ image->name = name; image->pixels = scm_gc_malloc (width * height, "image pixels"); return smob; } Let us look at what might happen when `make_image' is called. The conversions of S_WIDTH and S_HEIGHT to `int's might fail and signal an error, thus causing a non-local exit. This is not a problem since no resources have been allocated yet that would have to be freed. The allocation of IMAGE in step 1 might fail, but this is likewise no problem. Step 2 can not exit non-locally. At the end of it, the IMAGE struct is in a valid state for the `mark_image' and `free_image' functions (see below). Step 3 can not exit non-locally either. This is guaranteed by Guile. After it, SMOB contains a valid smob that is properly initialized and protected, and in turn can properly protect the Scheme values in its IMAGE struct. But before the smob is completely created, `SCM_NEWSMOB' might cause the garbage collector to run. During this garbage collection, the `SCM' values in the IMAGE struct would be invisible to Guile. It only gets to know about them via the `mark_image' function, but that function can not yet do its job since the smob has not been created yet. Thus, it is important to not store `SCM' values in the IMAGE struct until after the smob has been created. Step 4, finally, might fail and cause a non-local exit. In that case, the complete creation of the smob has not been successful, but it does nevertheless exist in a valid state. It will eventually be freed by the garbage collector, and all the resources that have been allocated for it will be correctly freed by `free_image'.  File: guile.info, Node: Type checking, Next: Garbage Collecting Smobs, Prev: Creating Instances, Up: Defining New Types (Smobs) 4.4.3 Type checking ------------------- Functions that operate on smobs should check that the passed `SCM' value indeed is a suitable smob before accessing its data. They can do this with `scm_assert_smob_type'. For example, here is a simple function that operates on an image smob, and checks the type of its argument. SCM clear_image (SCM image_smob) { int area; struct image *image; scm_assert_smob_type (image_tag, image_smob); image = (struct image *) SCM_SMOB_DATA (image_smob); 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); scm_remember_upto_here_1 (image_smob); return SCM_UNSPECIFIED; } See *note Remembering During Operations:: for an explanation of the call to `scm_remember_upto_here_1'.  File: guile.info, Node: Garbage Collecting Smobs, Next: Garbage Collecting Simple Smobs, Prev: Type checking, Up: Defining New Types (Smobs) 4.4.4 Garbage Collecting Smobs ------------------------------ Once a smob has been released to the tender mercies of the Scheme system, it must be prepared to survive garbage collection. Guile calls the _mark_ and _free_ functions of the smob to manage this. As described in more detail elsewhere (*note Conservative GC::), every object in the Scheme system has a "mark bit", which the garbage collector uses to tell live objects from dead ones. When collection starts, every object's mark bit is clear. The collector traces pointers through the heap, starting from objects known to be live, and sets the mark bit on each object it encounters. When it can find no more unmarked objects, the collector walks all objects, live and dead, frees those whose mark bits are still clear, and clears the mark bit on the others. The two main portions of the collection are called the "mark phase", during which the collector marks live objects, and the "sweep phase", during which the collector frees all unmarked objects. The mark bit of a smob lives in a special memory region. When the collector encounters a smob, it sets the smob's mark bit, and uses the smob's type tag to find the appropriate _mark_ function for that smob. It then calls this _mark_ function, passing it the smob as its only argument. The _mark_ function is responsible for marking any other Scheme objects the smob refers to. If it does not do so, the objects' mark bits will still be clear when the collector begins to sweep, and the collector will free them. If this occurs, it will probably break, or at least confuse, any code operating on the smob; the smob's `SCM' values will have become dangling references. To mark an arbitrary Scheme object, the _mark_ function calls `scm_gc_mark'. Thus, here is how we might write `mark_image': SCM mark_image (SCM image_smob) { /* Mark the image's name and update function. */ struct image *image = (struct image *) SCM_SMOB_DATA (image_smob); scm_gc_mark (image->name); scm_gc_mark (image->update_func); return SCM_BOOL_F; } Note that, even though the image's `update_func' could be an arbitrarily complex structure (representing a procedure and any values enclosed in its environment), `scm_gc_mark' will recurse as necessary to mark all its components. Because `scm_gc_mark' sets an object's mark bit before it recurses, it is not confused by circular structures. As an optimization, the collector will mark whatever value is returned by the _mark_ function; this helps limit depth of recursion during the mark phase. Thus, the code above should really be written as: SCM mark_image (SCM image_smob) { /* Mark the image's name and update function. */ struct image *image = (struct image *) SCM_SMOB_DATA (image_smob); scm_gc_mark (image->name); return image->update_func; } Finally, when the collector encounters an unmarked smob during the sweep phase, it uses the smob's tag to find the appropriate _free_ function for the smob. It then calls that function, passing it the smob as its only argument. The _free_ function must release any resources used by the smob. However, it must not free objects managed by the collector; the collector will take care of them. For historical reasons, the return type of the _free_ function should be `size_t', an unsigned integral type; the _free_ function should always return zero. Here is how we might write the `free_image' function for the image smob type: size_t free_image (SCM image_smob) { struct image *image = (struct image *) SCM_SMOB_DATA (image_smob); scm_gc_free (image->pixels, image->width * image->height, "image pixels"); scm_gc_free (image, sizeof (struct image), "image"); return 0; } During the sweep phase, the garbage collector will clear the mark bits on all live objects. The code which implements a smob need not do this itself. There is no way for smob code to be notified when collection is complete. It is usually a good idea to minimize the amount of processing done during garbage collection; keep the _mark_ and _free_ functions very simple. Since collections occur at unpredictable times, it is easy for any unusual activity to interfere with normal code.  File: guile.info, Node: Garbage Collecting Simple Smobs, Next: Remembering During Operations, Prev: Garbage Collecting Smobs, Up: Defining New Types (Smobs) 4.4.5 Garbage Collecting Simple Smobs ------------------------------------- It is often useful to define very simple smob types -- smobs which have no data to mark, other than the cell itself, or smobs whose immediate data word is simply an ordinary Scheme object, to be marked recursively. Guile provides some functions to handle these common cases; you can use this function as your smob type's _mark_ function, if your smob's structure is simple enough. If the smob refers to no other Scheme objects, then no action is necessary; the garbage collector has already marked the smob cell itself. In that case, you can use zero as your mark function. If the smob refers to exactly one other Scheme object via its first immediate word, you can use `scm_markcdr' as its mark function. Its definition is simply: SCM scm_markcdr (SCM obj) { return SCM_SMOB_OBJECT (obj); }  File: guile.info, Node: Remembering During Operations, Next: Double Smobs, Prev: Garbage Collecting Simple Smobs, Up: Defining New Types (Smobs) 4.4.6 Remembering During Operations ----------------------------------- It's important that a smob is visible to the garbage collector whenever its contents are being accessed. Otherwise it could be freed while code is still using it. For example, consider a procedure to convert image data to a list of pixel values. SCM image_to_list (SCM image_smob) { struct image *image; SCM lst; int i; scm_assert_smob_type (image_tag, image_smob); image = (struct image *) SCM_SMOB_DATA (image_smob); lst = SCM_EOL; for (i = image->width * image->height - 1; i >= 0; i--) lst = scm_cons (scm_from_char (image->pixels[i]), lst); scm_remember_upto_here_1 (image_smob); return lst; } In the loop, only the `image' pointer is used and the C compiler has no reason to keep the `image_smob' value anywhere. If `scm_cons' results in a garbage collection, `image_smob' might not be on the stack or anywhere else and could be freed, leaving the loop accessing freed data. The use of `scm_remember_upto_here_1' prevents this, by creating a reference to `image_smob' after all data accesses. There's no need to do the same for `lst', since that's the return value and the compiler will certainly keep it in a register or somewhere throughout the routine. The `clear_image' example previously shown (*note Type checking::) also used `scm_remember_upto_here_1' for this reason. It's only in quite rare circumstances that a missing `scm_remember_upto_here_1' will bite, but when it happens the consequences are serious. Fortunately the rule is simple: whenever calling a Guile library function or doing something that might, ensure that the `SCM' of a smob is referenced past all accesses to its insides. Do this by adding an `scm_remember_upto_here_1' if there are no other references. In a multi-threaded program, the rule is the same. As far as a given thread is concerned, a garbage collection still only occurs within a Guile library function, not at an arbitrary time. (Guile waits for all threads to reach one of its library functions, and holds them there while the collector runs.)  File: guile.info, Node: Double Smobs, Next: The Complete Example, Prev: Remembering During Operations, Up: Defining New Types (Smobs) 4.4.7 Double Smobs ------------------ Smobs are called smob because they are small: they normally have only room for one `void*' or `SCM' value plus 16 bits. The reason for this is that smobs are directly implemented by using the low-level, two-word cells of Guile that are also used to implement pairs, for example. (*note Data Representation:: for the details.) One word of the two-word cells is used for `SCM_SMOB_DATA' (or `SCM_SMOB_OBJECT'), the other contains the 16-bit type tag and the 16 extra bits. In addition to the fundamental two-word cells, Guile also has four-word cells, which are appropriately called "double cells". You can use them for "double smobs" and get two more immediate words of type `scm_t_bits'. A double smob is created with `SCM_NEWSMOB2' or `SCM_NEWSMOB3' instead of `SCM_NEWSMOB'. Its immediate words can be retrieved as `scm_t_bits' with `SCM_SMOB_DATA_2' and `SCM_SMOB_DATA_3' in addition to `SCM_SMOB_DATA'. Unsurprisingly, the words can be set to `scm_t_bits' values with `SCM_SET_SMOB_DATA_2' and `SCM_SET_SMOB_DATA_3'. Of course there are also `SCM_SMOB_OBJECT_2', `SCM_SMOB_OBJECT_3', `SCM_SET_SMOB_OBJECT_2', and `SCM_SET_SMOB_OBJECT_3'.  File: guile.info, Node: The Complete Example, Prev: Double Smobs, Up: Defining New Types (Smobs) 4.4.8 The Complete Example -------------------------- Here is the complete text of the implementation of the image datatype, as presented in the sections above. We also provide a definition for the smob's _print_ function, and make some objects and functions static, to clarify exactly what the surrounding code is using. As mentioned above, you can find this code in the Guile distribution, in `doc/example-smob'. That directory includes a makefile and a suitable `main' function, so you can build a complete interactive Guile shell, extended with the datatypes described here.) /* file "image-type.c" */ #include #include static scm_t_bits image_tag; 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 make_image (SCM name, SCM s_width, SCM s_height) { SCM smob; struct image *image; int width = scm_to_int (s_width); int height = scm_to_int (s_height); /* Step 1: Allocate the memory block. */ image = (struct image *) scm_gc_malloc (sizeof (struct image), "image"); /* Step 2: Initialize it with straight code. */ image->width = width; image->height = height; image->pixels = NULL; image->name = SCM_BOOL_F; image->update_func = SCM_BOOL_F; /* Step 3: Create the smob. */ SCM_NEWSMOB (smob, image_tag, image); /* Step 4: Finish the initialization. */ image->name = name; image->pixels = scm_gc_malloc (width * height, "image pixels"); return smob; } SCM clear_image (SCM image_smob) { int area; struct image *image; scm_assert_smob_type (image_tag, image_smob); image = (struct image *) SCM_SMOB_DATA (image_smob); 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); scm_remember_upto_here_1 (image_smob); return SCM_UNSPECIFIED; } static SCM mark_image (SCM image_smob) { /* Mark the image's name and update function. */ struct image *image = (struct image *) SCM_SMOB_DATA (image_smob); scm_gc_mark (image->name); return image->update_func; } static size_t free_image (SCM image_smob) { struct image *image = (struct image *) SCM_SMOB_DATA (image_smob); scm_gc_free (image->pixels, image->width * image->height, "image pixels"); scm_gc_free (image, sizeof (struct image), "image"); return 0; } static int print_image (SCM image_smob, SCM port, scm_print_state *pstate) { struct image *image = (struct image *) SCM_SMOB_DATA (image_smob); scm_puts ("#name, port); scm_puts (">", port); /* non-zero means success */ return 1; } void init_image_type (void) { image_tag = scm_make_smob_type ("image", sizeof (struct image)); scm_set_smob_mark (image_tag, mark_image); scm_set_smob_free (image_tag, free_image); scm_set_smob_print (image_tag, print_image); scm_c_define_gsubr ("clear-image", 1, 0, 0, clear_image); scm_c_define_gsubr ("make-image", 3, 0, 0, make_image); } Here is a sample build and interaction with the code from the `example-smob' directory, on the author's machine: zwingli:example-smob$ make CC=gcc gcc `guile-config compile` -c image-type.c -o image-type.o gcc `guile-config compile` -c myguile.c -o myguile.o gcc image-type.o myguile.o `guile-config link` -o myguile zwingli:example-smob$ ./myguile guile> make-image # guile> (define i (make-image "Whistler's Mother" 100 100)) guile> i # guile> (clear-image i) guile> (clear-image 4) ERROR: In procedure clear-image in expression (clear-image 4): ERROR: Wrong type (expecting image): 4 ABORT: (wrong-type-arg) Type "(backtrace)" to get more information. guile>  File: guile.info, Node: Function Snarfing, Next: Programming Overview, Prev: Defining New Types (Smobs), Up: Programming in C 4.5 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 initialiation 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 SCM_DEFINE (clear_image, "clear-image", 1, 0, 0, (SCM image_smob), "Clear the image.") { /* C code to clear the image in `image_smob'... */ } 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_smob'), 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". For historical reasons, the `SCM_DEFINE' macro also defines a static array of characters named `s_clear_image', initialized to the string "clear-image". You shouldn't use this array, but you might need to be aware that it exists. 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, Prev: Function Snarfing, Up: Programming in C 4.6 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 4.6.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 Smobs:: 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 4.6.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 Smobs, Prev: Dia Objective, Up: Extending Dia 4.6.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 "SMOB" 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 "SMOBs" and "primitives" to the Scheme world. The following subsections expand on these four points in turn.  File: guile.info, Node: Dia Smobs, Next: Dia Primitives, Prev: Dia Steps, Up: Extending Dia 4.6.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 the idea of SMOBs comes in, and with it 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 SMOB. The SMOB is what is passed into and out of Scheme code, and the Scheme-specific C structure inside the SMOB 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 SMOB. 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 SMOB 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 SMOB type. * Whenever you need to represent a C shape onto the Scheme level, create a SMOB instance for it, and pass that. * In primitive code that receives a shape SMOB 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 SMOB 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 SMOB value, it calls the "SMOB free" function that was specified when defining the shape SMOB 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 SMOB types, see *note Defining New Types (Smobs)::.  File: guile.info, Node: Dia Primitives, Next: Dia Hook, Prev: Dia Smobs, Up: Extending Dia 4.6.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: #define FUNC_NAME "square?" static SCM square_p (SCM shape) { struct dia_guile_shape * guile_shape; /* Check that arg is really a shape SMOB. */ SCM_VALIDATE_SHAPE (SCM_ARG1, shape); /* Access Scheme-specific shape structure. */ guile_shape = SCM_SMOB_DATA (shape); /* 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)); } #undef FUNC_NAME Notice how easy it is to chain through from the `SCM shape' parameter that `square_p' receives -- which is a SMOB -- to the Scheme-specific structure inside the SMOB, and thence to the underlying C structure for the shape. In this code, `SCM_SMOB_DATA' and `scm_from_bool' are from the standard Guile API. `SCM_VALIDATE_SHAPE' is a macro that you should define as part of your SMOB definition: it checks that the passed parameter is of the expected type. 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 4.6.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 ` :', 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 4.6.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 SMOB 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 SMOBs and have written primitive code as described in the preceding subsections, you also need to insert calls to declare your new SMOBs 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 4.6.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 SMOBs 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 SMOB 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 SMOBs 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 SMOB 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 4.6.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 4.6.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 4.6.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 4.6.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 4.6.4.2 Functional and Performance Constraints ..............................................  File: guile.info, Node: Style Choices, Next: Program Control, Prev: Basic Constraints, Up: Programming Options 4.6.4.3 Your Preferred Programming Style ........................................  File: guile.info, Node: Program Control, Prev: Style Choices, Up: Programming Options 4.6.4.4 What Controls Program Execution? ........................................  File: guile.info, Node: User Programming, Prev: Programming Options, Up: Programming Overview 4.6.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: API Reference, Next: Guile Modules, Prev: Programming in C, Up: Top 5 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. * The SCM Type:: The fundamental data type for C code. * Initialization:: Initializing Guile. * Snarfing Macros:: Macros for snarfing initialization actions. * Simple Data Types:: Numbers, strings, booleans and so on. * Compound Data Types:: Data types for holding other data. * Smobs:: Defining new data types in C. * Procedures and Macros:: Procedures and macros. * 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. * Read/Load/Eval:: Reading and evaluating Scheme code. * Memory Management:: Memory management and garbage collection. * Objects:: Low level object orientation support. * Modules:: Designing reusable code libraries. * Scheduling:: Threads, mutexes, asyncs and dynamic roots. * Options and Config:: Configuration, features and runtime options. * Translation:: Support for translating other languages. * Internationalization:: Support for gettext, etc. * Debugging:: Debugging infrastructure and Scheme interface. * GH:: The deprecated GH interface.  File: guile.info, Node: API Overview, Next: The SCM Type, Up: API Reference 5.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 bot for the return value and for the arguments.  File: guile.info, Node: The SCM Type, Next: Initialization, Prev: API Overview, Up: API Reference 5.2 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 5.3 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: Simple Data Types, Prev: Initialization, Up: API Reference 5.4 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: Simple Data Types, Next: Compound Data Types, Prev: Snarfing Macros, Up: API Reference 5.5 Simple Generic Data Types ============================= This chapter describes those of Guile's simple data types which are primarily used for their role as items of generic data. By "simple" we mean data types that are not primarily used as containers to hold other data -- i.e. pairs, lists, vectors and so on. For the documentation of such "compound" data types, see *note Compound Data Types::. * Menu: * Booleans:: True/false values. * Numbers:: Numerical data types. * Characters:: Single characters. * Character Sets:: Sets of characters. * Strings:: Sequences of characters. * Regular Expressions:: Pattern matching and substitution. * Symbols:: Symbols. * Keywords:: Self-quoting, customizable display keywords. * Other Types:: "Functionality-centric" data types.  File: guile.info, Node: Booleans, Next: Numbers, Up: Simple Data Types 5.5.1 Booleans -------------- The two boolean values are `#t' for true and `#f' for false. 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 if cond case::), 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: Simple Data Types 5.5.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 Numbers: (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. * Primitive Numerics:: Primitive numeric functions. * Bitwise Operations:: Logical AND, OR, NOT, and so on. * Random:: Random number generation.  File: guile.info, Node: Numerical Tower, Next: Integers, Up: Numbers 5.5.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 5.5.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. The infinities `+inf.0' and `-inf.0' are considered to be inexact integers. They are explained in detail in the next section, together with reals and rationals. 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 `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 `#f'. (integer? 487) => #t (integer? 3.0) => #t (integer? -3.4) => #f (integer? +inf.0) => #t -- C Function: int scm_is_integer (SCM x) This is equivalent to `scm_is_true (scm_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_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) 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_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) 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 Initializing Integers: (gmp)Initializing Integers, for details. -- C Function: SCM scm_from_mpz (mpz_t val) Return the `SCM' value that represents VAL.  File: guile.info, Node: Reals and Rationals, Next: Complex Numbers, Prev: Integers, Up: Numbers 5.5.2.3 Real and Rational Numbers ................................. Mathematically, the real numbers are the set of numbers that describe all possible points along a continuous, infinite, one-dimensional line. The rational numbers are the set of all numbers that can be written as fractions P/Q, where P and Q are integers. All rational numbers are also real, but there are real numbers that are not rational, for example the square root of 2, and pi. Guile can represent both exact and inexact rational numbers, but it can not represent irrational numbers. Exact rationals are represented by storing the numerator and denominator as two exact integers. Inexact rationals are stored as floating point numbers using the C type `double'. Exact rationals are written as a fraction of integers. There must be no whitespace around the slash: 1/2 -22/7 Even though the actual encoding of inexact rationals is in binary, it may be helpful to think of it as a decimal number with a limited number of significant figures and a decimal point somewhere, since this corresponds to the standard notation for non-whole numbers. For example: 0.34 -0.00000142857931198 -5648394822220000000000.0 4.0 The limited precision of Guile's encoding means that any "real" number in Guile can be written in a rational form, by multiplying and then dividing by sufficient powers of 10 (or in fact, 2). For example, `-0.00000142857931198' is the same as -142857931198 divided by 100000000000000000. In Guile's current incarnation, therefore, the `rational?' and `real?' predicates are equivalent. Dividing by an exact zero leads to a error message, as one might expect. However, dividing by an inexact zero does not produce an error. Instead, the result of the division is either plus or minus infinity, depending on the sign of the divided number. The infinities are written `+inf.0' and `-inf.0', respectivly. This syntax is also recognized by `read' as an extension to the usual Scheme syntax. Dividing zero by zero yields something that is not a number at all: `+nan.0'. This is the special `not a number' value. On platforms that follow IEEE 754 for their floating point arithmetic, the `+inf.0', `-inf.0', and `+nan.0' values are implemented using the corresponding IEEE 754 values. They behave in arithmetic operations like IEEE 754 describes it, i.e., `(= +nan.0 +nan.0)' => `#f'. The infinities are inexact integers and are considered to be both even and odd. While `+nan.0' is not `=' to itself, it is `eqv?' to itself. To test for the special values, use the functions `inf?' and `nan?'. -- Scheme Procedure: real? obj -- C Function: scm_real_p (obj) Return `#t' if OBJ is a real number, else `#f'. Note that the sets of integer and rational values form subsets of the set of real numbers, so the predicate will also be fulfilled if OBJ is an integer number or a rational number. -- Scheme Procedure: rational? x -- C Function: scm_rational_p (x) Return `#t' if X is a rational number, `#f' otherwise. Note that the set of integer values forms a subset of the set of rational numbers, i. e. the predicate will also be fulfilled if X is an integer number. Since Guile can not represent irrational numbers, every number satisfying `real?' also satisfies `rational?' in Guile. -- Scheme Procedure: rationalize x eps -- C Function: scm_rationalize (x, eps) Returns the _simplest_ rational number differing from X by no more than EPS. As required by R5RS, `rationalize' only returns an exact result when both its arguments are exact. Thus, you might need to use `inexact->exact' on the arguments. (rationalize (inexact->exact 1.2) 1/100) => 6/5 -- Scheme Procedure: inf? x -- C Function: scm_inf_p (x) Return `#t' if X is either `+inf.0' or `-inf.0', `#f' otherwise. -- Scheme Procedure: nan? x -- C Function: scm_nan_p (x) Return `#t' if X is `+nan.0', `#f' otherwise. -- Scheme Procedure: nan -- C Function: scm_nan () Return NaN. -- Scheme Procedure: inf -- C Function: scm_inf () Return Inf. -- Scheme Procedure: numerator x -- C Function: scm_numerator (x) Return the numerator of the rational number X. -- Scheme Procedure: denominator x -- C Function: scm_denominator (x) Return the denominator of the rational number X. -- C Function: int scm_is_real (SCM val) -- C Function: int scm_is_rational (SCM val) Equivalent to `scm_is_true (scm_real_p (val))' and `scm_is_true (scm_rational_p (val))', respectively. -- C Function: double scm_to_double (SCM val) Returns the number closest to VAL that is representable as a `double'. Returns infinity for a VAL that is too large in magnitude. The argument VAL must be a real number. -- C Function: SCM scm_from_double (double val) Return the `SCM' value that representats VAL. The returned value is inexact according to the predicate `inexact?', but it will be exactly equal to VAL.  File: guile.info, Node: Complex Numbers, Next: Exactness, Prev: Reals and Rationals, Up: Numbers 5.5.2.4 Complex Numbers ....................... Complex numbers are the set of numbers that describe all possible points in a two-dimensional space. The two coordinates of a particular point in this space are known as the "real" and "imaginary" parts of the complex number that describes that point. In Guile, complex numbers are written in rectangular form as the sum of their real and imaginary parts, using the symbol `i' to indicate the imaginary part. 3+4i => 3.0+4.0i (* 3-8i 2.3+0.3i) => 9.3-17.5i Polar form can also be used, with an `@' between magnitude and angle, 1@3.141592 => -1.0 (approx) -1@1.57079 => 0.0-1.0i (approx) Guile represents a complex number with a non-zero imaginary part as a pair of inexact rationals, so the real and imaginary parts of a complex number have the same properties of inexactness and limited precision as single inexact rational numbers. Guile can not represent exact complex numbers with non-zero imaginary parts. -- Scheme Procedure: complex? z -- C Function: scm_complex_p (z) Return `#t' if X is a complex number, `#f' otherwise. Note that the sets of real, rational and integer values form subsets of the set of complex numbers, i. e. the predicate will also be fulfilled if X is a real, rational or integer number. -- C Function: int scm_is_complex (SCM val) Equivalent to `scm_is_true (scm_complex_p (val))'.  File: guile.info, Node: Exactness, Next: Number Syntax, Prev: Complex Numbers, Up: Numbers 5.5.2.5 Exact and Inexact Numbers ................................. R5RS requires that a calculation involving inexact numbers always produces an inexact result. To meet this requirement, Guile distinguishes between an exact integer value such as `5' and the corresponding inexact real value which, to the limited precision available, has no fractional part, and is printed as `5.0'. Guile will only convert the latter value to the former when forced to do so by an invocation of the `inexact->exact' procedure. -- Scheme Procedure: exact? z -- C Function: scm_exact_p (z) Return `#t' if the number Z is exact, `#f' otherwise. (exact? 2) => #t (exact? 0.5) => #f (exact? (/ 2)) => #t -- Scheme Procedure: inexact? z -- C Function: scm_inexact_p (z) Return `#t' if the number Z is inexact, `#f' else. -- Scheme Procedure: inexact->exact z -- C Function: scm_inexact_to_exact (z) Return an exact number that is numerically closest to Z, when there is one. For inexact rationals, Guile returns the exact rational that is numerically equal to the inexact rational. Inexact complex numbers with a non-zero imaginary part can not be made exact. (inexact->exact 0.5) => 1/2 The following happens because 12/10 is not exactly representable as a `double' (on most platforms). However, when reading a decimal number that has been marked exact with the "#e" prefix, Guile is able to represent it correctly. (inexact->exact 1.2) => 5404319552844595/4503599627370496 #e1.2 => 6/5 -- Scheme Procedure: exact->inexact z -- C Function: scm_exact_to_inexact (z) Convert the number Z to its inexact representation.  File: guile.info, Node: Number Syntax, Next: Integer Operations, Prev: Exactness, Up: Numbers 5.5.2.6 Read Syntax for Numerical Data ...................................... The read syntax for integers is a string of digits, optionally preceded by a minus or plus character, a code indicating the base in which the integer is encoded, and a code indicating whether the number is exact or inexact. The supported base codes are: `#b' `#B' the integer is written in binary (base 2) `#o' `#O' the integer is written in octal (base 8) `#d' `#D' the integer is written in decimal (base 10) `#x' `#X' the integer is written in hexadecimal (base 16) If the base code is omitted, the integer is assumed to be decimal. The following examples show how these base codes are used. -13 => -13 #d-13 => -13 #x-13 => -19 #b+1101 => 13 #o377 => 255 The codes for indicating exactness (which can, incidentally, be applied to all numerical values) are: `#e' `#E' the number is exact `#i' `#I' the number is inexact. If the exactness indicator is omitted, the number is exact unless it contains a radix point. Since Guile can not represent exact complex numbers, an error is signalled when asking for them. (exact? 1.2) => #f (exact? #e1.2) => #t (exact? #e+1i) ERROR: Wrong type argument Guile also understands the syntax `+inf.0' and `-inf.0' for plus and minus infinity, respectively. The value must be written exactly as shown, that is, they always must have a sign and exactly one zero digit after the decimal point. It also understands `+nan.0' and `-nan.0' for the special `not-a-number' value. The sign is ignored for `not-a-number' and the value is always printed as `+nan.0'.  File: guile.info, Node: Integer Operations, Next: Comparison, Prev: Number Syntax, Up: Numbers 5.5.2.7 Operations on Integer Values .................................... -- Scheme Procedure: odd? n -- C Function: scm_odd_p (n) Return `#t' if N is an odd number, `#f' otherwise. -- Scheme Procedure: even? n -- C Function: scm_even_p (n) Return `#t' if N is an even number, `#f' otherwise. -- Scheme Procedure: quotient n d -- Scheme Procedure: remainder n d -- C Function: scm_quotient (n, d) -- C Function: scm_remainder (n, d) Return the quotient or remainder from N divided by D. The quotient is rounded towards zero, and the remainder will have the same sign as N. In all cases quotient and remainder satisfy N = Q*D + R. (remainder 13 4) => 1 (remainder -13 4) => -1 -- Scheme Procedure: modulo n d -- C Function: scm_modulo (n, d) Return the remainder from N divided by D, with the same sign as D. (modulo 13 4) => 1 (modulo -13 4) => 3 (modulo 13 -4) => -3 (modulo -13 -4) => -1 -- Scheme Procedure: gcd x... -- C Function: scm_gcd (x, y) Return the greatest common divisor of all arguments. If called without arguments, 0 is returned. The C function `scm_gcd' always takes two arguments, while the Scheme function can take an arbitrary number. -- Scheme Procedure: lcm x... -- C Function: scm_lcm (x, y) Return the least common multiple of the arguments. If called without arguments, 1 is returned. The C function `scm_lcm' always takes two arguments, while the Scheme function can take an arbitrary number. -- Scheme Procedure: modulo-expt n k m -- C Function: scm_modulo_expt (n, k, m) Return N raised to the integer exponent K, modulo M. (modulo-expt 2 3 5) => 3  File: guile.info, Node: Comparison, Next: Conversion, Prev: Integer Operations, Up: Numbers 5.5.2.8 Comparison Predicates ............................. The C comparison functions below always takes two arguments, while the Scheme functions can take an arbitrary number. Also keep in mind that the C functions return one of the Scheme boolean values `SCM_BOOL_T' or `SCM_BOOL_F' which are both true as far as C is concerned. Thus, always write `scm_is_true (scm_num_eq_p (x, y))' when testing the two Scheme numbers `x' and `y' for equality, for example. -- Scheme Procedure: = -- C Function: scm_num_eq_p (x, y) Return `#t' if all parameters are numerically equal. -- Scheme Procedure: < -- C Function: scm_less_p (x, y) Return `#t' if the list of parameters is monotonically increasing. -- Scheme Procedure: > -- C Function: scm_gr_p (x, y) Return `#t' if the list of parameters is monotonically decreasing. -- Scheme Procedure: <= -- C Function: scm_leq_p (x, y) Return `#t' if the list of parameters is monotonically non-decreasing. -- Scheme Procedure: >= -- C Function: scm_geq_p (x, y) Return `#t' if the list of parameters is monotonically non-increasing. -- Scheme Procedure: zero? z -- C Function: scm_zero_p (z) Return `#t' if Z is an exact or inexact number equal to zero. -- Scheme Procedure: positive? x -- C Function: scm_positive_p (x) Return `#t' if X is an exact or inexact number greater than zero. -- Scheme Procedure: negative? x -- C Function: scm_negative_p (x) Return `#t' if X is an exact or inexact number less than zero.  File: guile.info, Node: Conversion, Next: Complex, Prev: Comparison, Up: Numbers 5.5.2.9 Converting Numbers To and From Strings .............................................. -- Scheme Procedure: number->string n [radix] -- C Function: scm_number_to_string (n, radix) Return a string holding the external representation of the number N in the given RADIX. If N is inexact, a radix of 10 will be used. -- Scheme Procedure: string->number string [radix] -- C Function: scm_string_to_number (string, radix) Return a number of the maximally precise representation expressed by the given STRING. RADIX must be an exact integer, either 2, 8, 10, or 16. If supplied, RADIX is a default radix that may be overridden by an explicit radix prefix in STRING (e.g. "#o177"). If RADIX is not supplied, then the default radix is 10. If string is not a syntactically valid notation for a number, then `string->number' returns `#f'. -- C Function: SCM scm_c_locale_stringn_to_number (const char *string, size_t len, unsigned radix) As per `string->number' above, but taking a C string, as pointer and length. The string characters should be in the current locale encoding (`locale' in the name refers only to that, there's no locale-dependent parsing).  File: guile.info, Node: Complex, Next: Arithmetic, Prev: Conversion, Up: Numbers 5.5.2.10 Complex Number Operations .................................. -- Scheme Procedure: make-rectangular real imaginary -- C Function: scm_make_rectangular (real, imaginary) Return a complex number constructed of the given REAL and IMAGINARY parts. -- Scheme Procedure: make-polar x y -- C Function: scm_make_polar (x, y) Return the complex number X * e^(i * Y). -- Scheme Procedure: real-part z -- C Function: scm_real_part (z) Return the real part of the number Z. -- Scheme Procedure: imag-part z -- C Function: scm_imag_part (z) Return the imaginary part of the number Z. -- Scheme Procedure: magnitude z -- C Function: scm_magnitude (z) Return the magnitude of the number Z. This is the same as `abs' for real arguments, but also allows complex numbers. -- Scheme Procedure: angle z -- C Function: scm_angle (z) Return the angle of the complex number Z. -- C Function: SCM scm_c_make_rectangular (double re, double im) -- C Function: SCM scm_c_make_polar (double x, double y) Like `scm_make_rectangular' or `scm_make_polar', respectively, but these functions take `double's as their arguments. -- C Function: double scm_c_real_part (z) -- C Function: double scm_c_imag_part (z) Returns the real or imaginary part of Z as a `double'. -- C Function: double scm_c_magnitude (z) -- C Function: double scm_c_angle (z) Returns the magnitude or angle of Z as a `double'.