Modules for Prolog: Proposal for Part 2 of the Standard

Appeared in volume 8/4, November 1995

Jonathan Hodgson
Email: jhodgson@sju.edu

In the fall of 1995, the relevant national bodies will be voting on whether to accept the current working draft as a committee draft for part 2 of the Prolog standard. Part 1 which contains the general core of the language was approved as an international standard in April of 1995. Part 2 deals with modules. The draft is available from the project editor, Jonathan Hodgson at the above address or can be downloaded from the X3J17 web site at http://www.sju.edu/~jhodgson/x3j17.html. My purpose here is to provide a brief explanation of the proposal.

At its meeting in London in April 1994, WG17 decided that the Prolog module system should be based on the module system found in Quintus Prolog. In the subsequent months leading up to the November 1994 meeting of WG17 in Utrecht, the US committee prepared a document that became the basis of the proposed committee draft. A number of features in the draft go beyond the Quintus system, in particular the distinction between accessible and visible predicates. It is these features that I want to outline here.

The proposed module system is flat, so that no nesting of modules is permitted. However, the proposal distinguishes between unit modules whose text must be contiguous and module parts which allow the text of a module to be in a number of discontiguous parts. The interface to a module (or module part) specifies the name of the module, the list of exported predicates, the list of meta-predicates exported by the module, and the list of predicates made accessible by the module. Accessibility is a new concept; a predicate P that is made accessible by a module M can be called from outside the module using explicit module qualification M:P. A predicate that is defined in a module, but not exported or accessible, cannot be called from outside the module. This allows information hiding for software engineering purposes.

A module may import any predicate, or meta-predicate, that is exported by another module, either by importing the whole module or by a selective import mechanism. Imported predicates or meta-predicates can be invoked without module qualification. They can also be exported by the importing module.

The colon operator ':' is used for module qualification. The interpretation of M:P depends on the nature of the predicate P being qualified (I am ignoring multiple qualification; to find out about the effect in that case you will have to read the draft.) If the predicate P is an ordinary predicate then M:P refers to the accessible predicate P from module M. If P is a meta-predicate then M:P determines the calling context for P. The database of user predicates can be viewed as being indexed by module name. Each module defines a subset of the database. Since each clause in the database belongs to some module, the clauses in the database do not have module qualified heads.

In the case of predicates such as clause/2, assert/2, or retract/2 that affect the database, the module qualification determines the module in which the clauses for the predicate will be sought. Clause/2 behaves slightly differently from the others in that the first argument of clause/2 should not be module qualified. On the other hand, asserta(M:P) can succeed provided that P is a dynamic accessible predicate in M. It should be noted that M:G, call(M:G) and M:call(G) all have the same interpretation as goals when M makes G accessible. In this brief summary, I have highlighted the major features of the working draft proposal for part 2 of the international Prolog standard. I will be grateful for any comments on the draft. I can be reached at the email address provided above.

Jonathan Hodgson
Saint Joseph's University
Philadelphia, PA 19131, USA
Email: jhodgson@sju.edu