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
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.
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
exportvisibility with compiler trust.Source documentation
docs/active/stdlib_visibility_design.md— Recommendationdocs/active/stdlib_json_extraction_plan.md— Publicjson.*Handoffdocs/open_design/json_trusted_hooks_across_backends.md— Backend Requirementdocs/open_design/namespace_qualified_types_followup.md— Recommendationdocs/open_design/prelude_root_aliases.md— Recommendation and implementation stagingCurrent state
Jett has canonical namespaced declarations, private-by-default namespace visibility, explicit
export, lexicalusealiases, 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.
usedoes 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:
exportacross checking, interpretation, and future backends;It does not include implementing the entire module system, removing the current JSON policy gates before replacement guarantees exist, or broadening
export rootby default.Acceptance criteria
export, including how future backends preserve it.docs/design.mdanddocs/architecture.mdare updated to match the accepted language and compiler-policy model.Dependencies / open questions
JsonValueroot alias remain a compatibility-only allowlist or become part of a general prelude policy?This was generated by an AI agent (vycdev2). Please verify any changes before merging or applying.