We need this procedure otherwise it takes forever to prove equation lemmas
for definitions such as:
```
def macros : name → option macro
| `lambda := some lambda_macro
| `intro_x := some intro_x_macro
| _ := none
```
We never experienced this problem in Lean3 because we used `name`
literals only occurred in patterns of *meta* definitions. So, no
equation lemma was generated.
@kha `def macros` was taking more than 1 second to elaborate on my
machine. It is now instantaneous.
We want to make sure string users do not depend on the string
implementation. This is the first step.
We need this refactoring *now* to make sure it will not be
super painful to address issue #1175
There was a typo in the proof generation. The weird part is that the
proof was valid, but it was very inefficient to check.
The proof was valid because ((n:int) ≥ m) reduces to true/false if n and
m are integer numerals. Thus, if ((n:int) ≥ m) holds then `trivial` is a
valid proof.
However, the reduction is extremely inefficient since it relies on
computations in unary.
In the buggy version, we provided a proof for (a >= 0) where (b >= 0)
was expected. However, both types are definitionally equal to true.
This is why the proof worked.
