GitLab

Thanks to Amin Timany for an initial version of the proof.

This solves issue #100: the proof mode notation is sometimes not printed. As
Ralf discovered, the problem is that there are two overlapping notations:

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

(□ 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.

These unfolds kind of make sense, and I was quite surprised that
it used to work before. However, when changing to primitive
records, these unfolds are actually needed.

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.

Otherwise, ownership of cores in our ordered RA model will not be persistent.

As Aleš observed, in the ordered RA model it is not, unless the order on the
unit is timeless.

Thanks to discussions with Ales and Amin.

This commit is based on code by Amin Timany.

This way, it can be used with `iApply`.

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

Now that we have the plain modality, we can get rid of the basic updates
in the soundness statement.

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

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`

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

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.

This causes a bit of backwards incompatibility: it may now succeed with
later stripping below unlocked/TC transparent definitions. This problem
actually occured for `wsat`.

We used to normalize the goal, and then checked whether it was of
a certain shape. Since `uPred_valid P` normalized to `True ⊢ P`,
there was no way of making a distinction between the two, hence
`True ⊢ P` was treated as `uPred_valid P`.

In this commit, I use type classes to check whether the goal is of
a certain shape. Since we declared `uPred_valid` as `Typeclasses
Opaque`, we can now make a distinction between `True ⊢ P` and
`uPred_valid P`.

In order to do that, we need to quantify over non-expansive
predicates instead of arbitrary predicates.