Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arch-split: Requalify enhancements #788

Merged
merged 4 commits into from
Jul 23, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 39 additions & 1 deletion docs/arch-split.md
Original file line number Diff line number Diff line change
Expand Up @@ -220,6 +220,10 @@ done for any type, constant or fact:
type, constant or fact, so that the unqualified name unambiguously denotes
the architecture-specific concept for the current architecture.

Note: the `requalify_*` commands will warn when the unqualified name is already
available in the global context (see: Dealing with name clashes). To suppress
this warning, pass `(aliasing)` as the first parameter.

We do this in a generic theory:

- `l4v/proof/invariant-abstract/ADT_AI.thy`
Expand Down Expand Up @@ -298,6 +302,40 @@ This disparity will only get worse as the Arch context grows bigger, and
might indicate the need for some alternative functionality.


### Requalifying into the Arch locale

The `requalify` commands support a target parameter, e.g.

```isabelle
requalify_facts (in Arch) user_mem_dom_cong
```

Which prevents exporting the name into the global theory context, exporting it
under `Arch.` instead:

```isabelle
thm user_mem_dom_cong (* ERROR *)
thm ARM.user_mem_dom_cong (* ok *)
thm Arch.user_mem_dom_cong (* ok *)
```

This functionality can be useful when we want to give an architecture-specific
constant/type/fact a generic name, but not mix it with generic namespace (see
also Dealing with name clashes, as this affects lookup order inside
interpretations).

One can target any locale in this fashion, although the usefulness to arch-split
is then decreased, since short names might not be visible past a naming prefix:

```isabelle
requalify_facts (in Some_Locale) ARM.user_mem_dom_cong

thm user_mem_dom_cong (* ERROR *)
thm ARM.user_mem_dom_cong (* ok *)
thm Some_Locale.user_mem_dom_cong (* ok *)
```


### Dealing with name clashes

Things are a bit more complicated when a generic theory needs to refer to an
Expand Down Expand Up @@ -327,7 +365,7 @@ term deriveCap (* In the Arch context, this is the deriveCap funct
term RetypeDecls_H.deriveCap (* This is the arch-generic deriveCap function. *)

(* The following makes Arch.deriveCap refer to the architecture-specific constant. *)
requalify_consts deriveCap
requalify_consts deriveCap (* Warning: Name "deriveCap" already exists in theory context *)

(* Unfortunately, the above also means that in a context in which Arch is interpreted,
`deriveCap` unqualified would refer to the arch-specific constant, which may break existing proofs.
Expand Down
1 change: 1 addition & 0 deletions lib/ROOT
Original file line number Diff line number Diff line change
Expand Up @@ -127,6 +127,7 @@ session LibTest (lib) in test = Refine +
Named_Eta_Test
Rules_Tac_Test
MonadicRewrite_Test
Requalify_Test
(* use virtual memory function as an example, only makes sense on ARM: *)
theories [condition = "L4V_ARCH_IS_ARM"]
CorresK_Test
Expand Down
Loading
Loading