Imperative Program Synthesis from Answer Set Programs
BB. Bogaerts, E. Erdem, P. Fodor, A. Formisano,G. Ianni, D. Inclezan, G. Vidal, A. Villanueva,M. De Vos, F. Yang (Eds.): InternationalConference on Logic Programming 2019 (ICLP’19).EPTCS 306, 2019, pp. 413–417, doi:10.4204/EPTCS.306.55
Imperative Program Synthesis from Answer Set Programs
Sarat Chandra Varanasi
University of Texas at Dallas, Richardson, TX, United States [email protected]
Our research concerns generating imperative programs from Answer Set Programming Specifica-tions. ASP is highly declarative and is ideal for writing specifications. Further with negation-as-failure it is easy to succinctly represent combinatorial search problems. We are currently working onsynthesizing imperative programs from ASP programs by turning the negation into useful computa-tions. This opens up a novel way to synthesize programs from executable specifications.
Our research area is broadly in Program Synthesis from Logical Specifications. Currently we are workingon synthesizing imperative code from Answer Set Programming specifications. ASP enables one tosuccinctly model various planning and combinatorial search problems [5]. These specifications heavilyuse negation-as-failure which is the cornerstone feature of ASP. What ASP represent are executablespecifications. We want to transform them into meaningful and efficient imperative programs. We targetimperative programs because our overarching goal is to be able to synthesize concurrent data structuresfrom concurrency specifications written in ASP.Concurrent Programs are very difficult to design and debug. Our idea is to partially evaluate the ASPconcurrency specification with respect to the operational semantics provided by s(ASP) [1, 9] and obtainconcurrent imperative code adhering to the specification.Concurrent In ASP, specification and computation are synonymous which is highly desirable torapidly prototype systems [2]. However the implementations of ASP are quite complex [3, 4]. On theother hand, imperative programs reflect a simpler operational model of computation making them easierto trace and in general enjoy faster run-times than their declarative program counterparts. This is becauseimperative programs often represent computationally faster implementations of a specification withoutdirectly being concerned about the specification. This makes deriving imperative programs from ASPspecifications highly desirable. Our main insight is to employ the recently-developed operational seman-tics for ASP realized in the s(ASP) system [9, 1]. s(ASP) is a query-driven answer set programmingsystem which computes the (partial) stable models of a query against an answer set program withoutgrounding the program first. Traditional implementations of ASP are based on grounding the program toits propositional equivalent and then use a procedure similar to SAT solvers to compute the answer sets [4]. Using the operational semantics of s(ASP), one can follow how the stable models are computed for aquery in a step-by-step manner. This provides us the right playground, to extract an imperative programwhile simplifying all the machinery that makes s(ASP) work.
Program synthesis has been tackled in various ways. One of the earliest works are related to theorem-proving [8]. More recently synthesis has been reduced to verification [14, 13]. The work of Srivastava14 Imperative Program Synthesis fromAnswerSetProgramset al. [14] assumes a logical input-output specification and generates finite syntactic program structures(candidate programs) and then use Hoare-logic [6] to verify that the syntactic structures indeed satisfy theinput-output specifications. To that end, verification is reduced to constraint-solving. We take a differentdirection in our research. The correct computational specifications are already given. All we need to dois to sieve out an imperative program. To our knowledge, no one else has attempted transforming ASPspecifications to imperative programs till date.
Prominent Features of s(ASP):
We next summarize the salient features of the s(ASP) system that arerelevant to our work here. The operational semantics of s(ASP) is a Prolog style execution of an issuedquery adhering to the stable model semantics. The query triggers a search where all clauses that areconsistent are resolved and backtracking happens when inconsistent goals are encountered. All the termsencountered in the consistent goals constitute the “partial” stable model associated with the query. Nogrounding of clauses is needed. The procedure to decide which clauses are consistent or inconsistent isquite sophisticated. At a simple level, the current resolvent is invalid when during expansion it leads toa stable model that has both a goal and its negation. This is in fact the way how stable models are con-structed in the propositional variant of s(ASP), namely Galliwasp [10]. Note that the execution algorithmof s(ASP) relies on corecursion [12] to handle even loops [9], but this feature is not as important for thework reported here.
Handling negation with Dual rules:
In s(ASP) negated goals are executed through dual rules. Thedual rule of a predicate p systematically negates the literals in a rule body defining p . Dual rules of allpredicates together with the rules in the original program represent its completion [7]. For instance, thedual rule of the predicate p with the following definition is shown below: % d e f i n i t i o n of p % dual of p /0p : - not q . not p : - np 1 , np2p : - r , not s . % negating of not q yields qnp1 : - q .% negating r , not s yields% d i s j u n c t i o n ( not r ) ∨ s np2 : - not r .np2 : - s . Forall mechanism:
We have just shown dual rules for propositions which are simple enough. However,writing dual rules for predicates is more involved. One complication is due to implicit quantifiers inpredicate rules. For a rule such as: p ( X ) : - q ( Y ) , r ( X ). X is universally quantified over the whole formula, whereas Y is existentially quantified in the body only.Therefore, negating p ( X ) results in Y being universally quantified in the body as follows: not p ( X ) : - np1 ( X ) , np2 ( X ).np1 ( X ) : - forall (Y , not q ( Y )).np2 ( X ) : - not r ( X ). Notice that the universal quantifier for Y in not q ( Y ) is enclosed within a f orall ( ... ) . The f orall repre-sents a proof procedure which runs through all values in the domain of Y and verifies if the goal enclosedarat Chandra Varanasi 415within it is satisfied. In our example, the f orall checks that not q ( Y ) holds for all values of in the domainof Y . No such mechanism existed in prior Prolog based systems. It is this f orall mechanism coupledwith dual rules that we make extensive use of in our synthesis procedure. Because they treat negatedpredicates constructively [9], we turn them into computations in our synthesis procedure. As mentioned before, our main goal is to synthesize efficient concurrent programs. Writing programs thatare correct-by-construction is highly desirable because it automatically alleviates the burden of testing,debugging and formal verification. Our research is centered around the s(ASP) system which is still inexperimental stage. The s(ASP) system provides a valid operational semantics. This enables a user toissue a query and get answer sets relevant to his query. This is to be contrasted with traditional ASPsolvers which ground the entire program and solve answer sets using some form of SAT-solving [4].Another goal is to speedup the s(ASP) system by fine-tuning the goal-directed execution. Currently thetop-down query evaluation in s(ASP) needs further improvement in performance. This is due to the wayconstraints are handled by the s(ASP) engine. This is addressed in Section 6. We are able to synthesize sequential combinatorial algorithms such as graph-coloring, n-queens etc.We are progressing towards dynamic domains such as planning problems. For instance, modelling aconcurrent linked list is no different than blocks-world planning. The blocks-world problem can bedescribed in the
Action language A [5]. A concurrent list also represents a dynamic domain. Forexample, updating the nodes in a list are no different than placing one block over another. The updatesare subject to having “locks”. These restrictions represent executability conditions in Action languages.We have written the entire specification of a concurrent list execution. What remains is to come up withan appropriate procedure to extract the corresponding imperative algorithm. Right now we can synthesize imperative programs for a class of datalog answer set programs. Furtherall the variables in the ASP program must be safe and come from finite domains. To properly motivateour work we give the following example.Consider the ASP program that finds the maximum of n numbers, that is naturally specified in ASPas shown below: max ( X ) : - num ( X ) , not smaller ( X ).smaller ( X ) : - num ( X ) , num ( Y ) , X < Y . num ( X ) provides the domain of numbers over which the input values range. smaller ( X ) defines whena number X is dominated by another number Y . max ( X ) gives the definition for X to be the maximum.The main predicate from where the computation to decide whether a given number X is the maximumbegins with max ( X ) . The negation of smaller ( X ) can be translated to a f orall as shown below: not smaller ( X ) : - forall (Y , not ( num ( X ) , num ( Y ) , X < Y )). As stated earlier, s(ASP) is experimental yet
16 Imperative Program Synthesis fromAnswerSetProgramsAssuming that num ( X ) and num ( Y ) are true, the negation only applies to X < Y . Therefore, replacingthe definition of not smaller ( X ) in max ( X ) gives us the following: max ( X ) : - forall (Y , num ( X ) , num ( Y ) , not ( X < Y )). The f orall definition of max ( X ) makes apparent the operational flavor involved in finding the maxi-mum of n numbers: enumerate all numbers Y and compare them with X . If X is not smaller than any Y ie. X < Y is false for all Y , then X is maximum. The f orall can be translated to a for-loop in imperativelanguages if the domains of the variables involved in the scope of f orall are finite. From an AnswerSet Programming point of view, max ( X ) is present in the answer set if the f orall succeeds (if X is themaximum), otherwise it is not present. The abstract code synthesized through program tranformation,thus looks like: def max ( x ):for y in num :if x < y :return Falsereturn True We have submitted an entire paper explaining this idea in detail to the LOPSTR 2019 conference. Themain insight is that the f orall mechanism from s(ASP) can be directly translated into for-loops (atleastfor finite domains).
The work reported here is the first step towards obtaining efficient implementation from high level spec-ifications. Our eventual goal is to specify algorithms (e.g., inserting, deleting, and checking for member-ship of an element) for concurrent data structures (lists, queues, trees, heaps, etc.) as answer set programsand automatically be able to obtain the efficient, imperative versions of those algorithms. Achieving sucha goal requires making extensive use of partial evaluation and semantics-preserving re-arrangement ofgoals in the current resolvent. It is part of our future work. Currently our synthesis procedure does nothandle global constraints (head-less rules in ASP). For example our work supports synthesis of the graphcoloring problem written in the form: color (X , C ) : - node ( X ) , color ( C ) , not a n o t h e r _ c o l o r (X , C ) ,not conflict (X , C ).a n o t h e r _ c o l o r (X , C ) : - node ( X ) , color ( C ) , color ( C1 ) , C != C1 ,color (X , C1 ).conflict (X , C ) : - node ( X ) , color ( C ) , node ( Y ) , X != Y , edge (X , Y ) ,color (X , C ) , color (Y , C ).
But not the form written with global constraints as follows: color (X , C ) : - node ( X ) , color ( C ) , not a n o t h e r _ c o l o r (X , C ).a n o t h e r _ c o l o r (X , C ) : - node ( X ) , color ( C ) , node ( Y ) ,X != Y , color (Y , C ).: - color (X , C ) , color (Y , C ) , edge (X , Y ). arat Chandra Varanasi 417Essentially, we should be able to take constraints and move them up in the resolvent to the earliestpoint where this constraint can be executed.Handling global constraints is closely related to dynamic consistency checking (DCC) in goal-directed answer set programs [11, 10]. DCC ensures only the necessary constraints, that are relevantto a rule and the possible bindings variables could take, are checked along with the rule-body. All otherconstraints which are not relevant to the rule can be ignored. This has been addressed for ground an-swer set programs. Our future work focuses on providing DCC for predicates. This would also enablesynthesis of programs specifying dynamic domains such as data structures, and planning problems.
References [1] Joaquin Arias, Manuel Carro, Elmer Salazar, Kyle Marple & Gopal Gupta (2018):
Constraint answer setprogramming without grounding . TPLP 18(3-4), pp. 337–354, doi: .[2] Thomas Eiter (2005):
Data integration and answer set programming . In: LPNMR, Springer, pp. 13–25,doi: .[3] Thomas Eiter, Georg Gottlob & Heikki Mannila (1997):
Disjunctive datalog . ACM TODS 22(3), pp. 364–418, doi: .[4] Martin Gebser, Nicola Leone, Marco Maratea, Simona Perri, Francesco Ricca & Torsten Schaub (2018):
Evaluation Techniques and Systems for Answer Set Programming: a Survey . In: IJCAI, ijcai.org, pp. 5450–5456, doi: .[5] M. Gelfond & Y. Kahl (2014):
Knowledge representation, reasoning, and the design of intelligent agents:The answer-set programming approach . Cambridge Univ. Press, doi: .[6] Charles Antony Richard Hoare (1969):
An axiomatic basis for computer programming . CommunicationsoftheACM 12(10), pp. 576–580, doi: .[7] John W Lloyd (1987):
Foundations of logic programming . Springer, doi: .[8] Z. Manna & R. J. Waldinger (1971):
Towards automatic program synthesis . In: Symp.onSemanticsofAlgo.Lang., Springer, pp. 270–310, doi: .[9] K. Marple, E. Salazar & G. Gupta (2017):
Computing stable models of normal logic programs withoutgrounding . arXiv:1709.00501.[10] Kyle Marple, Ajay Bansal, Richard Min & Gopal Gupta (2012):
Goal-directed execution of answer setprograms . In: Proc.14 th PPDPSymposium, ACM, pp. 35–44, doi: .[11] Kyle Marple & Gopal Gupta (2014):
Dynamic consistency checking in goal-directed answer set program-ming . TPLP 14(4-5), pp. 415–427, doi: .[12] Luke Simon, Ajay Mallya, Ajay Bansal & Gopal Gupta (2006):
Coinductive logic programming . In: Inter-nationalConferenceonLogicProgramming, Springer, pp. 330–345, doi: .[13] Armando Solar-Lezama, Liviu Tancau, Rastislav Bodik, Sanjit Seshia & Vijay Saraswat (2006):
Combina-torial sketching for finite programs . ACM Sigplan Notices 41(11), pp. 404–415, doi: .[14] S. Srivastava, S. Gulwani & J. S. Foster (2010):
From program verification to program synthesis . In: ACMSigplanNotices, 45(1):313-326, doi:10.1145/1707801.1706337