Toolchain composition

Consider compiling a function that adds two integers. The source gives the parameters names and spells out the addition. A code generator needs the parameter and result types, the operation to perform, and how the values reach that operation. It shouldn't need to know how the parser recognized the text.

From the function body to executable code

Library interprets the source and constructs its Type and Execution objects. Type describes the values involved; Execution describes the operations and value flow. The dialect's retained result, its Monograph, keeps those objects available to a consumer. Source policies provide the names and locations needed for inspection and diagnostics.

For our addition, the terminal follows the inputs into the addition operation and its result into the return. Renaming a parameter changes what an editor shows, but the code generator still needs that parameter's place in the input flow and its use in the addition. It can obtain those facts through the model's contracts without reading the name or inspecting a Library parser object.

Another dialect, or a loaded package with no authored source, can supply the same model contracts. The terminal can then consume those objects through the same interfaces. It still has to understand the operations it is given. An unfamiliar operation doesn't become compilable just because its arguments have the same layout as an operation the terminal already knows.

App selects a program entry and checks its callable requirements. That is a separate decision from interpreting the function's body. A helper function can be valid Library code without being a suitable entry for a particular program. Library, Shader and App may share parser fragments where their syntax matches; the consumers of their models don't acquire that syntax as a requirement.

Keeping the result after compilation

Once the terminal has emitted the addition, invoking it needs the executable code and any retained runtime state. It no longer needs the source tokens or the parser's objects. The terminal must copy the facts it needs and retain any implementation whose code the emitted result will call.

That last condition includes destruction. Releasing a provider while a result still needs one of its functions to clean up would leave a dangling call even if the addition itself had finished. The retention chapter follows how a consumer negotiates retained access and releases it.

An editor may keep the source model alive for a different reason: a user can still ask where the function came from or inspect a diagnostic. Puffer hosts those requests and retains the relevant source session. An emitted program's lifetime and an editor's source lifetime therefore need separate owners.

Acquiring the tools

The project also has to obtain the dialect and terminal that perform this work. A Build dialect describes how its tools are acquired and connected. The host and a module agree on an entry ABI before any negotiation can happen. Calling that entry establishes the interface through which the host requests the module's capabilities. Scoped results can negotiate Retain when they need to outlive their supplying call; host services have their own interfaces.

The Library parser can then do its job without deciding which binary to load or how long an emitted program should keep that binary available. Those decisions belong to the host and result owners that have the information to make them.