17309
|
1 |
(*
|
|
2 |
File: TLA/Stfun.thy
|
|
3 |
ID: $Id$
|
3807
|
4 |
Author: Stephan Merz
|
6255
|
5 |
Copyright: 1998 University of Munich
|
3807
|
6 |
|
|
7 |
Theory Name: Stfun
|
|
8 |
Logic Image: HOL
|
|
9 |
|
6255
|
10 |
States and state functions for TLA as an "intensional" logic.
|
3807
|
11 |
*)
|
|
12 |
|
17309
|
13 |
theory Stfun
|
|
14 |
imports Intensional
|
|
15 |
begin
|
|
16 |
|
|
17 |
typedecl state
|
|
18 |
|
|
19 |
instance state :: world ..
|
3807
|
20 |
|
|
21 |
types
|
17309
|
22 |
'a stfun = "state => 'a"
|
|
23 |
stpred = "bool stfun"
|
3807
|
24 |
|
|
25 |
|
|
26 |
consts
|
6255
|
27 |
(* Formalizing type "state" would require formulas to be tagged with
|
|
28 |
their underlying state space and would result in a system that is
|
|
29 |
much harder to use. (Unlike Hoare logic or Unity, TLA has quantification
|
|
30 |
over state variables, and therefore one usually works with different
|
|
31 |
state spaces within a single specification.) Instead, "state" is just
|
|
32 |
an anonymous type whose only purpose is to provide "Skolem" constants.
|
|
33 |
Moreover, we do not define a type of state variables separate from that
|
|
34 |
of arbitrary state functions, again in order to simplify the definition
|
|
35 |
of flexible quantification later on. Nevertheless, we need to distinguish
|
|
36 |
state variables, mainly to define the enabledness of actions. The user
|
|
37 |
identifies (tuples of) "base" state variables in a specification via the
|
12607
|
38 |
"meta predicate" basevars, which is defined here.
|
3807
|
39 |
*)
|
6255
|
40 |
stvars :: "'a stfun => bool"
|
3807
|
41 |
|
|
42 |
syntax
|
17309
|
43 |
"PRED" :: "lift => 'a" ("PRED _")
|
|
44 |
"_stvars" :: "lift => bool" ("basevars _")
|
3807
|
45 |
|
|
46 |
translations
|
6255
|
47 |
"PRED P" => "(P::state => _)"
|
|
48 |
"_stvars" == "stvars"
|
3807
|
49 |
|
12607
|
50 |
defs
|
17309
|
51 |
(* Base variables may be assigned arbitrary (type-correct) values.
|
12607
|
52 |
Note that vs may be a tuple of variables. The correct identification
|
|
53 |
of base variables is up to the user who must take care not to
|
|
54 |
introduce an inconsistency. For example, "basevars (x,x)" would
|
|
55 |
definitely be inconsistent.
|
6255
|
56 |
*)
|
17309
|
57 |
basevars_def: "stvars vs == range vs = UNIV"
|
|
58 |
|
|
59 |
ML {* use_legacy_bindings (the_context ()) *}
|
3807
|
60 |
|
|
61 |
end
|