Module System

The ECLiPSe module system has been designed to meet the following criteria:

1. Be a structuring tool allowing to develop and maintain large applications.  

2. Avoid name clashes by having a separate name space for each module.  

3. Support privacy by allowing restrictions on the access to certain information of a module.  

4. Be incremental by giving as much freedom as possible in the order in which the predicate are defined and re-defined and the visibility declared and changed and by allowing the changes to be done dynamically.

5. Be transparent to non-modular applications. A Prolog program written in a non-modular system should run without changes when put into a unique module.  

These requirements make it clear that the main function of the module system must be to regulate the access to certain (or all) Prolog items. For instance, requirement states that the module system must be able to recognise that there are two items with the same name, but used independently, and provide the means to restrict their accessibility so that no conflict arises. The module system is therefore concerned with the access to certain items. The main task of the ECLiPSe module system is to control the access in such a way that the above requirements can be fulfilled.

• Terminology
• Basic Properties
• Modules and the Top Level Loop
• Modules and Source Files
  • The Module Interface
• Creating and Erasing Modules at Runtime
• Visibility of Predicates
  • Access rule for predicates as goal name
  • Access rules for predicates as arguments of built-ins
  • Defining and modifying the visibility
  • Tools
  • System Tools
• Libraries
• Other Modular Items
• Privacy
• Dynamic Procedures
• Event handlers
• Debugger