Bidirectional Interpolation for the Lambda-Calculus -- Revisiting and Formalising Craig-Čubrić Interpolation
This paper presents a new proof of Čubrić's proof-relevant interpolation theorem for the simply-typed lambda-calculus using bidirectional typing principles and provides its formalization in the Rocq proof assistant.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
The Big Picture: The "Translator" Problem
Imagine you have two people, Alice and Bob, who need to communicate.
- Alice speaks a language with words like "Apple," "Red," and "Fruit."
- Bob speaks a language with words like "Car," "Fast," and "Engine."
- They want to pass a message from Alice to Bob, but they can't talk directly because their vocabularies are too different.
Craig's Interpolation Theorem (the old idea) says: "Don't worry! There is a Translator (an Interpolant) who only speaks words that both Alice and Bob know (like 'Object' or 'Thing'). Alice can explain her message to the Translator, and the Translator can explain it to Bob."
This paper is about a new, super-powerful version of this Translator. It doesn't just translate the words; it translates the logic and the proof of the message. It ensures that if you take Alice's original message, translate it to the Translator, and then to Bob, you get the exact same message back, step-for-step.
The Problem with the Old Method
The previous method for finding this Translator (developed by a mathematician named Čubrić) was like trying to solve a maze by guessing.
- It worked, but the instructions were messy and confusing.
- It relied on a "brute force" approach: "If this part of the sentence is too big, chop it off and replace it with a variable."
- The authors of this paper looked at the old instructions and said, "This is ugly. There must be a cleaner way to do this."
The New Solution: "Bidirectional Typing"
The authors found a new way to build the Translator using a concept called Bidirectional Typing.
The Analogy: The Assembly Line vs. The Inspection Station
Imagine a factory making toys.
- Inference (The Assembly Line): You look at a toy part and ask, "What is this?" You figure out its type based on its shape. (e.g., "This is a wheel.")
- Checking (The Inspection Station): You are told, "This must be a wheel." You look at the part and verify, "Yes, it fits the definition of a wheel."
In computer science (specifically the Lambda Calculus, which is the math behind programming languages), "Bidirectional Typing" means switching between these two modes depending on what you are doing.
- When you are building a complex structure (like a function), you check it against a known blueprint.
- When you are using a structure (like applying a function to an argument), you infer what it does.
The authors realized that this "switching" method perfectly matches the "Normal Forms" (the cleanest, most efficient versions of a mathematical proof). By using this method, they could build their Translator much more cleanly than the old "brute force" method.
The "Sum" Problem (The Tricky Part)
The paper deals with a specific type of math called STLC+ (Simply Typed Lambda Calculus with Sums).
- The "Sum" Analogy: Imagine a menu that says "Choose either a Burger OR a Pizza."
- In math, handling "OR" statements is notoriously difficult. It's like trying to build a bridge where the road splits into two different directions, and you have to make sure the bridge holds up on both sides simultaneously.
Previous attempts to handle this "OR" split were messy. The authors discovered that their "Bidirectional" method handles these splits naturally. It's like having a smart traffic light that knows exactly when to send cars to the Burger lane and when to send them to the Pizza lane, ensuring no traffic jams (mathematical errors) occur.
The "Formal" Part: The Robot Lawyer
The authors didn't just write this down on paper; they built a Robot Lawyer (using a tool called Rocq, which is a proof assistant).
- They fed their new rules into the robot.
- The robot checked every single step of their logic to ensure there were no holes, no mistakes, and no "magic" assumptions.
- Why do this? In math, humans make mistakes. A robot doesn't. If the robot says "This proof is correct," you can trust it 100%.
They also proved that their method works for Normalization.
- Analogy: Imagine you have a messy, tangled ball of yarn (a complex proof).
- Normalization is the process of untangling it until it's a perfect, neat ball.
- The authors proved that their new method can untangle any valid proof, even the messy ones involving "OR" statements, which was a hard thing to prove before.
Why Should You Care?
- Better Software: This math is the foundation of programming languages. If we understand how to "translate" code logic better, we can build compilers that catch bugs earlier and write safer software.
- Cleaner Math: They took a messy, 60-year-old proof and cleaned it up, making it easier for future mathematicians to understand and build upon.
- The "Proof-Relevant" Twist: Most math proofs just say "This is true." This paper says, "Here is exactly how it is true, and here is the recipe to rebuild the proof from scratch." It's the difference between being told "The cake is delicious" and being given the exact recipe to bake it again.
Summary in One Sentence
The authors took a messy, old mathematical puzzle about translating logic between different systems, solved it using a clever "two-way" checking method (Bidirectional Typing), and proved it works perfectly using a computer robot, making the whole process cleaner, faster, and more reliable.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.