A Proof-Theoretic Perspective on SMT-Solving for Intuitionistic Propositional Logic

Efficient SAT-based Proof Search in Intuitionistic Propositional Logic

“…6. Here we comply with the presentation in [10], equivalent to the original one in [2]. The recursive auxiliary function prAux plays the role of the main loop of proveR (but in proveR the set of atomsà is not used); the loop inside prAux corresponds to the inner loop of proveR.…”

“…This leads to a highly performant decision strategy; actually, on the basis of a standard benchmarks suite, intuit outperforms two of the state-of-the-art provers for IPL, namely fCube [5] and intHistGC [11]. At first sight, the intuit decision procedure seems to be far away from the traditional techniques for deciding IPL validity; on the other hand, the in-depth investigation presented in [10] unveils a close and surprising connection between the intuit approach based on SMT and the known proof-theoretic methods. The crucial point is that the main loop of the decision procedure mimics a standard root-first proof search strategy for the sequent calculus LJT SAT [10] (see Fig.…”

“…At first sight, the intuit decision procedure seems to be far away from the traditional techniques for deciding IPL validity; on the other hand, the in-depth investigation presented in [10] unveils a close and surprising connection between the intuit approach based on SMT and the known proof-theoretic methods. The crucial point is that the main loop of the decision procedure mimics a standard root-first proof search strategy for the sequent calculus LJT SAT [10] (see Fig. 7), a variant of Dyckhoff's calculus LJT [3].…”

“…7), a variant of Dyckhoff's calculus LJT [3]. In [10] the intuit decision procedure is re-formulated so that, given a sequent σ, it outputs either a derivation of σ in LJT SAT or a countermodel for σ.…”

“…Here we continue this investigation to better take advantage of the interplay between the SMT perspective and proof-theoretic methods. At first, we have enhanced the Haskell intuit code 1 by implementing the derivation/countermodel extraction procedures discussed in [10]. We experimented some unexpected and weird phenomena: derivations are often convoluted and contain applications of the cut rule which cannot be trivially eliminated; countermodels in general contain lots of redundancies.…”