There are small differences between the current K.U.Leuven CHR system
in SWI-Prolog, older versions of the same system, and SICStus’CHR
system.
The current system maps old syntactic elements onto new ones and
ignores a number of no longer required elements. However, for each a deprecated
warning is issued. You are strongly urged to replace or remove
deprecated features.
Besides differences in available options and pragmas, the following
differences should be noted:
- The constraints/1 declaration
This declaration is deprecated. It has been replaced with the
chr_constraint/1
declaration.
- The option/2 declaration
This declaration is deprecated. It has been replaced with the
chr_option/2
declaration.
- The handler/1 declaration
In SICStus every CHR module requires a handler/1 declaration declaring a
unique handler name. This declaration is valid syntax in SWI-Prolog, but
will have no effect. A warning will be given during compilation.
- The rules/1 declaration
In SICStus, for every CHR module it is possible to only enable a subset
of the available rules through the rules/1 declaration. The declaration
is valid syntax in SWI-Prolog, but has no effect. A warning is given
during compilation.
- Guard bindings
The check_guard_bindings option only turns invalid calls to
unification into failure. In SICStus this option does more: it
intercepts instantiation errors from Prolog built-ins such as is/2
and turns them into failure. In SWI-Prolog, we do not go this far, as we
like to separate concerns more. The CHR compiler is aware of the CHR
code, the Prolog system, and the programmer should be aware of the
appropriate meaning of the Prolog goals used in guards and bodies of CHR
rules.
