lean4-htt/tests/lean/run/4644.lean
Joachim Breitner 4eea57841d
refactor: rfl tactic: do not use Kernel.isDefEq (#3772)
Sebastian mentioned that the use of the kernel defeq was to work around
a performance issue that was fixed since. Let's see if we can do
without.

This is also a semantic change: Ground terms (no free vars, no mvars)
are reduced at
“all” transparency even if the the transparency setting is default. This
was the case
even before 03f6b87647 switched to the
kernel defeq
checking for performance. It seems that this is rather surprising
behavior from the user
point of view. The fallout on batteries and mathlib is rather limited,
only a few
`rfl` proofs seem to have (inadvertently or not) have relied on this.

The speedcenter reports no significant regressions on core or mathlib.
2024-09-03 19:51:14 +00:00

48 lines
1.8 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

-- NB: well-founded recursion, so irreducible
def sorted_from_var [x: LE α] [DecidableRel x.le] (a: Array α) (i: Nat): Bool :=
if h: i + 1 < a.size then
have : i < a.size := Nat.lt_of_succ_lt h
a[i] ≤ a[i+1] && sorted_from_var a (i + 1)
else
true
termination_by a.size - i
def check_sorted [x: LE α] [DecidableRel x.le] (a: Array α): Bool :=
sorted_from_var a 0
/--
error: The rfl tactic failed. Possible reasons:
- The goal is not a reflexive relation (neither `=` nor a relation with a @[refl] lemma).
- The arguments of the relation are not equal.
Try using the reflexivity lemma for your relation explicitly, e.g. `exact Eq.refl _` or
`exact HEq.rfl` etc.
⊢ check_sorted #[0, 3, 3, 5, 8, 10, 10, 10] = true
-/
#guard_msgs in
example: check_sorted #[0, 3, 3, 5, 8, 10, 10, 10] = true := by
rfl -- fails because `rfl` uses `.default` transparency, and `sorted_from_var` is marked as irreducible
/--
error: tactic 'decide' failed for proposition
check_sorted #[0, 3, 3, 5, 8, 10, 10, 10] = true
since its 'Decidable' instance
instDecidableEqBool (check_sorted #[0, 3, 3, 5, 8, 10, 10, 10]) true
did not reduce to 'isTrue' or 'isFalse'.
After unfolding the instances 'instDecidableEqBool' and 'Bool.decEq', reduction got stuck at the 'Decidable' instance
match check_sorted #[0, 3, 3, 5, 8, 10, 10, 10], true with
| false, false => isTrue ⋯
| false, true => isFalse ⋯
| true, false => isFalse ⋯
| true, true => isTrue ⋯
-/
#guard_msgs in
example: check_sorted #[0, 3, 3, 5, 8, 10, 10, 10] := by
decide -- fails because `decide` uses `.default` transparency, and `sorted_from_var` is marked as irreducible
unseal sorted_from_var in
example: check_sorted #[0, 3, 3, 5, 8, 10, 10, 10] := by
decide -- works
example: check_sorted #[0, 3, 3, 5, 8, 10, 10, 10] := by
with_unfolding_all decide -- should work