Project directions

Building tools from replaceable capabilities

Replacing a dialect behind an unchanged host would test the separation between source interpretation and the Type and Execution models. The test would feed its result to a terminal, release discovery, and run the emitted program. Running it after release checks whether the result retained the state and code it needs.

Self-hosting adds another substitution: a TTX-authored provider takes the place of a bootstrap implementation. Its output needs checking through an independent consumer, including the representation and artifact checks used for the original. Agreement between the compiler and its own reader could otherwise hide a shared mistake.

Following meaning across languages

Consider following a TTX reference to a C declaration in an editor hosted by Puffer. The language service would ask the supplying frontend for the declaration's identity and source location. A macro or generated declaration may need more provenance than a file and line number, and a C declaration may depend on its translation-unit context.

Editing that source while an older result is still displayed would test the lifetime rules. The old result must retain its source generation, while a new request sees the replacement. Incomplete edits should remain navigable without turning an unsettled answer into a permanent absence.

Extending the engine experiment

An image operation is a small place to try an engine bridge. A Unity-facing consumer could request convolution from a Godot-backed adapter and compare the result with the existing image oracle. Releasing the original engine resource before reading the result would also test whether the adapter retained what it needed.

That experiment would cover image behavior and lifetime. Scene callbacks, event ordering, physics and threading would each require further contracts, as the substitution chapter explains.