11479
|
1 |
(* Title: HOL/UNITY/State.thy
|
|
2 |
ID: $Id$
|
|
3 |
Author: Sidi O Ehmety, Computer Laboratory
|
|
4 |
Copyright 2001 University of Cambridge
|
|
5 |
|
12195
|
6 |
Formalizes UNITY-program states using dependent types so that:
|
11479
|
7 |
- variables are typed.
|
|
8 |
- the state space is uniform, common to all defined programs.
|
|
9 |
- variables can be quantified over.
|
|
10 |
*)
|
|
11 |
|
|
12 |
State = UNITYMisc +
|
|
13 |
|
12195
|
14 |
consts var::i
|
|
15 |
datatype var = Var("i:list(nat)")
|
|
16 |
type_intrs "[list_nat_into_univ]"
|
11479
|
17 |
|
|
18 |
consts
|
|
19 |
type_of :: i=>i
|
12195
|
20 |
some :: i
|
|
21 |
state :: i
|
|
22 |
st_set :: i =>o
|
|
23 |
translations
|
|
24 |
"state" == "Pi(var, type_of)"
|
11479
|
25 |
|
12195
|
26 |
defs
|
|
27 |
(* To prevent typing conditions (like `A<=state') from
|
|
28 |
being used in combination with the rules `constrains_weaken', etc. *)
|
|
29 |
st_set_def "st_set(A) == A<=state"
|
11479
|
30 |
|
|
31 |
rules
|
12195
|
32 |
some_assume "some:state"
|
11479
|
33 |
|
12195
|
34 |
(***
|
|
35 |
REMARKS:
|
|
36 |
1. The reason of indexing variables by lists instead of integers is that,
|
|
37 |
at the time I was writing this theory, translations like `foo == Var(#1)'
|
|
38 |
mysteriously provoke a syntactical error. Such translations are used
|
|
39 |
for introducing variable names when specifying programs.
|
11479
|
40 |
|
12195
|
41 |
2. State space `state' is required to be not empty. This requirement
|
|
42 |
can be achieved by definition: the space "PROD x:var. type_of(x) Un {0}"
|
|
43 |
includes the state `lam x:state. 0'. However, such definition leads to
|
|
44 |
complications later during program type-chinking. For example, to prove
|
|
45 |
that the assignment `foo:=#1' is well typed, for `foo' an integer
|
|
46 |
variable, we would have to show two things: (a) that #1 is an integer
|
|
47 |
but also (b) that #1 is different from 0. Hence axiom `some_assume'.
|
|
48 |
***)
|
11479
|
49 |
end |