Skip to content

feat: MultiAppForStrongNorm#405

Open
WegmannDavid wants to merge 10 commits intoleanprover:mainfrom
WegmannDavid:pr/MultiApp
Open

feat: MultiAppForStrongNorm#405
WegmannDavid wants to merge 10 commits intoleanprover:mainfrom
WegmannDavid:pr/MultiApp

Conversation

@WegmannDavid
Copy link
Contributor

Added an operation that allows a list of arguments to be applied to a term and corresponding lemmas. This operation is required for strong normalization in a future pull request.

@WegmannDavid WegmannDavid changed the title feat:MultiAppForStrongNorm feat: MultiAppForStrongNorm Mar 7, 2026
@WegmannDavid WegmannDavid requested a review from fmontesi as a code owner March 7, 2026 03:10
Copy link
Collaborator

@chenson2018 chenson2018 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not carefully step through the last two longer proofs yet, but here is some initial feedback.

@@ -0,0 +1,201 @@
/-
Author: David Wegmann
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the standard copyright header from existing modules.

Comment on lines +12 to +13
set_option linter.unusedSectionVars false
set_option linter.unusedVariables false
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not unset linters other than unusedDecidableInType. For unusedSectionVars see the usage of for instance omit [HasFresh Var] in before a theorem.

if one of the arguments performs a single step, and the rest are locally closed.
-/
@[reduction_sys "βᶠ"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While you can technically use the same symbol because these notations are scoped, I don't think this is a good idea.

Comment on lines +27 to +28
multiApp f [x_1, x_2, ..., x_n] applies the arguments x_1, x_2, ..., x_n
to f in left-associative order, i.e. as (((f x_1) x_2) ... x_n).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unicode \1, \2, \_n would look nicer in these docstrings.

Comment on lines +52 to +54
lemma multiApp_step_lc_r {Ns Ns' : List (Term Var)}
(step : Ns ⭢βᶠ Ns') :
(∀ N ∈ Ns', LC N) := by
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This signature fits on one line.

Comment on lines +67 to +68
LC (M.multiApp Ns) ↔ LC M ∧ (∀ N ∈ Ns, LC N)
:= by
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
LC (M.multiApp Ns) ↔ LC M ∧ (∀ N ∈ Ns, LC N)
:= by
LC (M.multiApp Ns) ↔ LC M ∧ (∀ N ∈ Ns, LC N) := by

multiApp f [x_1, x_2, ..., x_n] applies the arguments x_1, x_2, ..., x_n
to f in left-associative order, i.e. as (((f x_1) x_2) ... x_n).
-/
@[simp]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
@[simp]
@[simp, scoped grind =]

Comment on lines +70 to +72
· induction Ns
· case nil => grind [multiApp]
· case cons N Ns ih => intro h_lc; cases h_lc; grind
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the last review, there is no need to use · and case together:

Suggested change
· induction Ns
· case nil => grind [multiApp]
· case cons N Ns ih => intro h_lc; cases h_lc; grind
· induction Ns with
| nil => grind [multiApp]
| cons => intro h_lc; cases h_lc; grind


/- congruence lemma for multi reduction of the left most term of a multi-application -/
@[scoped grind ←]
lemma steps_multiApp_l {M M' : Term Var} {Ns : List (Term Var)}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you place variable {M M' : Term Var} {Ns : List (Term Var)} at the top of the module it would make things a lot clearer in these signatures, which would then mostly fit in one or two lines.

Comment on lines +116 to +121
lemma invert_abs_multiApp_st {Ps} {M N Q : Term Var}
(h_red : multiApp (M.abs.app N) Ps ⭢βᶠ Q) :
(∃ M', M.abs ⭢βᶠ Term.abs M' ∧ Q = multiApp (M'.abs.app N) Ps) ∨
(∃ N', N ⭢βᶠ N' ∧ Q = multiApp (M.abs.app N') Ps) ∨
(∃ Ps', Ps ⭢βᶠ Ps' ∧ Q = multiApp (M.abs.app N) Ps') ∨
(Q = multiApp (M ^ N) Ps) := by
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit messy. Is it possible to separate these existentials into their own theorems?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants