7.1.1 Purpose of Modules
The purpose of the module system is to provide a way to package
a piece of code in such a way that
internals are hidden;
- it has a clearly defined interface;
- naming conflicts are avoided.
In particular, this helps with
Structuring of large applications:
Modules should be used to break application programs into
natural components and to define the interfaces between them.
- Provision of libraries:
All ECLiPSe libraries are modules. Their interfaces are
defined in terms of what the module makes visible to the world.
- Different implementations of the same predicate:
In constraint programming it is quite common to have different
implementations of a constraint, which all have the same declarative
meaning but different operational behaviour (e.g., different amount of
propagation, using different algorithms, exhibiting different
performance characteristics). The module system supports that by
allowing users to specify easily which version(s) of a predicate should
be used in a particular context.
7.1.2 What is under Visibility Control?
The ECLiPSe module system governs the visibility of the following
Predicates can always be used in the module where they are defined
and optionally in other modules when they are made available.
- Structure names
Structure declarations can be valid only locally within a module, or
shared between several modules.
- Syntax settings
These include operator declarations (see
syntax options and
This means in particular that different modules can use different
language dialects (e.g., ECLiPSe vs. ISO-Prolog).
- Container names
These include the names of record keys, non-logical variables and
They are always local to the module where they are declared.
- Initialization and finalization goals
Modules can have initialization and finalization goals attached,
see section 7.4.3.
Note that every definition (predicate, structure etc.) is in some module,
there is no space outside the modules. When you don’t explicitly
specify a module, you inherit the module from the context in which
you do an operation. When you are using an interactive ECLiPSe
toplevel, a prompt will tell you in which module your input is
read and interpreted.
7.1.3 What Modules are There?
The module system is flat, i.e., no module is part of another module,
and module names must be unique. There are
a few basic modules that are part of the ECLiPSe
runtime system and are always there. The most important one is
called eclipse_language and is by default imported
into all other modules.
- the library modules: every library consists of at least one
module. By convention, that module name is the library name
and same as the base part of the library file name.
- the application-defined modules: these are created by the
- in an interactive ECLiPSe toplevel there is one module
in which queries entered by the user are read and executed.
That module name is displayed in a prompt.