Interop & Migration

Interop Boundaries

The canonical boundary between Topaz modules, generated artifacts, foreign tools, and conversion workflows.

Interop is a labeled producer/build boundary, not a second syntax inside Topaz. Canonical source keeps ordinary Topaz imports, expressions, types, patterns, and diagnostics. Foreign code may appear in an explicitly labeled host artifact or conversion example, never as evidence for Topaz grammar.

Contract and components

Topaz integration happens at module, generated-artifact, or conversion boundaries. The toolchain can generate Rust, Python, JavaScript, TypeScript, and WASM artifacts, but foreign-language tokens do not become valid Topaz syntax.

Workflow

Keep domain logic in checked Topaz modules. Cross a boundary by building a declared target, integrating its generated ABI, or converting source through a separate tool. Validate the Topaz side with check and reference execution; validate the host side with its own build/test gate; compare only the explicitly declared shared observables.

Current support

The current target builders, package tests, web ABI tests, Python differential fixtures, and Lena Code conversion snapshots exercise labeled boundaries. Primary failures remain Topaz diagnostics; host compiler output may be translated as secondary detail. Canonical docs scan Topaz fences for foreign and forbidden forms.

Boundaries and limitations

There is no import rust, inline Rust/Python/JavaScript expression, implicit ABI, or automatic ownership conversion. Side-effect imports and foreign module paths are not part of the language. External converters publish their own supported language pairs and release lifecycle.

Command reference

topaz check --root . src/main.tpz
topaz build --root . src/main.tpz --out-dir build