Understand the TypeRB compilers

You do not need to know everything first

Compiler code can look like a wall of unfamiliar words: token, syntax tree, resolver, type checker, intermediate representation, ABI. This guide introduces each word beside the TypeRB responsibility that gives it meaning.

Files and helper names will move. The guide therefore separates durable concepts, responsibility-based change journeys, short versioned code clinics, versioned code maps, and executable evidence. Read how to follow a changing codebase before trying to memorize a repository tree.

Learn the shared ideas

Build a small mental model of how source text becomes a running program.

Run one trace

See a real source file, compiler boundary, generated artifact, and result.

Read a short code clinic

Follow the same input through a few highlighted implementation decisions.

Use the map as reference

Open pinned source links only when you need a responsibility’s current address.

Two compilers, two paths

The reference compiler is written in Go. It checks one portable TypeRB language and can generate Go, Ruby, or TypeScript.

The Native compiler is an experimental compiler written in TypeRB. It checks a deliberately smaller language subset and produces native executables through Native MIR and QBE.

Both paths begin with the same question: what does this TypeRB program mean? They answer the later question—how should it run?—in different ways.

Keep a place to return to

• Use Make your first compiler change for the complete route from setup to a reviewable pull request.
• Use the workflow and test matrix to choose a fast focused check and the broader checks required before review.
• Use the contributor glossary when two compiler or evidence terms sound almost alike.
• Use Test a compiler change before coupling a new test to a private helper.
• Follow a reference diagnostic backward when you want a short route to semantic ownership.
• Learn to read Native evidence before interpreting a gate, seed, fixed point, or performance result.