This section gives you some programming hints for CHR. For maximum efficiency of your constraint handler, see also the previous subsections on declarations and options.

Constraint handling rules for a given constraint system can often be derived from its definition in formalisms such as inference rules, rewrite rules, sequents, formulas expressing axioms and theorems. CHR can also be found by first considering special cases of each constraint and then looking at interactions of pairs of constraints sharing a variable. Cases that do not occur in the application can be ignored.

It is important to find the right *granularity* of the constraints.
Assume one wants to express that `n` variables are different
from each other. It is more efficient to have a single constraint
`all_different(List_of_n_Vars)`

than `n*n` inequality
constraints between each pair of different variables. However,
the extreme case of having a single constraint modeling the whole
constraint store will usually be inefficient.

Starting from an executable specification, the rules can then be refined
and adapted to the specifics of the application. Efficiency can be
improved by weakening the guards to perform simplification as early as
needed and by strengthening the guards to do the *just right* amount
of propagation. Propagation rules can be expensive, because no
constraints are removed.

The more heads a rule has, the more expensive it is. *Rules
with several heads* are more efficient, if the heads of the rule
share a variable (which is usually the case). Then the search for
a partner constraint has to consider less candidates. In the current
implementation, constraints are indexed by their functors,
so that the search is only performed among the constraints containing
the shared variable. Moreover, two rules with identical (or
sufficiently similar) heads can be merged into one rule so that
the search for a partner constraint is only performed once instead of
twice.

As guards are tried frequently, they should be simple *tests*
not involving side-effects. Head matching is more efficient
than explicitly checking equalities in the ask-part of the guard. In
the tell part of a guard, it should be made sure that variables
from the head are never touched (e.g. by using `nonvar`

or
`ground`

if necessary). For efficiency and clarity reasons, one
should also avoid using constraints in guards. Besides
conjunctions, disjunctions are allowed in the guard, but
they should be used with care. The use of other control built-in
predicates in the guard is discouraged. Negation and if-then-else in
the ask part of a guard can give wrong results, since e.g. failure of
the negated goal may be due to touching its variables.

*Several handlers can be used simultaneously if* they do not share
constraints with the same name. The implementation will not work
correctly if the same constraint is defined in rules of different
handlers that have been compiled separately. In such a case, the
handlers must be merged *by hand*. This means that the source
code has to be edited so that the rules for the shared constraint are
together (in one module). Changes may be necessary (like
strengthening guards) to avoid divergence or loops in the computation.