Next: Getting Started
Up: Module System
Previous: Module System
Index
Subsections
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.
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 declared7.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.
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.
Next: Getting Started
Up: Module System
Previous: Module System
Index
Warwick Harvey
2004-08-07