Conversation

Then separately, you might design a language in Iris whose semantics were those of the abstract machine, and try to prove them observationally equivalent (using some sort of contextual refinement, maybe?).
3
Well, they're what you're actually *implementing*, so if you want to tie this proof to what you're doing it's necessary. You don't have to do it if you just want to prove things about your theory, but in fact most bugs in Coq are not foundational ones, but implementation errors.
1
1
A huge advantage of having parts of the kernel (especially stuff like the reduction machine) formalized would be to catch those bugs, since the correctness of those modules is relied upon heavily elsewhere and they are used all over the place.
2
1
Ideally you'd extract an implementation, but in practice we aren't really there yet, so you just try to make sure it matches closely. It's not a satisfying answer and I hope to improve that! That said, I believe even something like that would catch almost all implementation bugs.
1
1
For dependent type theory I think it's particularly important because the reduction machine is this crazy call by need thing that gets repeatedly *executed* during typechecking rather than being an idealized model used as the source for an optimizing compiler.
1
1
It needs to preserve typing and conversion and properly handle substitutions under bindings and so on, but it *also* usually has a bunch of hacks like caching, configurable reduction strategies, and complex preconditions to make it go fast, making reasoning about it nontrivial.
1
1