 27 Nov, 2017 1 commit


Robbert Krebbers authored

 21 Nov, 2017 1 commit


Robbert Krebbers authored

 20 Nov, 2017 2 commits


Robbert Krebbers authored

Robbert Krebbers authored

 16 Nov, 2017 1 commit


Ralf Jung authored

 14 Nov, 2017 1 commit


Robbert Krebbers authored
This is an old flag set by the ssr plugin, and recently unset in coqstdpp, see https://gitlab.mpisws.org/robbertkrebbers/coqstdpp/issues/5.

 11 Nov, 2017 1 commit


Robbert Krebbers authored

 28 Oct, 2017 1 commit


JacquesHenri Jourdan authored
This is to be used on top of stdpp's 4b5d254e.

 26 Oct, 2017 1 commit


Robbert Krebbers authored
Now, associativity needs only to be established in case the elements are valid and their compositions are defined. This is very much like the notion of separation algebras I had in my PhD thesis (Def 4.2.1). The Dra to Ra construction still easily works out.

 25 Oct, 2017 4 commits


Robbert Krebbers authored

Robbert Krebbers authored
Rename `UCMRA` → `Ucmra` Rename `CMRA` → `Cmra` Rename `OFE` → `Ofe` (`Ofe` was already used partially, but many occurences were missing) Rename `STS` → `Sts` Rename `DRA` → `Dra`

Robbert Krebbers authored

Robbert Krebbers authored

 10 Oct, 2017 2 commits
 21 Sep, 2017 1 commit


Robbert Krebbers authored

 17 Sep, 2017 3 commits


Robbert Krebbers authored

Robbert Krebbers authored
For obsolete reasons, that no longer seem to apply, we used ∅ as the unit.

Robbert Krebbers authored

 17 Aug, 2017 3 commits


Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored
That way, we can use Contractive as part of structure definitions in which we do not have a bundled OFE yet.

 06 Aug, 2017 1 commit


JacquesHenri Jourdan authored

 28 Jul, 2017 1 commit


JacquesHenri Jourdan authored

 12 Jun, 2017 1 commit


Robbert Krebbers authored

 08 Jun, 2017 6 commits


Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored

 13 Apr, 2017 2 commits


Robbert Krebbers authored

Robbert Krebbers authored

 12 Apr, 2017 1 commit


Ralf Jung authored

 07 Apr, 2017 1 commit


JacquesHenri Jourdan authored

 24 Mar, 2017 5 commits


Robbert Krebbers authored

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.

Robbert Krebbers authored

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.

Robbert Krebbers authored
