Assume we want to make Social Security payments. That is, pay(X,Y) means ``pay the sum X to Y''. Assume that we also have this code fragment.
pay(X,Y):-In each clause, the first subgoal in the body is acting as a test in a program using the test --- process schema. We also assume that, for some reason, we have not been able to apply the disjoint (and exhaustive) case analysis technique.
Consequently, if we have successfully checked that a person is British and, for some reason, the subgoal entitled(X,Details,Y) fails (or some later computation forces backtracking back to redo the call to pay/2 that we are considering) then there may be no point in
The truth is, of course, that we may want these two consequences whether or not entitled/3 fails.
If this is so, then we insert a cut as shown below and highlighted by a .
pay(X,Y):-We want to be committed to the choice for the pay/2 predicate. We can see the use of !/0 as a guard that has two effects.
Note that, with the cut in the position it is above, it is still possible that entitled/3 could be resatisfied. We have to guarantee that we have made entitled/3 determinate before we can guarantee that pay/2 is determinate. We have to do some more on this issue.
Also note that the effect of cut ( !/0) prunes the search space only until the parent goal of the cut fails. If we leave the Fail port of pay/2 and some previous goal leads to another call to pay/2 then the cut ( !/0) has no effect until it is executed.
We also have to remember that cut ( !/0) has two distinct effects: backtracking cannot redo any subgoals to the left of the cut and clauses in the program database for the same predicate that are textually after the current clause are unreachable. See figure 9.1 for a graphic representation of these effects on a rather artificial program.
Figure 9.1: The Effect of cut on the AND/OR Tree