Basics

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 to specify easily which version(s) of a predicate should be used in a particular context.

What is under Visibility Control?

The ECLiPSe 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 local to a module or shared between several modules.

Syntax settings

These include operator declarations op/3, syntax options and character classes. 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, nonlogical variables and references. They are always local to the module where they are declared^7.1.

Initialization goals

These are goals that are executed when the module is loaded or imported.

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.

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 filename.
• the application-defined modules: these are created by the application programmer.
• 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.