Research directions

The point of building several examples is to keep the architecture from becoming too comfortable with one of them. Image processing is useful, but it doesn't ask all the questions that a compiler, an editor or an engine bridge will ask. Each new application should expose another assumption while the contracts are still small enough to change.

There are a few directions that seem especially useful for that work. They share the same foundations, but each needs its own evidence before we can treat it as a working system.

Building tools from replaceable capabilities

The Source and model rework is separating dialect invocation from the Type and Execution objects a consumer uses. A Build dialect could then describe how to acquire the relevant tools and connect them for a project, rather than carry a private copy of every parser and terminal.

A useful first result would be a complete source-to-product path with a provider that can be replaced without changing the host. Package restoration and workspace replacement would add further lifetime and identity questions. The focused Source examples let us work through those problems in bounded steps before trying to make the entire toolchain self-hosting.

Self-hosting would itself be a replacement experiment. A TTX-authored provider would take the place of a bootstrap implementation behind the same contracts. Independent consumers would still need to agree on the output, and release, representation and artifact checks would still matter. Being able to describe ourselves doesn't make the description correct.

Following meaning across languages

An editor that can jump from a TTX reference into a C declaration and then into another language would put the ownership model to a different test. The language service needs identity, provenance and relationships from the system that knows what the declaration means. Reconstructing another frontend's private model would bring back the duplication the shared boundary is meant to reduce.

The awkward cases are also the interesting ones: macros, generated declarations, translation-unit context, incomplete edits and older source generations that are still borrowed. A useful cross-language editor has to preserve those distinctions while giving the user a coherent way to navigate them.

Puffer supplies the host in which to explore that direction. The universal multi-language surface remains a goal; the portable source and invocation work is providing the pieces we need to attempt it.

Extending the engine experiment

The Godot lab shows that several languages and execution systems can supply one bounded family of operations. Extending that to an engine compatibility layer would require agreements about object lifecycle, resources, events and much more of the engine's behavior.

A practical next step is a capability useful to projects on both sides, with an adapter that can be tested through the same consumer. That gives us a way to learn which parts of the host model can be shared and which need explicit policy. Trying to cover an entire engine first would make it much harder to see where a failure actually came from.

Learning from the development process

These integrations also keep the research question grounded. If explicit contracts reduce the context an implementer needs, a new provider should be able to join without a growing inventory of unrelated changes. If it can't, the failure should tell us which assumption escaped the interface.

I'm interested in recording that work more carefully: the context supplied, the changes required to integrate a replacement, the mistakes found by tests and the review needed to settle the boundary. The observations so far are encouraging, but the project and its tooling have evolved together. More concrete comparisons will be more useful than declaring one workflow universally better.

The lab, TTX foundation and development guide provide places to begin. The larger experiments give us reasons to keep testing how those pieces fit together.