 
 
7.1  Basics
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 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
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.
- 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 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.
 
