JaggerScript / docsProject documentation

Explanation

Motivation

Understand the design decisions, alternatives, and limits.

JaggerScript is less about inventing a production language and more about owning the whole language pipeline. It starts with source text, passes through a PEG grammar, normalizes into explicit program structures, and then executes through an interpreter whose state can be inspected and explained.

The separation pays for itself at failure boundaries. Grammar bugs produce malformed parse trees, compiler bugs produce incorrect normalized tokens, runtime bugs corrupt state, and interface bugs make the language hard to explore. The browser playground exposes those boundaries directly.

The right mental model is a small object-oriented language laboratory. The project is not competing with JavaScript, TypeScript, or Java. It is a controlled environment for showing how source text becomes executable behavior: how a grammar recognizes a program, how a compiler gives the parse tree a cleaner runtime shape, and how an interpreter manages variables, references, calls, and errors.

  • Primary goal: implement the full parser-to-runtime loop in TypeScript.
  • User goal: make language behavior explorable without local setup.
  • Design constraint: keep the runtime small enough that examples are easy to reason about.