Functional Programming with Isabelle/HOL e H O l L l e b - - PowerPoint PPT Presentation

Functional Programming with Isabelle/HOL

λ → ∀

=

I s a b e l l e

β α

H O L

Florian Haftmann Technische Universit¨ at M¨ unchen January 2009

Overview

Viewing Isabelle/HOL as a functional programming language:

• 1. Isabelle/HOL Specification Tools.
• 2. Code Generation from Isabelle/HOL-Theories.
• 3. Behind the Scene.

1 / 18

Overview

Viewing Isabelle/HOL as a functional programming language:

• 1. Isabelle/HOL Specification Tools.
• 2. Code Generation from Isabelle/HOL-Theories.
• 3. Behind the Scene.

Isabelle/HOL SML / OCaml / Haskell specification tools code generation

1 / 18

Isabelle/HOL specification tools

The definitional game

Aim: write “programs” in Isabelle/HOL as naturally as in, say, SML . . .

Isabelle/HOL specification tools 3 / 18

The definitional game

Aim: write “programs” in Isabelle/HOL as naturally as in, say, SML . . . but it’s not enough just to claim arbitrary things:

axiomatization nonsense :: nat ⇒ nat where nonsense-def : nonsense n = Suc (nonsense n)

Isabelle/HOL specification tools 3 / 18

The definitional game

Aim: write “programs” in Isabelle/HOL as naturally as in, say, SML . . . but it’s not enough just to claim arbitrary things:

axiomatization nonsense :: nat ⇒ nat where nonsense-def : nonsense n = Suc (nonsense n) lemma 0 = Suc 0 proof − from nonsense-def have nonsense 0 − nonsense 0 = Suc (nonsense 0) − nonsense 0 by simp then show 0 = Suc 0 by simp qed

Isabelle/HOL specification tools 3 / 18

The definitional game

Aim: write “programs” in Isabelle/HOL as naturally as in, say, SML . . . but it’s not enough just to claim arbitrary things:

axiomatization nonsense :: nat ⇒ nat where nonsense-def : nonsense n = Suc (nonsense n) lemma 0 = Suc 0 proof − from nonsense-def have nonsense 0 − nonsense 0 = Suc (nonsense 0) − nonsense 0 by simp then show 0 = Suc 0 by simp qed

Things have to be properly constructed, that is:

• Find an appropriate primitive definition.
• Derive desired specification (honest toil).

Specification tools automate this.

Isabelle/HOL specification tools 3 / 18

The Isabelle/HOL toolbox

Isabelle/HOL SML / OCaml / Haskell specification tools code generation inductive predicates Knaster-Tarski fixed point theorem inductive datatypes inductive predicate plus typedef primitive recursion primitive recursion combinator terminating functions explicit function graph plus definite choice

Isabelle/HOL specification tools 4 / 18

Type classes

Leightweight mechanism for overloading plus abstract specification. Example: algebra

Isabelle/HOL specification tools 5 / 18

Code generator basics

Code generation paradigms

proof extraction animates proof derivations in the spirit of the Curry- Howard isomorphism (cf. Coq)

Code generator basics 7 / 18

Code generation paradigms

proof extraction animates proof derivations in the spirit of the Curry- Howard isomorphism (cf. Coq) shallow embedding identifies term language of logic with term lan- guage of target language

Code generator basics 7 / 18

Code generation paradigms

proof extraction animates proof derivations in the spirit of the Curry- Howard isomorphism (cf. Coq) shallow embedding identifies term language of logic with term lan- guage of target language In the HOL tradition the second approach is favoured, Isabelle/HOL permits proof extraction, though.

Code generator basics 7 / 18

Code generation paradigms

proof extraction animates proof derivations in the spirit of the Curry- Howard isomorphism (cf. Coq) shallow embedding identifies term language of logic with term lan- guage of target language In the HOL tradition the second approach is favoured, Isabelle/HOL permits proof extraction, though. Isabelle/HOL SML / OCaml / Haskell specification tools code generation

Code generator basics 7 / 18

Code generation using shallow embedding

Correctness criterion: semantics of generated target language program P describes a term rewrite system where each derivation can be simulated in the theory Θ of the logic: sum [Suc Zero_nat, Suc Zero_nat] Suc (Suc Zero_nat)

datatype nat = Suc of nat | Zero_nat; fun plus_nat (Suc m) n = plus_nat m (Suc n) | plus_nat Zero_nat n = n; fun sum [] = Zero_nat | sum (m :: ms) = plus_nat m (sum ms);

t t u u E Θ E P code generation identification identification

Code generator basics 8 / 18

Code generation using shallow embedding

Correctness criterion: semantics of generated target language program P describes a term rewrite system where each derivation can be simulated in the theory Θ of the logic: sum [Suc Zero_nat, Suc Zero_nat] Suc (Suc Zero_nat)

datatype nat = Suc of nat | Zero_nat; fun plus_nat (Suc m) n = plus_nat m (Suc n) | plus_nat Zero_nat n = n; fun sum [] = Zero_nat | sum (m :: ms) = plus_nat m (sum ms);

t t u u E Θ E P code generation identification identification (partial correctness)

Code generator basics 8 / 18

Examples

• amortised queues
• amortised queues with poor man’s datatype abstraction
• algebra with type classes

Code generator basics 9 / 18

A closer look at code generation

How does a code generator look like?

A closer look at code generation 11 / 18

How does a code generator look like?

A closer look at code generation 11 / 18

Architecture

Isabelle/HOL tools Isabelle theory code equations intermediate language serialisation SML OCaml . . . Haskell selection preprocessing translation

A closer look at code generation 12 / 18

Intermediate language

purpose: add “structure” to bare logical equations

A closer look at code generation 13 / 18

Intermediate language

purpose: add “structure” to bare logical equations

data κ αk = f 1 of τ1 | . . . | f n of τn fun f :: ∀ α::sk. τ where f [α::sk] t1 = t1 | . . . | f [α::sk] tk = tk class c ⊆ c1 ∩ . . . ∩ cm where f 1 :: ∀ α. τ 1, . . ., f n :: ∀ α. τ n inst κ α::sk :: c where f 1 [κ α::sk] = t1, . . ., f n [κ α::sk] = tn

. . . a kind of “Mini-Haskell”

A closer look at code generation 13 / 18

Intermediate language

purpose: add “structure” to bare logical equations

data κ αk = f 1 of τ1 | . . . | f n of τn fun f :: ∀ α::sk. τ where f [α::sk] t1 = t1 | . . . | f [α::sk] tk = tk class c ⊆ c1 ∩ . . . ∩ cm where f 1 :: ∀ α. τ 1, . . ., f n :: ∀ α. τ n inst κ α::sk :: c where f 1 [κ α::sk] = t1, . . ., f n [κ α::sk] = tn

. . . a kind of “Mini-Haskell” . . . not “All-gol”, but “Thin-gol”

A closer look at code generation 13 / 18

Selecting

Two degrees of freedom: code equations by default: definition, primrec, fun, function explicitly: attribute [code] datatype constructors by default: datatype, record explicitly: code-datatype

A closer look at code generation 14 / 18

Preprocessing

Interface to plugin arbitrary theorem transformations: rewrites simpset function transformators theory -> thm list -> thm list

A closer look at code generation 15 / 18

Serialising

Adaption to target-language specifics:

• improving readability and aesthetics of generated code (bools, tuples,

lists, . . . )

• gaining efficiency (target-language integers)
• interface with language parts which have no direct counterpart in HOL

(imperative data structures)

A closer look at code generation 16 / 18

Serialising

Adaption to target-language specifics:

• improving readability and aesthetics of generated code (bools, tuples,

lists, . . . )

• gaining efficiency (target-language integers)
• interface with language parts which have no direct counterpart in HOL

(imperative data structures) . . . but: know what you are doing!

A closer look at code generation 16 / 18

Serialising

Adaption to target-language specifics:

• improving readability and aesthetics of generated code (bools, tuples,

lists, . . . )

• gaining efficiency (target-language integers)
• interface with language parts which have no direct counterpart in HOL

(imperative data structures) . . . but: know what you are doing! Remember the fundamental rule of software engineering: Don’t write your own foo; if you can, use somebody else’s.

A closer look at code generation 16 / 18

Serialising

Adaption to target-language specifics:

• improving readability and aesthetics of generated code (bools, tuples,

lists, . . . )

• gaining efficiency (target-language integers)
• interface with language parts which have no direct counterpart in HOL

(imperative data structures) . . . but: know what you are doing! Remember the fundamental rule of software engineering: Don’t write your own foo; if you can, use somebody else’s. foo ∈ { operating system, garabage collector, cryptographic algorithm, concurrency framework, theorem prover, . . . }

A closer look at code generation 16 / 18

Serialising

Adaption to target-language specifics:

• improving readability and aesthetics of generated code (bools, tuples,

lists, . . . )

• gaining efficiency (target-language integers)
• interface with language parts which have no direct counterpart in HOL

(imperative data structures) . . . but: know what you are doing! Remember the fundamental rule of software engineering: Don’t write your own foo; if you can, use somebody else’s. foo ∈ { operating system, garabage collector, cryptographic algorithm, concurrency framework, theorem prover, . . . } ∪ {serialisation}

A closer look at code generation 16 / 18

What remains

Not mentioned here

• implementing equality
• code extraction from proofs

Ongoing work and research

• turning inductive predicates into equations
• Haskabelle: importing Haskell files
• Quickcheck
• concept for datatype abstraction

Further reading

• Tutorials in the Isabelle distribution for functions, code generation

etc.

• PhD thesis on code generation (under heavy construction. . . )

. . .

A closer look at code generation 17 / 18

Happy proving, happy hacking Thanks for your attention