10.34.2.2 Semantics

In this subsubsection the operational semantics of CHR in Prolog are presented informally. They do not differ essentially from other CHR systems.

When a constraint is called, it is considered an active constraint and the system will try to apply the rules to it. Rules are tried and executed sequentially in the order they are written.

A rule is conceptually tried for an active constraint in the following way. The active constraint is matched with a constraint in the head of the rule. If more constraints appear in the head they are looked for among the suspended constraints, which are called passive constraints in this context. If the necessary passive constraints can be found and all match with the head of the rule and the guard of the rule succeeds, the rule is committed and the body of the rule executed. If not all the necessary passive constraint can be found, the matching fails or the guard fails, the body is not executed and the process of trying and executing simply continues with the following rules. If for a rule, there are multiple constraints in the head, the active constraint will try the rule sequentially multiple times, each time trying to match with another constraint.

This process ends either when the active constraint disappears, i.e. it is removed by some rule, or after the last rule has been processed. In the latter case the active constraint becomes suspended.

A suspended constraint is eligible as a passive constraint for an active constraint. The other way it may interact again with the rules, is when a variable appearing in the constraint becomes bound to either a non-variable or another variable involved in one or more constraints. In that case the constraint is triggered, i.e. it becomes an active constraint and all the rules are tried.

Rule Types. There are three different kinds of rules, each with their specific semantics:

simplification

The simplification rule removes the constraints in its head and calls its body.

propagation

The propagation rule calls its body exactly once for the constraints in its head.

simpagation

The simpagation rule removes the constraints in its head after the \ and then calls its body. It is an optimization of simplification rules of the form:

          constraints_1, constraints_2 <=> constraints_1, body

Namely, in the simpagation form:

          constraints_1 \ constraints_2 <=> body

the constraints_1 constraints are not called in the body.

Rule Names. Naming a rule is optional and has no semantical meaning. It only functions as documentation for the programmer.

Pragmas. The semantics of the pragmas are:

passive(Identifier)

The constraint in the head of a rule Identifier can only match a passive constraint in that rule.

Additional pragmas may be released in the future.

Options. It is possible to specify options that apply to all the CHR rules in the module. Options are specified with the chr_option/2 declaration:

     :- chr_option(Option,Value).

and may appear in the file anywhere after the first constraints declaration.

Available options are:

check_guard_bindings

This option controls whether guards should be checked for (illegal) variable bindings or not. Possible values for this option are on, to enable the checks, and off, to disable the checks. If this option is on, any guard fails when it binds a variable that appears in the head of the rule. When the option is off, the behavior of a binding in the guard is undefined.

optimize

This option controls the degree of optimization. Possible values are full, to enable all available optimizations, and off (the default), to disable all optimizations. If optimization is enabled, debugging must be disabled.

debug

This options enables or disables the possibility to debug the CHR code. Possible values are on (the default) and off. See CHR Debugging for more details on debugging.