[Paper Review] foetus -- Termination Checker for Simple Functional Programs

Andreas Abel|arXiv (Cornell University)|Jul 9, 2024

Formal Methods in Verification7 references16 citations

TL;DR

foetus provides a termination checker for a simple functional language with tuples, constructors, and pattern matching by extracting calls, completing a call graph, and finding a lexical termination order for function parameters.

ABSTRACT

We introduce a simple functional language foetus (lambda calculus with tuples, constructors and pattern matching) supplied with a termination checker. This checker tries to find a well-founded structural order on the parameters on the given function to prove termination. The components of the check algorithm are: function call extraction out of the program text, call graph completion and finding a lexical order for the function parameters.

Motivation & Objective

• Motivate and formalize the termination problem for a simple functional language (foetus).
• Develop a termination checker based on a well-founded order on function parameters.
• Handle mutual recursion via a call graph and its completion.
• Provide a practical prototype with examples illustrating termination behavior.

Proposed method

• Extract direct and indirect function calls from program text to build a call graph.
• Complete the call graph by composing edges to capture transitive calls.
• Search for a lexical (permutation) termination order on function parameters that decreases in all recursive calls.
• Formalize the approach using call matrices and a completion process to reason about termination.
• Demonstrate termination decisions on representative foetus programs (e.g., add, mult, sub, ack, fib).
• Explain limitations and special cases where termination cannot be established (or where the checker reports non-termination).

Experimental results

Research questions

• RQ1 How can termination of foetus functions be determined using a structural order on parameters?
• RQ2 How can a caller-callee relationship be represented and completed to capture recursive calls?
• RQ3 What termination orders (permutations) suffice to prove termination for a given function’s recursion?
• RQ4 What are the limitations of the termination checker when faced with complex or mutually recursive definitions?
• RQ5 How do concrete examples reflect the capabilities and boundaries of the approach?

Key findings

• The checker proves termination for several standard recursive definitions (e.g., addition, multiplication) by exhibiting a lexical order over parameters.
• It can prove termination in cases like Ackermann-type recursion and certain list-processing functions (map, foldl, reverse).
• It identifies non-termination in examples such as certain mutual or higher-order patterns (e.g., a specific mutual recursion that fails the lexical order after call-graph completion).
• Division-related examples show that termination may depend on auxiliary proofs; when a helper function (div’) fails termination, the outer division function is also deemed non-terminating by the checker.
• The approach is illustrated across a spectrum of programs, highlighting both terminating and non-terminating cases and how call-graph completion affects verdicts.
• The implemented checker relies on a finite completion of the call graph and permutation-based termination orders to reach conclusions.