GitLab

I saw no need for `stuckness_flip`: strong atomicity always works,
while weak atomicity works only for expressions that are not stuck.
Since this seemed unclear, I split lemma `wp_atomic'` up into
`wp_strong_atomic` (parametric in the WP's `s`) and `wp_weak_atomic`
(not). The proof mode instance is stated in terms of the derived rule
`wp_atomic` (parametric in `s`).

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.

This class, in combination with `TCForall`, turns out the useful in
LambdaRust to express that lists of expressions are values.

Coq also uses level 200 for these constructs.
Besides, heap_lang's match and if were also already at this level.

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.

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

This problem has been reported by Léon Gondelman.

Before, when using, for example wp_alloc, in an expression like:

  ref (ref v)

It would apply `tac_wp_alloc` to the outermost ref, after which it
fails to establish that the argument `ref v` is a value. In this
commit, other evaluation positions will be tried whenever it turn
out that the argument of the construct is not a value. The same
applies to store/cas/...

I have implemented this by making use of the new `IntoVal` class.

Expression `e` such that `to_val e = Some v` is in the context gets
reflected into value `v` together with the proof that `to_val e = Some
v`.

This is helpful for substitution and for `solve_to_val` operating on
the reflected syntax.

This way `IntoLaterNEnvs` is ought to be computed less frequently

The tactic was doing something weird and only once used.

- Get rid of wp_finish, which was a hack.
- Write the wp_ tactics for stateful steps in the same style as
  wp_pure, i.e. by taking the context into account.
- Make use of the context K in wp_pure.

Instead of writing a separate tactic lemma for each pure reduction,
there is a single tactic lemma for performing all of them.

The instances of PureExec can be shared between WP tactics and, e.g.
symbolic execution in the ghost  threadpool