CS 376 Programming with Abstract Data Types Ulrich Berger 1 - PDF document

CS 376 Programming with Abstract Data Types Ulrich Berger

1 Introduction This course is about the development of reliable software , i.e., computer programs that are (i) adequate , i.e. solve the customers problem, (ii) correct , i.e. are free of bugs and thus behave the way the programmer wants them to behave, (iii) easy to maintain , i.e. can be easily modified or ex- tended without introducing new errors.

It is estimated that presently 80% of the total time and money presently invested into software development is spent for finding errors and amending incorrect or poorly de- signed software. Therefore: we need better programming methodologies .

The program development methods studied in this course will mainly rely on • mathematical modelling • formal specification • formal reasoning

Other courses where these issues also played and will play an important role: • Modelling Computing Systems • Logic Programming • System Specification • Theory of Programming Languages • Logic and Foundations of Mathematics • Mathematics for Computation • Logic and Semantics • Functional Programming I,II • Interactive Theorem Proving • Concepts of Programming Languages • Algebraic Specification of Software and Hardware

Practical applications: • Implementation of ADTs in programming languages • Structuring of large software systems through ADTs • System support for the specification of ADTs • Industrially applied specification languages • Rapid prototyping • Program verification

Literature [1] J Loeckx, H-D Ehrich, M Wolf, Specification of Abstract Data Types Wiley/Teubner 1996. Theoretical foundations of ADTs , [2] K Meinke, J V Tucker, Universal Algebra, pp. 189- 411 in Handbook of Logic in Computer Science, OUP, 1992. Model-theoretic aspects [3] A Baader, T Nipkow, Term rewriting and all that, CUP, 1998. Algorithmic aspects

[4] N Dale, H M Walker, Abstract Data Types: Speci- fication, Implementations, and Applications, D C Heath Company, 1996. Applications in programming [5] D van Dalen, Logic and Structure, third edition, Springer, 1994. Logical foundations [6] A Eliens, Principles of Object-Oriented Software De- velopment, 2nd edition, Addison Wesley 2000. ADTs and Object Orientation [7] C Okasaki, Purely Functional data Structures, Cam- bridge, 1998. Implementation of ADTs

2 Formal Methods in Software Design • The software design process • An Example of Program Development • Programming by transformation • Programming by extraction from proofs

Conventional software design ❄ problem ✛ programming ❄ program maintenance compiling testing ❄ program in machine code executing ❄ results

Deficiencies: • Tests can only confirm the existence of errors, not their absence = ⇒ Testing fails to prove correctness • In testing results are compared with expectations (which might be wrong) ⇒ Inadequacies are not detected = 11

• Goal Avoid errors and inadequacies, or detect and correct them in an early stage of the design • Idea Formalize problem and derive program in controlled steps

Controlled program development ❄ ✛ problem ✛ ❄ rapid protot. informal spec. formalization ❄ formal specification ✛ ✛ program maintenance prog. verif. development ❄ program written in prog. lang. compiling ❄ program written in machine code executing testing ❄ results

1. Informal specification, abstract from unnecessary de- tails. 2. Formalisation. Formal specification possibly executable (rapid prototyping). Inadequacies of the specification are detected at an early stage. 3. Program development leads to a provably correct pro- gram. 4. Testing. 14

Example Problem Compute the gcd of two positive natural numbers m , n . Informal specification gcd ( m, n ) is a number k that divides m and n , such that if l is any other number l also dividing m and n then l divides k . Formal specification k = gcd ( m, n ) ↔ k | m ∧ k | n ∧ ∀ l ( l | m ∧ l | n → l | k ) k | m ↔ ∃ q k ∗ q = m Transformation Program extraction Prove the formula Formal specification 1 ∃ r [ r < n ∧ ∃ q m = q ∗ n + r ∧ ∀ m > 0 ∀ n > 0 ∃ k r = 0 → gcd ( m, n ) = n ∧ k | m ∧ k | n ∧ r > 0 → gcd ( m, n ) = gcd ( n, r ) ] ∀ l ( l | m ∧ l | n → l | k ) Extract from a formal proof Formal specification 2 mod ( m, n ) < n ∧ ∃ q [ m = q ∗ n + mod ( m, n ) ∧ a program gcd provably mod ( m, n ) = 0 → gcd ( m, n ) = n ∧ satisfying the specification. mod ( m, n ) > 0 → That is, the formula gcd ( m, n ) = gcd ( n, mod ( m, n )) ∀ m > 0 ∀ n > 0 Formal specification 3 gcd ( m, n ) | m ∧ gcd ( m, n ) | n ∧ m < n → mod ( m, n ) = m ∧ ∀ l ( l | m ∧ l | n → l | gcd ( m, n )) m ≥ n → mod ( m, n ) = mod ( m − n, n ) ∧ mod ( m, n ) = 0 → gcd ( m, n ) = n ∧ is provable mod ( m, n ) > 0 → gcd ( m, n ) = gcd ( n, mod ( m, n ))

Program function mod (m,n:integer, m,n > 0) : integer; begin if m < n then mod := m else mod := mod(m-n,n) end function gcd (m,n:integer, n > 0) : integer; begin r:= mod(m,n); if r=0 then gcd := n else gcd := gcd(n,r) end

Programming by transformation For correctness one needs to prove Formal specification ↑ Formal specification 1 ↑ Formal specification 2 ↑ Formal specification 3 Also, a proof is required that the derived program termi- nates on all legal inputs.

Formal specifications as they occurred in this example are called algebraic specifications because their natural interpretations are algebras. The class of models of an algebraic specification forms an Abstract Data Type (ADT) . In the literature (but not in this course) algebraic specifi- cations and abstract data types are often identified.

Program development using ADTs is a well-established tech- nique for producing reliable software. Main methodological principles: • Abstraction: The description of unnecessary details is avoided. • Modularisation The programming task is divided into small manageable pieces that can be solved inde- pendently.

Program Extraction from Proofs 1. Programming problem is given in the form ∀ x ∃ y A ( x, y ) 2. Find a constructive formal proof of ∀ x ∃ y A ( x, y ) 3. Extract (automatically) program p from the proof that provable meets the specification: ∀ x A ( x, p ( x ))

Constructive proofs • Introduced by Kronecker, Brouwer and Kolmogorov • Formalization by Heyting • Algorithmic interpretation of constructive proofs is called – BHK-interpretation – Curry-Howard-interpretation – proofs-as-programs paradigm formula ≡ data type constructive proof of formula A ≡ program of type A

Proof calculus studied in this course: Natural Deduction Systems supporting program extraction from proofs: Agda, Coq, Fred, Minlog, NuPrl, PX, . . .

3 Logic • Signatures and algebras • Terms and Formulas and their Semantics • Logical Consequence, Validity, Satisfiability • Undecidability of Validity • Substitutions • Other Logics 23

Signatures A many-sorted signature is a pair Σ = ( S, Ω) such that • S is a set of sorts • Ω is a set of operations • Operations are of the form f : s 1 × . . . × s n → s, where s 1 × . . . × s n → s is called arity of f , with argument sorts s 1 , . . . , s n and tar- get sort s . 24

Algebras A many-sorted algebra A for a signature Σ = ( S, Ω) is given by the following. • For each sort s in S a nonempty set A s , the carrier set of sort s . • For each constant c : s in Ω, that is operation with arity → s , an element c A ∈ A s . • For each operation f : s 1 × . . . × s n → s in Ω a function f A : A s 1 × . . . × A s n → A s 25

Example Σ Signature nat , boole Sorts 0: nat , T: boole , F: boole Constants Operations add: nat × nat → nat ≤ : nat × nat → boole 26

Algebra A Carriers N , B 0 , T , F Constants Operations +: N × N → N ≤ : N × N → B N := { 0 , 1 , 2 , . . . } B := { T , F } 27

Algebra B N + , B Carriers 1, T, F Constants Operations ∗ : N + × N + → N + | : N + × N + → B m | n : ⇔ m divides n 28

Terms Let Σ = ( S, Ω) be a signature, and let for every sort s ∈ S a set X s of variables be given. Σ - terms and their sorts are defined by the fol- lowing rules. (i) Every variable x ∈ X s is a term of sort s . (ii) Every constant c in Σ of sort s is a term of sort s . (iii) If f : s 1 × . . . × s n → s is an operation in Σ, and t 1 , . . . , t n are terms of sorts s 1 , . . . , s n , respectively, then f ( t 1 , . . . , t n ) is a term of sort s . 29

• The set of all terms of sort s with variables in X is denoted by T(Σ , X ) s . • A term is closed if it doesn’t contain vari- ables, i.e. is built without the use of rule (i). • The set of all closed terms of sort s is denoted by T(Σ) s . • Clearly T(Σ) s = T(Σ , ∅ ) s . 30

Examples of terms x 0 add(0 , y ) add(add(0 , x ) , y ) add(add(0 , 0) , add( x, x )) add(0 , add(0 , add(0 , 0))) Which of these terms are closed? 31