The Representation of Program Synthesis in Higher Order Logic - PDF document

The Representation of Program Synthesis in Higher Order Logic Christoph Kreitz 1. Motivation and Basic Ideas 2. Type Theory and Programming 3. Methodology and Notation 4. A formalization of programming concepts 5. Principal approaches to program synthesis 1

THE SITUATION IN PROGRAM SYNTHESIS • Systematic program development is a solution for the software crisis. Programming is viewed as a reasoning process. • Machine support for program construction requires a full formalization of all the mechanisms involved. • There are many general calculi in which programs can be developed. • Implementations of program synthesizers have the same problems as other software products. They are difficult to maintain and modify, there are doubts about cor- rectness. • There is a lack of ideas how to synthesize programs.

THESES ON REASONS • Program synthesizers are essentially the same as other programs. • The development of program synthesizers does not follow methodologies similar to those which they shall automate. • There are no tools capable of formal reasoning about both programs and deductive methods in programming. • A theoretical foundation for such tools does not exist. • Existing formal frameworks are too low in their level of abstraction. The lack of insights into the nature of deductive mechanisms comes from the lack of abstraction in their formalization. For all “correctness preserving transformations” T and all specifications: SOLVABLE(specification) ⇐ SOLVABLE(T(specification)) is easier to understand than For all input and output domains IN, OUT , for all predicates IC on input variables, and all predicates IOR, ior on input and output variables: There is a program p from IN to OUT such that ∀ x:IN. IC(x) ⇒ IOR(x,(p)(x)) ⇐ There is a program p from IN to OUT such that ∀ x:IN. IC(x) ⇒ ior(x,(p)(x)) & ∀ x:IN. ∀ y:OUT. IC(x) ⇒ (IOR(x,y) ⇐ ior(x,y))

A SOLUTION • Develop a unified framework in which programs and program construc- tion can be investigated both completely formal and on a high level of abstraction. • Within the formal framework: – represent deductive mechanisms for programming – prove them correct and investigate properties – create a verified implementation • Short term goal: investigate principal approaches to program synthesis and already known individual strategies. Long term goal: derive a verified implementation of a program synthe- sizer for a certain class of problems. • Select an established general calculus to underly the formal framework. Implement high-level concepts with a proof system for it. With the extraction mechanism of the underlying calculus derive imple- mentations of deductive mechanisms from formal proofs. Requirements: Higher order logic and a model of computation. Related work “low level” calculi: Martin-L¨ of 82; Coquand & Huet 88,89; Paulin-Mohring 89; Galmiche 90; Constable et.al. 85,86,87. meta-reasoning in calculi: Constable, Knoblock, Howe 86,87,88,90. representing deductive mechanisms: ISABELLE (Paulson 87); TOOL-USE, DEVA (Sintzoff, Gabriel, Weber 86,89,90), KIV (Heisel Reif Stephan 90).

TYPE THEORY • A universal, expressive higher-order language. • A model of datatypes and computation. • Basic objects are types and members of types . • Mathematical objects and programming concepts have immediate coun- terparts. • Propositions-as-types correspondence : Each logical concept has an immediate counterpart. • Proofs-as-programs paradigm : Every theorem has a computational content which can be extracted from its proof. • An interactive environment for developing completely formal theories is available for the “dialect” NuPRL. – Sequent calculus: x 1 : T 1 , .., x n : T n ⊢ C [ext m ] – Top down proof style using refinement rules – Important system features: proof-editor to develop proofs and extract computational contents, definition mechanism , and meta-level programming of proofs. An appropriate calculus to underly the formal framework.

METHODOLOGY AND NOTATION • Formally separate abstraction levels: – object level and meta-level of programming – individuals and classes of individuals • Deductive mechanisms are considered inference rules and represented by formal theorems: ⊢ ∀ <vars involved in the context>. Main goal ⇐ Subgoal 1 . . & . & Subgoal n Aspects of a formal theorem: – Representation : formalization of the behaviour, – Justification as a logically correct reasoning step, – Implementation : Execute by applying the theorem, – Algorithm construction from partial algorithms for subgoals. • Formal definitions: <New Object> ≡ <Formal NuPRL Representation> • Classes for the object level ≡ U1 TYPES ≡ U1 FORMULAE ≡ T -> FORMULAE FORMULAE(T) ≡ { T:U1| ∀ x,y:T (x=y in T| ¬ x=y in T) } DTYPES ≡ { f:U1| (f | ¬ f) } DFORMULAE ≡ T -> DFORMULAE DFORMULAE(T)

Program Construction Concepts “Describe a problem by specifying Input and Output-domain, a pre- condition on the input and the input-output relation. Solve a specifica- tion <IN,OUT,IC,IOR> by developing a program <IN,OUT,body> which fulfils it” ≡ IN:TYPES # OUT:TYPES # FORMULAE(IN) # FORMULAE(IN#OUT) SPECIFICATIONS ≡ IN:TYPES # OUT:TYPES # (IN -> OUT) PROGRAMS ≡ IN(sp)=IN(p) in TYPES & OUT(sp)=OUT(p) in TYPES FULFILS(sp,p) & ∀ x:IN(sp). IC(sp)(x) ⇒ IOR(sp)(x,body(p)(x)) ≡ ∃ p:PROGRAMS. FULFILS(sp,p) SOLVABLE(sp) ≡ <SPECIFICATIONS, PROGRAMS, p-c, FULFILS> SYNTHSPEC(p-c) SYNTHESIZABLE(pc) ≡ ∃ synth:SPECIFICATIONS->PROGRAMS. ∀ sp:SPECIFICATIONS. pc(sp) ⇒ FULFILS(sp,synth(sp)) The same for multivalued programs ≡ IN:TYPES # OUT:TYPES # (IN -> P(OUT) ) M-PROGRAMS ≡ IN(sp)=IN(p) in TYPES & OUT(sp)=OUT(p) in TYPES M-FULFILS(sp,p) & ∀ x:IN(sp). IC(sp)(x) ⇒ body(p)(x)= { y:OUT(sp)|IOR(sp)(x,y) } ≡ ∃ p:M-PROGRAMS. M-FULFILS(sp,p) M-SOLVABLE(sp)

AE Approaches to program synthesis Given a specification <IN,OUT,IC,IOR> extract a program from a construc- tive proof for ∀ x : IN. ∃ y : OUT. IC ( x ) ⇒ IOR ( x, y ) Correctness of the deduction method: Unquestionable, provided a proof is correct. Representation formally justified by: ⊢ ∀ spec: SPECIFICATIONS. ∀ x:IN(spec). ∃ y:OUT(spec). IC(spec)(x) ⇒ IOR(spec)(x,y) ⇔ SOLVABLE( spec ) The intuitionistic aspect of Type Theory made explicit: ⊢∀ IN,OUT:TYPES. ∀ p:FORMULAE(IN#OUT). ∀ x:IN. ∃ y:OUT. p(x,y) ⇔ ∃ f:IN → OUT. ∀ x:IN.p(x,f(x)) Proof: Move all assumptions to the hypotheses list, add an identifier to the last one 1.-3. IN:TYPES, OUT:TYPES, p:FORMULAE(IN#OUT) id: ∀ x:IN. ∃ y:OUT. p(x,y) 4. ⊢ ∃ f:IN → OUT. ∀ x:IN.p(x,f(x)) Since propositions are types id is a member of the type x:IN → (y:OUT#p(x,y)) , a function returning y and a proof for p(x,y) for each x . Introduce λ x.(y where id(x)=<y,proof>) for f and β -reduce f(x). 5. λ x.(y where id(x)=<y,proof>) ∈ IN → OUT ⊢ ∀ x:IN.p(x, (y where id(x)=<y,proof>) ) Moving x to the hypotheses list and instantiating 4 with x proves the goal

Transformation based approaches Given a specification <IN,OUT,IC,IOR> define a predicate P ( x, y ) by: ∀ x : IN. ∀ y : OUT.IC ( x ) ⇒ P ( x, y ) ⇔ IOR ( x, y ) In this frame transform IOR ( x, y ) until it is computationally convenient. Representation formally justified: Express the predicative program P ( x, y ) by a multivalued program p with body ( p )( x ) := { y : OUT ( p ) | P ( x, y ) } . Constructing p means to prove: ∃ p:M-PROGRAMS. ∀ x:IN(p). IC(x) ⇒ body(p)(x)= { y:OUT(p)|IOR(x,y) } The same as M-SOLVABLE(<IN,OUT,IC,IOR>) . ≡ { t:SPECIFICATIONS->SPECIFICATIONS | TRANSFORMATIONS ∀ s:SPECIFICATIONS. IN(T(s))=IN(s) in TYPES & OUT(T(s))=OUT(s) in TYPES & IC(T(s))=IC(s) in TYPES } C-TRANSFORMATIONS ≡ { t:TRANSFORMATIONS| ∀ s:SPECIFICATIONS. ∀ x:IN(s). ∀ y:OUT(s). IC(s)(x) ⇒ (IOR(s)(x,y) ⇐ IOR(T(s))(x,y)) } EQ-TRANSFORMATIONS ≡ { t:TRANSFORMATIONS| ∀ s:SPECIFICATIONS. ∀ x:IN(s). ∀ y:OUT(s). IC(s)(x) ⇒ (IOR(s)(x,y) ⇔ IOR(T(s))(x,y)) } Correctness of the deduction method: ⊢ ∀ T:C-TRANSFORMATIONS. ∀ specification:SPECIFICATIONS. SOLVABLE(specification) ⇐ SOLVABLE(T(specification)) ⊢ ∀ T:EQ-TRANSFORMATIONS. ∀ specification:SPECIFICATIONS. SOLVABLE(specification) ⇔ SOLVABLE( T(specification) ) ⇔ & M-SOLVABLE(specification) M-SOLVABLE(T(specification))

Summary • A unified framework for reasoning about programs and program con- struction, propositions and proofs. • Completely formal - concepts can be immediately implemented • High level of abstraction leads to deeper insights into the mathematics of program construction and simpler proofs. • Existing approaches to program synthesis can be unified. • Future work: – Formalize a full theory of program construction – Investigate particular subproblems (e.g. recursion schemes) – Represent individual approaches (LOPS, KIDS) • Not restricted to the area of programming