Iris issueshttps://gitlab.mpi-sws.org/iris/iris/-/issues2018-10-31T14:44:29Zhttps://gitlab.mpi-sws.org/iris/iris/-/issues/164Take a closer look at the interaction of fancy updates and plainly2018-10-31T14:44:29ZRalf Jungjung@mpi-sws.orgTake a closer look at the interaction of fancy updates and plainlyCurrently we have these two laws:
```
fupd_plain' E1 E2 E2' (P Q : PROP) `{!Plain P} :
E1 ⊆ E2 →
(Q ={E1, E2'}=∗ P) -∗ (|={E1, E2}=> Q) ={E1}=∗ (|={E1, E2}=> Q) ∗ P;
later_fupd_plain E (P : PROP) `{!Plain P} :
(▷ |={E}=> ...Currently we have these two laws:
```
fupd_plain' E1 E2 E2' (P Q : PROP) `{!Plain P} :
E1 ⊆ E2 →
(Q ={E1, E2'}=∗ P) -∗ (|={E1, E2}=> Q) ={E1}=∗ (|={E1, E2}=> Q) ∗ P;
later_fupd_plain E (P : PROP) `{!Plain P} :
(▷ |={E}=> P) ={E}=∗ ▷ ◇ P;
```
First, I find it surprising that we need two laws. Second, the first law looks really unwieldy.Ralf Jungjung@mpi-sws.orgRalf Jungjung@mpi-sws.orghttps://gitlab.mpi-sws.org/iris/iris/-/issues/163Dealing with nested modalities in `iModIntro`2020-06-29T10:38:08ZRobbert KrebbersDealing with nested modalities in `iModIntro`We should support introducing `monPred_at P i`. Currently this presents a problem because we already have the following instance:
```coq
Global Instance from_modal_monPred_at i P Q 𝓠 :
FromModal modality_id P Q → MakeMonPredAt i Q 𝓠 →...We should support introducing `monPred_at P i`. Currently this presents a problem because we already have the following instance:
```coq
Global Instance from_modal_monPred_at i P Q 𝓠 :
FromModal modality_id P Q → MakeMonPredAt i Q 𝓠 → FromModal modality_id (P i) 𝓠.
```
This instance allows introduction of e.g. updates below `monPred_at`.
When we add a `FromModal` instance for `monPred_at P i`, we end up with ambiguity when introducing `monPred_at (|==> P) i`: should `|==>` or `monPred_at` be introduced?
Concretely, we should:
- [ ] Add a `FromModal` instance for `monPred_at`
- [ ] Get the priorities of that instance and e.g. the above `from_modal_monPred_at` right
- [x] Do the same for `embed`https://gitlab.mpi-sws.org/iris/iris/-/issues/162Have `iFrame` smartly instantiate existentials2018-03-03T19:06:32ZJacques-Henri JourdanHave `iFrame` smartly instantiate existentialsIn the case the goal is e.g., of the form `P * ?Q`, where `?Q` is an existential, and we want to frame some assertion `R` that does not appear, we may want to instantiate `?Q` with `R * ?Q'`. Therefore, the meta-variable serves as a "buf...In the case the goal is e.g., of the form `P * ?Q`, where `?Q` is an existential, and we want to frame some assertion `R` that does not appear, we may want to instantiate `?Q` with `R * ?Q'`. Therefore, the meta-variable serves as a "buffer" where we put everything which we frame and fail to put anywhere else.
This is usefull in CFML, so I think I will implement this anyway in CFML. The reason it is usefull is that the typical CFML workflow implies working with an evar as a post-condition, which is instantiated by whatever is remaining.
Would you think this might be worth having in the general IPM?https://gitlab.mpi-sws.org/iris/iris/-/issues/161Use `plainly_alt` as an axiom and replace most of the current ones2020-03-18T15:08:43ZJacques-Henri JourdanUse `plainly_alt` as an axiom and replace most of the current onesIn the interface for plainly, we could have `plainly_alt` as an axiom. Here are the reasons this is not a completely absurd idea:
1- Most of the axioms can be removed. Namely, the only ones remaining are:
* `bi_persistently_impl_plainly...In the interface for plainly, we could have `plainly_alt` as an axiom. Here are the reasons this is not a completely absurd idea:
1- Most of the axioms can be removed. Namely, the only ones remaining are:
* `bi_persistently_impl_plainly`, `bi_plainly_impl_plainly` (which I find kind of arbitrary anyway),
* `sbi_mixin_prop_ext` (which is actually one of the few current axioms of `plainly` that actually /says/ something about the BI. So this is expected that it stays.
* The axioms about the updates, but I would say these are rather about the update than about `bi_plainly`
* `sbi_mixin_later_plainly_2`, which somehow I am not able to prove. But perhaps I am missing something.
Note that for some of these axioms (except `bi_plainly_impl_plainly`, `sbi_mixin_prop_ext` and the update axioms), we could
replace "for all plain assertion P" by "for all equality", which make them understandable even without understanding what is plainly.
2- I would say the definition of `plainly_alt` is quite intuitive. Indeed, `P /\ emp = emp` is a way of internally saying `emp |- P`, which exactly means that `P` is valid. So this definition can directly be interpreted as the "internal validity".https://gitlab.mpi-sws.org/iris/iris/-/issues/160Figure out the best place for the plainly modality2018-03-03T16:56:51ZRalf Jungjung@mpi-sws.orgFigure out the best place for the plainly modalityRight now, `plainly` is part of the BI interface, so *every* logic has to have this modality. Given that this modality is not at all needed for the proof mode to function, I think that's a bad choice. We already have some rather arbitra...Right now, `plainly` is part of the BI interface, so *every* logic has to have this modality. Given that this modality is not at all needed for the proof mode to function, I think that's a bad choice. We already have some rather arbitrary-looking axioms for `bi_persistently`; let's try to minimize the amount of "strange modalities" in the interface(s) as much as possible.
The following proposals are on the table:
1. Follow !98 and treat `plainly` like `fupd` and `bupd`: As "standardized extensions" that come with their own separate interface, but once instantiated with proofs of the basic laws are automatically integrated into the proofmode (because a bunch of instances based on this interface already exist).
1. Put `plainly` into `Sbi`.
1. Have a new "IrisLikeLogic", extending `Sbi`, which contains `plainly` as well as the update modalities.
My own comments:
1. This is the most general and, absent technical concerns, "best" solution -- but handling the resulting hierarchie(s) could become annoying. We'd also have to decide which approach to use for these (bundled/unbundled, typeclasses/canonical structures). (I somehow thought @robbertkrebbers was able to solve all hierarchy problems in Coq as that's what you did so far; hearing even you say that this is getting too complicated is quite unsettling to be honest ;)
1. I see no motivation for doing this, it seems rather arbitrary.
1. seems okay to me -- a little sad, but given the state of affairs probably a reasonable compromise for the time being. We have no example of a logic that would benefit from `plainly` that doesn't also have the updates.
Ideally I'd prefer 1., but given that if @robbertkrebbers can't get the hierarchy to work, neither will I -- that makes 3. look appealing enough. ;) I don't like 2. at all.Generalized Proofmode Mergerhttps://gitlab.mpi-sws.org/iris/iris/-/issues/159Find better name for "emp |- P"2018-07-13T08:51:26ZRalf Jungjung@mpi-sws.orgFind better name for "emp |- P"Currently, `emp |- P` is called `bi_valid P` and is used as a coercion from `PROP` to `Prop`. This turns out to be the right definition for the coercion (i.e., `(l |-> v -* l |->{0.5} v * l |->{0.5} v)%I` is provable), but the name is d...Currently, `emp |- P` is called `bi_valid P` and is used as a coercion from `PROP` to `Prop`. This turns out to be the right definition for the coercion (i.e., `(l |-> v -* l |->{0.5} v * l |->{0.5} v)%I` is provable), but the name is dubious: Usually, validity is defined as `True |- P`. Let's try to find a better name.Generalized Proofmode Mergerhttps://gitlab.mpi-sws.org/iris/iris/-/issues/158Make clear which arguments of tactics are optional in `ProofMode.md`2020-12-19T17:43:20ZRobbert KrebbersMake clear which arguments of tactics are optional in `ProofMode.md`See the discussion in https://gitlab.mpi-sws.org/FP/iris-coq/merge_requests/116#note_25050See the discussion in https://gitlab.mpi-sws.org/FP/iris-coq/merge_requests/116#note_25050https://gitlab.mpi-sws.org/iris/iris/-/issues/157`done` loops in proofmode2018-03-07T18:16:58ZRobbert Krebbers`done` loops in proofmode```coq
Lemma test : ∃ R, R ⊢ ∀ P, P.
Proof. eexists. iIntros "?" (P). done.
``````coq
Lemma test : ∃ R, R ⊢ ∀ P, P.
Proof. eexists. iIntros "?" (P). done.
```Generalized Proofmode MergerRobbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/156How to deal with `emp`, `True`, and friends when the BI is ambigious2018-07-13T08:40:32ZRobbert KrebbersHow to deal with `emp`, `True`, and friends when the BI is ambigiousThe following discussion from !115 should be addressed:
We often write `emp : PROP`. However, since coercions are explicit term constructors in Coq, this apparently leads to unification problems here and there.
The alternative is to wr...The following discussion from !115 should be addressed:
We often write `emp : PROP`. However, since coercions are explicit term constructors in Coq, this apparently leads to unification problems here and there.
The alternative is to write `bi_emp (PROP:=PROP)`, which is ugly.
Maybe we should have special notations to force the type arguments of `emp`, `True`, and friends.
I think ssr is also doing something like that. Depending on the outcome of this issue, we should not just address the occurrence in !115, but also fix other occurrences.Generalized Proofmode Mergerhttps://gitlab.mpi-sws.org/iris/iris/-/issues/155Make `iPureIntro` able to introduce affine pure assertions when the context i...2018-02-15T16:08:05ZJacques-Henri JourdanMake `iPureIntro` able to introduce affine pure assertions when the context is emtpy.The current lemma behind `iPureIntro` is:
```coq
Lemma tac_pure_intro Δ Q φ : FromPure false Q φ → φ → envs_entails Δ Q.
Proof. intros ??. rewrite /envs_entails -(from_pure _ Q). by apply pure_intro. Qed.
```
Could we change it a bit, ...The current lemma behind `iPureIntro` is:
```coq
Lemma tac_pure_intro Δ Q φ : FromPure false Q φ → φ → envs_entails Δ Q.
Proof. intros ??. rewrite /envs_entails -(from_pure _ Q). by apply pure_intro. Qed.
```
Could we change it a bit, so that we ask for `FromPure true Q φ` when the context is empty? That way, we could introduce CFML's affine pure assertions transparently when the context is empty.Robbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/154Bring back side-conditionals for `iMod`2018-07-13T08:51:28ZRobbert KrebbersBring back side-conditionals for `iMod`By @jtassaro
> So, in Iris 2.0, if I'm recalling correctly, one only had (|={E1,E2}=> |={E2,E3}=> P) ={E1,E3}=> P under the assumption that E2 ⊆ E1 ∪ E3. I guess in the Iris 3.0 this assumption is no longer needed anymore, and so this ...By @jtassaro
> So, in Iris 2.0, if I'm recalling correctly, one only had (|={E1,E2}=> |={E2,E3}=> P) ={E1,E3}=> P under the assumption that E2 ⊆ E1 ∪ E3. I guess in the Iris 3.0 this assumption is no longer needed anymore, and so this assumption is not part of the FUpdFacts (and I can't think of a way to jam it into the instance of ElimModal so that iMod will do the right thing). The problem is that the logic from our ESOP 2017 paper is based on Iris 2.0 style so I need this assumption. Any thoughts? Obviously I can just re-define a version of iMod that accounts for this additional hypothesis, but I'm wondering if there's a preferred way.Robbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/153Exponential slowdown in `iFrame` and the number of laters2018-02-20T00:50:15ZRobbert KrebbersExponential slowdown in `iFrame` and the number of laters```coq
From iris Require Import proofmode.tactics.
Lemma test2 {M} (P Q R : uPred M) :
(▷ P ∧ ▷ Q ∧ ▷ R) -∗ ▷ ▷ (P ∗ Q ∗ R).
Proof. Time Fail iIntros "$". (* 0.141s *) Admitted.
Lemma test4 {M} (P Q R : uPred M) :
(▷ P ∧ ▷ Q ∧ ▷ R)...```coq
From iris Require Import proofmode.tactics.
Lemma test2 {M} (P Q R : uPred M) :
(▷ P ∧ ▷ Q ∧ ▷ R) -∗ ▷ ▷ (P ∗ Q ∗ R).
Proof. Time Fail iIntros "$". (* 0.141s *) Admitted.
Lemma test4 {M} (P Q R : uPred M) :
(▷ P ∧ ▷ Q ∧ ▷ R) -∗ ▷ ▷ ▷ ▷ (P ∗ Q ∗ R).
Proof. Time Fail iIntros "$". (* 0.7s *) Admitted.
Lemma test8 {M} (P Q R : uPred M) :
(▷ P ∧ ▷ Q ∧ ▷ R) -∗ ▷ ▷ ▷ ▷ ▷ ▷ ▷ ▷ (P ∗ Q ∗ R).
Proof. Time Fail iIntros "$". (* 6.796s *) Admitted.
```Robbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/152iRewrite: Support rewriting with Coq hypotheses2019-11-01T12:51:27ZRalf Jungjung@mpi-sws.orgiRewrite: Support rewriting with Coq hypothesesiRewrite should be able to rewrite with a Coq equality embedded into Iris. Ideally, if the embedded equality is Leibniz equality, this would work even without `Proper` instances.
Cc @tslilyaiiRewrite should be able to rewrite with a Coq equality embedded into Iris. Ideally, if the embedded equality is Leibniz equality, this would work even without `Proper` instances.
Cc @tslilyaiRobbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/151Naming : Absolute, absolutely, relatively2018-03-04T19:19:42ZJacques-Henri JourdanNaming : Absolute, absolutely, relativelyThis issue is here just to make sure that everyone agrees with the new names and notations (and to choose other ones, as I am sure you will not agree).
So:
- `monPred_all` becomes `monPred_absolutely`, written `∀ᵢ P`
- `monPred_ex` beco...This issue is here just to make sure that everyone agrees with the new names and notations (and to choose other ones, as I am sure you will not agree).
So:
- `monPred_all` becomes `monPred_absolutely`, written `∀ᵢ P`
- `monPred_ex` becomes `monPred_relatively`, written `∃ᵢ P`
- `Objective` becomes `Absolute`
Just to be clear: it took these names because something had to be chosen to make progress, and because there was objections about the previous names. No decision is taken, and anyone should feel free to contest.Generalized Proofmode Mergerhttps://gitlab.mpi-sws.org/iris/iris/-/issues/150Smarter iFrame: Prefer framing below `*` over framing below disjunction or wand2019-11-01T13:31:27ZRalf Jungjung@mpi-sws.orgSmarter iFrame: Prefer framing below `*` over framing below disjunction or wandWhen framing below a disjunction or a wand/implication, it can happen that `P` could have been framed elsewhere, and that would have been smarter. This is the case both for `(True \/ P) * P` and `(False -* P) * P`.
One possible way to ...When framing below a disjunction or a wand/implication, it can happen that `P` could have been framed elsewhere, and that would have been smarter. This is the case both for `(True \/ P) * P` and `(False -* P) * P`.
One possible way to solve this would be to have some kind of precedence for "framing positions" and not stop searching just because we found one below a disjunction/wand.https://gitlab.mpi-sws.org/iris/iris/-/issues/149The current axioms of BI imply emp ≡ True2018-02-26T13:43:07ZAleš Bizjakales@alesb.comThe current axioms of BI imply emp ≡ TrueAs the subject states, the current axiomatization of the plainly modality implies emp ≡ True.
In particular, the guilty parties are the axioms `prop_ext` and `plainly_emp_intro`.
I am not sure whose axioms they are, but I hope either @r...As the subject states, the current axiomatization of the plainly modality implies emp ≡ True.
In particular, the guilty parties are the axioms `prop_ext` and `plainly_emp_intro`.
I am not sure whose axioms they are, but I hope either @robbertkrebbers or @jjourdan knows the history.
I believe this must be an error, since otherwise there is no point in having `emp`.
```coq
From iris.bi Require Import interface.
Import bi.
Section bi_emp.
Context {PROP : bi}.
Notation "P ⊢ Q" := (@bi_entails PROP P%I Q%I).
Lemma bar: emp ⊢ (True → emp) ∧ (emp → True).
Proof.
apply and_intro.
- apply impl_intro_r, and_elim_l.
- apply impl_intro_r, pure_intro; exact I.
Qed.
Lemma baz: True ⊢ ((True : PROP) ≡ emp).
Proof.
transitivity (bi_plainly (emp : PROP))%I; first apply plainly_emp_intro.
transitivity (bi_plainly ((True → emp : PROP) ∧ (emp → True))%I).
{ apply plainly_mono, bar. }
apply prop_ext.
Qed.
End bi_emp.
```Generalized Proofmode MergerJacques-Henri JourdanJacques-Henri Jourdanhttps://gitlab.mpi-sws.org/iris/iris/-/issues/148Make `iNext` smarter for mixed `▷` and `▷^(n+m)`2018-02-20T15:29:40ZLéon Gondelman Make `iNext` smarter for mixed `▷` and `▷^(n+m)`Following the (fixed) issue (https://gitlab.mpi-sws.org/FP/iris-coq/issues/141), there is still an error w.r.t. addition in the laterN modality:
```coq
From iris Require Import proofmode.tactics.
Lemma foo {M} (P : uPred M) n m : ▷ ▷^...Following the (fixed) issue (https://gitlab.mpi-sws.org/FP/iris-coq/issues/141), there is still an error w.r.t. addition in the laterN modality:
```coq
From iris Require Import proofmode.tactics.
Lemma foo {M} (P : uPred M) n m : ▷ ▷^(n+m) P ⊢ ▷^n ▷ P.
Proof. iIntros "H". iNext.
```
```coq
(* Gives
"H" : ▷ ▷^(n + m) P
--------------------------------------∗
▷ P
*)
```
forgetting erroneously to cancel `n` in the premise `"H"`.Robbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/147Infrastructure for the `monPred_all` modality2018-07-13T08:51:27ZJacques-Henri JourdanInfrastructure for the `monPred_all` modalityIf everything in the context is objective, then we should be able to introduce the `monPred_all` modality. This should reuse the infrastructure of `iAlways`.
However, I would like to go a bit further: Actually, in the case everything in...If everything in the context is objective, then we should be able to introduce the `monPred_all` modality. This should reuse the infrastructure of `iAlways`.
However, I would like to go a bit further: Actually, in the case everything in the context is objective, and the goal is objective too, we might want to switch to Iris proofmode to get rid of embeddings and all that.https://gitlab.mpi-sws.org/iris/iris/-/issues/146Lemmas about updates should be instantiated by default witht the current BI i...2018-07-13T08:51:27ZJacques-Henri JourdanLemmas about updates should be instantiated by default witht the current BI instead of `iProp`The instances for the `FUpd` and `FUpdFacts` type classes are set in a way that gives the priority to `iProp`? Therefore, when using lemmas about updates in `vProp`, we sometimes have to manually instantiate them with the current BI. Oth...The instances for the `FUpd` and `FUpdFacts` type classes are set in a way that gives the priority to `iProp`? Therefore, when using lemmas about updates in `vProp`, we sometimes have to manually instantiate them with the current BI. Otherwise, the lemmas are instantiated with `iProp` and used through the embedding.
See, for example https://gitlab.mpi-sws.org/FP/sra-gps/blob/gen_proofmode_WIP/theories/examples/circ_buffer.v#L236
The instances for the `AsValid` type class prioritizes the fact of not using the embedding, so we should be able to fix this issue by simply making sure the search for `AsValid` occurs before `FUpd`, but I do not know how to do that.
@robbertkrebbers, any idea?Robbert KrebbersRobbert Krebbershttps://gitlab.mpi-sws.org/iris/iris/-/issues/145Framing should succeed when a disjunct is exactly the framed hypothesis2018-02-08T21:00:00ZRobbert KrebbersFraming should succeed when a disjunct is exactly the framed hypothesisFor example, framing `P` in `(P ∨ Q) ∗ R` should succeed and turn the goal into `R`.
In general, framing of non-persistent hypotheses in just one disjunct of a disjunction leads to information loss, so should fail. However, if framing i...For example, framing `P` in `(P ∨ Q) ∗ R` should succeed and turn the goal into `R`.
In general, framing of non-persistent hypotheses in just one disjunct of a disjunction leads to information loss, so should fail. However, if framing in one disjunct turns it into `True`, framing should succeed.Robbert KrebbersRobbert Krebbers