Skip to content

design: define module imports and trusted stdlib origins #3

Description

@vycdev2

Summary

Define the module/import/prelude model and a backend-neutral representation of trusted stdlib origin so namespaced library declarations can be loaded, resolved, and authorized without conflating export visibility with compiler trust.

Source documentation

Current state

Jett has canonical namespaced declarations, private-by-default namespace visibility, explicit export, lexical use aliases, and driver-managed stdlib loading. The interpreter marks compiler-shipped functions trusted from reserved stdlib file IDs, and the four policy-bearing public JSON calls require trusted private hooks and wrappers.

What is still missing is the documented real module/import registry and dependency model. use does not import from such a registry, stdlib fragments are prepended in lexical path order, and trusted-origin guarantees have not been designed for future backends. As a result, compiler-owned JSON policy gates cannot yet be handed off to ordinary stdlib mechanisms safely.

Scope

This is a design-decision issue. It includes:

  • specifying canonical module discovery, dependency ordering, import/alias lookup, and prelude/root-export behavior;
  • specifying how compiler-shipped origin is represented and preserved independently of source-level export across checking, interpretation, and future backends;
  • defining a staged migration path for current stdlib loading and the policy-bearing public JSON bridges;
  • identifying focused conformance and spoofing tests required by that design.

It does not include implementing the entire module system, removing the current JSON policy gates before replacement guarantees exist, or broadening export root by default.

Acceptance criteria

  • A concrete module/import/prelude design decision is recorded, including discovery, ordering, aliases, visibility, and root-export policy.
  • Trusted stdlib provenance is specified as compiler-owned metadata separate from source export, including how future backends preserve it.
  • The design defines staged implementation units and tests for namespace collisions, untrusted name spoofing, import ordering, and JSON bridge handoff.
  • docs/design.md and docs/architecture.md are updated to match the accepted language and compiler-policy model.
  • The originating planning docs remain in place and reflect the issue's final status.

Dependencies / open questions

  • Should the narrow JsonValue root alias remain a compatibility-only allowlist or become part of a general prelude policy?
  • Which compiler phase owns canonical module identity and trusted-origin metadata before HIR/MIR and native backends exist?

This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions