 12 Feb, 2018 2 commits


JacquesHenri Jourdan authored
This reverts commit 78ba9509.

JacquesHenri Jourdan authored

 07 Feb, 2018 2 commits


Robbert Krebbers authored

Robbert Krebbers authored
This commit implements a generic `iAlways` tactic that is not tied to `persistently`, `affinely` and `plainly` but can be instantiated with a variety of alwaysstyle modalities. In order to plug in an alwaysstyle modality, one has to decide for both the persistent and spatial what action should be performed upon introducing the modality:  Introduction is only allowed when the context is empty.  Introduction is only allowed when all hypotheses satisfy some predicate `C : PROP → Prop` (where `C` should be a type class).  Introduction will only keep the hypotheses that satisfy some predicate `C : PROP → Prop` (where `C` should be a type class).  Introduction will clear the context.  Introduction will keep the context asif. Formally, these actions correspond to the following inductive type: ```coq Inductive always_intro_spec (PROP : bi) :=  AIEnvIsEmpty  AIEnvForall (C : PROP → Prop)  AIEnvFilter (C : PROP → Prop)  AIEnvClear  AIEnvId. ``` An alwaysstyle modality is then a record `always_modality` packing together the modality with the laws it should satisfy to justify the given actions for both contexts.

 02 Feb, 2018 1 commit


JacquesHenri Jourdan authored

 25 Jan, 2018 1 commit


JacquesHenri Jourdan authored

 24 Jan, 2018 1 commit


JacquesHenri Jourdan authored

 20 Jan, 2018 1 commit


Robbert Krebbers authored

 16 Jan, 2018 1 commit


Robbert Krebbers authored
This used to be done by using `ElimModal` in backwards direction. Having a separate type class for this gets rid of some hacks:  Both `Hint Mode`s in forward and backwards direction for `ElimModal`.  Weird type class precedence hacks to make sure the right instance is picked. These were needed because using `ElimModal` in backwards direction caused ambiguity.

 20 Dec, 2017 1 commit


Robbert Krebbers authored

 03 Dec, 2017 1 commit


Robbert Krebbers authored
We do not have a notation for `bi_affinely` either, so this is at least consistent.

 01 Nov, 2017 2 commits


JacquesHenri Jourdan authored

JacquesHenri Jourdan authored
(□ P) now means (bi_bare (bi_persistently P)). This is motivated by the fact that these two modalities are rarely used separately. In the case of an affine BI, we keep the □ notation. This means that a bi_bare is inserted each time we use □. Hence, a few adaptations need to be done in the proof mode class instances.

 30 Oct, 2017 5 commits


Robbert Krebbers authored
Whenever we iSpecialize something whose conclusion is persistent, we now have to prove all the premises under the sink modality. This is strictly more powerful, as we now have to use just some of the hypotheses to prove the premises, instead of all.

Robbert Krebbers authored

Robbert Krebbers authored
This also applies to the introduction pattern `!#`. Both will now introduce as many ■ or □ as possible. This behavior is consistent with the dual, `#`, which also gets rid of as many ■ and □ modalities as possible.

Robbert Krebbers authored
The absence of this axiom has two consequences:  We no longer have `■ (P ∗ Q) ⊢ ■ P ∗ ■ Q` and `□ (P ∗ Q) ⊢ □ P ∗ □ Q`, and as a result, separating conjunctions in the unrestricted/persistent context cannot be eliminated.  When having `(P ∗ ⬕ Q) ∗ P`, we do not get `⬕ Q ∗ P`. In the proof mode this means when having: H1 : P ∗ ⬕ Q H2 : P We cannot say `iDestruct ("H1" with "H2") as "#H1"` and keep `H2`. However, there is now a type class `PositiveBI PROP`, and when there is an instance of this type class, one gets the above reasoning principle back. TODO: Can we describe positivity of individual propositions instead of the whole BI? That way, we would get the above reasoning principles even when the BI is not positive, but the propositions involved are.

Robbert Krebbers authored

 28 Oct, 2017 1 commit


Robbert Krebbers authored

 26 Oct, 2017 1 commit


Robbert Krebbers authored

 25 Oct, 2017 5 commits


Robbert Krebbers authored
Replace/remove some occurences of `persistently` into `persistent` where the property instead of the modality is used.

Robbert Krebbers authored

Robbert Krebbers authored

Robbert Krebbers authored
I have reimplemented the tactic for introduction of ∀s/pures using type classes, which directly made it much more modular.

Robbert Krebbers authored
The advantage is that we can directly use a Coq introduction pattern `cpat` to perform actions to the pure assertion. Before, this had to be done in several steps: iDestruct ... as "[Htmp ...]"; iDestruct "Htmp" as %cpat. That is, one had to introduce a temporary name. I expect this to be quite useful in various developments as many of e.g. our invariants are written as: ∃ x1 .. x2, ⌜ pure stuff ⌝ ∗ spacial stuff.

 10 Oct, 2017 1 commit


Robbert Krebbers authored

 28 Aug, 2017 1 commit


Robbert Krebbers authored
persistent context. Given the source does not contain a box:  Before: noop if there is a Persistent instance.  Now: noop in all cases.

 08 Jun, 2017 1 commit


Robbert Krebbers authored

 13 Apr, 2017 1 commit


Robbert Krebbers authored
This enables things like `iSpecialize ("H2" with "H1") in the below: "H1" : P □ "H2" : □ P ∗ Q ∗ R

 07 Apr, 2017 1 commit


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`.

 21 Mar, 2017 3 commits


Robbert Krebbers authored
This way, iSplit will work when one side is persistent.

Robbert Krebbers authored

Robbert Krebbers authored

 15 Mar, 2017 2 commits


Robbert Krebbers authored
The instances frame_big_sepL_cons and frame_big_sepL_app could be applied repeatedly often when framing in [∗ list] k ↦ x ∈ ?e, Φ k x when ?e an evar. This commit fixes this bug.

Robbert Krebbers authored
 Allow framing of persistent hypotheses below the always modality.  Allow framing of persistent hypotheses in just one branch of a disjunction.

 09 Mar, 2017 1 commit


Robbert Krebbers authored
Also, make the setup of IntoLaterN more consistent with that of WandWeaken. Maybe, we should do something similar for other proof mode classes too.

 22 Feb, 2017 1 commit


Robbert Krebbers authored
There is no need to restrict the type class using Hint Mode, we have a default instance that will always be used first. In case of evars, the default instance should apply. The reason for this change is that `iAssumption` should be able to prove `H : ?e  P` and `H : P  ?e`. The former Hint Mode prevented it from doing that.

 11 Feb, 2017 1 commit


Robbert Krebbers authored
Instead of doing all the instantiations by invoking a single type class search, it now performs the instantiations by invoking individual type class searches. This a.) gives better error messages and b.) works when `xj` depends on `xi`.

 26 Jan, 2017 1 commit


Robbert Krebbers authored
TODO: document the setup of the IntoWand and WandWeaken type classes and the tricks using Hint Mode.

 22 Jan, 2017 1 commit


Robbert Krebbers authored
This fixes issue #62.
