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

fix: Fix/GuessLex: refine through more casesOnApp/matcherApp #3176

Merged
merged 3 commits into from Jan 13, 2024

Conversation

nomeata
Copy link
Contributor

@nomeata nomeata commented Jan 13, 2024

there was a check

if !Structural.recArgHasLooseBVarsAt recFnName fixedPrefixSize e then

that would avoid going through .refineThrough/.addArg for
matcher/casesOn applications. It seems it tries to detect when refining
the motive/param is pointless, but it was too eager, and cause confusion
with, for example, this reasonably reasonable function:

def foo : (n : Nat) → (i : Fin n) → Bool
  | 0, _ => false
  | 1, _ => false
  | _+2, _ => foo 1 ⟨0, Nat.zero_lt_one⟩
decreasing_by simp_wf; simp_arith

In particular, the GuessLex code later expects that the (implict)
PProd.casesOn in the implementation of foo._unary will refine the
paramter, because else the (rather picky) unpackArg fails. But it also
prevents this from being provable.

So let's try without this shortcut.

Fixing this also revealed that withRecApps wasn’t looking in all corners
of a matcherApp/casesOnApp.

Fixes #3175

there was a check

    if !Structural.recArgHasLooseBVarsAt recFnName fixedPrefixSize e then

that would avoid going through `.refineThrough`/`.addArg` for
matcher/casesOn applications. It seems it tries to detect when refining
the motive/param is pointless, but it was too eager, and cause confusion
with, for example, this reasonably reasonable function:

    def foo : (n : Nat) → (i : Fin n) → Bool
      | 0, _ => false
      | 1, _ => false
      | _+2, _ => foo 1 ⟨0, Nat.zero_lt_one⟩
    decreasing_by simp_wf; simp_arith

In particular, the `GuessLex` code later expects that the (implict)
`PProd.casesOn` in the implementation of `foo._unary` will refine the
paramter, because else the (rather picky) `unpackArg` fails. But it also
prevents this from being provable.

So let's try without this shortcut.
@github-actions github-actions bot added the toolchain-available A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN label Jan 13, 2024
leanprover-community-mathlib4-bot added a commit to leanprover-community/mathlib4 that referenced this pull request Jan 13, 2024
@github-actions github-actions bot temporarily deployed to lean-lang.org/lean4/doc January 13, 2024 16:12 Inactive
leanprover-community-mathlib4-bot added a commit to leanprover-community/mathlib4 that referenced this pull request Jan 13, 2024
@leanprover-community-mathlib4-bot
Copy link
Collaborator

Mathlib CI status (docs):

@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot added the builds-mathlib CI has verified that Mathlib builds against this PR label Jan 13, 2024
leanprover-community-mathlib4-bot added a commit to leanprover-community/mathlib4 that referenced this pull request Jan 13, 2024
@nomeata nomeata marked this pull request as ready for review January 13, 2024 18:02
@nomeata nomeata added this pull request to the merge queue Jan 13, 2024
Merged via the queue into master with commit 53af5ea Jan 13, 2024
16 checks passed
@nomeata nomeata deleted the joachim/fix2175 branch January 13, 2024 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
builds-mathlib CI has verified that Mathlib builds against this PR toolchain-available A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug: GuessLex prints “Unexpected expression while unpacking n-ary argument”
2 participants