This PR implements the option `revert`, which is set to `false` by default. To recover the old `grind` behavior, you should use `grind +revert`. Previously, `grind` used the `RevSimpIntro` idiom, i.e., it would revert all hypotheses and then re-introduce them while simplifying and applying eager `cases`. This idiom created several problems: * Users reported that `grind` would include unnecessary parameters. See [here](https://leanprover.zulipchat.com/#narrow/channel/270676-lean4/topic/Grind.20aggressively.20includes.20local.20hypotheses.2E/near/554887715). * Unnecessary section variables were also being introduced. See the new test contributed by Sebastian Graf. * Finally, it prevented us from supporting arbitrary parameters as we do in `simp`. In `simp`, I implemented a mechanism that simulates local universe-polymorphic theorems, but this approach could not be used in `grind` because there is no mechanism for reverting (and re-introducing) local universe-polymorphic theorems. Adding such a mechanism would require substantial work: I would need to modify the local context object. I considered maintaining a substitution from the original variables to the new ones, but this is also tricky, because the mapping would have to be stored in the `grind` goal objects, and it is not just a simple mapping. After reverting everything, I would need to keep a sequence of original variables that must be added to the mapping as we re-introduce them, but eager case splits complicate this quite a bit. The whole approach felt overly messy. The new behavior `grind -revert` addresses all these issues. None of the `grind` proofs in our test suite broke after we fixed the bugs exposed by the new feature. That said, the traces and counterexamples produced by `grind` are different. The new proof terms are also different.
69 lines
1.9 KiB
Text
69 lines
1.9 KiB
Text
module
|
||
example (f : Int → Int) (x : Int)
|
||
: 0 ≤ x → x ≠ 0 → x ≤ 1 → f x = 2 → f 1 = 2 := by
|
||
grind
|
||
|
||
|
||
-- In the following example, model-based theory combination is disabled,
|
||
-- and we have an invalid counterexample where `x := 1`,
|
||
-- but `f x` and `f 1` have different assignments.
|
||
/--
|
||
trace: [grind.lia.model] x := 1
|
||
[grind.lia.model] f x := 2
|
||
[grind.lia.model] f 1 := 5
|
||
-/
|
||
#guard_msgs (trace) in
|
||
set_option trace.grind.lia.model true in
|
||
example (f : Int → Int) (x : Int)
|
||
: 0 ≤ x → x ≠ 0 → x ≤ 1 → f x = 2 → f 1 = 2 := by
|
||
fail_if_success grind -mbtc
|
||
sorry
|
||
|
||
/--
|
||
trace: [grind.lia.model] x := 2
|
||
[grind.lia.model] f x := 2
|
||
[grind.lia.model] f 1 := 5
|
||
-/
|
||
#guard_msgs (trace) in
|
||
set_option trace.grind.lia.model true in
|
||
example (f : Int → Int) (x : Int)
|
||
: 0 ≤ x → x ≠ 0 → x ≤ 3 → f x = 2 → f 1 = 2 := by
|
||
fail_if_success grind
|
||
sorry
|
||
|
||
example (f : Int → Int → Int) (x y : Int)
|
||
: 0 ≤ x → x ≠ 0 → x ≤ 1 → f x y = 2 → f 1 y = 2 := by
|
||
grind
|
||
|
||
example (f : Nat → Nat) (x : Nat)
|
||
: x ≠ 0 → x ≤ 1 → f x = 2 → f 1 = 2 := by
|
||
grind
|
||
|
||
example (f : Nat → Nat → Nat) (x y : Nat)
|
||
: x ≠ 0 → x ≤ 1 → f x y = 2 → f 1 y = 2 := by
|
||
grind
|
||
|
||
|
||
-- `b` must not be `2`. Otherwise, `f (b+1)` and `f 3` must be equal.
|
||
/--
|
||
trace: [grind.lia.model] a := 5
|
||
[grind.lia.model] b := 3
|
||
-/
|
||
#guard_msgs (trace) in
|
||
set_option trace.grind.lia.model true in
|
||
example (f : Int → α) (a b : Int) : b > 1 → f (b + 1) = x → f 3 = y → x = y := by
|
||
(fail_if_success grind); sorry
|
||
|
||
-- `b` must not be `2`. Otherwise, `f (b+1)` and `f 3` must be equal.
|
||
/--
|
||
trace: [grind.lia.model] x := 5
|
||
[grind.lia.model] y := 6
|
||
[grind.lia.model] a := 7
|
||
[grind.lia.model] b := 3
|
||
[grind.lia.model] f 3 := 6
|
||
[grind.lia.model] f (b + 1) := 5
|
||
-/
|
||
#guard_msgs (trace) in
|
||
set_option trace.grind.lia.model true in
|
||
example (f : Int → Int) (a b : Int) : b > 1 → f (b + 1) = x → f 3 = y → x = y := by
|
||
(fail_if_success grind); sorry
|