INTERNATIONAL ISO/IEC
STANDARD 13211-2
First edition
2000-06-01
Information technology — Programming
languages — Prolog —
Part 2:
Modules
Technologies de l'information — Langages de programmation — Prolog —
Partie 2: Modules
Reference number
©
ISO/IEC 2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2000
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2000 – All rights reserved

Contents Page
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
1Scope :: :::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::::1
1.1 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative reference :::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::::1
3 Terms and definitions ::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::::1
4 Compliance :: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::::3
4.1 Prolog processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2 Module text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3 Prolog goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.4 Prolog modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.4.1 Prolog text without modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.4.2 The module user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.5 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.5.1 Dynamic Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.5.2 Inaccessible Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5Syntax::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::::4
5.1 Module text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 Language concepts and semantics ::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::::4
6.1 Related terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1.1 Qualified and unqualified terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2 Module text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.1 Module user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.2 Procedure Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.3 Module interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.4 Module directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2.5 Module body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2.6 Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3 Complete database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3.1 Visible database . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4 Context sensitive predicates. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4.1 Metapredicate built-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4.2 Context sensitive built-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4.3 Module name expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4.4 Examples: Metapredicates . . . . . . . . . . . . . . . . . . . . . . . . 9
6.5 Converting a term to a clause, and a clause to a term . . . . . . . . . . . . . . . . . 10
6.5.1 Converting a term to the head of a clause . . . . . . . . . . . . . . . . . . . 10
6.5.2 Converting a module qualified term to a body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.5.3 Converting the body of a clause to a term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.6 Executing a Prolog goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
iii
© ISO/IEC 2000 – All rights reserved

6.6.1 Data types for the execution model . . . . . . . . . . . . . . . . . . . . . 12
6.6.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.6.3 Searching the complete database . . . . . . . . . . . . . . . . . . . . . . 13
6.6.4 Selecting a clause for execution. . . . . . . . . . . . . . . . . . . . . . . 13
6.6.5 Backtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.6.6 Executing a user-defined procedure: . . . . . . . . . . . . . . . . . . . . . 14
6.6.7 Executing a built-in predicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.7 Executing a control construct . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.7.1 call/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.7.2 catch/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.7.3 throw/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.8 Predicate properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.9 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.9.1 Flag: colon sets calling context . . . . . . . . . . . . . . . . . . . . . . 16
6.10 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.10.1 Error classification. . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Built-in predicates::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: ::::: :::: :::: 16
7.1 The format of built-in predicate definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.1 Type of an argument. . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Module predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.1 current module/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2.2 predicate property/2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 Clause retrieval and information . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.1 clause/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.2 current predicate/1 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4 Database access and modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.4.1 asserta/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.4.2 assertz/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4.3 retract/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4.4 abolish/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iv
© ISO/IEC 2000 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized
system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International
Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and
IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard
requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 13211 may be the subject of patent rights. ISO and IEC
shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 13211-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 22, Programming languages, their environments and system software interfaces.
ISO/IEC 13211 consists of the following parts, under the general title Information technology — Programming languages — Prolog:
� Part 1: General core
� Part 2: Modules
v
© ISO/IEC 2000 – All rights reserved

Introduction
This is the first International Standard for Prolog, Part 2 (Modules). It was produced on May 1, 2000.
Prolog (Programming in Logic) combines the concepts of logical and algorithmic programming, and is recognized
not just as an important tool in AI (Artificial Intelligence) and expert systems, but as a general purpose high-level
programming language with some unique properties.
The language originates from work in the early 1970s by Robert A. Kowalski while at Edinburgh University (and ever
since at Imperial College, London) and Alain Colmerauer at the University of Aix-Marseilles in France. Their efforts
led in 1972 to the use of formal logic as the basis for a programming language. Kowalski’s research provided the
theoretical framework, while Colmerauer’s gave rise to the programming language Prolog. Colmerauer and his team then
built the first interpreter, and David Warren at the AI Department, University of Edinburgh, produced the first compiler.
The crucial features of Prolog are unification and backtracking. Unification shows how two arbitrary structures can be
made equal, and Prolog processors employ a search strategy which tries to find a solution to a problem by backtracking
to other paths if any one particular search comes to a dead end.
Prolog is good for windowing and multimedia because of the ease of building complex data structures dynamically, and
also because the concept of backing out of an operation is built into the language. Prolog is also good for interactive
web applications because the language lends itself to both the production and analysis of text, allowing for production
of HTML ‘on the fly’.
This International Standard defines syntax and semantics of modules in ISO Prolog. There is no other International
Standard for Prolog modules.
Modules in Prolog serve to partition the name space and support encapsulation for the purposes of constructing large
systems out of smaller components. The module system is procedure-based rather than atom-based. This means that
each procedure is to be defined in a given name space. The requirements for Prolog modules are rendered more
complex by the existence of context sensitive procedures.
vi
© ISO/IEC 2000 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 13211-2:2000(E)
Information technology — Programming languages —
Prolog — Part 2: Modules
recent edition of the normative document indicated below. For
1Scope
undated references, the latest edition of the normative document
referred to applies. Members of ISO and IEC maintain registers of
This part of ISO/IEC 13211 is designed to promote the
currently valid International Standards.
applicability and portability of Prolog modules that contain
Prolog text complying with the requirements of the Programming
ISO/IEC 13211-1 : 1995, Information technology — Program-
Language Prolog as specified in this part of ISO/IEC 13211.
ming languages – Prolog Part 1: General core.
This part of ISO/IEC 13211 specifies:
a) The representation of Prolog text that constitutes a Prolog
3 Terms and definitions
module,
The terminology for this part of ISO/IEC 13211 has a format
b) The constraints that shall be satisfied to prepare Prolog
modeled on that of ISO 2382.
modules for execution, and
An entry consists of a phrase (in bold type) being defined,
c) The requirements, restrictions and limits imposed on a
followed by its definition. Words and phrases defined in the
conforming Prolog processor that processes modules.
glossary are printed in italics when they are defined in ISO/IEC
13211-1 or other entries of this part of ISO/IEC 13211. When
This part of ISO/IEC 13211 does not specify:
a definition contains two words or phrases defined in separate
entries directly following each other (or separated only by a
a) The size or number of Prolog modules that will exceed the
punctuation sign), * (an asterisk) separates them.
capacity of any specific data processing system or language
processor, or the actions to be taken when the limit is
Words and phrases not defined in the glossary are assumed to
exceeded,
have the meaning given in ISO 2382-15 and ISO/IEC 13211-1;
if they do not appear in ISO 2382-15 or ISO/IEC 13211-1, then
b) The methods of activating the Prolog processor or the
they are assumed to have their usual meaning.
set of commands used to control the environment in which
Prolog modules are prepared for execution,
A double asterisk (**) is used to denote those definitions where
there is a change from the meaning given in ISO/IEC 13211-1.
c) The mechanisms by which Prolog modules are loaded,
d) The relationship between Prolog modules and the
3.1 accessible procedure: See 3.39 – procedure, accessible.
processor-specific file system.
3.2 activation, of a procedure: A procedure has been
1.1 Notes activated when it is called for execution.
Notes in this part of ISO/IEC 13211 have no effect on the
3.3 argument, qualified: A qualified term which is an
language, Prolog text, module text or Prolog processors that are
argument in a module name qualified * predication.
defined as conforming to this part of ISO/IEC 13211. Reasons
for including a note include:
3.4 calling context: The set of visible procedures,the operator
a) Cross references to other clauses and subclauses of this
table, the character conversion mapping and Prolog flag values
part of ISO/IEC 13211 in order to help readers find their
denoted by a module name, and used as a context for activation
way around,
of a context sensitive procedure.
b) Warnings when a built-in predicate as defined in this part
of ISO/IEC 13211 has a different meaning in some existing
3.5 database, visible: The visible database of a module M
implementations.
is the set of procedures that can be activated without module
name qualification from within M.
2 Normative reference
3.6 defining module: See 3.23 – module, defining.
The following normative document contains provision which,
through reference in this text, constitute provisions of this part of
3.7 export: To make a procedure of an exporting module
ISO/IEC 13211. For dated references, subsequent amendments to,
available for import or re-export by other modules.
or revisions of, any of these publications do not apply. However,
parties to agreements based on this part of ISO/IEC 13211 are
encouraged to investigate the possibility of applying the most 3.8 exported procedure: See 3.41 – procedure, exported.
© ISO/IEC 2000 – All rights reserved

3.9 import: To make procedures * exported or re-exported 3.25 module, existing: A module whose interface has been
by a module * visible in an importing or re-exporting module. prepared for execution (see 6.2.3).
3.10 import, selective: The importation into a module of only
3.26 module, exporting: A module that makes available
certain explicitly indicated procedures * exported or re-exported
procedures for import or re-export by other modules.
by a module (see 6.2.5.2).
3.27 module interface: A sequence of read-terms which
3.11 load (a module): Load the module interface of a module
specify the exported and re-exported procedures and exported *
and correctly prepare all its bodies,if any,for execution.
metapredicates of a module.
NOTE — The interface of a module shall be loaded before any body
of the module (see 6.2.3).
3.28 module, importing: A module into which procedures
are imported, adding them to the visible database of the module.
3.12 load (a module interface): Correctly prepare the module
interface of the module for execution.
3.29 module, lookup: The module where search for clauses
of a procedure takes place.
3.13 lookup module: See 3.29 – module, lookup.
NOTE — The lookup module defines the visible database of procedures
accessible without module name qualification (see 6.1.1.3).
3.14 meta-argument: An argument in a metaprocedure which
is context sensitive.
3.30 module name: An atom identifying a module.
3.15 metapredicate: A predicate denoting a metaprocedure.
3.31 module name qualification: The qualification of a term
3.16 metapredicate directive: A directive stipulating that a
with a module name.
procedure is a metapredicate.
3.32 module, qualifying: See 6.1.1.3 – Qualifying mod-
3.17 metapredicate mode indicator: Either a predicate indi-
ule, lookup module and defining module.
cator or a compound term each of whose arguments is ‘:’,or
‘*’ (see 6.1.1.4).
3.33 module, re-exporting: A module which, by re-
exportation,* imports certain procedures and exports these
3.18 metaprocedure: A procedure whose actions depend on
same procedures.
the calling context, and which therefore carries augmented
module information designating this calling context.
3.34 module text: A sequence of read-terms denoting direc-
3.19 metavariable: A variable occurring as an argument tives, module directives and clauses.
in a metaprocedure which will be subject to module name
qualification when the procedure is activated.
3.35 module, user: A module with name user containing
all user-defined procedures that are not specified as belonging
3.20 module: A named collection of procedures and directives
to a specific module.
together with provisions to export some of the procedures and
to import and re-export * procedures from other modules.
3.36 predicate **: An identifier or qualified identifier together
with an arity.
3.21 module body: A Prolog text containing the definitions
of the procedures of a module together with import and other
directives local to that module body.
3.37 predicate name, qualified: The qualified identifier of a
predicate.
3.22 module, calling (of a procedure): The module in which
a corresponding activator is executed.
3.38 preparation for execution: Implementation dependent
handling of both Prolog text and module text by a processor
which results, if successful, in the processor being ready to
3.23 module, defining: The module in whose module body
execute the prepared Prolog text or module text.
(or bodies) a procedure is defined explicitly and entirely.
3.24 module directive: A term D which affects the meaning 3.39 procedure, accessible: A procedure is accessible if it
of module text (6.2.4), and is denoted in that module text by a can be activated with module name qualification from any
directive-term :- (D). module which is currently loaded.
© ISO/IEC 2000 – All rights reserved

3.40 procedure, context sensitive: A procedure is context 1) the requirements of this part of ISO/IEC 13211,
sensitive if the effect of its execution depends on the calling including the requirements set out in ISO/IEC 13211-1
context in which it is activated. General Core, whether or not the text makes explicit use
of modules, and
3.41 procedure, exported: A procedure that is made available
2) the implementation defined and implementation specific
by a module for import or re-export by other modules.
features of the Prolog processor,
b) Correctly execute Prolog goals which have been prepared
3.42 procedure, visible (in a module M): A procedure
for execution and which conform to:
that can be activated from M without using module name
qualification.
1) the requirements of this part of ISO/IEC 13211 and
ISO/IEC 13211, and
3.43 process **: Execution activity of a processor running
2) the implementation defined and implementation specific
prepared Prolog text and module text to manipulate conforming
features of the Prolog processor,
Prolog data, accomplish side effects and compute results.
c) Reject any Prolog text, module text or read-term whose
syntax fails to conform to:
3.44 prototype: A compound term where each argument is
a variable.
1) the requirements of this part of ISO/IEC 13211 and
ISO/IEC 13211, and
3.45 prototype, qualified: A qualified term whose first
argument is a module name and second argument is a prototype.
2) the implementation defined and implementation specific
features of the Prolog processor,
d) Specify all permitted variations from this part of ISO/IEC
3.46 qualification: The textual replacement (6.4.3) of a term
13211 and ISO/IEC 13211 in the manner prescribed by this
T by the term M:T where M is a module name.
part of ISO/IEC 13211 and ISO/IEC 13211, and
e) Offer a strictly conforming mode which shall reject the
3.47 qualified argument: See 3.3 – argument, qualified
use of an implementation specific feature in Prolog text,
module text or while executing a goal.
3.48 qualified term: See 3.51 – term, qualified.
4.2 Module text
3.49 re-export: To make procedures * exported by a module
Conforming module text shall use only the constructs specified
* visible in the re-exporting module, while at the same time
in this part of ISO/IEC 13211 and ISO/IEC 13211-1, and
making them available for import or re-export by other modules
the implementation defined and implementation specific features
from the re-exporting module.
supported by the processor.
3.50 re-export, selective: The re-exportation by a re-exporting Strictly conforming module text shall use only the constructs
* module of certain indicated procedures * exported from another specified in this part of ISO/IEC 13211 and ISO/IEC 13211-1,
module (see 6.2.4.3). and the implementation defined features specified by this part
of ISO/IEC 13211.
3.51 term, qualified: A term whose principal functor is
(:)/2.
4.3 Prolog goal
A conforming Prolog goal is one whose execution is defined
3.52 visible procedure (in a moduleM): See 3.42 – procedure,
by the constructs specified in this part of ISO/IEC 13211
visible.
and ISO/IEC 13211-1, and the implementation defined and
implementation specific features supported by the processor.
3.53 visible database (of a module M): See 3.5 – database,
A strictly conforming Prolog goal is one whose execution is
visible.
defined by constructs specified in this part of ISO/IEC 13211
and ISO/IEC 13211-1, and the implementation defined features
specified by this part of ISO/IEC 13211.
4 Compliance
4.4 Prolog modules
4.1 Prolog processor
4.4.1 Prolog text without modules
A conforming processor shall:
a) Correctly prepare for execution Prolog text and module A processor supporting modules shall be able to prepare and
text which conforms to: execute Prolog text that does not explicitly use modules. Such
© ISO/IEC 2000 – All rights reserved

Table 1 — The initial operator table
text shall be prepared and executed as the body of the required
built-in module named user.
Priority Specifier Operator(s)
1200 xfx :- -->
1200 fx :- ?-
4.4.2 The module user
1100 xfy ;
1050 xfy ->
A Prolog processor shall support a built-in module user.
1000 xfy ,
User-defined procedures not defined in any particular module
900 fy \+
shall belong to the module user.
700 xfx = \=
700 xfx == \== @< @=< @> @>=
700 xfx =.
4.5 Documentation
700 xfx is =:= =\= < =< > >=
600 xfy :
A conforming Prolog processor shall be accompanied by docu-
500 yfx +-/\\/
mentation that completes the definition of every implementation
400 yfx * / // rem mod << >>
defined implementation specific features (if any) specified in
200 xfx **
this part of ISO/IEC 13211and ISO/IEC 13211-1.
200 xfy ˆ
200 fy - \
4.5.1 Dynamic Modules
A Prolog processor may support additional implementation
Clause 6.2.4 defines the module directives and the module
specific procedures that support the creation or abolition of
interface directives. Clause 6.2.5 defines directives in addition
modules during execution of a Prolog goal.
to those of ISO/IEC 13211-1 that can appear in a module body
and their meanings.
4.5.2 Inaccessible Procedures
5.2 Terms
A Prolog processor may support additional features whose effect
is to make certain procedures defined in the body of a module
5.2.1 Operators
not accessible from outside the module.
The operator table specific to a module M defines which atoms
will be regarded as operators in the context of the given module
module M when (1) a sequence of tokens is parsed as a read-term
5Syntax
by the built-in predicate read term/3 or (2) Prolog text is
prepared for execution or (3) output by the built-in predicates
This clause defines the abstract syntax of Prolog text that
write term/3, write term/2, write/1, write/2,
supports modules. The notation is that of ISO/IEC 13211-1.
writeq/1, writeq/2.
Clause 5.1 defines the syntax of module text. Clause 5.2 defines
The effect of the directives op/3, char conversion/2
the role of the operator ‘:’.
and set prolog flag/2 in modules with multiple bodies is
described in 6.2.5.4.
5.1 Module text
Table 1 defines the predefined operators. The operator ‘:’ is
used for module qualification.
Module text is a sequence of read-terms which denote (1)
module directives, (2) interface directives, (3) directives, and (4)
NOTES
clauses of user-defined procedures.
1 This table is the same as table 7 of ISO/IEC 13211-1 with the
The syntax of a module directive and of a module interface
single addition of the operator ‘:’.
directive is that of a directive.
2 When used in a predicate indicator or predicate name ‘:’ is an
module text = m text ;
atom qualifier. This means that a predicate name can be a compound
Abstract:mtmtterm provided that the functor is ‘:’.
3 The operator table can be changed both by the use of the module
interface directive op/3 and by the module directive op/3 in the
m text = directive term, m text ;
body of a module.
Abstract:dtdt
m text = clause term, m text ; 6 Language concepts and semantics
Abstract:ctct
This clause defines the semantic concepts of Prolog with
modules.
m text = ;
Abstract: nil a) Subclause 6.1 defines the qualifying module and unqual-
ified term associated with a qualified term,
4 © ISO/IEC 2000 – All rights reserved

b) Subclause 6.2 defines the division of module text into If the flag colon sets calling context 6.9.1 is true
Prolog modules, shall be a compound term each of whose arguments is ‘:’ or
‘*’. In this case an argument whose position corresponds to a
c) Subclause 6.2.6 defines the relationship between clauses ‘:’ is a meta-argument, and an argument corresponding to ‘*’
in module text and in the complete database, shall not be a meta-argument.
d) Subclause 6.3 defines the complete database and its
relation to Prolog modules, 6.2 Module text
e) Subclause 6.4 defines metapredicates and the process of
Module text specifies one or more user-defined modules and the
name qualification,
required module user. A module consists of a single module
interface and zero or more corresponding bodies. The interface
f) Subclause 6.5 defines the process of converting terms to
shall be prepared for execution before any of the bodies. Bodies
clauses and vice versa in the context of modules,
may be separated from the interface. If there are multiple
bodies, they need not be contiguous.
g) Subclause 6.6 defines the process of executing a goal in
the presence of module qualification,
The heads of clauses in module text shall be implicitly module
qualified only by the module body in which they appear, not
h) Subclause 6.7 defines the process of executing a control
by explicit qualification of the clause head.
construct in the presence of module qualification.
Every procedure that is neither a control construct nor a
i) Subclause 6.8 defines predicate properties,
built-in predicate belongs to some module. Built-in predi-
cates and control constructs are visible everywhere and do
j) Subclause 6.9 defines required flags in addition to those
not require module qualification, except that if the flag
required by ISO/IEC 13211-1.
colon sets calling context 6.9.1 is true the builtin
metapredicates (6.4.1) , the context sensitive builtins 6.4.2 and
k) Subclause 6.10 defines errors in addition to those required
call/1 and catch/3 may be module qualified for the purpose
by ISO/IEC 13211-1.
of setting the calling context.
6.1 Related terms
6.2.1 Module user
This clause extends the definitions of clause 7.1 of ISO/IEC
The required module user contains all user-defined procedures
13211-1.
not defined within a body of a specific module. It has by default
an empty module interface. However, module text may contain
6.1.1 Qualified and unqualified terms an explicit interface for module user. Any such interface
must be loaded before any Prolog text belonging to the module
user.
6.1.1.1 Qualified terms
NOTE — An explicit interface for module user enables procedures
A qualified term is a term whose principal functor is (:)/2.
to be exported from module user to other modules and allows
metapredicates to be defined in module user.
6.1.1.2 Unqualified terms
6.2.2 Procedure Visibility
An unqualified term is a term whose principal functor is not
(:)/2.
All procedures defined in a module are accessible from any
module by use of explicit module qualification. It shall be an
allowable extension to provide a mechanism that hides certain
6.1.1.3 Qualifying module
procedures defined in a module M so that they cannot be
activated, inspected or modified except from within a body of
Given a module M and a term T, the associated qualifying
the module M.
module QM = qm(M:T) and associated unqualified term UT =
ut(M:T) of (M:T) are defined as follows:
A module shall not make visible by import or re-export two or
more procedures with a given (unqualified) predicate indicator
a) If the principal functor of T is not (:)/2 then qm(M:T)
defined in different modules. If a procedure with (unqualified)
is M and ut(M:T) is T;
predicate indicator PI from the complete database is visible in
b) If the principal functor of T is (:)/2 with first argument M no other procedure with the same predicate indicator shall be
MM, and second argument TT,then qm(M:T) is the qualifying made visible in M.
module of qm(MM:TT),and ut(M:T) is the unqualified
NOTE — More than one import or re-export directive may make
term ut(MM:TT).
visible a single procedure in a module.
6.1.1.4 Metapredicate mode indicators
6.2.3 Module interface
A metapredicate mode indicator is either a predicate indicator or
a compound term M Name(Modes) each of whose arguments A module interface in module text specifies the name of the
is ‘:’ or ‘*’. module, the operators, character conversions and Prolog flag
© ISO/IEC 2000 – All rights reserved

values that shall be used when the processor begins to prepare designated by PI,and that MM makes these procedures available
for execution the bodies of the module, and the user-defined for import or re-export (from MM) by other modules.
procedures of a module that are
A procedure designated by PI in a reexport(M,PI) directive
shall be that of a procedure exported or re-exported by the
a) exported from the module,
module M.
b) re-exported from the module, and
No procedure designated by PI shall be a control construct or
a built-in predicate.
c) defined to be metapredicates by the module.
A sequence of directives shall form the module interface of the
module with name Name if :
6.2.4.4 Module interface directive reexport/1
a) The first directive is a directive module(Name). A module interface directive reexport(PI) in the module
(6.2.4.1)
interface of a module M,where PI is an atom, a sequence of
atoms, or a list of atoms specifies that the module M imports
b) The last directive is a directive end module(Name). all the user defined procedures exported or re-exported by the
(6.2.4.9) modules designated by PI and that M makes these procedures
available for import into or re-exportation by other modules.
c) Each other element of the sequence is a module interface
directive. (6.2.4.2 through 6.2.4.8)
6.2.4.5 Module interface directive metapredicate/1
The interface for a module Name shall be loaded before any
body of the module.
A module interface directive metapredicate(MI) in the
module interface of a module M,where MI is a metapredicate
mode indicator, a metapredicate mode indicator sequence, or
6.2.4 Module directives
a metapredicate mode indicator list specifies that the module
defines and exports the metaprocedures designated by MI.
Module directives are module text which serve to 1) separate
module text into the individual modules, and 2) define operators,
character conversions and flag values that apply to the preparation
6.2.4.6 Module interface directive op/3
for execution of the bodies of the corresponding module.
A module interface directiveop(Priority,Op specifier,
Operator) in the module interface of a module M enables
6.2.4.1 Module directive module/1
the initial operator table to be altered only for the preparation
for execution of all the bodies of the module M.
The module directivemodule(Name) specifies that the interface
text bracketed by the directive and the matching closing interface
The arguments Priority, Op specifier,and Operator
directive end module(Name) defines the interface to the
shall satisfy the same constraints as for the successful execution
Prolog module Name.
of the built-in predicate op/3 (8.14.3 of ISO/IEC 13211-1) and
the initial operator table of the module shall be altered in the
same way.
6.2.4.2 Module interface directive export/1
Operators defined in a module interface directive
A module interface directive export(PI) in the module
op(Priority, Op specifier, Operator) shall not
interface of a module M,where PI is a predicate indicator,
affect the syntax of read terms in Prolog and module texts other
a predicate indicator sequence or a predicate indicator list,
than the bodies of the corresponding module.
specifies that the module M makes the procedures designated by
PI available for import into or re-export by other modules.
6.2.4.7 Module interface directive char conversion/2
A procedure designated by PI in a export(PI) directive
shall be that of a procedure defined in the body (or bodies) of
A module interface directive char conversion(In char,
the module M.
Out char) in the module interface of a module M enables
the initial character conversion mappingConv(see 3.29 ofCNo procedure designated by PI shall be a control construct, a
ISO/IEC 13211-1) to be altered only for the preparation for
built-in predicate, or an imported procedure.
execution of all the bodies of the module M.
NOTE — Since control constructs and built-in predicates are visible
everywhere they cannot be exported. The arguments In char,and Out char shall satisfy the
same constraints as for the successful execution of the built-in
predicate char conversion/2 (8.14.5 of ISO/IEC 13211-1)
6.2.4.3 Module interface directive reexport/2
andConvshall be altered in the same way.C
A directive reexport(M, PI) in the interface of a module MM Character conversions defined in a module interface directive
where M is an atom and PI is a predicate indicator, a predicate char conversion(In char, Out char) shall not affect
indicator sequence or a predicate indicator list specifies that the syntax of read terms in Prolog and module texts other than
the module MM imports from the module M all the procedures the bodies of the corresponding module.
6 © ISO/IEC 2000 – All rights reserved

6.2.4.8 Module interface directive set prolog flag/2 the module MM imports from the module M all the procedures
designated by PI.
A module interface directive set prolog flag(Flag,
Value) in the module interface of a module M enables A procedure designated by PI in a import(M,PI) directive
shall be a procedure exported or re-exported by the module M.
the initial value associated with a Prolog flag to be altered only
for the preparation for execution of all the bodies of the module
No procedure designated by PI shall be a control construct or
M.
a built-in predicate.
The arguments Flag,and Value shall satisfy the same
constraints as for the successful execution of the built-in
predicate set prolog flag/2 (8.17.1 of ISO/IEC 13211-1) 6.2.5.3 Directive import/1
and the Value shall be associated with flag Flag in the same
way.
A directive import(MI) in a body of a module MM where MI
is an atom, a sequence of atoms, or a list of atoms specifies
Values associated with flags in a module interface directive
that the module MM imports all the procedures exported by the
set prolog flag(Flag, Value) shall not affect the values
modules designated by MI. Such procedures shall be visible in
associated with flags in Prolog and module texts other than the
MM without name qualification.
bodies of the corresponding module.
6.2.5.4 Module directive end body/1
6.2.4.9 Module directive end module/1
The module directive end body(Name) where Name is an
The module directive end module(Name)where Name is an
atom that has already appeared as the argument of a module
atom that has already appeared as the argument of a module
directive body/1 specifies the termination of the Prolog text
directive module/1, specifies the termination of the interface
belonging to the particular module body of module Name.
for the module Name.
The preparation for execution of any module interface shall
NOTE — Unless otherwise so defined module directives are not Prolog
set the operator table, character conversion mappingConvC
text. Thus op/3, char conversion/2 and set prolog flag/2
(see 3.29 of ISO/IEC 13211-1), and Prolog flag values to a
are both module directives and directives (see ISO/IEC 13211-1 7.4.2.4,
new initial state, determined by the module interface directives
7.4.2.5 and 7.4.2.9.)
op/3, char conversion/2,and set prolog flag/2 in
the interface of M. This state shall affect only the preparation
for execution of the subsequent bodies of the module M.
6.2.5 Module body
The effect of directives op/3, char conversion/2,and
set prolog flag/2 in a body of a module M shall accumulate
A module body belonging to a module is Prolog text which
during the preparation for execution of the current body and all
defines user-defined procedures that belong to the module.
subsequent bodies of the module M.
A sequence of directives and clauses shall form a body of the
NOTE — A single module may have more than one body. However
module with name Name if:
module text does not permit the nesting of any module body within
the Prolog text of the body of any module other than the user
a) The first element of the sequence is a directive
module.
body(Name) (6.2.5.1).
b) The last element of the sequence is a directive
6.2.6 Clauses
end body(Name)(6.2.5.4).
A clause-term in one of the bodies of a module M of module
Directives import/1 and import/2 make visible in the
text causes a clause of a user-defined procedure to be added to
importing module procedures defined in an exporting or re-
the module M.
exporting module.
Aclause C of a clause-term (=C.) in the body of a module M
shall be an unqualified term which is a clause term whose head
6.2.5.1 Module directive body/1
is an unqualified term and shall satisfy the same constraints as
those required for a successful execution of the built-in predicate
A module directive body(Name) where Name is an atom
assertz(C) (7.4.2) in the context of M, except that no error
giving the name of a module specifies that the Prolog text
referring to modification of a static procedure shall occur. C
bracketed between this directive and the next end module
shall be converted to a clause h:- t and added to the module
directive end body(Name) belongs to the module Name.
M.
Such procedures shall be visible in all bodies of Name without
name qualification.
The predicate indicator P/N of the head of C shall not be
the predicate indicator of any built-in predicate, or a control
construct, and shall not be that of any predicate imported into
6.2.5.2 Directive import/2
or reexported by M.
A directive import(M, PI) in a body of a module MM where
NOTE — If the directive discontiguous/1 is in effect for a
M is an atom and PI is a predicate indicator, a predicate
...