5.6.1 Single Sided Unification Guards

Using the construction Head, Guard => Body, the Guard is executed after the single sided head unification. If the Guard succeeds the clause executes a cut (!/0) and proceeds normally. There are no restrictions on the guard code. A well behaved guard is a test. Notably:

• Though not enforced^{183We do not know about an efficient way to enforce unification against head arguments}, guard code shall not instantiate variables in the Head because this breaks the promise of SSU and may make the node non-steadfast.
• It is bad style (but again, not enforced) to have any type of side effects (output, database change, etc.)
• Typically, guard calls are semidet. Non-deterministic calls are allowed. If the guard succeeds with choicepoints these are pruned before the body is entered.

As a special exception, explicit unification against a variable in the head is moved into the head. See section 2.17.3. In the example below, the X = f(I) is moved into the head and (thus) is executed using single sided unification.

p(X), X = f(I), integer(I) => q(X).

Warning Moving the guard unification into the head changes the semantics of the unification. This may be defended by the rules above that claim one should not unify against the head arguments in the guard. Future versions may use a dedicated operator to indicate that the unification may be moved into the head.