prometeu-studio/docs/pbs/agendas/14.4. Name Resolution Workshop 4 - Linking Phase Boundary.md

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