1. 26 Oct, 2017 3 commits
  2. 25 Oct, 2017 6 commits
  3. 27 Sep, 2017 1 commit
    • Robbert Krebbers's avatar
      Fix issue #99. · 7ed067a9
      Robbert Krebbers authored
      This causes a bit of backwards incompatibility: it may now succeed with
      later stripping below unlocked/TC transparent definitions. This problem
      actually occured for `wsat`.
      7ed067a9
  4. 17 Sep, 2017 1 commit
  5. 23 Aug, 2017 1 commit
  6. 17 Aug, 2017 1 commit
  7. 07 Aug, 2017 2 commits
  8. 13 Jun, 2017 3 commits
  9. 12 May, 2017 2 commits
  10. 24 Mar, 2017 1 commit
    • 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
  11. 15 Mar, 2017 1 commit
  12. 09 Mar, 2017 1 commit
  13. 11 Feb, 2017 1 commit
  14. 27 Jan, 2017 1 commit
  15. 22 Jan, 2017 2 commits
  16. 11 Jan, 2017 1 commit
  17. 05 Jan, 2017 1 commit
  18. 03 Jan, 2017 1 commit
  19. 27 Dec, 2016 1 commit
  20. 23 Dec, 2016 1 commit
  21. 13 Dec, 2016 1 commit
    • Robbert Krebbers's avatar
      Use different module structuring of uPred. · 766dbcd2
      Robbert Krebbers authored
      This fixes the following issue by JH Jourdan:
      
        The fact of including uPred_[...] in the module uPred (in base_logic.v),
        implies that typeclasses instances are declared twice. Once in module
        uPred and once in module uPred_[...]. This has the unfortunate
        consequence that it has to backtrack to both instances each time the
        first one fails, making failure of type class search for e.g.
        PersistentP potentially exponential.
      
        Goal ((□ ∀ (x1 x2 x3 x4 x5: nat), True -∗ True) -∗ True : iProp Σ).
          Time iIntros "#H".
          Undo.
          Remove Hints uPred_derived.forall_persistent : typeclass_instances.
          Time iIntros "#H".
      
      Thanks to Jason Gross @ Coq club for suggesting this fix.
      766dbcd2
  22. 09 Dec, 2016 1 commit
  23. 05 Dec, 2016 2 commits
  24. 29 Nov, 2016 1 commit
  25. 27 Nov, 2016 1 commit
  26. 24 Nov, 2016 1 commit
  27. 22 Nov, 2016 1 commit