Prolog Best Practices

Analogy categoryAnalogies

Writing good Prolog is less about syntax and more about designing predicates that have a clear declarative reading, a predictable calling convention, and a search behavior you can reason about. Established habits — consistent argument ordering, sparing use of cuts, avoiding accidental infinite loops, and testing predicates in multiple query modes — separate maintainable Prolog from code that only works for the one query the author happened to try. Because the same predicate can be called with different arguments bound or unbound, robust Prolog code is written with all realistic calling patterns in mind, not just the 'happy path'.

🏏

Cricket analogy: Designing a predicate to work whether the first or second argument is bound is like a genuine all-rounder such as Ravindra Jadeja being useful whether the team needs him to bowl first or bat first, rather than a specialist who only performs in one specific match situation.

Predicate Design and Documentation

Good Prolog predicates follow a consistent argument convention — typically input arguments first, output arguments last — and are documented with mode and determinism annotations such as %! length(+List, -Length) is det, which tells callers what must be bound going in and what comes out. Predicate names should read naturally in a query, like parent(tom, bob) or is_leap_year(2024), and each predicate should capture one clear relation rather than conflating several unrelated behaviors behind conditional branches. Avoiding singleton variables (variables used only once, usually a typo) is also essential — SWI-Prolog and most other systems emit a warning for them, and that warning should never be ignored.

🏏

Cricket analogy: Documenting a predicate's modes like +List, -Length is like a scorecard clearly labeling which column is 'balls faced' versus 'runs scored', so anyone reading it instantly knows what's given and what's derived, unlike a scrawled note mixing the two together.

prolog

% Poorly named / undocumented
x(A,B) :- y(A,C), z(C,B).

% Well documented, consistent argument order
%! sibling_of(+Person, -Sibling) is nondet.
%  True when Sibling shares a parent with Person and is not Person.
sibling_of(Person, Sibling) :-
    parent(Parent, Person),
    parent(Parent, Sibling),
    Sibling \= Person.

Cut Discipline and Negation as Failure

The cut (!) should be placed immediately after the head and any tests that determine a clause is the right one, committing to that choice without discarding solutions the query still needs — this is called a 'green cut' because removing it wouldn't change the set of correct answers, only performance. A 'red cut' changes the logical meaning of the predicate and should be used sparingly and documented clearly, since it makes the predicate's behavior depend on clause order in a way that's easy to get wrong when the program is later refactored. Negation as failure (\+ Goal) is unsound when Goal contains unbound variables — \+ member(X, [1,2,3]) succeeds by binding nothing and leaving X unconstrained, which can silently produce wrong results if the caller expected X to be meaningfully instantiated afterward.

🏏

Cricket analogy: A green cut is like a third umpire confirming a clear six and moving on without reviewing every other camera angle — it doesn't change the correct decision, only how fast play resumes, unlike a red cut that would be like changing the actual result based on which camera you happened to check first.

\+ Goal only tells you Goal cannot currently be proven — it does not mean Goal is false in general, especially with unbound variables. Always ground the relevant variables before negating a goal, or you risk logically unsound conclusions.

Performance: Indexing, Accumulators, and Tail Recursion

SWI-Prolog and most modern systems perform first-argument indexing automatically, quickly skipping clauses whose first argument's principal functor can't unify with the call — so putting the most distinguishing argument first (an atom or tagged functor rather than an unbound variable) meaningfully speeds up predicates with many clauses. List-building predicates should use an accumulator and build results in reverse then flip once, or use difference lists, rather than the naive pattern of calling append/3 inside a recursive call, which produces quadratic behavior because each append/3 call re-traverses its first list. Tail-recursive predicates, where the recursive call is the last goal in the clause body, allow last-call optimization so the call stack doesn't grow unboundedly on long lists — a naive non-tail-recursive reverse or sum can blow the stack on large inputs where an accumulator-based version runs in constant stack space.

🏏

Cricket analogy: First-argument indexing is like a bowling attack immediately identifying a left-hander at the crease and switching to the pre-planned line, rather than bowling a generic delivery and adjusting only after seeing the shot played.

prolog

% Naive reverse: quadratic due to append/3 inside recursion
naive_reverse([], []).
naive_reverse([H|T], R) :-
    naive_reverse(T, RT),
    append(RT, [H], R).

% Accumulator reverse: linear, tail-recursive
fast_reverse(List, Reversed) :-
    fast_reverse(List, [], Reversed).

fast_reverse([], Acc, Acc).
fast_reverse([H|T], Acc, Reversed) :-
    fast_reverse(T, [H|Acc], Reversed).

SWI-Prolog's listing/1 prints a predicate's clauses exactly as loaded, and gtrace/0 opens the graphical debugger — both are indispensable for verifying that clause order and indexing are behaving the way you expect before you optimize.

Order predicate arguments consistently (inputs before outputs) and document modes and determinism.
Avoid singleton variables — they usually indicate a typo and most systems warn about them for a reason.
Prefer green cuts (which don't change results) over red cuts (which change logical meaning) and document any red cut clearly.
Negation as failure (\+ Goal) is unsound with unbound variables — ground relevant variables before negating.
Put the most distinguishing argument first to benefit from first-argument indexing.
Use accumulators or difference lists instead of naive append-in-recursion to avoid quadratic list-building.
Write predicates as tail-recursive where possible so last-call optimization keeps stack usage constant on large inputs.