12.2 How to treat a Constraint as a Value?

In order work with constraints, it would be nice if a constraint store could be a value accessible by a variable. In this way, one could, for instance report unification failure by binding a variable to a value, say the empty list for instance. One could also define all kinds of operations on constraints as discussed in the following examples.

For instance, one might consider the following existential constraints

local Y in  X=f(Y Y) end

which requires the value of X to be a tree with two identical subtrees at first and second position. Once this constraints is told to the constraint store, only the operations of the constraint store are applicable to it. For instance, one can ask the constraint store for the equality between both subtrees of X:

case X.1==X.2 then {Browse true} else {Browse false} end

This conditional can behave in three possible manners depending on the state of the constraint store:

• Whenever the asked equality is logically implied by the constraint store, true is browsed.

• If the equality is inconsistent with the constraint store, true is browsed.

• If equation is not yet available but could be added lateron the conditional suspends until more information is available.

The third case may be problematic if one would like to know about the actual state of the constraint store at the time point being. An alternative conditional which never blocks can be written in Oz. In general, however, it is not clear how to write operations for the constraint store which are not directly expressible by the constructs of the Oz-language.

A trivial way of how to represent constraints - which works in all programming languages - is to use ground terms (trees) for representing constraints and then to define all operations for them by hand. For representing the above constraints, we might write for instance:

f(1 1)

Here, the integer 1 is not intended to be a value itself but simply expresses the coreference between the two positions of the described term. When using ground terms for descriptions, however, it is impossible to use the operations of the constraint store like unification. For instance, the terms f(1 1) and f(3 g(2)) should be unifiable since the information they represent can be combined. In order to do so, the user has to write its own unification procedure Unif which is able to deal with applications like:

{Unify f(1 1) f(3 g(2))}

Writing unification by hand is odd, in particular when using a programming language which provides unification.