Sparkle

1. Sparkle A theorem prover for the functional language Clean Maarten de Mol University of Nijmegen February 2002

2. Introduction • Sparkle: Yet Another Theorem Prover: • Design goals. • Why build a new theorem prover? • Short description of Sparkle: • Specification language (Clean). • Logic and semantics. • Tactic language. • Support for building proofs. • User interface. • Current status. Proof Tools Day 2002

3. Design goals • Basic idea: integrate theorem prover with a programming language. • Use theorem prover to annotate written programs with useful properties. • Goal: enhance programs. • Intended users: mainly programmers. • “Program” and “Prove”: same person. • Proving is side activity. • Important: small proofs should be easy. Proof Tools Day 2002

4. Why own theorem prover? • Integration with Clean: • Reason on source code level: • Semantics. • Syntax. • Project structure. • Store properties and proofs in programs. • Link theorem prover to existing tools, such as editor. • Distribute with Clean. Proof Tools Day 2002

5. Specification language • Clean: • Functional programming language. • Referential transparency allows equational reasoning. • Developed at University of Nijmegen. • Very similar to Haskell. • Some concepts: • Higher-order, curried and partial functions. • Lazy evaluation. • User-defined strict evaluation. • Sharing/Overloading / Comprehensions / Uniqueness. Proof Tools Day 2002

6. Example program map :: (a  b) [a]  [b] map f [x:xs] = [f x : map f xs] map f [] = [] increase :: [Int]  [Int] increase list = map (+ 1) list Proof Tools Day 2002

7. Partial functions • If in a program the expression “hd []” is evaluated, the program will terminate immediately (and an error message will be shown). hd :: [a]  a hd [x:xs] = x Proof Tools Day 2002

8. Lazy evaluation nats :: Int  [Int] nats n = [n: nats (n+1)] • Only parts of expressions that are really needed will actually be built. • Allows for infinite intermediate results: • Nothing wrong with using “hd (nats 7)”. • The evaluation of “last (nats 7)” will either ‘hang’ a program or halt it with an error message (out of resources). Proof Tools Day 2002

9. Strictness annotations hd :: ![a]  a hd [x:xs] = x K :: !a b  a K x y = y • Strictness annotations: argument must be reduced before function is entered. • Only changes reduction order. • May change termination properties. Proof Tools Day 2002

10. Logic • First-order propositional logic: • Basic units: True, False, e1 = e2, x. • Operators: , , , , . • Quantors: , . • No predicates allowed. • Quantification allowed over: • Expressions of arbitrary type. • Propositions. Proof Tools Day 2002

11. Semantics (1) • Total semantics: • The constant expression  is used to represent error values. • Reduction may have  as result: • The erronous application of a partial function leads to . • hd [] reduces to • Error values propagate stepwise to the outermost level: • (hd []) + 7reduces to + 7reduces to. Proof Tools Day 2002

12. Semantics (2) • Semantics of equality: • Based on reduction, but not dependent on reduction strategy. • Based on observations: • The observation of an expression is obtained by replacing all its redexes by . • e1 = e2 is true iff: • for all (e1reducesto r1) • there exists (e2reduces to r2) • such that r1 and r2 are observationally equal • (and vice-versa) Proof Tools Day 2002

13. Semantics (3) • Properties of equality: • Copes with finite equalities. • Copes with infinite equalities. • Copes with infinite reductions (equal to ). • Semantics of quantors: • All expressions of valid type may be substituted, including: • ‘infinite’ expressions. • the error value . Proof Tools Day 2002

14. Semantics: examples • xs ++ (ys ++ zs) = (xs ++ ys) ++ zs • True for all values of xs, ys and zs, including all finite values, all infinite values and . • reverse (reverse xs) = xs • True for all finite values of xs. • True for xs = . • Not true for any infinite values of xs. • xs = ones  last xs = 1 (ones = [1:ones]) • True for all values of xs, except: • Not true for xs = ones!! Proof Tools Day 2002

15. Tactics • Standard, borrowed from logic and other theorem provers: • Intros; Split; Apply; Rewrite; … • Special for Clean: • Induction. • Reduce; SplitCase; Case; ChooseCase; … • Only 42 in total; no high-level automated tactics available. Proof Tools Day 2002

16. Proving support • Command prompt. • Tactic list (prove by clicking). • Hint mechanism: • Sparkle automatically searches for applicable tactics. • A score is assigned to each hint. • Hints are displayed and can be applied: • Manually. • Automatically (with threshold). Proof Tools Day 2002

17. Current status • Alpha-version, but fully operational. • Released in Clean distribution: • http://www.cs.kun.nl/~clean • Tested on examples found in the book “Introduction to Functional Programming”: • Promising results: • Proofs were easily made in Sparkle. • Many proofs were found automatically by Sparkle. • Not tested yet by programmers. • Not tested yet on larger examples. • Largest program: 8Queens Proof Tools Day 2002

18. Future plans • Development on Sparkle continues. • User interface. • Tactical language. • Hint mechanism. • Enhance integration with Clean: • Allow properties to be specified in programs. • Allow proofs to be stored in programs. • Prove the (partial) correctness of a large application written in Clean. • Scalability? Proof Tools Day 2002