GitLab

update Makefile and CI

See merge request !2

The simplification is acheieved by removing the stackUR workaround.
That RA was used to enusure that the nodes that were parts of the
stack do not change themselves -- this is crucial for the safety of
pop and iter operations.

Now this is achieved by using duplicable propositions (∃ q, n ↦ᵢ{q} v)
to ensure that the node are still alive/not freed.

install CI and update build system

See merge request !1

Thanks to Robbert

Thunk the FG/CG_increment functions at the point of initialization.
This allows us to avoid the use of lamsubst.

- relational specifications for weak increment
- logically atomic specification for `ticket_lock.acquire`

We define a stronger rule `related_bind_up`, in which there is a baked
in semantic type `R`. The idea here is that we don't actually require
the expressions that we bind to have the same syntactic type.

```
  {E;R::Δ;⤉Γ} ⊨ e1 ≤log≤ e2 : τ
∗ (∀ vv, ⟦ τ ⟧ (R::Δ) vv -∗ {E;Δ;Γ} ⊨ K[v1] ≤log≤ K'[v2] : τ')
____________________________________________________________
  {E;Δ;Γ} ⊨ K[e1] ≤log≤ K'[e2] : τ'
```

We can then use `bin_log_related_weaken_2` to prove the original
binding rule.

The advantages of the new rule is that it allows us to prove the
following compatibility rule for seq:

```
{E;(R::Δ);⤉Γ} ⊨ e1 ≤log≤ e1' : τ1 -∗
{E;Δ;Γ} ⊨ e2 ≤log≤ e2' : τ2 -∗
{E;Δ;Γ} ⊨ (e1;; e2) ≤log≤ (e1';; e2') : τ2.
```

The idea here is that we can also pick any *semantic* type to related
e1 and e1'. For instance, if both e1 and e1' are expressions of type
Nat then it is not necessarily the case that we can relate them at
that type -- they might reduce to two different numerals -- but
it *should* be the case that we can relate their effects, if it makes
sense. E.g.

((#l <- #1;; #0) ;; e) ≤ ((#l <- #1;; #1) ;; e)