⌗ AST Execution Badges

Understanding the colored dots in the AST viewer

When you run APL code and switch to the AST tab, you'll see colored dots on certain nodes. These execution badges show how the interpreter actually executed each part of your code — whether it was compiled to fast bytecode, optimized with tail calls, loop-fused, or replaced with a specialized fast path.

Badge Types

Compiled

The dfn (direct function { }) or sub-expression was compiled to bytecode and executed in a tight VM loop. This is the fastest execution path — all operations run as native VM instructions without touching the AST tree-walker. On mixed dfns, green dots appear on the highest fully-native subtrees.

f←{⍵+1}
f 42 ⍝ → 43 — { } gets a green ● compiled badge

TCO (Tail Call Optimization)

The dfn contains a recursive self-call (∇) in tail position. Instead of growing the call stack, the VM reuses the current stack frame — enabling deep recursion (e.g., countdown 1000000) without stack overflow.

countdown←{⍵=0:⍵ ⋄ ∇ ⍵-1}
countdown 10 ⍝ → 0 — { } gets ● compiled + ♻ TCO badges

Fused

A chain of element-wise operations was loop-fused into a single pass over the data. Instead of creating intermediate arrays for each operation, the fusion engine compiles the chain into a register machine that processes each element once. Shows the number of fused ops and register count.

1+(⍳1000)×2 ⍝ ⍳, ×2, +1 fused into one pass — no temp arrays

Specialized

At runtime, the interpreter recognized this dfn as a known pattern and replaced it with a hand-optimized fast path. For example, {≢⍵} used as the operand of Key (⌸) triggers a specialized tally-key implementation that's much faster than interpreting the dfn body for each group.

{≢⍵}⌸ 'banana' ⍝ → 3 1 2 1 — {≢⍵} is specialized by ⌸

Try It: All 4 Badges

Paste this into the interpreter and check the AST tab to see all badge types at once:

countdown←{⍵=0:⍵ ⋄ ∇ ⍵-1} ⍝ compiled + tco
countdown 10
{≢⍵}⌸ 'banana' ⍝ specialized
1+(⍳1000)×2 ⍝ fused

How It Works

When you run code, the interpreter records which dfns compiled successfully, which sub-expressions compiled natively, and which optimizations (fusion, specialization, TCO) were applied. The AST viewer then overlays this information as badges on the corresponding nodes.

Parse → AST → Execute code → Record optimizations → Annotate AST

All badge logic runs in Rust/WASM — the JavaScript frontend just renders the dots. Badges are computed immediately after execution to guarantee consistency between the runtime logs and the AST structure.

Reading the Dots

Dot	Position	Meaning
●	Top-right of `{ }` or sub-expression	Fully compiled to bytecode VM (native)
♻	Top-left of `{ }`	Tail-call optimized recursion
🔥	Bottom-right of expression	Element-wise chain was loop-fused
⚡	Top-right of `{ }`	Replaced by specialized fast path

💡 Green dot on { } = entire dfn compiled natively.
💡 Green dots on sub-expressions = those subtrees compiled to native bytecode.
💡 No dot on { } = dfn wasn't called during this execution.