1. 07 Apr, 2017 1 commit
  2. 24 Mar, 2017 5 commits
    • Robbert Krebbers's avatar
      bf8da205
    • Robbert Krebbers's avatar
      Make big_opL type class opaque. · 02a0929d
      Robbert Krebbers authored
      This commit fixes the issues that refolding of big operators did not work nicely
      in the proof mode, e.g., given:
      
          Goal forall M (P : nat → uPred M) l,
            ([∗ list] x ∈ 10 :: l, P x) -∗ True.
          Proof. iIntros (M P l) "[H1 H2]".
      
      We got:
      
          "H1" : P 10
          "H2" : (fix
                  big_opL (M0 : ofeT) (o : M0 → M0 → M0) (H : Monoid o) (A : Type)
                          (f : nat → A → M0) (xs : list A) {struct xs} : M0 :=
                    match xs with
                    | [] => monoid_unit
                    | x :: xs0 => o (f 0 x) (big_opL M0 o H A (λ n : nat, f (S n)) xs0)
                    end) (uPredC M) uPred_sep uPred.uPred_sep_monoid nat
                   (λ _ x : nat, P x) l
          --------------------------------------∗
          True
      
      The problem here is that proof mode looked for an instance of `IntoAnd` for
      `[∗ list] x ∈ 10 :: l, P x` and then applies the instance for separating conjunction
      without folding back the fixpoint. This problem is not specific to the Iris proof
      mode, but more of a general problem of Coq's `apply`, for example:
      
          Goal forall x l, Forall (fun _ => True) (map S (x :: l)).
          Proof.
            intros x l. constructor.
      
      Gives:
      
           Forall (λ _ : nat, True)
             ((fix map (l0 : list nat) : list nat :=
                match l0 with
                | [] => []
                | a :: t => S a :: map t
                end) l)
      
      This commit fixes this issue by making the big operators type class opaque and instead
      handle them solely via corresponding type classes instances for the proof mode tactics.
      
      Furthermore, note that we already had instances for persistence and timelessness. Those
      were really needed; computation did not help to establish persistence when the list in
      question was not a ground term. In fact, the sitation was worse, to establish persistence
      of `[∗ list] x ∈ 10 :: l, P x` it could either use the persistence instance of big ops
      directly, or use the persistency instance for `∗` first. Worst case, this can lead to an
      exponential blow up because of back tracking.
      02a0929d
    • Robbert Krebbers's avatar
      Derive monoid_right_id. · b99023e7
      Robbert Krebbers authored
      b99023e7
    • 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
    • Robbert Krebbers's avatar
      15bfdc15
  3. 21 Mar, 2017 1 commit
  4. 20 Mar, 2017 1 commit
  5. 14 Mar, 2017 1 commit
  6. 11 Mar, 2017 1 commit
  7. 10 Mar, 2017 2 commits
  8. 09 Mar, 2017 3 commits
  9. 01 Mar, 2017 1 commit
  10. 23 Feb, 2017 1 commit
  11. 22 Feb, 2017 3 commits
  12. 21 Feb, 2017 1 commit
  13. 16 Feb, 2017 1 commit
  14. 11 Feb, 2017 1 commit
  15. 10 Feb, 2017 5 commits
  16. 09 Feb, 2017 3 commits
  17. 06 Feb, 2017 1 commit
  18. 03 Feb, 2017 1 commit
  19. 01 Feb, 2017 2 commits
    • Robbert Krebbers's avatar
      Arguments for gsetC and gset_disjC. · bf069d12
      Robbert Krebbers authored
      bf069d12
    • 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
  20. 30 Jan, 2017 2 commits
  21. 27 Jan, 2017 1 commit
  22. 26 Jan, 2017 1 commit
  23. 25 Jan, 2017 1 commit