SWI-Prolog 7.4.2 Reference Manual: Section 3.2

## 3.2 Using modules

Modules have been debated fiercely in the Prolog world. Despite all counter-arguments we feel they are extremely useful because:

- They hide local predicates
  This is the reason they were invented in the first place. Hiding provides two features. They allow for short predicate names without worrying about conflicts. Given the flat name-space introduced by modules, they still require meaningful module names as well as meaningful names for exported predicates.

- They document the interface
  Possibly more important than avoiding name conflicts is their role in documenting which part of the file is for public usage and which is private. When editing a module you may assume you can reorganise anything except the name and the semantics of the exported predicates without worrying.

- They help the editor
  The PceEmacs built-in editor does on-the-fly cross-referencing of the current module, colouring predicates based on their origin and usage. Using modules, the editor can quickly find out what is provided by the imported modules by reading just the first term. This allows it to indicate in real-time which predicates are not used or not defined.

Using modules is generally easy. Only if you write meta-predicates (predicates reasoning about other predicates) that are exported from a module is a good understanding required of the resolution of terms to predicates inside a module. Here is a typical example from `library(readutil)`.

    :- module(read_util,
              [ read_line_to_codes/2,       % +Fd, -Codes
                read_line_to_codes/3,       % +Fd, -Codes, ?Tail
                read_stream_to_codes/2,     % +Fd, -Codes
                read_stream_to_codes/3,     % +Fd, -Codes, ?Tail
                read_file_to_codes/3,       % +File, -Codes, +Options
                read_file_to_terms/3        % +File, -Terms, +Options
              ]).