Prototype Verification Demo

MysticIR
💩 Federation 🌊

v0.8.5

Different Surface, Same Underground Pipeline

💩 ScatLang
🌊 SeaIR
The Claim: Even when the surface symbols differ, once programs are parsed into the Core AST they become indistinguishable — same CEK trace, same error, same step.
scroll

What Is This, Actually

MysticIR Federation v0.8.5 is a prototype verification demo — not a formal proof, not a complete system, and emphatically not a production compiler. It targets three representative failure cases to confirm one specific claim.

💩 ScatLang and 🌊 SeaIR use entirely different surface symbols. After normalization through a shared parser, they produce the same Core AST. The CEK machine then runs the same trace and produces the same error signature — at the same step — regardless of which surface you came from.

The implementation uses a shared normalizing parser that accepts both ScatLang-style and SeaIR-style tokens and maps them to the same Core AST nodes. "Two independent frontends converging" would be an overstatement for v0.8.5. That's a v0.9 problem.

A Note on the Symbol Choice

💩 and 🌊 are surface markers, not semantic primitives. The underground pipeline is indifferent to surface notation. A, B, or any other symbol would work equally well. The choice of 💩 is intentionally arbitrary — and, as a separate academic document in this repository argues at considerable length, linguistically defensible. Poop terms are universal across all documented human languages. The IR merely reflects this universality.

The Underground Pipeline

Surface symbols enter from two directions. The shared normalizing parser collapses them into a single Core AST. From that point forward, execution is identical — same continuations, same environment, same error.

💩 ScatLang
surface parser
🌊 SeaIR
surface parser
Core AST
both normalize to the same tree
CEK Machine / Trace
same steps, same continuations
Error Federation
same signature, excluding frontend label

Frontend labels (💩ScatLang / 🌊SeaIR) are preserved in the trace records, so surface differences are captured as evidence while the underlying execution is identical.

Three Failure Cases, All Confirmed

The following results are actual output from running the Python script. For all three representative cases: ast_equal, trace_equal, error_equal = true and surface_diff = true.

Case Error Type ast_equal trace_equal error_equal surface_diff Steps
mod by zero
💩×3 ⊛ 💩₀ → division by zero
ScatError ✓ true ✓ true ✓ true ✓ true 12 == 12
unbound variable
reference to undefined variable "missing"
ScatError ✓ true ✓ true ✓ true ✓ true 2 == 2
step limit / infinite loop
0 ≠ succ(0) is always true → halted at step 40
StepLimitError ✓ true ✓ true ✓ true ✓ true 40 == 40

* Steps match because both surface symbols normalize to the same Core AST in these representative cases, causing the CEK machine to advance by the same number of steps.

What the Four Metrics Actually Mean

Four flags are recorded per case. All four being true constitutes confirmation of the Federation claim for that case.

✓ ast_equal

Structural equality check on the parsed Core AST: parse(scat_src) == parse(sea_src). True means both surface notations produce the identical internal tree before execution begins.

✓ trace_equal

The step-sequence records produced by the CEK machine, compared with frontend labels stripped. True means both followed the same execution path.

✓ error_equal

The state fingerprint at the moment of the error, compared with frontend labels stripped. True means both failed at the same point with the same signature.
⚠️ Current signature includes error_message text — fragile to wording changes. Future: separate stable error_code.

✓ surface_diff

When compared with frontend labels, a mismatch is expected. True means surface differences are preserved in the record — evidence that the notation differences are captured, not erased.

Underflow: A Deliberate Non-Error

💩∅

pred(💩₀) does not raise an error in MysticIR. It returns an Underflow value (💩∅), propagating silently as a value rather than halting execution.

Underflow is intentionally excluded from the Error Federation cases in v0.8.5. It is treated as a value, not an error event — therefore has no error signature to federate. Future versions may introduce a dedicated Underflow federation check if needed.