-
Notifications
You must be signed in to change notification settings - Fork 84
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
Template <-> PCUIC proofs #533
Conversation
7b967c5
to
21e77a0
Compare
…than anticipated: one really has to do surgeryon the binary applications derivation to produce onewhere applications are n-ary *without* relying on transitivity of cumulativityanywhere. This requires to use induction on the size of derivations (includingnon-principal/paranoid hypotheses).
dddefdc
to
f8ab08d
Compare
Suprise surprise: when I thought PCUIC -> Template was finished I realized the application case was actually not done. It really requires a stronger induction principle on typing derivations, and a way to measure a special type of application spines to get the induction going. It's all written down in comments and proven now. I will leave the Template -> PCUIC proof as is, that is missing the proof that translation of case predicates and branches is correct, as this is currently very ugly and should get better with the upcoming new case representation. @jakobbotsch I'll handle that part when we settle on the Ast/Typing rule. |
ef23702
to
5b34d94
Compare
This PR fills the remaining holes in these proofs, mainly by updating the Template Typing definitions from what's in PCUIC now. Currently, I only finished the (easier) PCUIC -> Template proof but the other one is just boring passing of well-formedness conditions (I hope 🤞 ).
Two notable differences appeared:
PCUIC needs an additional G |- tProd na A B : tSort s assumption in applications, otherwise it's impossible to produce the corresponding assumption in Template's typing (where application is based on spines, and every product type appearing there must have a sorting judgment). Not to worry, by PCUICValidity we can get rid of this paranoid assumption.
I finally removed the
isLambda
side condition on bodies of (inductive) fixpoints as is is not needed anywhere. (And would be problematic with eta-conversion/reduction)