fix: occurence check in mkInjectiveTheoremTypeCore?
#3398
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
toolchain-available
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Feb 19, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Feb 19, 2024
leanprover-community-mathlib4-bot
added
the
builds-mathlib
|
Mathlib CI status (docs):
|
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Feb 19, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Feb 19, 2024
arthur-adjedj
force-pushed
the
gen_inj_bug
branch
from
8aba2de
to
c0b9285
Compare
|
awaiting-review |
arthur-adjedj
added a commit
to arthur-adjedj/lean4
that referenced
this pull request
Mar 13, 2024
There remains 2 issues: - the check for existing mutual equivalents of the nested appearance is not right. This will need more work - (not certain) instead of simply collecting necessary local variables from `loose_bvars`, we should also collect them in the type of the lvars associated, in a chain, similarly to `occursOrInType` in PR leanprover#3398 The generation of `SizeOf` is failing on a simple example, and more complex ones lead to a segfault, but this is a good step forward.
arthur-adjedj
added a commit
to arthur-adjedj/lean4
that referenced
this pull request
Mar 15, 2024
There remains 2 issues: - the check for existing mutual equivalents of the nested appearance is not right. This will need more work - (not certain) instead of simply collecting necessary local variables from `loose_bvars`, we should also collect them in the type of the lvars associated, in a chain, similarly to `occursOrInType` in PR leanprover#3398 The generation of `SizeOf` is failing on a simple example, and more complex ones lead to a segfault, but this is a good step forward.
arthur-adjedj
added a commit
to arthur-adjedj/lean4
that referenced
this pull request
Mar 31, 2024
There remains 2 issues: - the check for existing mutual equivalents of the nested appearance is not right. This will need more work - (not certain) instead of simply collecting necessary local variables from `loose_bvars`, we should also collect them in the type of the lvars associated, in a chain, similarly to `occursOrInType` in PR leanprover#3398 The generation of `SizeOf` is failing on a simple example, and more complex ones lead to a segfault, but this is a good step forward.
semorrison
reviewed
Apr 22, 2024
github-merge-queue bot
pushed a commit
that referenced
this pull request
Apr 24, 2024
Not certain this is a good idea. Motivated by code duplication introduced in #3398.
arthur-adjedj
force-pushed
the
gen_inj_bug
branch
from
98073ed
to
70a0ce4
Compare
|
!bench |
|
Here are the benchmark results for commit 70a0ce4. |
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 10, 2024
This reverts commit 706a4cf introduced in #3970 As explained in #4124, `findM?` can become a footgun if used in monads which induce side-effects such as caching. This PR removes that function, and fixes the code introduced by #3398 for which the function was first added. cc @semorrison.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #3386
Currently, when generating the signature of an injectivity lemma for a certain constructor
c : forall xs, Foo a_1 ... a_n,mkInjectiveTheoremTypeCore?will differentiate between variables which are bound to stay the same between the two equal values (i.e inductive indices), and non-fixed ones. To do that, the function currently checks whether a variablex ∈ xsappears in the final co-domainFoo a_1 ... a_nof the constructor. This condition isn't enough however. As shown in the linked issue, the codomain may also depend on variables which appears in the type of free vars contained inFoo a_1 ... a_n, but not in the term itself. This PR fixes the issue by also checking the types of any free variable occuring in the final codomain, so as to ensure injectivity lemmas are well-typed.