/swi-prolog-programmer

name: swi-prolog-programmer
description: SWI-Prolog-specific tooling, standards, and idioms. Use when working with SWI-Prolog code. Emphasizes relational thinking, steadfastness, DCGs, constraints, and mandatory testing with PlUnit.

SWI-Prolog Programmer

Expert-level SWI-Prolog development centers on **thinking in relations not procedures**, writing steadfast predicates that work in multiple directions, and embracing the declarative paradigm. The most critical mental shift: abandon "how" (procedural thinking) for "what" (declarative specifications).

**Related skills:**

• `logic-programmer` - Logic programming fundamentals (relations, unification, search)
• `software-engineer` - System design principles and architecture
• `test-driven-development` - Testing philosophy (PlUnit section below covers SWI-specific practices)

<logic_programming_fundamentals> **Core logic programming principles:**

• **Relations, not functions**: Predicates describe relationships that can work in multiple directions
• **Unification**: Two-way pattern matching that binds variables—not one-way assignment
• **Backtracking**: Systematic search through solution space—the "time machine" for exploring alternatives
• **Declarative reading**: Read `p(X, Y) :- q(X), r(Y)` as "X is related to Y when q(X) holds and r(Y) holds"

</logic_programming_fundamentals>

This skill focuses on SWI-Prolog-specific tools, idioms, and practices that distinguish veteran developers from beginners.

Version Targeting: Development Track Recommended

**Target version**: Latest development release (9.3.x series as of November 2025) **Current stable**: 9.2.9.1 (April 2025) **Current development**: 9.3.34 (November 2025)

**Aggressive adoption philosophy**: Most developers should use development releases even for production. The development track is released every 2-4 weeks, typically robust, provides latest features, and issues are resolved quickly. The stable track (even minor versions) only receives critical patches and is intended for conservative deployments requiring predictable installations.

SWI-Prolog tries to minimize breaking changes and stay close to the ISO standard. From the SWI-Prolog documentation:[^1] "We try to make as few as possible changes that break backward compatibility..."

[^1]: Jan Wielemaker. SWI-Prolog: Directions. https://www.swi-prolog.org/Directions.html

**Version history reference**: https://www.swi-prolog.org/ChangeLog

Respecting Third-Party Codebases

When contributing to existing Prolog projects or open-source:

• Respect existing coding style and conventions
• Don't introduce modern features to projects targeting older versions
• Follow the project's pack dependencies and version constraints
• Propose improvements through proper channels (issues, governance)
• "You're a guest—respect the house rules"

The aggressive adoption philosophy applies ONLY to codebases you own.

The Philosophical Foundation: Logic First, Procedure Second

<core_philosophy> SWI-Prolog's design philosophy prioritizes **knowledge-intensive interactive systems** where logical correctness and development experience trump raw performance. As Jan Wielemaker (creator, 35+ years experience) explains: "My primary motivation has always been to build stuff that works rather than stuff that allows writing an academic paper."

The critical insight: **Backtracking provides a time machine** for exploring computation paths. Any use of the dynamic database (assert/retract) breaks this superpower. The database is explicitly documented as **"a non-logical extension to Prolog"** that "destroys all these nice goodies" of logical search.

Veteran developers avoid assert/retract except when information must genuinely survive backtracking, which is rare. Instead: thread state through arguments. </core_philosophy>

When to Choose SWI-Prolog

Use SWI-Prolog when the problem involves:

• Relational data querying (tabular and graph-shaped data)
• Recursive structures (trees, nested data)
• Search with backtracking
• Constraint satisfaction problems
• Symbolic manipulation and term rewriting
• CPU-intensive server tasks with large shared datasets
• Soft real-time behavior with concurrent access
• Live programming (hot-patching without restart)

**Don't choose Prolog for**:

• Pure number crunching (use NumPy, Julia, Fortran)
• High-frequency trading latency requirements
• Problems where machine learning models excel
• Frontend user interfaces (though web backends work well)

The 2010 "Prolog Story" by Kyle Cordes documents a 90% cost reduction on a complex scheduling system—not from coding faster, but from **thinking more clearly**. The declarative approach forced better problem understanding.

Relational Thinking: The Core Mental Shift

The fundamental shift from imperative programming: **think in terms of two variables instead of one**. You cannot write `i = i + 1` in Prolog because no value equals itself plus one. Instead: `I #= I0 + 1` describes the **relation** between two different variables I0 and I.

As Markus Triska emphasizes: "The same variable cannot reflect two different states, old and new, at the same time."

Reading Code Declaratively

**Procedural reading** (wrong): "To find X such that Y holds, do the following steps..."

**Declarative reading** (correct): "X is related to Y when the following conditions hold..."

For `insert(Key, Tree, NewTree)`, read it as: "insert/3 shows how a key is related to a tree with and a tree without that key." The predicate describes a relationship, not a procedure.

The Power of Multidirectionality

Everything is a relation, so programs work in multiple directions. `append/3` with one definition provides four methods:

?- append([1,2], [3,4], ZS).     % List construction
ZS = [1,2,3,4].

?- append([1,2], YS, [1,2,3,4]). % List subtraction
YS = [3,4].

?- append(XS, YS, [1,2,3,4]).    % Generate all partitions
XS = [], YS = [1,2,3,4] ;
XS = [1], YS = [2,3,4] ;
XS = [1,