145 lines
5.5 KiB
Markdown
145 lines
5.5 KiB
Markdown
# PBS Name Resolution Workshop 4
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the fourth focused discussion for `14. Name Resolution and Module Linking Specification.md` on phase ownership:
|
|
|
|
- what belongs to syntax,
|
|
- what belongs to static semantics,
|
|
- what belongs to module/linking,
|
|
- and whether PBS keeps linking as a distinct normative phase at all.
|
|
|
|
## Why This Slice Last
|
|
|
|
This slice should come last because it is mostly a boundary-setting exercise over decisions already made in Workshops 1 through 3.
|
|
|
|
Trying to close it earlier would force abstract phase arguments before the actual failure classes were concrete.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm the concrete failure categories identified in earlier workshops.
|
|
2. Group those failures by source-only, module-resolution, and cross-module visibility concerns.
|
|
3. Decide whether PBS names linking as a distinct normative phase.
|
|
4. Decide how this boundary feeds diagnostics, conformance, and frontend implementation claims.
|
|
5. Record any residual editorial cleanup for the spec integration pass.
|
|
|
|
## Failure Classes To Sort
|
|
|
|
This workshop should explicitly sort at least the following classes:
|
|
|
|
- malformed import syntax,
|
|
- unresolved module path,
|
|
- import of non-exported symbol,
|
|
- duplicate local declarations,
|
|
- ambiguous imported names,
|
|
- callable-set ambiguity across modules,
|
|
- builtin-receiver member lookup failure,
|
|
- duplicate canonical builtin or host identities in one resolved environment,
|
|
- and barrel entries that fail to resolve against module declarations.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. Whether linking is a distinct normative phase in PBS v1.
|
|
2. Ownership of the major failure classes already identified.
|
|
3. The minimum phase vocabulary needed by diagnostics and conformance.
|
|
4. The frontend implementation consequences of the chosen phase model.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Keep Linking As A Distinct Normative Phase
|
|
|
|
Candidate direction:
|
|
|
|
- syntax owns grammar and token-shape failures,
|
|
- static semantics owns declaration validity, typing, and callsite selection,
|
|
- linking owns cross-file and cross-module visible-set formation and barrel/import matching.
|
|
|
|
Rationale:
|
|
|
|
- This gives a clean home to failures that are neither purely syntactic nor ordinary local typing.
|
|
- It matches the practical compiler architecture implied by module loading and barrel visibility.
|
|
- It gives `11` and `13` a usable phase vocabulary.
|
|
|
|
Alternative to discuss:
|
|
|
|
- collapse linking into static semantics and treat "linking" only as an implementation detail.
|
|
|
|
### 2. Module-Visibility And Import Failures Belong To Linking
|
|
|
|
Candidate direction:
|
|
|
|
- unresolved exported-name lookup after the target module is loaded belongs to linking,
|
|
- ambiguous imported visible names belong to linking,
|
|
- callable-set ambiguity across modules belongs to linking,
|
|
- and unresolved barrel entries belong to linking or module-linking rather than to syntax.
|
|
|
|
Rationale:
|
|
|
|
- These failures arise from assembling visible declarations across files or modules, not from parsing isolated declarations.
|
|
|
|
### 3. Callsite Selection Remains Static Semantics
|
|
|
|
Candidate direction:
|
|
|
|
- once visible callable sets are formed, overload resolution at a callsite remains static semantics,
|
|
- member lookup driven by the known receiver type also remains static semantics unless it fails earlier due to unresolved imported shell visibility.
|
|
|
|
Rationale:
|
|
|
|
- This keeps typing and callable selection together.
|
|
- It prevents linking from becoming a catch-all bucket for any failure that mentions imports.
|
|
|
|
### 4. Diagnostics And Conformance Need Only A Small Stable Vocabulary
|
|
|
|
Candidate direction:
|
|
|
|
- the minimum normative phase vocabulary is:
|
|
syntax,
|
|
static semantics,
|
|
manifest/import resolution,
|
|
linking,
|
|
and host-binding/capability admission.
|
|
- tools may subdivide internally, but they should map back to that stable external vocabulary.
|
|
|
|
Rationale:
|
|
|
|
- This is enough for source-facing determinism without overfitting to one compiler pipeline.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Is there real value in naming linking as its own normative phase, or does that add conceptual weight without enough payoff?
|
|
2. Should unresolved barrel entries be considered module-internal static invalidity or linking invalidity?
|
|
3. Should builtin-receiver member lookup failure always stay in static semantics once receiver type is known?
|
|
4. Do diagnostics and conformance need the word `linking`, or only a broader `resolution` bucket?
|
|
5. Does the chosen phase model help or hinder future lowering and verifier specs?
|
|
|
|
## Expected Outputs
|
|
|
|
This workshop should produce:
|
|
|
|
1. a decision record for the PBS phase model around name resolution and linking,
|
|
2. a sorted matrix of failure classes by phase,
|
|
3. a concrete update plan for `14`,
|
|
4. and explicit follow-ups for `11` and `13`.
|
|
|
|
## Explicit Deferrals
|
|
|
|
The following topics should be deferred unless unavoidable:
|
|
|
|
- detailed diagnostic code design,
|
|
- artifact-level failure surfacing,
|
|
- verifier and loader phase internals,
|
|
- and optimizer or backend pipeline naming.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/11. Diagnostics Specification.md`
|
|
- `docs/pbs/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/specs/14. Name Resolution and Module Linking 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`
|
|
- `docs/pbs/agendas/14.2. Name Resolution Workshop 2 - Builtin Shells and Host Owners.md`
|
|
- `docs/pbs/agendas/14.3. Name Resolution Workshop 3 - Callable Sets and Cross-Module Linking.md`
|