Name resolution

Platform spec node

Name resolution

Back to Program structure ◎ Open in platform map

Spec standingStandard

Owner

Piotr Mikstacki pmikstacki@cybernomad.it

Submitter

Piotr Mikstacki pmikstacki@cybernomad.it

Current document

ADRs

No architecture decision records under adr/ for this feature yet. Standard features must publish at least one ADR or keep a ## Decisions summary on the hub.

Articles

• Code style and naming Language-level naming and style conventions that affect readability and tooling consistency. article Proposed
• extend type Type extension syntax replacing impl blocks; public members only, full type scope access. article Standard Reviewed Wed May 20
• Modules and visibility File layout, `public`/`internal` boundaries, and how packages compose. The driver and package manager use the same module graph the typechecker sees. article Standard Reviewed Thu May 21
• Name resolution Scopes, imports, and shadowing tie syntax to symbols. Diagnostics for unresolved names must cite these rules verbatim. article Standard Reviewed Thu May 21

History

0 revisions (git unavailable at build; counts may be empty)

Open full history on GitHub

No commits recorded for this path.

Completeness

OKarea · 2 SpecSection(s) · 0 H2 heading(s)

Section id	Required	Found
scope	yes	yes
features	yes	yes

Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).

Related spec docs

• Area
  Program structure

  Parent area

• Domain
  Language meta

  Parent domain hub

• Domain
  Platform specification

  Cross-cutting index

• Domain
  Execution documentation

  Non-normative legacy execution bridge

Resolution flow

flowchart TD
  useDecl[use declaration]
  scope[Build scope chain]
  path[Qualify path segments]
  vis[Check visibility]
  bind[Bind to symbol]
  useDecl --> scope --> path --> vis --> bind
  bind --> value[Value symbol]
  bind --> type[Type symbol]
  bind --> mod[Module re-export]

Normative specification

Scope

Defines how identifiers and paths bind to program items across modules. Module shape is in Modules and visibility.

use declarations

• use Path; imports the final segment into the current scope.
• use Path as Alias; binds the resolved target to Alias.
• use before declaration in the same module must error (E1106) when forward reference is illegal.
• Unknown import paths must error (E1105); ambiguous imports must error (E1104).

Value and type paths

• Value paths resolve to functions, locals, constants, enum constructors, and contract namespaces.
• Type paths resolve to types, generics, and primitive names.
• Unresolved value E1101; unresolved type E1201; unknown module segment E1108.

Locals and shadowing

• Inner scopes may shadow outer locals; shadowing should warn (W1103).
• Duplicate definitions in the same scope must error (E1006, E1102).

Static rules

• Resolution must respect visibility from the importer’s module.
• Generic parameters shadow type names in signature scope only for the declaring signature.

Dynamic semantics

Resolution is compile-time; emitted metadata records stable qualifiedName strings for tooling.

Diagnostics

Import band E1104–E1108; resolve duplicates E1102. Registry: Diagnostic code registry.

Conformance

L1 resolver tests must pass for cross-module use and private item rejection.

Decisions

• D-LM-NAME-001 — Single resolver graph: Package driver and typechecker share one resolution snapshot per compilation.
• D-LM-NAME-002 — Contract namespaces: Contracts may appear as path prefixes for static methods without a separate use import of each method.
• D-LM-NAME-003 — Qualified names for tooling: Emitted qualifiedName strings must be stable across compiles for the same source snapshot.
• D-LM-NAME-004 — No implicit null imports: Resolution must not inject nullable or optional aliases.

Platform view

Scopes, imports, and shadowing tie syntax to symbols. Diagnostics for unresolved names must cite these rules verbatim.