31.1 Rationale

When programs become large, naming conflicts can occur when a function or global variable defined in one file has the same name as a function or global variable in another file. Even just a similarity between function names can cause hard-to-find bugs, since a programmer might type the wrong function name.

The approach used to tackle this problem is called information encapsulation, which consists of packaging functional units into a given name space that is clearly separated from other name spaces. The language features that allow this are usually called the module system because programs are broken up into modules that are compiled and/or loaded separately, and the loading process entails systematic and well-defined operations.

Older languages, like C, have limited support for name space manipulation and protection. In C a variable or function is public by default, and can be made local to the module where it is defined with the static keyword, but you cannot reference these public variables and functions using different names.

More advanced module systems have become a common feature in recently designed languages: ML, Python, Perl, and Modula 3 all allow the renaming of objects from a foreign module, so they will not clutter the global name space. In addition to this ability, Guile offers lower-level access to the module system mechanisms through variables as first class objects.

31.2 Scheme and modules

Scheme, as defined in R5RS, does not have a module system at all.

Aubrey Jaffer, mostly to support his portable Scheme library SLIB, implemented a provide/require mechanism for many Scheme implementations. Library files in SLIB provide a feature, and when user programs require that feature, the library file is loaded in.

For example, the file random.scm in the SLIB package contains the line

     (provide 'random)

so to use its procedures, a user would type

     (require 'random)

and they would magically become available, but still have the same names! So this method is nice, but not as good as a full-featured module system.

31.3 Brief history of Guile's module system

In 1996 Tom Lord implemented a full-featured module system for Guile which allows loading Scheme source files into a private name space. This system has been available since Guile version 1.4.

For Guile version 1.4.2 and later, the system has been improved to have better integration from C code, more fine-grained user control over interfaces, and documentation.

Although it is anticipated that the module system implementation will change in the future, the Scheme programming interface described in this manual should be considered stable. The C programming interface is considered relatively stable, although at the time of this writing, there is still some flux.