Justifications in Constraint Handling Rules for Logical Retraction in   Dynamic Algorithms

Thom Fruehwirth

arXiv:1706.07946·cs.AI·September 12, 2017

Justifications in Constraint Handling Rules for Logical Retraction in Dynamic Algorithms

Thom Fruehwirth

PDF

Open Access

TL;DR

This paper introduces a method to add justifications to constraints in CHR, enabling logical retraction and making algorithms fully dynamic by allowing constraints and their consequences to be undone efficiently.

Contribution

It proposes a simple source-to-source transformation for CHR that supports logical retraction, enhancing its incremental capabilities with correctness guarantees.

Findings

01

The scheme is proven confluent and correct.

02

Demonstrated with dynamic algorithms for minimum maintenance and shortest paths.

03

Prototype implementation is available online.

Abstract

We present a straightforward source-to-source transformation that introduces justifications for user-defined constraints into the CHR programming language. Then a scheme of two rules suffices to allow for logical retraction (deletion, removal) of constraints during computation. Without the need to recompute from scratch, these rules remove not only the constraint but also undo all consequences of the rule applications that involved the constraint. We prove a confluence result concerning the rule scheme and show its correctness. When algorithms are written in CHR, constraints represent both data and operations. CHR is already incremental by nature, i.e. constraints can be added at runtime. Logical retraction adds decrementality. Hence any algorithm written in CHR with justifications will become fully dynamic. Operations can be undone and data can be removed at any point in the…

Equations58

r : H_{1} \ H_{2} \Leftrightarrow C ∣ B

r : H_{1} \ H_{2} \Leftrightarrow C ∣ B

s : H_{2} \Leftrightarrow C ∣ B .

s : H_{2} \Leftrightarrow C ∣ B .

p : H_{1} \Rightarrow C ∣ B .

p : H_{1} \Rightarrow C ∣ B .

X =< Y \land Y =< X \land c (X, Y) \equiv X = Y \land c (X, X) \neq \equiv X = Y \land c (X, X) \land c (X, X) .

X =< Y \land Y =< X \land c (X, Y) \equiv X = Y \land c (X, X) \neq \equiv X = Y \land c (X, X) \land c (X, X) .

⊨ \forall (S_{1 bi} \to \exists \overset{y}{ˉ} ((S_{1 u d} = S_{2 u d}) \land S_{2 bi})) \land \forall (S_{2 bi} \to \exists \overset{x}{ˉ} ((S_{1 u d} = S_{2 u d}) \land S_{1 bi}))

⊨ \forall (S_{1 bi} \to \exists \overset{y}{ˉ} ((S_{1 u d} = S_{2 u d}) \land S_{2 bi})) \land \forall (S_{2 bi} \to \exists \overset{x}{ˉ} ((S_{1 u d} = S_{2 u d}) \land S_{1 bi}))

r : i = 1 ⋀ l K_{i} \ j = 1 ⋀ m R_{j} \Leftrightarrow C ∣ k = 1 ⋀ n B_{k}

r : i = 1 ⋀ l K_{i} \ j = 1 ⋀ m R_{j} \Leftrightarrow C ∣ k = 1 ⋀ n B_{k}

r f : i = 1 ⋀ l K_{i}^{F_{i}} \ j = 1 ⋀ m R_{j}^{F_{j}} \Leftrightarrow C ∣ j = 1 ⋀ m rem (R_{j}^{F_{j}})^{F} \land k = 1 ⋀ n B_{k}^{F} \mbox w h er e F = i = 1 ⋃ l F_{i} \cup j = 1 ⋃ m F_{j} .

r f : i = 1 ⋀ l K_{i}^{F_{i}} \ j = 1 ⋀ m R_{j}^{F_{j}} \Leftrightarrow C ∣ j = 1 ⋀ m rem (R_{j}^{F_{j}})^{F} \land k = 1 ⋀ n B_{k}^{F} \mbox w h er e F = i = 1 ⋃ l F_{i} \cup j = 1 ⋃ m F_{j} .

r : H_{1} \ H_{2} \Leftrightarrow C ∣ B

r : H_{1} \ H_{2} \Leftrightarrow C ∣ B

r f : H_{1}^{J} \ H_{2}^{J} \Leftrightarrow C ∣ rem (H_{2})^{J} \land B^{J} .

r f : H_{1}^{J} \ H_{2}^{J} \Leftrightarrow C ∣ rem (H_{2})^{J} \land B^{J} .

kill : kill (f) \ G^{F} \Leftrightarrow f \in F ∣ true

kill : kill (f) \ G^{F} \Leftrightarrow f \in F ∣ true

revive : kill (f) \ r e m (G^{F_{c}})^{F} \Leftrightarrow f \in F ∣ G^{F_{c}},

revive : kill (f) \ r e m (G^{F_{c}})^{F} \Leftrightarrow f \in F ∣ G^{F_{c}},

((K_{1} \land R_{1}) - A_{1}) \land K_{2} \land R_{2} \land A_{1} = A_{2} \land C_{1} \land C_{2} .

((K_{1} \land R_{1}) - A_{1}) \land K_{2} \land R_{2} \land A_{1} = A_{2} \land C_{1} \land C_{2} .

(((K_{1} \land K_{2} \land R_{2}) - A_{2}) \land B_{1} \land E <> ((K_{1} \land R_{1} \land K_{2}) - A_{1}) \land B_{2} \land E) .

(((K_{1} \land K_{2} \land R_{2}) - A_{2}) \land B_{1} \land E <> ((K_{1} \land R_{1} \land K_{2}) - A_{1}) \land B_{2} \land E) .

kill : kill (f) \ G^{F} \Leftrightarrow f \in F ∣ true

kill : kill (f) \ G^{F} \Leftrightarrow f \in F ∣ true

revive : kill (f) \ r e m (G^{F_{c}})^{F} \Leftrightarrow f \in F ∣ G^{F_{c}},

revive : kill (f) \ r e m (G^{F_{c}})^{F} \Leftrightarrow f \in F ∣ G^{F_{c}},

r f : K^{J} \ R^{J} \Leftrightarrow C ∣ rem (R)^{J} \land B^{J}

r f : K^{J} \ R^{J} \Leftrightarrow C ∣ rem (R)^{J} \land B^{J}

kill (f) \land K^{J} \land R^{J} \land G^{F} = A^{F} \land f \in F \land C,

kill (f) \land K^{J} \land R^{J} \land G^{F} = A^{F} \land f \in F \land C,

(kill (f) \land ((K^{J} \land R^{J}) - G^{F}) \land E <> kill (f) \land K^{J} \land rem (R)^{J} \land B^{J} \land E),

(kill (f) \land ((K^{J} \land R^{J}) - G^{F}) \land E <> kill (f) \land K^{J} \land rem (R)^{J} \land B^{J} \land E),

kill (f) \land K^{J} \land R^{J} \land E \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

kill (f) \land K^{J} \land R^{J} \land E \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

A^{J} \land G^{{f}} \land kill (f) \mapsto^{*} B^{J} \land rem (R)^{J} \land kill (f) \neq \mapsto_{k i l l, r e v i v e},

A^{J} \land G^{{f}} \land kill (f) \mapsto^{*} B^{J} \land rem (R)^{J} \land kill (f) \neq \mapsto_{k i l l, r e v i v e},

A^{J} \mapsto^{*} B^{J} \land rem (R)^{J} .

A^{J} \mapsto^{*} B^{J} \land rem (R)^{J} .

strip (f, kill (f) \land G^{F} \land f \in F \land E^{J} \mapsto_{kill} kill (f) \land E^{J})

strip (f, kill (f) \land G^{F} \land f \in F \land E^{J} \mapsto_{kill} kill (f) \land E^{J})

strip (f, kill (f) \land r e m (G^{F_{c}})^{F} \land f \in F \land E^{J} \mapsto_{revive} kill (f) \land G^{F_{c}} \land E^{J})

strip (f, kill (f) \land r e m (G^{F_{c}})^{F} \land f \in F \land E^{J} \mapsto_{revive} kill (f) \land G^{F_{c}} \land E^{J})

strip (f, K^{J} \land R^{J} \land C \land E^{J} \mapsto_{rf} K^{J} \land rem (R)^{J} \land B^{J} \land C \land E^{J})

strip (f, K^{J} \land R^{J} \land C \land E^{J} \mapsto_{rf} K^{J} \land rem (R)^{J} \land B^{J} \land C \land E^{J})

true \land true \land true \land E^{J^{'}} \equiv true \land E^{J^{'}}

true \land true \land true \land E^{J^{'}} \equiv true \land E^{J^{'}}

true \land G^{F_{c}} \land true \land E^{J^{'}} \equiv true \land G^{F_{c}} \land E^{J^{'}} \mbox i f f \neq \in F_{c}

true \land G^{F_{c}} \land true \land E^{J^{'}} \equiv true \land G^{F_{c}} \land E^{J^{'}} \mbox i f f \neq \in F_{c}

true \land true \land true \land E^{J^{'}} \equiv true \land true \land E^{J^{'}} \mbox i f f \in F_{c}

true \land true \land true \land E^{J^{'}} \equiv true \land true \land E^{J^{'}} \mbox i f f \in F_{c}

K^{J^{'}} \land R^{J^{'}} \land C \land E^{J^{'}} \equiv K^{J^{'}} \land R^{J^{'}} \land C \land E^{J^{'}} \mbox w h er e f \neq \in J^{'},

K^{J^{'}} \land R^{J^{'}} \land C \land E^{J^{'}} \equiv K^{J^{'}} \land R^{J^{'}} \land C \land E^{J^{'}} \mbox w h er e f \neq \in J^{'},

r f : i = 1 ⋀ l K_{i}^{F_{i}} \ j = 1 ⋀ m R_{j}^{F_{j}} \Leftrightarrow C ∣ j = 1 ⋀ m rem (R_{j}^{F_{j}})^{F} \land k = 1 ⋀ n B_{k}^{F} \mbox w h er e F = i = 1 ⋃ l F_{i} \cup j = 1 ⋃ m F_{j}

r f : i = 1 ⋀ l K_{i}^{F_{i}} \ j = 1 ⋀ m R_{j}^{F_{j}} \Leftrightarrow C ∣ j = 1 ⋀ m rem (R_{j}^{F_{j}})^{F} \land k = 1 ⋀ n B_{k}^{F} \mbox w h er e F = i = 1 ⋃ l F_{i} \cup j = 1 ⋃ m F_{j}

Peer Reviews

No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.

Videos

No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.

Taxonomy

TopicsConstraint Satisfaction and Optimization · AI-based Problem Solving and Planning · Logic, Reasoning, and Knowledge

Full text

11institutetext: Ulm University, Germany

11email: [email protected]

Justifications in Constraint Handling Rules for Logical Retraction in Dynamic Algorithms

Thom Frühwirth

Abstract

We present a straightforward source-to-source transformation that introduces justifications for user-defined constraints into the CHR programming language. Then a scheme of two rules suffices to allow for logical retraction (deletion, removal) of constraints during computation. Without the need to recompute from scratch, these rules remove not only the constraint but also undo all consequences of the rule applications that involved the constraint. We prove a confluence result concerning the rule scheme and show its correctness.

When algorithms are written in CHR, constraints represent both data and operations. CHR is already incremental by nature, i.e. constraints can be added at runtime. Logical retraction adds decrementality. Hence any algorithm written in CHR with justifications will become fully dynamic. Operations can be undone and data can be removed at any point in the computation without compromising the correctness of the result.

We present two classical examples of dynamic algorithms, written in our prototype implementation of CHR with justifications that is available online: maintaining the minimum of a changing set of numbers and shortest paths in a graph whose edges change.

1 Introduction

Justifications have their origin in truth maintenance systems (TMS) [McA90] for automated reasoning. In this knowledge representation method, derived information (a formula) is explicitly stored and associated with the information it originates from by means of justifications. This dependency can be used to explain the reason for a conclusion (consequence) by its initial premises. With the help of justifications, conclusions can be withdrawn by retracting their premises. By this logical retraction, e.g. default reasoning can be supported and inconsistencies can be repaired by retracting one of the reasons for the inconsistency. An obvious application of justifications are dynamic constraint satisfaction problems (DCSP), in particular over-constrained ones [BM06].

In this work, we extend the applicability of logical retraction to arbitrary algorithms that are expressed in the programming language Constraint Handling Rules (CHR) [Frü09, Frü15]. To accomplish logical retraction, we have to be aware that CHR constraints can also be deleted by rule applications. These constraints may have to be restored when a premise is retracted. With logical retraction, any algorithm written in CHR will become fully dynamic111Dynamic algorithms for dynamic problems should not be confused with dynamic programming..

Minimum Example. Given a multiset of numbers min( $n_{1}$ ), min( $n_{2}$ ),…, min( $n_{k}$ ). The constraint (predicate) min( $n_{i}$ ) means that the number $n_{i}$ is a candidate for the minimum value. The following CHR rule filters the candidates.

min(N) \ min(M) <=> N=<M | true.

The rule consists of a left-hand side, on which a pair of constraints has to be matched, a guard check N=<M that has to be satisfied, and an empty right-hand side denoted by true. In effect, the rule takes two min candidates and removes the one with the larger value (constraints after the \ symbol are deleted). Note that the min constraints behave both as operations (removing other constraints) and as data (being removed).

CHR rules are applied exhaustively. Here the rule keeps on going until only one, thus the smallest value, remains as single min constraint, denoting the current minimum. If another min constraint is added during the computation, it will eventually react with a previous min constraint, and the correct current minimum will be computed in the end. Thus the algorithm as implemented in CHR is incremental. It is not decremental, though: We cannot logically retract a min candidate. While removing a candidate that is larger than the minimum would be trivial, the retraction of the minimum itself requires to remember all deleted candidates and to find their minimum. With the help of justifications, this logical retraction will be possible automatically.

Contributions and Overview of the Paper. In the next section we recall syntax and operational semantics for CHR. Our contributions are as follows:

•

We introduce CHR with justifications (CHRJ) in Section 3. We enhance standard CHR programs with justifications by a source-to-source program transformation. We show the operational equivalence of rule applications in both settings. Thus CHRJ is a conservative extension of standard CHR.

•

We define a scheme of two rules to enable logical retraction of constraints based on justifications in Section 4. We show that the rule scheme is confluent with each rule in any given program, independent of the confluence of that program. We prove correctness of logical retraction: the result of a computation with retraction is the same as if the constraint would never have been introduced in the computation.

•

We present a proof-of-concept implementation of CHRJ in CHR and Prolog (available online) in Section 5. We discuss two classical examples for dynamic algorithms, maintaining the minimum of a changing set of numbers and maintaining shortest paths in a graph whose edges change.

The paper ends with discussion of related work in Section 6 and with conclusions and directions for future work.

2 Preliminaries

We recall the abstract syntax and the equivalence-based abstract operational semantics of CHR in this section. Upper-case letters stand for (possibly empty) conjunctions of constraints in this paper.

2.1 Abstract Syntax of CHR

Constraints are relations, distinguished predicates of first-order predicate logic. We differentiate between two kinds of constraints: built-in (pre-defined) constraints and user-defined (CHR) constraints which are defined by the rules in a CHR program.

Definition 1

A CHR program is a finite set of rules. A (generalized) simpagation rule is of the form

[TABLE]

where $r:$ is an optional name (a unique identifier) of a rule. In the rule head (left-hand side), $H_{1}$ and $H_{2}$ are conjunctions of user-defined constraints, the optional guard $C|$ is a conjunction of built-in constraints, and the body (right-hand side) $B$ is a goal. A goal is a conjunction of built-in and user-defined constraints. A state is a goal. Conjunctions are understood as multisets of their conjuncts.

In the rule, $H_{1}$ are called the kept constraints, while $H_{2}$ are called the removed constraints. At least one of $H_{1}$ and $H_{2}$ must be non-empty. If $H_{1}$ is empty, the rule corresponds to a simplification rule, also written

[TABLE]

If $H_{2}$ is empty, the rule corresponds to a propagation rule, also written

[TABLE]

In this work, we restrict given CHR programs to rules without built-in constraints in the body except ${\it true}$ and ${\it false}$ . This restriction is necessary as long as built-in constraint solvers do not support the removal of built-in constraints.

2.2 Abstract Operational Semantics of CHR

Computations in CHR are sequences of rule applications. The operational semantics of CHR is given by the state transition system. It relies on a structural equivalence between states that abstracts away from technical details in a transition[RBF09, Bet14].

State equivalence treats built-in constraints semantically and user-defined constraints syntactically. Basically, two states are equivalent if their built-in constraints are logically equivalent (imply each other) and their user-defined constraints form syntactically equivalent multisets. For example,

[TABLE]

For a state $S$ , the notation $S_{bi}$ denotes the built-in constraints of $S$ and $S_{ud}$ denotes the user-defined constraints of $S$ .

Definition 2 (State Equivalence)

Two states $S_{1}=(S_{1bi}\land S_{1ud})$ and $S_{2}=(S_{2bi}\land S_{2ud})$ are equivalent, written $S_{1}\equiv S_{2}$ , if and only if

[TABLE]

with $\bar{x}$ those variables that only occur in $S_{1}$ and $\bar{y}$ those variables that only occur in $S_{2}$ .

Using this state equivalence, the abstract CHR semantics is defined by a single transition (computation step). It defines the application of a rule. Note that CHR is a committed-choice language, i.e. there is no backtracking in the rule applications.

Definition 3 (Transition)

Let the rule $(r:H_{1}\backslash H_{2}\Leftrightarrow C|B)$ be a variant222A variant (renaming) of an expression is obtained by uniformly replacing its variables by fresh variables. of a rule from a given program $\cal{P}$ . The transition (computation step) $S\mapsto_{r}T$ is defined as follows, where $S$ is called source state and $T$ is called target state:

$\underline{S\equiv(H_{1}\land H_{2}\land C\land G)\ \ \ (r:H_{1}\backslash H_{2}\Leftrightarrow C|B)\in{\mathcal{P}}\ \ \ (H_{1}\land C\land B\land G)\equiv T}$

$S\mapsto_{r}T$

The goal $G$ is called context of the rule application. It is left unchanged.

A computation (derivation) of a goal $S$ in a program $\mathcal{P}$ is a connected sequence $S_{i}\mapsto_{r_{i}}S_{i+1}$ beginning with the initial state (query) $S_{0}$ that is $S$ and ending in a final state (answer, result) or the sequence is non-terminating (diverging). We may drop the reference to the rules $r_{i}$ to simplify the presentation. The notation $\mapsto^{*}$ denotes the reflexive and transitive closure of $\mapsto$ .

If the source state can be made equivalent to a state that contains the head constraints and the guard built-in constraints of a variant of a rule, then we delete the removed head constraints from the state and add the rule body constraints to it. Any state that is equivalent to this target state is in the transition relation.

The abstract semantics does not account for termination of inconsistent states and propagation rules. From a state with inconsistent built-in constraints, any transition is possible. If a state can fire a propagation rule once, it can do so again and again. This is called trivial non-termination of propagation rules.

Minimum Example, contd. Here is a possible transition from a state $S=(min(0)\land min(2)\land min(1))$ to a state $T=(min(0)\land min(1))$ :

$S\equiv(min(X)\land min(Y)\land X\leq Y\land(X=0\land Y=2\land min(1)))$

$(min(X)\backslash min(Y)\Leftrightarrow X\leq Y|true)$

$\underline{(min(X)\land X\leq Y\land true\land(X=0\land Y=2\land min(1)))\equiv T}$

$S\mapsto T$

3 CHR with Justifications (CHRJ)

We present a conservative extension of CHR by justifications. If they are not used, programs behave as without them. Justifications annotate atomic CHR constraints. A simple source-to-source transformation extends the rules with justifications.

Definition 4 (CHR Constraints and Initial States with Justifications)

A justification $f$ is a unique identifier. Given an atomic CHR constraint $G$ , a CHR constraint with justifications is of the form $G^{F}$ , where $F$ is a set of justifications. An initial state with justifications is of the form $\bigwedge_{i=1}^{n}G^{\{f_{i}\}}_{i}$ where the $f_{i}$ are distinct justifications.

We now define a source-to-source translation from rules to rules with justifications. Let $\mathit{kill}$ and $\mathit{rem}$ (remove) be to unary reserved CHR constraint symbols. This means they are only allowed to occur in rules as specified in the following.

Definition 5 (Translation to Rules with Justifications)

Given a generalized simpagation rule

[TABLE]

Its translation to a simpagation rule with justifications is of the form

[TABLE]

The translation ensures that the head and the body of a rule mention exactly the same justifications. More precisely, each CHR constraint in the body is annotated with the union of all justifications in the head of the rule, because its creation is caused by the head constraints. The reserved CHR constraint rem/1 (remember removed) stores the constraints removed by the rule together with their justifications.

3.1 Operational Equivalence of Rule Applications

Let $A,B,C\ldots$ be states. For convenience, we will often consider them as multisets of atomic constraints. Then the notation $A{-}B$ denotes multiset difference, $A$ without $B$ . By abuse of notation, let $A^{\mathcal{J}},B^{\mathcal{J}},C^{\mathcal{J}}\ldots$ be conjunctions and corresponding states whose atomic CHR constraints are annotated with justifications according to the above definition of the rule scheme. Similarly, let $\mathit{rem}(R)^{\mathcal{J}}$ denote the conjunction $\bigwedge_{j=1}^{m}\mathit{rem}(R^{F_{j}}_{j})^{F}$ .

We show that rule applications correspond to each other in standard CHR and in CHRJ.

Lemma 1 (Equivalence of Program Rules)

There is a computation step $S\mapsto_{r}T$ with simpagation rule

[TABLE]

if and only if there is a computation step with justifications $S^{\mathcal{J}}\mapsto_{rf}T^{\mathcal{J}}\wedge\mathit{rem}(H_{2})^{\mathcal{J}}$ with the corresponding simpagation rule with justifications

[TABLE]

Proof. We compare the two transitions involving rule r and rf, respectively:

$(r:H_{1}\backslash H_{2}\Leftrightarrow C|B)$

$\underline{S\equiv(H_{1}\land H_{2}\land C\land G)\ \ \ (H_{1}\land C\land B\land G)\equiv T}$

$S\mapsto_{r}T$

$(rf:H_{1}^{\mathcal{J}}\backslash H_{2}^{\mathcal{J}}\Leftrightarrow C|\mathit{rem}(H_{2})^{\mathcal{J}}\land B^{\mathcal{J}})$

$\underline{S^{\mathcal{J}}\equiv(H_{1}^{\mathcal{J}}\land H_{2}^{\mathcal{J}}\land C\land G^{\mathcal{J}})\ \ \ (H_{1}^{\mathcal{J}}\land C\land B^{\mathcal{J}}\land G^{\mathcal{J}})\equiv T^{\mathcal{J}}\land\mathit{rem}(H_{2})^{\mathcal{J}}}$

$S^{\mathcal{J}}\mapsto_{rf}T^{\mathcal{J}}\land\mathit{rem}(H_{2})^{\mathcal{J}}$

Given the standard transition with rule $r$ , the transition with justifications with rule $\mathit{rf}$ is always possible: The rule $\mathit{rf}$ by definition does not impose any constraints on its justifications. The justifications in the rule body are computed as the union of the justifications in the rule head, which is always possible. Furthermore, the reserved rem constraints always belong to the context of the transition since by definition there is no rule rf that can match any of them.

Conversely, given the transition with justifications with rule $\mathit{rf}$ , by the same arguments, we can strip away all justifications from it and remove $\mathit{rem}(H_{2})^{\mathcal{J}}$ from the rule and the target state to arrive at the standard transition with rule $r$ . ∎

Since computations are sequences of connected computation steps, this lemma implies that computations in standard CHR program and in CHRJ correspond to each other. Thus CHR with justifications is a conservative extension of CHR.

4 Logical Retraction Using Justifications

We use justifications to remove a CHR constraint from a computation without the need to recompute from scratch. This means that all its consequences due to rule applications it was involved in are undone. CHR constraints added by those rules are removed and CHR constraints removed by the rules are re-added. To specify and implement this behavior, we give a scheme of two rules, one for retraction and one for re-adding of constraints. The reserved CHR constraint $\mathit{kill}(f)$ undoes all consequences of the constraint with justification $f$ .

Definition 6 (Rules for CHR Logical Retraction)

For each $n$ -ary CHR constraint symbol $c$ (except the reserved $\mathit{kill}$ and $\mathit{rem}$ ), we add a rule to kill constraints and a rule to revive removed constraints of the form:

[TABLE]

where $G=c(X_{1},\ldots,X_{n})$ , where $X_{1},\ldots,X_{n}$ are different variables.

Note that a constraint may be revived and subsequently killed. This is the case when both $F_{c}$ and $F$ contain the justification $f$ .

4.1 Confluence of Logical Retraction

Confluence of a program guarantees that any computation starting from a given initial state can always reach equivalent states, no matter which of the applicable rules are applied. There is a decidable, sufficient and necessary syntactic condition to check confluence of terminating programs and to detect rule pairs that lead to non-confluence when applied.

Definition 7 (Confluence)

If $A\mapsto^{*}B$ and $A\mapsto^{*}C$ then there exist states $D_{1}$ and $D_{2}$ such that $B\mapsto^{*}D_{1}$ and $C\mapsto^{*}D_{2}$ where $D_{1}\equiv D_{2}$ .

Theorem 4.1

[Abd97, AFM99*]** *A terminating CHR program is confluent if and only if all its critical pairs are joinable. **

Decidability comes from the fact that there is only a finite number of critical pairs to consider.

Definition 8 (Overlap, Critical Pair)

Given two (not necessarily different) simpagation rules whose variables have been renamed apart, $K_{1}\backslash R_{1}\Leftrightarrow C_{1}|B_{1}$ and $K_{2}\backslash R_{2}\Leftrightarrow C_{2}|B_{2}$ . Let $A_{1}$ and $A_{2}$ be non-empty conjunctions of constraints taken from $K_{1}\land R_{1}$ and $K_{2}\land R_{2}$ , respectively. An overlap of the two rules is the state consisting of the rules heads and guards:

[TABLE]

The critical pair are the two states that come from applying the two rules to the overlap, where $E=(A_{1}{{\tt=}}A_{2}\land C_{1}\land C_{2})$ :

[TABLE]

Note that the two states in the critical pair differ by $R_{2}\land B_{1}$ and $R_{1}\land B_{2}$ .

A critical pair is trivially joinable if its built-in constraints are inconsistent or if both $A_{1}$ and $A_{2}$ do not contain removed constraints [AFM99].

We are ready to show the confluence of the $\mathit{kill}$ and $\mathit{revive}$ rules with each other and with each rule in any given program. It is not necessary that the given program is confluent. This means for any given program, the order between applying applicable rules from the program and retracting constraints can be freely interchanged. It does not matter for the result, if we kill a constraint first or if we apply a rule to it and kill it and its consequences later.

Theorem 4.2 (Confluence of Logical Retraction)

Given a CHR program whose rules are translated to rules with justifications together with the $\mathit{kill}$ and $\mathit{revive}$ rules. We assume there is at most one $\mathit{kill}(f)$ constraint for each justification $f$ in any state. Then all critical pairs between the $\mathit{kill}$ and $\mathit{revive}$ rules and any rule from the program with justifications are joinable.

Proof. There is only one overlap between the $\mathit{kill}$ and $\mathit{revive}$ rules,

[TABLE]

since $G^{F}$ cannot have the reserved constraint symbol $\mathit{rem/1}$ . The overlap is in the $\mathit{kill}(f)$ constraint. But since it is not removed by any rule, the resulting critical pair is trivially joinable.

By our assumption, the only overlap between two instances of the $\mathit{kill}$ rule must have a single $\mathit{kill}(f)$ constraint. Again, since it is not removed, the resulting critical pair is trivially joinable. The same argument applies to the only overlap between two instances of the $\mathit{revive}$ rule.

Since the head of a simpagation rule with justifications from the given program

[TABLE]

cannot contain reserved $\mathit{kill}$ and $\mathit{rem}$ constraints, these program rules cannot have an overlap with the $\mathit{revive}$ rule.

But there are overlaps between program rules, say a rule $\mathit{rf}$ , and the $\mathit{kill}$ rule. They take the general form:

[TABLE]

where $A^{F}$ occurs in $K^{\mathcal{J}}\land R^{\mathcal{J}}$ . This leads to the critical pair

[TABLE]

where $E=(G^{F}{=}A^{F}\land{f{\in}F}\land C)$ . In the first state of the critical pair, the $\mathit{kill}$ rule has been applied and in the second state the rule $\mathit{rf}$ . Note that $A^{F}$ is atomic since it is equated to $G^{F}$ in $E$ . Since $G^{F}$ has been removed in the first state and $G^{F}{=}A^{F}$ , rule $\mathit{rf}$ is no longer applicable in that state.

We would like to join these two states. The joinability between a rule rf and the kill rule can be visualized by the diagram:

[TABLE]

We now explain this joinability result. The states of the critical pair differ. In the first state we have the constraints $R^{\mathcal{J}}$ and have $G^{F}$ removed from $K^{\mathcal{J}}\land R^{\mathcal{J}}$ , while in the second state we have the body constraints $\mathit{rem}(R)^{\mathcal{J}}\land B^{\mathcal{J}}$ of rule $\mathit{rf}$ instead. Any constraint in $\mathit{rem}(R)^{\mathcal{J}}\land B^{\mathcal{J}}$ must include $f$ as justification by definition, because $f$ occurred in the head constraint $A^{F}$ and $E$ contains ${f{\in}F}$ .

The goal $\mathit{rem}(R)^{\mathcal{J}}$ contains $\mathit{rem}$ constraints for each removed constraint from $R^{\mathcal{J}}$ . But then we can use $\mathit{kill}(f)$ with the $\mathit{revive}$ rule to replace all $\mathit{rem}$ constraints by the removed constraints, thus adding $R^{\mathcal{J}}$ back again. Furthermore, we can use $\mathit{kill}(f)$ with the $\mathit{revive}$ rule to remove each constraint in $B^{\mathcal{J}}$ , as each constraint in $B^{\mathcal{J}}$ contains the justification $f$ . So $\mathit{rem}(R)^{\mathcal{J}}\land B^{\mathcal{J}}$ has been removed completely and $R^{\mathcal{J}}$ has been re-added.

The two states may still differ in the occurrence of $G^{F}$ (which is $A^{F}$ ). In the first state, $G^{F}$ was removed by the kill rule. Now if $A^{F}$ ( $G^{F}$ ) was in $R^{\mathcal{J}}$ , it has been revived with $R^{\mathcal{J}}$ . But then the $\mathit{kill}$ rule is applicable and we can remove $A^{F}$ again. In the second state, if $A^{F}$ was in $R^{\mathcal{J}}$ it has been removed together with $R^{\mathcal{J}}$ by application of rule rf. Otherwise, $A^{F}$ is still contained in $K^{\mathcal{J}}$ . But then the $\mathit{kill}$ rule is applicable to $A^{F}$ and removes it from $K^{\mathcal{J}}$ . Now $A^{F}$ ( $G^{F}$ ) does not occur in the second state either.

We thus have arrived at the first state of the critical pair. Therefore the critical pair is joinable. ∎**

This means that given a state, if there is a constraint to be retracted, we can either kill it immediately or still apply a rule to it and use the $\mathit{kill}$ and $\mathit{revive}$ rules afterwards to arrive at the same resulting state.

Note that the confluence between the $\mathit{kill}$ and $\mathit{revive}$ rules and any rule from the program is independent of the confluence of the rules in the given program.

4.2 Correctness of Logical Retraction

We prove correctness of logical retraction: the result of a computation with retraction is the same as if the constraint would never have been introduced in the computation. We show that given a computation starting from an initial state with a kill(f) constraint that ends in a state where the kill and revive rules are not applicable, i.e. these rules have been applied to exhaustion, then there is a corresponding computation without constraints that contain the justification $f$ .

Theorem 4.3 (Correctness of Logical Retraction)

Given a computation

[TABLE]

where $f$ does not occur in $A^{\mathcal{J}}$ . Then there is a computation without $G^{\{f\}}$ and $\mathit{kill}(f)$

[TABLE]

Proof. We distinguish between transitions that involve the justification $f$ or do not. A rule that applies to constraints that do not contain the justification $f$ will produce constraints that do not contain the justification. A rule application that involves at least one constraint with a justification $f$ will only produce constraints that contain the justification $f$ .

We now define a mapping from a computation with $G^{\{f\}}$ to a corresponding computation without $G^{\{f\}}$ . The mapping essentially strips away constraints that contain the justification $f$ except those that are remembered by rem constraints. In this way, the exhaustive application of the revive and kill rules $\mathit{kill}(f)$ is mimicked.

$\mathit{strip}(f,A^{\mathcal{J}}\wedge B^{\mathcal{J}}):=\ \mathit{strip}(f,A^{\mathcal{J}})\wedge\mathit{strip}(f,B^{\mathcal{J}})$

$\mathit{strip}(f,\mathit{rem}(G^{F_{1}})^{F_{2}}):=\ \mathit{strip}(f,G^{F_{1}})$ if $f\in F_{2}$

$\mathit{strip}(f,G^{F}):=\ {\it true}$ if $G$ is an atomic constraint except rem/1 and $f\in F$

$\mathit{strip}(f,G^{F}):=\ G^{F}$ otherwise.

We extend the mapping from states to transitions. We keep the transitions except where the source and target state are equivalent, in that case we replace the transition $\mapsto$ by an equivalence $\equiv$ . This happens when a rule is applied that involves the justification $f$ . The mapping is defined in such a way that in this case the source and target state are equivalent. Otherwise a rule that does not involve $f$ has been applied. The mapping ensures in this case that all necessary constraints are in the source and target state, since it keeps all constraints that do not mention the justification $f$ . For a computation step $C^{\mathcal{J}}\mapsto D^{\mathcal{J}}$ we define the mapping as:

$\mathit{strip}(f,C^{\mathcal{J}}\mapsto_{rf}D^{\mathcal{J}}):=\ \mathit{strip}(f,C^{\mathcal{J}})\equiv\mathit{strip}(f,D^{\mathcal{J}})$ if rule $\mathit{rf}$ involves $f$

$\mathit{strip}(f,C^{\mathcal{J}}\mapsto_{rf}D^{\mathcal{J}}):=\ \mathit{strip}(f,C^{\mathcal{J}})\mapsto_{rf}\mathit{strip}(f,D^{\mathcal{J}})$ otherwise.

We next have to show is that the mapping results in correct state equivalences and transitions. If a rule is applied that does not involve justification $f$ , then it is easy to see that the mapping strip( $f,\ldots$ ) leaves states and transitions unchanged.

Otherwise the transition is the application of a rule rf from the program, the rule kill or the rule revive where $f$ is contained in the justifications. Let the context $E^{\mathcal{J}}$ be an arbitrary goal where $f\in\mathcal{J}$ . Then we have to compute

[TABLE]

and to show that equivalent states are produced in each case. The resulting states are

[TABLE]

where, given a goal $A$ , the expression $A^{\mathcal{J}^{\prime}}$ contains all constraints from $A^{\mathcal{J}}$ that do not contain the justification $f$ .

In the end state of the given computation we know that the revive and kill rules have been applied to exhaustion. Therefore all $\mathit{rem}(G^{F_{1}})^{F_{2}}$ where $F_{2}$ contains $f$ have been replaced by $G^{F_{1}}$ by the revive rule. Therefore all standard constraints with justification $f$ have been removed by the kill rule (including those revived), just as we do in the mapping strip( $f,\ldots$ ).

Therefore the end states are indeed equivalent except for the remaining kill constraint. ∎

5 Implementation

As a proof-of-concept, we implement CHR with justifications (CHRJ) in SWI-Prolog using its CHR library. This prototype source-to-source transformation is available online at http://pmx.informatik.uni-ulm.de/chr/translator/. The translated programs can be run in Prolog or online systems like WebCHR.

Constraints with Justifications. CHR constraints annotated by a set of justifications are realized by a binary infix operator ##, where the second argument is a list of justifications:

$C^{\{F_{1},F_{2},\ldots\}}$ is realized as C ## [F1,F2,...].

For convenience, we add rules that add a new justification to a given constraint C. For each constraint symbol c with arity n there is a rule of the form

addjust @ c(X1,X2,...Xn) <=> c(X1,X2,...Xn) ## [_F].

where the arguments of X1,X2,...Xn are different variables.

Rules with Justifications. A CHR simpagation rule with justifications is realized as follows:

[TABLE]

rf @ K1 ## FK1,... \ R1 ## FR1,... <=> C | union([FK1,...FR1,...],Fs), rem(R1##FR1) ## Fs,...B1 ## Fs,...

where the auxiliary predicate union/2 computes the ordered duplicate-free union of a list of lists333More precisely, a simplification rule is generated if there are no kept constraints and a propagation rule is generated if there are no removed constraints..

Rules remove and revive. Justifications are realized as flags that are initially unbound logical variables. This eases the generation of new unique justifications and their use in killing. Concretely, the reserved constraint $\mathit{kill}(f)$ is realized as built-in equality F=r, i.e. the justification variable gets bound. If $\mathit{kill}(f)$ occurred in the head of a kill or revive rule, it is moved to the guard as equality test F==r. Note that we rename rule kill to remove in the implementation.

$\textrm{revive}:\mathit{kill}(f)\ \backslash\ rem(C^{F_{c}})^{F}\Leftrightarrow{f\in F}\ |\ C^{F_{c}}$

$\textrm{kill}:\mathit{kill}(f)\ \backslash\ C^{F}\Leftrightarrow{f\in F}\ |\ {\it true}$

revive @ rem(C##FC) ## Fs <=> member(F,Fs),F==r | C ## FC. remove @ C ## Fs <=> member(F,Fs),F==r | true.

Since rules are tried in program order in the CHR implementation, the constraint C in the second rule is not a reserved rem/1 constraint when the rule is applicable. The check for set membership in the guards is expressed using the standard nondeterministic Prolog built-in predicate member/2.

Logical Retraction with killc/1. We extend the translation to allow for retraction of derived constraints. The constraint killc(C) logically retracts constraint C. The two rules killc and killr try to find the constraint C - also when it has been removed and is now present in a rem constraint. The associated justifications point to all initial constraints that where involved in producing the constraint C. For retracting the constraint, it is sufficient to remove one of its producers. This introduces a choice implemented by the member predicate.

killr @ killc(C), rem(C ## FC) ## _Fs <=> member(F,FC),F=r. killc @ killc(C), C ## Fs <=> member(F,Fs),F=r.

Note that in the first rule, we bind a justification F from FC, because FC contains the justifications of the producers of constraint C, while Fs also contains those that removed it by a rule application.

5.1 Examples

We discuss two classical examples for dynamic algorithms, maintaining the minimum of a changing set of numbers and shortest paths when edges change.

Dynamic Minimum. Translating the minimum rule to one with justifications results in:

min(A)##B \ min(C)##D <=> A<C | union([B,D],E), rem(min(C)##D)##E.

The following shows an example query and the resulting answer in SWI-Prolog:

?- min(1)##[A], min(0)##[B], min(2)##[C]. rem(min(1)##[A])##[A,B], rem(min(2)##[C])##[B,C], min(0)##[B].

The constraint min(0) remained. This means that 0 is the minimum. The constraints min(1) and min(2) have been removed and are now remembered. Both have been removed by the constraint with justification B, i.e. min(0).

We now logically retract with killc the constraint min(1) at the end of the query. The killr rule applies and removes rem(min(1)##[A])##[A,B]. (In the rule body, the justification A is bound to r - to no effect, since there are no other constraints with this justification.)

?- min(1)##[A], min(0)##[B], min(2)##[C], killc(min(1)). rem(min(2)##[C])##[B,C], min(0)##[B].

What happens if we remove the current minimum min(0)? The constraint min(0) is removed by binding justification B. The two rem constraints for min(1) and min(2) involve B as well, so these two constraints are re-introduced and react with each other. Note that min(2) is nwo removed by min(1) (before it was min(0)). The result is the updated minimum, which is 1.

?- min(1)##[A], min(0)##[B], min(2)##[C], killc(min(0)). rem(min(2)##[C])##[A,C], min(1)##[B].

Dynamic Shortest Path. Given a graph with directed arcs e(X,Y), we compute the lengths of the shortest paths between all pairs of reachable nodes:

% keep shorter of two paths from X to Y pp @ p(X,Y,L1) \ p(X,Y,L2) <=> L1=<L2 | true. % edges have a path of unit length e @ e(X,Y) ==> p(X,Y,1). % extend path in front by an edge ep @ e(X,Y), p(Y,Z,L) ==> L1=:=L+1 | p(X,Z,L1).

The corresponding rules in the translated program are:

pp@p(A,B,C)##D \ p(A,B,E)##F <=> C=<E | union([D,F],G), rem(p(A,B,E)##F)##G. e @e(A,B)##C ==> true | union([C],D), p(A,B,1)##D. ep@e(A,B)##C,p(B,D,E)##F ==> G is E+1 | union([C,F],H),p(A,D,G)##H.

We now use constraints without justifications in queries. Justifications will be added by the addjust rules.

?- e(a,b), e(b,c), e(a,c). rem(p(a, c, 2)##[A, B])##[A,B,C], p(a, b, 1)##[A], e(a, b)##[A], p(b, c, 1)##[B], e(b, c)##[B], p(a, c, 1)##[C], e(a, c)##[C].

We see that a path of length 2 has been removed by the constraint e(a,c)##[C], which produced a shorter path of length one. We next kill this constraint e(a,c).

?- e(a,b), e(b,c), e(a,c), kill(e(a,c)). p(a, b, 1)##[A], e(a, b)##[A], p(b, c, 1)##[B], e(b, c)##[B], p(a, c, 2)##[A,B].

Its path p(a,c,1) disappears and the removed remembered path p(a,c,2) is re-added. We can see that the justifications of a path contains are those from the edges in that path. The same happens if we logically retract p(a,c,1) instead of e(a,c).

What happens if we remove p(a,c,2) from the initial query? The killr rule applies. Since the path has two justifications, there are two computations generated by the member predicate. In the first one, the constraint e(a,b) disappeared, in the second answer, it is e(b,c). In both cases, the path cannot be computed anymore, i.e. it has been logically retracted.

?- e(a,b), e(b,c), e(a,c), kill(p(a,c,2)). p(b, c, 1)##[B], e(b, c)##[B], p(a, c, 1)##[C], e(a, c)##[C] ; p(a, b, 1)##[A], e(a, b)##[A], p(a, c, 1)##[C], e(a, c)##[C].

6 Related Work

The idea of introducing justifications into CHR is not new. The thorough work of Armin Wolf on Adaptive CHR [WGG00] was the first to do so. Different to our work, this technically involved approach requires to store detailed information about the rule instances that have been applied in a derivation in order to undo them. Adaptive CHR had a low-level implementation in Java [Wol01], while we give an implementation in CHR itself by a straightforward source-to-source transformation that we prove confluent and correct. Moreover we prove confluence of the rule scheme for logical retraction with the rules of the given program. The application of adaptive CHR considered dynamic constraint satisfaction problems (DCSP) only, in particular for the implementation of search strategies [Wol05], while we apply our approach to arbitrary algorithms in order to make them fully dynamic.

The issue of search strategies was further investigated by Leslie De Koninck et. al. [DKSD08]. They introduce a flexible search framework in CHR∨ (CHR with disjunction) extended with rule and search branch priorities. In their work, justifications are introduced into the semantics of CHR∨ to enable dependency-directed backtracking in the form of conflict-directed backjumping. Our work does not need a new semantics for CHR, nor its extension with disjunction, it rather relies on a source-to-source transformation within the standard semantics.

Our work does not have a particular application of justifications in mind, but rather provides the basis for any type of application that requires dynamic algorithms. There are, however, CHR applications that use justifications.

The work of Jeremy Wazny et. al. [SSW03] introduced informally a particular kind of justifications into CHR for the specific application of type debugging and reasoning in Haskell. Justifications correspond to program locations in the given Haskell program. Unlike other work, the constraints in the body of CHR rules have given justifications to which justifications from the rule applications are added at runtime.

The more recent work of Gregory Duck [Duc12] introduces SMCHR, a tight integration of CHR with a Boolean Satisfiability (SAT) solver for quantifier-free formulae including disjunction and negation as logical connectives. It is mentioned that for clause generation, SMCHR supports justifications for constraints that include syntactic equality constraints between variables. A dynamic unification algorithm using justifications has been considered in [Wol98].

7 Conclusions

In this paper, the basic framework for CHR with justifications (CHRJ) has been established and formally analyzed. We defined a straightforward source-to-source program transformation that introduces justifications into CHR as a conservative extension. Justifications enable logical retraction of constraints. If a constraint is retracted, the computation continues as if the constraint never was introduced. We proved confluence and correctness of the two-rule scheme that encodes the logical retraction. We presented a prototype implementation that is available online together with two classical examples.

Future work could proceed along three equally important lines: investigate implementation, dynamic algorithms and application domains of CHR with justifications. First, we would like to research how logical as well as classical algorithms implemented in CHR behave when they become dynamic. While our approach does not require confluence of the given program, the arbitrary re-introduction of removed constraints may lead to unwanted orders of rule applications in non-confluent programs. Second, we would like to improve the implementation, optimize and benchmark it [Fru17]. Currently, the entire history of removed constraints is stored. It could suffice to remember only a partial history if only certain constraints can be retracted or if partial recomputation proves to be more efficient for some constraints. A lower-level implementation could benefit from the propagation history that comes with the application of propagation rules in most CHR implementations. Third, we would like to extend the rule scheme to support typical application domains of justifications: explanation of derived constraints by justifications (for debugging), detection and repair of inconsistencies (for error diagnosis), and implementing nonmonotonic logical behaviors (e.g. default logic, abduction, defeasible reasoning). Logical retraction of constraints can also lead to reversal of computations, and as a first step the related literature on reversibility should be explored.

Acknowledgements. We thank Daniel Gall for implementing the online transformation tool for CHRJ. We also thank the anonymous reviewers for their helpful suggestions on how to improve the paper.

Bibliography16

The reference list from the paper itself. Each links out to its DOI / PubMed record.

1[Abd 97] Slim Abdennadher. Operational semantics and confluence of constraint propagation rules. In G. Smolka, editor, CP ’97: Proc. Third Intl. Conf. Principles and Practice of Constraint Programming , volume 1330 of LNCS , pages 252–266. Springer, 1997.
2[AFM 99] Slim Abdennadher, Thom Frühwirth, and Holger Meuss. Confluence and semantics of constraint simplification rules. Constraints , 4(2):133–165, 1999.
3[Bet 14] Hariolf Betz. A unified analytical foundation for constraint handling rules . Bo D, 2014.
4[BM 06] Kenneth N Brown and Ian Miguel. Uncertainty and change, chapter 21. Handbook of Constraint Programming , pages 731–760, 2006.
5[DKSD 08] Leslie De Koninck, Tom Schrijvers, and Bart Demoen. A flexible search framework for chr. In Constraint Handling Rules — Current Research Topics , volume LNAI 5388, pages 16–47. Springer, 2008.
6[Duc 12] Gregory J Duck. Smchr: Satisfiability modulo constraint handling rules. Theory and Practice of Logic Programming , 12(4-5):601–618, 2012.
7[Frü09] Thom Frühwirth. Constraint Handling Rules . Cambridge University Press, 2009.
8[Frü15] Thom Frühwirth. Constraint handling rules – what else? In Rule Technologies: Foundations, Tools, and Applications , pages 13–34. Springer International Publishing, 2015.