
+Constraint r_conflict ?ConflictSet

   Annotate Constraint as a repair constraint and monitor it for conflicts.

Arguments
   Constraint          Constraint to be monitored for conflict (Goal)
   ConflictSet         Handle for the conflict set (atom or varibale)
                argument can alternatively be ConflictSet-ConflictData

Type
   library(repair)

Description

Repair constraints are constraints that are monitored by the repair library 
for conflicts caused by the tentative values of variables in the constraints. 
r_conflict/2 annotates a constraint to be a repair constraint, and performs
the simplest form of monitoring for violation: the repair constraint is 
passive in that it simply waits for constraint to become violated due to 
bindings to its variables or their tentative values. In such a case, the 
constraint will show up in the ConflictSet, from where it can be
retrieved using conflict_constraints/2.


Note that setting up a repair constraint does not propagate the 
constraint as a normal constraint as well. Call the constraint again
without the annotation to propagate the constraint.


Constraint can be any goal that works logically, it should be useable
as a ground check, and work on any instantiation pattern. Typically,
it will be a constraint from some solver library.


ConflictSet can be a user-defined name (an atom) or it can be
a variable in which case the system returns a conflict set handle that can
later be passed to conflict_constraints/2. 


Note that using different conflict sets for different groups of constraints
will often make the search algorithm easier and more efficient.
A second allowed form of the r_conflict annotation is
Constraint r_conflict ConflictSet-ConflictData.
If this is used, f ConflictData will appear in the conflict
set instead of the Constraint itself.
This feature can be used to pass additional information to the
search algorithm.


Modules
   This predicate is sensitive to its module context (tool predicate, see @/2).

Resatisfiable
   no

Examples
   % lib(fd) is loaded
[eclipse 17]:  A #= B r_conflict c , B tent_set 11, A tent_set 5,  conflict_constraints(c, X).

B = B{11}
A = A{5}
X = [A{5} #= B{11}]  % the constraint is in conflict due to tentative values

[eclipse 18]: A #= B r_conflict c , B = 11, A = 5, conflict_constraints(c, X).

B = 11
A = 5
X = [5#=11] % the constraint is in conflict due to the values of the variables

 A #= B r_conflict c, B tent_set 11, conflict_constraints(c, X).

A = A
B = B{11}
X = []  % the constraint is not in conflict

 A::[1..10],  A #= B r_conflict c, B tent_set 11, conflict_constraints(c, X).

A = A{[1..10]}
B = B{11}
X = [A{[1..10]} #= B{11}]

[eclipse 26]:  A::[1..10],  A #= B r_conflict c, A #= B, B = 11, conflict_constraints(c, X).

no (more) solution. 
% fails because A #= B is also set up as a normal constraint

[eclipse 23]: A::[1..10],  A #= B r_conflict c, A #= B, B tent_set 11, conflict_constraints(c, X).

A = A{fd:[1..10], repair:11}
B = A{fd:[1..10], repair:11}
X = [A{fd:[1..10], repair:11} #= A]
% does not fail because the normal A #= B does not consider tenative values


See Also
   conflict_constraints / 2, r_conflict_prop / 2
