I was reading the thesis on metacoq `3.2. Functional Core: CCω`

and I noticed that well formed context is defined in terms of the typing judgement.

So the natural implementation from my perspective was mutual recursion between the typing judgement and the well foundeness of contexts.

But I got stuck during proofs (weakening lemma which is basically the first proof I attempted)

My weakening lemma looked like follows:

```
Γ ⊢ t: T -> Γ ##ₘ Γ' -> ⊢ Γ -> (Γ ∪ Γ' ) ⊢ t : T.
```

the `##ₘ`

means they share no free variables ... (the definition is slightly different from thesis one's.

But to prove it I needed to show the following:

```
⊢ Γ -> ⊢ Γ' -> Γ ##ₘ Γ' -> ⊢ (Γ ∪ Γ').
```

Which says if two contexts are well formed and have no common free variables, then their uniion is also well formed.

But then this required proving the weakening lemma.

I saw in metacoq that defined things in a way that avoid the mutually inductive typing as described by the the thesis.

My question here is I don't have good understanding of why mutual induction is problem.

you're talking of https://github.com/MetaCoq/metacoq/blob/v1.1-8.16/template-coq/theories/Typing.v#L741-L863 I guess? Seems like they're lifting `typing`

to `wf_local`

using a generic construction `All_local_env`

yes this is what am talking about, my question is why does this work, while mutual inductive definitions does not work!

that sounds unlikely; if you're asking "why do they avoid mutual recursion", one reason is probably that `All_local_env`

and its theory is reusable across lots of judgments.

I see, so that means that my proofs fail to work for different reason! Alright I will dig deeper.

that's not clear either

all your message shows is that one proof strategy runs into trouble, but maybe weakening and well-formedness need to be proven in mutual recursion?

what does that mean ?

`Lemma foo : ... with bar : ...`

or `Lemma foo_mut : (statement1) /\ (statement2).`

sometimes

Alright, I will check how pcuic does it in metacoq.

I also wonder if you could or should assume `⊢ (Γ ∪ Γ').`

as a hypothesis

Paolo Giarrusso said:

I also wonder if you could or should assume

`⊢ (Γ ∪ Γ').`

as a hypothesis

I was trying to stick to the paper formalization as close as possible.

_in general_ the exact order in which lemmas are proven, what is (mutually) recursive with what, is very subtle

(is/can be)

So parameterize things and avoiding mutual inductive types usually simplifies stuff ?

the problem you're describing seems orthogonal from how the types are defined

I am not if that means related to, or not related to :sweat_smile: .

orthogonal ~= unrelated

mathematically, I think reusing `All_local_env`

vs "inlining it" into a mutually recursive type should not affect what is provable, but the way theorems are formalized differs... _in particular_, avoiding mutual recursion makes the *generated* induction principle strictly weaker

one can still prove the "right" induction principle, but that's not automated by Coq's standard support

I assume that mutual recurious is better in this case.

Alright. I will have to study pcuic in more details. at least the helper lemma before I proceed with my implementation.

I would be easy to just post my code here again and ask for direct help,but I want to learn how to unstuck myself .... so I will try doing that first for a while.

once again thanks a lot for all the pointers @Paolo Giarrusso

walker has marked this topic as resolved.

welcome — but please keep in mind I'm not a metacoq dev/expert, I have more experience in simpler cases

Regarding context well-formation, what MetaCoq uses here is called a _nested_ inductive type: this is a type where the type under definition appears as a parameter of another inductive type in its own definition. The standard example is

```
Inductive rose_tree (A : Type) :=
| node : list (rose_tree A) -> rose_tree A.
```

A lot of such nested inductive type can be expressed as mutual ones instead, here for instance we can do

```
Inductive rose_tree' (A : Type) :=
| node' : rose_forest A -> rose_tree' A
with
rose_forest (A : Type) :=
| nil : rose_forest A
| cons : rose_tree' A -> rose_forest A -> rose_forest A.
```

But inlining the nested definition (here, that of list) means that each time you need to reprove all theorems on your inlined inductive type (in the second definition, you cannot use lemmas on lists to reason on `rose_forest`

). In a setting such as that of MetaCoq, this is inconvenient, which is why we go the nested way, so that we can share the theory (of `All_local_env`

in your particular case). However, on paper it is often nicer in terms of presentation to go for a more "independent" formulation, which does not depend on another definition, and thus resembles more the mutual definition than the nested one. In the end though this is mostly a formalization question, but should not impact too much the provability of lemmas.

Note, though, that in MetaCoq the "induction principle" we show for typing and use everywhere is *not* just the "standard" one you would get for a nested inductive type (although even that notion is afaik an open question, at least engineering-wise), but one that is tailored to make subsequent proofs by induction nicer.

Also, I wouldn't call my thesis "the" thesis on MetaCoq: Théo Winterhalter talks about it in his as well, and I only cover a small bit of all there is in the project!

thanks for the clarification, and I think I was able to prove weakening lemma, and almost completed proving the substitution lemma, but I went with the mutual induction, as it looks more readable to me.

The standard example is

what's A for?

Gaëtan Gilbert said:

what's A for?

Right, there is no need for a parameter

Last updated: Jul 25 2024 at 15:02 UTC