@kha @dselsam: I added a small repro for the bug reported by Daniel on
Zulip. The current fix is not polished at all since we will replace
the equation compiler with one implemented in Lean. The bug is once
again on the code that handle nested `match`-expressions containing
recursive calls. We had problems in this module before, and the
current compilation strategy using auxiliary `*._match_<id>` functions
is also very inconvenient for users. They are often puzzled when they
see these auxiliary functions appearing in proof goals after unfolding
and/or simplification. They usually don't know what to do with these
auxiliary definitions, and have no idea how they were defined and what
they correspond to if the function has several nested
`match`-expression. Right now, the best option is to use `#print
<fun-name>._match_<id>` which is far from ideal.
@kha: @dselsam and I discussed an alternative approach where we do not
create the auxiliary definitions, annotate the generated `cases_on`
applications with meta-data indicating they correspond to a nested
match, and modify the pretty printer to display these annotated
`cases_on` applications using the `match` syntax. With these
modifications, the behavior will be similar to the one in Coq where
complex `match`-expressions are reduced to atomic ones. The only
difference is that we represent these "atomic" `match`-expressions
using `cases_on` applications.
This commit uses a simpler version of this approach where we do not
create auxiliary `*._match_<id>` functions, and more importantly do
not use the dreadful `pull_nested_rec_fn` code.
This is a temporary hack. After we eliminate the old elaborator,
we will delete the C++ class `local_context`.
In Lean4, we will not have two different kinds of local context:
`local_ctx` and `local_context`.
The scope of the expr2ctor cache updates was incorrect.
This bug affects code of the form
```
let x := C.cases_on y ...; K[x]
```
when we try to float the `cases_on` application, and the continuation
`K[x]` contains another `cases_on` application with major `y`.
The new test exposes the bug.
This commit also fixes the case where the continuation `K[x]` projects `y`.
Fixes#26
These fields were rarely used, but they were used in the hash code
calculation. So, we may see a negative performance impact.
There is also a positive performance impact since `Expr` consumes less
memory, and it is faster to allocate them.
@joehendrix I changed the default to `LLVM=OFF` for now to avoid
disrupting existing projects. It will become `LLVM=ON` after we have
tested it more, and have the JIT integrated.
@kha Could you please set a new Azure pipeline job for `LLVM=ON`?
We also add "." (i.e., current directory) if `LEAN_PATH` is not defined.
Users may still override stdlib since we add the builtin search path in the end.
@dselsam You should now be able to compile your project without setting `LEAN_PATH`
cc @kha
