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
• f all the mechanisms involved.
• There are many general calculi in which programs can be developed.
• Implementations of program synthesizers have the same problems as
• ther 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¨

• f 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: x1 : T1, .., xn : Tn ⊢ 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 ⇐ Subgoal1 & . . . & Subgoaln

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

TYPES

≡ U1

FORMULAE

≡ U1

FORMULAE(T)

≡ T -> FORMULAE

DTYPES

≡ {T:U1|∀x,y:T (x=y in T|¬x=y in T)}

DFORMULAE

≡ {f:U1| (f |¬f)}

DFORMULAE(T)

≡ T -> DFORMULAE

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”

SPECIFICATIONS

≡ IN:TYPES # OUT:TYPES # FORMULAE(IN) # FORMULAE(IN#OUT)

PROGRAMS

≡ IN:TYPES # OUT:TYPES # (IN -> OUT)

FULFILS(sp,p)

≡ IN(sp)=IN(p) in TYPES & OUT(sp)=OUT(p) in TYPES

& ∀x:IN(sp). IC(sp)(x) ⇒ IOR(sp)(x,body(p)(x)) SOLVABLE(sp)

≡∃ p:PROGRAMS. FULFILS(sp,p)

SYNTHSPEC(p-c)

≡ <SPECIFICATIONS, PROGRAMS, p-c, FULFILS>

SYNTHESIZABLE(pc) ≡∃ synth:SPECIFICATIONS->PROGRAMS. ∀sp:SPECIFICATIONS. pc(sp) ⇒ FULFILS(sp,synth(sp))

The same for multivalued programs

M-PROGRAMS

≡ IN:TYPES # OUT:TYPES # (IN -> P(OUT) )

M-FULFILS(sp,p)

≡ IN(sp)=IN(p) in TYPES & OUT(sp)=OUT(p) in TYPES

& ∀x:IN(sp). IC(sp)(x) ⇒ body(p)(x)={y:OUT(sp)|IOR(sp)(x,y)} M-SOLVABLE(sp)

≡ ∃ p:M-PROGRAMS. M-FULFILS(sp,p)

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) 4. id: ∀x:IN.∃y:OUT. p(x,y) ⊢ ∃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>).

TRANSFORMATIONS ≡ {t:SPECIFICATIONS->SPECIFICATIONS | ∀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
• f 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

NuPRL’s proof calculus for Type Theory

• Declaration: x : T

“Declare x of type T”

• Typing: t ∈ T

“The term t belongs to type T”

Hidden variant: T [ext t]

“T is inhabited”

• Sequent (goal): x1 : T1, .., xn : Tn ⊢ C [ext m]

“Under the assumptions xi : Ti we can prove that conclusion C is inhabited” (by some yet unknown member m)

m is the extract term of the goal.

• Initial goal:

⊢ C

“Start with an empty hypothesis list”

• Top down proof style:

A proof is a tree whose nodes are goals and rules. Children of a node are given by applying the rule to the goal.

• Refinement rules: explicitely given by rule schemes

H ⊢ C [ext m] by rule

• 1. H1 ⊢ C1 [ext m1]

.

• n. Hn ⊢ Cn [ext mn]

“H ⊢ C is provable if the subgoals Hi ⊢ Ci can be proven” If proofs of the subgoals yield witnesses mi for Ci being inhabited then a witness m ∈ C for the main goal is constructed by the rule.

LOPS

• Start: formula of the form ∀i.∃o. ( IC(i) ⇒ OC(i,o) )

Goal: algorithmically better formula

• Method: correctness-preserving transformations, guided by strategies

and supported by deductive tools

• Central strategies: GUESS-DOMAIN and GET-REC with additional

pre- and postprocessing. GUESS-DOMAIN: find a portion of the specification which can be used to split the input into smaller pieces and compute the desired output recursively from these pieces. GET-REC: introduce recursion depending on the results of GUESS- DOMAIN and some recursion scheme chosen from some library. Strategies leave some choices open which could be made by an assisting user or some programmed heuristic.

The strategy GUESS

∀i.∃y. ( IC(i) ⇒ OC(i,y) ) is transformed into ∀i.∀g.∃ y. dom(i,g) ⇒ (IC(i) ⇒ OC(i,y) ∧ (g=y ∨ g=y))

“Guess some hopefully correct output g or at least partial information about the output. Restrict the seach for g by some domain predicate dom(i, g) which has to be chosen from among the subsets of the conjuncts in OC(i, g). It must be possible to compute some g with dom(i, g).”

Generalized GUESS as Meta-Theorem (top-down style)

⊢ ∀vIN,OT,A:TYPES.∀IC:FORMULAE(IN).∀OC:FORMULAE(IN#OUT). ∀dom:FORMULAE(IN#A).∀t:FORMULAE(A#OUT). ∀i:IN.∃y:OUT. IC(i) ⇒ OC(i,y) ⇐ ∀i:IN.∃g:A. IC(i) ⇒ dom(i,g) & ∀i:IN.∀g:A. ∃y:OUT. dom(i,g) ⇒ IC(i) ⇒ OC(i,y) & ( t(g,y)

∨ ¬t(g,y))

• Representation:
• Justification:

Formal proof of the correctness of the deductive mechanism.

• Implementation:

Applying the theorem means executing the transformation.

• Program construction:

Extract term of the theorem is an algorithm building a program from (partial) programs for the pieces created by the transformation. Higher abstraction is desirable to strip off unimportant context