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,
..., ic: (A #>= B), ...
passes the constraint
A #>= B to the ic 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,
..., [ic, suspend]: (A #>= B), ...
will pass the constraint to both the ic and suspend solvers.
Module qualification is not needed if the constraint is defined by an
imported module, and there is no other imported module
which defines the same constraint. For example, if ic is the only imported
module which defines
#>=/2 can be used without
..., A #>= B, ...
Note that for constraints that are defined for
>= (the standard arithmetic test), the default behaviour
when an unqualified call to such a
constraint is made is to pass it to
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
imported. To access the
ic version, module qualification should
..., ic:(A >= B), ...
Alternatively, the synonymous
$>=/2 constraint could be used:
..., A $>= B, ...
In general, module qualifications are recommended if the programmer wants to ensure a particular constraint behaviour regardless of which other modules might be loaded. On the other hand, if the intention is to switch easily between different solvers by simply loading a different library, module qualification is best omitted.
Finally, it is also possible to let the running program determine which solver to use. In this case, the program has a variable in the module position, which will only be bound at runtime:
..., Solver:(A #>= B), ...
This will however prevent the solver from performing any compile-time preprocessing on the constraint.