8.1  Basics

• Purpose of Modules
• What is under Visibility Control?
• What Modules are There?

8.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 ECLⁱPS^e 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.

8.1.2  What is under Visibility Control?

The ECLⁱPS^e module system governs the visibility of the following entities:

Predicate names

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 op/3), syntax options and character classes. This means in particular that different modules can use different language dialects (e.g., ECLⁱPS^e vs. ISO-Prolog).

Container names

These include the names of record keys, non-logical variables and references. 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 8.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 ECLⁱPS^e toplevel, a prompt will tell you in which module your input is read and interpreted.

8.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 ECLⁱPS^e 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 application programmer.
• in an interactive ECLⁱPS^e toplevel there is one module in which queries entered by the user are read and executed. That module name is displayed in a prompt.