// STRYKELANG — ENGINEERING REPORT

>_EXECUTIVE SUMMARY

strykelang is a single-binary Perl 5 implementation written in Rust. The interpreter compiles source to a 351-opcode bytecode, runs it on a register+stack hybrid VM, and JITs hot blocks through Cranelift to native code. Parallel primitives (pmap, pgrep, pflat_map, pfor) ride on rayon work-stealing. Synchronization spans the full stack: mysync / oursync for lockless atomic shared state, mutex() + semaphore($n) with parking_lot::Mutex + Condvar for explicit blocking critical sections / bounded concurrency, and POSIX flock($fh, OP) for cross-process advisory file locks. Pipe-forward (|>) and the thread macro (~>) extend Perl 5 syntax with Clojure / Racket / Scala threading semantics. Editor tooling rides on the same binary — stryke --lsp for Language Server Protocol, stryke --dap for Debug Adapter Protocol (line breakpoints, step over/into/out, recursive variable drill-down) — consumed by a first-class JetBrains plugin under editors/intellij/. 350k production Rust lines + 227k .stk lines + 10,453 builtins (11,229 keys in %all) + 1,349 Rosetta tasks + 173 Exercism solutions — matching surface coverage that took dynamic languages with multi-decade histories.

~SCALE & POSITION

Quantitative comparison against the established dynamic-language reference set. Source-LOC figures are approximate (counted from each project's public source tree, excluding vendored deps and external bindings). Stryke is single-author single-language-binary; the others span tens to hundreds of contributors over multi-decade histories.

#Builtin Count vs Other Bareword-Fn Languages

Stryke's 10,453 primary builtins exceed every other language whose stdlib is exposed as bareword fns — including Wolfram Language, the only prior holder of "world's largest builtin set" branding. APL/J/K/q have hundreds of primitives, but as glyphs (+/, ⌽, ~:) rather than barewords; R has ~2k+, but split across library()'d packages rather than always-loaded. Stryke is the only bareword-fn language past the 10k threshold.

Wolfram is the only language that has marketed builtin count as a competitive metric. Stryke's 10,453 clears Wolfram v14.1's stated count by ~3,260 and clears the high end of a plausible v14.3 band (~7,300) by ~3,135. Bareword-fn rivalry past the 10k mark: stryke is alone in the category.

Density: builtins per byte of binary

~175× denser than Wolfram per builtin/byte. The single-binary qualifier matters: no kernel boot, no paclet manager, no licensing daemon, no GUI runtime, no library() resolution — ~/.cargo/bin/s is one statically-linked Rust binary that cold-starts in <10 ms with 11,139 callable spellings (10,453 builtins + 686 aliases) plus 90 keywords reflected in %all (11,229 keys total). Caveat: bytes-per-builtin is partly apples-to-oranges — Wolfram's GBs include datasets, image / video native code, and the Wolfram Notebook GUI. The defensible composite claim is "11,139 callable names + 44 MB single binary + sub-10 ms cold start", which no other language clears simultaneously.

#SUBSYSTEM BREAKDOWN

Source partitioned by role. Builtins dominate at 31.8% — the language ships with 10,453 primaries in %b (11,229 keys in %all = 10,453 primaries + 686 aliases + 90 keywords) spanning string / array / hash / regex / I/O / process / OO / format / pack / crypto / codec / parallel / sync (mutex / semaphore / flock) / HTTP / database / network / AI / web / math / physics / chemistry / biology / signal / finance domains. Core pipeline (lexer→parser→compiler→VM→JIT) is ~17.6% of the Rust slice.

$TOP 20 FILES BY SIZE

The 20 largest source files account for 54.2% of the codebase (Rust under strykelang/ + tests/ + tooling slice). Builtins is by far the largest single file: every Perl 5 core function plus stryke extensions (HTTP, JSON, parallel, codec, OO, AI, web) lives here, dispatched through a single match table generated at build time.

@EXECUTION PIPELINE

Source flows through 5 stages. Tier 1 is the bytecode VM; tier 2 is Cranelift JIT'd native code for hot blocks. Both tiers share the same NaN-boxed value representation, so deoptimization (JIT→VM fallback on type miss) is a frame-pointer swap, not a re-marshal.

  Source (.stk / .pl / -e '...')
       │
       ▼
  ┌─────────────┐     ┌─────────────┐     ┌──────────────┐
  │  lexer.rs   │────▶│  parser.rs  │────▶│ compiler.rs  │
  │  (4,187)    │     │  (22,790)   │     │  (9,894)     │
  │  Tokenizer  │     │  AST node   │     │  351 opcodes │
  │  heredocs   │     │  variants   │     │  const fold  │
  │  regex lit  │     │  prec climb │     │  reg alloc   │
  │  q/qq/qw/qr │     │  whitelist  │     │  peephole    │
  └─────────────┘     └─────────────┘     └──────┬───────┘
                                                  │
                              ┌────────────────────┤
                              │                    │
                              ▼                    ▼
                     ┌──────────────┐     ┌──────────────┐
                     │    vm.rs     │     │   jit.rs     │
                     │   (11,648)   │     │  (5,174)     │
                     │  Bytecode VM │     │  Cranelift   │
                     │  reg + stack │     │  block JIT   │
                     │  hot detect  │────▶│  native code │
                     │  exc unwind  │◀────│  deopt stubs │
                     └──────┬───────┘     └──────────────┘
                            │
                            ▼
                  ┌───────────────────┐
                  │   builtins.rs     │
                  │   (43,786)        │
                  │   10,453 builtins  │
                  │   11,229 spellings │
                  │   + extended      │
                  │   (12,643)        │
                  │   + math_wolfram* │
                  │   (58,672 / 82 f) │
                  └─────────┬─────────┘
                            │
           ┌────────────────┼─────────────────┐
           │                │                 │
    ┌──────▼──────┐  ┌──────▼──────┐  ┌──────▼──────┐
    │  value.rs   │  │  scope.rs   │  │  parallel   │
    │  (5,050)    │  │  (3,270)    │  │  (4,803)    │
    │  NaN-boxed  │  │  my/local/  │  │  pmap/pgrep │
    │  StrykeValue  │  │  oursync    │  │  rayon work │
    └─────────────┘  └─────────────┘  └─────────────┘

&BUILTIN INVENTORY

Builtins are partitioned at build time by build.rs, which scans strykelang/parser.rs and strykelang/builtins.rs to generate CORE_CATEGORY_MAP (Perl 5 core), EXT_CATEGORY_MAP (stryke extensions), and ALL_CATEGORY_MAP (every callable spelling, primaries plus aliases); language keywords (if, my, sub, fn, …) live in a separate hand-curated KEYWORDS table. The reflection tables back the runtime %b / %k / %all / %pc / %e / %a / %d / %c / %p hashes (plus their %stryke::* long-form aliases) under the disjoint-union invariant %all = %a + %b + %k. At runtime stryke also exposes %parameters (zsh-style live binding view) and per-package stashes (%main::, %Foo::) refreshed lazily on read.

118 hot builtins are reachable through dedicated BuiltinId opcodes in bytecode.rs — the rest go through the generic dispatch table. The 686-alias overhead exists so canonical Perl spellings (localtime), abbreviations (tj), and stryke-style snake_case alternatives all coexist without disambiguation. Disjoint union: keys %a + keys %b + keys %k == keys %all.

// CATEGORIES

// STRING COORDINATES — BYTES VS CODEPOINTS

Stryke runs string code in two coordinate systems. Perl 5 builtins stay byte-indexed for binary-protocol and .pm-source compat. Stryke extensions are codepoint-indexed so search positions and slice bounds line up. Never auto-converted — mixing across systems silently misaligns on any non-ASCII content.

For "hello ─ world" (15 bytes, 13 codepoints): length = 15, len = 13, index $s, "world" = 9, cindex $s, "world" = 7.

!VM & BYTECODE

351 opcodes grouped into 27 functional categories. The VM is a register+stack hybrid: frame-local scalar slots provide O(1) access for hot variables (no string lookup), while the operand stack handles temporaries and complex expressions. Frame-local slots win on tight loops; the stack wins on irregular control flow.

// OPCODE CATEGORIES

~CRANELIFT JIT

Tier-2 compiler. The VM detects hot blocks (loops with stable types) and hands them to jit.rs, which lowers bytecode to Cranelift IR, then to native machine code. NaN-boxed StrykeValue stays the same shape across tiers, so a JIT→VM deopt is frame-pointer-swap-and-go — no value re-boxing.

%PARALLEL RUNTIME

11 modules listed below sum to 2,968 lines; the full parallel subsystem (helpers + stress.rs + orchestration) is 4,803 lines in the roll-up table. Every parallel builtin is a streaming iterator under the hood: pmap, pgrep, and pflat_map produce lazy results that flow into pipe-forward chains without materializing intermediate vectors. builtins_sync.rs adds blocking mutex + counting semaphore primitives backed by parking_lot::Mutex + Condvar for cases where lockless mysync isn't enough (compound multi-statement critical sections, bounded-concurrency throttles).

^PARSER & AST

Recursive-descent parser with operator-precedence climbing. 196 parse_* functions cover the full Perl 5 grammar plus stryke extensions: pipe-forward (|>), thread macro (~>), match patterns, class blocks, named arguments, retry / backoff syntax, defer, try/catch/finally.

*TESTS & PARITY

Two complementary suites. Unit + integration tests are #[test] functions in Rust; parity tests are .pl scripts that must produce byte-identical output between system perl and stryke. CI runs both on every push.

// TEST SURFACES

>REPL & INTERACTIVE SHELL

The s binary doubles as a Perl 5 interpreter and a Unix shell. Reedline-backed REPL with persistent history, tab-completion against the full 22,071-name corpus, ANSI-colored cyberpunk banner, and 80+ shell-style coreutils builtins (ls, cat, grep, cd, pushd, whoami, curl_get, tree) that are in-process Rust function calls, not subprocess spawns. No fork, no PATH walk, no exec — every result is a stryke value ready for the next pipeline stage.

// STARTUP BANNER

The banner is computed at REPL launch from live reflection — never hard-coded. Numbers shift as builtins land or get removed.

// SHELL-LIKE BUILTINS (NO FORK, NO EXEC)

// DESIGN DECISIONS

// COMPARISON

Nushell is the only direct architectural peer (in-process pipelines, structured values) but it's an order of magnitude smaller in builtin surface and slower to cold-start. No other REPL passes the combination of shell-grade pipelines + 10k+ builtin surface + sub-10 ms launch.

:EDITOR TOOLING — LSP / DAP / JETBRAINS

The same stryke binary that runs scripts also serves Language Server Protocol and Debug Adapter Protocol. No separate stryke-lsp or stryke-dap artifacts — editors point their LSP/DAP clients at stryke --lsp / stryke --dap and get hover docs, completion, semantic tokens, breakpoints, step over/into/out, and recursive variable drill-down. The TTY debugger (stryke -d) and the DAP server share a single Debugger state machine.

// LSP SERVER — stryke --lsp

• Hover over any of 4,255 documented builtins → category + signature + description from the live %stryke::descriptions / %stryke::categories hashes
• Completion with the full builtin set (every spelling in %all — 11,229 keys including 686 aliases and 90 keywords)
• Semantic tokens — keywords, builtins, sigils, types, regex flags get distinct categories so themes can paint them independently
• Signature help on function-call cursor; code actions for common diagnostics
• Go-to-definition for user subs, classes, structs, enums

// DAP DEBUGGER — stryke --dap [HOST:PORT]

Standard Debug Adapter Protocol over stdio or TCP. Same Debugger state machine the TTY REPL (stryke -d) uses — breakpoints, step modes, scope inspection, call-stack tracking, all shared. Two front-ends on one core.

Supported DAP requests: initialize, setBreakpoints (line), setFunctionBreakpoints, setExceptionBreakpoints, configurationDone, launch, threads, stackTrace, scopes, variables, continue, next, stepIn, stepOut, pause, evaluate, terminate, disconnect. Events: initialized, stopped, output, process, thread, exited, terminated.

// JETBRAINS PLUGIN — editors/intellij/

First-class JVM plugin built on IntelliJ Platform Gradle Plugin 2.16.0, Kotlin 2.0.21, JDK 17. Supports the entire JetBrains paid lineup: RustRover, IDEA Ultimate, GoLand, PyCharm Pro, WebStorm, RubyMine, PhpStorm, CLion, Rider, DataGrip, Aqua. Community editions are not supported — LSP API is paid-only on the JetBrains side.

• .stk file association with 44-slot color scheme. Keywords, sigils, builtins, types, regex bodies/flags, heredocs, sub names, class fields, all paintable independently.
• LSP client consuming stryke --lsp — semantic tokens, completion, hover, signature help, code actions.
• DAP debugger consuming stryke --dap HOST:PORT (TCP transport keeps OSProcessHandler stdout/stderr free for the program's own p/print output).
• Reflection tool window — 9 tabs on the live %stryke::* hashes (≈11k builtin names, 686 aliases, 90 keywords, 318 categories, 4,386 descriptions, 8,937 primaries, 10,267 extensions, 186 perl_compats). Left single-click opens the docs popup; right-click inserts at cursor.
• Run configurations + gutter run icons — execute, debug, or profile any .stk file with one click.

// OTHER EDITORS

.EXAMPLES & SOLVED PROBLEMS

Stryke ships with the largest curated corpus of cross-language exemplars in any single-author Perl 5 work-alike: 2,960 .stk programs under examples/ totaling 227,213 LOC. All 1,349 Rosetta Code tasks in list.txt are solved (100%) — every test compiles and runs against the current build, so any builtin regression surfaces as a failing test before it reaches the parity suite.

// CORPUS BREAKDOWN

The Rosetta corpus is a complete cross-language reference port at 1,349/1,349 (100%). The full test runner (s test examples/project/t examples/rosetta/t) executes 1,751 .stk test files and 12,211 assert_eq / assert_ok checks across those trees; any builtin drift surfaces as a failing test before it reaches the parity suite. New Rosetta tasks land as fast as the canonical site adds them.

+DEPENDENCIES

135 direct dependencies, 680 transitive crates in Cargo.lock. Every dep is audited against the “will this still build cleanly in 2030” bar — foundational crates (serde, regex, libc, nix) over fashionable ones.

;PUBLIC API SURFACE

strykelang ships as both a binary (stryke, st, s) and an embeddable Rust crate (stryke on docs.rs). The public surface stays small relative to internals — embedders get the high-level entry points; the rest is implementation.

?KEY DESIGN DECISIONS

Why stryke looks the way it does. Each call-out below is a decision the implementation could have gone either way on, with the rationale for the path taken.