Options parametrise the rule compilation process. Thus they
should precede the rule definitions. Example:
The format below lists the names of the recognized options together with
the acceptable values. The first entry in the lists is the default
- Instruments the generated code such that the execution
of the rules may be traced (see CHR Debugging).
- Per default, for guards of type ask the CHR runtime system makes sure
that no variables are touched or the cause of an
instantiation error. These checks may be turned off with this
option, i.e. all guards are treated as if they were of the tell
variety. The option was kept for backward compatibility. Tell and ask
guards offer better granularity.
- If this option is on, the CHR runtime system checks for the presence of
an identical constraint upon the insertion into the store. If present,
the attempted insertion has no effect. Since checking for duplicates for
all constraints costs, duplicate removal specific to individual
constraints, using a few simpagation rules of the following form instead,
may be a better solution.
Constraint \ Constraint <=> true.
- The intention of simplification and simpagation rules is often to
combine the heads into a stronger version of one of them.
Depending on the strength of the guard, the new constraint may be
identical to one of the heads removed by the rule. This removal
followed by addition is inefficient and may even cause termination
problems. If the option is enabled, this situation is detected and the
corresponding problems are avoided. This option applies to all
constraints and is provided mainly for backward compatibility. Better
grained control can be achieved with corresponding pragmas. (see CHR Pragmas).
The remaining options are meant for CHR implementors only: