Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ltree_every and ltree_finite_branching #1172

Merged

Conversation

binghe
Copy link
Member

@binghe binghe commented Dec 11, 2023

Currently in ltreeTheory (co-inductive lazy tree, which allows for both infinite depth
and infinite breadth), there's no predicate asserting the tree is "finite branching" (either finite or infinite depth). The existing ltree_finite states for both finite depth and breadth, i.e. the number of subtrees is finite.

It seems that, a every predicate for each subtree (thus both the node data and children are accessible) of a ltree can be simply defined like this by CoInductive:

CoInductive ltree_every :
    P a ts /\ every (ltree_every P) ts ==> (ltree_every P (Branch a ts))
End

And then ltree_finite_branching simply says that each subtree has finite number of directly children:

   [ltree_finite_branching_def]  Definition
      
      ⊢ ltree_finite_branching = ltree_every (λa ts. LFINITE ts)

To ease the use of ltree_finite_branching, just like it's co-inductively defined by CoInductive, the following 3 theorems (rules, cases, and coind) are manually proved (while the 3 for ltree_every are auto-generated):

   [ltree_finite_branching_cases]  Theorem      
      ⊢ ∀t. ltree_finite_branching t ⇔
            ∃a ts.
              t = Branch a (fromList ts) ∧ EVERY ltree_finite_branching ts
   
   [ltree_finite_branching_coind]  Theorem      
      ⊢ ∀P. (∀t. P t ⇒ ∃a ts. t = Branch a (fromList ts) ∧ EVERY P ts) ⇒
            ∀t. P t ⇒ ltree_finite_branching t
   
   [ltree_finite_branching_rules]  Theorem      
      ⊢ ∀a ts.
          EVERY ltree_finite_branching ts ⇒
          ltree_finite_branching (Branch a (fromList ts))

Please review the correctness (of the definitions).

@mn200
Copy link
Member

mn200 commented Dec 11, 2023

These definitions look nice, but it would be nice to have iff (and probably [simp]) theorems for both new constants as well if possible. I guess something like

ltree_every P (Branch a ts) <=> P a /\ every (ltree_every P ts)

for ltree_every and something similar for finitely branching.

@binghe
Copy link
Member Author

binghe commented Dec 11, 2023

Thanks. I have now added:

   [ltree_every_rewrite]  Theorem      
      ⊢ ltree_every P (Branch a ts) ⇔ P a ts ∧ every (ltree_every P) ts

   [ltree_finite_branching_rewrite]  Theorem      
      ⊢ ltree_finite_branching (Branch a ts) ⇔
        LFINITE ts ∧ every ltree_finite_branching ts

@binghe
Copy link
Member Author

binghe commented Dec 11, 2023

By the way, is there a shorter way to write GEN_REWRITE_TAC (RATOR_CONV o ONCE_DEPTH_CONV) empty_rewrites []? I have used tactics like this many times when I needed to rewrite only the L part of a term like L = R (replacing RATOR_CONV with RAND_CONV I can do the R-part)

@mn200
Copy link
Member

mn200 commented Dec 11, 2023

The SimpLHS and SimpRHS (documented in the DESCRIPTION manual) special forms can help with this sort of thing, when using the simplifier.

@binghe
Copy link
Member Author

binghe commented Dec 11, 2023

The SimpLHS and SimpRHS (documented in the DESCRIPTION manual) special forms can help with this sort of thing, when using the simplifier.

Thanks. I have simplified the two proofs involving GEN_REWRITE_TAC (and it turns out that even SimpLHS, etc. is not needed...) I think you can squash all commits in this PR.

@mn200 mn200 merged commit d587e1c into HOL-Theorem-Prover:develop Dec 11, 2023
2 checks passed
@mn200
Copy link
Member

mn200 commented Dec 11, 2023

Thanks!

@binghe binghe deleted the ltree_every_n_finite_branching branch December 21, 2023 04:07
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