Towards a formal theory of program construction Christoph Kreitz - PDF document

Towards a formal theory of program construction Christoph Kreitz Abstract Principles of a unified formal theory on reasoning about programs and program con- struction built on top of Intuitionistic Type Theory. 1

OVERVIEW 1. Motivation and Basic Ideas 2. Type Theory and Programming (a) Type Theory (b) NuPRL specifics (c) Notation (d) Representing the Object-Language in Type Theory. 3. Collecting ideas: Example formalization of LOPS Strategies 4. Principles of a general theory (a) A formal specification of the concepts involved (b) Metatheorems about principal approaches (c) Meta-classes: Investigating deductive methods on a higher level of abstraction

The situation in Program Synthesis • Systematic program development is considered as an answer to the software crisis. Programming is identified as a reasoning process for which reasonable machine support can be provided. • An intellegible automation of the programming process requires a full formalization of all the mechanisms involved. • Program synthesis systems so far have the same problems as other software products. Their implementation is experimental, they are difficult to maintain and modify, and it is not clear if or why they are correct. Additionally, there is a lack of ideas how to synthesize programs. Theses on reasons • The development of a program synthesizer must follow the same methodologies as the development of “conventional programs” ex- cept for a higher level of reasoning. The lack of ideas how to guide and control deductive mechanisms in programming is due to a lack of formal metamathematics giving insights into their nature. • There is a need for systems capable of formal reasoning about both programs and deductive methods in programming (which are just higher level programs). • A unified framework for formal reasoning about programs and pro- gram development does not exist so far.

Build a formal theory of program construction 1. Avoid “creating a new logic” by expressing the formal theory within some already established general formalism Complex special purpose reasoning within the theory then can be reduced to a series of simple reasoning steps in the more general formalism. Requirements on the general formalism: A higher order theory including a model of computation. 2. Implement reasoning within the formal theory on top of a proof system for the general formalism. 3. (Mechanically) prove meta-theorems about program construction and other necessary knowledge within the formal theory. 4. Derive a verified implementation of a program synthesizer from the formal proofs. Advantages: Correctness of the synthesizer, easy maintenance and modification, clear knowledge about its behaviour and capabilities.

TYPE THEORY Intuitionistic Type Theory, a typed version of the λ -calculus, is an appropriate basis for a formal theory of program construction. • A universal, expressive language. • A model of datatypes and computation. • Fundamental for higher order mathematics and programming language design. • Basic objects are types and members of types • Logical concepts can be expressed via the propositions-as-types correspondence • Every theorem has a computational content. (Formal proofs about program construction give a verified implementation of a program synthesizer for free.) • A proof system for a special dialect of Type Theory is already implemented (Cornell’s NuPRL).

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): x 1 : T 1 , .., x n : T n ⊢ C [ext m ] “Under the assumptions x i : T i 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. H 1 ⊢ C 1 [ext m 1 ] . n. H n ⊢ C n [ext m n ] “ H ⊢ C is provable if the subgoals H i ⊢ C i can be proven” If proofs of the subgoals yield witnesses m i for C i being inhabited then a witness m ∈ C for the main goal is constructed by the rule.

NuPRL • Interactive proof development system. • problem solving paradigm: Proofs as Programs • Features: – proof-editor for interactive development – definition mechanism for readability – meta-language ML for programmed application of rules • Logic: a descendent of Martin-L¨ of’s Type Theory

NuPRL Types type canonical members logical equivalents atomic types int ... -1, 0, 1,... atom ”...” void none FALSE propositions as types atomic predicates a = a ′ in A axiom if a = a ′ , (no members otherwise ) i < j axiom if i, j ∈ int, i < j , (no members otherwise) type constructors A # B � a, b � A ∧ B if a ∈ A, b ∈ B A | B inl ( a ) , inr ( b ) A ∨ B if a ∈ A, b ∈ B A → B λx.b A ⇒ B if b ∈ B A list nil, a.l if a ∈ A, l ∈ A list x : A # B � a, b � ∃ x:A.B if a ∈ A, b ∈ B [ a/x ] x : A → B λx.b ∀ x:A.B if b ∈ B [ x ] { x : A | B } a if a ∈ A, B [ a/x ] x, y : A//B a (Equality changed: a = a ′ iff B [ a, a ′ /x, y ] ) if a ∈ A rec ( z, x.T ; A ) a if a ∈ T [ λx.rec ( z, x.T ; x ) , A/z, x ] A ❀ B (partial functions from A to B ) Universes U 1 atomic types all that can be constructed via type constructors. U 2 U 1 , members of U 1 , and all that can be constructed via type constructors. U 3 U 2 ,........

Fixing the Object-Language Notation • typewriter font for NuPRL-Expressions and -Theorems • <New Object> ≡ <Formal NuPRL Representation> defines a new type-theoretical object in terms of already existing constructs. (Supported by NuPRL’s definition facility.) ≡ 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)

LOPS • Start: formula of the form ∀ i. ∃ o. ( IC(i) ⇒ OC(i,o) ) Goal: algorithmically better formula • Method: correctness-preserving transformations, guided by strate- gies and supported by deductive tools • Central strategies: GUESS-DOMAIN and GET-REC with ad- ditional 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) ) ⇓ ∀ 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) ⊢ ∀ IN,OUT,A:TYPES. ∀ IC:FORMULAE(IN). ∀ OC:FORMULAE(IN#OUT). ∀ dom:FORMULAE(IN#A). ∀ t:FORMULAE(A#OUT). ∀ i:IN. IC(i) ⇒ ∃ y:OUT. OC(i,y) ⇐ ∀ i:IN. IC(i) ⇒ ∃ g:A. dom(i,g) ∀ i:IN. ∀ g:A. dom(i,g) ⇒ IC(i) ⇒ & ∃ y:OUT. OC(i,y) & ( t(g,y) | ¬ t(g,y)) • 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 transforma- tion. Extracted Algorithm: Let P 1 , P 2 be algorithms extracted from proofs of the subgoals, i.e. P 1 computes for i ∈ IN with IC ( i ) some g ∈ A with dom ( i, g ) and P 2 calculates for appropriate i, g some y ∈ OUT with OC ( i, y )&( t ( g, y ) |¬ t ( g, y )). Then for all i ∈ IN return P 2 ( i, P 1 ( i )). Higher abstraction desirable to strip off unimportant context

Proof of the GUESS Theorem ⊢ ∀ IN,OUT,A:TYPES. ∀ IC:FORMULAE(IN). ∀ OC:FORMULAE(IN#OUT). ∀ dom:FORMULAE(IN#A). ∀ t:FORMULAE(A#OUT). ∀ i:IN. IC(i) ⇒ ∃ y:OUT. OC(i,y) ⇐ ∀ i:IN. IC(i) ⇒ ∃ g:A. dom(i,g) ∀ i:IN. ∀ g:A. dom(i,g) ⇒ IC(i) ⇒ & ∃ y:OUT. OC(i,y) & ( t(g,y) | ¬ t(g,y)) Proof: Move all assumptions to the hypothesis list 1.-3. IN,OUT,A:TYPES 4. IC:FORMULAE(IN) 5. OC:FORMULAE(IN#OUT) 6. dom:FORMULAE(IN#A) 7. t:FORMULAE(A#OUT) ∀ i:IN. IC(i) ⇒ ∃ g:A. dom(i,g) 8. ∀ i:IN. ∀ g:A. dom(i,g) ⇒ IC(i) ⇒ 9. ∃ y:OUT. OC(i,y) & ( t(g,y) | ¬ t(g,y)) 10. i:IN 11. IC(i) ⊢ ∃ y:OUT. OC(i,y) Instantiate 8. on i (we show new hypotheses only) 12. ∃ g:A. dom(i,g) ⊢ ∃ y:OUT. OC(i,y) Eliminate 12. (give the existing object a name) 13. g:A 14. dom(i,g) ⊢ ∃ y:OUT. OC(i,y) Instantiate 9. on i, g , eliminate the result 15. ∃ y:OUT. OC(i,y) & ( t(g,y) | ¬ t(g,y)) 16. y:OUT 17. OC(i,y) ( t(g,y) | ¬ t(g,y)) 18. ⊢ ∃ y:OUT. OC(i,y) Choose the y in hypothesis 16 as solution.