Constraint handling rules

Constraint Handling Rules

and a closer look at Chameleon

Sander Mak

Centre for Software Technology, Universiteit Utrecht

October 13, 2006

Centre for Software Technology Sander Mak

Constraint Handling Rules > Introduction

Outline

Introduction
1

Syntax, Solving and Semantics
2

Conﬂuence
3

CHR Applications
4

Chameleon
5

Comparisons and conclusions
6



Author
Formalism introduced by Thom Fr¨hwirth in 1991
u
Universit¨t Ulm, Germany
a
Tom Schrijvers at KU Leuven
Big, active community:
over 700 papers referring to CHR
various workshops on the theory and applications

: The logo



What is CHR?

Multi-headed, committed-choice language
High level constraint language
Possible interpretation: a formalism to write specialized solvers
Executable speciﬁcation
Exhaustive rewriting with rules



What is CHR?

Elements of a CHR system:
Embedding of (some)
CHR syntax
Alternatively: an API
to build CHR
programs/rules
A built-in constraint
solver

Several implementations: in
Java, Haskell, Lisp etc.


Constraint Handling Rules > Syntax, Solving and Semantics > Syntax

Three types of rules (syntax)

⇔ G1 ...Gj | B1 ...Bk
Simpliﬁcation : H1 ...Hi
⇒ G1 ...Gj | B1 ...Bk
Propagation : H1 ...Hi
H1 ...Hl Hl+1 ...Hi ⇔ G1 ...Gj | B1 ...Bk
Simpagation :
space
Where:
Hi : head atoms (CHR constraints) i>0
Gj : guards (built-in constraints) j≥0
Bk : body (CHR/built-in constraints) k≥0
space
Simpliﬁcation replaces constraints (logical equivalence)
Propagation adds constraints (logical implication,redundance)
space
Simpagation does both and can be desugared to:
H1 ...Hl ∧ Hl+1 ...Hi ⇔ G1 ...Gj | H1 ...Hl ∧ B1 ...Bk


Constraint Handling Rules > Syntax, Solving and Semantics > Syntax

Example rules
Define partial order relation ≤
≤ Y∧Y≤X ⇔
antisymmetry : X X=Y
≤ Y∧Y≤X ⇒ X≤Z
transitivity : X
≤ Y∧X≤Y ⇔ X≤Y
redundancy : X
≤ ⇔
reflexivity : X X true
≤ ⇔ X = Y | true
(alt. reflexivity) : X Y

≤ ∧ ≤ ∧ ≤ C∧A≤A
A B C A B reflexivity
≤ ∧ ≤ ∧ ≤
A B C A B C transitivity
≤ ∧ ≤ ∧ ≤ C∧C≤B
A B C A B antisymmetry
≤ ∧ ≤ ∧
A B C A B = C antisymmetry (with B=C)
∧
A = B B = C result!


Constraint Handling Rules > Syntax, Solving and Semantics > Solving

Solving

Informal outline of the solving process:
Start with initial constraints (goal or constraint store)
1

Find matching CHR
2

match means:
constraints in store match head of rule
guard of this rule holds true
implementation issue: try rules top to bottom (according to source
CHR program)
No match: solving is done
3

otherwise: update goal (replace or add constraints)
4

Contradiction in goal: solving is done
5

otherwise: goto step 2
6



Solving

Committed-choice: no backtracking
Constraint Theory - built-in constraints are available at every step
even host language code may be used, but it must be declarative
Earlier results inﬂuence matching (as in example)
Avoid trivial non-termination: apply propagations only once
what if head propagates to itself?
Non-deterministic choices (but does not aﬀect outcome):
In which order are rules considered?
1

Which element of the goal is picked in case of multiple candidates?
2



Solving

The sieve of Eratosthenes

The rules of the game
: primes(1) ⇔ true
cutoﬀ rec
: primes(N) ⇔ N > 1 | M is N-1, p(N), primes(M)
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
sift

spacer
spacer
spacer
spacer
spacer
spacer
spacer


Solving


cutoﬀ rec
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
sift

spacer
spacer
spacer
spacer
POP-QUIZ: Can you improve (ok, slightly) the deﬁnition of sift?
spacer


Solving


cutoﬀ rec
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
sift

spacer
spacer
spacer
spacer
Ok, a hint then: can you rewrite it to a simpagation rule?
spacer


Solving


cutoﬀ rec
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
sift

spacer
spacer
spacer
spacer
Answer: sift: p(I) / p(J) ⇔ J % I = 0 | true
spacer


Solving


cutoﬀ rec
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
sift

Find all primes up to 7
primes(7) (initial goal)
p(7),primes(6) (gen primes)
p(7),p(6), primes(5) (gen primes)
p(7),p(6), p(5), primes(4) (gen primes)
p(7),p(6), p(5), p(4), primes(3) (gen primes)
.... Centre for Software Technology Sander Mak


Solving


cutoﬀ rec
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
sift

Find all primes up to 7 (cont’d)
p(7),p(6), p(5), p(4), p(3), primes(2) (gen primes)
p(7), p(5), p(4), p(3), p(2), primes(1) (sift)
p(7), p(5), p(4), p(3), p(2), true (cutoﬀ rec)
p(7), p(5), p(3), p(2) (sift)



Solving


Most ’elegant’ imperative algorithm (Wikipedia):
limit = 1000000; // arbitrary search limit
for (i = 2; i <= limit; i++) {
is_prime[i] = true // assume all numbers are prime at first
}
for (n = 2; n <= sqrt (limit); n++) {
if (is_prime[n]) {
// eliminate multiples of each prime, starting with its square
for (i = n^2; i <= limit; i += n) { is_prime[i] = false }
}
}
for (n = 2; n =< limit; n++) {
if is_prime[n] then print n
}

CHR combines data and computation in elegant and concise
speciﬁcation

Constraint Handling Rules > Syntax, Solving and Semantics > Semantics

Semantics of CHRs
There are at least 3 diﬀerent semantics in the literature:
1 Operational Semantics

Introduces a state transition mechanism
Transitions to:
Apply one of the rule types
Introduce a constraint
Solve a built-in constraint
Reﬁned Operational Semantics also includes order of evaluation
Formalizes the intuitive solving algorithm
Declarative Semantics
2

Expresses CHRs in pure 1s t order logic
Facilitates proofs and analysis
Linear Logic Semantics
3

Most useful in non-traditional use of CHR
Uses subset of linear logic, which can explicitly model resource
usage


Declarative Semantics

Simpliﬁcation Propagation
spacer spacer
H⇔G|B H⇒G|B
meaning meaning
∀ (G → (H ↔ ∃y B)) ∀ (G → (H → ∃y B))
spacer
With these translation rules, we can state:
spacer
CHR program P
meaning
CT ∧ r ∈P meaning (r )
spacer
Example:
X ≤ Y ⇔ X = Y | true meaning ∀X,Y (X = Y) → (X ≤ Y ↔ true)



Properties of CHR solvers

Online → at any point in time a safe approximation
Incremental → adding a constraint to the goal does not invalidate
previous steps
Concurrent → applying rules in parallel does not aﬀect semantics
spacer
Solving a goal using a CHR program requires monotonicity :
if A →P B then A ∧ C →P B ∧ C, for all C


Constraint Handling Rules > Confluence

Confluence definition

’The confluence property guarantees that any computation starting
from a goal results in the same final state’ spacer
Computation result should be independent of the ordering of rules
and independent of ordering of picking elements from goal
spacer
Example non-confluent CHR program
r1: P ⇔ Q
r2: P ⇔ false
—————–
start computation with P

Result: Q or false...



Confluence
The previous program can be made confluent by adding a rule: spacer
Example confluent CHR program
r1: P ⇔ Q
r2: P ⇔ false
r3: Q ⇔ false
—————–
start computation with P

Result: always false spacer
Note: same result does not mean syntactically identical
Note: confluence does not guarantee termination
Confluence is an issue because of the committed-choice nature of
CHR
But, how to check confluence for a given program?


Confluence checking

Paper explains the confluence check using the refined operational
semantics
spacer
Key points:
Problems arise with overlapping heads
Confluence is compromised only with simplification rules
Still, overlapping heads are not necessarily problematic:
The rules of the game (you know, the Sieve..)
cutoff rec
gen primes
: p(I), p(J) ⇔ J % I = 0 | p(I)
elim nonprimes



Confluence checking

Confluence checking is a very non-trivial program analysis on the
CHR language. spacer
Possible by virtue of clean semantics
Details in paper
Completion: algorithm to make a program confluent based on
confluence check results.
Add a single rule each time until confluent
Termination not guaranteed
If it terminates, confluence is guaranteed
spacer



Confluence: implications

Using the fact that order is irrelevant, optimizations can be devised:
Favor simplification over propagation rules (goal does not grow)
Prefer single headed rules (find candidates faster)
If CHR is applied, first apply other CHRs involving same variables
(empirical data)
...
Some of these optimizations were implemented in the ECLi PSe CHR
compiler.


Constraint Handling Rules > CHR Applications

Roots of CHR

CHR embodies the ideas of several ancestral concepts:
Term rewriting
Constraint Logic Programming
Automated Theorem Proving (but CHR is restricted and
directional, therefore tractable)
Even integrity constraints in relational databases
As a consequence, interesting CHR programs can be derived from
applications in the above systems.



CHR applications

What can we do with CHRs?
Original ﬁeld: constraint reasoning
Program Analysis:
Type inferencing
..
Constraint satisfaction problems
Scheduling and timetabling
Polynomial equation solving
Theorem proving
Even useful/important things... (next slide)
Fr¨wirth: in ’unconventional’ applications, view conjuctions of
u
constraints as interacting collections of agents or processes



Diagnosis application
... such as:
’Cancer Diagnosis aid: lung cancer is leading cause of cancer death,
very low survival rate. Use bio-markers indicating gene mutations to
diagnose lung cancer.’ Simon Fraser University, Vancouver

Example CHR:
age(X,A),history(X,smoker),
serum_data(X,marker_type) <=>
marker(X,marker_type,P,B),
probability(P,X,B) |
possible_lung_cancer(yes,X).



Concluding words on CHR

CHR is Turing complete
But Fr¨wirth discourages viewing it as an general purpose
u
language
Every algorithm can be implemented in optimal space and time
complexity
claim by author, no proof attached
Better yet, implementation can start out almost isomorphic to
speciﬁcation. Later, performance tweaks can be applied.
Next big thingTM : CHR Machine



All the hard-working people who lavished us with CHR

Yes, you want to be part of this! really, you do, don’t you??


Constraint Handling Rules > Chameleon

Chameleon’s characteristics

Research project by Sulzmann, Stuckey and Wazny
Programming environment
Goals:
improve type error messages using precise location information
1

to experiment with advanced type extensions and corresponding
2

error messages.
Typing is implemented using CHRs
Haskell-style language, can interface with Haskell code

Contents of this part of the presentation based on:
Interactive Type Debugging in Haskell: Stuckey, Sulzmann
and Wazny 2003
and publications at:
http://www.comp.nus.edu.sg/~sulzmann/chameleon/



Chameleon recipe
Map expressions to constraints with attached program locations
Collect constraints for each function def. into simplification rule
Solve constraints and if succesful, build typescheme
Otherwise: find offending constraints

Generated constraints
For p: (t1 = Char )1 , f (t2 )2 ,
(t2 = t1 → t3 )3 , (t4 = t3 )4
Example For f :
(t5 = Bool)5 , (t6 = Bool)6 ,
p4 = (f2 ’a’1 )3
(t7 = t5 → t6 )7
f7 True5 = True6

Obviously not well-typed f (t) is a predicate symbol, referring
to an instance of f having type t
Actual constraints contain more
information


Chameleon recipe
A simplification for each function definition:
Corresponding CHRs
p(t4 ) ⇔ (t1 = Char )1 , f (t2 )2 , (t2 = t1 → t3 )3 , (t4 = t3 )4
f (t7 ) ⇔ (t5 = Bool)5 , (t6 = Bool), (t7 = t5 → t6 )7

Now let’s infer a type for p(t) (on hypothetical location 8):

p(t)8
→ (first rule)
(t = t4 ),(t1 = Char ){1,8} , f (t2 ){2,8} , (t2 = t1 → t3 ){3,8} , (t4 = t3 ){4,8}
→ (second rule)
(t = t4 ),(t1 = Char ){1,8} ,(t2 = t7 ),(t5 = Bool){5,2,8} ,
(t6 = Bool){6,2,8} , (t7 = t5 → t6 ){7,2,8} , (t2 = t1 → t3 ){3,8} , (t4 =
t3 ){4,8}

This is not satisfiable: (t1 = Char ) and (t5 = Bool) for example clash


Chameleon recipe
Now, we have to find a minimal unsatisfiable subset to highlight
locations:
Algorithm
Min unsat example
min_unsat(D)
(t1 = Char ){1,8} ,
M := {}
(t2 = t7 ),
while satisfiable(M) {
= t5 → t6 ){7,2,8} ,
(t7
C := M
= t1 → t3 ){3,8}
(t2
while satisfiable(C){
let e in (D - C)
Collect offending locations:
C := union(C,{e})
{1,2,3,5,7} (8 was hypothetical)
}
Result
D := C; M := union(M,{e})
} p4 = (f2 ’a’1 )3
return M f7 True5 = True6



Creating constraints
So far constraints followed ’naturally’. Formally, there is a
syntax-directed(?) constraint generation deduction system:



Chameleon is lazy...

Consider:
correct = let incorrect = 1 1
in True

Derived rules
⇔ (t1 =Int),(t1 =t2 → t3 ),(t2 =Int),(t3 =t)
incorrect(t)
⇔
correct(t) (t1 =Bool)

Inference for correct(t) will succeed and deliver Bool, despite the error
in f!



Type explanation
Chameleon has 3 ways of ’exploring’ types:
Compile time error messages
1

Interactive debugging: user answers questions about types in
2

min unsat
Example.hs>debug p
f :: Bool -> Bool
Example.hs is this type correct?>y
etc.
Source based directives:
3

reverse ::?
reverse = foldl (flip (:)) [ ]
-----Output @ compilation:-----
reverse :: [a] − > [[a]]



Comparing error messages

f g x y = (g (if x then x else y), g quot;abcquot;)
yields:
GHC: Couldn’t match ‘Bool’ against ‘[Char]’
Expected type: Bool
Inferred type: [Char]
In the ﬁrst argument of ‘g’, namely ‘”abc”’
In the deﬁnition of ‘f’: f g x y = (g (if ... y), g ”abc”)
Hugs: ERROR ”test.ch”:1 - Type error in application
** Expression : g (if x then x else y)
** Term : if x then x else y
** Type : Bool
** Does not match : [Char]
Chameleon: f g x y = (g (if x then x else y), g ”abc”)
spacer
My opinion: it’s better, but lacks actual type information


Typesystem extensions

Common type system design approach:
Find out and describe domain of types and constraints
Deﬁne set of well-typed programs and typing rules
Establish soundness of typesystem
Provide tractable type inference algorithm
CHR/Chameleon approach:
Make use of HM(X) type system CHR framework (X is extension)
Describe constraint domain X using CHRs
Do type inference/checking with CHRs
Paper: Chameleon, Systematic Type System Design via
Compositional type system building




Program on type level to introduce more advanced rules for:
Functional Dependencies
Existential types
Extensible records
The list goes on..

Example of type-level rule
f x y = x / y + x ‘div‘ y
Integral a, Fractional a ⇔ False




Existential types
Extensible records
The list goes on..

Compiler output
type error - contributing locations:
f x y = x / y + x ‘div‘ y
rule(s) involved: Integral a, Fractional a ⇔ False




Existential types
Extensible records
The list goes on..

Multi-parameter typeclasses with functional dependencies
Collect a b | a − > b
is modelled by:
Collect a b, Collect a b’ ⇒ b = b’


Constraint Handling Rules > Comparisons and conclusions

Helium vs. Chameleon vs. Type Error Slicing

Chameleon goals Helium goals
Provide framework for good Enhance user experience of
1 1

type error messages in beginners in a constrained
arbitrary advanced environment
environments Compile time error messages
2

Compile time error messages only
2

and interactive debugger No mechanism for type
3

As a consequence: has type explanation, only type error
3

explanation mechanisms explanation
Generic error reporting (only Specialized error messages
4 4

highlight locations) possible
Rules can be defined in source Rules can be defined orthogonal to
(extensions) sourcefiles


Helium vs. Chameleon vs. Type Error Slicing

Type Error Slicing
Provide good type error messages in constrained environment
1

Compile time error messages only
2

No mechanism for type explanation, only type error explanation
3

Generic error reporting (calculate slices)
4

Rules are ’embedded’ in HM style type system implementation



Closing remarks

CHR is a powerful mechanism
Has lots of intricacies not discussed, complexity can be high
Chameleon is a very relevant application of CHR
It was not really just how open the environment is


Constraint handling rules

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Constraint handling rules

Ähnlich wie Constraint handling rules (20)

Mehr von Sander Mak (@Sander_Mak)

Mehr von Sander Mak (@Sander_Mak) (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Constraint handling rules