Esoteric/legacy frontend probes — umbrella (new category: "esoteric")

• Type: feature — umbrella, new category esoteric-frontend-probe
• Status: backlog — category definition + candidate list, no code yet
• Owner: —
• Opened: 2026-07-05 (user decision — Sunday-afternoon brainstorm, made concrete)
• Priority: unranked — opportunistic, pick up when convenient

Core vs opportunistic (2026-07-05, user narrowing)

The valid, first-class test surface going forward is: Pascal, C, BASIC, and the Python dialect (Nil-Python). These are the frontends actually worth investing real effort in (Pascal = the product; C/BASIC/Nil-Python = proven, already-real cross-language-import demonstrations — see [[feature-pxx-basic]]). Rust stays parked at its current landed state (3/12, per the earlier "no need beyond proving the concept" decision) — not core, not being advanced further either.

Everything else in this umbrella (Ada, Algol, Fortran, COBOL, Zig, Erlang, LOLCODE, Whitespace) is explicitly opportunistic, not core. Pick one up only when it sounds fun/cheap in a given session; none of them compete for priority against real work. This also relaxes the "must be a compiled skeleton" expectation for anything in this outer ring — COBOL, for instance, is now fine as an interpreter instead of a frontend (see [[feature-esoteric-cobol]]'s "Scope relaxed further" note) purely as a pragmatic scope call, not because it needs that treatment the way Lisp does.

The category, stated plainly

A skeleton-only frontend (lexer + parser for a trivial subset, lowering straight onto the existing shared IR — no new IR primitives, no new backend work) for a language chosen for how differently shaped it is from anything PXX already parses, done specifically to shake bugs out of shared internals that Pascal/C/Nil-Python/Rust never think to exercise.

Restated even more precisely (2026-07-05, user correction): the real goal is not "compile language X" at all — it's proving AST/IR correctness. "Oh, and it compiles Fortran" is the funny side effect people notice, not the actual point. The point is that feeding a structurally-different program through the shared lexer→AST→IR→backend pipeline is a differential test of that pipeline's correctness — the specific source language is just a vehicle for generating a test case shaped unlike anything the existing test suite thinks to write. Keep this framing in mind when picking candidates: the question is "what shape of program would exercise the AST/IR in a way nothing else does," not "which language would be a cool demo" (that's [[feature-pxx-basic]]'s job, a different bucket entirely — see below).

The goal is explicitly NOT "make the language work." Inverted success criteria, stated up front so nobody chases scope later:

• Finds a bug in shared IR/codegen/ABI → the probe earned its keep. File the bug as its own ticket immediately (Track A), same as bug-selfhost-multifn-ifelse-miscompile came out of the Rust skeleton landing. This is the expected, valuable outcome.
• Compiles and runs correctly, first try, no bugs found → also fine, not a failure. It means the shared internals are more robust than assumed for that shape of program. Cheap confirmation, still worth having done it.
• Either way, stop at skeleton depth. Do not chase "compiles a real program in this language." That escalation is explicitly what happened with Rust (12 sub-tickets, "multi-week project") and what was rejected for Zig (comptime engine) and de-prioritized for Erlang (scheduler) — those stay parked as full-language efforts. A skeleton-only pass at any of them is back in scope under this category, precisely because the scope is capped.

Precedent (why this isn't a new idea, just a named one)

• The C frontend's whole multi-session bring-up repeatedly surfaced shared bugs unrelated to C itself.
• Landing the Rust skeleton (3/12 sub-tickets, [[feature-rust-frontend]]) surfaced bug-selfhost-multifn-ifelse-miscompile — a pre-existing shared bug, found because Rust's syntax shape hit a code path Pascal never does.
• examples/lisp/lispdemo.pas similarly proved the RTL robust enough to host a real interpreter — different axis (RTL capability, not frontend), same spirit: an unusual workload finds things a normal one doesn't.

Candidates (add more as they come up — this list is not exhaustive)

Explicit non-goals (the whole point of this category)

• Not a commitment to ship any of these as usable frontends.
• Not competing with Rust for "real second language" status — this category is bug-probing, Rust (parked at 3/12) is the one actual attempt at real-language usability.
• Not scheduled, not prioritized against each other — pick whichever sounds fun/cheap in a given session.

Log

• 2026-07-05 — filed per user decision: reframe exotic/joke-tier frontend ideas (Zig, Erlang, LOLCODE, Whitespace, plus new candidates Ada/Fortran/ COBOL) not as feature requests but as a deliberate, capped bug-finding technique. New ticket category "esoteric-frontend-probe" established.

Status sweep (2026-07-07, Track Z session — two days, six probes closed)

Aggregate verdict after seven shapes: the shared AST→IR→x86-64 pipeline has taken every grammar family thrown at it (Pascal-kin, C-kin, dynamic-ish, tokenless stack machine, implicit-typing, pattern-dispatch) without a single shared CODEGEN bug. What the probes actually surface, consistently, is (a) frontend-API sharp edges (ARG formatting sentinels, RSeqAppend head contract, unset-field traps) and (b) one real prescan bug. That is exactly the differential-testing value the category was created for; the marginal value of further grammar-shape diversity is now low. COBOL stays available as opportunistic; nothing else queued.

2026-08-07 — the probes have a SECOND value: shared-IR canaries

Recorded because this umbrella currently justifies the probes as opportunistic fun, and one of them just earned its keep on the gate.

Landing tyUCS4Char (feature-nilpy-text-string-kind) added a conversion hook in ir.inc that re-typed a concat node on any tkPlus with a string operand, with no guard that a code point was involved. It therefore fired for every string concat in every frontend.

Pascal, C, NilPy, Rust and Zig all passed. The failure was test_lolcode_skeleton.lol — SMOOSH (string concat) went into an infinite loop until it blew the stack.

That is not luck, and it is the argument for keeping these:

A probe frontend is a thin lowering onto the shared IR and nothing else. It has no frontend-specific machinery to absorb an IR-level mistake, so it fails where a mature frontend quietly copes.

The mature frontends have enough of their own typing and lowering to mask a change that is wrong in general but harmless in their particular shape. The skeleton has none, so it reports. That makes the probes worth keeping GREEN and worth keeping IN the full tier — their value is not the language, it is that they exercise the substrate from an angle nothing else does.

Consistent with devdocs/dev/ir-as-substrate.md: if the claim is that generality lives in the IR and frontends stay thin, then the thinnest frontends are the sharpest test of that claim.

(No change of priority intended — still opportunistic to ADD one. This is about not deleting or skipping the ones that exist.)