Skip to content
Beskid Platform specification

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

Typed emitter and transforms - Design model

Platform spec article

Typed emitter and transforms - Design model

Spec standingStandard

Owner
Piotr Mikstacki
Submitter
Piotr Mikstacki

This article documents the design model for Typed emitter and transforms.

Emit applies only typed edits; language-meta forbids raw-text patching as the normative contract.

  • Compilation instance — implicit handle to the compilation under construction (Compiler Mod SDK / Beskid.Compiler.Compilation).
  • Syntax snapshot — immutable tree with stable node identities suitable for incremental keys.
  • Capability tokens — host-granted permissions for I/O, diagnostics, and emit operations during mod execution.
  • Mod SDK facades never bypass the host bridge for effects.
  • Generation logic in the reference compiler remains Rust-internal; Beskid sees only the generated Beskid.Compiler.* projection.
  • compiler/crates/beskid_analysis/src/syntax/items/ — patterns for well-formed item emission.
  • compiler/crates/beskid_codegen/ — downstream expectations after merge.

Typed emit must construct or mutate Program-level syntax nodes (or a documented multi-file aggregate feeding the same parser contract), not ad hoc HIR patches. Contributions must pass the same well-formedness checks as user-authored items before merge.

Ordering — Multiple contributors touching the same declaration identity produce a deterministic merge failure surfaced as structured diagnostics; the host must not leave a partially merged tree.

Handoff to lowering — After typed emit commits at syntax.generation and the host emits lower.ready, the merged syntax must be the sole input to lower_normalize_resolve_type_spanned / codegen lowering paths documented in Stage ordering and lowering; lowering must not begin until emit validation succeeds or emit is skipped for that generation round.