Haskell's own course, just completed, spent sixteen chapters showing what "declarative" means when a language evaluates pure expressions to values. This course is the direct counterpoint: Prolog is also called declarative, but it means something genuinely different — describing relations that hold true, then asking the system to search for what satisfies them.

SWI-Prolog & the ?- REPL

SWI-Prolog is the standard modern implementation; swipl launches its interactive top-level. Similar in spirit to GHCi's own REPL — but every query here ends in a period, and the answers look nothing like a function's return value.

Facts — The Most Basic Unit

A genuinely different starting point from haskell1-1's own function-first orientation. There's no function being defined here at all — parent(tom, bob). is a fact, a statement simply asserted as true and added permanently to Prolog's own database. A Prolog program begins as a collection of facts about relations, not a sequence of function definitions.

Querying — Asking Questions of the Database

Here's this chapter's central reveal: a query isn't "calling a function" — it's asking, literally, "is this true?" or "for what X is this true?" parent(tom, X) genuinely asks Prolog to search its own database and find a value for X that makes the statement hold. This is a fundamentally different orientation from every other language on this site, where calling something always means "run this code and give me back a value."

Multiple Facts, Multiple Answers

With two matching facts in the database, parent(tom, X) genuinely has two possible answers — typing ; at the prompt asks Prolog for the next one. A first, gentle preview of Chapter 4's own full backtracking treatment, without naming the underlying machinery yet.

No main, No Entry Point — A Genuinely Different Program Shape

Stated plainly: there's no equivalent to haskell1-1's own main :: IO () at this level at all. A Prolog "program" is its database of facts and rules — "running" it means posing queries against that database, not executing a fixed starting point. There's no single place execution begins the way there always was in every language covered before this one.

Coding Challenges

prolog1-1 covered plain facts. This chapter adds rules — facts that depend on other goals being true — and gets precise about what actually organizes a Prolog program.

Rules — Facts That Depend on Other Facts

:- reads as "if." This rule says: grandparent(X, Z) is true if parent(X, Y) is true and parent(Y, Z) is true. The comma is logical AND — a genuinely different reading from every other language's own comma usage on this site.

The Body Is Just More Goals

A rule's body is itself a sequence of goals, each one potentially a plain fact or another rule. Rules can call other rules — genuinely comparable in spirit to function composition — but querying a rule works exactly the same way as querying a plain fact. The caller can't tell the difference from outside at all, a real, clean uniformity.

Predicates — The Real Unit of Organization

A predicate is a name plus arity (argument count) — parent/2. Every fact and rule sharing that same name and argument count together define one predicate. Genuinely comparable to how haskell1-4's own multiple function equations (sumList's base case and recursive case) together define one function — Prolog's version has this exact "multiple clauses, one definition" shape.

Recursive Rules — Building ancestor from parent

A real, genuinely recursive rule — base case plus recursive case, directly comparable to haskell1-4's own base-case/recursive-case shape for functions. The difference: this recursively defines a relation, not a function computing a single value.

Variables Are Scoped to a Single Clause

A real, easy-to-miss detail: a variable's name is scoped to a single clause only. Reusing X across two clauses of the same predicate does not link them — each clause gets its own completely independent set of variables, a real departure from ordinary lexical scoping in every other language covered so far.

Anonymous Variables — The Underscore

_ means "some value exists here, but I don't care what it is, and I won't bind it to a name." Directly comparable to haskell1-4's and haskell1-7's own discard pattern — a real, genuine syntactic and conceptual convergence between the two languages.

Coding Challenges

This is the chapter this whole course's own framing has been pointing toward. Unification looks, at a glance, like Haskell's pattern matching — both languages check whether a value has a certain shape and bind pieces of it to names. They are not the same mechanism, and the difference is real and structural.

What Unification Actually Does

Two terms unify if they can be made identical by substituting values for variables. X = 5 doesn't assign — it attempts to unify the unbound variable X with 5, which succeeds by binding X. 5 = 5 succeeds trivially (already identical); 5 = 6 fails outright — no substitution could ever make them equal.

Unifying Two Variables

When both sides are unbound, unification succeeds by linking them — if either is later bound to something concrete, the other becomes bound too. Genuinely different from every other language's own assignment, which always gives a value to a variable, never links two unknowns to each other.

Unifying Compound Terms — Structural Matching

Genuinely comparable to Haskell's own pattern matching on a constructor's shape — same functor name, same arity required, corresponding arguments unified pairwise.

The Central Contrast — Bidirectional vs. One-Directional

Here's the explicit, promised reveal: haskell1-7's own pattern matching always matches a known, already-computed value against a pattern — the pattern side can never "reach backwards" and solve for an unknown piece of the value being matched. Prolog's unification has no such asymmetry at all. There is no "the pattern" and "the value" in Prolog — only two terms being made equal, in either order, or with variables on both sides at once. Genuinely bidirectional, where Haskell's matching is genuinely one-directional.

A Concrete Demonstration — Solving What Pattern Matching Never Could

X is bound to g(Z) — a compound term that itself still contains an unbound variable — and later, Z gets unified with 3, retroactively completing X's own value. Values can be partially known and progressively refined. Haskell's pattern matching has no equivalent to this "partially solved, filled in later" behavior at all — matching there is all-or-nothing against an already-complete value.

The Unification Algorithm, Briefly

A real, honest technical note: the full unification algorithm includes an "occurs check" to detect a variable unifying with a term that contains itself — but SWI-Prolog, by default, does not perform this check, for performance reasons. Worth naming plainly rather than glossing over, matching this site's established pattern of honest technical caveats.

Coding Challenges

prolog1-1 showed ; producing a second answer without explaining how. Here's the real machinery underneath — and a genuinely rich comparison to a mechanism Haskell only offers as one specific, opt-in monad.

The Search Tree — How Prolog Actually Finds Answers

When a goal has multiple clauses that could match, Prolog tries the first one. If that path later leads to failure, Prolog automatically backtracks to try the next alternative. A useful mental model: a tree of choices, explored via depth-first search, backing up and trying a different branch whenever the current one dead-ends.

Conjunction and the Order Goals Are Tried

Goals are tried left to right — and if a later goal fails, Prolog backtracks into an earlier goal to try its next alternative there, not just moving on independently. Genuinely sequential dependency, matching haskell2-3's own >>= chaining in spirit (each step can depend on what came before) — but Prolog explores every alternative automatically, with no explicit lambda written per step.

; for Explicit Alternatives (Disjunction)

; is logical OR, usable directly inside a rule body — not just something the top-level REPL shows between answers. Worth naming explicitly: the top-level's own ; prompt and rule-body ; are genuinely the same underlying mechanism, just triggered in two different places.

Comparison to Haskell's Own [] Monad

A genuinely rich comparison: haskell2-3's own list monad represents nondeterminism — >>= on [] explores every combination of possible results, conceptually similar in spirit to Prolog's backtracking search. But Prolog's version is baked into the entire language's execution model by default — every goal call is implicitly a potential source of backtracking, not something wrapped in one specific type a programmer opts into. The same distinction haskell1-5 drew between Java's opt-in Stream laziness and Haskell's own language-wide laziness, appearing again here in a new context: Haskell's [] monad is one specific tool; Prolog's backtracking is the language's own default way of running everything.

A Practical Example — Generating Combinations

Real, useful combinatorial work — no explicit nested loop was written anywhere. Backtracking generates every pairing automatically, on demand.

Backtracking Can Be Expensive — A Real, Honest Performance Note

Searching a large tree with many choice points can be genuinely slow if the search space isn't constrained somehow. Chapter 8's own ! (cut) is one real tool for controlling this — foreshadowed here without going deep into it yet.

Coding Challenges

Two languages, built from entirely different premises, looking at lists and landing on almost the same notation. This chapter is that convergence, made explicit — plus a real Prolog-specific twist unification adds on top.

List Syntax — [], [H|T]

An empty list, or a head consed onto a tail — [1,2,3] is genuinely sugar for the fully nested cons form.

The Genuine Convergence with Haskell's (x:xs)

Here's this chapter's central comparison: haskell1-4's own (x:xs) splits a list into head x and tail xs using :. Prolog's [H|T] does exactly the same conceptual split using |. Both languages, working from the identical foundational insight — a list is either empty, or a head attached to a tail — arrived at visually similar notation completely independently, not through shared ancestry. Worth naming as a genuine convergence rather than a coincidence.

Multiple Elements Before the Tail

A real, practical convenience — splitting off more than one leading element in a single pattern.

Building Lists via Unification, Not Construction

A real Prolog-specific angle, tying directly back to prolog1-3's own central theme: since = is unification, not assignment, [H|T] can be used to take apart a known list, or to build a new one from known pieces — the identical syntax, in either direction, because unification never cared which side supplied the concrete values.

Common List Predicates — length/2, append/3, member/2

A genuinely great illustration of bidirectionality applied to lists: the exact same append/3 definition computes a concatenation forward, or — run "backwards" — searches for every possible way to split a list into two pieces, via backtracking. One predicate definition, two genuinely different uses.

Coding Challenges

Prolog also has no for, no while. Same surface fact as haskell1-4's own Haskell. The reason underneath is genuinely different, and worth being precise about.

No Traditional Loops in Prolog Either

Here's the real distinction: Haskell has no loops because it has no mutation for a loop counter to increment — haskell1-3 made that structural argument directly. Prolog is different: it genuinely can have mutable-feeling state, via the dynamic database (assert/retract, covered in full in Course 2). The absence of loops here isn't because mutation is impossible — it's because Prolog's entire computational model is the relational/search model. Recursion isn't a workaround for a missing loop construct; it's the natural, direct way to define a relation across a list structure, which a loop simply isn't shaped to express at all.

Length — A Genuinely Recursive Relation

Base case plus recursive case, structurally parallel to haskell1-4's own shape — but this defines a relation between a list and its length, rather than "computing and returning" a length the way a Haskell function would.

Sum — Threading an Accumulator

Genuinely comparable to a tail-recursive accumulator pattern in any language — but here it's built directly into how the relation threads a running value through recursive calls via an extra argument, not a special "accumulator" language feature.

Recursion Explores the Search Tree Too

A real, honest connecting thread back to prolog1-4: a recursive predicate call is itself just another goal — meaning every recursive call is potentially a fresh source of backtracking, not merely "a loop iteration." A genuinely different mental model from imperative-style recursion in every other language, where a call is understood as deterministic unless explicitly made otherwise.

A Concrete Example — Filtering

The exact same conceptual operation as haskell1-4's own filter — keep only elements satisfying a condition — expressed as a genuinely different kind of construct: three clauses defining a relation, rather than a single higher-order function call.

Coding Challenges

prolog1-3's tip-box promised this chapter directly. Three operators, all doing something with equality-shaped names, all genuinely different — and mixing them up is the single most common early Prolog mistake.

= — Unification, Not Arithmetic

X = 2 + 3 does not compute anything. It unifies X with the actual compound term 2+3 — functor +, two arguments — never evaluated as arithmetic at all. Genuinely surprising for anyone assuming = means "compute and assign."

is — Forcing Arithmetic Evaluation

is evaluates its right side as a genuine arithmetic expression, then unifies the left side with the resulting number. A real asymmetry unlike unification's own flexibility: is's right side must already resolve to a number — an unbound variable there is a real error, not something is can work around the way unification handles unbound variables freely.

== — Structural Equality, No Unification Side Effects

== checks whether two terms are already identical, with zero unification side effects — nothing gets bound. Two different unbound variables aren't identical, even though = on the same two would succeed by linking them.

The Three Side by Side

Comparison Operators for Numbers

=:=, =\=, <, >, =<, >= all force arithmetic evaluation on both sides — the same spirit as is, genuinely different from =='s own pure structural comparison. A second, concrete demonstration of the exact same underlying distinction.

Coding Challenges

Fundamentals closes with Prolog's most debated single character. Cut is real, useful, and genuinely controversial within the Prolog community itself — this chapter doesn't pick a side, it explains exactly what's actually being traded.

What Cut Actually Does

!, when reached during execution, commits to every choice made so far in the current clause — permanently pruning any remaining backtracking alternatives, both for goals earlier in the same clause and for the choice of which other clause to try for the predicate itself.

A Concrete Example — Cutting Off Alternatives

Without the cut, asking for further solutions via ; after the correct answer could backtrack into the first clause despite 3 >= 5 already having failed for those bindings in one call, or produce unintended additional results in more complex predicates. The cut commits: once X >= Y succeeds, this is the answer — no exploring further.

Green Cuts vs. Red Cuts — An Honest Distinction

A real, well-known distinction worth naming explicitly. A green cut only improves efficiency — it prunes alternatives that would have failed anyway, changing nothing about the program's actual logical meaning. A red cut genuinely changes the set of solutions a predicate produces compared to removing it. Red cuts are the controversial ones — a predicate relying on one can no longer be read as pure logic alone; understanding which kind you've written requires understanding your own program's behavior with and without the cut present.

The Real Cost to Declarative Purity

Stated plainly, matching this whole course's own established pattern (the same honesty haskell2-6 applied to monad transformer stacks): a predicate using cut can no longer be freely reordered, and its logical reading now depends on Prolog's own specific left-to-right, depth-first execution order. A real, genuine departure from pure declarative logic, where a set of facts and rules should mean the same thing regardless of execution strategy. Cut ties correctness to execution order — a real, controversial tradeoff, not a free efficiency win.

Cut in Rule Bodies — A Common, Practical Pattern

The "if-then-else"-shaped idiom — genuinely practical, very common real-world Prolog code, not just a toy example. Each cut commits to that branch once its own condition succeeds, preventing later clauses from ever being tried for that same call.

Negation as Failure, Previewed

A brief, honest forward-pointer: Course 2's own \+ (negation as failure) is commonly implemented internally using exactly this cut-based pattern — worth naming now, without going deep, since Course 2 covers \+ properly.

Coding Challenges