Skip to content
Snippets Groups Projects
Commit 339e9d14 authored by Ralf Jung's avatar Ralf Jung
Browse files

adjust docs for new PreG pattern

parent ea832a21
No related branches found
No related tags found
No related merge requests found
...@@ -112,34 +112,31 @@ Proof. apply (heap_adequacy clientΣ)=> ?. apply client_safe. Qed. ...@@ -112,34 +112,31 @@ Proof. apply (heap_adequacy clientΣ)=> ?. apply client_safe. Qed.
Some Iris modules involve a form of "global state". For example, defining the Some Iris modules involve a form of "global state". For example, defining the
`↦` for HeapLang involves a piece of ghost state that matches the current `↦` for HeapLang involves a piece of ghost state that matches the current
physical heap. The `gname` of that ghost state must be picked once when the physical heap. The `gname` of that ghost state must be picked once when the
proof starts, and then globally known everywhere. Hence it is added to proof starts, and then globally known everywhere. Hence `gen_heapG`, the type
`gen_heapG`, the type class for the generalized heap module: class for the generalized heap module, bundles the usual `inG` assumptions
together with the `gname`:
```coq ```coq
Class gen_heapPreG (L V : Type) (Σ : gFunctors) `{Countable L} := {
gen_heap_preG_inG :> inG Σ (authR (gen_heapUR L V))
}.
Class gen_heapG (L V : Type) (Σ : gFunctors) `{Countable L} := { Class gen_heapG (L V : Type) (Σ : gFunctors) `{Countable L} := {
gen_heap_inG :> inG Σ (authR (gen_heapUR L V)); gen_heap_inG :> gen_heapPreG L V Σ;
gen_heap_name : gname gen_heap_name : gname
}. }.
``` ```
Such modules always need some kind of "initialization" to create an instance The `gen_heapPreG` typeclass (without the singleton data) is relevant for
of their type class. For example, the initialization for `heapG` is happening initialization, i.e., to create an instance of `gen_heapG`. This is happening as
as part of [`heap_adequacy`](iris_heap_lang/adequacy.v); this in turn uses part of [`heap_adequacy`](iris_heap_lang/adequacy.v) using the
the initialization lemma for `gen_heapG` from initialization lemma for `gen_heapG` from
[`gen_heap_init`](iris/base_logic/lib/gen_heap.v): [`gen_heap_init`](iris/base_logic/lib/gen_heap.v):
```coq ```coq
Lemma gen_heap_init `{gen_heapPreG L V Σ} σ : Lemma gen_heap_init `{gen_heapPreG L V Σ} σ :
(|==> _ : gen_heapG L V Σ, gen_heap_ctx σ)%I. (|==> _ : gen_heapG L V Σ, gen_heap_ctx σ)%I.
``` ```
These lemmas themselves only make assumptions the way normal modules (those These lemmas themselves only make assumptions the way normal modules (those
without global state) do, which are typically collected in a `somethingPreG` without global state) do. Just like in the normal case, `somethingPreG` type
type class (such as `gen_heapPreG`): classes have an `Instance` showing that a `subG` is enough to instantiate them:
```coq
Class gen_heapPreG (L V : Type) (Σ : gFunctors) `{Countable L} := {
gen_heap_preG_inG :> inG Σ (authR (gen_heapUR L V))
}.
```
Just like in the normal case, `somethingPreG` type classes have an `Instance`
showing that a `subG` is enough to instantiate them:
```coq ```coq
Instance subG_gen_heapPreG {Σ L V} `{Countable L} : Instance subG_gen_heapPreG {Σ L V} `{Countable L} :
subG (gen_heapΣ L V) Σ gen_heapPreG L V Σ. subG (gen_heapΣ L V) Σ gen_heapPreG L V Σ.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment