1 / 64

Hoare logic for higher order store using simple semantics

Billiejoe (Nathaniel) Charlton University of Sussex. Hoare logic for higher order store using simple semantics. WoLLIC 2011. Outline. What is higher order store (HOS) ? introduce a minimal programming language with HOS. Outline. What is higher order store (HOS) ?

didier
Download Presentation

Hoare logic for higher order store using simple semantics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Billiejoe (Nathaniel) Charlton University of Sussex Hoare logic for higher order store using simple semantics WoLLIC 2011

  2. Outline • What is higher order store (HOS)? • introduce a minimal programming language with HOS

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

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

  5. 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”

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

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

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

  9. A minimal language with HOS

  10. A minimal language with HOS Quote turns a command, unexecuted, into a value which can be stored

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

  12. Example HOS programs • This program sets up a non-terminating recursion:

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

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

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

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

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

  18. Proof rules for HOS R = “Run”: Used when we know exactly which code we are going to invoke

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

  20. 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”!

  21. An example proof Define: Then the following program searches for a square root of m:

  22. An example proof Define: Then the following program searches for a square root of m:

  23. An example proof Define: Then the following program searches for a square root of m:

  24. An example proof Define: Then the following program searches for a square root of m:

  25. An example proof Define: Then the following program searches for a square root of m:

  26. An example proof Define: Then the following program searches for a square root of m:

  27. An example proof Define: Then the following program searches for a square root of m:

  28. An example proof Now we need to use the mu rule to deal with the recursion

  29. An example proof Now we need to use the mu rule to deal with the recursion This is the instance to use:

  30. An example proof Now we need to use the mu rule to deal with the recursion This is the instance to use: To finish, we must prove the premises...

  31. Finishing the proof

  32. Finishing the proof

  33. Finishing the proof

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

  35. Semantics using domain theory • Reus and Streicher (ICALP, 2005) proved rules R, H and mu sound. • Theirmodel looks like this: • These equations are recursive so domain theory is used

  36. Disagreeable aspects of existing work • However some things are not so nice: • Semantic setup is (relatively) complicated, due to domain theory

  37. Disagreeable aspects of existing work • However some things are not so nice: • Semantic setup is (relatively) complicated, due to domain theory • Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts

  38. Disagreeable aspects of existing work • However some things are not so nice: • Semantic setup is (relatively) complicated, due to domain theory • Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts • All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic

  39. Disagreeable aspects of existing work • However some things are not so nice: • Semantic setup is (relatively) complicated, due to domain theory • Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts • All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic • Adding non-deterministic program statements breaks the theory

  40. Disagreeable aspects of existing work • However some things are not so nice: • Semantic setup is (relatively) complicated, due to domain theory • Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts • All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic • Adding non-deterministic program statements breaks the theory • Testing syntactic equality between commands is not allowed

  41. Disagreeable aspects of existing work • However some things are not so nice: • Semantic setup is (relatively) complicated, due to domain theory • Thus soundness proofs are (relatively) complicated, depending on domain-theoretic results by Andrew Pitts • All three new rules have inexplicable “downwards closure” side-conditions (not shown in this talk) where the domain theory leaks out into the logic • Adding non-deterministic program statements breaks the theory • Testing syntactic equality between commands is not allowed • Rest of this talk: Fix these issues with a simple construction.

  42. Simpler semantics • Stores and environments (for auxiliary variables) have simple types: • (Syntactic) commands encoded using a bijection • Evaluation of expressions:

  43. Simpler semantics • Small-step execution relation for commands:

  44. Simpler semantics • Small-step execution relation for commands:

  45. Simpler semantics • Small-step execution relation for commands: Read integer value from the store, decode it back into a syntactic command, and run

  46. Assertions:

  47. Assertions: • Interpretation is completely standard

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

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

  50. Main judgement used in proofs:

More Related