Fix a typo in constructions.tex

x_1 should be a_1

See merge request !35

Really, *all* of our files contain proof rules

Use agree instead of dec_agree

This demonstrates that a list-based agreement could work, and form an OFE. I didn't bother to prove all the functor laws.

Man, this reasoning with about the lists is annoying^^.

What I don't like about this is that un-injection (`agree_car`) is only non-expansive for valid elements. I want to try using a different equivalence relation, maybe I can find one where this works.

Cc @jjourdan @robbertkrebbers

See merge request !22

Thanks to Robbert for fixing gen_heap

State invariants in WP and the dead of heap_ctx.

This merge request changes the WP construction so that it takes _state interpretation_ as its parameter (part of the `irisG` type class), instead of building in the authoritative ownership of the entire state. When instantiating WP with a concrete language, one can choose the state interpretation. For example, for `heap_lang` we directly use `auth (gmap loc (frac * dec_agree val))`, and avoid the indirection through an invariant managing ownership of the entire state.

As a result, we no longer have to carry around `heap_ctx`.

See merge request !25

The WP construction now takes an invariant on states as a parameter
(part of the irisG class) and no longer builds in the authoritative
ownership of the entire state. When instantiating WP with a concrete
language on can choose its state invariant. For example, for heap_lang
we directly use `auth (gmap loc (frac * dec_agree val))`, and avoid
the indirection through invariants entirely.

As a result, we no longer have to carry `heap_ctx` around.

We typically use the _1 and _2 suffix to denote individual directions
of a lemmas that is a biimplication.

case H; clear H would fail when H is dependent whereas destruct H
would succeed on that, but just not clear it.

The case tactic is faster than destruct.

Example:

Goal
  ¬False → ¬False → ¬False → ¬False → ¬False → ¬False → ¬False →
  False.
Proof.
  intros. done. (* takes very long *)

Add locking to value-scope notation for lambdas

This attempts to hide all our locking machinery so that users don't have to care. To this end, `locked` is added to the value-scope notation for lambdas and recursive functions, and the tactics wp_rec and wp_lam are enhanced to unlock properly.

The main open question is: How can we figure out automatically what to unfold? The heuristic I cam up with fails in barrier_client because there, we have a value parameterized by something on the Coq level.

Maybe a more viable alternative would be to add locking to the coercion that embeds values into expressions?

Cc @robbertkrebbers @jjourdan

See merge request !34