Source-to-source optimizing transformations of Prolog programs based on abstract interpretation

Source-to-source optimising transformations of Prolog programs based on abstra ct in terpreta tion F ran¸ cois Gob ert and B audouin Le Cha rlier Universit ´ e Catholique de Louvai n, Belgi um, { francois .gobert,ba udouin.lecharlier } @uclouvain.be This w o rk is sup p orted b y the Belgian FNRS fun d. Abstract. Making a Prolog program more efficient by transforming its source code, without changing its op erational semantics, is n ot an ob- vious task. It requires the user to have a clear understanding of how the Prolog compiler w orks, and in particular, of the effects of ‘impure’ features like the cut. The wa y a Prolog code is written - e.g., th e order of clauses , the order of literals in a clause, the use of cu ts or negations - influ ences its effici ency . F urthermore, different optimisation t ec hniques ma y b e redundant or conflicting when they are applied together, dep end - ing on th e wa y a p rocedu re is called - e.g., inserting cuts and enabling indexing. W e present an optimiser, based on abstract interpretation, th at automatically p erforms safe co de t ransformations of Prol og p rocedu res in t he context of some cla ss of input calls. The met h od is more effective if pro cedures are an n otated with additional information ab out mo des, types, sharing, num b er of solutions an d t he lik e. Thus the approac h is similar to Mercury . It applies to an y Prolog program, ho wev er. Keywords. Abstract interpretatio n , automated optimisation, cut inser- tion, logic programs, Prolog, source-to-source program transformation, static analysis. 1 In tr o duction Progr amming in Pro log a llows us to write so-called multidir e ctional pro cedures, in the sense that the sa me co de of a pr o cedure ca n b e used in more than one wa y (the arguments b eing either input da ta or output re s ults). The undesirable consequence fo r multidirectionalit y is inefficiency (in terms o f space utilisa tion and o f executio n time). This efficiency issue comes from the genera l execution mo del of Prolo g , which is generally ba sed on the W ar ren’s Abstract Machine (W AM, f or short) [1, 14]. Answer subs titutions are computed according to a depth-first sear ch stra tegy with backtracking, where clauses ar e executed from top-to-b ottom, a nd liter als a re executed from left-to-right inside a clause. Giv en the incompleteness of Pro log, so me input-output patterns can lo op. Also, Pro lo g uses a gener al algor ithm for unification, with no restric tio n on the ter ms b e- ing unified, but most co mpilers do not perfo rm the o ccur-chec k tes t dur ing the unification. F or efficiency reas ons, some built-in pro cedures are not m ultidir ec- tional (for example, a rithmetic and comparison predica tes). Negation as failure is sound only if it applies to a gr ound liter a l. Due to the incompleteness and unsoundness of P rolog , not ev er y o rdering of claus es and litera ls is op er ationally correct, and the wa y a pro ce dur e is written gr eatly influences the s e a rch o f its solutions, and then, the efficiency . A solution for optimising multidirectional pro cedures is to g enerate sp e - cialised co de for e a ch particular use o f the pro cedure. In the co ntext of a di- rectionality , one can try to find a more efficient ordering of clauses and liter als, such that the pr o gram s till rema ins op er ationally co rrect for that direc tio nal- it y . In Prolog , we can also try to insert cuts to prune the s e arch tree without removing solutions. This can grea tly reduce the size of the search tre e , and im- prov es the efficiency . Applying cor rect co de transfor mations is not ob vio us and is tricky to b e done manually , be cause it is very error -prone. This pap er de- scrib es an o ptimiser ba sed o n abstr act interpretation, which rea lizes this task automatically . T o illustr ate the in terest o f sp ecia lising co de, co nsider the mutidirectional pro cedure efface(X ,T,TEf f) , which is the running example of [6]: X is an ele- men t of list T , and TEff is the list T witho ut the firs t o ccurrence of X in T . efface (X,[H |T],[H|T Eff]) : - efface (X,T,T Eff), not (X=H) . efface (X,[X |T],T). This co de ca n b e used in several wa ys: either when every input argument is a ground term; or when inputs X and T are ground and TE ff is a v aria ble; or when inputs X a nd TEff ar e g round and X is a v ariable; or when inputs X and TE ff are v ariables and T is ground; etc. No w, if we consider only the first directionality , then our optimiser will b e able to automatically gener ate the following specialise d co de (the optimiser has chec ked that the pr o cedure is deter ministic for this directionality): efface (X,[X |T],T) :- !. efface (X,[H |T],[H|TEff]) :- efface (X,T, TEff). The clauses ar e r eordered, a cut has be e n inserted in the first clause, a nd the negation is remov ed. F or a ll inputs sa tisfying the fir st directionality , the se - quences o f ans wer substitutions of the sp ecialised and of the multidirectional co des are identical. T able 1 compares the execution b etw ee n the multidirec- tional and the sp ecialised co des. Several tests hav e b een p erformed by v arying the list-length of the input list T . The ta ble shows that the multidirectional co de is less efficient than the sp ecialised one in terms of executio n time a nd of used lo cal stack. In particular , the s p ecia lised c o de uses a co nstant amoun t of lo cal stack (independently of the siz e o f the input), while w e yield a loc a l s ta ck error if we try to ex ecute the multidirectional co de with an input list of size 250 00. The sp eedup increases according to the size of the input: for instance, the optimised co de sp ent 3.61 times less execution time for a n input list of size 10000 . Our appro ach is s trongly inspired b y [6], wher e a metho do logy to build cor- rect pro grams is prop osed: sta rting from a spe c ification and a s o-called lo gic description of the pr o blem, the metho dology co ns tructs op era tionally correct progra ms which ar e not written in the usua l s t yle of exp erienced Pr olog pr o- grammers : pro ce dures are normalis ed, with explicit unifications , and are thus Input Execution Time (ms) Used Local Stack (By) list Multidirectional Optimized Multidirectional Optimized size (ms) (ms) (sdup) (By) (By) 100 71 25 2.84 8508 108 1000 693 225 3.09 84108 108 10000 8176 22 64 3.61 840108 108 25000 ERROR 5633 - ERROR 108 T able 1. Program efface(X,T ,TEFf) executed 1000 times, when X is a ground term, T is a ground list, and TEff is a v ariable. The program has b een tested on a 1.5 Ghz P en - tium; 1Gb RA M; Linux Suse; SWI-Prolog v 5.4.6 [15]. The size to which the local stack is al lo wed to gro w is 20 48000 By . inefficient . The author of [6] then prop oses to a pply some c o de transformations, in or der to pro duce more efficient pro grams (written in the usual s t y le and where cuts a re introduced). It is not obvious to ensure the correct application of trans- formations, nor to choose the best o rder to apply them. Our optimiser does not require or assume that Pr olog pro grams are wr itten in a sp ecia lised syntax. It accepts any kind o f Pr olog programs. So, the progra mmer has the lib erty to wr ite its progra m in the style he wan ts: no rmalised or no t. O ur optimiser then auto - matically sp ecialises the program for some directio nality , b y c ho o sing a suitable order for applying the transformatio ns, and by ensuring that the tra nsformations are cor rectly applicable. The transfo rmations pe rformed by the system a re related to pa rtial ev al- uation: liter als are ev alua ted at compile-time, such that so me of them can be remov ed, and some unifications ca n b e simplified. How ever, we do no t unfold pro cedure ca lls as it is norma lly done in pa rtial deduction. The optimiser is based on an abstract interpretation framework [3, 10, 11], that collects and verifies the semantic informa tion needed for corr e ct applica- tion o f source- to-source transformations . The op era tional prop erties ca tc hed and verified b y the framework that a re useful for the purp os e of the optimiser are: cardinality information (including determina c y a nd conditions for sure success and failure), detection of the exclusiv it y betw een clauses, information ab out the mo de, t yp e, shar ing, linearit y , and size of input/output terms, occur-check free- ness, and induction parameters for pr oving ter mination. The rest of the pape r is org anised as follows. Section 2 presents the source- to-source transfor mations w e apply o n Prolo g pr o grams, and sp ecifies the co n- ditions for applying correctly such trans formations. Se c tion 3 describ es briefly the abstract interpretation framework. F or ma l sp ecificatio ns are introduced, to allow the user to ex press the directio nality for whic h the co de must b e o ptimised. Section 4 illustr ates in which order the tra ns formations a re applied. Section 5 rep orts on e x per iment al results, a nd Section 6 pr esents the related work. 2 Source-to-source T ransformations Optimisation is carried out by means o f transfor mations based on the o pe r a- tional semantics of Pro log. Section 2.1 describ es the Pro log programs acce pted by the ana lyser, a nd the syntax of normalise d progr ams, on whic h most co de transformatio ns a re applied. Section 2.2 introduces the concept of se quenc e of answer substitut ions , that allows us to describe the sufficient conditions for a p- plying corr e ct source- to-source tr a nsformations. Section 2.3 defines s ome seman- tic pr op erties that c har acterise sequences of answer substitutions. Such prop er- ties are undecidable, but can be safely a pproximated by our framework. Finally , Section 2.4 pre s ent s the tra ns formation rules. 2.1 Prolog Synta x The optimiser accepts any Pro log prog r am that is ISO confor mant, with sp ecial features lik e the cut and the negation, as w ell as constructs of the for m ; (dis- junctions) and - >; (if then else). The abstract in terpre tation framew o rk of the optimiser is designed on normalise d progr ams, and most co de tr ansformations apply on s uch prog rams. A norma lis ed pro cedur e pr is a no nempt y sequence of cla uses c . Each normalised cla use c has the form h :- g where the head is of the form p ( X 1 , ..., X n ), whereas the b o dy g is a possibly empt y seque nc e of nor- malised literals. A norma lis ed literal is either a built-in o f the form X i 1 = X i 2 , a built-in of the form X i 1 = f ( X i 2 , ..., X i n ), a pro ce dure call p ( X i 1 , ..., X i n ), a cut !, or a nega tion not ( l ), where l is a normalis ed literal. The v ariables o ccurring in a literal are all distinct; all cla us es o f a pro cedure hav e exactly the s ame head; if a c la use uses m different v aria bles, these v ariables are X 1 , ..., X m . O bserve that all Prolog program can b e rewritten int o equiv alent normalised pro grams. In the r est of this pa per , P denotes the g iven normalised progr am. 2.2 Sequence of Answ e r Substituti ons Semantically , a norma lised pro cedur e pr ca n b e v iewed as a function mapping every input s ubstitution θ to a sequence of answer subs titutions S . A subs titu- tion θ is a finite set of the form { X 1 /t 1 , ..., X n /t n } where X 1 , ..., X n are dis tinct progra m v ariables , and where t 1 , ..., t n are terms (v ar iables occ ur ring in terms a r e standar d v aria bles; the sets of s tandard and pro gram v ariables a re disjoint). A sequence of answer substitutions S ca n be either finite < θ 1 , ..., θ k > ( k ≥ 0), o r infinite < θ 1 , ..., θ k , ... > ( k ∈ N ), or incomplete < θ 1 , ..., θ k , ⊥ > ( k ≥ 0 ), where the symbol ⊥ deno tes that the pr o cedure lo ops. T o e xpress this b ehaviour, w e use the notation of [1 1]: h θ , pr i 7→ P S for a pro cedure, h θ , c i 7→ P S for a cla us e, and h θ , g , c i 7→ P S for a prefix of a c lause. In the rest of this pap er, w e a s- sume that each pro cedur e terminates. Thus, we o nly consider finite sequences of a ns wer substitutions. O ur optimiser is ba sed on the abstract in ter pretation framework defined in [10], that uses induction para meters to verify that a proce- dure terminates . Notice that every pro cedure of our b enchmarks terminates. The substitutions of S are denoted by Subst ( S ), and the length o f S is denoted by | S | . 2.3 Seman ti c Prop ertie s This sectio n defines some se mant ic pro p er ties that characterise the execution of literals, prefixes of the b o dy of a clause, clauses, procedur es, in ter ms of the length of their sequence of a ns wer substitutions. Suc h prop erties are useful to express the sufficient conditions to apply safely the code transformations. Let pr b e a pro cedure of arity n , let c b e a clause of the pro cedure pr , let ( g , l ) b e a prefix of the clause c , where g is a g oal and l is a literal. Let θ b e a n input pr ogra m substitution with domain { X 1 , ..., X n } . Co nsider the execution of the pro cedure h θ , pr i 7→ P S pr , the execution of the clause h θ , c i 7→ P S c , the execution of the prefix of the clause h θ , g , c i 7→ P S g . Assume that the literal l is of the for m q ( X i 1 , ..., X i r ). The execution of the literal l after the execution of the goal g c a n b e des crib ed for all θ ′ ∈ S u bst ( S g ) by h ϑ θ ′ , l i 7→ P S θ ′ , wher e X k ϑ θ ′ = X i k θ ′ (1 ≤ k ≤ r ). W e can now define the following pro pe r ties (the terminology of [6] is used): – The pr o cedure p r , or the clause c , or the prefix o f a clause g , or the lit- eral after the execution o f the go al g is deterministi c w.r.t. θ iff their sequence of answer substitutions has at m ost one co mputed answer s ubs ti- tution: | S pr | , | S c | , | S g | , | S θ ′ | ∈ { 0 , 1 } , for all θ ′ ∈ Subst ( S g ). – The pro ce dure pr , or the claus e c , o r the prefix of a clause g , or the literal after the execution of the goa l g is fully deterministic w.r .t. θ iff their sequence of answer substitutions has one and only one answer substitution: | S pr | = | S c | = | S g | = | S θ ′ | = 1, for a ll θ ′ ∈ Subst ( S g ). – The pro ce dure pr , or the claus e c , o r the prefix of a clause g , or the literal after the execution of the goal g surel y succeeds w.r.t. θ iff their sequence of answer substitutions ha s at le ast one answer subs titution: | S pr | , | S c | , | S g | , | S θ ′ | ≥ 1, for a ll θ ′ ∈ Subst ( S g ). – The literal l is a test l iteral after the execution of the goal g w.r.t. θ if it is not a cut, and it is deterministic w.r.t. θ , and it do es not instantiate any v ariable. F or all θ ′ ∈ Su bst ( S g ), S ′ θ is either the empt y se q uence <> or the sequence < ϑ θ ′ > . – The tw o pro cedures pr 1 and pr 2 (with the same arity n ) are exclusive w.r.t. θ iff either the execution of pr 1 fails, or the execution of pr 2 fails, or bo th executions o f pr 1 and pr 2 fail: h θ, pr 1 i 7→ P S 1 h θ, pr 2 i 7→ P S 2  ⇒ S 1 = <> o r S 2 = <> The sa me definition applies for exclusivity betw een t wo clauses o f sa me arity , or b etw een tw o pr efixes of clauses of same ar it y . The ab ov e pr op erties are undecidable but can b e safely appr oximated by o ur abstract interpretation framework present ed in Section 3 . 2.4 T ransformations Rul es The s ubsequent trans fo rmation rules ar e adapted fro m [6 ]. Let pr b e a nor- malised pro cedure s w ho se arity is n , and let θ b e a pro gram substitution whose domain is { X 1 , ..., X n } . A rule transforming the pr o cedure pr o f the program P int o the pro cedure pr ′ is c orr e ct w.r.t. θ if the executions o f pr (in the context of the prog ram P ) and o f pr ′ (in the context of the prog ram P ′ , which is the progra m P where p r has b een replaced b y pr ′ ) pro duce the same sequence of answer substitutions. In other words, if h θ , pr i 7→ P S and h θ , pr ′ i 7→ P ′ S ′ then S = S ′ . The conditions given for applying the transformations a re expr essed us- ing the semantic proper ties defined in Section 2.3. Such conditio ns a re sufficien t but not alw ays necessary . It is assumed that the pro cedure pr has no side-effects when it is executed with input θ . Rule 1: Reorder clauses ... c i : p ( X 1 , ..., X n ) :- g i . ... c j : p ( X 1 , ..., X n ) :- g j . ... ... c j : p ( X 1 , ..., X n ) :- g j . ... c i : p ( X 1 , ..., X n ) :- g i . ... where: – for all k ∈ { i, ..., j } , the clause c k is deterministic w.r.t. θ ; – for all k , l ∈ { i , ..., j } : k 6 = l , w e have that c k and c l are exclusive w.r.t. θ ; – for all k ∈ { i, ..., j } , there is no c ut in g k . Rule 2: Insert green cuts c 1 : p ( X 1 , ..., X n ) :- g 1 . ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i , l i +1 , ..., l s . ... c r : p ( X 1 , ..., X n ) :- g r . c 1 : p ( X 1 , ..., X n ) :- g 1 . ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i , ! , l i +1 , ..., l s . ... c r : p ( X 1 , ..., X n ) :- g r . where: – the goal ( l 1 , ..., l i ) is deterministic w.r.t. θ ; – for all z ∈ { k + 1 , ..., r } , the g oal ( l 1 , ..., l i ) and clause c z are ex clusive w.r.t. θ . Rule 3: Eli minate dead co de c 1 : p ( X 1 , ..., X n ) :- g 1 . ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i , ! , l i +1 , ..., l s . ... c r : p ( X 1 , ..., X n ) :- g r . c 1 : p ( X 1 , ..., X n ) :- g 1 . ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i , ! , l i +1 , ..., l s . where: – the goal ( l 1 , ..., l i ) surely succeeds w.r.t. θ . Rule 4: Mov e bac kwards cut ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i − 1 , ! , l i , ..., l s . ... ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i − 1 , l i , ! , ..., l s . ... where: – l i is fully deterministic after the e x ecution of g oal ( l 1 , ..., l i − 1 ) w.r.t. θ . Rule 5: Rem ov e usel ess test literals c 1 : p ( X 1 , ..., X n ) :- l 1 , ..., l i − 1 , l i , l i +1 , ..., l s . ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i − 1 , l i , l i +1 , ..., l s . ... c r : p ( X 1 , ..., X n ) :- g r . c 1 : p ( X 1 , ..., X n ) :- l 1 , ..., l i − 1 , l i , l i +1 , ..., l s . ... c k : p ( X 1 , ..., X n ) :- l 1 , ..., l i − 1 , l i +1 , ..., l s . ... c r : p ( X 1 , ..., X n ) :- g r . where: – l i is a tes t literal after the execution of goa l ( l 1 , ..., l i − 1 ) w.r.t. θ ; – l i is deterministic after the execution o f goa l ( l 1 , ..., l i − 1 ) w.r.t. θ ; – l i is fully deterministic after the e x ecution of g oal ( l 1 , ..., l i − 1 ) w.r.t. θ or ∃ z ∈ { 1 , ..., k − 1 } s uch that a cut is surely executed in cla us e c z w.r.t θ . The a bstract interpretation framework that safely a pproximates the condi- tions for applying the above sour c e-to-sour ce transfor mations is discussed in the next section. 3 Abstract Interpretation F ramew ork This section present s the abstract interpretation framework [7, 1 0] that captures and c hecks the semantic pr op erties (and other o nes) defined in Section 2.3. This semantic information (e.g., a bo ut the determinacy , the exclus ivity) is neede d for ensuring co rrect a pplication of the co de tra nsformations. Section 3.1 desc r ib es the tw o fundamen tal abstract domains. An abstr act substitution r epresents a set of program substitutions, a nd a n abstr act se quenc e represents a set of seq uences of answer substitutions. Section 3 .2 illustrates the synt ax of formal sp e cific ations , that allows the user to write abstr a ct sequences into a conv enient syn tax . The abstract execution is briefly presented in Section 3.3. Finally , Section 3.4 shows how abstract domains are used to c he ck the sema n tic prop erties. 3.1 Abstract Substi tutions and Abs tract Sequences The domain of abstr act subst itutions is an instantiation to mo des, types, lin- earity and p ossible shar ing o f the generic abstract domain Pat ( ℜ ) describ ed in [4, 9]. An abstr a ct substitution represents a set o f progr am s ubs titutions of the form { X 1 /t 1 , ..., X n /t n } , wher e the X i ’s ar e progr am v aria bles, and the t i ’s are terms (v ar iables o ccurring in terms are standar d v a riables; the set of stan- dard and progra m v ariables ar e disjoint). The set of substitutions represented by β is denoted by Cc ( β ) . F o rmally , an abstra ct substitution β is a triple of the for m h sv , frm , α i . The same-value ( sv ) and fr ame ( frm ) components provide information ab out the structure o f terms. Each term descr ib ed in β is repr e- sented by an index. The sv comp onent ma ps each prog ram v a riable X to its corres p o nding index . Hence, the equality sv ( X ) = sv ( Y ) means that v ariables X and Y are bound to the same ter m. The frm comp onent descr ib e s the pattern of some indice s, by g iving their functor name and the indices of their co mpo s- ing subterms. The alpha tuple α is the generic pa rt of the domain. It provides extra information a b o ut a ll terms and subterms of interest (represented by the indices). In the current analyser , α is of the form h mo, ty , ps, l in, E i . The mo comp onent [9] maps eac h index to its mo de (e.g., gr (ground), var (v aria ble)). The ty co mpo nent ma ps each index to its so-called typ e expr ession [7] (e.g., list(i nt) denotes the set of all lists of integers, l ist(an y) denotes the set of all p oss ibly non-instantiated lists ). The ps comp onent [9 ] is a binary r elation ov er indices, and expre sses the p os sible sha r ing betw e e n t wo terms. Pairs of in- dices that do not b elong to ps sur ely do not share a v aria ble. The l i n comp onent contains all indices that are surely linear (i.e., they do not co n tain se veral o c- currences of the same v aria ble). The E comp onent is a set of linear relations betw een the size of terms (several norms can b e combined). The abstra ct sub- stitution whos e concretisa tion is the empty se t is denoted b y ⊥ . The greatest low er b ound betw een t wo abs tr act substitutions β 1 and β 2 is denoted b y β 1 ⊓ β 2 and is such that Cc ( β 1 ) ∩ Cc ( β 2 ) = Cc ( β 1 ⊓ β 2 ). The domain of abstr act se qu enc es mo dels the op erational b ehaviour o f a Pro- log pro cedur e. An abstract seq uence B des crib es a set of pairs h θ, S i where θ is a program substitution and S is the s e q uence of a nswer substitutions res ulting from exec uting a pro cedure (a clause, a goal, etc.) with input substitution θ . An abstract sequence B is a tuple of the form h β in , β r ef , β fails , U , β out , E r ef out , E sol i that imposes conditions on the pairs h θ, S i . The set of pairs h θ, S i satisfying the conditions imp osed by B ar e denoted b y Cc ( B ). The input abstrac t substitu- tion β in describ es the class of a ccepted input calls: θ ∈ Cc ( β in ). The r efine d abstract substitution β r ef describ es the successful input calls , i.e., tho s e that pro duce at le a st one solution: S 6 = <> implies θ ∈ Cc ( β r ef ). The s e t of a bstract substitutions β fails describ es conditions of sure failure: the se q uence S is empty if the input substitution satisfies one of the abstract substitution of β fails , i.e., if there exists β f ∈ β fails such that θ ∈ Cc ( β f ) then S = <> . The untouche d com- po nent U describ es the set of input terms that are untouc hed (non-insta n tiated) during the execution. The outpu t abstra ct substitution β out describ es the sub- stitutions b elong ing to S : for each θ ′ in Su bst ( S ), we hav e tha t θ ′ ∈ Cc ( β out ). The size r elations compone nt E r ef out is a set of linear relatio ns (equatio ns and inequations) b etw een the size of the input/o utput terms. The c ar dinality com- po nent E sol is a set of linear relations b etw een the num b er of solutions and the size of the input terms, i.e., s ol= | S | is a solution of the system E sol . 3.2 F ormal Sp ecifications F ormal specificatio ns descr ibe abstrac t sequences using a concrete syn ta x mor e conv enient for a prog rammer than the mathematical formalism of abstract se- quences. A fo r mal s pec ification may c ontain other informatio n needed for the analyser , like the induction parameter for proving termina tio n. F or instance, the following tw o specifica tions for the effac e pr o cedure ca n be written b y the user (and can b e c hecked by the ana ly ser): efface efface in(X:g r,T:l ist(gr), TEff:var) in(X:g r,T:a ny,TEff:list(gr)) out(_, _, list( gr)) out(_, list(g r), _) srel(T Eff_o ut = T_in-1 ) srel(T Eff_i n = T _out- 1) sol(so l =< 1) sol(so l =< TEf f_in+ 1) sexpr( T) sexpr( TEff) W e find the different pa rts o f an a bs tract se quence. The first sp ecificatio n c o n- siders the situation wher e input X is a ground term, input T is a gro und list, and TEff is a v ariable. After success of execution, T Eff bec o mes a ground list, whose list-length is the list-length of input T min us one. The symbol ‘ _ ’ is used when we do not provide re fined information about an arg ument . The execution termi- nates (the size expression T decreas es throug h recursive calls) a nd is deterministic ( sol=<1 ). In the se cond sp e c ification, input X is a gr ound term, T is an y term, and T Eff is a ground lis t. This execution terminates and is non-deter ministic (the n umber of s o lutions is b etw een 0 and the list-leng th of input TE ff plus one). 3.3 Abstract Execution and Annotated Pro cedures Abstract execution is per formed on norma lised pro cedures (see Section 2.1), bec ause it simplifies the design of a bstract op erations . The a nalyser then first translates a general Prolog pro ce dure in to an equiv a len t normalised procedur e. The analysis is compositio nal. The system verifies a pr o cedure against a s pec i- fication, by assuming that the s p ecifica tions hold for subpro blems. F or a given progra m, it analy s es each pro cedur e; for a g iven pro cedure, it analy ses ea ch clause; for a given cla use, it a nalyses each atom. If a n atom in the b o dy of a clause is a pro cedure call, the analy ser lo oks at the g iven specifications to infer information ab out its executio n. The a nalyser succeeds if, for each pr o cedure and ea ch spe cification descr ibing this pro c e dure, the ana ly sis of the pro cedur e yields results that are cov er ed b y the considered sp ecification. As a result of the analysis, the pro cedure is annotated with abs tract seque nc e s at each progr am p o int. The annotation of the clause c ::= p ( X 1 , ..., X n ) :- l 1 , ..., l s . in the co ntext o f an abs tr act sequence B p = h β p in , ... i is of the for m: ( β p in ) p ( X 1 , ..., X n ) :- ( B 0 ) l 1 , ( B 1 ) ..., l s ( B s ) . ( B c ) The analy ser certifies that every abstra ct sequence at a prog r am p o int safely approximates the sequence of a nswer substitutions computed until that p oint. Let θ b e an input progr am substitution in Cc ( β p in ). F or each progr am p o int i (0 ≤ i ≤ s ), the conc r ete execution o f l 1 , ..., l i is a ppr oximated by B i , i.e., h θ, ( l 1 , ..., l i ) , c i 7→ P S i implies h θ , S i i ∈ Cc ( B i ). Similarly , the whole cla use ex- ecution is a pproximated b y B c , i.e., h θ, c i 7→ P S implies h θ , S i ∈ Cc ( B c ). The annotation of a pro cedure in the context of an abstr a ct sequence B p is the se- quence of its annotated clauses. 3.4 Chec king Semantic Prop erties This section explains how the analyser can chec k the s e mant ic prop erties of Sec- tion 2.3 that are useful for applying the co de transformations. The co mp onents of the abstr act sequences provide constraints about the length of the computed answer substitutions. Let B = h β in , β r ef , β fails , U , β out , E r ef out , E sol i b e the abstract sequence ap- proximating the ex ecution of a pr o cedure, or of a clause, or of a pr e fix in a claus e, or a liter al l after the execution of a goal. Le t B i = h β in , β i r ef , β i fails , U i , β i out , E i r ef out , E i sol i b e the abstr act sequence modelling the ex ecution of the clause c i , or the exe c ution of some pre fix of the cla use c i (1 ≤ i ≤ 2), where c 1 and c 2 hav e the same na me and ar it y . – If deterministi c ( B ) returns tr ue then h θ, S i ∈ Cc ( B ) implies | S | ≤ 1. The v alue of determi nistic ( B ) is set to true if sol=<1 is a solution of E sol . – If full y deterministi c ( B ) returns true then h θ, S i ∈ Cc ( B ) implies | S | = 1 . The v alue of ful ly determini stic ( B ) is set to true if β in = β r ef , and β fails = ∅ , and so l=1 is a solution of E sol . – If tes t literal ( B ) r eturns true then h θ, S i ∈ Cc ( B ) implies S = <> o r S = < θ > . The v alue of test literal ( B ) is set to true if sol=<1 is a solution of E sol and if the untouche d comp onent U contains all the indices o f β r ef . – Let h θ , S 1 i ∈ Cc ( B 1 ) and h θ , S 2 i ∈ Cc ( B 2 ). If exclusi v e ( B 1 , B 2 ) r eturns true then S 1 = <> or S 2 = <> . The v alue o f exclusive ( B 1 , B 2 ) is set to true if one of the three follo wing conditions holds: • the r efine d comp onents β 1 r ef and β 2 r ef are incompatible: β 1 r ef ⊓ β 2 r ef = ⊥ • o r ∃ β 1 f ∈ β 1 fails : ( β 1 r ef ⊓ β 2 r ef ) ≤ β 1 f • o r ∃ β 2 f ∈ β 2 fails : ( β 1 r ef ⊓ β 2 r ef ) ≤ β 2 f The accura cy and the co op er ation b e t ween the abstr a ct domains allow the analyser to detect automa tically whether the conditions are satisfied for applying co de trans formations. The next section discuss es the tr ansformation strateg y realized by the optimiser. 4 A Strategy to Generate Sp ecialised Co de In the deriv a tion of a pro cedure, there is often mor e than one p o s sible sequence of transforma tions, resulting in different pro cedures. So me he ur istics must then be included whithin the automation of the der iv ation of pro cedures to find p er- m utations leading to efficien t pro cedur e s for a giv en sp ecification. F or instance, the following heuristics ar e suggested in [6 ]: – Cho ose tail r e cursive p ermutations. Last call optimisation is implemen ted in the W AM [14], suc h that the environment is dea llo cated b efor e ex e c uting the last call. The efficiency gain is substantial if the last literal is a re c ursive call. – Cho ose p ermu tations of the liter als with the longest deterministic pr efix. This choice pr e ven ts useless computed a nswer s ubstitutions by prefixes of the literals. Multiple answ er substitutions are only gene r ated by the suffixes. – Cho ose p ermutations of t he liter als that su pp ort the intro duction of cuts and the r emoval of useless liter als. – Cho ose p ermu t ations of the liter als such t hat the unific ations ar e at the b e- ginning. This is useful to instan tia te the c la use heads and to suppres s these equality literals. The combination of transformation rules per formed by the o ptimiser is guided by the above heuristics, and is illustr ated on the ex ample ef face , whose initial m ultidirectional sour ce co de is: efface(X,[ H|T],[H|TEff]) :- efface(X,T,TEff), not(X=H). efface(X,[ X|T],T). The following directiona lit y is cons ide r ed (ex pr essed in to a for mal s p ecifica tion): efface in(X:gr, T:list(gr ), TEff:any) sol(sol =< 1) STEP A: Syn tactic normalis ation. Most code transforma tions apply o n normalised prog r ams, and the abstract execution itself is defined on normalised progra ms, b ecause it facilitates the analysis. Th us, the firs t step of the optimiser consists of tr anslating the o r iginal pro cedur e into an equiv alent normalised co de : efface(X1, X2,X3) :- X2=[X4|X5], X3=[X4|X6], efface(X1,X5, X6), not(X1=X4). efface(X1, X2,X3) :- X2=[X1|X3]. STEP B: Co de annotation. In this step, the infor mation needed to apply the co de transfor mations is captured by the chec ker. Every cla use o f the nor- malised pro cedure is annotated with abstra ct sequences at each program po int . STEP C : C l ause reordering. If the or der of solutions is not mo dified, some cla use reo rdering is ac hieved ( Rule 1 ): a cla use containing a literal that is a go o d candidate to b e remov ed after the possible in tro duction of cuts, is placed at the bottom of the pro cedure. In the ex a mple efface and for the considered directionality , the fo llowing co de is generated (clause reo rdering can be realized bec ause the pr o cedure is deterministic): efface(X1, X2,X3) :- X2=[X1|X3]. efface(X1, X2,X3) :- X2=[X4|X5], X3=[X4|X6], efface(X1,X5, X6), not(X1=X4). STEP D: Se m an tic normalisation. In o rder to insert a cut at the leftmost po sition in a cla use, it may be us eful to decomp ose a unification that may fail int o equiv alent but simpler unifications. It ma y then happen that a cut will b e placed betw een such unifications, instead o f after the (unique) glo bal unification. This step is called semant ic normalisation to dis ting uish it with the synt actic normalisation p erfor med at the step A: the optimiser uses the sema n tic infor- mation av aila ble a t ea ch progra m p oint a bo ut the structure, the mo de, the type, the sha ring and the linear it y of ter ms, as w ell as the sure success o f the execution of a unificatio n. The fo llowing code is gener ated for ef face (the last clause is not nor malised semantically because no cut will b e inserted there): efface(X1, X2,X3) :- X2=[X4|X5], X4=X1, X5=X3. efface(X1, X2,X3) :- X2=[X4|X5], X3=[X4|X6], efface(X1,X5, X6), not(X1=X4). In the fir st clause, the unification X2= [X1|X 3] has b een deco mpo sed in three elementary unifications: the initial unification succeeds if X 2 is a non-empty list (i.e., X2 =[X4|X 5] ), and if the fir st element of X2 is X 1 (i.e., X4=X1 ), and if the tail of X2 is X3 (i.e., X5 =X3 ). STEP E: Leftmost cut insertion with de ad co de el imination. The ob jective of this step is to insert leftmost g reen cuts in every clause, except in the last c lause ( Rule 2 ). In our example, a green cut is introduced in the first clause, at the program p o int where it is exclusive with the second clause: efface(X1, X2,X3) :- X2=[X4|X5], X4=X1, !, X5=X3. efface(X1, X2,X3) :- X2=[X4|X5], X3=[X4|X6], efface(X1,X5, X6), not(X1=X4). The cut has been inser ted b efor e the last unification X5=X3 . If we had not p er- formed the previous s tep, then the cut would hav e been placed at the end of the first cla use. When inserting a cut, some success ive clauses may b ecome useless, such that they can b e r emov ed ( Rule 3 ). STEP F: Mov e cuts bac kwa rds. The o b jective o f this step is to obtain the longest deter ministic prefix b efore ex ecuting a cut in a cla us e. While making sure tha t the pro cedure still terminates and that the sub calls are still correctly mo ded a nd typed, s o me literals are reorder ed inside the clause s . An inserted cut is moved backw a rds by pa ssing litera ls tha t surely succeed b efore the cut ( Rule 4 ). In our example, the cut canno t b e mov ed backw ar ds, b ecaus e the unification X5 =X3 do es not sur ely succeed (a t that p oint, X 5 is a ground list and X3 is an y term). STEP G: Removing usele ss literals . The a na lyser is able to captur e the input co nditions for which a cut is sur ely executed. This informa tion is used to refine the input conditio ns o f the succes sive clauses. T his a llows the optimiser to remov e s ome literals whic h beco me useless ( Rule 5 ) (e.g., negation, test predicates, a rithmetic built-ins ). In our example, the cut is surely e x ecuted when the first elemen t of input lis t X2 is the input X1 . The second clause is thus surely not executed for that input. In particular, the negation surely succeeds and can therefore b e suppressed safely: efface(X1, X2,X3) :- X2=[X4|X5] , X4=X1, !, X5=X3 . efface(X1, X2,X3) :- X2=[X4|X5] , X3=[X4| X6], efface(X1,X5 ,X6). STEP H: Sem an tic denormalisation. The c o de gener ated until this step is still normalise d (with pos sibly added cuts). Thus, it r emains inefficient. The last step co nsists of applying the reverse trans fo rmation. The semantic denor- malisation uses the information capture d b y the analy s er to suppress explicit unifications, or to repla ce them by s impler ones, and to place them implicitly in the head of clauses. The sp ecialised co de for e fface is thus finally gener ated: efface(X1, [X1|X2],X3) :- !, X2=X3. efface(X1, [X4|X2],[X4|X3]) :- efface(X1,X2,X 3). Remark. It may happ en that the initial sour ce co de a lready contains some cuts. In such situation, the optimiser first r emov es every gr een cut, such that only the neces sary leftmost cuts will b e intro duce d dur ing the step E. 5 Exp erimen tal Ev aluation T able 2 compares the execution betw e e n the o riginal and the generated versions of efface( X,T,TE ff) pr esented in the pr evious section. Several tests hav e bee n per formed by considering executions that succeed a nd tha t fail, a nd by v a rying the list-length of the input list T . The ta ble shows that the multidirectional co de is less efficient than the sp ecialised one in terms of executio n time a nd of used lo cal stack. In particular , the s p ecia lised c o de uses a co nstant amoun t of lo cal stack (indep endently of the size of the input), while w e yield a lo cal stack error if we try to execute the m ultidirectional co de with an input list of size 250 00. Success Input Execution Ti me (ms) Used Local Stack (By) of list Multidirectional Optimized Multidirectional Optimized execution size (ms) (ms) (sdup) (By) (By) no 100 41 23 1.83 8508 156 no 1000 380 194 1.96 84108 156 no 10000 4268 1893 2.25 840 108 156 no 25000 ERROR 4715 - E RROR 156 yes 100 115 26 4.39 8508 156 yes 1000 689 221 3.11 84108 156 yes 10000 7334 2207 3.32 840 108 156 yes 25000 ERROR 5527 - E RROR 156 T able 2. Program efface(X,T,TEF f) executed 1000 times, when X is a ground term, T is a ground list, and TEff is any term. Several tests are p erformed, dep end- ing on whether the execution fails or succeeds, and depend in g on the list-length of T . The program has b een tested on a 1.5 Ghz Pen tium; 1Gb RA M; Linux Suse; SWI - Prolog v 5.4.6 [15]. The size to which the lo cal stac k is allo wed to gro w is 2048000 By . The optimiser has b een tested on some classical programs, bor row ed from [2, 6 , 1 3] and from the In ter net. The source prog rams, the for mal sp eci- fications, the generated s p ecia lised c o des, a nd the efficiency tests are av ailable at http://www.i n fo.ucl.ac .b e/ ∼ gob ert . The tests hav e b een realized o n a 1 .5 Ghz Pen- tium, 1Gb RAM, Lin ux Suse, with SWI-Pro lo g v 5.4.6 [15]. T ests on Execution Time. T a ble 3 re p o r ts o n execution time sp eedup, defined as the ratio b etw een the execution time sp ent for the so urce pro gram and for the spe c ia lised progra m. A sp eedup greater than (resp. les s than) one means that the sp ecia lised co de is more (resp. less) efficient than the source co de. W e consider 59 pr o cedures and 112 sp ecifications (so me pro cedures hav e several sp ecifications , b ecause they are m ultidirectio nal). The benchmark al l is comp osed of 173 efficiency tes ts (there is a t least o ne efficiency test for each spec- ification of a pro cedure). The b enchmark det is a subset o f the b enchmark al l . It co nt a ins only the efficiency tests for the deterministic pro cedures. The bench- mark ss contains the efficiency tests fo r the pro cedures that s urely succeed. The benchmark det+s s co n tains the efficiency tests for the determinitic pro cedures that s urely s ucceed. The mean sp eedup ranges from 1.42 to 1.68. The maximal sp eedup is 8.54 and the minimum sp eedup is 0 .5 9. Efficiency Execution Time (Sdup) tests Mean Max Min 173 al l 1.42 8.54 0.59 125 det 1.45 8.54 0.59 45 ss 1.6 8.54 0.8 38 det+ss 1.68 8.54 0.8 T able 3. Execution time sp eedup b etw een source codes and specialized codes generated by the optimiser: 173 efficiency t ests distributed out of 59 predicates and 112 formal sp ecifications. F rom the 173 tests, we obtain a sp eed up for 112 tests, and a sp eed dow n for 61 tests. T ests on Space Util isation. T a ble 4 repo rts o n lo cal stack utilisation. 57 generated pro cedur es ar e co nsidered. The maximal amount of lo cal stack used during the executio n of the ge ne r ated co de is either reduced (for 28 pro c e dures), or identical (17 pro cedur es), o r incr eased (1 2 pro cedures) w.r .t. the maximal amount of lo cal stack used during the ex ecution of the source co de. Generated Used lo cal stac k Used lo cal stack Used lo cal stac k procedures is reduced wrt i s identical wrt is increased wrt source code source code source code 57 28 17 12 T able 4. Comparisons b etw een source & generated co des in terms of space utilization. Accuracy of the T e s ts. The res ults r e po rted on T able 3 and T able 4 de- pend on the c hoice of the efficiency tests. It is impossible to p erfo rm tests that include every situatio n in the context of a directio nality . W e have tried to make sufficiently gener al tests for each direc tionality . The efficiency r esults dep end also o n the way the source co de is written. F or all the b enchmark rep orted in the tables, the or iginal program w as written in the usual Pro log style (i.e., not normalised). The optimiser can ta ke as input progr ams that are normalis ed, like the ones that are derived in the metho dolo gy [6]. If we p erfor m the sa me effi- ciency tests with normalised pro grams as initial so ur ce code, then we obtain a mean sp eedup of 3. This shows the utilit y of the o ptimiser. Generated co de ma y someti mes b e les s efficient. In general, the op- timiser gener ates co de tha t is more efficient than the sour ce co de, in terms of execution time a nd of lo cal stack utilisation. But the tables rep or t that a gen- erated co de can sometimes b e less efficient than the original code. F o r instance, this o ccurs with the app end(L 1,L2,L 3) pro cedure which co ncatenates tw o lists (w e consider the usual directionality where inputs L1 and L2 are ground lists and L3 is a v ariable). The initia l source co de is : append([], L,L). append([H| L1],L2,[H|L3]) :- append(L1,L2,L3). In SWI-Pro log, indexing is ena bled by default on the first argument. Thus, in the context o f the co ns idered directionality , no choice po int is created on the lo cal stack. Indeed, the rig ht cla use is dir ectly selected accor ding to the principa l functor of the first input list, which is either a n empty or a non-e mpt y list. F urthermore, the seco nd cla use is a chain rule (i.e., there is o nly one atom in the bo dy), such that no environmen t frame is allo cated on the loc al stack. Therefore, this so urce co de uses a constant amount of lo cal stack, and executes very quickly . The o ptimiser do es not tak e in to account the indexing tec hnique in its strat- egy for apply ing corre c t co de tra nsformations, and the following co de will b e generated: append([H| L1],L2,[H|L3]) :- append(L1,L2 ,L3), !. append( ,L,L). where the t wo clauses are reorder ed, a cut is inser ted a fter the recurs ive call, and the co nstant [] in the second cla use is r emov ed. This code is les s efficient than the initial s ource co de. Indexing has no effect beca use the right clause ca nnot be selected acco rding to the principa l functor o f the input list L1 . Thus, Prolog creates a choice p oint on the lo cal stack ea ch time the first clause is called (and it is often ex ecuted b eca use it is the recursive ca ll). The cut is a de ep cut (i.e., it is not lo c a ted just after the symbol :- ). It o ccurs after the recurs ive call, such that the fir st clause is no more a ch ain ru le , and a n environment frame must b e allo cated on the lo cal stack each time we execute the first claus e. The amount of lo cal stack used during executio n is increasing throug h recursive calls, to the contrary of the initial source co de, which uses a constant amoun t of lo cal stack. 6 Related W ork The Mercury pro gramming languag e [12] is as s o ciated with a whole range o f analysis to ols for o ptimisation purp oses . In Mercury also , the progra mmer has to anno tate the pr ogra m with information a bo ut mo des, t yp es, success and de- terminacy . A main difference is that not a ll logic pr ogra ms are accepted b y Mercury (o nly limited forms of unification a r e allowed) . Ther e a r e restr ictions on the form of the progr ams and queries in order to generate more efficient co de. Mercury is no t based on the W a rren’s Abstract Machine, but has sp ecialised - more efficient - a lgorithms, dep ending on the determinacy information. So our approach is more a ppe a ling to progr ammers who a re willing to keep the full power of Pro log. Unlike Mercury , we do not change the usual execution mo del of Prolog based on the W AM [1, 14 ]: our optimiser p erforms some transforma tions at the Pr olog co de level. Actually , our optimiser should b e able to genera te low- level co de. But p er forming sourc e-to-sour ce transforma tions is mor e p ortable (and easier to ex plain) than generating sp ecialise d W AM’s instructions. Most Mercury annotatio ns ca n b e tra nslated int o our for ma l sp ecifica tion languag e. A cur rent limitatio n to our languag e is that, for ins tance, we c a nnot expr e ss that a n input list con ta ins only free distinct v ar iables (this can b e expressed in Mercury). On the other hand, more genera l directio na lities can b e describ ed in our lang uage. F o r instance, we can express that some argument is a list p o ssi- bly non-instantiated and p ossibly non-linear , and that tw o terms possibly shar e a v ariable (this cannot b e express ed in Merc ury), like in the following for mal sp ecification for a ppend : append in(L1:list (any), L2:list(any), L3:any) out(_, _, list(any )) sol(sol =< 1) The Ciao prepro cessor CiaoPP [8] is a pow e rful static analyser based on ab- stract interpretation, which features many analyses similar to o urs and other ones. The s y stem ca n infer and/or check prop erties like regula r t yp e s, mo des, sharing, non-failure and determinacy , b ounds on computational cost, bounds on sizes o f terms in the pr ogra m, a nd termination. In that system, pro cedur e s can be optionally annotated by asser tions, which partia lly corres po nds to specifica - tions of our s ystem. The system can per form automatic optimisa tions s uch as source-to - source transforma tion, spec ialisation, pa rtial ev aluation o f pro g rams, progra m parallelis ation. Some transfor mations like cut insertion and semantic denormalisa tio n are not p erformed in CiaoPP . The author s of [5] co nsider how most of the common uses of cut can b e eliminated from Pr o log s ource prog rams, by relying on static a na lysis to generate them at co mpile time. Static analys is techniques are used to detect situa tions where to place cuts. In o ur approach, the insertion of c uts is o nly o ne part of the o ptimisation pro cess: s e veral so urce-to-s ource tra nsformations are applied to find the b est pla ce where to pla c e the cut (e.g., cla us e and literal reor dering, semantic nor malisation, etc.), to r emov e literals b ecoming useless due to the execution of cut in previous clause s , and to p er form some par tial ev aluation. 7 Conclusion and F uture W ork W e have prese n ted an optimiser based on abstra ct in ter pretation which attempts to ma ke a Pr olog progr am more efficient b y transforming its sour ce co de without changing its op erationa l semantics. The to ol auto matically p erfor ms s a fe co de transformatio ns of any Pro log prog ram in the co n text of some cla ss of input calls (describ ed in formal spec ifica tions). Preliminar y exp e rimental tests of the optimiser show encoura ging re s ults, since the sp ecialis e d co des ar e, at the av- erage, 1.42 time mor e efficient in terms of execution time consumption and of lo cal stack utilisation. The optimiser ca n b e improv e d: we plan to find b etter heuristics for sp e cialising the co de, based on the knowledge of the W AM [1, 14], in or der to take into account the indexing technique, and the influence on the efficiency of a dding or not de ep cuts. References 1. H. A ¨ ıt-Kaci. Warr en ’s Abst r act M achine: A T utorial R e c onstruction . 1991. The MIT Press . Lond on. 2. K.R. A pt. F r om L o gic Pr o gr ammi ng to Pr ol o g . Pren t ice Hall, 1997. 3. Bruyno oghe, M. 1991 . A pr actic al fr amework f or the abstr act interpr etation of lo gic pr o gr ams. J. Log. Program. 10, 2 (Jan. 1991), 91-124. 4. A. Cortesi, B. Le Charlie r, P . V an Hentenryck. Combination of abstr act domains for lo gic pr o gr amm i ng: op en pr o duct and generic p attern c onstruction . Science of Computer Progra mming 38:27–7 1, Elsevier Science 20 00. 5. S. K. Debray and D. S. W arren. T owar ds Banishing the Cut fr om Pr olo g. IEEE T rans. Soft w. Eng. 16, 3 (Mar. 1990), 335-34 9. 1990. 6. Y. Deville. L o gic Pr o gr amming:Systematic Pr o gr am Development . A. W esley , 1990. 7. F. Gobert and B. Le Charlie r. A System to che ck Op er ational Pr op erties of L o gi c Pr o gr ams . AF ADL’07 conference. Nam ur. 2007. 8. M. Hermenegil do, G. Puebla, F. Bueno, P . L´ opez- Garc ´ ıa. Inte gr ate d Pr o gr am De- bugging, V erific ation, and Optimi zation Using Abs tr act Interpr etation (and T he Ciao System Pr epr o c essor). Science of Computer Programming, V ol. 58, Num. 1- 2, pages 115-140, Elsevier Science, Oct ober 2005. 9. B. Le Charlier and P . V an H entenryck. Exp erimental Evaluation of a Generic Ab str act Interp r etation Algor ithm for Pr olo g . A CM T ransactions on Progr amming Languages and Sy stems (TOPLAS ), 16(1):3 5–101, Ja nuary 1994. 10. B. Le Charlier, C. Lecl` ere, S . R ossi, and A . Cortesi. Aut omate d V erific ation of Pr olo g Pr o gr ams. JLP , 39:3–42, Elsevier Science 199 9. 11. B. Le Charlier, S. Rossi, and P . V an Hentenryck. Se quenc e-Base d Abst r act Inter- pr etation of Pr olo g . TPLP 2(1): 25-84 ( 2002) 12. Z.Somogyi, F.Henderson, T.Con w ay . The Exe cution A lgorithm of M er cury, an Ef- ficient Pur ely De clar ative L o gic Pr o gr amming L anguage . JLP, 29(1–3):17–64 , 1996. 13. L. Sterling and E. Shapiro. The Art of Pr ol o g, A dvanc e d Pr o gr amming T e chniques . Second Edition. The MIT Press . 1994. Cam bridge, Massac husetts. London. 14. D. H. D. W arren. An abstr act Pr olo g instruction set . T echnical Note 309, SR I International, Menlo Pa rk , CA, Octob er 1983. 15. J. Wielemak er. SWI-Pr olo g 5.6 R efer enc e Manual. Un iversit y of Amsterdam. April 2006. ht tp://www.swi-pr olo g.or g