7.7 Programming Tips and Tricks

• Check guard bindings yourself
  It is considered bad practice to write guards that bind variables of the head and to rely on the system to detect this at runtime. It is inefficient and obscures the working of the program.

• Set semantics
  The CHR system allows the presence of identical constraints, i.e. multiple constraints with the same functor, arity and arguments. For most constraint solvers, this is not desirable: it affects efficiency and possibly termination. Hence appropriate simpagation rules should be added of the form: [ constraint \constraint <=> true ]

• Multi-headed rules
  Multi-headed rules are executed more efficiently when the constraints share one or more variables.

• Mode and type declarations
  Provide mode and type declarations to get more efficient program execution. Make sure to disable debug (-nodebug) and enable optimization (-O).

• Compile once, run many times
  Does consulting your CHR program take a long time in SWI-Prolog? Probably it takes the CHR compiler a long time to compile the CHR rules into Prolog code. When you disable optimizations the CHR compiler will be a lot quicker, but you may loose performance. Alternatively, you can just use SWI-Prolog's qcompile/1 to generate a .qlf file once from your .pl file. This .qlf contains the generated code of the CHR compiler (be it in a binary format). When you consult the .qlf file, the CHR compiler is not invoked and consultation is much faster.

• Finding Constraints
  The find_chr_constraint/1 predicate is fairly expensive. Avoid it, if possible. If you must use it, try to use it with an instantiated toplevel constraint symbol.