GitLab

New IntoAcc typeclass to decouple creating and elliminating accessors; ElimInv supports both with and without Hclose

Extend ElimModal with Boolean flags to specify whether it operates on the persistent/spatial context.

This is backwards-compatible; it desugars to a normal application on previous versions

This requires changing the Hint Mode of the [Frame] type class because it should not fail if its parameter is an evar, but instantiate it instead. In order to prevent all the other instances of [Frame] to intantiate this evar themselves, we create a new type class [KnwonFrame], which corresponds to the old behavior.

This supports Iris 2 like update modalities, as used in e.g. by @jtassaro.

This commit fixes issue #154.

We already used the following naming convention: `wp_value'` is stated in
terms of `of_val` and `wp_value` is stated in terms of `IntoVal`. This
commit applies this convention to `wp_value_inv` as well.

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.

It can be infered now.

This reverts commit 913059d2.

This reverts commit 849abb8d, reversing changes
made to 8de0b894.  The merge was done
accidentally, before review happened.

This is derived from `wp_forget_not_stuck` and a trivial preorder on
stuckness bits. (The two lemmas are redundant, but I have examples
where each seems more natural than the other.)

I did *not* bake `wp_stuckness_mono` into `strong_mono` for two
reasons. Mainly, I didn't see a nice way to combine the two proofs
(beyond `cut`). Less important, changing the type of `wp_strong_mono`
will break code.

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

Pull progress bit out of the WP fixpoint,
make (most) wp adequacy notation only parsing, and
generalize forget_progress.