We now go onto the key problem of making
our programs determinate.
That is, if they succeed, then they succeed precisely once
unless we * really* want them to generate alternative solutions.
Many programmers find taming backtracking to be a major problem.

Consider the problem raised by this program:

together with the goalsum(1,1).sum(N,Ans):-

NewN is N-1,

sum(NewN,Ans1),

Ans is Ans1+N. [-5pt]

The meaning of?- sum(2,X).

We * know* that, for the ** mode sum(+,-)**,
there is only one such result. Therefore, if we try to ** redo**
a goal such as ** sum(2,Ans)** it should fail.
We could test that this is so with:

We would like the result:?- sum(2,Ans),write(Ans),nl,fail.

Alas, here is the result using Edinburgh3no

We have a runaway recursion. Figure 9.2 shows the execution tree for the goal3(a very very long wait)

**Figure 9.2:** The First Solution to the Goal ** sum(2,Ans)**

Now look at the goal:

and the resulting fragment of the execution tree which is shown in figure 9.3.?- sum(2,X),fail.

**Figure 9.3:** Resatisfying the Goal ** sum(2,Ans)**

** Prolog** goes into a non terminating computation.
We want to make sure that, having found a solution, ** Prolog**
never looks for another solution via ** Redo**ing the goal.
Figure 9.4 shows the consequence when the cut (** !/0**) is used.

sum(1,1):-.

sum(N,Ans):-

NewN is N-1,

sum(NewN,Ans1),

Ans is Ans1+N.

**Figure 9.4:** The Effect of the cut on the Goal ** sum(2,Ans)**

Mon May 24 20:14:48 BST 1999