next up previous contents index
Next: The Dynamic Loader and Up: System Description Previous: The System and its   Contents   Index

The Module system of XSB

XSB has been designed as a module-oriented Prolog system. Modules provide a small step towards logic programming ``in the large'' that facilitates large programs or projects to be put together from components which can be developed, compiled and tested separately. Also module systems enforce the principle of information hiding and can provide a basis for data abstraction.

The module system of XSB, unlike the module systems of most other Prolog systems is atom-based. Briefly, the main difference between atom-based module systems and predicate-based ones is that in an atom-based module system any symbol in a module can be imported, exported or be a local symbol as opposed to the predicate-based ones where this can be done only for predicate symbols 3.1.

Usually the following three files are associated with a particular module:

The header file is normally used to contain declarations and directives while the source file usually contains the actual definitions of the predicates defined in that module. The module hierarchy of XSB is therefore flat -- nested modules are not possible.

In order for a file to be a module, it should contain one or more export declarations, which specify that a set of symbols appearing in that module is visible and therefore can be used by any other module. A module can also contain local declarations, which specify that a set of symbols are visible by this module only, and therefore cannot be accessed by any other module. Any file (either module or not) may also contain import declarations, which allow symbols defined in and exported by other modules to be used in the current module. We note that only exported symbols can be imported; for example importing a local symbol will cause an environment conflict error.

Export, local, and import declarations can appear anywhere in the source or header files and have the following forms:

:- export $sym_1$, ..., $sym_l$.

:- local $sym_1$, ..., $sym_m$.

:- import $sym_1$, ..., $sym_n$ from $module$.

where $sym_i$ has the form $functor/arity$.

If the user does not want to use modules, he can simply bypass the module system by not supplying any export declarations. Such exportless files (non-modules) will be loaded into the module usermod, which is the working module of the XSB interpreter.

Currently the module name is stored in its byte code file, which means that if the byte code file is renamed, the module name is not altered, and hence may cause confusion to the user and/or the system. So, it is advisable that the user not rename byte code files generated for modules by the XSB compiler. However, byte code files generated for non-modules can be safely renamed. We will try to fix the problem described above in future releases.

In order to understand the semantics of modules, the user should keep in mind that in a module oriented system, the name of each symbol is identified as if it were prefixed with its module name, hence two symbols of the same $functor/arity$ but different module prefixes are distinct symbols. Currently the following set of rules is used to determine the module prefix of a symbol:

The following facts about the module system of XSB may not be immediately obvious:

next up previous contents index
Next: The Dynamic Loader and Up: System Description Previous: The System and its   Contents   Index
Baoqiu Cui