Skip to content

refactor(bz): migrate HexBerlekampZassenhaus to the module system - #8597

Merged
kim-em merged 2 commits into
mainfrom
bz-module-migration
Jul 4, 2026
Merged

refactor(bz): migrate HexBerlekampZassenhaus to the module system#8597
kim-em merged 2 commits into
mainfrom
bz-module-migration

Conversation

@kim-em

@kim-em kim-em commented Jul 4, 2026

Copy link
Copy Markdown
Owner

This PR migrates the executable HexBerlekampZassenhaus library onto the Lean 4 module system (module / public import / public section), the prerequisite for splitting its 19k-line Basic.lean monolith into dependency-ordered leaves.

The migration surfaced two genuine lean4 module-system reduction bugs, both diagnosed to root and worked around locally (each with a -- revert once upstream lands comment):

  • Array.instDecidableEqImpl is not @[expose], so decide/rfl over Array equality does not reduce in the kernel under the module system for two nonempty arrays (Array.instDecidableEq inlines the empty cases but delegates the nonempty case to the opaque impl). Worked around with import all Init.Data.Array.DecidableEq, keeping the efficient Array instance rather than switching to a slower List-based one. Upstream fix: fix: expose Array equality for kernel reduction leanprover/lean4#14270.
  • Array.back? does not reduce under the module system, so DensePoly.leadingCoeff is reimplemented as coeffs.getD (size - 1) 0 instead of coeffs.back?.getD 0 (definitionally equal, kernel-reducible, and it avoids an Option allocation).

The remaining changes are the standard migration mechanics: public meta imports so the 117 #guard compile-time checks evaluate, the backward.{proofsInPublic,privateInPublic} options for private-in-public references, @[expose] on the executable defs that exported decide/rfl/unfold proofs reduce through (including the shallow factor 0 constant-branch closure), de-privatising the leaked GcdLaws Rat instance, and exposing SquareFreeRat. The leadingCoeff reimplementation rippled into about a dozen leadingCoeff = coeff (size - 1) re-proofs across HexPoly/HexHensel/HexBerlekamp/HexPolyFp/HexPolyZ/HexPolyMathlib/HexBerlekampZassenhausMathlib, all rewritten to the simp [leadingCoeff, coeff, size] form.

There is no runtime performance regression: the only change to compiled code is leadingCoeff (equal or marginally faster), and the DecidableEq instance is unchanged. Full lake build (4088 jobs) is green, check_dag.py passes, and no sorry/axiom is introduced.

🤖 Prepared with Claude Code

Migrate the executable Berlekamp-Zassenhaus library onto the Lean 4 module
system (module / public import / public section), the prerequisite for
splitting the 19k-line Basic.lean monolith.

Works around two lean4 module-system reduction bugs found in the process:
- Array.instDecidableEqImpl is not @[expose], so decide/rfl over Array
  equality does not reduce in the kernel under the module system for
  nonempty arrays. Worked around with import all Init.Data.Array.DecidableEq
  (keeping the efficient Array instance); upstream fix in leanprover/lean4#14270.
- Array.back? does not reduce under the module system; reimplement
  DensePoly.leadingCoeff as coeffs.getD (size - 1) 0 (equal, reducible).

Adds public meta imports for the #guards, the backward.{proofsInPublic,
privateInPublic} options, @[expose] on the executable defs exported defeq
proofs reduce through, and de-privatises the leaked GcdLaws Rat instance.
No runtime performance regression (only leadingCoeff's compiled body
changes, equal-or-faster; DecidableEq unchanged).

See progress/20260704T000000Z_bz-module-migration-phase1a.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…vers

The DensePoly.leadingCoeff reimplementation (coeffs.getD (size-1) 0 instead
of coeffs.back?.getD 0) broke the monic-witness proofs in the bench exe and
emit-fixture drivers, which the module-migration commit missed because a
plain `lake build` does not build the bench/conformance sub-projects (CI
does). Rewrite the `change ...back?.getD 0 = 1` proofs to close the
getD form via Array.getElem_push.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@kim-em
kim-em merged commit 1cf289d into main Jul 4, 2026
1 check passed
kim-em added a commit that referenced this pull request Jul 4, 2026
…tem (#8600)

Migrate the Mathlib-side Berlekamp-Zassenhaus correspondence library (the 13
files under `HexBerlekampZassenhausMathlib/` plus the umbrella) onto the Lean 4
module system, the Phase-1b follow-up to #8597 and the prerequisite for the
Phase-2 split of the 22k-line `Basic.lean`.

Per file: `module`, `public import`, `public section`, and the
`backward.{proofsInPublic,privateInPublic}` crutch where private decls are
referenced in public. The bridge proves correctness by unfolding executable
and Mathlib-side defs, so it needs a large `@[expose]` pass (89 defs, driven
outward from each "not an exposed body" / "not unfolded because not exposed"
error until green) spanning the executable `HexBerlekampZassenhaus`/`HexHensel`
layers, the `HexBerlekampMathlib`/`HexPolyZMathlib` bridges, and the library's
own defs.

The `irreducible_cert` tactic and its tests need their elaboration-time helpers
marked `meta` (`public meta import` for the reifier), and the certificate
kernel replay reduces `checkIrreducibleCertLinear` and its Berlekamp pow-chain
plus `Array`/`DensePoly` `==` through `import all` of the executable checker
modules and `Init.Data.Array.DecidableEq`.

Two proof-text repairs in the `monicModPImage`-zero branch adapt to module
reduction (a `simp` that started leaving a spurious `SemigroupWithZero`
metavariable, and a `dvd_zero` on `toMathlibPolynomial 0`); no theorem
statements change.

See progress/20260704T141029Z_bz-mathlib-module-migration-phase1b.md.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant