Towards Next Generation Logic Programming Systems

1. Towards Next Generation Logic Programming Systems Ajay Bansal Advisor: Dr. Gopal Gupta Applied Logic, Programming-Languages and Systems (ALPS) Lab The University of Texas at Dallas, Richardson, Texas, USA

2. Logic Programming • use of mathematical logic for computer programming • treats implications as goal-reduction procedures • B1 and … and Bn implies H, is interpreted as • to show/solve H, show/solve B1 and … and Bn • Prolog – the most representative LP language • H :- B1, …, Bn. • Algorithm = Logic + Control • where “Logic” represents a logic program and “Control” represents different theorem-proving strategies, which led to various extensions of Logic Programming

3. Extensions of Logic Programming • Constraint Logic Programming (CLP) : • generalization of logic programming • relations between variables can be stated in the form of constraints • special solvers (decision procedures) are used to solve subgoals (called constraints) involving a particular domain (e.g., real numbers, Boolean) • used for efficiently solving large scale scheduling and resource allocation problems

4. Extensions of Logic Programming • Tabled Logic Programming (Tabled LP) : • rules that match a goal are tried in a dynamic order • suspends execution when it encounters a variant goal, tries other rules • solutions found from other rules are used to resolve suspended goals & to resume their execution • provides completeness (w.r.t. least fixed point semantics) to Prolog • used for deductive verification, model checking, etc.

5. Extensions of Logic Programming • Co-Logic Programming (co-LP) : • extends traditional LP by allowing the use of coinduction • provides capability to reason about infinite objects and/or properties (as it computes greatest fixed point) • ideal for verification of real-time systems, model checking • Answer Set Programming (ASP) : • extends traditional LP by allowing the use of negation • provides capability to do non-monotonic reasoning • has been used for knowledge representation, practical planning problems, reasoning about action and change

6. Limitations of current LP systems • all extensions developed in isolation from others • techniques devised for implementing each of the extensions are quite complex • takes a long time to implement each extension atop an existing Prolog system • no current LP system combines more than two of the extensions • applications that require features from multiple extensions are very hard to encode

7. Model Checking To elegantly encode an -automata and to verify for both safety & liveness properties in model checking we need Tabled LP (safety properties) + co-LP (liveness properties)

8. Verification of Real-time systems To enumerate all infinite strings accepted by this automata and to verify properties of those strings, we need co-LP + CLP(R)

9. Timed Planning To encode planning problems, with real-time constraints on actions, requires the ability to do non-monotonic reasoning in presence of constraints. So we need CLP(R) + ASP

10. Next Generation LP System • Lot of research in LP resulting in advances: • CLP, Tabled LP, Parallelism, Coroutining, ASP, now co-LP • However, no “one stop shop” system • Dream: build this “one stop shop” system ASP Or-Parallelism CLP Next Generation Prolog System Tabled LP Coroutining Rule selection Goal selection co-LP

11. Our Insight • To design extremely simple yet efficient implementation techniques for incorporating each of the extensions in a Prolog system • It should be possible to incorporate these techniques in any existing Prolog system in 2 to 3 man months of work.

12. YAP Prolog (our choice for an existing Prolog system to extend) • open source • most efficient Prolog system available • has existing implementations for CLP and Tabled LP

13. Our Goal • To design a simple & efficient implementation technique to implement co-LP atop YAP Prolog • To design a simple & efficient implementation technique to implement a way to execute Answer Set Programs atop YAP Prolog

14. Circularity in Computer Science • Circular phenomenon are quite common in Computer Science: • Circular linked lists • Graphs (with cycles) • Controllers (run forever) • Bisimilarity • Interactive systems • Automata over infinite strings/Kripke structures • Perpetual processes • Logic/LP not equipped to model circularity

15. Circularity in LP systems • Circularity has been banned from automated theorem proving and logic programming through the occurs check: • An unbound variable cannot be unified with a term containing that variable • If occurs check is removed, we’ll generate circular (infinite) structures: • X = [1,2,3 | X] • Recent LP systems do allow for such circular structures (rational terms), but they only exist as data-structures, i.e., there is no proof theory to go along with it. • One can hold the data-structure in memory within an LP execution, but one can’t reason about it.

16. Coinduction • Circular structures are infinite structures X = [1, 2 | X] is logically speaking X = [1, 2, 1, 2, ….] • Proofs about their properties are infinite-sized • Coinduction is the technique for proving these properties • first proposed by Peter Aczel in the 80s • Systematic presentation of coinduction & its application to computing, math. and set theory: “Vicious Circles” by Moss and Barwise (1996) • Our focus: inclusion of coinductive reasoning techniques into LP and theorem proving

17. Applications of Coinduction • model checking • bisimilarity proofs • lazy evaluation in FP • reasoning with infinite structures • perpetual processes • cyclic structures • Type inference systems for lazy functional languages

18. Induction vs Coinduction • Induction is a mathematical technique for finitely reasoning about an infinite (countable) no. of things. • Examples of inductive structures: • Naturals: 0, 1, 2, … • Lists: [ ], [X], [X, X], [X, X, X], … • 3 components of an inductive definition: (1) Initiality, (2) iteration, (3) minimality • for example, the set of lists is specified as follows: [ ] – an empty list is a list (initiality) [H | T] is a list if T is a list and H is an element (iteration) nothing else is a list (minimality)

19. Induction vs Coinduction • Coinduction is a mathematical technique for (finitely) reasoning about infinite things. • Mathematical dual of induction • If all things were finite, then coinduction would not be needed. • Perpetual programs, automata over infinite strings • 2 components of a coinductive definition: (1) iteration, (2) maximality • for example, for a list: [ H | T ] is a list if T is a list and H is an element (iteration). Maximal set that satisfies the specification of a list. • This coinductive interpretation specifies all infinite sized lists

20. Inductive Logic Programming • Logic Programming • is actually inductive logic programming. • has definite programs with minimal Herbrand model declarative semantics (using least fixed-points) • terms: Herbrand universe U(P) • atoms: Herbrand base B(P) • useful for writing programs for reasoning about finite things: - data structures - properties

21. Infinite Objects and Properties • Traditional logic programming is unable to reason about infinite objects and/or properties. • Example: perpetual binary streams • traditional logic programming cannot handle this bit(0). bit(1). bitstream( [ H | T ] ) :- bit( H ), bitstream( T ). |?- X = [ 0, 1, 1, 0 | X ], bitstream( X ). • Goal: Combine traditional LP with coinductive LP

22. Overview of Coinductive LP • Coinductive Logic Program is a definite program with maximal co-Herbrand model declarative semantics. • Declarative Semantics: across the board dual of traditional LP: • greatest fixed-points • terms: co-Herbrand universe Uco(P) • atoms: co-Herbrand base Bco(P) • program semantics: maximal co-Herbrand model Mco(P).

23. Operational Semantics • nondeterministic state transition system • states are pairs of • a finite list of syntactic atoms [resolvent] (as in Prolog) • a set of syntactic term equations of the form x = f(x) or x = t • For a program p :- p. => the query |?- p. will succeed. • p( [ 1 | T ] ) :- p( T ). => |?- p(X) to succeed with X= [ 1 | X ]. • transition rules • definite clause rule • “coinductive hypothesis rule” • if a coinductive goal Q is called, and Q unifies with a call made earlier (e.g., P :- Q) then Q succeeds.

24. Implementation • Search strategy: hypothesis-first, leftmost, depth-first • Meta-Interpreter implementation. query(Goal) :- solve([],Goal). solve(Hypothesis, (Goal1,Goal2)) :- solve( Hypothesis, Goal1), solve(Hypothesis,Goal2). solve( _ , Atom) :- builtin(Atom), Atom. solve(Hypothesis,Atom):- member(Atom, Hypothesis). solve(Hypothesis,Atom):- notbuiltin(Atom), clause(Atom,Atoms), solve([Atom|Hypothesis],Atoms). • A more efficient implementation atop YAP also available

25. Example: Number Stream :- coinductive stream/1. stream( [ H | T ] ) :- num( H ), stream( T ). num( 0 ). num( s( N ) ) :- num( N ). |?- stream( [ 0, s( 0 ), s( s ( 0 ) ) | T ] ). • MEMO: stream( [ 0, s( 0 ), s( s ( 0 ) ) | T ] ) • MEMO: stream( [ s( 0 ), s( s ( 0 ) ) | T ] ) • MEMO: stream( [ s( s ( 0 ) ) | T ] ) Answers: T = [ 0, s(0), s(s(0)), s(s(0)) | T ] T = [ 0, s(0), s(s(0)), s(0), s(s(0)) | T ] T = [ 0, s(0), s(s(0)) | T ] . . . T = [ 0, s(0), s(s(0)) | X ] (where X is any rational list of numbers.)

26. Example: Comember member(H, [ H | T ]). member(H, [ X | T ]) :- member(H, T). ?- L = [1,2 | L], member(3, L) succeeds. Instead: :- coinductive comember/2. %drop/3 is inductive comember(X, L) :- drop(X, L, R), comember(X, R). drop(H, [ H | T ], T). drop(H, [ X | T ], T1) :- drop(H, T, T1). ?- X=[ 1, 2, 3 | X ], comember(2,X). ?- X = [1,2 | X], comember(3, X). Answer: yes. Answer: no ?- X=[ 1, 2, 3, 1, 2, 3], comember(2, X). Answer: no. ?- X=[1, 2, 3 | X], comember(Y, X). Answer: Y = 1; Y = 2; Y = 3;

27. Applications w/ addition of co-LP • Model checking - co-logic programming provides an elegant framework for verifying both safety & liveness properties in model checking using Tabled LP (for safety properties) + co-LP (for Liveness properties) • Verification of Real-Time Systems – -automata w/ time constrained transitions & stopwatches (Timed automata) can be encoded elegantly using CLP(R) + co-LP • Reasoning with properties of infinite structures – Tabled LP + co-LP provides a straight forward way to encode and verify properties of (Nested) finite or infinite automata

28. Answer Set Programming (ASP) • Answer set programming (ASP) is a popular formalism for non-monotonic reasoning • Applications in real-world reasoning, planning, etc. • Semantics given via lfp of a residual program obtained after “Gelfond-Lifschitz” transform • Popular implementations: Smodels, DLV, etc. • No goal-directed execution strategy available • ASP limited to only finitely groundable programs • Co-logic programming solves both these problems. • Also provides a goal-directed method to check if a proposition is true in some model of a prop. formula

29. Why Goal-directed ASP? • Most of the time, given a theory, we are interested in knowing if a particular goal is true or not. • Top down goal-directed execution provides operational semantics (important for usability) • Execution more efficient. - Tabled LP vs bottom up Deductive Deductive Databases • Why check the consistency of the whole knowledgebase? - - Inconsistency in some unrelated part will scuttle the whole system • Most practical examples anyway add a constraint to force the answer set to contain a certain goal. E.g. Zebra puzzle: :- not satisfied. • Answer sets of non-finitely groundable programs computable & Constraints incorporated in Prolog style.

30. Bottom-Up execution of ASP • Consider the following program, A: p :- not q. t. r :- t, s. q :- not p. s. A has 2 answer sets: {p, r, t, s} & {q, r, t, s}. • Now suppose we add the following rule to A: h :- p, not h. (falsify p) Only one answer set remains: {q, r, t, s} • Gelfond-Lifschitz Method: • Given an answer set S, for each p  S, delete all rules whose body contains “not p”; • delete all goals of the form “not q” in remaining rules • Compute the least fix point, L, of the residual program • If S = L, then S is an answer set

31. Goal-directed ASP • Consider the following program, A’: p :- not q. t. r :- t, s. q :- not p, r. s. h :- p, not h. • Separate into constraint and non-constraint rules: only 1 constraint rule in this case. • Execute the query under co-LP, candidate answer sets will be generated. • Keep the ones not rejected by the constraints. • Suppose the query is ?- q. Execution: q  not p, r  not not q, r  q, r  r  t, s  s  success. Ans = {q, r, t, s} • Next, we need to check that constraint rules will not reject the generated answer set. • (it doesn’t in this case)

32. Negation in Co-LP • Given a clause such as p :- q, not p. ?- p. fails coinductively when not p is encountered • To incorporate negation in coinductive reasoning, need a negative coinductive hypothesis rule: • In the process of establishing not(p), if not(p) is seen again in the resolvent, then not(p) succeeds • Also, not not p reduces to p. • Answer set programming takes into account failing computations: • p :- q, not p. is consistent if p = false and q = false • However, this takes away monotonicity: q can be constrainted to false, causing q to be withdrawn, if it was established earlier.

33. Goal-directed ASP • In general, for the constraint rules of p as head, p1:- B1. p2:- B2. ... pn :- Bn., generate rule(s) of the form: chk_p1 :- not(p1), B1. chk_p2 :- not(p2), B2. ... chk_pn :- not(p), Bn. • Generate: nmr_chk :- not(chk_p1), ... , not(chk_pn). • For each pred. definition, generate its negative version: not_p :- not(B1), not(B2), ... , not(Bn). • If you want to ask query Q, then ask ?- Q, nmr_chk. • Execution keeps track of atoms in the answer set (PCHS) and atoms not in the answer set (NCHS).

34. Goal-directed ASP • Consider the following program, P1: (i) p :- not q. (ii) q:- not r. (iii) r :- not p. (iv) q :- not p. P1 has 1 answer set: {q, r}. • Separate into: 3 constraint rules (i, ii, iii) 2 non-constraint rules (i, iv). p :- not(q).q :- not(r).r :- not(p).q :- not(p). chk_p :- not(p), not(q).chk_q :- not(q), not(r).chk_r :- not(r), not(p). nmr_chk :- not(chk_p), not(chk_q), not(chk_r). not_p :- q. not_q :- r, p.not_r :- p. Suppose the query is ?- r. Expand as in co-LP: r  not p  not not q  q (  not r  fail, backtrack)  not p  success. Ans={r, q} which satisfies the constraint rules of nmr_chk.

35. Applications w/ addition of ASP • Timed Planning (planning & scheduling) – Planning problems w/ real-time constraints can be encoded easily using CLP(R) + (Top-Down) ASP • Job Shop scheduling • Planning & Verification – can be modeled elegantly using (Top-Down) ASP + co-LP + Tabled LP • Spacecraft assembly, integration, and verification • Non-monotonic reasoning with Tabling & constraints

36. Application: Model Checking • automated verification of hardware and software systems • -automata • accept infinite strings • accepting state must be traversed infinitely often • requires computation of lfp and gfp • Tabled LP works for safety property (that is based on lfp) in an elegant manner, but not for liveness. • co-logic programming provides an elegant framework for checking liveness properties.

37. Safety versus Liveness • Safety • “nothing bad will happen” • naturally described inductively • straightforward encoding in Tabled LP • liveness • “something good will eventually happen” • dual of safety • naturally described coinductively • straightforward encoding in coinductive LP

38. Verifying Liveness Properties • Verifying safety properties in LP is relatively easy: safety modeled by reachability • Accomplished via tabled logic programming • Verifying liveness is much harder: a counter-example to liveness is an infinite trace • transformed into a safety check via use of negations in model checking and tabled LP • Considerable overhead incurred • co-LP solves the problem more elegantly: • Infinite traces that serve as counter-examples are easily produced as answers

39. Verifying Liveness Properties • Consider Safety: • Question: Is an unsafe state, Su, reachable (safe)? • If answer is yes, the path to Su is the counter-ex. • Consider Liveness, then dually • Question: Is a state, D, that should be dead, live? • If answer is yes, the infinite path containing D is the counter example • co-LP will produce this infinite path as the answer • Checking for liveness is just as easy as checking for safety

40. Dining Philosophers Problem (DPP) • five philosophers sitting at a circular table doing one of two things – either eating or thinking • each philosopher has one fork to the left and one fork to the right that they use while eating • problem is to find a fair, deadlock free, starvation free algorithm for philosophers to access the forks

41. DPP – Safety: Deadlock Free • One potential solution • Force one philosopher to pick forks in different order than others • Checking for deadlock • Bad state is not reachable • Implemented using Tabled LP :- table reach/2. reach(Si, Sf) :- trans(_,Si,Sf). reach(Si, Sf) :- trans(_,Si,Sfi), reach(Sfi,Sf). ?- reach([1,1,1,1,1], [2,2,2,2,2]). no

42. DPP – Liveness: Starvation Free • Phil. waits forever on a fork • One potential solution • phil. waiting longest gets the access • implemented using CLP(R) • Checking for starvation • once in bad state, is it possible to remain there forever • implemented using co-LP ?- starved(X). no

43. Application: Timed Planning • (Acc. to MIT ency. of Cognitive Science) Planning is the process of generating (partial) representations of future behavior in order to constrain or control that behavior • the outcome is usually a set of actions, with temporal and other constraints on them • Action description languages (like A) describe domains (with actions and change) used for planning problems • Timed Planning is planning in presence of time constraints • Language AT (extension of A) can be used to describe domains with real-time constraints on actions • No elegant executable encoding of AT programs as it requires ASP + CLP(R) in a single framework

44. Real-Time Soccer Playing Domain

45. Real-Time Soccer Playing Domain • holds(clearShot, res(passBall,S)) :- not_holds(clearShot, S), b_getval(clock, Clock), {Clock =< 1}, {NewClock > 0}, b_setval(clock, NewClock). • not_holds(hasBall, res(wait,S)) :- holds(hasBall,S), b_getval(clock,Clock), {Clock > 1}, {NewClock > Clock}, b_setval(clock,NewClock). If clearShot is false in the initial state, then the query ?- holds(goal, S). % produces the solution S = res(shotTaken, res(passBall, s0))

46. Contributions & Timeline • Design of “Coinductive Logic Programming” and “Co-Logic Programming” languages. (Completed – July, 2006) • A simple (and efficient) implementation technique to implement the above mentioned languages atop an existing Prolog engine. (Completed – December, 2006) • A Top-Down algorithm for goal-directed execution of propositional ASP. (Completed – July, 2007) • A simple (and efficient) implementation technique to implement the goal-directed ASP atop an existing Prolog engine. (Completed – September, 2007) • Applications justifying the combinations of co-LP, CLP, ASP and Tabled LP. (Completed – October, 2007)

47. Future Work • Automatic generation of co-LP programs for model checking applications described in CCS + μ-calculus • Extend our goal-directed, propositional ASP engine to work for (full) predicate ASP • Automatic generation of ASP + CLP(R) programs for real-time domains described in the language AT • Apply our integrated framework to encode larger applications in model checking, timed planning, etc.

48. Publications Conference & Workshops: • Coinductive Logic Programming and Its Applications; G. Gupta,A. Bansal, R. Min, L. Simon, A. Mallya, ICLP, 2007 • Goal-Directed Execution of Answer Set Programs; A. Bansal, R. Min and G. Gupta, submitted to ETAPS, 2008 • Co-Logic Programming: Extending Logic Programming with Coinduction; L. Simon, A. Bansal, A. Mallya and G, Gupta, ICALP, July 200 • Co-Inductive Logic Programming, Intl. Conference on Logic Programming; L. Simon, A. Mallya, A. Bansal and G. Gupta, ICLP at FLoC 2006 • Combining Traditional and Coinductive Logic Programming; L. Simon, A. Mallya, A. Bansal and G. Gupta, SVV Workshop at FLoC 2006 • Automatic Composition of Semantic Web Services; S. Kona, A. Bansal and G. Gupta, IEEE ICWS 2007

49. Publications (contd.) • A Universal Service-Semantics Description Language; A. Bansal, S. Kona, G. Gupta, et.al., IEEE ECOWS 2005(Won Best Paper Award) • Towards Intelligent Services: A Case Study in Chemical Emergency Response System; A. Bansal, K. Patel, G. Gupta, et. al., IEEE ICWS 2005 Journal: • Extending Logic Programming with Coinduction; L. Simon, A. Bansal, A. Mallya, G. Gupta, in preparation for submission to special issue on Co algebra and Logic in the Journal of Logic and Computation • USDL: A Service-Semantics Description Language for Automatic Service Discovery and Composition; S. Kona, A. Bansal, L. Simon, A. Mallya, G. Gupta, and T. Hite, under 2nd round of review for Journal of Web Services Research • Towards Intelligent Services: A Case Study in Chemical Emergency Response; A. Bansal, K. Patel, G. Gupta, B. Raghavachari, J. Staves and E. Harris, under review at Journal of Software Practice & Experience

50. Towards Next Generation Logic Programming Systems ? For more details contact ajay.bansal@student.utdallas.edu