Skip to content
Snippets Groups Projects
  1. Feb 03, 2021
  2. Jan 19, 2021
  3. Jan 07, 2021
  4. Nov 11, 2020
  5. Nov 10, 2020
  6. Nov 04, 2020
  7. Nov 03, 2020
  8. Sep 29, 2020
  9. Sep 16, 2020
  10. Sep 10, 2020
  11. May 28, 2020
  12. Apr 07, 2020
  13. Mar 16, 2020
  14. Feb 11, 2020
  15. Sep 13, 2019
    • Jacques-Henri Jourdan's avatar
      Reorder Requires so that we do not depend of Export bugs. · 43a1a90f
      Jacques-Henri Jourdan authored
      The general idea is to first import/export modules which are further
      than the current one, and then import/export modules which are close
      dependencies.
      
      This commit tries to use the same order of imports for every file, and
      describes the convention in ProofGuide.md. There is one exception,
      where we do not follow said convention: in program_logic/weakestpre.v,
      using that order would break printing of texan triples (??).
      43a1a90f
  16. May 24, 2019
    • Robbert Krebbers's avatar
      More consistent naming for `auth`. · 597ec42e
      Robbert Krebbers authored
      This MR is a follow up on the renamings performed (implicitly) as part of
      !215. This MR makes the following changes:
      
      - `auth_both_frac_valid` and `auth_both_valid` are now of the same shape
        as `auth_both_frac_validN` and `auth_both_validN`. That is, both are
        now biimplications.
      - The left-to-right  direction of `auth_both_frac_valid` and
        `auth_both_valid` only holds in case the camera is discrete. The
        right-to-left versions for non-discrete cameras are prefixed `_2`, the
        convention that we use throughout the development.
      - Change the direction of lemmas like `auth_frag_valid` and
        `auth_auth_valid` so that it's consistent with the other lemmas. I.e.
        make sure that the ◯ and ● are always on the LHS of the biimplication.
      597ec42e
  17. May 23, 2019
  18. Mar 06, 2019
  19. Mar 05, 2019
  20. Jan 24, 2019
  21. Apr 26, 2018
  22. Apr 25, 2018
  23. Oct 30, 2017
  24. Oct 25, 2017
  25. Sep 17, 2017
  26. Aug 17, 2017
  27. Jun 08, 2017
  28. Mar 24, 2017
    • Robbert Krebbers's avatar
      Generic big operators that are no longer tied to CMRAs. · 6fbff46e
      Robbert Krebbers authored
      Instead, I have introduced a type class `Monoid` that is used by the big operators:
      
          Class Monoid {M : ofeT} (o : M → M → M) := {
            monoid_unit : M;
            monoid_ne : NonExpansive2 o;
            monoid_assoc : Assoc (≡) o;
            monoid_comm : Comm (≡) o;
            monoid_left_id : LeftId (≡) monoid_unit o;
            monoid_right_id : RightId (≡) monoid_unit o;
          }.
      
      Note that the operation is an argument because we want to have multiple monoids over
      the same type (for example, on `uPred`s we have monoids for `∗`, `∧`, and `∨`). However,
      we do bundle the unit because:
      
      - If we would not, the unit would appear explicitly in an implicit argument of the
        big operators, which confuses rewrite. By bundling the unit in the `Monoid` class
        it is hidden, and hence rewrite won't even see it.
      - The unit is unique.
      
      We could in principle have big ops over setoids instead of OFEs. However, since we do
      not have a canonical structure for bundled setoids, I did not go that way.
      6fbff46e
  29. Mar 21, 2017
  30. Jan 27, 2017
  31. Jan 09, 2017
  32. Jan 06, 2017
  33. Jan 05, 2017
  34. Jan 03, 2017
  35. Dec 09, 2016
Loading