Hoare logic for higher order store using simple semantics Billiejoe (Nathaniel) Charlton University...

Preview:

Citation preview

Hoare logic for higher order store using simple semantics

Billiejoe (Nathaniel) Charlton

University of Sussex

WoLLIC 2011

Outline

• What is higher order store (HOS)?

- introduce a minimal programming language with HOS

Outline

• What is higher order store (HOS)?

- introduce a minimal programming language with HOS

• Show an existing Hoare logic for reasoning about this minimal HOS language (Reus and Streicher, ICALP 2005)

- Look at a correctness proof for a small program

Outline

• What is higher order store (HOS)?

- introduce a minimal programming language with HOS

• Show an existing Hoare logic for reasoning about this minimal HOS language (Reus and Streicher, ICALP 2005)

- Look at a correctness proof for a small program

• Point out some disagreeable things about Reus and Streicher’s logic

- These stem from the unnecessary use of domain theory

Outline

• What is higher order store (HOS)?

- introduce a minimal programming language with HOS

• Show an existing Hoare logic for reasoning about this minimal HOS language (Reus and Streicher, ICALP 2005)

- Look at a correctness proof for a small program

• Point out some disagreeable things about Reus and Streicher’s logic

- These stem from the unnecessary use of domain theory

• Give a simpler alternative construction which addresses these issues

- “Get a better logic for less work”

What is higher order store?

• A programming language is said to feature HOS when:

a program’s code / commands / procedures are part of the mutable store which the program manipulates as it runs

What is higher order store?

• A programming language is said to feature HOS when:

a program’s code / commands / procedures are part of the mutable store which the program manipulates as it runs

• So HOS programs can modify their own code while running

What is higher order store?

• A programming language is said to feature HOS when:

a program’s code / commands / procedures are part of the mutable store which the program manipulates as it runs

• So HOS programs can modify their own code while running

• Where does HOS occur?

- in functional languages with mutable state e.g. ML

- dynamic loading and unloading of code e.g. plugins

- “hot update” – updating a program while it is running

- runtime code generation

A minimal language with HOS

A minimal language with HOS

Quote turns a command, unexecuted, into a value which can be stored

A minimal language with HOS

Quote turns a command, unexecuted, into a value which can be stored

run command is used to invoke commands which were stored previously

• This program sets up a non-terminating recursion:

Example HOS programs

• This program sets up a non-terminating recursion:

• This is “recursion through the store” or “Landin’s knot” (which allegedly is one reason HOS causes complications)

Example HOS programs

• This program sets up a non-terminating recursion:

• This is “recursion through the store” or “Landin’s knot” (which allegedly is one reason HOS causes complications)

Example HOS programs

• This program sets up a non-terminating recursion:

• This is “recursion through the store” or “Landin’s knot” (which allegedly is one reason HOS causes complications)

• Here we store in x a command which will overwrite itself when run:

Example HOS programs

• This program sets up a non-terminating recursion:

• This is “recursion through the store” or “Landin’s knot” (which allegedly is one reason HOS causes complications)

• Here we store in x a command which will overwrite itself when run:

Example HOS programs

Reus and Streicher’s logic

Boils down to three new proof rules to deal with HOS (ICALP, 2005).

Main judgement used in proofs:

If k = 0 write . Let mean and .

Context consisting of a bunch of assumptions; each assumption is a Hoare triple

Hoare triple which holds in the given context

Proof rules for HOS

R = “Run”:Used when we know exactly which code we are going to invoke

Proof rules for HOS

H = “Hypothesis”:Allows us to use a hypothesis, from the context, about how some code works(p is an auxiliary variable)

Proof rules for HOS

mu for (mutual) recursion: when proving that C and D “work”, we can assume that recursive invocations of C and D “work”!

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Define:

Then the following program searches for a square root of m:

An example proof

Now we need to use the mu rule to deal with the recursion

An example proof

This is the instance to use:

Now we need to use the mu rule to deal with the recursion

An example proof

This is the instance to use:

Now we need to use the mu rule to deal with the recursion

To finish, we must prove the premises...

Finishing the proof

Finishing the proof

Finishing the proof

Finishing the proof

This is an instance of the H rule so we are done.

• Reus and Streicher (ICALP, 2005) proved rules R, H and mu sound.

• Their model looks like this:

• These equations are recursive so domain theory is used

Semantics using domain theory

Disagreeable aspects of existing work

However some things are not so nice:

1. Semantic setup is (relatively) complicated, due to domain theory

Disagreeable aspects of existing work

However some things are not so nice:

1. Semantic setup is (relatively) complicated, due to domain theory

2. Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts

Disagreeable aspects of existing work

However some things are not so nice:

1. Semantic setup is (relatively) complicated, due to domain theory

2. Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts

3. All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic

Disagreeable aspects of existing work

However some things are not so nice:

1. Semantic setup is (relatively) complicated, due to domain theory

2. Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts

3. All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic

4. Adding non-deterministic program statements breaks the theory

Disagreeable aspects of existing work

However some things are not so nice:

1. Semantic setup is (relatively) complicated, due to domain theory

2. Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts

3. All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic

4. Adding non-deterministic program statements breaks the theory

5. Testing syntactic equality between commands is not allowed

Disagreeable aspects of existing work

However some things are not so nice:

1. Semantic setup is (relatively) complicated, due to domain theory

2. Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts

3. All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic

4. Adding non-deterministic program statements breaks the theory

5. Testing syntactic equality between commands is not allowed

• Rest of this talk: Fix these issues with a simple construction.

• Stores and environments (for auxiliary variables) have simple types:

• (Syntactic) commands encoded using a bijection

• Evaluation of expressions:

Simpler semantics

• Small-step execution relation for commands:

Simpler semantics

• Small-step execution relation for commands:

Simpler semantics

• Small-step execution relation for commands:

Read integer value from the store,decode it back into a syntactic command, and run

Simpler semantics

• Assertions:

• Assertions:

• Interpretation is completely standard

• Assertions:

• Interpretation is completely standard

• Interpretation of Hoare triples:

means: in environment rho, any completed execution of e starting in a P-state, and containing n or fewer steps, ends in a Q-state.

• Assertions:

• Interpretation is completely standard

• Interpretation of Hoare triples:

Formally:

means: in environment rho, any completed execution of e starting in a P-state, and containing n or fewer steps, ends in a Q-state.

• Main judgement used in proofs:

• Main judgement used in proofs:

...then this triple holdsIf these triples hold...

• Main judgement used in proofs:

...then this triple holdsfor executions of n steps or fewer

If these triples hold...for executions of n - 1 steps or fewer

• Main judgement used in proofs:

...then this triple holdsfor executions of n steps or fewer

If these triples hold...for executions of n - 1 steps or fewer

Soundness of proof rules

Soundness of proof rules

Suppose that (1)

Need to prove that

Soundness of proof rules

Suppose that (1)

Need to prove that

So let be such that

in n steps or fewer.

Soundness of proof rules

Suppose that (1)

Need to prove that

So let be such that

in n steps or fewer.

Soundness of proof rules

Suppose that (1)

Need to prove that

So let be such that

in n steps or fewer.

We must have

where

Soundness of proof rules

Suppose that (1)

Need to prove that

So let be such that

in n steps or fewer.

We must have

where

To finish we can apply (1) to suffix

which has length n – 1

Soundness of proof rules

Proof is by induction on length of execution sequence. Define:

Inductive step requires proving

Give or take some fiddling with variables, the premise says this!

Roughly, “C and D work correctly for n steps”

Summary

• Explained an existing Hoare logic for reasoning about a minimal language with HOS

- This logic has some disagreeable aspects, stemming from the unnecessary use of domain theory

Summary

• Explained an existing Hoare logic for reasoning about a minimal language with HOS

- This logic has some disagreeable aspects, stemming from the unnecessary use of domain theory

• Gave a simpler alternative construction which addresses these issues

“Get a better logic for less work”

Summary

• Explained an existing Hoare logic for reasoning about a minimal language with HOS

- This logic has some disagreeable aspects, stemming from the unnecessary use of domain theory

• Gave a simpler alternative construction which addresses these issues

“Get a better logic for less work”

1. Semantic setup, and thus soundness proofs, are simple

2. Proof rules do not have inexplicable side-conditions

3. Non-deterministic program statements are supported

4. Testing syntactic equality between commands is permitted

The End

Recommended