Repository navigation
Land the Data library modules that no Phase 3 issue owns #124
Description
Part of #76 (Phase 3 — standard library).
Remeasured 2026-10-03 on master at fe40d17, 25 of the 342 passing files
blocked on a missing library module name a module that #94, #95, and #96 do not
cover. Measured by first blocking stage:
| Module | Files |
|---|---|
Data.Eq |
5 |
Data.Array |
2 |
Data.Symbol |
2 |
Data.Predicate |
2 |
Data.Monoid |
2 |
Data.Foldable |
2 |
Data.Unit |
1 |
Data.Ordering |
1 |
Data.Newtype |
1 |
Data.Generic.Rep |
1 |
Data.Functor.Contravariant |
1 |
Data.Function.Uncurried |
1 |
Data.Bifunctor |
1 |
Data.Bifoldable |
1 |
stdlib/lib/Data/ currently holds only Either.purs and Maybe.purs, so the
gap is the module surface rather than any missing semantic machinery: these are
declarations over mechanisms the compiler already has.
Do
Follow the split DEC-11
fixes — a wrapper module over the compiler-owned primitives, with any raw
intrinsic import staying inside WASI.* or the Prim.* hierarchy. Data.Eq in
particular must not grow its own notion of structural equality; it has to read
the one the class solver already proves, or Eq will disagree with the
dictionary the solver emits.
Note that Data.Foldable and Data.Bifunctor are the ones with real
specification weight — they are the class surface the FE-16 deriving work and
the FE-14 fundep work both assume. Land them as declarations over existing
machinery rather than as a second implementation.
Acceptance
The 25 files move past their first blocker, and the board's Corpus cases for
this issue drops toward zero as each module lands. Because these files are
counted at first blocking stage, some will expose a later blocker once the
module resolves; re-measure and record that rather than assuming a clean pass.
Activity
Correct the first-stage blocker decomposition and close out Phase 2
Land Data.Monoid and Data.Foldable
biuld commentedon Oct 16, 2026
On 2026-10-03 the 25
passingfiles in this issue were first-blocked on a missingDatamodule. The 2026-10-17 L2 board reports 0 missing-library blockers, so those modules resolve.The same day's runtime board stops 66 in-scope
passingfiles onData.Symbol.unsafeCoerce, which has no target implementation (P8 library linking). That foreign is now the first blocker, soCorpus casesmoves from 27 to 66.Record.Unsafe.unsafeGet(2 files) is not a module this issue lists. The foreign stays unimplemented.Evidence: L6/M7 273/413 in
docs/design/D-04-suite-roadmap.md, recorded by #145.biuld commentedon Oct 17, 2026
Reopening: the
Closes #124keyword in the open-record acceptance PR #146 body auto-closed this issue, but that land is unrelated to the Data-library module accounting tracked here. The open-record topic's acceptance evidence is recorded in the open-record checklist and D-04 instead, not in this issue.Corpus casesaccounting stays as of the 2026-10-17 evidence above (Data.Symbol.unsafeCoerceremains the first blocker); a fresh recount belongs to this issue's own next measurement.biuld commentedon Oct 18, 2026
Fresh recount (the one the reopen asked for), measured 2026-10-18 on master
f5abccda(PR #148's tree), annotations oracle + serial per-root runtime board, packagee556bf2f:passingfile is first-blocked on aData.*(or any other) module this issue tracks.Data.Symbol.unsafeCoercevia the typedUnsafe.Coercedelegate (package6fcef6cc),Record.Unsafe.unsafeGetvia the checked storage primitives and official wrappers (e556bf2f;Deriving.pursandTCOFloated.pursexecute withDone).Test.Assert.checkThrows(TCOMutRec.purs), which is Effect, Effect.Console and Test.Assert surfaces over the WASI library #95'sBlockedrow, not this issue's module accounting.So
Corpus cases= 0 (stays 0 from the corrected accounting), and the issue's acceptance — the 25 files move past their first blocker, the count drops toward zero — is met. The broaderDatamodule API surface keeps its acceptance through the L6/M7 gate and the stdlib conformance tooling, not through this issue.