7.6 Backwards Compatibility

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 programmer should be aware of the appropriate meaning of the Prolog goals used in guards and bodies of CHR rules.