To use the constraints, ECLiPSe needs to know which solver to pass a particular constraint to. The easiest method for doing this is to module qualify the constraint. For example,
..., fd: (A #>= B), ...
passes the constraint A #>= B to the fd solver. The solver must be
loaded first (e.g. via lib/1) before any constraint can be passed to it.
A constraint can also be passed to more than one solver by specifying a list in the module qualification. For example,
..., [fd, suspend]: (A #>= B), ...
will pass the constraint to both the fd and suspend solvers.
Module qualification is not needed if the constraint is defined in a module
imported into the current module, and there is no other imported module
which defines the same constraint. For example, if fd is the only module
imported which defines #>=/2, then #>=/2 can be used without
qualification:
..., A #>= B, ...
Module qualifications are recommended if the user wants to ensure the right behaviour regardless of which other modules might be loaded.
Note that for constraints that are defined for eclipse_language,
such as >= (the standard arithmetic test), the default behaviour
when an unqualified call to such a
constraint is made is to pass it to eclipse_language,
even if another solver which defines the constraint is imported.
Thus, for example
..., A >= B, ...
will by default have standard (i.e. non-suspending) test semantics, even
if, e.g. the ic library (which also defines >=/2) is
imported. This behaviour can be overridden by explicitly importing a
constraint before it is used for the first time:
:- lib(ic). :- import (>=)/2 from ic. ic_ge(A, B) :- A >= B. simple_test_ge(A, B) :- eclipse_language: (A >= B).
In this case, A >= B will be passed to the ic solver, and to use
the standard arithmentic test >=/2, it needs to be qualified with
eclipse_language instead.