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

▶
towards a formal theory of program construction
SMART_READER_LITE
LIVE PREVIEW

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

Aug 18, 2023 180 likes •402 views

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

slide-1
SLIDE 1

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

slide-2
SLIDE 2

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

  • n a higher level of abstraction
slide-3
SLIDE 3

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.

slide-4
SLIDE 4

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.

slide-5
SLIDE 5

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).

slide-6
SLIDE 6

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 : 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. 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.

slide-7
SLIDE 7

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¨
  • f’s Type Theory
slide-8
SLIDE 8

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

if a ∈ A, b ∈ B

A ∧B A|B inl(a), inr(b)

if a ∈ A, b ∈ B

A ∨B A → B λx.b

if b ∈ B

A ⇒ B A list nil, a.l

if a ∈ A, l ∈ A list

x : A#B a, b

if a ∈ A, b ∈ B[a/x]

∃x:A.B x : A → B λx.b

if b ∈ B[x]

∀x:A.B {x : A|B} a

if a ∈ A, B[a/x]

x, y : A//B a

if a ∈ A (Equality changed: a = a′ iff B[a, a′/x, y] )

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 U1 atomic types all that can be constructed via type constructors. U2 U1, members of U1, and all that can be constructed via type constructors. U3 U2,........

slide-9
SLIDE 9

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.)

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

slide-10
SLIDE 10

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

  • utput 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.

slide-11
SLIDE 11

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

  • utput. 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 P1, 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 2calculates for appropriate i, g some y ∈ OUT with OC(i, y)&(t(g, y)|¬t(g, y)). Then for all i ∈ IN return P2(i, P1(i)).

Higher abstraction desirable to strip off unimportant context

slide-12
SLIDE 12

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) 8. ∀i:IN. IC(i) ⇒ ∃g:A. dom(i,g) 9. ∀i:IN.∀g:A. dom(i,g) ⇒ IC(i) ⇒ ∃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) 18. ( t(g,y) | ¬t(g,y)) ⊢ ∃y:OUT. OC(i,y) Choose the y in hypothesis 16 as solution.

slide-13
SLIDE 13

GUESS-Postprocessing

Normalize (GET-DNF):

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

Cases Splitting scheme

⊢ ∀ A,B,p:Umax. ( A | B ) ⇐ (p | ¬p) & (p ⇒ A & ¬p ⇒ B ) Extracted algorithm: Let P 1 decide p|¬p, P 2 compute a proof for A from one for p, and P 3 prove B from ¬p. If P 1 decides for p return P2(p1) as a witness for A. Return P3(p1) proving B, otherwise.

Cases Splitting instantiated to the result of GUESS

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

slide-14
SLIDE 14

An Example for GET-REC

ByA STRUCT denote a recursive type of structures generalizing Graphs, Trees, Sets, Lists, .. over A, base be a zero objectA STRUCT (e.g. the empty graph) and S \x result the structured object S reduced by x ∈ A (e.g. a node is taken out of some graph).

Recursion scheme: taking out one element - precondition fixed

⊢ ∀A:TYPES.∀P, pre:FORMULAE(A STRUCT # A). ∀i:A Struct.∀g:A. pre(i,g) ⇒ P(i,g) ⇐ ∀i:A Struct.∀g:A. pre(i,g) ⇒ P(base,g) & ∀i:A Struct.∀g:A. pre(i,g) ⇒ (P(i\g,g) ⇒ P(i,g)) Extracted Algorithm: Let P 1 compute a solution for the base case, P 2 one for i from a solution for i\g. Compute a solution for i by recursively applying P 2 to previous results until the base case P 1 is reached.

Instantiating the above with the result of simple guessing:

⊢ ∀OUT:TYPES.∀IC:FORMULAE(OUT STRUCT).∀OC:FORMULAE(OUT STRUCT#OUT). ∀dom:SUB-FORMULAE(OC,OUT STRUCT#OUT). ∀i:OUT STRUCT.∀g:OUT. dom(i,g) ⇒ ¬p(i,g) ⇒ IC(i) ⇒ ∃y:OUT. OC(i,y) & ¬g=y ⇐ ∀i:OUT STRUCT.∀g:OUT. dom(i,g) ⇒ ¬p(i,g) ⇒ IC(base) ⇒ ∃y:OUT. OC(base,y) & ¬g=y & ∀i:OUT STRUCT.∀g:OUT. dom(i,g) ⇒ ¬p(i,g) ⇒ (IC(i) ⇒ ∃y:OUT. OC(i,y) & ¬g=y ⇐ IC(i\g) ⇒ ∃y:OUT. OC(i\g,y) & ¬g=y ) with p := OC\dom in T f subformula of F in T

≡∃p:FORMULAE(T). ∀x:T. (p(x) & f(x) ⇔ F(x))

SUB-FORMULAE(F,T)

≡{f:FORMULAE(T) | f subformula of F in T}

F\f in T

≡first(f subformula of F in T)

slide-15
SLIDE 15

Program Construction Concepts

SPECIFICATIONS

≡IN:TYPES # OUT:TYPES

# FORMULAE (IN) # FORMULAE (IN#OUT) PROGRAMS

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

FULFILLS (spec, program)

≡IN(spec) = IN(program) in TYPES

& OUT(spec) = OUT(program) in TYPES & ∀x:IN(spec). IC(spec)(x) ⇒ IOR(spec)(x, body(program)(x)) SOLUTIONS(spec)

≡{p:PROGRAMS | FULFILLS(spec, p)}

SOLVABLE(spec)

≡∃p:PROGRAMS. FULFILLS(spec, p)

SYNTHSPEC

≡<SPECIFICATIONS, PROGRAMS, problem-class,

λp,spec.FULFILLS(spec,p)> SYNTHESIZERS

≡{synth:SPECIFICATIONS->PROGRAMS

|∀spec:SPECIFICATIONS. problem-class(spec) ⇒ FULFILLS(spec,synth(spec))}

The same for multivalued programs

M-PROGRAMS

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

M-FULFILLS (spec,p)

≡IN(spec) = IN(p) in TYPES

& OUT(spec) = OUT(p) in TYPES &∀x:IN(spec). IC(spec)(x) ⇒ body(p)(x) = {y:OUT(spec)|IOR(spec)(x,y)} M-SOLUTIONS(spec)

≡{p:M-PROGRAMS | M-FULFILLS (spec, p) }

M-SOLVABLE(spec)

≡∃p:M-PROGRAMS. M-FULFILLS(spec, p)

slide-16
SLIDE 16

AE Approaches to program synthesis

Given a specification < IN, OUT, IC, IOR > Extract a program from a constructive proof for ∀x : IN.∃y : OUT. IC(x) ⇒ IOR(x, y) Representation formally justified:

⊢ ∀spec: SPECIFICATIONS. ∀x:IN(spec).∃y:OUT(spec). IC(spec)(x) ⇒ IOR(spec)(x,y) ⇔ SOLVABLE( spec ) ⊢ ∀spec: SPECIFICATIONS. ∀x:IN(spec).∃o:P(OUT(spec)). IC(spec)(x) ⇒ o={y:OUT(spec)|IOR(spec)(x,y)} ⇔ M-SOLVABLE( spec ) By applying these theorems one may switch representations.

Correctness of the deduction method: Unquestionable, provided a proof is correct.

slide-17
SLIDE 17

Transformation based approaches

Given a specification < IN, OUT, IC, IOR > Define a new 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 computationally convenient. Representation formally justified: Instead of a predicative program P(x, y) use a multivalued function p with body(p)(x) := {y : OUT(p)|P(x, y)}. A proof that such a program can be defined:

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

This is exactly the same as showing M-SOLVABLE(<IN, OUT, IC, IOR>). Correctness of the deduction method:

⊢ ∀IN,OUT:TYPES.∀IC:FORMULAE(IN).∀ior,ior’:FORMULAE(IN#OUT). ∃p:M-PROGRAMS.∀x:IN(p). IC(x) ⇒ body(p)(x)={y:OUT(p)|ior(x,y)} ⇐ ∃p:M-PROGRAMS.∀x:IN(p). IC(x) ⇒ body(p)(x)={y:OUT(p)|ior’(x,y)} & ∀x:IN.∀y:OUT. IC(x) ⇒ (ior’(x,y) ⇔ ior(x,y) ) Still too much context hiding the true effect. Formalize the essence of the theorem.

slide-18
SLIDE 18

Transformations as types

T is a transformation

≡∀s:SPECIFICATIONS.

IN(T(s))=IN(s) in TYPES & OUT(T(s))=OUT(s) in TYPES & IC(T(s))=IC(s) in TYPES TRANSFORMATIONS

≡{t:SPECIFICATIONS->SPECIFICATIONS |

t is a transformation} T correctness preserving

≡∀s:SPECIFICATIONS.∀x:IN(s).∀y:OUT(s).

IC(s)(x) ⇒ (IOR(s)(x,y) ⇐ IOR(T(s))(x,y)) T equivalence preserving

≡∀s:SPECIFICATIONS.∀x:IN(s).∀y:OUT(s).

IC(s)(x) ⇒ (IOR(s)(x,y) ⇔ IOR(T(s))(x,y)) C-TRANSFORMATIONS

≡{t:TRANSFORMATIONS|

T correctness preserving} EQ-TRANSFORMATIONS

≡{t:TRANSFORMATIONS|

T equivalence preserving}

Correctness of transformations clarified:

⊢ ∀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)) For each transformation these meta-theorems return verified deduction rules for program synthesis based on applying T.

slide-19
SLIDE 19

Example: GUESS as transformation

T guess(A,dom,t)(<IN,OUT,IC,IOR>) ⇔ <IN, OUT, IC, λi,y.∀g:A. dom(i,g) ⇒ IOR(i,y) & (t(g,y)|¬t(g,y))>

GUESS-Theorem

⊢ ∀spec:SPECIFICATIONS.∀A:TYPES.∀dom:FORMULAE(IN(spec)#A). SOLVABLE(<IN(spec),A,IC(spec),dom>) ⇒ ∀t:FORMULAE(A#OUT(spec)). T guess(A,dom,t) in C-TRANSFORMATIONS & ∀t:DFORMULAE(A#OUT(spec)). T guess(A,dom,t) in EQ-TRANSFORMATIONS The previous version is a corollary of this theorem and the above justification theorems:

  • By the above theorem T guess is verified as C-/EQ-Transformation.
  • With the justification of transformation based methods we get an deduction rule

(metatheorem) for each C-/EQ-Transformation.

  • With the AE-justification theorem we may change representations between the

SOLVABLE predicate and the AE form.

slide-20
SLIDE 20

Characteristics of the Theory

  • A unified framework for reasoning about programs and program

construction, propositions and proofs.

  • Built on top of Type Theory.
  • Concepts developed here can be straightforwardly implemented

with NuPRL.

  • Expressive, high level of abstraction.
  • Explicit Knowledge in (Meta-)Theorems.
  • Intellegible Proofs: Supports proof/program development close to

human-reasoning style.

  • Emphasis on correctness, uniformity, clarity, and short derivations

rather than on efficient proof search. Suitable for Interactive Reasoning Lots of details need to be filled in.

Open Question: How to hide as much formalism as possible (using NuPRL’s defini- tion facility) to have a formal theory (with mechanized proofs) intellegible for humans (not just NuPRL-Experts).