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

FunInd chokes on pattern match with dependent targets #4146

Closed
nomeata opened this issue May 13, 2024 · 0 comments · Fixed by #5364
Closed

FunInd chokes on pattern match with dependent targets #4146

nomeata opened this issue May 13, 2024 · 0 comments · Fixed by #5364
Labels
bug Something isn't working P-medium We may work on this issue if we find the time

Comments

@nomeata
Copy link
Contributor

nomeata commented May 13, 2024

Lean.Meta.MatcherApp.transform, used by FunInd, chokes upon a dependent match as is produced by

def bar (n : Nat) : Bool :=
  if h : n = 0 then
    true
  else
    have m+1 := n
    bar m
termination_by n

/-
error: failed to transform matcher, type error when constructing new pre-splitter motive:
  bar.match_1
    (fun n h_1 =>
      h = h_1 → (∀ (y : Nat), (invImage (fun x => x) instWellFoundedRelationOfSizeOf).1 y n → motive y) → motive n)
    x h
---
error: application type mismatch
  h✝ = h
argument
  h
has type
  ¬n✝ = 0 : Prop
but is expected to have type
  ¬x = 0 : Prop
-/
#check bar.induct

The have syntax is desugared to

def baz (n : Nat) : Bool :=
  if h : n = 0 then
    true
  else
    match n, h with
    | m+1, _ => baz m
termination_by n
#check baz.induct

And also affects other types, e.g.

def foo [DecidableEq α] (xs : List α) : Bool :=
  if h : xs = [] then
    true
  else
    have _::ys := xs
    foo ys
termination_by xs
#check foo.induct

Versions

4.9.0-nightly-2024-05-11

Impact

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

@nomeata nomeata added the bug Something isn't working label May 13, 2024
nomeata added a commit that referenced this issue May 13, 2024
this fixes #4146

The resulting functional induction principles generated when there is a
`match` in the function definition are far from pretty and contain
suprious copies of local definitions at their non-refined or refined
type. I expect that sometimes these may be useful, so I am hesitant to
remove them too aggressively, so for now it’s better to have too many
assumptions than too few, or even a failure (as in #4146).
@leanprover-bot leanprover-bot added the P-medium We may work on this issue if we find the time label Aug 23, 2024
github-merge-queue bot pushed a commit that referenced this issue Sep 16, 2024
A round of clean-up for the context of the functional induction
principle cases.

* Already previously, with `match e with | p => …`, functional induction
would ensure that `h : e = p` is in scope, but it wouldn’t work in
dependent cases. Now it introduces heterogeneous equality where needed
(fixes #4146)
* These equalities are now added always (previously we omitted them when
the discriminant was a variable that occurred in the goal, on the
grounds that the goal gets refined through the match, but it’s more
consistent to introduce the equality in any case)
* We no longer use `MVarId.cleanup` to clean up the goal; it was
sometimes too aggressive (fixes #5347)
* Instead, we clean up more carefully and with a custom strategy:
* First, we substitute all variables without a user-accessible name, if
we can.
  * Then, we substitute all variable, if we can, outside in.
* As we do that, we look for `HEq`s that we can turn into `Eq`s to
substitute some more
  * We substitute unused `let`s.
  
**Breaking change**: In some cases leads to a different functional
induction principle (different names and order of assumptions, for
example).
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
2 participants