English for Prolog Developers

Prolog forces a genuinely different way of describing what code does: you’re not describing steps, you’re describing facts and rules, and letting the engine search for solutions. Teams new to logic programming often reach for imperative vocabulary that doesn’t actually match what’s happening, which is where confusion starts.

Key Vocabulary

Unification — the core mechanism by which Prolog matches a query against facts and rules, binding variables to values so both sides become identical, which is closer to pattern-matching-with-binding than to assignment or equality checking. “This isn’t assignment — when the query unifies with the fact, X gets bound to alice as a side effect of unification succeeding, and that binding persists for the rest of the current search branch.”

Backtracking — Prolog’s automatic process of undoing variable bindings and trying the next alternative when a goal fails or when more solutions are explicitly requested, the engine’s built-in search strategy rather than something the program author has to implement. “You don’t need a loop to find every matching parent — just ask the query again for more solutions, and backtracking will retry the alternative facts and rules automatically until none are left.”

Cut (!) — an operator that commits Prolog to the choices made so far in the current clause, pruning away backtracking points that would otherwise be tried, used to control search performance and behavior but notorious for making rules harder to reason about if overused. “Adding a cut here after the first matching case prevents Prolog from wasting time backtracking into alternatives we already know we don’t want — but be careful, since it also silently changes what solutions this predicate can produce.”

Predicate — Prolog’s fundamental unit of logic, a name plus a set of facts and/or rules defining a relation, roughly analogous to a function but describing a relationship that can be queried in multiple directions rather than computed one way. “This predicate isn’t ‘a function that computes an ancestor’ — it’s a relation, so you can query it forwards to find someone’s ancestors, or backwards to find their descendants, using the exact same predicate definition.”

Closed-world assumption — Prolog’s default reasoning rule that anything not provable from the known facts and rules is treated as false, rather than unknown, a foundational assumption that shapes how negation and missing data behave in the language. “The query failed not because we proved the fact false, but because of the closed-world assumption — Prolog couldn’t derive it from what it knows, so it treats it as false by default, which isn’t the same thing as actually disproving it.”

Common Phrases

• “Did that succeed because of unification, or are we confusing it with a plain equality check?”
• “Is backtracking finding this, or do we need to request the next solution explicitly?”
• “Is there a cut here, and do we understand exactly what search branches it’s pruning?”
• “Is this predicate meant to be queried in both directions, or only one?”
• “Is this failing because it’s actually false, or just unprovable under the closed-world assumption?”

Example Sentences

Explaining a query result: “The variable got bound to bob because the query unified successfully with the second fact in the database — if we ask for another solution, backtracking will retry against the third fact and potentially bind it to someone else.”

Justifying a cut in code review: “We added a cut right after confirming the input is valid, specifically to stop backtracking from retrying the validation clause on failure elsewhere in the rule — without it, an unrelated failure downstream could cause Prolog to re-attempt validation in a confusing way.”

Explaining a negation surprise: “This isn’t proving the claim false — under the closed-world assumption, Prolog is just reporting it can’t derive the claim from what it currently knows. If the fact is genuinely missing from the database, negation-as-failure will report it as false regardless.”

Professional Tips

• Describe unification as pattern-matching-with-binding, not assignment — this framing is what actually helps a teammate coming from imperative languages understand why the same variable can be bound differently across different backtracking attempts.
• Explain backtracking explicitly whenever a predicate can return multiple solutions — it’s Prolog’s built-in search strategy, not a loop the programmer wrote, and that distinction matters when debugging unexpected extra or missing solutions.
• Use a cut sparingly and document exactly which backtracking points it prunes — a cut changes what a predicate can prove, not just its performance, and an undocumented cut is one of the hardest things to safely refactor later.
• Design predicates to be genuinely relational where practical, queryable in more than one direction — that’s one of Prolog’s real strengths over imperative code, and losing it by hardcoding a single query direction wastes the language’s advantage.
• Be explicit when a result depends on the closed-world assumption, especially in domains like knowledge bases where “unproven” and “false” carry very different real-world meaning — conflating them is a common source of incorrect conclusions downstream.

Practice Exercise

1. Explain the difference between unification and ordinary variable assignment.
2. Describe what backtracking does when a Prolog query is asked for additional solutions.
3. Write a sentence explaining why an undocumented cut can make a predicate harder to safely refactor.