This note clarifies how to handle solution gathering meta-calls, asserts and retracts in the groundness analysis of Prolog

Heaton, Andrew

King, Andy

English

Kent Academic Repository

Abstrating Builtins for Groundness AnalysisAndy Heaton and Andy KingShool of Computer Studies, University of Leeds, LS2 9JT, UK.Computing Laboratory, University of Kent, CT2 7NF, UK.AbstratThis note laries how to handle solution gathering meta-alls, asserts and retratsin the groundness analysis of Prolog.1 IntrodutionMost work on stati program analysis for Prolog has onentrated on thedesign of abstrat domains and their operations, rather than issues of howbuiltins suh as meta-alls and dynami prediates should be handled. Manyrealisti programs ontain suh builtins, however, and so this is an importantissue to address when onstruting an analyser [2{4,6,7℄. This note details howbuiltins are handled in a groundness analyser developed at the University ofKent in ollaboration with the Universities of Ben-Gurion and Leeds. Thisanalyser is omposed to two ore modules: an abstrater module whih takes,as input, a program and produes, as output, an abstrat version of the pro-gram that only expresses grounding dependeny information; a xpoint enginewhih traes the dependenies in the abstrat program to infer whih argu-ments of the input program are ground. Builtins pose (at least) four problemsfor stati analysis and, in partiular, program abstration:meta-all problem The problem with a goal suh as all(G) is that the prin-ipal funtor of the goal G might not be known until run-time and thus weannot in general trae the all to G and dedue its answer (and those itspossibly generates through sub-goals). Analogous safety problems an ourwith bagof, ndall, one, not and setof.solution gathering problem A partiular problem that ours in solution gath-ering meta-alls suh as ndall(T , p(S, T ), B) is that they annot simplybe abstrated as p(S, T ) or even p(S, B). This is beause the goal ndall(T ,p(S, T ), B) neither instantiates S nor T (though it might ground B). Anal-ogous problems our with bagof and setof.Preprint submitted to Elsevier Preprint 20 Deember 1999assert problem The problem with assert goals is that they an extend theprogram at run-time and thereby introdue new alls and answers. Speif-ially, suppose that a program onsists of the fats p() and q( ) and thelause r(X) :- assert((p(Y ) :- q(Y ))), p(X). The query r(X) will all the as-sert goal. This asserts the lause p(Y ) :- q(Y ) whih, in turn, introdues anew omputation path through q(Y ) (whih has true as its all and answerpatterns) and leads to answer pattern of true for the top-level goal r(X). Ifthe assert was merely ignored, then all and answer patterns for q would bemissed, and an inorret answer pattern for r would be inferred.retrat problem The problem with a retrat goal is basially one of prei-sion. Consider a program that shares data between two program pointsusing dynami prediates to implement a blakboard mehanism. The allassert(data(I)) will write (and extend) the blakboard and elsewhere inthe program the all retrat(data(O)) will read (and prune) the blak-board. The goal retrat(data(O)) an be safely abstrated by true. Preisionould be improved, however, if we an infer that I is ground when the goalassert(data(I)) is alled beause then retrat(data(O)) must ground O.To resolve the meta-all problem (and muh of the assert problem) we followthe elegant analysis model set out in [3,4℄ in whih there are assumed to betwo versions of the program: one (virgin) program that is unanalysed; andanother (renamed) version that is ompletely analysed. The idea is for therenamed version to only express information about the alls that the analysisis able to trae. The renamed program is onstruted by substituting eahatom (that is not a builtin) in the virgin program, G = p(t1; : : : ; tn), withnew atom, G0= p0(t1; : : : ; tn). Heneforth, G0will denote the rename of G.Top-level alls, as suh those speied in the export delarations of a moduleinterfae, are direted at the renamed prediates. Renaming ensures that allsin one version of the program annot normally invoke prediates in the other.One exeption is with meta-alls whih our in the renamed program. Thesebuild unrenamed goals and thus all the virgin program. The other exeptionis with asserts that our in the renamed program. The bodies of assertedlauses are omposed of unrenamed goals and therefore an all into the virginprogram. The important point is that these alls (and those they generate) donot need to be traked to safely reason about the all and answer patterns ofthe renamed program. This means that, if desired, a meta-all suh as all(G)an safely be ignored during analysis. Note, however, that preision may beimproved by replaing all(G) with the goalG0if its prinipal funtor is known.To summarise, the two program model of [3,4℄ essentially buys safety at theexpense of doubling the size of the program.With this model in mind, setion 2 details how meta-alls and solution gath-ering goals are handled, and setions 3 and 4 explains how assert and retratgoals are dealt with. As far as we aware, previous work has not onsideredthe solution gathering problem and also the literature on handling assert and2retrat ontains a number of holes. The appendix lists the groundness abstra-tions for a set of (less problemati) builtins. Setion 5 onludes.2 Meta-all and bagof problemThe two program model of [2,4℄ enables meta-alls to G to be (essentially)ignored during analysis. If the prinipal funtor of G is known, however, it isusually better to replae the meta-all with a all to G0as is desribed below.2.1 The all, one and not goalsGoals suh as all(G) and one(G) an be handled as if they were G0. Goalssuh as not(G) and n+(G), however, are replaed with the goal p(X1; : : : ; Xn)where p is a new prediate symbol and var(G) = fX1; : : : ; Xng. The newprediate is dened as the lause p(X1; : : : ; Xn) :- G0, !, fail and the fatp(X1; : : : ; Xn). This essentially unfolds the denition of not(G0).2.2 The bagof, setof and ndall goalsThese goals are not entirely straightforward to abstrat sine they annot betreated as normal meta-alls. The meta-all bagof(T , G, B) binds B to a listof instanes of the template T generated through all the proofs of the goal G.(To simplify the presentation, we assume that T and B are variables.) Themeta-all fails if G fails. More generally, meta-alls an take the form bagof(T ,Y1b : : :bYnbG, B) where b denotes existential quantiation. Variables that arenot quantied (and do not orrespond to T ) an be bound by a proof ofG. The goal bagof(T , Y1b : : :bYmbG, B) an be handled by replaing it withp(X1; : : : ; Xn; B) where var(G) n fT; Y1; : : : ; Ymg = fX1; : : : ; Xng and p is anew prediate dened by the lause p(X1; : : : ; Xn; B) :- G0, opy term(T , B).G0annot propagate bindings through Y1; : : : ; Ymsine these variables are notarguments of p. The setof meta-all an be treated similarly.The meta-all ndall(T , G, B) diers from bagof and setof in that it alwayssueeds and never binds any variables of G. Furthermore, the solution listis made up of variants of the instanes of T that are generated through solv-ing G. The meta-all is thus handled by replaing ndall(T , G, B) with thegoal p(X1; : : : ; Xn; B) where var(G) n fTg = fX1; : : : ; Xng and p is a newprediate dened by the lauses p(X1; : : : ; Xn; B) :- G0, opy term(T , B) andp(X1; : : : ; Xn; B) :- ground(B).3Observe that opy term(T;B) is not desribed by the grounding dependenyB  T . If it were, the groundness of T and B after the exeution of theompound goal opy term(T;B), T = a would be desribed by (B  T )^T =T ^ B, whih is inorret. To handle opy term aurately it is neessaryto extend the xpoint engine to ground B if T is ground when the goal isenountered.3 The assert problemThe database mutation prediates are assert, retrat and abolish. The retratand abolish builtins remove lauses from the database, annot aet safety,and thus are not as problemati as assert. With the two program model,however, asserts an be handled safely.3.1 Exploiting dynami delarationsOne simple tati is based on inspeting the dynami delarations of the pro-gram sine it is normally only permissible to assert lauses whose head predi-ate symbols are dynami [8℄. If p=n is delared dynami, then a (nop) lausep0(X1; : : : ; Xn) an be added to the renamed program so as to ensure thatthe answer pattern alulated for p0is safe. The nop lause is a devie thatis introdued temporarily for analysis: it should not appear in the ode gen-erated for the renamed program. In this sheme, the assert goals in both thevirgin and renamed program must be retained and the behaviour of assert(slightly) revised. Speially, a all assert((H :- B1; : : : ; Bn)) must both addH :- B1; : : : ; Bnto the virgin program and add H0:- B1; : : : ; Bnto the re-named program. This ensures onsisteny between the two versions of theprogram. The semantis of retrat also needs to be amended to keep both ver-sions of the program onsistent. Note that the body atoms of both assertedlauses are not renamed and thus only generate alls into the virgin program.The asserted lauses do not therefore ompromise the safety of the all andanswer patterns alulated for the renamed prediates.3.2 Exploiting prinipal funtor informationThe dynami delarations provide a useful safety net for handling asserts.Often, however, the prinipal funtors of all the head and body atoms of all theasserted lauses are known at ompile-time. This enables asserts to be analysedwithout resorting to safe (albeit impreise) nop lauses. Speially, onsider4the goal assert((H :- B1; : : : ; Bn)) and suppose that the prinipal funtors ofH, B1; : : : ; Bnare all known (rather than, say, uninstantiated variables). Thenthe H0:- B01; : : : ; B0nlause an be added to the renamed program for thepurposes of analysis. As with nop lauses, the renamed lause is merely ananalysis devie and should not appear in the ode generated for the renamedprogram. Also like before, the assert goals must be retained. With the modiedassert semantis, this again adds H :- B1; : : : ; Bnto the virgin program andH0:- B1; : : : ; Bnto the renamed program. The hief advantage of this tatiover just exploiting dynami delarations is that it may improve the preisionof the answer pattern of an asserted lause.In ases where we do not have full knowledge at ompile-time of all the assertedlauses, we still need to resort to the nop tati. Speially, if a programontains an assert with a lause that ontains a body atom whose priniplefuntor is not known at ompile-time, then the nop tati has to be applied.Similarly, if the program ontains a meta-all to a goal whose priniple funtoris not known, then the nop tati has to be applied. This is beause, in general,unknown meta-alls and body atoms may take the form assert(p(X1; : : : ; Xn))where p=n is dynami.3.3 Exploiting groundness informationIf the program does not need to ontain nop lauses (for the reasons explainedabove), then preision an be further improved by inferring the groundnessinformation that desribes the program state at the time at whih the as-sert goal is enountered. Speially, for the goal assert((H :- B1; : : : ; Bn)),the tati is to dedue the grounding dependenies between fX1; : : : ; Xmg =var(H :- B1; : : : ; Bn) at the program point at whih the assert ours. Thisis ahieved by inserting the all p(X1; : : : ; Xm) into the renamed programimmediately prior to the assert goal where p=m is a new prediate symbol.The p=m goal reords the state of the X1; : : : ; Xmvariables. To ensure thatthe all sueeds (without binding X1; : : : ; Xm) the nop fat p(X1; : : : ; Xm) isadded to the renamed program. Observe that the all and answer patternsof p=m oinide. To model the eet of the bindings on X1; : : : ; Xm, thelauses H0:- q(X1; : : : ; Xm); B01; : : : ; B0nand q(X1; : : : ; Xm) :- p(X1; : : : ; Xm)are added to the renamed program where q=m is another new prediate sym-bol. The xpoint engine is (very slightly) modied to reognise the q=m lauseas assert related and speially bar the p(X1; : : : ; Xm) body atom from on-tributing to the all pattern of p=m. Otherwise all and answer patterns arisingwithin the q=m are traed normally. Hene the all pattern on p=m orre-sponds to the answer pattern on q=m whih, in turn, propagates the bindingson X1; : : : ; Xminto the asserted lause.54 The retrat problemAs previously explained, the problem with a goal suh as retrat((H :- B))is essentially one of preision: retrat goals an be ignored but this loses thegrounding eets of mathing H :- B against the dynami database. An anal-ogous problem ours with lause((H :- B)) whih an be interpreted as anon-mutating read of the dynami database. If the prinipal funtor of H isknown at ompile-time to be p=n and the (stati and dynami) lauses for p=nare known to be fats, then the goals retrat(H :- B) and lause(H :- B) anbe handled as the onjuntion all(H), B = true. A simpler tati is appliablefor goals suh as retrat(H) and lause(H) where H is bound at ompile-timeto a fat with a prinipal funtor p=n. Both retrat and lause goals an thenbe replaed with the all H0. This is safe beause if the dynami database on-tains a mathing fat, then the answer pattern for p0=n will safely approximatethe eet of unifying H with the database.5 DisussionMost goals an be handled relatively straightforwardly in program analysis:ompound goals suh as G1; G2, G1 > G2, et an dealt with by simple pro-gram transformations; table lookup an be used for most builtins; and evenath and throw an be supported [4℄. Constraints an be handled straight-forwardly by re-writing to three-variable form [1℄. For example, w = x+ y  z,is written to w = x + t; t = y  z, where t is a fresh, temporary variable.Table lookup is then used to map three-variable forms to Boolean formulae,for example w = x + t and t = y  z map to f1= (w  (x ^ t)) ^ (x  (w ^ t)) ^ (t (w ^ x)) and f2= (t (y ^ z)). The grounding behaviour ofthe onstraint w = x+ t; t = yz is desribed by f1^f2. (Temporary variablessuh as t an be removed by projetion, for example, t an be eliminated by9t:(f1^ f2) = (w (x ^ y ^ z)) ^ (x (w ^ y ^ z)). However, we hoose notto do this, preferring to keep the abstrater as simple as possible. This onlyreally aets EPosN.)The real problem in handling builtins is that the large number of ases meansthat it is easy to aidently introdue some impreision. An appendix thusdetails how our analyser handles various builtins. It is intended to help otherdevelopers in the analysis ommunity. Other issues that have not be disussedin this note, however, are more problemati. For example, supporting programsthat are broken aross several les [4,5,9℄ is a study within its own right. Atpresent, our analyser has no support for modules. It also annot handle termmutating setarg/3 goals.6Referenes[1℄ N. Baker and H. Sndergaard. Deniteness Analysis for CLP(R). AustralianComputer Siene Communiations, 15(1):321{332, 1993.[2℄ F. Bueno, D. Cabeza, M. Gara de al Banda, M. Hermenegildo, and G. Puebla.Abstrat Funtions for the Analysis of Builtins in the PLAI System. TehnialReport CLIP1/95.0, Tehnial University of Madrid (UPM), Spain, 1995.[3℄ F. Bueno, D. Cabeza, M. Hermenegildo, and G. Puebla. Data-Flow Analysis ofProlog Programs with Extra-Logial Features. Tehnial Report CLIP5/95.0,Tehnial University of Madrid (UPM), Spain, 1995.[4℄ F. Bueno, D. Cabeza, M. Hermenegildo, and G. Puebla. Global Analysis ofStandard Prolog Programs. In European Symposium on Programming, pages108{124. Springer-Verlag, 1996. LNCS 1058.[5℄ M. Codish, S. Debray, and R. Giaobazzi. Compositional Analysis of ModularLogi Programs. In Priniples of Programming Languages, pages 451{464. ACMPress, 1993.[6℄ A. Cortesi and G. File. Abstrat interpretation of Prolog: the treatment ofbuilt-ins. In Proeedings of the GULP Conferene on Logi Programming, pages87{104, 1992.[7℄ S. Debray. Flow Analysis of Dynami Logi Programs. Journal of LogiProgramming, 7(2):149{176, 1989.[8℄ P. Deransart, A. Ed-Dbali, and L. Cervoni. Prolog: The Standard. Springer-Verlag, 1996.[9℄ M. Hermenegildo, K. Marriott, G. Puebla, and P. Stukey. Inremental Analysisof Logi Programs. In International Conferene on Logi Programming, pages797{812. MIT Press, 1995.A Groundness abstrations for builtinsIn order to make the appendix ontainable, we give representative ground-ness abstrations for a range of builtins. In the sequel fidenotes the formula^var(ti) where var(ti) is the set of variables ourring in the term ti. Notethat ^; = true.The following builtins ground all their arguments: </2, >/2, =</2, >=/2, =:=/2,=\=/2, abolish/1, abolish/2, absolute le name/2, atom/1, atom hars/2,atomi/1, ompile/1, onsult/1, harater ount/2, lose/1, urrent atom/1,urrent input/1, urrent module/1, urrent module/2, urrent op/3,urrent output/1, urrent stream/3, ensure loaded/1, erase/1, oat/1,7ush output/1, get/1, get/2, get0/1, get0/2, ground/1, integer/1, is/2, leash/1,line ount/2, line position/2, load/1, name/2, nl/1, number/1,number hars/2, numbervars/3, op/3, open/3, open/4, open null stream/1,peek har/1, peek har/2, prolog ag/2, prolog ag/3, prompt/2, put/1,put/2, reonsult/1, see/1, seeing/1, set input/1, set output/1, skip/1, skip/2,skip line/1, soure le/1, statistis/2, stream ode/2, tab/1, tab/2, tell/1,telling/1, ttyget/1, ttyget0/1, ttyput/1, ttyskip/1, ttytab/1, use module/2,use module/3, version/1.The following builtins are abstrated as true: </2, >/2, =</2, >=/2, \==/2,break/0, allable/1, ompound/1, debug/0, debugging/0, dif/2, display/1,expand term/2, leerrors/0, garbage ollet/0, g/0, help/0, listing/0,listing/1, nl/0, nodebug/0, noleerrors/0, nog/0, nonvar/1, nospyall/0,notrae/0, otherwise/0, phrase/2, phrase/3, print/1, read/1, repeat/0,retratall/1, subsumes hk/2, seen/0, simple/1, skip line/0, statistis/0,told/0, true/0, ttyush/0, ttynl/0, var/1, version/0, write/1, writeq/1,write anonial/1.The following builtins are desribed by the bottom element of the groundnessdomain (usually false): abort/0, fail/0, false/0, halt/0, halt/1.The nal table details some (non-trivial) grounding dependenies.t1= t2f1$ f2t1=.. t2f1$ f2t1== t2f1$ f2C(t1, t2, t3) t1= [t2jt3℄arg(t1, t2, t3) f1^ (f3 f2) ompare(t1, t2, t3) f1urrent prediate(t1, t2) f1format(t1, t2) f1format(t1, t2, t3) f1^ f2funtor(t1, t2, t3) f2^ f3hash term(t1, t2) f2hash term(t1, t2, t3, t4) f2^ f3^ f4instane(t1, t2) f1keysort(t1, t2) f1$ f2length(t1, t2) f2portray lause(t1, t2) f1prediate property(t1, t2) f2print(t1, t2) f1read(t1, t2) f1sort(t1, t2) f1$ f2soure le(t1, t2) f2write(t1, t2) f1write anonial(t1, t2) f1writeq(t1, t2) f1For many goals, partial evaluation an be used to improve preision when thearguments of the goal are partially instantiated. For example, the uniationf(X; Y ) = f(U; V ) an be redued to the onjuntion X = U , Y = V whih,in turn, is desribed as (X $ U)^ (Y $ V ) rather than (X ^ Y )$ (U ^ V ).C/3 is handled by transforming the goal into an expliit uniation.8

Abstracting Builtins for Groundness Analysis

http://kar.kent.ac.uk/22058/1/Abstracting_Builtins_for_Groundness_Analysis.ps

Abstracting Builtins for Groundness Analysis

Abstract

Similar works

Full text

Available Versions

Kent Academic Repository