Skip to content
Snippets Groups Projects
  1. Sep 19, 2019
  2. 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
  3. Aug 13, 2019
  4. Jun 16, 2019
    • Robbert Krebbers's avatar
      Replace `C`s with `O`s since we use OFEs instead of COFEs. · 2855d1f5
      Robbert Krebbers authored
      Used the following script:
      
      sed '
      s/\bCofeMor/OfeMor/g;
      s/\-c>/\-d>/g;
      s/\bcFunctor/oFunctor/g;
      s/\bCFunctor/OFunctor/g;
      s/\b\%CF/\%OF/g;
      s/\bconstCF/constOF/g;
      s/\bidCF/idOF/g
      s/\bdiscreteC/discreteO/g;
      s/\bleibnizC/leibnizO/g;
      s/\bunitC/unitO/g;
      s/\bprodC/prodO/g;
      s/\bsumC/sumO/g;
      s/\bboolC/boolO/g;
      s/\bnatC/natO/g;
      s/\bpositiveC/positiveO/g;
      s/\bNC/NO/g;
      s/\bZC/ZO/g;
      s/\boptionC/optionO/g;
      s/\blaterC/laterO/g;
      s/\bofe\_fun/discrete\_fun/g;
      s/\bdiscrete\_funC/discrete\_funO/g;
      s/\bofe\_morC/ofe\_morO/g;
      s/\bsigC/sigO/g;
      s/\buPredC/uPredO/g;
      s/\bcsumC/csumO/g;
      s/\bagreeC/agreeO/g;
      s/\bauthC/authO/g;
      s/\bnamespace_mapC/namespace\_mapO/g;
      s/\bcmra\_ofeC/cmra\_ofeO/g;
      s/\bucmra\_ofeC/ucmra\_ofeO/g;
      s/\bexclC/exclO/g;
      s/\bgmapC/gmapO/g;
      s/\blistC/listO/g;
      s/\bvecC/vecO/g;
      s/\bgsetC/gsetO/g;
      s/\bgset\_disjC/gset\_disjO/g;
      s/\bcoPsetC/coPsetO/g;
      s/\bgmultisetC/gmultisetO/g;
      s/\bufracC/ufracO/g
      s/\bfracC/fracO/g;
      s/\bvalidityC/validityO/g;
      s/\bbi\_ofeC/bi\_ofeO/g;
      s/\bsbi\_ofeC/sbi\_ofeO/g;
      s/\bmonPredC/monPredO/g;
      s/\bstateC/stateO/g;
      s/\bvalC/valO/g;
      s/\bexprC/exprO/g;
      s/\blocC/locO/g;
      ' -i $(find theories -name "*.v")
      2855d1f5
  5. Jun 03, 2019
  6. Mar 06, 2019
  7. Mar 05, 2019
  8. Mar 04, 2019
  9. Feb 18, 2019
  10. Dec 10, 2018
  11. Nov 26, 2018
  12. Nov 06, 2018
  13. Nov 01, 2018
  14. Oct 04, 2018
  15. Jul 31, 2018
  16. May 17, 2018
  17. Feb 20, 2018
  18. Nov 29, 2017
  19. Oct 25, 2017
  20. Sep 21, 2017
  21. Sep 17, 2017
  22. Aug 17, 2017
  23. Apr 07, 2017
  24. 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
  25. Feb 09, 2017
  26. Feb 06, 2017
  27. Feb 03, 2017
  28. Feb 01, 2017
    • Jacques-Henri Jourdan's avatar
      Cancelable and IdFree typeclasses. · 71c10187
      Jacques-Henri Jourdan authored
      Cancelable elements are a new way of proving local updates, by
      removing some cancellable element of the global state, provided that
      we own it and we are willing to lose this ownership.
      
      Identity-free elements are an auxiliary that is necessary to prove that
      [Some x] is cancelable.
      
      For technical reasons, these two notions are not defined exactly like
      what one might expect, but also take into account validity. Otherwise,
      an exclusive element would not be cancelable or idfree, which is
      rather confusing.
      71c10187
  29. Jan 27, 2017
  30. Jan 25, 2017
  31. Jan 11, 2017
  32. Jan 05, 2017
  33. Jan 04, 2017
Loading