- 12 May, 2017 5 commits
-
-
Robbert Krebbers authored
Otherwise, the tactic will fail subsequently. Besides, it was inconsistent w.r.t. the iLöb tactic, which was already doing this.
-
Robbert Krebbers authored
-
Robbert Krebbers authored
-
Robbert Krebbers authored
-
Ralf Jung authored
-
- 09 May, 2017 1 commit
-
-
Robbert Krebbers authored
-
- 27 Apr, 2017 2 commits
-
-
Robbert Krebbers authored
Now they can also be used to clear/frame the whole pure/persistent/spatial context.
-
Robbert Krebbers authored
-
- 26 Apr, 2017 1 commit
-
-
Robbert Krebbers authored
After discussing this with Ralf, again, it turned out that using a bar instead of a turnstyle would be better. When formalizing type systems, one often wants to use a turnstyle in other notations (the typing judgment), so having the turnstyle in the proofmode notation is confusing.
-
- 19 Apr, 2017 3 commits
- 13 Apr, 2017 6 commits
-
-
Robbert Krebbers authored
-
Robbert Krebbers authored
-
Robbert Krebbers authored
-
Robbert Krebbers authored
-
Robbert Krebbers authored
This enables things like `iSpecialize ("H2" with "H1") in the below: "H1" : P ---------□ "H2" : □ P -∗ Q ---------∗ R
-
Robbert Krebbers authored
-
- 12 Apr, 2017 3 commits
- 11 Apr, 2017 4 commits
-
-
Jacques-Henri Jourdan authored
A notion of CMRA morphims based on the compatibility with validity, core and composition. See merge request !56
-
Ralf Jung authored
-
Ralf Jung authored
-
Ralf Jung authored
-
- 07 Apr, 2017 3 commits
-
-
Robbert Krebbers authored
For example, when having `H : ▷ P → Q` and `HP : P`, we can now do `iSpecialize ("H" with "HP")`. This is achieved by putting a `FromAssumption` premise in the base instance for `IntoWand`.
-
Ralf Jung authored
-
Jacques-Henri Jourdan authored
-
- 05 Apr, 2017 1 commit
-
-
Jacques-Henri Jourdan authored
-
- 04 Apr, 2017 1 commit
-
-
Jacques-Henri Jourdan authored
-
- 31 Mar, 2017 2 commits
- 30 Mar, 2017 1 commit
-
-
Ralf Jung authored
Fixes issue #85
-
- 28 Mar, 2017 2 commits
-
-
Robbert Krebbers authored
This fixes the bug that when having: iDestruct (foo with "H") as "{H1 H2} #[H1 H2]" The hypothesis H would not be kept.
-
Robbert Krebbers authored
-
- 27 Mar, 2017 1 commit
-
-
Robbert Krebbers authored
-
- 24 Mar, 2017 4 commits
-
-
Robbert Krebbers authored
Generic big operators that are computational for lists Closes #38 See merge request !54
-
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
-