Thanks to @fpvandoorn for noticing this issue in Lean 2! We encountered
this situation when the inferred type of the projection argument did not
reduce to the structure type with the current transparency setting of
the type context.
We need this feature for:
1) Defining nonlinear search patterns. Example: (?m <= ?m + 1)
2) Preprocessing recursive equations and support the pattern
refinement approach used in Agda. Example: in Agda, they accept
```
def append {A : Type} : Π (m n : nat), Vec A m -> Vec A n -> Vec A (m + n)
| m n nil ys := ys
| m n (cons m' x xs) ys := cons x (append m' n xs ys)
```
These equations have to be refined. For example, `m` has to be
replaced with `0` (in the first equation), and `succ m'` in the
second. To implement this kind of refinement, we need to convert
the pattern variables (local constants) into metavariables during
elaboration. Then, the unassigned metavariables become local constants
again. This preprocessing step will fix some of the issues on #1594.
To completely fix#1594, we will need yet another preprocessing step
which will implement "complete transition" used in the equation
compiler before we start elim_match.cpp
@dselsam You have assumed that the left-hand-side (t) and
right-hand-side (s) of (t = s) and (t == s) are the last two arguments.
This is a reasonable assumption, and it is correct for eq, but it is
incorrect for heq.
The type of heq is
```
Π {α : Sort u_1}, α → Π {β : Sort u_1}, β → Prop
```
Do you recall other places where we may have made this assumption?
The dependent eliminator for an inductive predicate C is called C.drec
TODO: construct dcases_on and drec_on using C.drec
We need this recursor for implementing dependent elimination for
inductive predicates.
We don't need to define acc.drec and eq.drec in the standard library anymore.
(Type u) is the old (Type (u+1))
(PType u) is the old (Type u)
Type* is the old (Type (_+1))
PType* is the old Type*
The stdlib can be compiled, but we still have > 70 broken tests
See discussion at #1341
They were at src/library because we hoped we would be able to use them
in the type_context unifier. However, the plan did not work for several
reasons. We saved the partial implementation in the branch: https://github.com/leodemoura/lean/tree/type_context_with_refl_lemmas
Here are the problems:
1) We have to be able to rewrite even when the type context is already in tmp-mode.
This is an issue because the tmp metavariables in the refl lemma clash with the ones created in the type context.
Solution: implemented lift operation for idx metavariables, and custom
match. This solution is not perfect since the lifting is extra overhead.
2) The term being "unfolded" may be stuck. Example:
nat.add n (@one nat ?m)
will not match the pattern
nat.add ?x_0 (nat.succ ?x_1)
because ?m is not assigned yet.
We can assign it during the matching process because it is a regular metavariable and the matching is performed in
tmp_mode.
Possible workaround a) try to instanciate type class instances before we try the refl lemmas.
This is a potential performance problem because the term can be arbitrarily big.
The current heuristics we use to speed up the process do not work for the example above.
Possible workaround b) allow regular metavariables be assigned by type class resolution even
when we are in tmp-mode.
We have not tried to implement any of these workarounds.
3) There are many more lazy-delta steps. Before this feature, when we unfold `nat.add a (succ ... (succ b) ...)`,
we are done with delta-reduction. It is just iota and beta after that.
However, with refl-lemmas, the term `nat.add a (succ ... (succ b) ...)` produces one lazy-delta step per succ.
This produces nasty side-effects because of the
The heuristic (f t =?= f s) ==> (t =?= s).
Examples such as
(fib 8) =?= 34
will take a very long time because of this heuristic.
Possible workaround: cache failures like we did in Lean2.
However, failure are only easy to cache if there are no meta-variables.
4) The type context trace gets very confusing since we use is_def_eq for matching lhs while we are computing is_def_eq.
Possible workaround: disable trace when trying refl_lemmas.
5) We must be able to temporarily disable the feature.
Example: when proving a refl_lemma for a definition `f`, we may have
to expand the nested definitions
(e.g., for match-end blocks)
6) refl/simp lemmas were designed to rewrite elaborated terms.
Using them during unification may produce a series of unexpected
behaviors since terms usually contain many regular and universe meta-variables.
7) We need to define a notion of "refl stuck application".
Right now, a metavar is stuck, a projection is stuck if the structure
is stuck, a recursor is stuck is the major premise is stuck.
An application (f ...) is refl-lemma stuck if f has refl-lemmas
associated with it, AND metavariables occurring in arguments are
preventing a refl-lemma from being applied.
Now, eta and impredicativity are assumed to be always true.
Motivation: the rest of the system assumes eta.
Regarding impredicativity, we decided to support only the standard library.
