compositional operational semantics for prolog programs

New Generation Computing, 10 (1992) 315-328 OHMSHA, LTD. and Springer-Verlag

�9 OHMSHA, LTD. 1992

Compositional Operational Semantics for Prolog Pro- grams

M. H. M. C H E N G , R. N. HORSPOOL, M. R. LEVY, and M. H. van

E M D E N Department o f Computer Science, University o f Victoria, P. O. Box 3055, Victoria, BC, Canada V8W 3P6

Received 5 August 1991 Revised manuscript received 16 December 1991

Abstract To relate operational semantics of logic programs to its declarative semantics, we have to rely on SLD-trees. But this form of operational semantics does not make it easy to relate execution behaviour to program structure. The reason is that the traversal of SLD-trees decomposes in a way that is different from the decomposition (which is by disjunction and conjunction) of programs.

We propose SLD-contours, a variant of SLD-trees, that are, like programs, built up out of simpler components by means of disjunction and conjunction. The traversal of SLD-trees carries over to the traversal of SLD-contours in such a way that the trace events of the Box Model (Try, Succeed, Retry, Fail) are reproduced in the same way as during the execution of the program. Thus SLD-contours relate the trace more closely to the program than SLD-trees. SLD-contours specify the trace more completely than the Box Model does.

However, SLD-contours have the disadvantage that similar constructs are repeated. We introduce a way of collapsing repeated occurrences into a single one. The result is an elaboration of the existing Box Model. Hence we call them SLD-boxes. In this way, SLD-boxes connect the semantics of Prolog programs to the Box Model, the most widely used aid in tracing Prolog programs.

Keywords: Box Model, Compositionality, Cut Operator, Debugging, Prolog Exe- cution, Operational Semantics, SLD-Trees, Tracing.

3t6 M.H.M. Cheng, R. N. Horspool, M. R. Levy, and M. H. van Emden

w 1 Introduct ion 1 . 1 W h y Trace Logic Programs ?

According to a certain purist view there is no need to trace logic programs: if you make sure that your program contains only true assertions about the relations that you need, then you cannot get a wrong answer. According to this view, any urge to trace is only a symptom of a lack of understanding of the proper method. This view is wrong because we not only want to avoid wrong answers, but we also want to make sure we do get an answer, or all answers, as the case may be. On this latter aspect, only recently is some theory starting to emerge, and it is not yet clear what, if any, is ready for practical application by the Prolog programmer. In the meantime, tracing remains important.

Another reason why logic programs need tracing is the same reason why specifications need debugging: people are sometimes mistaken when they think they have written a complete set of true assertions. Of course they shouldn' t make mistakes, but they do. Then what ? In casting about for something reasonable to do in such a situation, tracing the execution is often the only alternative to just fretting. And tracing is often extremely effective.

1 . 2 How Are Traces Justified by Semantics ? It is, of course, crucially important that the trace produced by a Prolog

implementat ion be correct. Tha t is, the trace should be based on the semantics of Prolog programs. In practice, the trace mechanism is built into the Prolog engine and its correctness depends on that of the Prolog engine. So the question of the correctness of traces can be reduced to that of the correctness of a Prolog interpreting or compiling algorithm. The latter is covered in Ref. 13).

1 . 3 Compositional Semantics Is the Most Useful Variety for Tracing In Ref. 13) the correctness of the Prolog engine is based on traversal o f

SLD-trees. Because of the purpose for which traces are used, SLD-trees do not provide a satisfactory basis for correctness of traces, as we will now explain.

Without tracing, the Prolog engine only produces the final result, the answer substitution. The trace should help the programmer understand how the final result is obtained. This understanding can only be based on a relation between the program's structure and the trace. The program is built out o f components by the operations of disjunction and conjunction. Therefore, the trace should also be understood in terms of decomposi t ion by disjunction and conjunction.

The problem is that SLD-trees are not composed out of smaller SLD- trees, by means of disjunction and conjunction, in the same way as programs are. We express this by saying that the operat ional semantics based on SLD-trees only is not compositional. In this paper we describe SLD-contours, a variant o f

Compositional Operational Semantics for Prolog Programs 317

SLD-trees that are, like programs, built out of simpler components by means of disjunction and conjunction. Hence SLD-contours provide a composi t ional operat ional semantics for Prolog programs.

The traversal of the SLD-contour of a program is a sequence of events that we denote by Try, Succeed, Retry, and Fail. These are the same events that are reported by the usual trace facility of Prolog implementations based on Byrd's Box Model. Of course, a more complete trace is obtained by attaching to each Box-Model event the associated substitution. In this paper we omit these substitutions, al though our approach supports such more extensive tracing equally well. After all, the Box Model has gained wide acceptance while also withholding the substitutions associated with the trace events.

1 . 4 The Results of This Paper The first result of this paper is that we connect traces to the semantics of

Prolog programs. This connection is established in several steps. The first step is the well-known connection between semantics (model-theoretic or fixpoint) and SLD-trees. 3a) The second step is established in this paper: between SLD- trees and SLD-contours. We also take the final step which consists in showing that traversal of an SLD-contour gives a trace, which is a sequence of Box-Model events. We believe that such a trace is always the one yielded by the trace facility of a Prolog implementation. Indeed, the several examples we have examined are consistent with this belief. I~ut we cannot be sure whether this is always the case, as traces are not explained by Byrd's Box Model. This model only identifies the four events: Try, Succeed, Retry, and Fail. It does not justify how traces are built up from these events. Such a justification is provided in this paper.

SLD-contours have the disadvantage of containing repeated constructs. The second result of this paper is an improvement of the SLD-contour that consists of collapsing the repetitions into a single occurrence. The result, which we call the SLD-box, has the same traversal as the original SLD-contour. Hence the SLD-box specifies a trace as well. The new construct has this name, because it turns out to be a refinement of Byrd's Box Model. Thus we have connected the Box Model to the semantics of logic programs and in the process found a composi t ional operational semantics.

1 . 5 Implications for Prolog Implementation In Ref. 13) an interpreting algorithm for Prolog programs was based on

SLD-tree traversal. The work in this paper suggests that a Prolog engine be based on SLD-tree traversal (this should be preserved as it gives the semantic justification), but, unlike Ref. 13), via SLD-boxes. We found that this approach is a natural one for object-oriented programming. We have used it to develop a hybrid system (reported elsewhere 7)) that allows Prolog code to co-exist with C ++ code, neither language being subordinate to the other.

318 M.H.M. Cheng, R. N. Horspool, M. R. Levy, and M. H. van Emden

1 . 6 Related Work The operational semantics of Prolog derives from two sources. Kowalski

first described 8~ what is now called SLD-resolution. Colmerauer, in defining and implementing Prolog, determined the special case where search is depth-first from left to right and where goal selection always proceeds from left to r ight ) ) The earliest aid in tracing Prolog programs is Byrd's Box Model. 2) It has recently been elaborated into the Box and Plane Model of Numao, Morishita, and Maruyama. 1~ Eisenstadt and Brayshaw 6) have used a n d / o r trees as a basis for an aid in tracing.

As it stands, Byrd's Box Model is very much underused. The existing exposit ions follow Byrd's paper z) in translating the situation of a procedure A calling procedure B to the box for A containing the box for B. But no more structure is represented than that. Numao et al. 1~ take an additional step: by introducing planes as larger entities that can contain several boxes, they give a graphical representation of the definition of the procedure as a disjunction of conjunctions. The result is a version of the Prolog SLD-tree. As will become clear in this paper, it is possible to extend the Box Model to a version of the And-Or tree of the program.

w Shortcomings of the SLD-Tree as Model of Prolog Execut ion The operational semantics of Prolog is given, in principle, by depth-first,

left-to-right traversal of the SLD-tree determined by selecting the leftmost goals. Thus the SLD-tree by itself is not sufficient for operat ional semantics: we should consider the tree in conjunction with the traversal line. Along this traversal line we have a choice of what information to include. The Box Model chooses to neglect information about substitutions. In this paper, as a first step, we follow this choice. Thus, in this section, we consider how to obtain a trace of Box- Model events from traversal of the SLD-tree. But it may be necessary to review the Box Model first.

2 . 1 Review of the Box Model Most Prolog implementat ions provide a debugger that reports execution

events in terms of Byrd's Box Model. This model identifies the two ways in which control can enter and the two ways in which control can leave a Prolog procedure. According to the Box Model, a procedure is symbolized by a rectan- gular box with four one-way ports, each with an arrow indicating whether control enters or leaves by that port. See Fig. 1.

In this paper we will refer to the entry ports as Try and Retry; to the exit ports as Succeed and Fail. During an attempt to solve a goal for the first time, control enters the box for the corresponding procedure by the Try port. In case of failure, control exits via the Fail port. In case of success, control leaves by the Succeed port. In the latter case, subsequent failure elsewhere may cause the procedure to be reactivated and then control enters by the Retry port. A Box


Model event is the event of passing through a port. The events are named by the

name of the port together wi th the procedure to whose box the port belongs. A

t ra ce is then a sequence of Box Model events, ordered as they occur in time. See

Fig. 2 for an example trace in terms of Box Model events.

It is clear from descr ipt ions of the Box Mode l that a box typical ly

con ta ins another box. The outer box symbolizes a procedure call; usual ly this

needs for comple t ion a successful act ivat ion of a procedure. This later ac t iva t ion

is symbol ized by the inner box. See Fig. 1. A l t h o u g h both the outer and inne r

boxes have ports, Byrd's o r ig ina l paper 2) does no t connec t these; nor do most of

the derivative descript ions typical ly found in textbooks or Prolog manuals . As

Fig. 1

a :-b a Try I - ]'ucceed I - . b ~ ~

~Fail " Retry

= I

On the left the conventional position of the box port. On the right an example of a procedure calling a procedure resulting in nested boxes. Note how, in the conventional Box Model, the ports are not connected.

Program: a:- e. a: c. b: f. b:- g. c. c:- d. f:- h. f: i. i. g. d.

Trace from query ?- a,b. 1 Try a 16 Retry f 2 Try e 17 Retry i 3 Fail e 18 Fail i 4 Try c 19 Fail f 5 Succeed c 20 Try g 6 Succeed a 21 Succeed g 7 Try b 22 Succeed b 8 Try f 23 Retry b 9 Try h 24 Retry g 10 Fail h 25 Fail g 11 Try i 26 Fail b 12 Succeed i 27 Retry a 13 Succeed f 28 Retry c 14 Succeed b 29 Try d 15 Retry b 30 Succeed d

31 Succeed c 32 Succeed a repeat steps 7-26

Fig. 2

l ? ~ b

':;7' < \ \

?h I ?-i, \1~1--?-* (

t ~ l t I-I ) ~h7 ( L'~l,'~ /[dq~

Traversal of an SLD-tree is only part of the corresponding trace. Note the gaps 4-7, 14-20, and 22-28. Successful and failed nodes are indicated by showing as descendant a success symbol ( [] ) or a failure symbol (a cross), respectively.

320 M. H. M. Cheng, R. N. Horspool, M. R. Levy, and M. H. van Emden

a result, although the original Box Model was intended for tracing, it fails to specify what a trace is. The first publication we know that does connect the ports o f nested boxes is Schnupp and Bernard's text. ~z~ A similar method is followed in Ref. 5).

A part of our contr ibution is that we relate the trace, defined by connecting the ports of nested boxes, to the standard of the operational semantics of Prolog. We first briefly review this standard and then explain why it is itself not adequate as a basis for tracing Prolog programs.

2 . 2 Shortcomings of SLD-Trees The basis of the operat ional semantics of Prolog is an SLD-tree deter-

mined by the initial query and the program and by a rule that selects a goal in each query in the SLD-tree. The Prolog SLD-tree is the one where in each query the leftmost goal is selected. The operational semantics of Prolog is then completed by specifying that this tree is traversed depth-first from left to right.

This formulation of the operational semantics is fundamental because it connects conveniently to the declarative semantics (model-theoretic and fixpoint) of Prolog) ) It is also important because it goes a long way towards providing a basis for implementation.

Even as a method of tracing, SLD-trees deserve consideration. The tree together with the traversal line corresponding to the depth-first left-to-right strategy constitute a tracing model; see Fig. 2. Most o f the Box Model events can be placed there in a natural way. Therefore the SLD-tree with traversal line is a serious candidate as a model for tracing. This is all the more so as the SLD-tree itself (together with its derivations) is used for proofs of theorems stating the correctness and completeness of pure Prolog.

Yet there are shortcomings. We mention two:

The traversal line of an SLD-tree skips certain segments of the trace; see for example Fig. 2. A complex SLD-tree is not the result of composi t ion of simpler SLD- trees. For example, both for purposes of theory and for tracing, it would be preferable if the SLD-tree for the query ?- a,b were a clearly recogniz- able composit ion of the SLD-trees for ?- a and for ?- b. This is not the case, but it is true of the constructs that we will derive from SLD-trees: SLD-contours and SLD-boxes.

w SLD-Contours The shortcomings of SLD-trees can be overcome. We first show how a

small modification of the SLD-tree diagram together with the traversal line combine to give a complete trace in terms of the Box Model events Try, Fail, Succeed, and Retry.

Consider Fig. 3 where we show one of the subtrees of the SLD-tree in Fig.


Program: a: e. a:- c. b:- f. b: g. c. c:-d. f: h. f: i. i. g. d.

Trace from query ?- b. 7 Try b 17 Retry i 8 Try f 18 Fail i 9 Try h 19 Fail f 10 Fail h 20 Try g 11 Try i 21 Succeed g 12 Succeed i 22 Succeed b 13 Succeed f 23 Retry b 14 Succeed b 24 Retry g 15 Retry b 25 Fail g I6 Retry f 26 Fail b

Fig. 3

t g

An SLD-contour. Note that every Box-Model event now corresponds to a crossing of the traversal line with a contour, and vice versa.

2 and its traversal line. In add i t ion we have d rawn a con tour a round every

SLD-tree except that the success leaves prot rude from the contour . Not ice that

the left success leaf is no t on ly a success leaf of the tree rooted in i bu t also one

for the trees rooted in f and b. Thus the edge of the tree to this success leaf crosses

three contours .

Now consider the places where the traversal l ine crosses a contour . A n

entry crossing near the top we call Try; an exit crossing near the top we call Fail. A n exit crossing near a success leaf we call Succeed; and entry crossing nea r a

success leaf we call Retry. W h e n we now follow the traversal line, the sequence o f contour crossings is a complete trace.

This example i l lustrates SLD-contours, our model for ob t a in ing complete

traces of Prolog execut ion in a way that derives from SLD-tree traversal, the

s tandard by which the ope ra t iona l semantics of Prolog is defined.

More precisely, and SLD-con tou r for a s ingle-goal query ?- G consists of

two components :

The first c o m p o n e n t is a closed con tour with an entry and exit port called

Try and Fai l and a pair of exit and entry ports for each of the zero or

more successes possible for the given goal G. The latter are called Succeed

and Retry, respectively.

The second c o m p o n e n t of an SLD-con tou r is the traversal line, a l ine

322 M . H . M . Cheng, R. N. Horspool, M. R. Levy, and M. H. van Emden

connecting the Try port to the first Succeed port, if any, a line connecting every Retry port to the next Succeed port, if any, and a line connecting the last Retry port, if any, to the Fail port. These connecting lines are typically partly made up o f traversal lines of component SLD-contours.

SLD-contours are primitive or composite. The primitive SLD-contours are of two kinds: Success and Failure. The primitive SLD-contour Success represents a query that succeeds immediately (i.e., it derives the empty query [~). It has one Succeed and one Retry port. Its Try port is connected directly to the Succeed port, and the Retry port is connected directly to the Fail port, The primitive SLD-contour Failure represents a query that fails immediately (i.e., it derives the failure symbol X) . It has no Succeed or Retry port. Its Try port is connected directly to its Fail port.

All composite SLD-contours are composed of other SLD-contours in two different ways: by disjunction or by conjunction.

3 . 1 Disjunction of SLD-Contours As shown in Fig. 5, the disjunction C of SLD-contours C1 .... , C~ is an

SLD-contour. We define C by defining its two components.

The traversal line of C is obtained by connecting the Try port of C to the Try port of C1, by connecting, for i = 1 ..... n -- 1, the Fail port of C~ to the Try port of Ci+l, and by connecting the Fail port of Cn to the Fail port of C. The contour of C is the smallest contour containing the contours of C1 ..... Cn, but not their success leaves.

The disjunction operat ion is related in an obvious way to the logical connective of the same name. Note, however, that the disjunction of SLD- contours is not commutative. See Fig. 4.

\ !

c

Fig. 4 Disjunction of SLD-contours.


C=A,B

Fig. 5 Conjunction of SLD-contours.

3 . 2 Conjunction of SLD-Contours So far, we have only defined SLD-contours for single-goal queries. To

model the trace resulting from a conjunction of goals as in a condit ion or in a query, it is necessary to perform the conjunction operat ion on SLD-contours. The conjunction C of the SLD-contours A and B is an SLD-contour. C is defined by defining its two components, as follows:

The traversal line of C is obtained by attaching a copy of B to each of the zero or more Succeed-Retry pairs of A, in the following way: connect the Succeed port of the selected pair of A to the Try port of the copy of B and connect the Fail port of the copy of B to the Retry port o f the selected pair of A. The contour of C is the smallest contour containing A and the copies of B, but not the success leaves of the copies of B.

We write C = A , B for the conjunction of SLD-contours A and B. Note that, in spite of what the name may suggest, conjunction of SLD-contours is neither associative nor commutative. The lack of associativity seems to be mostly a formality. Although P, (Q, R) and (P, Q), R and different SLD-contours, their traversal lines specify the same trace.

To model the behaviour of a multi-goal query, one uses a conjunction of SLD-contours. The trace of a query with goals a~, ..., an is the sequence of events associated with the traversal line of the SLD-contour resulting from the conjunction of a~, ..., an, in that order, according to the way they are associated. Thus the primitive SLD-boxes, together with the operations of conjunction and disjunction, completely specify traces of programs in pure Prolog. We will treat cuts in a later section.

324 M.H.M. Cheng, R. N. Horspool, M. R. Levy, and M. H. van Emden

w S L D - B o x e s Byrd's Box Model 2) does not explicitly specify the trace that it is intended

to help understand. It is also not clear how it relates to SLD-tree traversal, which forms the basis of Prolog's operat ional semantics. SLD-contours are an improvement in that they are closely related to SLD-trees and specify the trace as the succession of ports along the traversal line of an SLD-contour.

What more can one ask? Well, there is still a problem: conjunction may require copying many identical SLD-contours. We propose to avoid this problem by merging all Succeed-Retry pairs (if any) into a single pair. The merging implies a fan-in when passing through the merged Succeed port and a fan-out when entering through the merged Retry port. When a trace line leaves through a Succeed port, the port identity must be retained, so that the corresponding Retry port can be selected when the next conjunct fails. The memory required to retain the port identity is symbolized by a long narrow bar inserted between the possibly many Succeed-Retry pairs of the SLD-contour and the single pair in the modified version of SLD-contours. See Fig. 6 for our graphical notat ion for the memory.

It will not have escaped the reader's notice that with this modification of the SLD-contour we have re-invented the box of the Box Model. All that remains to be done is to turn the modified SLD-contour on its side. We call the result an SLl)-box. The similarity to the Box Model is no coincidence. We

Fig. 6

T F

Try

Fail

I

Succeed

~ t r y

SLD-box is SLD-contour with memory. Top left: example SLD-contour with two Succee~ Retry pairs of ports. Top right: SLD-box version of same. Bottom: the same SLD-box, bl rendered in a shape and position suggested by the usual notation for Byrd's Box Model.


accept the requirement that a trace o f Prolog execution must be a sequence o f

Box Model events: Try, Succeed, Retry, and Fail. In the process o f our re- invent ion we have added the traversal line, so that the SLD-box model explicit ly specifies the trace. In addi t ion, SLD-boxes are an alternative nota t ion for

SLD-trees. Just as is the case with SLD-contours , there are primitive SLD-boxes and

compos i te SLD-boxes that can be composed by con junc t ion and by disjunction. For the purpose o f the definition, as SLD-box is to be regarded as an SLD- con tou r with a single Succeed-Retry pair o f ports. The difference between the

two concepts is the memory, which is internal to the SLD-box, hence does not affect the definition. So the definitions for SLD-con tours carry over to corre- spond ing ones for SLD-boxes. See Fig. 7 for a con junc t ion o f two SLD-boxes,

each o f which is a disjunction. This still concerns the proposi t ional case.

Program: a:- e. a:- c. b:- f. b: g. c. c: d. f: h. f:-i. i. g. d.

a b

e

C

_S

h !

,[ . i

J

Fig. 7 Example trace in the form of SLD-boxes.

4 . 1 U n i f i c a t i o n B o x e s

In the nonpropos i t iona l case we have to take into account unification between the goal and head arguments. The unificat ion o f a goal and the head

can either succeed or fail; it can never be retried. Hence, unification is a box with on ly three ports: Try, Succeed, and Fail. Accordingly , we show unification boxes as triangles. See Fig. 8 for the generic example.

For each clause H ~-C1 ..... Cn, there is a unification box U con ta in ing Ha , where ~7 is a suitable renaming substitution. Let G be the curr~nt goal and

8 the current substitution. Let 7 be the most general unifier o f G8 and Ha . I f A is the SLD-box activated by G, then

3 2 6 M. H. M. Cheng, R. N. Horspool, M~ R. Levy, and M. H. van Emden

C, " A , - BI.~ ..... t?,,~,

C,. " A ~ B . ~ B . . . .

] U, B~. L

~ i .C. U2

. . .

/ ; u , 8m.~ k 0 A 0~ : . . . - -1-~

;0 f "

B l , n l

B...~

[ I

,liP---

, j

0,

0,

Fig, 8 SLD-boxes for unrestricted Horn clauses. Note unification boxes U~, ..., U,~.

the box events of A are: Try 0, Succeed O~, Redo 0n, and Fail 0. for each unification box U inside A with head H a , this box's events are:

Try 0, Succeed 7, and Fail 0.

w Effect of Cut in S L D - B o x e s If a tracing method is to help in understanding the execution of Prolog

programs, it should help in particular when cuts are encountered. T h i s is not the case for the Box Model. We believe SLD-boxes to be an improvement in that respect.

The problem with the cut is that it is at times necessary to give Prolog programs acceptable efficiency. But its action seems to be determined for the

implementer's convenience rather than the programmer's. The cut is not only simple to implement; it is also simple to define. We take as authoritative the definition of Colmerauer and Roussel, m which goes as follows.

Suppose the cut is selected as goal in a query Q that is a node in

an SLD-tree. This goal succeeds with the side effect of removing from the SLD-tree all untraversed subtrees that have as roots ancestors of Q up to and including the parent of the query where the cut first appeared.

Simple enough to say and remember. Hard to translate to the act of program ming. We find the cut much easier to work with when visualizing it by mean


Q Q

o

I ( A = _ _ L . . . - L I

Fig. 9 The effect of the cut is the short circuit in the traversal line indicated by the dotted line.

o f SLD-boxes, as shown in Fig. 9.

Acknowledgements We are grateful to the referees for suggestions for improvement . Generous

suppor t was provided by the British Co lumbia Advanced Systems Institute, the Na tu ra l Science and Engineer ing Research Counci l o f Canada, the C a n a d i a n Insti tute for Advanced Research, the Institute o f Robot ics and Intell igent

Systems, and the Labora to ry for Automat ion , C o m m u n i c a t i o n and In fo rmat ion

Systems Research.

R e f e r e n c e s 1) Apt, K. R. and van Emden, M. H., "Contributions to the Theory of Logic Program-

ming," Journal of the ACM, 29, 3, pp. 841-862, 1982. 2) Byrd, L., "Understanding the Control Flow of Prolog Programs," in Logic Program-

mign Workshop, Proceedings of the Workshop in Debrecen, Hungary, 14-16 July 1980, pp. 127-138, 1980.

3) Clark, K. L., "Predicate Logic as a Computational Formalism," Technical Report, DOC 79/59, Department of Computing, Imperial College, 1979.

4) Colmerauer, A., Kanoui, H., Pas6ro, R. and Roussel, P., "Un syst~me de communica- tion homme-machine en fran~ais," Technical Report, Groupe d'Intelligence Artificielle, Universit6 d'Aix-Marseille II, 1972.

5) Delrieux, C., Azero, P. and Tohm6, F., "Toward Integrating Imperative and Logic Programming Paradigms: A WYSIWYG Approach to Prolog Programming," A CM S1GPLAN Notices, 26, 3, pp. 35-44, 1991.

6) Eisenstadt, M. and Brayshaw, M., "Graphical Debugging with the Transparent Prolog Machine," in Proc. lOth International Joint Conference on Artificial Intelligence, 1987.

328

7)

M. H. M. Cheng, R. N. Horspool, M. R. Levy, and M. H. van Emden

Horspool, R. N. and Levy, M. "Integrating Imperative and Logic Programming," unpublished manuscript, Department of Computer Science, University of Victoria, 1991.

8) Kowalski, R. A., Logic for Problem-Solving, Elsevier North-Holland, 1979. 9) Lloyd, J. W., Foundations of Logic Programming, 2nd edition, Springer-Verlag, 1987.

10) Numao, M., Morishita, S. and Maruyama, H., "How Should Prolog Computation Be Represented for Practical Use ?," New Generation Computing, 8, 1990.

11) Roussel, Ph., "Prolog, manuel de r6f6rence et d'utilisation," Technical Report, Groupe d'Intelligence ArtificieIle, Universit6 d'Aix-Marseille H, 1975.

12) Schnupp, P. and W. Bernard, L. W., Productive Prolog Programming, Prentice Hall, 1987.

13) van Emden, M. H., "An Algorithm for Interpreting Prolog Programs," in Implementa- tions of Protog, El/is Horwood, pp. 93-110, 1984.

compositional operational semantics for prolog programs

Documents