Warning: This is the manual of the legacy Guile 2.2 series. You may want to read the manual of the current stable series instead.
Next: Using Guile Modules, Up: Modules [Contents][Index]
A Guile module can be thought of as a collection of named procedures, variables and macros. More precisely, it is a set of bindings of symbols (names) to Scheme objects.
Within a module, all bindings are visible. Certain bindings can be declared public, in which case they are added to the module’s so-called export list; this set of public bindings is called the module’s public interface (see Creating Guile Modules).
A client module uses a providing module’s bindings by either accessing the providing module’s public interface, or by building a custom interface (and then accessing that). In a custom interface, the client module can select which bindings to access and can also algorithmically rename bindings. In contrast, when using the providing module’s public interface, the entire export list is available without renaming (see Using Guile Modules).
All Guile modules have a unique module name, for example
(ice-9 popen) or (srfi srfi-11). Module names are lists
of one or more symbols.
When Guile goes to use an interface from a module, for example
(ice-9 popen), Guile first looks to see if it has loaded
(ice-9 popen) for any reason. If the module has not been loaded
yet, Guile searches a load path for a file that might define it,
and loads that file.
The following subsections go into more detail on using, creating, installing, and otherwise manipulating modules and the module system.