Primitive for updating the upper bound of Var so that it is at most Bound. A bound update on a variable may fail (when the update empties the domain), succeed (possibly updating the variable's bounds), or instantiate the variable (in the case where the domain gets restricted to a singleton value). Note that if the variable's type is integer, its bounds will always be adjusted to integral values.
Note that this predicate is intended for use only in implementing constraint propagators, and should not be called from ordinary user code (use ic:(Var =< Bound) instead). It differs from the usual constraint predicates in several ways. First, Bound is assumed to be exact (i.e. if it's a float, it's not widened). Second, if Bound is a bounded real, only its upper bound is significant, and it is this which is imposed on Var.
The final and most important difference relates to the execution of delayed goals. If the call to impose_max/2 results in a bound change, any delayed goals suspended on that bound will be scheduled for execution, as normal. However, impose_max/2 does not call the woken goal scheduler (wake/0), so these goals may not be executed immediately. (It is possible that under some circumstances the goals will be executed, if wake/0 is called indirectly - one example would be by the unify handler if the variable becomes ground - but this should not be relied upon.) To ensure that the goals are eventually executed, the caller should arrange for wake/0 to be called at some appropriate point in the subsequent execution. Please see the "Advanced Control Features" section of the User Manual for more information about woken goal management.
[eclipse 3]: X $:: 0..10, impose_min(X, 4.5).
X = X{4.5 .. 10.0}
Yes (0.00s cpu)
[eclipse 4]: X $:: 0..10, impose_min(X, 4.5), integers([X]).
X = X{5 .. 10}
Yes (0.00s cpu)
[eclipse 5]: X $:: 0..10, impose_min(X, 4.5), integers([X]), impose_max(X, 5.9).
X = 5
Yes (0.00s cpu)
[eclipse 6]: X $:: 0..10, impose_min(X, 4.5), impose_max(X, 4.3).
No (0.00s cpu)