-
Notifications
You must be signed in to change notification settings - Fork 23
Add Validatable trait #329
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
Changes from all commits
2a827ac
4069d96
c1e56a8
7adca18
bd48a1f
e1f4fe9
26d30ec
d476453
20e91cd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,45 @@ include "UInt.dfy" | |
| module {:extern "STL"} StandardLibrary { | ||
| import opened U = UInt | ||
|
|
||
| // A trait for objects with a Valid() predicate. Necessary in order to | ||
| // generalize some proofs, but also useful for reducing the boilerplate | ||
| // that most such objects need to include. | ||
| trait {:termination false} Validatable { | ||
| // TODO-RS: The style guide actually implies this should be "repr", | ||
| // but the convention is well-established at this point. | ||
| ghost var Repr: set<object> | ||
|
|
||
| predicate Valid() | ||
| reads this, Repr | ||
| ensures Valid() ==> this in Repr | ||
|
|
||
| // Convenience predicate for when your object's validity depends on one | ||
| // or more other objects. | ||
| predicate ValidComponent(component: Validatable) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Having convenience predicates like this is fantastic! |
||
| reads this, Repr | ||
| ensures ValidComponent(component) ==> ( | ||
| && component in Repr | ||
| && component.Repr <= Repr | ||
| && this !in component.Repr | ||
| && component.Valid()) | ||
|
Comment on lines
+25
to
+29
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This postcondition is not necessary, since it just restates the body and functions are transparent (non-opaque) in Dafny (unless you limit visibility with an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was convinced this was necessary for validation for some reason, perhaps it was confounded with whatever the real fix was. Will try removing. |
||
| { | ||
| && component in Repr | ||
| && component.Repr <= Repr | ||
| && this !in component.Repr | ||
| && component.Valid() | ||
| } | ||
|
|
||
| // Convenience predicate, since you often want to assert that | ||
| // new objects in Repr are fresh as well. | ||
| // TODO-RS: Better name? | ||
| twostate predicate ValidAndFresh() | ||
| reads this, Repr | ||
| ensures ValidAndFresh() ==> Valid() && fresh(Repr - old(Repr)) | ||
|
Comment on lines
+39
to
+42
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a benefit to writing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's questionable whether this is worth the trouble. I definitely DON'T think just "Fresh" is the right word anyway, so I'd rather come up with better or just drop this predicate. I'm more just observing this is a very common pattern. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ditto. This postcondition is not necessary. |
||
| { | ||
| Valid() && fresh(Repr - old(Repr)) | ||
| } | ||
| } | ||
|
|
||
| // TODO: Depend on types defined in dafny-lang/libraries instead | ||
| datatype Option<+T> = None | Some(get: T) | ||
| { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should update the style guide. I suggest it be updated to say that "public" fields (or, at least, public ghost fields) be capitalized, where "public" means "intended to be used and understood by clients".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should that also align with the set of symbols you export then?