Why Prolog Needs Modules
As a Prolog program grows beyond a single file, predicate name clashes become likely: two files might each define append/3, member/2, or a project-specific predicate name with different meanings. Modules give each file its own namespace, so predicates defined in one module do not silently collide with same-named predicates in another unless the programmer explicitly imports and uses them.
Cricket analogy: It is like two different domestic leagues both having a player named Sharma; without a team or franchise namespace attached, their stats would collide, so modules let each file be its own franchise.
Declaring and Using a Module
A file becomes a module through a module/2 directive naming the module and listing its exported predicate indicators. Another file loads it with use_module/1 to import all exported predicates, or use_module/2 with an explicit list to import only some of them. When two imported predicates share a name, or when you simply want to be unambiguous, you can call a predicate explicitly with Module:Goal to bypass normal import resolution.
Cricket analogy: It is like a player's central contract explicitly listing which formats, Test, ODI, or T20, they're exported to play, with a franchise importing that player only for the listed formats.
% file: geometry.pl
:- module(geometry, [area_circle/2]).
area_circle(Radius, Area) :-
Area is pi * Radius * Radius.
% file: main.pl
:- use_module(geometry).
?- area_circle(3, A).
% A = 28.274333882308138.Public vs Private Predicates
Only predicates listed in a module's export list, given by Name/Arity, are visible to code outside the module; everything else remains private, callable only from within the same file unless explicitly qualified with Module:Goal. This mirrors encapsulation in object-oriented languages, letting a module's author refactor internal helper predicates freely as long as the exported interface stays stable.
Cricket analogy: It is like a franchise's internal training drills staying private to the squad while only the final XI selection, the exported result, is visible to the public and opposition.
Module semantics are not fully standardized across Prolog implementations. SWI-Prolog's module system, the ISO module proposal, and library-level module conventions in other systems differ in directive names and in how predicates cross module boundaries, so module-based code written for one system may need adaptation before it runs unmodified on another.
Meta-predicates and Module Transparency
Some predicates, such as call/1 and findall/3, are declared module transparent, meaning they execute their goal argument in the context of whichever module called them rather than the module where they themselves are defined. This matters when writing reusable library predicates that accept a goal as an argument, since the goal must resolve against the caller's predicates, not the library's own private ones.
Cricket analogy: It is like a neutral umpire applying the home ground's specific boundary rules, rather than their own federation's default, when officiating a bilateral series, so their ruling is transparent to whichever ground's context they're in.
It is easy to accidentally define a predicate in your own module that shadows a name already imported from another module, such as redefining a helper called member/2 by accident. Prolog will typically report a conflict like 'already imported from module X', which can be confusing until you recognize it as a naming collision rather than a logic error.
- Modules give each Prolog file its own predicate namespace, preventing name clashes across files.
- module/2 declares a module's name and its list of exported predicate indicators (Name/Arity).
- use_module/1 imports all exported predicates; use_module/2 imports a restricted subset.
- Predicates not listed in the export list remain private to their defining module.
- Qualified calls (Module:Goal) let you call a predicate explicitly from a specific module.
- call/1 and findall/3 are module-transparent, executing goals in the calling module's context.
- Module semantics differ somewhat between Prolog implementations, so module-based code isn't always fully portable.
Practice what you learned
1. What problem do Prolog modules primarily solve?
2. Which directive declares a file as a module and lists its exported predicates?
3. What happens to a predicate defined in a module but not included in its export list?
4. What does it mean for a predicate like call/1 to be 'module transparent'?
5. Which syntax lets you explicitly call a predicate from a specific module?
Was this page helpful?
You May Also Like
Debugging Prolog Programs
Master Prolog's built-in tracer, spy points, and common failure patterns to systematically debug logic programs.
Prolog for Expert Systems
Learn how Prolog's rule-based inference engine maps naturally onto expert system architecture, from knowledge bases to forward and backward chaining.
Prolog and AI Search Algorithms
See how classic AI search strategies, depth-first, breadth-first, and best-first, map onto Prolog's own backtracking engine and how to implement them explicitly.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics