Skip to Main Content
Have library access? Log in through your library
The Implementation of Prolog

The Implementation of Prolog

Patrice Boizumault
Ara M. Djamboulian
Jamal Fattouh
Copyright Date: 1993
Pages: 324
  • Cite this Item
  • Book Info
    The Implementation of Prolog
    Book Description:

    A semantically well-defined programming language widely used in artificial intelligence, Prolog has greatly influenced other programming languages since its introduction in the late 1970s. A user may find Prolog deceptively easy, however, and there are a number of different implementations. In this book Patrice Boizumault draws from his extensive experience in Prolog implementation to describe for students of all levels the concepts, difficulties, and design limits of a Prolog system.

    Boizumault introduces the specific problems posed by the implementation of Prolog, studies and compares different solutions--notably those of the schools of Marseilles and Edinburgh--and concludes with three examples of implementation. Major points of interest include identifying the important differences in implementing unification and resolution; presenting three features of Prolog II--infinite trees,dif, andfreeze--that introduce constraints; thoroughly describing Warren's Abstract Machine (WAM); and detailing a Lisp imple-mentation of Prolog.

    Originally published in 1993.

    ThePrinceton Legacy Libraryuses the latest print-on-demand technology to again make available previously out-of-print books from the distinguished backlist of Princeton University Press. These paperback editions preserve the original texts of these important books while presenting them in durable paperback editions. The goal of the Princeton Legacy Library is to vastly increase access to the rich scholarly heritage found in the thousands of books published by Princeton University Press since its founding in 1905.

    eISBN: 978-1-4008-6344-0
    Subjects: Mathematics

Table of Contents

  1. Front Matter
    (pp. i-vi)
  2. Table of Contents
    (pp. vii-x)
    (pp. xi-xii)
    Marc Bergman

    1972 was the official birthdate of Prolog, recognized as the first operational implementation of LOGic PROgramming. A few years were sufficient to establish Prolog as a respectable and recognized language. The long list of languages that borrow its name in part or in whole testifies to the importance of the Prolog phenomenon.

    The history of programming languages is rich in examples where the specifications of a language and its implementation exist before its semantics are defined. This is not the case with Prolog, which benefited from the beginning from a well-defined semantics. This semantics evolved through successive refinements, unlike so...

    (pp. xiii-2)
    Patrice Boizumault
    (pp. 3-10)

    The concept of using predicate logic as a programming language appeared in the early 1970s as a result of the works of A. Colmerauer and R. Kowalski. The first Prolog interpreter (Prolog0) [CKPR72] was developed in 1972 at the university of Aix-Marseille by P. Roussel. This first implementation was written in Algol W and used a complete copying technique.

    The power and simplicity of Prolog, together with a well-defined semantics based on predicate calculus, gave birth during the 1970s to numerous works and applications, thus promoting a wide variety of implementations. Among these, let us just recall:

    Marseille Prologl, alias...


    • [Part I Introduction]
      (pp. 13-14)

      The purpose of this first part is to recall the fundamental principles ofclassical Prologas well as those ofProlog+with delaying mechanism. As required, we will also introduce the problems that will be treated in the second part as well as some common terminology.

      We will closely follow the second level of progression discussed in the general introduction, that is, the passage fromclassical PrologtoProlog+.For this, we will first describe the fundamental principles of the Prolog language, by considering the notions of unification (chapter 1) and control (chapter 2). Then, we will discuss (chapter 3)...

      (pp. 15-29)

      Unification is an essential part of any Prolog system. Unification is the process of determining whether two terms can be made identical by appropriate substitutions for their variables. The first unification algorithm was proposed by J. A. Robinson in 1965 [Rob65].

      But a vast majority of Prolog systems do not use Robinson’s unification algorithm. For reasons of efficiency, they deliberately choose not to perform the occur check (a variable can thus be unified with a term containing it).

      This choice entails some problems from a theoretical point of view, since it destroys the soundness of the SLD-resolution strategy used by...

      (pp. 30-48)

      Every Prolog system can be considered primarily as a theorem-proving system [Rob65] whose common application consists of asking queries in the context of a universe defined in clausal form.

      The answer to a query is obtained by refutation, that is, by showing that the system consisting of the initial clauses, to which the negation of the query is added, is unsatisfiable. This refutation uses a particular strategy of resolution [Rob65] called SLD-resolution [AE82].

      The Prolog control implements such a strategy of resolution by choosing a particular computation rule (always selecting the left-most literal in the current resolvent) and a particular...

      (pp. 49-66)

      Different approaches have been proposed to improve the classical strategy of Prolog control. H. Gallaire and C. Lasserre [GL82] suggest classifying control according to four principal levels.

      1. Pragmatic control takes advantage of the depth-first left-to-right traversal strategy for writing Prolog programs.

      2. Explicit control incorporated in the program consists of modifying the standard control strategy by means of built-in predicates or variables annotation. Several Prolog systems offer such possibilities: let us mention Prolog-II [Col82b], LM-Prolog [CK83], SP_ Prolog [SPP87], SICStus-Prolog [Car87], IC-Prolog [CCG82], MU-Prolog [Nai85a], and NUProlog [Nai86], [Nai88].

      3. Explicit control separated from the program differs from the...


    • [Part II Introduction]
      (pp. 69-71)

      The purpose of this second part is, first of all, to introduce the different problems encountered in implementing a Prolog system, then to describe and compare the various solutions that have been proposed. We will also give a brief historical overview and make an attempt at classifying the existing Prolog systems based on their main implementation characteristics, such as architecture of the working area, representation of terms, memory management, and extra control facilities.

      Our presentation will follow the two levels of progression given in the introduction:

      1. statement of the problems and the solutions in an interpreted approach leading to...

      (pp. 72-84)

      Prolog is above all a programming language and its control can therefore be considered, from a classical point of view, in terms of calls to and returns from procedures with parameter passing. But the usual model must be extended [Byr79], [Byr80] in order to take into account the particularities of unification and backtracking.

      To implement Prolog, we can take advantage of classical techniques of stack management already developed for other languages. We must, of course, make adjustments to the usual processes in order to meet the specific requirements of Prolog, especially those of unification and backtracking.

      Our approach will be...

      (pp. 85-102)

      During the course of a proof, unification constructs new terms (instances) from those initially appearing in the knowledge base (models). Variables are bound to the Prolog terms, which are either simple (variables or constants) or structured (lists or functional terms). Whereas in the case of simple terms the binding occurs by direct association between the variable and the term, the situation is different for structured terms for which the binding can take place in two different forms: constructing a new instance starting from a model or accessing an already existing instance.

      There are two different modes of representation for terms...

      (pp. 103-120)

      The updating of the control stack upon return from deterministic calls forces the introduction of a third stack in Prolog’s working area, independent of the terms representation's choice, whether by structure sharing or structure copying.

      Indeed, since L3c bindings do not respect creation times (see section 5.1.4), a variable could have a life span greater than that of the clause where it occurs. A premature updating could then cause an irrecoverable loss of information. Such bindings should therefore be allocated in a special memory area, outside the control stack.

      In the case of structure sharing, the proposed solution in Prolog-Dec...

      (pp. 121-136)

      Last-call optimization [Bru80], [Bru82a], [War80] manages specifically the call to the last literal of each rule. If the execution of the father goal has until now been deterministic, then the activation block associated with the call of the last literal replaces the father block. This optimization resembles the iterative management of tail-recursive calls developed in other languages such as Lisp [Gre77], [ASS85] but applies to all last-position calls, recursive or not.

      Last-call optimization may be considered as a generalization of deterministic calls updating presented in chapter 6. Indeed, the space allocated for the execution of a deterministic call is recovered...

      (pp. 137-144)

      The purpose of clause indexing [War77], [War83], [BBC83], [BBCT86] is to diminish, upon every goal call, the set size of selectable clauses, thus avoiding useless unification attempts and unwanted choice points creation.

      Indeed, upon a goal call, it is common practice (see section 2.2.2) to consider selectable all the clauses occurring in the set. However, quite often only one part among all selectable clauses will satisfy unification with the calling goal. We can thus try initially to disregard some of these.

      Accordingly, every set of clauses is organized (divided) into subsets. Upon every call of a goal its arguments’ type...

      (pp. 145-167)

      The first Prolog compiler (Prolog-Dec 10) was developed at the University of Edinburgh by D. H. Warren in 1977. Since then, much research has been conducted all over the world in this area [War80], [War83], [Bal83], [BBC83], [BBCT86], [Clo85]. Currently the overwhelming majority of commercialized Prolog systems embed a compiler.

      Most of the proposed solutions are based on the concept of a virtual machine in order to achieve portability. However, as D. H. Warren points out [War83], the intermediate code thus generated can be processed in different ways: by using an emulator [Qui86], by generating machine code [Car86], by microprogramming...

      (pp. 168-186)

      Thefreeze /2predicate of Prolog-II delays a goal as long as a variable remains unbound (see section 3.4.1). Thedif /2predicate enables the imposition of a constraint on two terms by forcing them to be different in the rest of the proof.

      Even thoughdif(t1, t2)is formally defined as being the addition of the inequalityt1≠t2to the current system of equations and inequations on rational trees [Col82b], its implementation uses the same delaying mechanism as thefreeze /2predicate (see section 3.4).

      The main idea in the implementation of the delaying mechanism is to perform a direct association between...


    • [Part III Introduction]
      (pp. 189-190)

      The goal of this third part, which is dedicated to implementation, is to employ the principles and implementation techniques described in Part 2. The sequence followed in Part 2 will be preserved in the construction of three different implementations (Mini-CProlog, Mini-WAM, and Mini-Prolog-II), related to the three levels previously described.

      1. Mini-CProlog is a CProlog implementation (see section 6.2). It has the following characteristics: structure sharing, a three-stack memory management, and updating of thelocal stackupon return from deterministic calls.

      2. Mini-WAM is based on the solution described in chapter 7. It can thus be considered as an interpreted...

      (pp. 191-206)

      Mini-CProlog is a CProlog implementation and corresponds to the first level described in Part 2. Consequently, Mini-CProlog takes into consideration the proposals of chapter 6 and is issued from the formulated specifications and from the alternatives that have been chosen in chapters 4 and 5.

      Mini-CProlog has the following characteristics: a terms representation by structure sharing, a three-stacks working zone architecture, and the updating of thelocal stackupon return from deterministic calls. Mini-CProlog will also benefit from the clauses indexing mechanism presented in chapter 8.

      Mini-CProlog is based on the solution presented in section 2 of chapter 6, so...

      (pp. 207-221)

      Mini-WAM is a Prolog interpreter that corresponds to the second level, as described in Part 2. Accordingly, it implements the proposals of chapter 7. The Mini-WAM characteristics are as follows: a terms representation by structure copying, a three-stacks working zone architecture, and alocal stackupdating based on last-call optimization.

      Mini-WAM corresponds to the solution proposed by D. H. Warren in 1983 (see chapter 7) and can thus be considered as an interpreted version of Warren’s Abstract Machine (see chapter 9 for the specific compiling considerations). In order to simplify the implementation of Mini-WAM, neither trimming (see section 9.1.3) nor...

      (pp. 222-236)

      Mini-Prolog-II is a Prolog interpreter that corresponds to the third level, as described in Part 2. Accordingly, it implements the proposals of chapter 10. The Mini-Prolog-II characteristics are as follows: a terms representation by structure sharing, a four-stacks working zone architecture, an updating of thelocal stackby last-call optimization, and the implementation of thedif/2andfreeze/2predicates.

      Consequently, Mini-Prolog-II can be considered as equivalent to the interpreted version of Warren’s Abstract Machine, except for the use of structure sharing (see chapter 7), and the addition of thedif/2andfreeze/2predicates of Prolog-II (see chapter 10). Of course, Mini-Prolog-II will benefit from the clauses indexing...

      (pp. 237-246)

      This chapter is relevant to the three versions just implemented. For the sake of homogeneity, an identical management of the built-in predicates has been chosen for the three implementations. Each version has its own built-in predicates (with a common part for Mini-CProlog and Mini-Prolog-II due to their common representation of terms). Moreover, each implementation has its own initialization file, which contains a set of utilities, themselves written in Prolog. The presentation will always refer to Mini-Prolog-II.

      The built-in predicates can be classified into many different classes, depending on their purpose: I/O, control, arithmetic, type conversion, tests, term comparison, dynamic management...

    (pp. 247-250)

    Research aimed at the design of machines dedicated to the execution of sequential Prolog has grown worldwide since the beginning of the 1980s. Among the various proposed designs, we retain the following two, which differ in their goals and thus in their approach toward the implementation of Prolog:

    1. the PSI machine (Personal Sequential Inference) developed in the context of the Japanese fifth-generation project is specialized in the execution of Prolog. The PSI machine uses a classical memory management and architecture inspired by D. H. Warren’s works.

    2. the MALI machine (Machine Adaptée aux Langages Indéterministes), developed at the IRISA...

    (pp. 251-257)
    (pp. 258-270)
    (pp. 271-281)
    (pp. 282-289)
    (pp. 290-299)