Skip to content
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

Generalize seems to try to generalize inside the hypothesis being defined #4845

Closed
3 tasks done
ymherklotz opened this issue Jul 26, 2024 · 0 comments · Fixed by #4846
Closed
3 tasks done

Generalize seems to try to generalize inside the hypothesis being defined #4845

ymherklotz opened this issue Jul 26, 2024 · 0 comments · Fixed by #4846
Labels
bug Something isn't working P-medium We may work on this issue if we find the time

Comments

@ymherklotz
Copy link
Contributor

ymherklotz commented Jul 26, 2024

Prerequisites

Please put an X between the brackets as you perform the following steps:

Description

generalize ... at * sometimes will try to modify the recursive hypothesis corresponding to the current theorem being defined, which may not be the expected behaviour. It should only try to generalize hypotheses that it can actually modify and are visible, not implementation details. Otherwise this means that there are discrepancies between generalize ... at * and generalize ... at H, even though H is the only hypothesis in the context. See the following examples:

/-! Fails because it tries to generalize the internal example hypothesis.  However, it should succeed and behave like the second example shown here. -/
example (H: 0 = 0): True := by
  generalize _H : 0 = z at *
  constructor

/-! Produces the expected behaviour. -/
example (H: 0 = 0): True := by
  generalize _H : 0 = z at H
  constructor

/-! This works as well, because it won't generalize under the binder for the internal hypothesis. -/
example (y : Nat) (H: y = 0): True := by
  generalize _H : y = z at *
  constructor

I have also made a tentative PR to try and fix to this.

Context

I tried to prove a few lemmas that required inverting hypotheses, however, these needed some of the arguments to be abstracted using generalize first so that the inversion with cases succeeds. By default I just tried generalize ... at *, however, this failed. Instead I used generalize ... at H which had the expected behaviour.

Steps to Reproduce

Link to example in playground

  1. Open the link above and observe that the first generalize fails whereas the two others succeed.

Expected behavior: generalize ... at * and generalize ... at H1 H2 ... HN should behave the same if H1 H2 ... HN are the only visible hypothesis in the context.

Actual behavior: generalize ... at * can fail sometimes where generalize ... at H1 H2 ... HN would succeed, because the wildcard version will try to generalize the internal hypothesis generated by the theorem being proven.

Versions

4.11.0-nightly-2024-07-26

Impact

Add 👍 to issues you consider important. If others are impacted by this issue, please ask them to add 👍 to it.

@ymherklotz ymherklotz added the bug Something isn't working label Jul 26, 2024
@leanprover-bot leanprover-bot added the P-medium We may work on this issue if we find the time label Aug 2, 2024
github-merge-queue bot pushed a commit that referenced this issue Oct 25, 2024
`generalize ... at *` sometimes will try to modify the recursive
hypothesis corresponding to the current theorem being defined, which may
not be the expected behaviour. It should only try to `generalize`
hypotheses that it can actually modify and are visible, not
implementation details. Otherwise this means that there are
discrepancies between `generalize ... at *` and `generalize ... at H`,
even though `H` is the only hypothesis in the context.

This commit uses `getLocalHyps` instead of `getFVarIds` to get the
current valid `FVarIds` in the context. This uses
`isImplementationDetail` to filter out `FVarIds` that are implementation
details in the context and are not visible to the user and should not be
manipulated by `generalize`.

Closes #4845
tobiasgrosser pushed a commit to opencompl/lean4 that referenced this issue Oct 27, 2024
…ver#4846)

`generalize ... at *` sometimes will try to modify the recursive
hypothesis corresponding to the current theorem being defined, which may
not be the expected behaviour. It should only try to `generalize`
hypotheses that it can actually modify and are visible, not
implementation details. Otherwise this means that there are
discrepancies between `generalize ... at *` and `generalize ... at H`,
even though `H` is the only hypothesis in the context.

This commit uses `getLocalHyps` instead of `getFVarIds` to get the
current valid `FVarIds` in the context. This uses
`isImplementationDetail` to filter out `FVarIds` that are implementation
details in the context and are not visible to the user and should not be
manipulated by `generalize`.

Closes leanprover#4845
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P-medium We may work on this issue if we find the time
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants