lean4-htt/tests/lean/671.lean.expected.out
Leonardo de Moura 7ebf16ca26 fix(library/equations_compiler): performance issues at structural_rec module and equational lemma generator
There were two performance bottlenecks in the recursive equation
compiler. Both bottlenecks were due to conversion checking.

1- We allow patterns such as (x+1) in the left-hand-side of a
   recursive equation. This is kind of pattern has to be reduced
   since it is not a constructor. Moreover, when we are trying to
   compile using structural recursion, we need to find an element
   that is structurally smaller in recursive applications.
   Again, we need to use reduction since the pattern may be (x+2),
   and in the recursive application we have (x+1). Now, consider
   the following equation

         f (x+1) (y+1) := f complex_term y

   It will first check whether complex_term is structurally smaller
   than (x+1), and the compiler will timeout trying to reduce
   complex_term.

   This commit adds the following workaround. The structural
   recursion module from now on will only unfold reducible constants
   and constants marked as patterns. This is not a complete
   solution. It will timeout in the following equation:

         f (x+1) (y+1) := f (x+1000000000000) y

   For this one, we need to add a whnf "fuel" option to type_context

2- Equational lemma generation was producing lemmas that are too
   expensive to check. Suppose we the following two definitions

       | f x 0     := 1
       | f x (y+1) := f complex_term y

    and

       | g 0     y    := 1
       | g (x+1) y    := g x complex_term

    Before this commit, we would generate the following proofs for
    the second equation of each definition:

         eq.refl (f complex_term y)
         eq.refl (g x complex_term)

    This proof triggers the following definitionally equality test:

             f x     (y+1)  =?= f complex_term y
             g (x+1) y      =?= g x complex_term

    Since, we have f/g on both sides, the type checker will try
    first to unify the arguments, and may timeout trying to solve

               x  =?= complex_term
               y  =?= complex_term

    since it may take a long time to reduce `complex_term`.

    We workaround this problem by creating a slightly different
    proof.

          eq.refl (unfold_of(f x (y+1)))
          eq.refl (unfold_of(g (x+1) y))

    where unfold_of(t) is the result of applying one delta reduction
    step.
2017-02-15 21:31:28 -08:00

3 lines
72 B
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

@[pattern]
protected def nat.add : :=
nat.add._main