prometeu-studio/docs/pbs/agendas/14.2. Name Resolution Workshop 2 - Builtin Shells and Host Owners.md

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