Diff — AdaLog

Before there was AdaLogic BASIC, I wrote **AdaLog** — and before there was a language to document, there was a workshop's worth of software quietly proving the thesis that would later drive ALB: that Ada is the right metal to build serious things on, and that programs should be able to *prove* what they do.

**AdaLog** is a Prolog-style logic engine I wrote in Ada 2012 with SPARK annotations, built as a utility-AI brain for games — a tiny reasoning machine that stores facts and rules, unifies them, and hands back provable answers one step at a time. It shipped with a small desktop suite I built around it at the same time: **TitaniumWM**, a SPARK-annotated tiling window manager for X11; **TitaniumRun**, a dmenu-style launcher; and **TitaniumBG**, a procedural animated-wallpaper renderer with its own state machines.[[cite: TitaniumComplete-0.2 source tree — AdaLog v0.9, TitaniumWM v2.2, TitaniumRun v0.4, TitaniumBG v0.7; the suite's bundled license is BSD-3-Clause, copyright 2026 Rocky L. Oliver.]]

None of it was ever released. All of it survives, source and binaries intact — a complete snapshot of my software workshop in the years before ALB.

The suite shares more than a name. Every program I wrote in that period is in Ada, every core module carries `pragma SPARK_Mode (On)`, every data structure is statically bounded — no heap, no malloc, no allocation after startup — and every piece was built to be *understood*, in the tradition of the hand-built desktops of the [[Year of the Linux Desktop|window-manager underground]].

The naming runs deeper than branding. AdaLog's own test program announces itself as `--- Titanium Engine: Utility AI Test ---` — the logic engine *was* the Titanium Engine. The suite and the language were one project with four faces: a brain (AdaLog), a desktop to run it on (TitaniumWM), a way to launch things (TitaniumRun), and something worth looking at while I thought (TitaniumBG).[[cite: AdaLog main.adb — the test harness prints "Titanium Engine: Utility AI Test", identifying the logic engine as the suite's namesake core.]]

The design target I had in mind was unusual and specific: **utility AI for games**. Most game AI scores options imperatively — an `if` ladder, a behavior tree, a hand-rolled scorer. I wanted to know: what if the scoring were *logical*? A rule only fires when its conditions are provably true against the world state; the engine doesn't just rank actions, it derives them. An orc doesn't get a "heal" score because a programmer wrote `if hp < 20 then heal` — it gets one because `health(orc, 15)` unified with `health(orc, H)`, bound `H = 15`, and the sub-goal `H < 20` was proven. The decision carries its own proof.

- **`Types`** — the value system. Every term is a `Term_ID` (a plain integer); atoms intern from 1,000,000 upward, variables from 2,000,000 upward, leaving small integers free to be literal numbers — the reason `health(orc, 15)` and `H < 20` can mix names and arithmetic in one fact. All bounds are constants I picked deliberately: 2,048 atoms, 64 variables, 1,024 facts, 256 rules, a 256-entry trail, up to 3 arguments per fact and 16 sub-goals per rule.[[cite: types.ads — Atom_Base 1_000_000, Var_Base 2_000_000, and the fixed pool sizes that bound the whole engine's memory.]]

[[File:adalog-orc.svg|right|340px|The orc's decision, drawn from my main.adb: facts and rules flow into the stepped solver, which enumerates every proven option; the caller takes the argmax.]]

Any competent programmer can write a Prolog in a weekend. What I cared about in AdaLog is that its unification isn't just *correct* — it's *contracted*:

Read the postcondition aloud: *if unification fails, the environment and trail pointer are provably unchanged.* A failed match can never leave half-written bindings behind to poison the next attempt — not because I reviewed the code, but because the contract states it and SPARK can prove it. That single line is the difference between a logic engine that probably works and one whose failure behavior is a theorem.[[cite: titanium_logic.ads — Unify's Post aspect: a failed unify restores Env and the trail pointer; backtracking via Trail_Array.]]

The same discipline runs through everything I built in the suite. Titanium_Database exposes `Abstract_State` rather than globals; TitaniumRun's launcher buffer carries `Pre`/`Post` contracts (`Insert_Char` requires room, `Backspace` requires content); TitaniumWM's `Layout` package is pure logic — `Tile_Windows` takes screen dimensions and computes positions, provably separated from the X11 event machinery that calls it. The whole suite is built on one pattern: **bounded static state, contract-checked behavior, pure logic at the core, impure I/O pushed to the edges.**

A normal Prolog runs to exhaustion. I made AdaLog's solver resumable instead: Initialize, then Step → Running/Found/Done, yielding after each solution. That's not a limitation — it's the design. A game loop can budget inference per frame, take one solution, render, and resume next tick. The logic engine cooperates with the frame rate instead of fighting it.

AdaLog's demo program is the whole pitch in 150 lines of Ada. It interns the atoms, asserts a two-fact world — the orc sees the player, and the orc has 15 hit points — asserts two scoring rules, then runs the query `score(orc, Action, Points).` one `Step` at a time.

**TitaniumWM** (v2.2) is the flagship of the trio — a hybrid tiling window manager I wrote for X11, in the tradition of dwm and its kin but in Ada 2012. Master-plus-stack tiling and full-screen monocle, twelve persistent workspaces, color-coded window decorations for focus state, everything driven from the Alt key — and, critically, a design split stated plainly in the code: the layout and state logic is SPARK-annotated while the X11 boundary is not (`pragma SPARK_Mode (Off)` sits honestly atop the event loop, because X event marshalling is a C world). The stated goal is "minimal memory footprint with no heap allocation after initialization" — a window manager you could, in principle, verify.[[cite: TitaniumWM README and src/main.adb, layout.ads — SPARK_Mode On for layout/state; the X11 event loop is explicitly non-SPARK by design.]]

**TitaniumRun** (v0.4) is the launcher — the same idea as dmenu or rofi: type, complete, run. Its `Completion` package keeps a fixed table of 8,192 candidate names (truncated at 16 characters), returns at most 5 matches, and annotates every buffer operation with contracts. A program whose entire job is to fuzzy-match a string carries formal proof annotations about that string's length. That is the Titanium sensibility in miniature — and honestly, it's the part of the suite I'm most amused by.[[cite: TitaniumRun src/completion.ads, launcher_core.ads — Max_Candidates 8192, Max_Results 5, Pre/Post contracts on every buffer operation.]]

**TitaniumBG** (v0.7) is the surprise — an *animated* procedural wallpaper engine. Each scene is a tagged object with `Render` and `Update` methods, drawn into a bounded pixel buffer sized for up to 4K displays. The `desert_mountain` scene keeps a coyote at fixed scene coordinates (220, 210) and runs a buzzard through a four-state machine — `Circling → Descending → Feasting → Ascending` — on its own RNG seed and frame counter. Jungle river, plasma fields, a snowy village round out the set, drawn by a hand-rolled VGPU layer with its own ditherer and fonts. It's a desktop wallpaper that thinks.[[cite: TitaniumBG src/desert_mountain.ads, titanium_bg.ads — Buzzard_State machine, Wallpaper_Item tagged type, Pixel_Array bounded to 3840×2160.]]

To the rest of the world, building a logic engine, a window manager, and a wallpaper renderer in Ada is eccentric. To me it was the obvious choice — Ada is the language industry already trusts where failure isn't an option: avionics, rail, medical. SPARK is its proof subset, where contracts aren't comments but checkable claims. The bet behind the whole suite — and behind ALB after it — is that the same discipline belongs on the desktop, in the game loop, in the wallpaper, and eventually in the language toolchain itself.

AdaLog answers a question ALB's existence raises: why would anyone build a language? Because I'd already built one. The Titanium suite is the evidence — I wrote a Prolog engine when I needed game AI, a window manager when I wanted a desktop, a renderer when I wanted wallpaper. ALB is what happened when the same instinct aimed at the language itself.

The pattern carried over intact: static bounds instead of dynamic allocation, contracts instead of conventions, a compiler pipeline of small honest units — lexer, parser, logic, solver, the same nouns that now structure `albt.adb`'s tokenizer, parser, and emitters. AdaLog v0.9 was the rehearsal. AdaLogic BASIC is the production.

- This article is written in the first person — the software is the author's own, and the account is primary testimony rather than secondhand reporting.

- All technical claims trace to the TitaniumComplete-0.2 source tree itself — the suite is unreleased, so the code *is* the documentation. Version numbers are the bundled ones: AdaLog v0.9, TitaniumWM v2.2, TitaniumRun v0.4, TitaniumBG v0.7.

- Screenshots of the running TitaniumWM and TitaniumBG are forthcoming and will join the schematic figures in this article.

[[Category:AdaLogic BASIC]]

[[Category:Languages]]

[[Category:Programming]]