|Did you know ...||Search Documentation:|
|Compatibility of the Module System|
The SWI-Prolog module system is largely derived from the Quintus Prolog module system, which is also adopted by SICStus, Ciao and YAP. Originally, the mechanism for defining meta-predicates in SWI-Prolog was based on the module_transparent/1 directive and strip_module/3. Since 5.7.4 it supports the de-facto standard meta_predicate/1 directive for implementing meta-predicates, providing much better compatibility.
The support for the meta_predicate/1 mechanism, however, is considerably different. On most systems, the caller of a meta-predicate is compiled differently to provide the required <module>:<term> qualification. This implies that the meta-declaration must be available to the compiler when compiling code that calls a meta-predicate. In practice, this implies that other systems pose the following restrictions on meta-predicates:
In SWI-Prolog, meta-predicates are also module-transparent, and qualifying the module-sensitive arguments is done inside the meta-predicate. As a result, the caller need not be aware that it is calling a meta-predicate and none of the above restrictions hold for SWI-Prolog. However, code that aims at portability must obey the above rules.
Other differences are listed below.
usermodule. In turn, the
usermodule imports from the module
systemthat provides all built-in predicates. The auto-import hierarchy can be changed using add_import_module/3 and delete_import_module/2.
This mechanism can be used to realise a simple object-oriented system or a hierarchical module system.
usermodule. I.e., operators are inherited from the import modules (see above).
:- op(precedence, type, user:(operatorname)).