160 lines
7.1 KiB
Markdown
160 lines
7.1 KiB
Markdown
# PBS Name Resolution Workshop 2
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the second focused discussion for `14. Name Resolution and Module Linking Specification.md` on reserved stdlib shells and host-owner resolution:
|
|
|
|
- builtin type shells,
|
|
- builtin constants,
|
|
- intrinsic member surfaces,
|
|
- and `declare host` owners imported from reserved stdlib modules.
|
|
|
|
## Why This Slice Second
|
|
|
|
This slice should come after Workshop 1 because it builds on already-closed rules for:
|
|
|
|
- module scope construction,
|
|
- ordinary import visibility,
|
|
- aliasing,
|
|
- and namespace-specific lookup order.
|
|
|
|
It also prepares the ground for later lowering by making the resolution contract explicit without prematurely defining artifact shape.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm already-settled ownership and stdlib-loading rules.
|
|
2. Close the visibility model for builtin and host shells.
|
|
3. Close lookup behavior for builtin types, builtin constants, and host owners.
|
|
4. Close member resolution on builtin receivers.
|
|
5. Close collision and ambiguity rules involving reserved shells.
|
|
6. Record deferred callable-linking issues for Workshop 3.
|
|
|
|
## Already-Settled Inputs To Reconfirm
|
|
|
|
The meeting should explicitly reaffirm:
|
|
|
|
- reserved stdlib project spaces include `@core:*` and `@sdk:*`,
|
|
- reserved stdlib spaces resolve only from the selected stdlib environment,
|
|
- source-visible builtin names resolve through imported builtin shell declarations,
|
|
- builtin intrinsic members are not imported as free functions,
|
|
- canonical builtin and host identities come from metadata rather than local alias spelling,
|
|
- and host-owner namespace remains distinct from type, value, and callable namespaces.
|
|
|
|
These are already fixed elsewhere and should not be reopened here.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. Visibility rules for builtin shells and host owners imported from reserved stdlib modules.
|
|
2. Lookup rules for builtin types, builtin constants, intrinsic members, and host owners.
|
|
3. Collision and ambiguity rules when reserved shells overlap with ordinary user-visible declarations.
|
|
4. Diagnostic ownership for reserved-shell resolution failures.
|
|
5. Deferred boundary between source resolution and later lowering.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Reserved Shells Enter Resolution As Ordinary Visible Declarations
|
|
|
|
Candidate direction:
|
|
|
|
- Imported builtin type shells become visible in the type namespace like other imported type declarations.
|
|
- Imported builtin constants become visible in the value namespace like other imported constants.
|
|
- Imported host owners become visible in the host-owner namespace like other imported host declarations.
|
|
- Reserved metadata changes canonical lowering identity, not the ordinary namespace they enter.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the source model uniform.
|
|
- It avoids a hidden parallel lookup system just for reserved stdlib surfaces.
|
|
- It matches the current specs that describe shells as imported declarations with metadata.
|
|
|
|
### 2. Builtin Simple Types Remain Separate From Imported Builtin Shells
|
|
|
|
Candidate direction:
|
|
|
|
- `int`, `float`, `bool`, and `str` remain always-available builtin simple types.
|
|
- Imported builtin shells such as `Vec2` or `Color` are ordinary visible type declarations and do not share special priority with builtin simple types.
|
|
- User-authored declarations still cannot reuse builtin simple type names.
|
|
|
|
Rationale:
|
|
|
|
- Separates the small predeclared core from stdlib-delivered builtin shells.
|
|
- Prevents `@core:*` imports from acting like implicit language keywords.
|
|
|
|
### 3. Intrinsic Members Resolve Through Receiver Type, Never Through Free Lookup
|
|
|
|
Candidate direction:
|
|
|
|
- Builtin intrinsic methods are resolved only during member lookup on a builtin-typed receiver.
|
|
- They do not appear in top-level callable lookup.
|
|
- They do not become visible through named import by method name.
|
|
- Alias changes to the builtin type affect only source spelling of the owner type, not intrinsic canonical identity.
|
|
|
|
Rationale:
|
|
|
|
- This matches the existing builtin and intrinsics spec.
|
|
- It prevents accidental confusion between member semantics and free functions.
|
|
|
|
### 4. Collision Policy For Reserved Shells
|
|
|
|
Candidate direction:
|
|
|
|
- Namespace collisions are handled by the same visibility rules used for ordinary declarations.
|
|
- A user-visible imported builtin type colliding with another visible type name is a deterministic conflict unless an already-closed shadowing rule says otherwise.
|
|
- A host owner colliding with a type or value name is not a conflict by itself because host-owner namespace is distinct.
|
|
- Duplicate canonical builtin identities in one resolved environment remain rejection cases even if local aliases differ.
|
|
|
|
Open point for discussion:
|
|
|
|
- whether conflicts involving reserved shells should be rejected more aggressively than ordinary import conflicts to preserve beginner clarity.
|
|
|
|
### 5. Diagnostic Ownership
|
|
|
|
Candidate direction:
|
|
|
|
- failure to resolve the reserved module remains manifest/import-resolution phase,
|
|
- import of a non-exported builtin or host shell remains linking or resolution-phase rejection,
|
|
- member lookup failure on a builtin receiver remains static-semantics or linking-phase depending on the final phase model,
|
|
- duplicate canonical builtin or host identities in one resolved environment remain deterministic compile-time rejection.
|
|
|
|
Rationale:
|
|
|
|
- This keeps module loading, visibility, and member resolution separate.
|
|
- It gives `11` a concrete discussion input later.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Should reserved shells be completely ordinary imported declarations at source level, or do any of them need special lookup priority?
|
|
2. Can an ordinary user declaration shadow an imported builtin shell, or should that always be rejected?
|
|
3. Is member lookup on builtin receivers purely a type-driven operation after receiver typing, or does name resolution need a separate reserved-shell step?
|
|
4. Should `@sdk:*` be allowed to expose builtin shells, or should builtin shells remain policy-preferred under `@core:*` only?
|
|
5. Which failures around canonical builtin identity belong to resolution, static semantics, or environment validation?
|
|
|
|
## Expected Outputs
|
|
|
|
This workshop should produce:
|
|
|
|
1. a decision record for reserved-shell visibility and lookup,
|
|
2. a decision record for collision policy involving builtin and host shells,
|
|
3. a concrete update plan for the reserved-shell sections of `14`,
|
|
4. and a deferred list for cross-module callable-set discussion in Workshop 3.
|
|
|
|
## Explicit Deferrals For Workshop 3
|
|
|
|
The following topics should be deferred unless unavoidable:
|
|
|
|
- imported callable-set merging across modules,
|
|
- overload resolution across ordinary and reserved callable surfaces,
|
|
- contract dispatch lookup,
|
|
- and whether linking is fully distinct from static semantics.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/5. Manifest, Stdlib, and SDK Resolution Specification.md`
|
|
- `docs/pbs/specs/6.1. Intrinsics and Builtin Types Specification.md`
|
|
- `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
|
|
- `docs/pbs/specs/18. Standard Library Surface Specification.md`
|
|
- `docs/pbs/agendas/14. Name Resolution and Module Linking Agenda.md`
|
|
- `docs/pbs/agendas/14.1. Name Resolution Workshop 1 - Scope, Lookup, and Imports.md`
|