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 enforced183We 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.
