Erlang.CodeCompared.To/Prolog

Erlang prints with io:format/1 and the ~n directive for the newline. Prolog runs a program by executing its :- Goal. directives as soon as they are read; writeln/1 writes a term followed by a newline. Neither language has a main function — the directives (Prolog) or the top-level expressions (Erlang shell) simply run in order.

A small, pleasant coincidence: both languages use % for a line comment. Prolog also supports C-style /* block comments */, which Erlang does not.

Erlang's ~p ("pretty print") directive renders any term for humans, including nested tuples and lists. Prolog's write/1 plays the same role: it prints a compound term (here point(1, [2,3])) in standard Prolog notation, functor followed by parenthesized arguments — the direct analogue of an Erlang tagged tuple.

Erlang has no built-in fact database, so a Rubyist-turned-Erlang-programmer models "alice is a person" as list membership and iterates with lists:foreach/2. Prolog gives facts a first-class syntax: person(alice). declares something true directly, and forall/2 walks every solution of its first argument, running the second goal for each.

This is the single biggest head start an Erlang developer has over, say, a Rubyist or Elixir developer learning Prolog: lowercase identifiers are atoms in both languages, with no punctuation required (unlike Elixir's :ok). is_atom/1 in Erlang and atom/1 in Prolog even share the same name pattern.

The Erlang side needs an explicit list comprehension with a guard to filter down to Alice's rows — you are telling the machine how to search. The query likes(alice, Thing) asks Prolog "for what values of Thing is this true?" and the engine finds every match on its own — you describe what, not how.

Unlike the jump from Ruby or Python, an Erlang developer already has this rule memorized: a name starting with an uppercase letter (or underscore) is a variable; a name starting lowercase is an atom. Prolog enforces the identical convention for the identical reason — this is one of the few languages where the habit transfers with zero relearning.

This is the deepest structural kinship between the two languages: in Erlang, = is not assignment, it is unification — exactly what Prolog's = does. Both destructure a compound term and bind any unbound variables in one step, in a single pass over the shape. (Prolog has no built-in tuple syntax like Erlang's {X, Y} — an ordinary compound term such as point(X, Y) plays that role instead.)

When the shapes genuinely disagree, the languages diverge on how loud the failure is. In Erlang a failed match is a crash — it raises {badmatch, Value}, an exception that (absent a try) brings down the process. In Prolog a failed unification is just a normal, quiet false — the goal fails, and if the engine has other choices to try (see backtracking, below), it moves on to them instead of crashing anything.

Another exact match: the underscore _ means "match anything here, and do not bother binding a name" in both languages. Neither language warns about an unused _ the way it would warn about an unused named variable.

Unification recurses through nested structure in both languages — a tagged tuple wrapping a cons list unifies element by element, binding First and Rest in the same motion. The [Head | Tail] cons-cell syntax you already use daily in Erlang is, character for character, the same syntax Prolog uses.

A Prolog rule — head :- body. — reads "head is true if body is true," which is the same relationship an Erlang fun or top-level function expresses between its arguments and its guarded body. The difference is that a rule is a logical statement you can query in either direction, not merely a computation you call.

The comma means "and" in the body of a Prolog rule, exactly the way it separates the shell expressions you already write in Erlang — both read as a sequence that must all succeed. The difference is that in Prolog each comma-separated goal can itself backtrack into multiple solutions, not just evaluate once.

Erlang's orelse is a boolean short-circuit. Prolog usually expresses "or" not with the ; operator but with multiple clauses for the same predicate — is_weekend(sat). and is_weekend(sun). are two independent facts, and a query succeeds if either one matches. This is the more idiomatic Prolog shape, and it is also how it handles what Erlang would call overloaded function clauses.

Both languages pick a clause by matching the call against each clause head in order, top to bottom, falling through when a guard fails. The Erlang when N > 0 guard and the Prolog N > 0 body goal play the same role: both reject a structurally-matching clause when the extra condition is false, letting the next clause have a turn.

This is the sharpest arithmetic gotcha for anyone arriving from Erlang. Writing Total = 2 + 3 * 4 in Prolog does not compute 14 — it tries to unify Total with the unevaluated term 2+3*4, which only works if Total is already unbound (it would bind to the raw expression tree, not a number). is/2 is the operator that actually evaluates the right-hand side and unifies the result with the left.

Both languages separate integer and float division cleanly. Erlang spells integer division and remainder as the words div and rem; Tau Prolog spells them as the operators // and mod. In both, the plain / always produces a float, even when the operands divide evenly.

Erlang routes math functions through the math module (math:sqrt/1, math:pow/2). Prolog's arithmetic evaluator recognizes function-like terms — sqrt(16.0), pow(2, 10) — directly inside an is/2 expression, with no module prefix needed.

Erlang's lists:seq/2 eagerly builds the whole list [1,2,3,4,5]. Prolog's between/3 is a goal, not a list builder — on backtracking it generates one integer at a time. Wrapping it in findall/3 (see the "Collecting Solutions" section) is how you turn that generator into an ordinary list, the way lists:seq/2 hands you one immediately.

Another small but genuine comfort: both languages spell "less than or equal" as =<, not the <= that most C-descended languages use. Erlang and Prolog share this convention because both trace back to the same academic lineage — you will not need to retrain your fingers here.

This is a genuine trap, not just a naming difference. In Erlang, == is the loose comparison (1 == 1.0 is true) and =:= is the exact one (1 =:= 1.0 is false, different types). In Prolog the roles are inverted: =:= evaluates both sides arithmetically and compares the numbers (1 =:= 1.0 is true), while == compares the raw terms with no evaluation at all, so 1 == 1.0 is false — an integer and a float are simply different terms.

Prolog's \= asks "do these two terms fail to unify?" — it is the negation of =/2, checked without actually binding any variables. Erlang has no single operator for this because it has no unification-that-can-fail-and-be-asked-about outside of pattern matching itself; the closest equivalent is simply comparing two already-bound values with =/=.

Both languages define a total order across every term, not just numbers, so that lists:sort/1 (Erlang) and msort/2 (Prolog, "sort but keep duplicates") never raise a "these types are not comparable" error the way many languages would. The exact ordering rules differ in the details, but the guarantee — everything can be placed somewhere — is the same design decision.

The bracket-and-comma list syntax is exactly the same character for character. Both are singly-linked cons lists under the hood, so this is not just a syntactic coincidence — the underlying data structure and its performance characteristics (cheap to prepend, linear to index) match too.

This is the single most direct syntactic match in the whole comparison: [Head | Tail] means the same thing, is spelled the same way, and unifies the same way in both languages. Whatever recursive list-processing instincts you have built up writing Erlang carry over completely unchanged.

Even the name matches: lists:member/2 in Erlang and member/2 in Prolog. The deeper difference only shows up when the first argument is unbound — Erlang's version cannot do that, but Prolog's member(X, [1,2,3]) becomes a generator that produces X = 1, then X = 2, then X = 3 on backtracking.

Erlang's lists:append/2 takes two lists and returns their concatenation, the way you would expect from any language. Prolog's append/3 is a genuine relation between three lists, and — unlike Erlang's version — it works in reverse too: append(X, Y, [1,2,3]) backtracks through every way to split [1,2,3] into a prefix and a suffix.

Same idea, same name, one small shape difference: Erlang's lists:reverse/1 returns its result, while Prolog's reverse/2 takes the input list and an output variable to unify with the reversed list — the general Prolog pattern of "one extra argument for the answer" that shows up throughout the standard library.

The recursive structure is identical: a base case for the empty list, and a recursive case that peels off the head and recurses on the tail. The visible difference is where the answer lives — Erlang's recursive fun returns a value, while the Prolog rule threads the answer through an extra argument (Length) that gets unified once the recursion bottoms out.

Both versions decompose the list the same way. Note the Prolog rule must say Sum is Head + TailSum rather than Sum = Head + TailSum — a reminder from the arithmetic section that unification alone will not add two numbers together; only is/2 evaluates.

The classic recursive definition transfers almost line for line: a base case, a guard restricting the recursive case to positive numbers, and a recursive call whose result feeds the final multiplication. Erlang's when N > 0 guard and Prolog's bare N > 0 goal in the body serve the identical purpose.

Three clauses, two base cases, one recursive case — the shape is identical in both languages, right down to using multiple clauses (rather than a single one with an if) to separate the cases. This is a good example of how naturally Erlang's "many small clauses" style maps onto Prolog's "many small rules."

Erlang's "abc" is secretly [97, 98, 99], a plain list of integer code points — which is why ~w ("write the raw term") shows the numbers, while the everyday ~p/~s directives print it back as text. Prolog inherited the very same double-quoted-string-is-a-code-list convention from its own history; day-to-day Prolog code more often reaches for single-quoted atoms ('abc') to hold text, which is the closest thing to Erlang's binaries or Elixir's strings.

Erlang concatenates character lists with ++ and converts the final result back to an atom with list_to_atom/1 if an atom is what you actually want. Prolog's atom_concat/3 joins two atoms directly into a third — no intermediate list representation to manage.

Since "hello" is really a list in Erlang, the ordinary length/1 function measures it. Prolog's atoms are not lists, so text length needs its own predicate, atom_length/2, which unifies its second argument with the count.

Erlang's atom_to_list/1 and Prolog's atom_chars/2 both explode an atom into its individual characters — Erlang as a list of character codes, Prolog as a list of single-character atoms ([h,e,l,l,o]). Either direction, this is the escape hatch for treating "opaque" atom text as ordinary, inspectable list data.

This is the concept that reorganizes everything else. An Erlang function call has exactly one result (or it crashes) — lists:member/2 is a boolean test, full stop. A Prolog goal like member(X, [1,2,3]) is not a test at all; it is a generator that can be asked, again and again, for its next solution. findall/3 is one of several ways to say "give me every one of them, right now, as a list."

Erlang never needs a "cut" because its clause selection is already deterministic — one clause wins, end of story. Prolog's clause selection is not automatically final; without the ! ("cut") operator, backtracking into classify/2 later could still try the remaining clauses even after one already succeeded. The cut is Prolog reaching for the commitment that Erlang gives you for free.

Erlang's if expression and Prolog's ( Cond -> Then ; Else ) construct both commit to exactly one branch and never backtrack into the other — this is the one place Prolog voluntarily gives up its "try everything" nature to behave like an ordinary conditional, which is exactly the behavior an Erlang developer already expects by default.

once/1 wraps a goal so it commits to its first solution and discards the rest, behaving exactly like an ordinary Erlang function call for that one goal. Reach for it whenever you want a query to feel like calling a ordinary deterministic Erlang function rather than a search.

Erlang's not/1 is ordinary boolean negation over a true/false result. Prolog's \+ is subtler: it means "this goal has no solutions" — it works by attempting the goal and succeeding only if that attempt fails entirely, which is why it is called negation as failure rather than logical negation. In this example the two behave the same, but \+ can give surprising answers when its argument goal contains unbound variables, since it can never bind anything itself.

Both languages separate "print the term" from "print a newline" into two composable pieces. Erlang spells the newline as the ~n format directive; Prolog spells it as its own predicate, nl/0. writeln/1 (used throughout this cheatsheet) is simply write/1 followed by nl/0, bundled for convenience.

The naming coincidence continues right into formatted output: both languages call it format, both take a template string with placeholders and a list of values, and both use ~n for a newline. Erlang's ~p ("pretty print") corresponds most closely to Prolog's ~w ("write") here — Prolog's format/2 comes from the library(format) module rather than the core language, the way Erlang's comes from the io module.

Erlang's lists:foreach/2 and Prolog's forall/2 both walk a collection purely for side effects, discarding any "return value." forall(Condition, Action) reads naturally as "for every way Condition can be true, do Action" — here, "for every member of the list, print it."

Prolog's maplist/2 applies a goal to every element of a list, checking that the goal succeeds for each — the closest analogue to Erlang's lists:foreach/2. Where Erlang can build an anonymous fun inline, ordinary Prolog reaches for a small named predicate like print_square/1 to pass around as the goal — Tau Prolog does not implement the library(yall) lambda extension that some other Prolog systems offer.

Erlang's lists:map/2 returns a new list directly. Prolog's maplist/3 takes a two-argument relation (here double/2) and two lists, and holds them related element-by-element — the output list Result is unified in place rather than returned, the same "extra argument for the answer" shape you have already seen in reverse/2 and append/3.

Erlang can hold a fun in a variable and invoke it directly, or reach for apply/3 when the function and arguments are assembled dynamically. Prolog's call/N is the direct analogue of apply/3: it takes a goal (here the atom succ, naming the built-in successor predicate) and appends extra arguments to it before executing.

These are the same idea wearing different syntax. Erlang's [X || X <- Source, Condition] and Prolog's findall(X, (Generator, Condition), List) both say "collect every X produced by this generator that also satisfies this condition" — the Erlang generator clause and the Prolog goal argument play matching roles.

A list comprehension over nothing quietly produces [] in Erlang — an entirely unremarkable value. bagof/3 makes a different choice: when the generator has zero solutions, the whole goal fails rather than binding an empty list. That distinction — "no answers" versus "the answer is empty" — matters more in Prolog because failure is itself a control-flow signal, not just an edge case to check for.

Erlang's lists:usort/1 sorts a list and removes duplicates in one call. setof/3 gives Prolog the same guarantee — sorted, deduplicated results — but as a byproduct of collecting solutions rather than a standalone list function; like bagof/3, it fails outright if there are no solutions to collect.

This is the common Prolog idiom for what a Rubyist or Erlang developer would reach for a single map-then-reduce pipeline to do: findall/3 plays the role of map (collecting the transformed values), and sum_list/2 plays the role of reduce. Erlang's list comprehension plus lists:sum/1 does the equivalent work in a single expression.

Here the two paradigms visibly part ways. Erlang has no mutable storage at all — "adding a fact" means building a new list and passing it along; the old list is untouched and still exists. Prolog's assertz/1 genuinely mutates the running program's database in place, appending a new clause that every subsequent query can see. A predicate must be declared :- dynamic(person/1). before it can be asserted into, since ordinarily Prolog treats its clause database as fixed once loaded.

retract/1 is the inverse of assertz/1: it deletes a clause matching the given pattern from the live database. There is nothing resembling this in Erlang, on purpose — Erlang's entire fault-tolerance story (the "let it crash" philosophy) depends on data never silently changing out from under a running process.

This contrast gets at something fundamental. To keep mutable state, idiomatic Erlang spawns a process that recurses, carrying the current value as an argument to its own next invocation — state lives in the call stack of a loop, never in a shared variable. Prolog's assertz/retract pair offers a shortcut: a genuinely mutable global fact, updated directly. It is convenient, but it is also the one place Prolog's "pure logic" story quietly breaks down — much the way Erlang's process-based state is a deliberate workaround for its own purity, not an exception to it.

The Erlang version needs a nested list comprehension to join the "parent of a parent" relationship by hand. The Prolog grandparent/2 rule states the relationship once, declaratively, and Prolog handles the two-step join internally every time it is queried — this is the classic example that shows why Prolog is called a relational language.

Depth-first graph traversal is where Prolog's built-in backtracking earns its keep. The Erlang version has to write out the "try each outgoing edge, recurse, and stop at the first success" logic explicitly with lists:any/2. The Prolog version states two facts about what a path is (an empty path from a node to itself, or an edge followed by a shorter path) and lets backtracking supply the depth-first search for free.

Recursive minimum-finding is a good final gut check on how closely the two languages' recursive style aligns: a one-element base case, a recursive case that compares the head against the minimum of everything after it, and an ordinary conditional to pick the smaller. Line for line, this could almost be a mechanical translation.

An accumulator parameter that carries the "answer so far" is a habit every Erlang developer already has for writing tail-recursive, constant-stack-space functions. Prolog rewards the exact same habit for the exact same reason: threading an accumulator through the recursive calls keeps each call a proper tail call, which Tau Prolog (like Erlang's BEAM) can optimize.