Hard cut (!) versus soft-cut (*->) for pruning a recursive search: which preserves debuggability?

Answer

For a recursive search that must commit to the first successful branch, a soft‑cut (Condition *-> Then ; Else) is semantically safer than a hard cut (!) placed after the guard. The two are equivalent only when the guard is deterministic (has at most one solution) and the Then branch contains no backtracking points of its own.

Why the soft‑cut is safer

• A hard cut eliminates all choice points created before it, including any alternative solutions of the guard and any earlier recursive alternatives. If the guard later turns out to have multiple solutions, those are silently discarded, changing the declarative meaning of the predicate (a “red cut”).
• A soft‑cut commits to the Then branch only after the guard succeeds once; it leaves the guard’s alternative solutions alive and allows backtracking into the Else branch if the Then branch later fails. This preserves clearer if‑then‑else semantics and makes debugging easier because the programmer can see why a particular branch was chosen.

Interaction with nested choice points

• Hard cut: If placed before the Then branch, it prunes not only the guard’s choice points but also any choice points created inside the Then branch (e.g., nested disjunctions or further recursion) unless an explicit cut appears later inside that branch.
• Soft‑cut: The outer soft‑cut does not affect choice points generated inside the Then branch. Those remain available for backtracking unless the programmer inserts another cut (hard or soft) within the branch itself.

Performance considerations

The soft‑cut introduces a modest overhead: the guard is evaluated, and a temporary choice point for the Else branch may be created. In SWI‑Prolog 9.x this overhead is typically small—often only a few percent—and only becomes measurable in tight loops where the guard succeeds the vast majority of the time. Profiling with statistics/2 or time/1 on a realistic data set is the only way to decide whether the cost justifies a hard cut.

Verification steps (recommended)

1. Write a minimal recursive predicate that searches a fact base with a guard.
2. Implement two versions: one with ! after the guard, another with Condition *-> Then ; Else.
3. Run each under the SWI‑Prolog debugger (trace/0) and observe which choice points are pruned.
4. Use statistics/2,time/1 to measure execution time on a large dataset.
5. Change the guard to have multiple solutions and confirm that the hard‑cut version loses those alternatives while the soft‑cut version still allows backtracking into the Else branch when the Then branch fails.

Missing diagnostic detail

To give a definitive recommendation, I need to know whether the guard predicate can succeed more than once for a given input. If the guard is guaranteed to be deterministic, a hard cut after it is safe and may avoid the tiny soft‑cut overhead; otherwise, the soft‑cut remains the safer choice.