PCB — Pocket, Cup, Box — is a programming language built from scratch on the JVM, designed around a central idea that most languages ignore: that code can run in two directions at once. Every construct in PCB has a mirror image. Loops run forward or backward. Functions have inverses. Variables are declared from either end. The language is not a curiosity — it is the theoretical core of the entire THEVM architecture, and the reason the workbenches exist.

The interpreter is a tree-walk runtime built in Java 21, currently at over 10,000 lines. It includes a full scanner, parser, AST, environment scoping, a dynamic type system (HATTAG), vector and matrix math, file I/O, and integration hooks for the FlatLand game engine. The language and its runtime — trainingGround — have not yet fully separated. They are still one organism.

language design compiler JVM bidirectionality topology
active

Every keyword in PCB has a reverse. The forward form and its mirror are syntactically distinct but semantically paired — running a program backward is not the same as reversing its output, but a structurally different execution path through the same code.

PCB is organized around a strict container hierarchy. Every value belongs to one of six container types: box (pure data), cup (lexically scoped execution block), pkt/pocket (autonomous threaded actor), knt/knot (topological crossing point), xob (opaque reverse container), and puc (inverted execution container). Each layer adds behavioral contracts — a cup introduces a scoped environment; a pocket adds a daemon tick thread and a lifetime policy; a knot adds crossing bracket topology that a dedicated analyzer resolves into directed regions before execution begins.

The knot container is PCB's most structurally unusual construct. A knot forms when cup brackets and pocket brackets interleave — ({)} or {()} — rather than nest cleanly inside one another. A seven-pass static analyzer runs over the knot topology to identify SETUP, ENTRY, and UNWIND regions, compute edge ownership, and verify that no subgraph is unreachable. The runtime then drives oscillation between ENTRY and UNWIND until an exit condition is satisfied, producing iteration that emerges from graph structure rather than a dedicated loop construct.

Pockets and their reverse form, tkp, are autonomous execution units. Each runs a daemon tick thread that loops for as long as its lifetime condition holds. Pocket and tkp communicate through seam crossing — a mechanism that transfers an execution context from a pocket into a tkp and back, governed by one of twelve starvation policies including STRICT and IMMORTAL. Contention over the execution token is resolved with compare-and-swap; conflicts are logged to the system container BIN for later inspection.

The puc container — mirror of cup — activates invertedMode on entry. Inside a puc block, every arithmetic operator, comparison, aggregate, and string operation dispatches to its inverted counterpart: addition becomes subtraction, greater-than becomes less-than, SUM becomes PRODUCT, upper-case becomes lower-case. This is not a post-hoc transformation of results — the dispatch table itself is flipped. Puc containers nest: entering a puc inside a puc restores forward behavior, making invertedMode a toggleable execution layer rather than a one-way switch.

PCB includes a user-defined type and inference system. Types are declared with paired mirror tokens — the closing header is the character-reversed form of the opening header, enforced at runtime. Slot patterns inside a type describe what strings each position of the structured box may hold: a single optional character, one-or-more from a character class, an exact literal, or an exclusive-or set. The ?box c = value inference statement runs the full matcher pipeline over all registered types and wraps the result in a structured BoxInstance. In backward mode, the value string is reversed before matching, producing a structurally distinct parse of the same input.

PCB defines six system containers registered in the global environment under both their forward and reversed names. BIN and GAP are opaque containers for collecting runtime error records and unclaimed values. NON stands in for the null concept. LIMBO is the default inverted scope container. TRASH and VOID are sinks for dynamic error routing. At JVM shutdown, ContainerPersistence serializes each container's state to disk and reloads it on next startup, giving the runtime persistent ambient memory across sessions — the system containers carry forward whatever was deposited in them during the previous run.

The bidirectionality invariant is enforced at the environment level, not just syntactically. When any value is defined — a variable, a function, a type, or a system container — it is stored under both its forward name and its mirrored name as separate bindings. The resolver pass walks all declarations in forward order when execution is set to run forward and in reverse order when set to run backward, computing scope distances used for direct-index environment lookup at runtime. A program authored entirely in forward PCB can be executed backward by flipping a single flag, traversing the same AST in the opposite direction through the same environment.

A pocket's tick loop is powered by a flow connector embedded in its body: "(." for a forward-direction flow, ".)" for backward. The flow carries a chain queue of bootstrap tokens; on each tick, the pocket scans its body for a Flow object — extracted directly or parsed from one of these string patterns — and uses it to execute the next body item in sequence: a cup block, a knot, or a function. Each execution spends one token from the chain queue. When the queue empties, the pocket reaches heat death and the tick thread stops. A pocket with no flow in its body immediately heat-deaths — the flow connector is the literal power source for autonomous execution, not optional scaffolding.

forward forms
boxpure data container
cupcode execution container
pktecosystem container
kntorientation operator
printforward output statement
returnforward function return
funforward function
assertforward assertion
reverse forms
xobopaque reverse container
pucinverted execution container
tkpreverse ecosystem container
tnkreverse orientation operator
tnirpreverse output statement
nruterreverse function return
nufreverse function
tressareverse assertion
// forward cup block — identifier opens, reversed identifier closes main{ print.("Hello, World!") }niam // reverse execution — mirror identifier opens, forward identifier closes niam{ ("dlroW ,olleH").tnirp }main // variable declarations box x = 10 box y = 32 print.(x + y) // user-defined type declaration — closing header is the reversed opening header :NumberFmt&Arithmetic#PreciseNums[ @sg $_^X["","-"] gs@, @in $$_^["0","1","2","3","4","5","6","7","8","9"] ni@, @dp $"." pd@, @fr $$_^["0","1","2","3","4","5","6","7","8","9"] rf@ ]smuNesicerP#citemhtirA&tmFrebmuN: // ?box infers a structured box by matching the literal against registered types ?box num = 3.14 // num.sg="" num.in="3" num.dp="." num.fr="14" // backward form: 3.14 = num xob? (literal reversed before matching) // pocket — "(." flow connector powers the tick loop (forward direction) counter( "(." )retnuoc
01
Language Specification
The complete formal specification for PCB v0.0.1-SNAPSHOT. Covers philosophy and design intent, all 20 sections of the language — lexical rules, container types, variable declaration, operators, control flow, functions, I/O, the HATTAG dynamic type system, FlatLand integration, and 19 full program examples including Hello World, Fibonacci, FizzBuzz, and FlatLand scripts.
language spec · v0.0.1-SNAPSHOT
02
Technical State Report
A comprehensive reference document — not a summary — of every file in the PCB language stack as of April 2026. Full file tree, line counts, and per-file descriptions for the interpreter, scanner, token system, parser, and supporting infrastructure. Includes what is working, what is partially implemented, and what remains open.
technical report · 2026-04-30
03
Interactive Language Reference
A searchable, filterable, dark-theme reference card for every operator, keyword, and construct in PCB. Organized by category — forward/reverse forms, containers, control flow, I/O, math, FlatLand integration — with syntax, examples, and notes for each entry. Built to be kept open while writing PCB.
interactive reference · HTML
04
Legacy Specification
The archival specification for the original standalone PCB — the speciation point before it was pulled into trainingGround. Documents the bidirectional core, the five-stage pipeline, the eight-container type vocabulary, the forward/backward execution model, HATTAG, and the math sub-language — and states explicitly what the legacy does not yet have. Lets you see how the old code actually works and runs.
legacy spec · v0.0.1-SNAPSHOT
interpreter tree-walk · 10,274 lines · Java 21
scanner complete · 901 lines
parser Expr 3,026 ln · Stmt 1,503 ln
type system HATTAG dynamic · 32 runtime types
container types box / xob · cup / puc · pkt / tkp · knt / tnk
version 0.0.1-SNAPSHOT · active development