How the toolchain is built
The compiler design documents, indexed where they live: the architecture, the type checker and the back end.
The toolchain is written in TorbScript and lives in compiler/, and it compiles itself from a seed. These are the
design documents of that work, in plain Markdown without front matter, linked here where they are instead of being
copied.
What belongs here#
Links to the compiler's own design documents, and nothing else. These documents are written for somebody changing the compiler, so they are long, they talk about milestones and gaps, and they change with the implementation rather than with the language.
What does not belong here: anything a user of the language needs. That is in the language reference
and in the toolchain pages. This section is marked skill: omit, because an agent writing
TorbScript has no use for the internals of the compiler that compiles it.
What holds every back end to one behaviour#
The language must be interpretable and compilable, and that is a design goal rather than a fact about a
code base - so there is a test that holds every back end to it. The conformance suite in
tests/conformance/ is one small program per behaviour, built and run, with the standard output, the standard error
and the exit code compared byte for byte against what is written down beside it, and the binary asked to free
everything it allocated. tests/conformance/README.md states that contract, says how a program is added, and names
what each program pins; nothing about what a program does is exempt from it. A rule of the language reference that
has observable run-time behaviour and no program in that suite is a rule nothing holds a back end to.
Pages#
- The page inventory - The historical work plan the documentation tree was written from, every page listed with its path, kind, scope and sources, grouped by the package a writer took.