Proof Relevant ATP for Type Inference? Katya Komentdantskaya (joint - PowerPoint PPT Presentation

Proof Relevant ATP for Type Inference? Katya Komentdantskaya (joint work with Peng Fu and Tom Schrijvers) Heriot-Watt University, Edinburgh Dagstuhl, 30th March 2016

A common pattern in typed language development 2 / 15

A common pattern in typed language development ◮ Some talks highlighted the problem already: if a proof is delivered by an ATP , it comes with no proof term. (It is a different “citizen" from lemmas whose proof terms are constructed interactively. ) ◮ Do we need a better picture? 2 / 15

Personal experience, 2014-2015 3 / 15

Relation of type classes to Horn Clause logic class Eq x where eq :: Eq x => x -> x -> Bool instance (Eq x, Eq y) => Eq (x, y) where eq (x1, y1) (x2, y2) = eq x1 x2 && eq y1 y2 instance Eq Int where eq x y = primtiveIntEq x y 4 / 15

Relation of type classes to Horn Clause logic class Eq x where eq :: Eq x => x -> x -> Bool instance (Eq x, Eq y) => Eq (x, y) where eq (x1, y1) (x2, y2) = eq x1 x2 && eq y1 y2 instance Eq Int where eq x y = primtiveIntEq x y Consider the following logic program: ( Eq x , Eq y ) ⇒ Eq ( x , y ) Eq Int Resolve the query ? Eq ( Int , Int ) . ◮ We have the following reduction by SLD-resolution: Φ ⊢ Eq ( Int , Int ) → Eq Int , Eq Int → Eq Int → ∅ 4 / 15

Problems... Ok, we have some grounds for interfacing FP (type class resolution) and LP (SLD-resolution). BUT: 5 / 15

Problems... Ok, we have some grounds for interfacing FP (type class resolution) and LP (SLD-resolution). BUT: ◮ This syntactic correspondence is too shallow and fragile a ground for a long-term and sustainable methodology 5 / 15

Problems... Ok, we have some grounds for interfacing FP (type class resolution) and LP (SLD-resolution). BUT: ◮ This syntactic correspondence is too shallow and fragile a ground for a long-term and sustainable methodology ◮ Gives a lot of trust to ATP , the latter is used as a black-box oracle, that certifies inference without constructing and passing back a proof evidence 5 / 15

Problems... Ok, we have some grounds for interfacing FP (type class resolution) and LP (SLD-resolution). BUT: ◮ This syntactic correspondence is too shallow and fragile a ground for a long-term and sustainable methodology ◮ Gives a lot of trust to ATP , the latter is used as a black-box oracle, that certifies inference without constructing and passing back a proof evidence ◮ This approach lacks a conceptual understanding of relation between Types, Computation, and Proof 5 / 15

Problems... Ok, we have some grounds for interfacing FP (type class resolution) and LP (SLD-resolution). BUT: ◮ This syntactic correspondence is too shallow and fragile a ground for a long-term and sustainable methodology ◮ Gives a lot of trust to ATP , the latter is used as a black-box oracle, that certifies inference without constructing and passing back a proof evidence ◮ This approach lacks a conceptual understanding of relation between Types, Computation, and Proof ◮ ... it is bound to cause practical and theoretical problems (with runnable proofs, corecursion, soundness, ...) 5 / 15

Problem: In type inference, proofs ARE programs! class Eq x where eq :: Eq x => x -> x -> Bool instance (Eq x, Eq y) => Eq (x, y) where eq (x1, y1) (x2, y2) = eq x1 x2 && eq y1 y2 instance Eq Int where eq x y = primtiveIntEq x y test :: Eq (Int, Int) => Bool test = eq (1,2) (1,2) {- eval: test ==> True -} We need to construct an evidence of Eq (Int, Int) for test . In this example and generally, it needs to be run as a function by Haskell NB: Type Inhabitation problem! 6 / 15

In Haskell, proofs ARE type inhabitants data Eq x where EqD :: (x -> x -> Bool) -> Eq x eq :: Eq x -> (x -> x -> Bool) eq (EqD e) = e k1 :: Eq x -> Eq y -> Eq (x, y) k1 d1 d2 = EqD q where q (x1, y1) (x2, y2) = eq d1 x1 x2 && eq d2 y1 y2 k2 :: Eq Int k2 = EqD primtiveIntEq test :: Eq (Int, Int) -> Bool test d = eq d (1,2) (1,2) {- eval: test (k1 k2 k2) ==> True -} How do we obtain (k1 k2 k2) for test ? SLD-resolution alone is not sufficent 7 / 15

Solution: Make resolution proof relevant: Horn formulas as types, proofs as terms Definition (Basic syntax) ::= x | K | t t ′ Term t ::= Atomic Formula A , B , C , D P t 1 ... t n Horn Formula ::= B 1 , ..., B n ⇒ A H Proof/Evidence ::= κ | e e ′ e Axiom Environment Φ ::= · | Φ , ( κ : H ) Definition (Resolution) Φ ⊢ e : A Φ ⊢ e 1 : σ B 1 · · · Φ ⊢ e n : σ B n if ( κ : B 1 , ..., B n ⇒ A ) ∈ Φ Φ ⊢ κ e 1 · · · e n : σ A 8 / 15

Solution: make resolution proof relevant: Horn formulas as types, proofs as terms Consider the following logic program Φ (clause names are constant terms) κ 1 : ( Eq x , Eq y ) ⇒ Eq ( x , y ) κ 2 : Eq Int Resolve the query ? Eq ( Int , Int ) . ◮ We have the following reduction: Φ ⊢ Eq ( Int , Int ) → κ 1 Eq Int , Eq Int → κ 2 Eq Int → κ 2 ∅ 9 / 15

Solution: make resolution proof relevant: Horn formulas as types, proofs as terms Consider the following logic program Φ (clause names are constant terms) κ 1 : ( Eq x , Eq y ) ⇒ Eq ( x , y ) κ 2 : Eq Int Resolve the query ? Eq ( Int , Int ) . ◮ We have the following reduction: Φ ⊢ Eq ( Int , Int ) → κ 1 Eq Int , Eq Int → κ 2 Eq Int → κ 2 ∅ ◮ Corresponding derivation: Φ ⊢ κ 2 : Eq x , Eq y ⇒ Eq ( x , y ) Φ ⊢ κ 1 : Eq Int Φ ⊢ κ 2 κ 1 : Eq y ⇒ Eq ( Int , y ) Φ ⊢ κ 1 : Eq Int Φ ⊢ κ 2 κ 1 κ 1 : Eq ( Int , Int ) 9 / 15

So far... ◮ We have started to build a “house" on solid grounds: NB: automated proof construction = type inhabitation. 10 / 15

So far... ◮ We have started to build a “house" on solid grounds: NB: automated proof construction = type inhabitation. Is it a suitable home for real-world Haskell type inference? By adding rules for fixpoint at term level, we were able to extend Haskell type class ability to handle nontermination coinductively. [FLOPS16] 10 / 15

Our method is now a coherent “building" that unifies foundations (type theory), implementation (evidence construction), applications (type class inference) [FLOPS16] 11 / 15

So far: Proof-relevant (or Curry-Howard) Resolution: 1. Retains operational semantics of first-order resolution (Operationally, it is still an ATP we started with!); 2. (Co)Recursive (with fixpoint terms inhabiting [coinductive] formulas with infinite proofs) 3. Coherently unifies type theory, automated proving, type inference 4. Based on solid principles: Curry-Howard approach to logic, computation, and proof. 12 / 15

Computation, programming, proof Bringing three classic themes back together: Automated inference Corresponding func- Proof Principle (type level) tion (term-level) terminating resolution 13 / 15

Computation, programming, proof Bringing three classic themes back together: Automated inference Corresponding func- Proof Principle (type level) tion (term-level) terminating resolution proof evidence construc- tion 13 / 15

Computation, programming, proof Bringing three classic themes back together: Automated inference Corresponding func- Proof Principle (type level) tion (term-level) terminating resolution proof evidence construc- inductive proofs tion 13 / 15

Computation, programming, proof Bringing three classic themes back together: Automated inference Corresponding func- Proof Principle (type level) tion (term-level) terminating resolution proof evidence construc- inductive proofs tion non-terminating resolu- tion 13 / 15

Computation, programming, proof Bringing three classic themes back together: Automated inference Corresponding func- Proof Principle (type level) tion (term-level) terminating resolution proof evidence construc- inductive proofs tion non-terminating resolu- corecursive evidence tion construction 13 / 15

Computation, programming, proof Bringing three classic themes back together: Automated inference Corresponding func- Proof Principle (type level) tion (term-level) terminating resolution proof evidence construc- inductive proofs tion non-terminating resolu- corecursive evidence coinductive proofs tion construction 13 / 15

Is it wrong to Dream of... change of methodology for all ATP in Type inference? From this: 14 / 15

Is it wrong to Dream of... modular methods of building ATPs for Type inference? 15 / 15

Is it wrong to Dream of... modular methods of building ATPs for Type inference? ◮ We have built a similar prover for TRS (first-order terms as types, reductions as proofs). ◮ How far can we go? ◮ Is it (un)thinkable to ask about Curry-Howard foundations for (e.g.) SMT-solvers for Type inference? 15 / 15