Backtracking

  The essence of don't-know nondeterminism is that failing computations ``dont't count'' and only successful computations may produce observable results. The don't-care interpretation of nondeterminism, on the other hand, requires that results of failing computations be observable. Hence a don't-care nondeterministic computation may produce partial output.

Don't-care nondeterminism is essential in modeling concurrent interactive systems[31]. In concurrent systems it would be too expensive to backtrack a choice, even if it proves to be wrong. The reason is that a choice, and the actions done afterwards, have already influenced the environment: to maintain consistency the whole system should backtrack, but this is too inefficient. It is rather preferrable to provide mechanisms to control the choices, so to avoid as far as possible that wrong decisions are taken[5].

COCA has constructs for communication, asynchronous event posting, and transactions which produce side effects. We take both the don't-know and don't-care interpretation of nondeterminism. Suppose the following is the execution trace of an active rule where $m, n \geq 0$and q₁ is the first predicate with side effect.

This is similar to the guarded Horn clauses notation in concurrent logic programming languages[31,5]. The execution of an active rule is implicitly divided into two parts. p₁, ..., p_m corresponds to the guard part, and q₁, ..., q_n the body. A failed predicate in the guard part may incur backtrack. But once the body part is entered, the side effects ever generated cannot be undone.

As was introduced in subsection 6.2, failure of a predicate within a transaction causes the whole transaction to rollback. Not to contradict the don't-care semantics, we restrict that the definition of a transaction should not call (directly or indirectly) predicates that communicate or post events.