39286862e3
we keep running into examples where working with well-founded recursion is slow because defeq checks (which are all over the place, including failing ones that are back-tracked) unfold well-founded definitions. The definition of a function defined by well-founded recursion should be an implementation detail that should only be peeked inside by the equation generator and the functional induction generator. We now mark the mutual recursive function as irreducible (if the user did not set a flag explicitly), and use `withAtLeastTransparency .all` when producing the equations. Proofs can be fixed by using rewriting, or – a bit blunt, but nice for adjusting existing proofs – using `unseal` (a.k.a. `attribute [local semireducible]`). Mathlib performance does not change a whole lot: http://speed.lean-fro.org/mathlib4/compare/08b82265-75db-4a28-b12b-08751b9ad04a/to/16f46d5e-28b1-41c4-a107-a6f6594841f8 Build instructions -0.126 %, four modules with significant instructions decrease. To reduce impact, these definitions were changed: * `Nat.mod`, to make `1 % n` reduce definitionally, so that `1` as a `Fin 2` literal works nicely. Theorems with larger `Fin` literals tend to need a `unseal Nat.modCore` https://github.com/leanprover/lean4/pull/4098 * `List.ofFn` rewritten to be structurally recursive and not go via `Array.ofFn`: https://github.com/leanprover-community/batteries/pull/784 Alternative designs explored were * Making `WellFounded.fix` irreducible. One benefit is that recursive functions with equal definitions (possibly after instantiating fixed parameters) are defeq; this is used in mathlib to relate [`OrdinalApprox.gfpApprox`](https://leanprover-community.github.io/mathlib4_docs/Mathlib/SetTheory/Ordinal/FixedPointApproximants.html#OrdinalApprox.gfpApprox) with `.lfpApprox`. But the downside is that one cannot use `unseal` in a targeted way, being explicit in which recursive function needs to be reducible here. And in cases where Lean does unwanted unfolding, we’d still unfold the recursive definition once to expose `WellFounded.fix`, leading to large terms for often no good reason. * Defining `WellFounded.fix` to unroll defintionally once before hitting a irreducible `WellFounded.fixF`. This was explored in #4002. It shares most of the ups and downs with the previous variant, with the additional neat benefit that function calls that do not lead to recursive cases (e.g. a `[]` base case) reduce nicely. This means that the majority of existing `rfl` proofs continue to work. Issue #4051, which demonstrates how badly things can go if wf recursive functions can be unrolled, showed that making the recursive function irreducible there leads to noticeably faster elaboration than making `WellFounded.fix` irreducible; this is good evidence that the present PR is the way to go. This fixes https://github.com/leanprover/lean4/issues/3988 --------- Co-authored-by: Leonardo de Moura <leomoura@amazon.com>
35 lines
841 B
Text
35 lines
841 B
Text
def ack : Nat → Nat → Nat
|
|
| 0, y => y+1
|
|
| x+1, 0 => ack x 1
|
|
| x+1, y+1 => ack x (ack (x+1) y)
|
|
termination_by a b => (a, b)
|
|
|
|
/--
|
|
info: [reduction] unfolded declarations (max: 1725, num: 4):
|
|
Nat.rec ↦ 1725
|
|
⏎
|
|
Eq.rec ↦ 1114
|
|
⏎
|
|
Acc.rec ↦ 1050
|
|
⏎
|
|
PSigma.rec ↦ 513[reduction] unfolded reducible declarations (max: 1577, num: 3):
|
|
Nat.casesOn ↦ 1577
|
|
⏎
|
|
Eq.ndrec ↦ 984
|
|
⏎
|
|
PSigma.casesOn ↦ 513[kernel] unfolded declarations (max: 1193, num: 5):
|
|
Nat.casesOn ↦ 1193
|
|
⏎
|
|
Nat.rec ↦ 1065
|
|
⏎
|
|
Eq.ndrec ↦ 973
|
|
⏎
|
|
Eq.rec ↦ 973
|
|
Acc.rec ↦ 754use `set_option diagnostics.threshold <num>` to control threshold for reporting counters
|
|
-/
|
|
#guard_msgs in
|
|
unseal ack in
|
|
set_option diagnostics.threshold 500 in
|
|
set_option diagnostics true in
|
|
theorem ex : ack 3 2 = 29 :=
|
|
rfl
|