Brummel
b586999e81
First iteration of the kernel-extension-mechanics milestone. Ships
the type-scoped `<TypeName>.<member>` resolution path as the
canonical form for type-associated operations, narrows the
`BareCrossModuleTypeRef` / `BadCrossModuleTypeRef` diagnostics from
"bare = strictly local" to "bare = in-scope by any path", migrates
12 std-library example fixtures, and introduces a workspace-wide
normalisation pre-pass `prepare_workspace_for_check` shared between
`check_workspace` and `monomorphise_workspace`.
Architectural discovery during implementation: the plan covered the
`Term::Var` dot-qualified resolver layer plus the workspace
validator's bare-name acceptance, but the migration of bare-form
fixtures exposed five sites where bare vs. qualified type-names
needed symmetric treatment — `Term::Ctor` resolution, `Type::Con`
well-formedness, mono's poly-free-fn name/constraint-count
enumeration, codegen's `lookup_ctor_by_type` bare-name path, and
the upstream desugar-then-qualify composition. Rather than
scattering TypeDef-first ladders across each site, the implementer
centralised the work into one pre-pass that walks every consumer
module's `Type::Con.name` and `Term::Ctor.type_name`, rewriting
bare cross-module references to their qualified `<home>.<Type>`
form. This is symmetric to the pre-existing `qualify_local_types`
(owner-side); the new pre-pass is the consumer-side mirror.
Downstream passes see qualified Types regardless of authoring form.
The TypeDef-first ladder still lives in `synth`'s `Term::Var` arm
because `<TypeName>.<member>` is term-position-only — `Maybe.from_maybe`
is a Var, not a Type expression, and the pre-pass does not rewrite
Var names.
Alternatives considered:
(a) Add TypeDef-first ladder at every resolution site separately
(the plan's implicit assumption). Rejected: O(N) extension
sites, each carrying the same workspace-walking logic; the
pre-pass version is O(1) — one pass, every downstream consumer
benefits.
(b) BLOCKED + spec re-brainstorm. Rejected: the architecture
extension is consistent with prep.1's thesis (bare type-name
resolves to the workspace-wide TypeDef) and forward-compatible
with prep.2 (Term::New.type_name falls under the same rewrite)
and prep.3 (kernel-tier TypeDefs enter the workspace map
automatically). No design regression to bounce back over.
Spec updated to document the realisation mechanism honestly: the
"Realisation mechanism — workspace pre-pass" subsection clarifies
that the resolver-level semantics described in "Implementation
shape" are the user-facing contract, and the actual code path is
the pre-pass.
Verification:
- `cargo test --workspace`: ALL GREEN. 87 e2e + every crate's unit
+ integration tests pass with no regressions.
- Three NEW in-source tests pin Task 1's resolver paths:
`type_scoped_member_resolves`, `type_scoped_member_not_found`,
`type_scoped_receiver_not_a_type`.
- One NEW workspace test pins the narrowed validator:
`ct1_validator_accepts_bare_with_explicit_import`.
- One renamed-and-flipped existing test:
`ct1_validator_rejects_bare_xmod_with_import_candidate` →
`ct1_validator_accepts_bare_xmod_with_import_candidate` (the
bare-with-import path is now ACCEPTED).
- One NEW companion test for the workspace-wide ctor lookup:
`ct2_term_ctor_bare_cross_module_via_workspace_resolves`.
- Two pre-existing tests' assertions updated for the new error
wording: `ct1_check_cli::check_human_mode_emits_actionable_message_to_stderr`
and `crates/ailang-check/tests/workspace.rs::unknown_module_prefix_is_reported`.
- 12 migrated `.ail` fixtures verified via the existing e2e
suite (each fixture is the test runner's target for an existing
`build_and_run` assertion).
- Negative fixture `ct_2_bare_cross_module.ail` semantically
preserved: dropped its `(import std_maybe)` so bare `Maybe` is
out-of-scope under the narrowed rule and still fires
`BareCrossModuleTypeRef`.
Concerns:
- The pre-pass introduces a new architectural layer (consumer-side
qualification) that the spec did not originally anticipate. Spec
amendment in this commit documents the layer. Future iterations
reference `prepare_workspace_for_check` as established
infrastructure.
- `examples/test_ct1_bare_xmod_rejected.ail.json` switched its
offending name from bare `Ordering` (which under the prep.1
semantics may now resolve via implicit prelude) to a still-
unresolvable `Mystery_Type`. The CLI test's intent (assert that
a human-mode `ail check` exits non-zero on a still-RED case) is
preserved.
Milestone status: kernel-extension-mechanics (Gitea #6) advances
1/3 iters. Next: prep.2 (`Term::New` construct) issue #32.
72 lines
2.8 KiB
Plaintext
72 lines
2.8 KiB
Plaintext
; Iter 15g — fifth stdlib module: first 3-way cross-module fn set.
|
||
; Imports std_list, std_either, std_pair simultaneously. All three
|
||
; combinators dispatch over List<Either<e, a>>; partition_eithers
|
||
; additionally returns Pair<List<e>, List<a>>. Stresses
|
||
; monomorphisation across List × Either × Pair, cross-module ctor
|
||
; resolution at qualified term-ctor sites, and the 16a desugar
|
||
; layer at depth-2 nested Ctor patterns (in `lefts` / `rights`).
|
||
|
||
(module std_either_list
|
||
|
||
(import std_list)
|
||
(import std_either)
|
||
(import std_pair)
|
||
|
||
(fn lefts
|
||
(doc "Project the Left payloads of a list of Eithers into a List<e>. Order-preserving. Uses the 16a nested-Ctor pattern to inline the inner Either dispatch within each Cons arm; the trailing wildcard arm seals the desugar's fall-through chain into a List<e> rather than the synthetic Unit fallback.")
|
||
(type
|
||
(forall (vars e a)
|
||
(fn-type
|
||
(params (con List (con Either e a)))
|
||
(ret (con List e)))))
|
||
(params xs)
|
||
(body
|
||
(match xs
|
||
(case (pat-ctor Cons (pat-ctor Left l) t)
|
||
(term-ctor List Cons l (app lefts t)))
|
||
(case (pat-ctor Cons (pat-ctor Right _) t)
|
||
(app lefts t))
|
||
(case _ (term-ctor List Nil)))))
|
||
|
||
(fn rights
|
||
(doc "Project the Right payloads of a list of Eithers into a List<a>. Symmetric to lefts; same nested-Ctor + wildcard-tail pattern shape.")
|
||
(type
|
||
(forall (vars e a)
|
||
(fn-type
|
||
(params (con List (con Either e a)))
|
||
(ret (con List a)))))
|
||
(params xs)
|
||
(body
|
||
(match xs
|
||
(case (pat-ctor Cons (pat-ctor Left _) t)
|
||
(app rights t))
|
||
(case (pat-ctor Cons (pat-ctor Right r) t)
|
||
(term-ctor List Cons r (app rights t)))
|
||
(case _ (term-ctor List Nil)))))
|
||
|
||
(fn partition_eithers
|
||
(doc "Partition a list of Eithers into a Pair<List<e>, List<a>>: lefts on the left, rights on the right. Single pass via direct recursion; head dispatch is a flat match on the recursive result's projections.")
|
||
(type
|
||
(forall (vars e a)
|
||
(fn-type
|
||
(params (con List (con Either e a)))
|
||
(ret (con Pair (con List e) (con List a))))))
|
||
(params xs)
|
||
(body
|
||
(match xs
|
||
(case (pat-ctor Nil)
|
||
(term-ctor Pair MkPair
|
||
(term-ctor List Nil)
|
||
(term-ctor List Nil)))
|
||
(case (pat-ctor Cons h t)
|
||
(let rest (app partition_eithers t)
|
||
(match h
|
||
(case (pat-ctor Left l)
|
||
(term-ctor Pair MkPair
|
||
(term-ctor List Cons l (app Pair.fst rest))
|
||
(app Pair.snd rest)))
|
||
(case (pat-ctor Right r)
|
||
(term-ctor Pair MkPair
|
||
(app Pair.fst rest)
|
||
(term-ctor List Cons r (app Pair.snd rest)))))))))))
|