1. 19 Feb, 2018 2 commits
  2. 15 Feb, 2018 2 commits
  3. 13 Feb, 2018 3 commits
  4. 12 Feb, 2018 4 commits
  5. 07 Feb, 2018 1 commit
    • Robbert Krebbers's avatar
      Generic `iAlways` tactic. · 6dc83bcb
      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 always-style modalities.
      In order to plug in an always-style 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 as-if.
      Formally, these actions correspond to the following inductive type:
      Inductive always_intro_spec (PROP : bi) :=
        | AIEnvIsEmpty
        | AIEnvForall (C : PROP → Prop)
        | AIEnvFilter (C : PROP → Prop)
        | AIEnvClear
        | AIEnvId.
      An always-style modality is then a record `always_modality` packing together the
      modality with the laws it should satisfy to justify the given actions for both
  6. 02 Feb, 2018 1 commit
  7. 25 Jan, 2018 1 commit
  8. 16 Jan, 2018 1 commit
    • Robbert Krebbers's avatar
      Special proof mode class for adding a modality to a goal. · a63f256e
      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
  9. 31 Dec, 2017 1 commit
  10. 04 Dec, 2017 1 commit
  11. 03 Dec, 2017 1 commit
  12. 27 Nov, 2017 1 commit
  13. 22 Nov, 2017 2 commits
  14. 13 Nov, 2017 1 commit
    • Robbert Krebbers's avatar
      Improved treatment of anonymous hypotheses in the proof mode. · bb3584e7
      Robbert Krebbers authored
      The proof mode now explicitly keeps track of anonymous hypotheses (i.e.
      hypotheses that are introduced by the introduction pattern `?`). Consider:
        Lemma foo {M} (P Q R : uPred M) : P -∗ (Q ∗ R) -∗ Q ∗ P.
        Proof. iIntros "? [H ?]". iFrame "H". iFrame. Qed.
      After the `iIntros`, the goal will be:
        _ : P
        "H" : Q
        _ : R
        Q ∗ P
      Anonymous hypotheses are displayed in a special way (`_ : P`). An important
      property of the new anonymous hypotheses is that it is no longer possible to
      refer to them by name, whereas before, anonymous hypotheses were given some
      arbitrary fresh name (typically prefixed by `~`).
      Note tactics can still operate on these anonymous hypotheses. For example, both
      `iFrame` and `iAssumption`, as well as the symbolic execution tactics, will
      use them. The only thing that is not possible is to refer to them yourself,
      for example, in an introduction, specialization or selection pattern.
      Advantages of the new approach:
      - Proofs become more robust as one cannot accidentally refer to anonymous
        hypotheses by their fresh name.
      - Fresh name generation becomes considerably easier. Since anonymous hypotheses
        are internally represented by natural numbers (of type `N`), we can just fold
        over the hypotheses and take the max plus one. This thus solve issue #101.
  15. 03 Nov, 2017 1 commit
  16. 01 Nov, 2017 3 commits
    • Robbert Krebbers's avatar
      Hide the proof mode entailment behind a definition. · 8574d1ea
      Robbert Krebbers authored
      This solves issue #100: the proof mode notation is sometimes not printed. As
      Ralf discovered, the problem is that there are two overlapping notations:
      Notation "P ⊢ Q" := (uPred_entails P Q).
      And the "proof mode" notation:
      Notation "Γ '--------------------------------------' □ Δ '--------------------------------------' ∗ Q" :=
        (of_envs (Envs Γ Δ) ⊢ Q%I).
      These two notations overlap, so, when having a "proof mode" goal of the shape
      `of_envs (Envs Γ Δ) ⊢ Q%I`, how do we know which notation is Coq going to pick
      for pretty printing this goal? As we have seen, this choice depends on the
      import order (since both notations appear in different files), and as such, Coq
      sometimes (unintendedly) uses the first notation instead of the latter.
      The idea of this commit is to wrap `of_envs (Envs Γ Δ) ⊢ Q%I` into a definition
      so that there is no ambiguity for the pretty printer anymore.
    • Jacques-Henri Jourdan's avatar
    • Jacques-Henri Jourdan's avatar
      Remove notations for bi_bare and bi_persistently. · a38db108
      Jacques-Henri 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.
  17. 31 Oct, 2017 1 commit
  18. 30 Oct, 2017 11 commits
  19. 28 Oct, 2017 2 commits