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

Progress on completing the trace monad rule set #667

Merged
merged 3 commits into from
Oct 5, 2023

Conversation

corlewis
Copy link
Member

@corlewis corlewis commented Aug 24, 2023

This fills out the rule set by copying in as many definitions and rules as possible from the nondet monad.

Note, for review purposes the first commit has been separated into two. The first commit currently seen here copies in verbatim from nondet monad and can be ignored. The second commit updates as required for the trace monad and the third is completely new content. Both should be reviewed as normal, although there is quite a bit of crossover between the second commit here and the first commit in #666.

@corlewis corlewis added the multicore anything related to multicore verification label Aug 24, 2023
@corlewis corlewis self-assigned this Aug 24, 2023
Copy link
Member

@lsf37 lsf37 left a comment

Choose a reason for hiding this comment

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

Nice!

lib/Monads/Fun_Pred_Syntax.thy Show resolved Hide resolved
lib/Monads/trace/Trace_Monad.thy Show resolved Hide resolved
@lsf37
Copy link
Member

lsf37 commented Aug 24, 2023

Should probably start making issues for this, but I think the next step would be to start on a Trace_RG_VCG theory. We could try to lift the existing hoare_vcg_* theorems via equivalence, but we'd only get them for R=G=True. With a bit of luck most of them will hold for arbitrary R and G, which would be nice to have.

We probably also want no_trace and prefix_closed proved of all monad primitives we have, so that these can be discharged completely automatically when they occur.

Looking at how equal all those existing proofs are to the nondet-monad it really is a bit of a shame that we can't do monads generically. I'm almost tempted to try some locales with way too general types that have large instantiations. One wouldn't get the definitions from the locales because of the too general types, but one could potentially get a lot of lemmas. They'd probably have large instantiations (all the definitions). Anyway. That one is lower priority -- the RG rules are not going to follow from the locales and those are the ones we really want to have in the end.

@corlewis
Copy link
Member Author

This PR now also copies empty_fail and its related proofs in from the nondet monad. While most of this was relatively easy to update for the trace monad, lemmas involving bind were a bit complicated and mk_ef was commented out, due to it requiring more thought about whether it makes sense to invent a (presumably empty) trace.

Copy link
Member

@lsf37 lsf37 left a comment

Choose a reason for hiding this comment

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

Thanks for adding those, that makes the setup more complete.


text \<open>Useful in forcing otherwise unknown executions to have the @{const empty_fail} property.\<close>
\<comment> \<open>definition mk_ef :: "'a set \<times> bool \<Rightarrow> 'a set \<times> bool" where
"mk_ef S \<equiv> (fst S, fst S = {} \<or> snd S)"\<close>
Copy link
Member

Choose a reason for hiding this comment

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

this appears commented out?

Copy link
Member Author

@corlewis corlewis Sep 27, 2023

Choose a reason for hiding this comment

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

Yes, I had commented it out due to it requiring more thought about how to define mk_ef for the trace monad. Thanks for getting me to look at it again though, I came up with a simple idea which while untested for use in proofs at least works for the basic empty_fail_mk_ef lemma.
See d026ada#diff-91fa50fb5dc2c82d728a640bb01749119aefd9da2a65256f460fe8b83c814a8fR24 for the new definition.

Collect generic empty_fail lemmas here:
- naming convention is emtpy_fail_NAME.
- add lemmas with assumptions to [empty_fail_cond] set
- add lemmas without assumption to [empty_fail_term] set
Copy link
Member

Choose a reason for hiding this comment

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

bit off-topic and beyond the scope of this PR, but would it be possible to write attributes that can check you're not putting the wrong thing into one of these sets, or automatically select which set to put it into?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ooh, interesting idea. That does feel possible, although I don't have experience with these lemma sets to know how they are used in practice and what the end result would be for us as users.

Copy link
Member

Choose a reason for hiding this comment

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

It's certainly possible to do, but the attribute(s) would be manually written ML code like [simp] and it would still be hard to prevent the user from just adding theorems to the set directly (without making it much harder to use, at least).

In terms of maintainability trade-off, the simple named-thms sets probably win out, because we don't usually dynamically add new stuff to these sets.

Copy link
Member

Choose a reason for hiding this comment

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

OK, if it's not going to get dynamically added to the wrong set by some future genius, then it's not worth it. Only wanted to point out that it's possible to programmatically check whether something has assumptions or not before the set add.


\<comment> \<open>lemma empty_fail_mk_ef[empty_fail_term]:
"empty_fail (mk_ef o m)"
by (simp add: empty_fail_def mk_ef_def)\<close>
Copy link
Member

Choose a reason for hiding this comment

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

any reason this one's commented out without a FIXME or indication of what to do?

Copy link
Member Author

Choose a reason for hiding this comment

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

It is uncommented out now that I have given mk_ef a new definition for the trace monad.

c \<leftarrow> C;
whileLoop (\<lambda>c s. c) (\<lambda>_. do B; C od) c;
return ()
od"
Copy link
Member

Choose a reason for hiding this comment

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

not sure about whether this is the PR for it, but these are not the new definition style, the wrapping is (as I was reminded recently):

definition name ::
  very_long_type
  where
  ...

Copy link
Member

@Xaphiosis Xaphiosis left a comment

Choose a reason for hiding this comment

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

Nice work!

This fills out the trace monad rule set by copying in as many
definitions and rules as possible from the nondet monad. Most of these
do not immediately work for the trace monad, see the next commit for the
required changes.

Signed-off-by: Corey Lewis <[email protected]>
This commit has all of the changes required so that the definitions and
rules added in the previous commit work for the trace monad.

Signed-off-by: Corey Lewis <[email protected]>
@corlewis corlewis merged commit 293b97c into seL4:master Oct 5, 2023
13 checks passed
@corlewis corlewis deleted the trace_more_rules branch October 5, 2023 00:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
multicore anything related to multicore verification
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants