Editing Logic programming (section)

==Variants and extensions==

===Prolog===
{{Main|Prolog}}

The SLD resolution rule of inference is neutral about the order in which subgoals in the bodies of clauses can be ''selected'' for solution. For the sake of efficiency, Prolog restricts this order to the order in which the subgoals are written. SLD is also neutral about the strategy for searching the space of SLD proofs.
Prolog searches this space, top-down,  depth-first, trying different clauses for solving the same (sub)goal in the order in which the clauses are written.

This search strategy has the advantage that the current branch of the tree can be represented efficiently by a [[Stack (abstract data type)|stack]]. When a goal clause at the top of the stack is reduced to a new goal clause, the new goal clause is pushed onto the top of the stack. When the selected subgoal in the goal clause at the top of the stack cannot be solved, the search strategy ''[[Backtracking|backtracks]]'', removing the goal clause from the top of the stack, and retrying the attempted solution of the selected subgoal in the previous goal clause using the next clause that matches the selected subgoal.

Backtracking can be restricted by using a subgoal, called ''[[Cut (logic programming)|cut]]'', written as !, which always succeeds but cannot be backtracked. Cut can be used to improve efficiency, but can also interfere with the logical meaning of clauses. In many cases, the use of cut can be replaced by negation as failure. In fact, negation as failure can be defined in Prolog, by using cut, together with any literal, say ''fail'', that unifies with the head of no clause:
<syntaxhighlight lang="prolog">
not(P) :- P, !, fail.
not(P).
</syntaxhighlight>

Prolog provides other features, in addition to cut, that do not have a logical interpretation. These include the built-in predicates ''assert'' and ''retract'' for destructively updating the state of the program during program execution.

For example, the [[#Knowledge representation|toy blocks world example above]] can be implemented without frame axioms using destructive change of state:

<syntaxhighlight lang="prolog">
on(green_block, table).
on(red_block, green_block).

move(Object, Place2) :- 
	retract(on(Object, Place1)), 
	assert(on(Object, Place2).
</syntaxhighlight>

The sequence of move events and the resulting locations of the blocks can be computed by executing the query:
<syntaxhighlight lang="prolog">
?- move(red_block, table), move(green_block, red_block), on(Object, Place).

Object = red_block,
Place = table.
Object = green_block,
Place = red_block.
</syntaxhighlight>

Various extensions of logic programming have been developed to provide a logical framework for such destructive change of state.<ref name="TL">Bonner, A.J. and Kifer, M., 1993, February. Transaction Logic Programming. In ICLP (Vol. 93, pp. 257-279).</ref><ref>Genesereth, M., 2023. Dynamic logic programming. In Prolog: The Next 50 Years (pp. 197-209). Cham: Springer Nature Switzerland.</ref><ref>Kowalski, R., Sadri, F., Calejo, M. and Dávila, J., 2023. Combining logic programming and imperative programming in LPS. In Prolog: The Next 50 Years (pp. 210-223). Cham: Springer Nature Switzerland.</ref>

The broad range of Prolog applications, both in isolation and in combination with other languages is highlighted in the Year of Prolog Book,<ref name="Prolog Book"/> celebrating the 50 year anniversary of Prolog in 2022.

Prolog has also contributed to the development of other programming languages, including [[Algebraic Logic Functional programming language|ALF]], [[Fril]], [[Gödel (programming language)|Gödel]], [[Mercury programming language|Mercury]], [[Oz (programming language)|Oz]], [[Ciao (programming language)|Ciao]], [[Visual Prolog]], [[XSB]], and [[λProlog]].

===Constraint logic programming===
{{Main|Constraint logic programming}}
[[Constraint logic programming]] (CLP) combines Horn clause logic programming with [[constraint solving]]. It extends Horn clauses by allowing some predicates, declared as constraint predicates, to occur as literals in the body of a clause. Constraint predicates are not defined by the facts and rules in the program, but are predefined by some domain-specific model-theoretic structure or theory.

Procedurally, subgoals whose predicates are defined by the program are solved by goal-reduction, as in ordinary logic programming, but constraints are simplified and checked for satisfiability by a domain-specific constraint-solver, which implements the semantics of the constraint predicates. An initial problem is solved by reducing it to a satisfiable conjunction of constraints.

Interestingly, the first version of Prolog already included a constraint predicate dif(term1, term2), from Philippe Roussel's 1972 PhD thesis, which succeeds if both of its arguments are different terms, but which is delayed if either of the terms contains a variable.<ref name=":02"/>

The following constraint logic program represents a toy temporal database of <code>john's</code> history as a teacher:
<syntaxhighlight lang="prolog">
teaches(john, hardware, T) :- 1990 ≤ T, T < 1999.
teaches(john, software, T) :- 1999 ≤ T, T < 2005.
teaches(john, logic, T) :- 2005 ≤ T, T ≤ 2012.
rank(john, instructor, T) :- 1990 ≤ T, T < 2010.
rank(john, professor, T) :- 2010 ≤ T, T < 2014.
</syntaxhighlight>
Here <code>≤</code> and <code><</code> are constraint predicates, with their usual intended semantics. The following goal clause queries the database to find out when <code>john</code> both taught <code>logic</code> and was a <code>professor</code>:
<syntaxhighlight lang="prolog">
?- teaches(john, logic, T), rank(john, professor, T).
</syntaxhighlight>
The solution 
<code>
2010 ≤ T, T ≤ 2012
</code>
results from simplifying the constraints
<code>
2005 ≤ T, T ≤ 2012, 2010 ≤ T, T < 2014.
</code>

Constraint logic programming has been used to solve problems in such fields as [[civil engineering]], [[mechanical engineering]], [[digital circuit]] verification, [[automated timetabling]], [[air traffic control]], and finance. It is closely related to [[abductive logic programming]].

=== Datalog ===
{{Main|Datalog}}
Datalog is a database definition language, which combines a relational view of data, as in [[relational database]]s, with a logical view, as in logic programming.

Relational databases use a relational calculus or relational algebra, with [[Relational database#Relational operations|relational operations]], such as ''union'', ''intersection'', ''set difference'' and ''cartesian product'' to specify queries, which access  a database. Datalog uses logical connectives, such as ''or'', ''and'' and ''not'' in the bodies of rules to define relations as part of the database itself.

It was recognized early in the development of relational databases that recursive queries cannot be expressed in either relational algebra or relational calculus, and that this defficiency can be remedied by introducing a least-fixed-point operator.<ref>Aho, A.V. and Ullman, J.D., 1979, January. Universality of data retrieval languages. In Proceedings of the 6th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (pp. 110-119).</ref><ref>Maier, D., Tekle, K.T., Kifer, M. and Warren, D.S., 2018. Datalog: concepts, history, and outlook. In Declarative Logic Programming: Theory, Systems, and Applications (pp. 3-100).</ref> In contrast, recursive relations can be defined naturally by rules in logic programs, without the need for any new logical connectives or operators.

Datalog differs from more general logic programming by having only constants and variables as terms. Moreover, all facts are variable-free, and rules are restricted, so that if they are executed bottom-up, then the derived facts are also variable-free.

For example, consider the family database:

<syntaxhighlight lang="prolog">
mother_child(elizabeth, charles).
father_child(charles, william).
father_child(charles, harry).
parent_child(X, Y) :- 
     mother_child(X, Y).
parent_child(X, Y) :- 
     father_child(X, Y).
ancestor_descendant(X, Y) :- 
     parent_child(X, X).
ancestor_descendant(X, Y) :- 
     ancestor_descendant(X, Z), 
     ancestor_descendant(Z, Y).
</syntaxhighlight>

Bottom-up execution derives the following set of additional facts and terminates:

<syntaxhighlight lang="prolog">
parent_child(elizabeth, charles).
parent_child(charles, william).
parent_child(charles, harry).

ancestor_descendant(elizabeth, charles).
ancestor_descendant(charles, william).
ancestor_descendant(charles, harry).

ancestor_descendant(elizabeth, william).
ancestor_descendant(elizabeth, harry).
</syntaxhighlight>

Top-down execution derives the same answers to the query:
<syntaxhighlight lang="prolog">
?- ancestor_descendant(X, Y).
</syntaxhighlight>

But then it goes into an infinite loop. However, top-down execution with [[Tabled logic programming|tabling]] gives the same answers and terminates without looping.

=== Answer set programming ===
{{Main|Answer Set Programming}}

Like Datalog, Answer Set programming (ASP) is not Turing-complete. Moreover, instead of separating goals (or queries) from the program to be used in solving the goals, ASP  treats the whole program as a goal, and solves the goal by generating a stable model that makes the goal true. For this purpose, it uses the [[stable model semantics]], according to which a logic program can have zero, one or more intended models. For example, the following program represents a degenerate variant of the map colouring problem of colouring two countries red or green:
<syntaxhighlight lang="prolog">
country(oz).
country(iz).
adjacent(oz, iz).
colour(C, red) :- country(C), not(colour(C, green)).
colour(C, green) :- country(C), not(colour(C, red)).
</syntaxhighlight>

The problem has four solutions represented by four stable models:
<syntaxhighlight lang="prolog">
country(oz). country(iz). adjacent(oz, iz). colour(oz, red).   colour(iz, red).

country(oz). country(iz). adjacent(oz, iz). colour(oz, green). colour(iz, green).

country(oz). country(iz). adjacent(oz, iz). colour(oz, red).   colour(iz, green).

country(oz). country(iz). adjacent(oz, iz). colour(oz, green). colour(iz, red).
</syntaxhighlight>

To represent the standard version of the map colouring problem, we need to add a constraint that two adjacent countries cannot be coloured the same colour. In ASP, this constraint can be written as a clause of the form:
<syntaxhighlight lang="prolog">
:- country(C1), country(C2), adjacent(C1, C2), colour(C1, X), colour(C2, X).
</syntaxhighlight>

With the addition of this constraint, the problem now has only two solutions:
<syntaxhighlight lang="prolog">
country(oz). country(iz). adjacent(oz, iz). colour(oz, red).   colour(iz, green).

country(oz). country(iz). adjacent(oz, iz). colour(oz, green). colour(iz, red).
</syntaxhighlight>
The addition of constraints of the form <code>:- Body.</code> eliminates models in which <code>Body</code> is true.

Confusingly, ''constraints in ASP'' are different from ''constraints in CLP''. Constraints in CLP are predicates that qualify answers to queries (and solutions of goals). Constraints in ASP are clauses that eliminate models that would otherwise satisfy goals. Constraints in ASP are like integrity constraints in databases.

This combination of ordinary logic programming clauses and constraint clauses illustrates the generate-and-test methodology of problem solving in ASP: The ordinary clauses define a search space of possible solutions, and the constraints filter out unwanted solutions.<ref>Eiter, T., Ianni, G. and Krennwallner, T., 2009. Answer Set Programming: A Primer. In Reasoning Web. Semantic Technologies for Information Systems: 5th International Summer School 2009, Brixen-Bressanone, Italy, August 30-September 4, 2009, Tutorial Lectures (pp. 40-110).</ref>

Most implementations of ASP proceed in two steps: First they instantiate the program in all possible ways, reducing it to a propositional logic program (known as ''grounding''). Then they apply a propositional logic problem solver, such as the [[DPLL algorithm]] or a [[Boolean SAT solver]]. However, some implementations, such as s(CASP)<ref>{{cite journal |first1=J. |last1=Arias |first2=M. |last2=Carro |first3=E. |last3=Salazar |first4=K. |last4=Marple |first5=G. |last5=Gupta |title=Constraint Answer Set Programming without Grounding |journal=Theory and Practice of Logic Programming |volume=18 |issue=3–4 |pages=337–354 |date=2018|doi=10.1017/S1471068418000285 |s2cid=13754645 |doi-access=free |arxiv=1804.11162 }}</ref> use a goal-directed, top-down, SLD resolution-like procedure without
grounding.

===Abductive logic programming===
{{Main|Abductive logic programming}}
[[Abductive logic programming]]<ref>{{cite journal |first1=M. |last1=Denecker |first2=A.C. |last2=Kakas |title=Special issue: abductive logic programming |journal=Journal of Logic Programming |volume=44 |issue=1–3 |pages=1–4 |date=July 2000 |doi=10.1016/S0743-1066(99)00078-3 |doi-access=free }}</ref> (ALP), like CLP, extends normal logic programming by allowing the bodies of clauses to contain literals whose predicates are not defined by clauses. In ALP, these predicates are declared as ''abducible'' (or ''assumable''), and are used as in [[Abductive reasoning#Formalizations of abduction#Logic-based abduction|abductive reasoning]] to explain observations, or more generally to add new facts to the program (as assumptions) to solve goals.

For example, suppose we are given an initial state in which a red block is on a green block on a table at time 0:
<syntaxhighlight lang="prolog">
holds(on(green_block, table), 0).
holds(on(red_block, green_block), 0).
</syntaxhighlight>

Suppose we are also given the goal:
<syntaxhighlight lang="prolog">
?- holds(on(green_block,red_block), 3), holds(on(red_block,table), 3).
</syntaxhighlight>

The goal can represent an observation, in which case a solution is an explanation of the observation. Or the goal can represent a desired future state of affairs, in which case a solution is a plan for achieving the goal.<ref>Eshghi, K., 1988, August. Abductive Planning with Event Calculus. In ICLP/SLP (pp. 562-579).</ref>

We can use the rules for cause and effect presented earlier to solve the goal, by treating the <code>happens</code> predicate as abducible:

<syntaxhighlight lang="prolog">
holds(Fact, Time2) :- 
    happens(Event, Time1),
    Time2 is Time1 + 1,
    initiates(Event, Fact).
     
holds(Fact, Time2) :- 
	happens(Event, Time1),
    Time2 is Time1 + 1,
    holds(Fact, Time1),
    not(terminated(Fact, Time1)).
    
terminated(Fact, Time) :-
   happens(Event, Time),
   terminates(Event, Fact).

initiates(move(Object, Place), on(Object, Place)).
terminates(move(Object, Place2), on(Object, Place1)).
</syntaxhighlight>

ALP solves the goal by reasoning backwards and adding assumptions to the program, to solve abducible subgoals. In this case there are many alternative solutions, including:

<syntaxhighlight lang="prolog">
happens(move(red_block, table), 0).
happens(tick, 1).
happens(move(green_block, red_block), 2).
</syntaxhighlight>

<syntaxhighlight lang="prolog">
happens(tick,0).
happens(move(red_block, table), 1).
happens(move(green_block, red_block), 2).
</syntaxhighlight>

<syntaxhighlight lang="prolog">
happens(move(red_block, table), 0).
happens(move(green_block, red_block), 1).
happens(tick, 2).
</syntaxhighlight>
Here <syntaxhighlight inline lang="prolog">tick</syntaxhighlight> is an event that marks the passage of time without initiating or terminating any fluents.

There are also solutions in which the two <code>move</code> events happen at the same time. For example:
<syntaxhighlight lang="prolog">
happens(move(red_block, table), 0).
happens(move(green_block, red_block), 0).
happens(tick, 1).
happens(tick, 2).
</syntaxhighlight>

Such solutions, if not desired, can be removed by adding an integrity constraint, which is like a constraint clause in ASP:

<syntaxhighlight lang="prolog">
:- happens(move(Block1, Place), Time), happens(move(Block2, Block1), Time).
</syntaxhighlight>

Abductive logic programming has been used for fault diagnosis, planning, natural language processing and machine learning. It has also been used to interpret negation as failure as a form of abductive reasoning.<ref>Eshghi, K. and Kowalski, R.A., 1989, June. Abduction Compared with Negation by Failure. In ICLP (Vol. 89, pp. 234-255).</ref>

===Inductive logic programming===
{{Main|Inductive logic programming}}

Inductive logic programming (ILP) is an approach to [[machine learning]] that [[Inductive reasoning|induces]] logic programs as hypothetical generalisations of positive and negative examples. Given a logic program representing background knowledge and positive examples together with constraints representing negative examples, an ILP system induces a logic program that generalises the positive examples while excluding the negative examples.

ILP is similar to ALP, in that both can be viewed as generating hypotheses to explain observations, and as employing constraints to exclude undesirable hypotheses. But in ALP the hypotheses are variable-free facts, and in ILP the hypotheses are general rules.<ref>{{Cite book |last1=Nienhuys-Cheng |first1=Shan-hwei |title=Foundations of inductive logic programming |last2=Wolf |first2=Ronald de |date=1997 |publisher=Springer |isbn=978-3-540-62927-6 |series=Lecture notes in computer science Lecture notes in artificial intelligence |location=Berlin Heidelberg |page=173}}</ref><ref>Flach, P.A. and Kakas, A.C., 2000. On the relation between abduction and inductive learning. In Abductive Reasoning and Learning (pp. 1-33). Dordrecht: Springer Netherlands.</ref>

For example, given only background knowledge of the mother_child and father_child relations, and suitable examples of the grandparent_child relation, current ILP systems can generate the definition of grandparent_child, inventing an auxiliary predicate, which can be interpreted as the parent_child relation:<ref>Cropper, A. and Dumančić, S., 2022. Inductive logic programming at 30: a new introduction. Journal of Artificial Intelligence Research, 74, pp.765-850.</ref>

<syntaxhighlight lang="prolog">
grandparent_child(X, Y):- auxiliary(X, Z), auxiliary(Z, Y).
auxiliary(X, Y):- mother_child(X, Y).
auxiliary(X, Y):- father_child(X, Y).
</syntaxhighlight>
Stuart Russell<ref>Russell, S., 2019. Human compatible: Artificial intelligence and the problem of control. Penguin.</ref> has referred to such invention of new concepts as the most important step needed for reaching human-level AI.

Recent work in ILP, combining logic programming, learning and probability, has given rise to the fields of [[statistical relational learning]] and [[probabilistic inductive logic programming]].

===Concurrent logic programming===
{{Main|Concurrent logic programming}}
Concurrent logic programming integrates concepts of logic programming with [[concurrent programming]]. Its development was given a big impetus in the 1980s by its choice for the systems programming language of the [[Fifth generation computer|Japanese Fifth Generation Project (FGCS)]].<ref>Shunichi Uchida and Kazuhiro Fuchi. ''Proceedings of the FGCS Project Evaluation Workshop''. Institute for New Generation Computer Technology (ICOT). 1992.</ref>

A concurrent logic program is a set of guarded [[Horn clauses]] of the form:

::<code>H :- G<sub>1</sub>, ..., G<sub>n</sub> | B<sub>1</sub>, ..., B<sub>n</sub>.</code>

The conjunction <code>G<sub>1</sub>, ... , G<sub>n</sub></code> is called the [[guard (computer science)|guard]] of the clause, and {{char|{{!}}}} is the commitment operator. Declaratively, guarded Horn clauses are read as ordinary logical implications:

::<code>H if G<sub>1</sub> and ... and G<sub>n</sub> and B<sub>1</sub> and ... and B<sub>n</sub>.</code>

However, procedurally, when there are several clauses whose heads <code>H</code> match a given goal, then all of the clauses are executed in parallel, checking whether their guards <code>G<sub>1</sub>, ... , G<sub>n</sub></code> hold. If the guards of more than one clause hold, then a committed choice is made to one of the clauses, and execution proceeds with the subgoals <code>B<sub>1</sub>, ..., B<sub>n</sub></code> of the chosen clause. These subgoals can also be executed in parallel. Thus concurrent logic programming implements a form of "don't care nondeterminism", rather than "don't know nondeterminism".

For example, the following concurrent logic program defines a predicate <code>shuffle(Left, Right, Merge)</code>, which can be used to shuffle two lists <code>Left</code> and <code>Right</code>, combining them into a single list <code>Merge</code> that preserves the ordering of the two lists <code>Left</code> and <code>Right</code>:

<syntaxhighlight lang="prolog">
shuffle([], [], []).
shuffle(Left, Right, Merge) :-
    Left = [First | Rest] |
    Merge = [First | ShortMerge],
    shuffle(Rest, Right, ShortMerge).
shuffle(Left, Right, Merge) :-
    Right = [First | Rest] |
    Merge = [First | ShortMerge],
    shuffle(Left, Rest, ShortMerge).
</syntaxhighlight>

Here, <code>[]</code> represents the empty list, and <code>[Head | Tail]</code> represents a list with first element <code>Head</code> followed by list <code>Tail</code>, as in Prolog. (Notice that the first occurrence of {{char|{{!}}}} in the second and third clauses is the list constructor, whereas the second occurrence of {{char|{{!}}}} is the commitment operator.)  The program can be used, for example, to shuffle the lists <code>[ace, queen, king]</code> and <code>[1, 4, 2]</code> by invoking the goal clause:

<syntaxhighlight lang="prolog">
shuffle([ace, queen, king], [1, 4, 2], Merge).
</syntaxhighlight>

The program will non-deterministically generate a single solution, for example <code>Merge = [ace, queen, 1, king, 4, 2]</code>.

[[Carl Hewitt]] has argued<ref name="Hewitt">{{cite web | url=https://hal.archives-ouvertes.fr/hal-01148496v6/document | title=Inconsistency Robustness for Logic Programs | publisher=Hal Archives | date=27 April 2016 | access-date=7 November 2016 | author=Hewitt, Carl | pages=21–26}}</ref> that, because of the [[Indeterminacy in concurrent computation|indeterminacy of concurrent computation]], concurrent logic programming cannot implement general concurrency. However, according to the logical semantics, any result of a computation of a concurrent logic program is a logical consequence of the program, even though not all logical consequences can be derived.

===Concurrent constraint logic programming===
{{Main|Concurrent constraint logic programming}}

[[Concurrent constraint logic programming]]<ref>Saraswat, V.A. and Rinard, M., 1989, December. Concurrent constraint programming. In Proceedings of the 17th ACM SIGPLAN-SIGACT symposium on Principles of programming languages (pp. 232-245).</ref> combines concurrent logic programming and [[constraint logic programming]], using constraints to control concurrency. A clause can contain a guard, which is a set of constraints that may block the applicability of the clause. When the guards of several clauses are satisfied, concurrent constraint logic programming makes a committed choice to use only one.

===Higher-order logic programming===
Several researchers have extended logic programming with [[higher-order programming]] features derived from [[higher-order logic]], such as predicate variables. Such languages include the Prolog extensions [[HiLog]]<ref name="hilog-jlp">{{cite journal |last1=Chen |first1=Weidong |last2=Kifer |first2=Michael |last3=Warren |first3=David S. |date=February 1993 |title=HiLog: A foundation for higher-order logic programming |journal=[[Journal of Logic Programming]] |volume=15 |issue=3 |pages=187–230 |doi=10.1016/0743-1066(93)90039-J|doi-access=free }}</ref> and [[λProlog]].<ref>Miller, D.A. and Nadathur, G., 1986, July. Higher-order logic programming. In International Conference on Logic Programming (pp. 448-462). Berlin, Heidelberg: Springer Berlin Heidelberg.</ref>

===Linear logic programming===
Basing logic programming within [[linear logic]] has resulted in the design of logic programming languages that are considerably more expressive than those based on classical logic. Horn clause programs can only represent state change by the change in arguments to predicates. In linear logic programming, one can use the ambient linear logic to support state change. Some early designs of logic programming languages based on linear logic include LO,<ref>{{cite journal|first=Jean-Marc|last=Andreoli|doi=10.1093/logcom/2.3.297|title=Logic Programming with Focusing Proofs in Linear Logic|journal=[[Journal of Logic and Computation]]|date=1 June 1992|volume=2|issue=3|pages=297–347}}</ref> Lolli,<ref>{{cite journal|first1=Joshua|last1=Hodas|first2=Dale|last2=Miller|url=http://repository.upenn.edu/cgi/viewcontent.cgi?article=1540&context=cis_reports|title=Logic Programming in a Fragment of Intuitionistic Linear Logic|journal=[[Information and Computation]]|date=1994|volume=110|issue=2|pages=327–365|doi=10.1006/inco.1994.1036 |doi-access=free}}</ref> ACL,<ref>{{cite conference|first1=Naoki|last1=Kobayashi|first2= Akinori|last2=Yonezawa|author-link2=Akinori Yonezawa|title=Asynchronous communication model based on linear logic|conference=US/Japan Workshop on Parallel Symbolic Computing|date=1994|pages=279–294|citeseerx=10.1.1.42.8749 }}</ref> and Forum.<ref>{{cite journal|first=Dale|last=Miller|title=Forum: A Multiple-Conclusion Specification Logic|journal=[[Theoretical Computer Science (journal)|Theoretical Computer Science]]|date=30 September 1996|volume=165|issue=1|pages=201–232|doi=10.1016/0304-3975(96)00045-X|doi-access=free}}</ref> Forum provides a goal-directed interpretation of all linear logic.

===Object-oriented logic programming===
[[F-logic]]<ref>Kifer, M. and Lausen, G., 1989, June. F-logic: a higher-order language for reasoning about objects, inheritance, and scheme. In Proceedings of the 1989 ACM SIGMOD international conference on Management of data (pp. 134-146).</ref> extends logic programming with objects and the frame syntax.

[[Logtalk]]<ref>de Moura, P.J.L., 2003. Design of an Object-Oriented Logic Programming Language (Doctoral dissertation, Universidade da Beira Interior).</ref> extends the Prolog programming language with support for objects, protocols, and other OOP concepts. It supports most standard-compliant Prolog systems as backend compilers.

===Transaction logic programming===
[[Transaction logic]]<ref name="TL"/> is an extension of logic programming with a logical theory of state-modifying updates. It has both a model-theoretic semantics and a procedural one. An implementation of a subset of Transaction logic is available in the [[Flora-2]]<ref>Yang, G. and Kifer, M., 2000, July. FLORA: Implementing an efficient DOOD system using a tabling logic engine. In International Conference on Computational Logic (pp. 1078-1093). Berlin, Heidelberg: Springer Berlin Heidelberg.</ref> system. Other prototypes are also [[Transaction logic|available]].