17.5 Declarative Suspension: Delay Clauses
For delaying calls to user-defined Prolog predicates, ECLiPSe
provides several alternatives, the first being delay clauses.
Delay clauses are a declarative means (they are in fact meta-clauses)
to specify the conditions under which the predicate should delay.
The semantics of delay clauses is thus cleaner than many alternative
approaches to delay primitives.
A delay clause is very similar to a normal Prolog clause. It has the form
A predicate may have one or more delay clauses.
They have to be textually before and consecutive
with the normal clauses of the predicate they belong to.
The simplest example for a delay clause is one that checks if a variable
delay <Head> if <Body>.
The operational semantics of the delay clauses is as follows:
when a procedure with delay clauses is called, then the delay
clauses are executed before executing the procedure itself.
If one of the delay clauses succeeds, the call is suspended,
otherwise they are all tried in sequence and,
if all delay clauses fail, the procedure is executed as usual.
delay report_binding(X) if var(X).
printf("Variable has been bound to %w\n", [X]).
The mechanism of executing a delay clause is similar to normal Prolog
clauses with two exceptions:
The reason for using pattern matching instead of unification
is to avoid a possible mixing of meta-level control with the
object level, similarly to .
the unification of the goal with the delay clause head is not the usual
Prolog unification, but rather unidirectional pattern matching
(see also section 5.5).
This means that the variables in the call cannot be bound
by the matching, if such a binding would be necessary to
perform the unification, it will fail instead.
E.g. the head of the delay clause
does not match the goal p(A, b) but it matches the goal p(a, b).
delay p(a, X) if var(X).
- the delay clauses are deterministic, they leave no choice points.
If one delay clause succeeds, the call is delayed and the following delay
clauses are not executed.
As soon as the call is resumed, all delay clauses that may succeed
The form of the head of a delay clause is not restricted.
For the body, the following conditions hold:
the body subgoals must not bind any variable in the call and they
must not delay themselves.
The system does not verify these conditions currently.
- it should contain at least one of the following subgoals:
If this is not the case, then the predicate may delay without being linked
to a variable, so it delays forever and cannot be woken again.
Experience shows that the above four primitives suffice to express most
CAUTION: It may happen that the symbol :- is erroneously
used instead of if in the delay clause. To indicate this error,
the compiler complains about redefinition of the built-in predicate
A predicate that checks if its argument is a proper list of integers.
The delay conditions specify that the predicate should delay if the list
is not terminated or if it contains variable elements.
This makes sure that it will never generate list elements, but only
acts as a test:
delay integer_list(L) if var(L).
delay integer_list([X|_]) if var(X).
integer_list([X|T]) :- integer(X), integer_list(T).
- Delay if the first two arguments are identical and the third is a variable:
delay p(X, X, Y) if var(Y).
- Delay if the argument is a structure whose first subterm is not ground:
delay p(X) if compound(X), arg(1, X, Y), nonground(Y).
- Delay if the argument term contains 2 or more variables:
delay p(X) if nonground(2, X).
predicate as a delaying condition is useful mainly
in predicates like X + Y = Z which need not be delayed if X == Z.
Y can be directly bound to 0, provided that X is later bound to a number
(or it is not bound at all)
The condition X \== Y makes sense
only if X or Y are nonground: a delay clause
executed with the call ?- p(a, b) of course succeeds and the call delays
forever, since no variable binding can wake it.
delay p(X, Y) if X \== Y.