4.11.1 Overview

The module system lets the user divide large Prolog programs into modules, or rather smaller sub-programs, and define the interfaces between those modules. Each module has its own name space; that is, a predicate defined in one module is distinct from any predicates with the same name and arity that may be defined in other modules. The module system encourages a group of programmers to define the dependence each has on others’ work before any code is written, and subsequently allows all to work on their own parts independently. It also helps to make library predicates behave as extensions of the existing set of built-in predicates.

The SICStus Prolog library uses the module system and can therefore serve as an extended example of the concepts presented in the following text. The design of the module system is such that loading library files and calling library predicates can be performed without knowledge of the module system.

Some points to note about the module system are that:

• It is based on predicate modularity rather than on data modularity; that is, atoms and functors are global.
• It is flat rather than hierarchical; any module may refer to any other module by its name—there is no need to specify a path of modules.
• It is not strict; modularity rules can be explicitly overridden. This is primarily for flexibility during debugging.
• It is efficient; calls to predicates across module boundaries incur little or no overhead.