Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
I
Iris
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Service Desk
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Incidents
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Rodolphe Lepigre
Iris
Commits
b1e67232
Commit
b1e67232
authored
Nov 26, 2017
by
David Swasey
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Adjust terminology and combine two changelog entries.
parent
1d9878b7
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
8 additions
and
9 deletions
+8
-9
CHANGELOG.md
CHANGELOG.md
+8
-9
No files found.
CHANGELOG.md
View file @
b1e67232
...
...
@@ -14,12 +14,14 @@ Changes in and extensions of the theory:
(defined in the logic of Iris using impredicative quantification).
*
Add a proof of the inverse of
`wp_bind`
.
*
Support verifying code that might get stuck by distinguishing
"progressive" vs. "non-progressive" weakest preconditions. (See
[Swasey et al. OOPSLA '17] for examples.) The progressive
`WP e @ E
{{ Φ }}`
ensures that, as
`e`
runs, it does not get stuck. The
non-progressive
`WP e @ E ?{{ Φ }}`
ensures that, as usual, all
invariants are preserved while
`e`
runs, but it permits execution to
get stuck. The former implies the latter.
"non-stuck" vs. "(potentially) stuck" weakest preconditions. (See
[Swasey et al. OOPSLA '17] for examples.) The non-stuck
`WP e @ E {{
Φ }}`
ensures that, as
`e`
runs, it does not get stuck. The stuck
`WP e @ E ?{{ Φ }}`
ensures that, as usual, all invariants are
preserved while
`e`
runs, but it permits execution to get stuck. The
former implies the latter. The full judgment is
`WP e @ s; E {{ Φ
}}`
, where non-stuck WP uses
*stuckness bit*
`s = not_stuck`
while
stuck WP uses
`s = maybe_stuck`
.
Changes in Coq:
...
...
@@ -104,9 +106,6 @@ sed 's/\bPersistentP\b/Persistent/g; s/\bTimelessP\b/Timeless/g; s/\bCMRADiscret
*
Move the
`prelude`
folder to its own project: std++
*
The rules
`internal_eq_rewrite`
and
`internal_eq_rewrite_contractive`
are now
stated in the logic, i.e. they are
`iApply`
friendly.
*
Use
*stuckness bits*
`s`
to define progressive vs. non-progressive
WP. The full judgment is
`WP e @ s; E {{ Φ }}`
; progressive WP uses
`s = not_stuck`
while non-progressive WP uses
`s = maybe_stuck`
.
*
Restore the original, stronger notion of atomicity alongside the
weaker notion. These are
`Atomic s e`
where the stuckness bit
`s`
indicates whether expression
`e`
is weakly (
`s = not_stuck`
) or
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment