Declarative Suspension: Delay Clauses

## 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

>     delay <Head> if <Body>.

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 is instantiated:

>     delay report_binding(X) if var(X).
>     report_binding(X) :-
>             printf("Variable has been bound to %w\n", [X]).

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.
The mechanism of executing a delay clause is similar to normal Prolog clauses with two exceptions:

- 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

  >     delay p(a, X) if var(X).

  does not match the goal p(A, b) but it matches the goal p(a, b).
- 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 are re-executed.

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 [3].
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:
  - var/1
  - nonground/1
  - nonground/2 (see nonground/3)
  - \==/2
  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 usual conditions.

#### More Examples

- 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([]).
  >     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).

- The \==/2 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

  >     delay p(X, Y) if X \== Y.

  executed with the call ?- p(a, b) of course succeeds and the call delays forever, since no variable binding can wake it.

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 delay/1.