4

I have been learning MLTT and working on implementing its type checker referencing Coq's core language specification. Currently, I am at the stage of implementing its termination checker. I find it somewhat dissatisfying that I need to implement a separate termination checker in addition to the type checker.

I suspect the need for a separate termination checker arises from the presence of lambda abstractions, which allow for recursive definitions. This requires us to distinguish valid recursive definitions from invalid ones, and the implementation of a termination checker doesn't look that simple.

Is there a version of MLTT that is fully combinatorial and does not include lambda abstraction? In such a system, recursion schemas like induction over natural numbers would be primitives, eliminating the need for a separate termination checker. Are there any papers or implementations of such a system?

If no such system exists, I am curious to know why. One potential issue I can foresee is that a fully combinatorial language might be less convenient for dealing with recursive definitions without lambda abstraction. However, it seems feasible to support lambda abstraction in the surface language and then desugar and elaborate it into a fully combinatorial core language.

What other challenges might arise with this approach? Or would a combinatorial system without lambda abstraction inherently be weaker than one with it?

12412316
  • 173
  • 4

1 Answers1

5

You need a termination checker to translate recursive pattern-matching definitions into corresponding uses of eliminators (recursion/induction principles). This has nothing to do with $\lambda$-abstraction. You can implement MLTT without a termination checker by using eliminators instead of pattern matching. MLTT itself is defined in terms of eliminators, not pattern matching.

Naïm Camille Favier
  • 731
  • 2
  • 7