Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Double Ended Queue example to tutorial #67

Draft
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

elaustell
Copy link
Collaborator

This example combines ideas from the imperative queue and doubly linked list for an even more complicated structure. Verifying this data structure includes proving equivalence of different predicates (i.e. if I "own" the queue in the forwards direction, then I "own" it in the backwards direction). As far as I know, this is the only example of proving predicates equivalent. It also shows a great example of proof by induction about ownership done entirely in CN itself.

This definitely needs a read through before it is merged. It is a convoluted example, so I'm sure I didn't explain it entirely well on the first try.

Copy link
Collaborator

@dc-mak dc-mak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looking good, thanks for this. Got a few questions/clarifications, comments in line.


=== Double Ended Queues

We have already seen an implementation of a single ended and a doubly linked list in CN. Now we can combine those ideas into a double ended queue. This is a list that allows for O(1) operations for adding or removing elements from either end of the list. Here is the C type definition:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all queues (including the earlier one) are double ended so this sentence will need some adjustment.

Comment on lines +1 to +20
/* A version of doubly linked lists that is essentially from Reynold's
original separation logic paper (https://www.cs.cmu.edu/~jcr/seplogic.pdf).
Page 10 has his definition of doubly-linked lists (dlist).

They're slightly different from ours in that they're "open":
there's no special treatment of null for the front of the list.

Technical note for the future: We could eliminate the hacky
assert_not_equal reasoning if we added this lemma:

lemma assert_not_equal (p, prev, cur, f, b)
requires Own_Fwd(prev, cur, f, b);
Owned<struct node>(p);
ensures Own_Fwd(prev, cur, f, b);
Owned<struct node>(p);
!ptr_eq(p,b);

This more specific lemma is something we could actually
(eventually) prove in Rocq, as an inductive fact derived from the
resource predicate definition. */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also eliminate the lemma if the ownership of Back was taken eagerly, as in the queue example. One would simply need to pass the Back node struct value down into the predicate so that it can be appropriately constrained in the base case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is not mentioned in the tutorial. And the files that are mentioned don't have the assert_not_equal lemmas in them. Can you please explain?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is all still WIP...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a bunch of writing / polishing / adding stuff still to do.

@dc-mak dc-mak marked this pull request as draft August 13, 2024 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants