CHORD Semantics

January, 2007

F-Atoms

• User Defined Constraint– A::B– A[B->C], A[B=>C]– A[B(V)->C], A[B(P:T0)=>T1]

• Built-in Constraint– 1 : Integer, “abc” : String– Integer :: Double– 1[toString()->”1”]– ...

Monotonic OO Semantics

General Rules: X::Y, Y::Z ==> X::Z.

X::Y, Y[M=>T] ==> X[M=>T]. X[M=>T] ==> X[M->V].

X[M=>T], X[M->V] ==> V::T. X[M->V1], X[M->V2] ==> V1 = V2.

X[M(V)->R], X[M(P:T0)=>T1) ==> V:T0, R:T1.

Simple Inheritance: X::Y, X::Z ==> Y = Z.

Non-MonotonicOO Semantics

(Overriding & Multiple Inheritance)

CHR Semantics x Open World Assumption

• Notation– ConstraintStore = Set(Constraint)– Program = Set(Rule)– i = initial constraint store– p = current program

CHR Semantics x Open World Assumption

• R : ConstraintStore x Program x ConstraintStore– Reachable predicate– R(cs, p) = some constraint store reachable from cs by

iteratively applying the rules from p

• I : Constraint x ConstraintStore x Program { t, f, u}– Interpretation function– Computes the “truth-value” of a constraint given some

initial constraint store and set of rules• t, the constraint can be proved true• f, the constraint can be proved false• u, the constraint can’t be proved neither true nor false

CHR Semantics x Open World Assumption

• cs (c s s R(i,p) I(c,i,p) = t)– Everything appearing in some reachable state is true

• cs (I(c,i,p) = u c s s R(i,p))– Every undefined constraint does not appear in any reachable

state

• c s (I(c,i,p) = f c s s R(i,p) false R(ic,p))– Every false constraint causes a failed final state when added to

some constraint store

CHR Semantics x Open World Assumption

• Remarks– We can’t reason directly about negative or

undefined facts in CHR– The set of positive facts is partially observable– We can prove some fact to be false by finding a

proof for its negation (Reductio Ad Absurdum)

OO Inheritance in OWA

c1 :: c2, c2[m->b]

true c1 :: c2, c2[m->b], c1[m->b]false c1 :: c3, c3 :: c2 ...undefined

Closed World Semantics

c1 :: c2, c2[m->b]

true X (c1[m->X]), c1 :: c2, c2[m->b]false c2 :: c1, c2[m->c1], ...unknown c1[m->b], c1 :: c3, c3 :: c2, ...

Open World Semantics

Overriding in OWA (1st Version)

X::Y, Y[M->>V] ==> X[M->>V1]

• Problems:– Too limited– Unnatural

• Solution– Use CWA locally for overriding missing facts

• if obtained facts do not contradict known facts

– Is this abduction?

Locally Closed OO Semantics for CHORD

Local Inheritance Context

• Definition:–a :: b, b[m->d]–b[m->d]/a

Local Overriding Inheritance Context

• Proposal:– Change the semantics from:

• a :: b b[m->d] (1)– To:

• a :: b b[m->d] X,Y( a::X X::b X[m->Y]) (2)– In this case we can inherit:

• a[m->d] (3)• If it comes directly from b

– If (2) is consistent with the current constraint store and program rules we say that (1) is a Consistent Overriding Local Inheritance Context

Not all Local Overriding Inheritance Contexts are consistent...

c1[m->a] ==> c1::c3.

GOAL: c1::c2, c3::c2, c2[m->a], c3[m->b]

c1::c2, c2[m->a] is a local overriding inheritance context!

c1[m->a]/c2 is NOT a consistent local overridinginheritance context because

X,Y( c1::X X::c2 X[m->Y]) is false for X = c3, Y = b

Proposal

Local Inheritance Contexts

Constraint Store

1. The final stores considers just the consistentlocal overriding inheritance contexts

2. Use backtracking to find the consistentlocal inheritance contexts

Important

There’s no negation in CHR so:

It’s not possible to directly prove anything like:

X,Y( a::X X::b X[m->Y])

BUT we can look for a counterexample.

Overriding in OWA (2nd Version) /1

X::Y, Y[M->V] ==> X[M->V1], ((V=V1, X[M->V1]/Y) ; true)

1st option:Suppose I’m consistent and the value of V can be directly inherited

2nd option:Maybe I’m not consistent

Overriding in OWA (2nd Version) /2

X[M->V]/Y, X::C, C::Y, C[M->Vx] ==> false.

Is there any provable counterexample?Backtrack.

Multiple Inheritance

Local Source Based Multiple Inheritance Context

• Proposal:– Change the semantics from:

• a :: b b[m->d] (1)– To:

• a :: b b[m->d] X,Y,T( b≠X a::X b::X X::b (X[m->Y] X[m=>T])) (2)

– In this case we can inherit:• a[m->d] (3)• If no other unrelated superclass defines m (for any value)

– If (2) is consistent with the current constraint store and program rules we say that (1) is a Consistent Local Source Based Multiple Inheritance Context

Local Value Based Multiple Inheritance Context

• Proposal:– Change the semantics from:

• a :: b b[m->d] (1)– To:

• a :: b b[m->d] X,Y,T( b≠X a::X b::X X::b X[m->Y] Y ≠ d) (2)

– In this case we can inherit:• a[m->d] (3)• If no other unrelated superclass defines m to be d

– If (2) is consistent with the current constraint store and program rules we say that (1) is a Consistent Local Value Based Multiple Inheritance Context

Multiple Inheritance in OWA

• We can’t do this change only by the means of extra rules:– We can’t prove negative constraints like

X,Y,T( b≠X a::X b::X X::b (X[m->Y] X[m=>T])))

– We can’t find a counterexample for it• We would need to prove “X::b”

• We need to change the default semantics of CHR

Possible Solutions

• Adopt a less restrictive multiple inheritance semantics

• Extend CHR semantics to handle negation

Less Restrictive Multiple Inheritance Semantics

Proposal

• We do not need extra rules to handle multiple inheritance. Ex:

a::b, a::c, b[m->2], b[m->3]

– This constraint store is false, because we are going to inherit a[m->2] and a[m->3] for a

• This is a similar approach to current programming languages supporting multiple inhertance (e. g. C++)– Multiple inheritance conflicts cause compilation or runtime

errors.

Changing default CHR semantics

Source Based Multiple inheritance in OWA

X[M->V]/Y, X::C, C::Y, Y::C, C[M->Vx] ==> YC | false.

X[M->V]/Y, X::C, C::Y, Y::C, C[M=>T] ==> YC | false.

Is there any provable counterexample?Backtrack.

Value Based Multiple inheritance in OWA

X[M->V]/Y, X::C, C::Y, Y::C, C[M->V] ==> YC | false.

Is there any provable counterexample?Backtrack.

CHRD¬

Negation as Absense

• Extending CHR with negation as Absence [Schrijvers et al 2006]

• p \\ q ==> r– If p is present and q is absent, then add r

• Conclusion– Lost declarativity– Lost theoretical properties – Non-logical negation

• We need logical negation!

Negation in Integrity Constraints + Abduction

• An Experimental CLP Platform for Integrity Constraints and Abduction [Abdennadher, 2000]

• For each predicate p, generate an abducible predicate p characterized by the integrity constraint:– p, p ==> false

Negation in Integrity Constraints + Abduction

• Conclusion– Doesn’t properly handle negation in rule head

• p may be true even if there’s no “p” in the constraint store

a ==> falsep ==> ab, p ==> cd, c ==> t

Initial store: b, d

“t” is true, however Abdennadher can’t prove it

My Proposal

• For each user defined constraint p– allow the constraint p having the same

arity– add the following integrity constraint

• p(X), p(Y) ==> X = Y | false

• Change rule head matching semantics

New rule semantics

• p0, ..., pn ==> g | b– If

• “p0,...,pk” match some constraint set in the current constraint store

– At least one constraint in the rule head must be on the constraint store (avoids trivial non termination)

• Adding “(pk+1 ; ... ; pn)” to current constraint store doesn’t lead to a failed state

• Guard holds

– Then• Add body to the current constraint store

Remarks

• This approach • adds logical negation to CHR• Generalizes the semantics of CHR rule matching

– CHRD: rule fires if there’s a set of matching constraints on the constraint store– CHRD : rule fires if there is a proof for the existence of matching

constraints for the rule head» Looking for matching constraints is still proving them

• Adding “(r s)” to current constraint store means:• T (r s ) |= • T |= (r s ) • T |= (r s )• T |= r s

Example

R1 @ p ==> falseR2 @ b, p ==> cR3 @ d, c ==> t

Initial store: b, d

Example – Extended Program

R1 @ p ==> falseR2 @ b, p ==> cR3 @ d, c ==> tE1 @ b, b ==> falseE2 @ c, c ==> falseE3 @ d, d ==> falseE4 @ p, p ==> false

Example – Execution

R1 @ p ==> falseR2 @ b, p ==> cR3 @ d, c ==> t

E1 @ b, b ==> falseE2 @ c, c ==> falseE3 @ d, d ==> falseE4 @ p, p ==> false

+ Store: b, d+ Rule try: R3, (trying: c)

++ Store: b, d, c++ Rule try: R2 (trying: p)

+++ Store: b, d, c, p+++ Rule: R1 – failed state, backtrack

++ Store: b, d, c, c++ Rule: E2 – failed state, backtrack

+ Store: b, d, t

Example with Variables

R1 @ p(2) ==> false.R2 @ q(X), p(X) ==> s(X).

Initial store: q(2)

Example with Variables – Extended Program

R1 @ p(2) ==> false.R2 @ q(X), p(X) ==> s(X).E1 @ p(X), p(Y) ==> X = Y | false.E2 @ q(X), q(Y) ==> X = Y | false.E3 @ s(X), s(Y) ==> X = Y | false.

Example with Variables – Execution

R1 @ p(2) ==> false.R2 @ q(X), p(X) ==> s(X).

E1 @ p(X), p(Y) ==> X = Y | falseE2 @ q(X), q(Y) ==> X = Y | falseE3 @ s(X), s(Y) ==> X = Y | false

+ Store: q(2)+ Rule try: R2 (trying p(2))

++ Store: q(2), p(2)++ Rule: R1, failed state, backtrack

+ Store: q(2), s(2)

Future Work on CHRD¬

• Investigate termination of CHRD¬ programs– Rules may be appliable even with no matching

constraint at current constraint store

• Investigate variables in rule head– How to deal with not found constraints containing

uninstantiated variables?