@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.
18 lines
368 B
Text
18 lines
368 B
Text
inductive Term : Type
|
|
| app : List Term -> Term
|
|
|
|
namespace Term
|
|
|
|
instance : Inhabited Term := ⟨app []⟩
|
|
|
|
partial def transform (f : Term -> Option Term) : Term -> Term
|
|
| t =>
|
|
match f t with
|
|
| some u => transform u
|
|
| none =>
|
|
match t with
|
|
| app args =>
|
|
let newArgs := args.map (fun arg => transform arg);
|
|
transform (app newArgs)
|
|
|
|
end Term
|