-
Notifications
You must be signed in to change notification settings - Fork 465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: simp
should not reduce tactic-defined lets.
#2682
Comments
Did not read this RFC in detail, but it seems related to other issues, and be fixed by #2734 With the PR above, we have /-
The first two example simplify because `simp` is using `decide` which will perform `zeta`.
-/
example : let l := 2; l = 2 := by
simp (config := {zeta := false})
example : let l := 2; l = 1 := by
simp (config := {zeta := false})
sorry
example : let l := 2; l = 2 := by
fail_if_success simp (config := {zeta := false, decide := false})
sorry
example : let l := 2; l = 1 := by
fail_if_success simp (config := {zeta := false, decide := false})
sorry
example (t : Nat) : let l := t; l = 2 := by
fail_if_success simp (config := {zeta := false})
sorry
example (t : Nat) : let l := 2; t = l := by
fail_if_success simp (config := {zeta := false})
sorry |
Hi Leo, sorry for being unclear and not actually leaving an mwe! Those examples were just for context, as I wasn't sure what the expected behaviour should be there. I think the main issue we'd like to change is this: example (a : Nat) : a + 1 - 1 = 37 := by
let x := a + 1 - 1
show x = _
simp only
-- I would like the goal to still be `x = _` without changing the default option.
-- Goal is instead a + 1 - 1 = 37.
sorry I understand this can be done by setting |
Leo, I'd just like to say that the main gist of this issue isn't fixed - I appreciate there's been many improvements, and the return of the |
Sorry about that, this might be due to error in my communicating with Leo. I'll reopen this now. Would anyone, e.g. @ericrbg be willing to investigate what the breakage looks like if we were to change the default to |
As requested to test in leanprover#2682.
I've tried to make a start at this in my own fork (#2779), although I'm not really sure of many details of how to develop with this. One thing that this made me realise is the point that Kyle was talking about: I'd (personally) want that a goal of the form I'm also struggling to find some tests; I can fix (or show there's issues) in the |
Here is my current understanding.
Agreed? |
Yes, I would agree with this! I'll post it in the Zulip thread too :) |
As naming suggestions, how about:
|
Great. Let's go with it. |
@semorrison BTW, I will use |
Proposal
simp
should not define tactic-definedlet
s (maybe these are calledfvar
s) by default, or at least the option to do so should be one character, as opposed to having to use(config := {zeta := false})
.In
mathlib
, the main waylet
s are used are to abstract some details of the proof; for example the following pattern:is very common, because
my_complicated_object a b 37 42
is a lot more mental strain to read thanq
; when this object appears many times in the goal, it can often be overwhelming.However, this illusion of abstraction is currently broken every time we use
simp
, as the default option to unfoldlet
bindings means that no matter our carefully packagedlet
s, we lose the details of such things every time, and the mental strain comes back, or we have to put a lot ofchange
s to keep the goal under control.There is already many ways to control
let
unfolding, with extra tools added in Mathlib. I think people were happy with the Lean3 status quo that if a let was to be unfolded, then we could just expressly put that intosimp
(i.e.by let a := b, simp [a]
); this doesn't seem to work in Lean4 either, but this is not the key issue.My proposed solution is simply that the default config option is
zeta := false
; this has an almost-zero maintainability burden bar the first refactoring for proofs that need it. There may be cleverer solutions that hopefully also don't require much more burden; see Kyle's comment below.Community Feedback
https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/simp.20unfolding.20let.20bindings is a thread discussing this issue. Within this limited sample, I see very little dissent, although this comment from Kyle is interesting:
I'm personally unsure about the details of this, but there is clearly something delicate going on:
In these examples, the first goal is closed, the second one is reduced to
False
, and the third and fourth are untouched. I'm not sure why.There seems to have been an attempt to change this here: https://github.com/PatrickMassot/lean4/releases/tag/zeta_false2.
Impact
Add 👍 to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add 👍 to it.
The text was updated successfully, but these errors were encountered: