16. Interop and ABI

Level: beginner · Reading time: 13 min · Prerequisite: book/chapters/15-pipeline.html · Track: essential · Maturity: reviewed · Last review: 2026-05-09

Prerequisites: book/chapters/15-pipeline.html. See also: book/chapters/15-pipeline.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

Interop pages become dangerous when they normalize foreign boundaries instead of isolating them.

Red Thread (Single Project)

One narrow bridge surface translates between a Vitte-facing contract and an external-facing edge.

For what

This chapter helps the reader keep foreign or runtime boundaries explicit and narrow.

What you are going to do

You will inspect one bridge-like helper, then compare it to a misuse where the foreign edge leaks too far.

Coherent example

space demo/interop

unsafe proc call_host(code: int) -> int {
  if code < 0 { give 11 }
  give 0
}

Global explanation

Interop is not a convenience feature. It is a coupling boundary. The chapter should therefore explain why the foreign edge exists, how narrow it is, and how the rest of the program stays readable around it.

Invalid case

proc leaked_host(code: int) -> int {
  unsafe
  give code
}

This invalid case is intentionally small. It exists to isolate the contract failure that the chapter is trying to teach.

Common pitfalls

• Letting foreign assumptions spread through ordinary code.
• Skipping the boundary rationale and teaching raw syntax only.
• Using interop examples with no visible safe wrapper around them.

Short exercise

Wrap the interop call in a safer procedure that exposes a domain-oriented result instead of a raw foreign detail.

Summary in 5 points

1. Interop is a narrow boundary, not a default tool.
2. The chapter should expose coupling cost clearly.
3. Unsafe or foreign edges must stay visible.
4. Safe wrappers are part of the teaching model.
5. The goal is controlled integration, not hidden magic.