src/HOL/TLA/Stfun.thy
author hoelzl
Fri Mar 22 10:41:43 2013 +0100 (2013-03-22)
changeset 51474 1e9e68247ad1
parent 42018 878f33040280
child 55382 9218fa411c15
permissions -rw-r--r--
generalize Bfun and Bseq to metric spaces; Bseq is an abbreviation for Bfun
wenzelm@35108
     1
(*  Title:      HOL/TLA/Stfun.thy
wenzelm@35108
     2
    Author:     Stephan Merz
wenzelm@35108
     3
    Copyright:  1998 University of Munich
wenzelm@21624
     4
*)
wenzelm@3807
     5
wenzelm@21624
     6
header {* States and state functions for TLA as an "intensional" logic *}
wenzelm@3807
     7
wenzelm@17309
     8
theory Stfun
wenzelm@17309
     9
imports Intensional
wenzelm@17309
    10
begin
wenzelm@17309
    11
wenzelm@17309
    12
typedecl state
wenzelm@17309
    13
haftmann@35318
    14
arities state :: world
wenzelm@3807
    15
wenzelm@42018
    16
type_synonym 'a stfun = "state => 'a"
wenzelm@42018
    17
type_synonym stpred  = "bool stfun"
wenzelm@3807
    18
wenzelm@3807
    19
wenzelm@3807
    20
consts
wenzelm@6255
    21
  (* Formalizing type "state" would require formulas to be tagged with
wenzelm@6255
    22
     their underlying state space and would result in a system that is
wenzelm@6255
    23
     much harder to use. (Unlike Hoare logic or Unity, TLA has quantification
wenzelm@6255
    24
     over state variables, and therefore one usually works with different
wenzelm@6255
    25
     state spaces within a single specification.) Instead, "state" is just
wenzelm@6255
    26
     an anonymous type whose only purpose is to provide "Skolem" constants.
wenzelm@6255
    27
     Moreover, we do not define a type of state variables separate from that
wenzelm@6255
    28
     of arbitrary state functions, again in order to simplify the definition
wenzelm@6255
    29
     of flexible quantification later on. Nevertheless, we need to distinguish
wenzelm@6255
    30
     state variables, mainly to define the enabledness of actions. The user
wenzelm@6255
    31
     identifies (tuples of) "base" state variables in a specification via the
wenzelm@12607
    32
     "meta predicate" basevars, which is defined here.
wenzelm@3807
    33
  *)
wenzelm@6255
    34
  stvars    :: "'a stfun => bool"
wenzelm@3807
    35
wenzelm@3807
    36
syntax
wenzelm@35354
    37
  "_PRED"   :: "lift => 'a"                          ("PRED _")
wenzelm@17309
    38
  "_stvars" :: "lift => bool"                        ("basevars _")
wenzelm@3807
    39
wenzelm@3807
    40
translations
wenzelm@6255
    41
  "PRED P"   =>  "(P::state => _)"
wenzelm@35108
    42
  "_stvars"  ==  "CONST stvars"
wenzelm@3807
    43
wenzelm@12607
    44
defs
wenzelm@17309
    45
  (* Base variables may be assigned arbitrary (type-correct) values.
wenzelm@12607
    46
     Note that vs may be a tuple of variables. The correct identification
wenzelm@12607
    47
     of base variables is up to the user who must take care not to
wenzelm@12607
    48
     introduce an inconsistency. For example, "basevars (x,x)" would
wenzelm@12607
    49
     definitely be inconsistent.
wenzelm@6255
    50
  *)
wenzelm@17309
    51
  basevars_def:  "stvars vs == range vs = UNIV"
wenzelm@17309
    52
wenzelm@21624
    53
wenzelm@21624
    54
lemma basevars: "!!vs. basevars vs ==> EX u. vs u = c"
wenzelm@21624
    55
  apply (unfold basevars_def)
wenzelm@21624
    56
  apply (rule_tac b = c and f = vs in rangeE)
wenzelm@21624
    57
   apply auto
wenzelm@21624
    58
  done
wenzelm@21624
    59
wenzelm@21624
    60
lemma base_pair1: "!!x y. basevars (x,y) ==> basevars x"
wenzelm@21624
    61
  apply (simp (no_asm) add: basevars_def)
wenzelm@21624
    62
  apply (rule equalityI)
wenzelm@21624
    63
   apply (rule subset_UNIV)
wenzelm@21624
    64
  apply (rule subsetI)
wenzelm@21624
    65
  apply (drule_tac c = "(xa, arbitrary) " in basevars)
wenzelm@21624
    66
  apply auto
wenzelm@21624
    67
  done
wenzelm@21624
    68
wenzelm@21624
    69
lemma base_pair2: "!!x y. basevars (x,y) ==> basevars y"
wenzelm@21624
    70
  apply (simp (no_asm) add: basevars_def)
wenzelm@21624
    71
  apply (rule equalityI)
wenzelm@21624
    72
   apply (rule subset_UNIV)
wenzelm@21624
    73
  apply (rule subsetI)
wenzelm@21624
    74
  apply (drule_tac c = "(arbitrary, xa) " in basevars)
wenzelm@21624
    75
  apply auto
wenzelm@21624
    76
  done
wenzelm@21624
    77
wenzelm@21624
    78
lemma base_pair: "!!x y. basevars (x,y) ==> basevars x & basevars y"
wenzelm@21624
    79
  apply (rule conjI)
wenzelm@21624
    80
  apply (erule base_pair1)
wenzelm@21624
    81
  apply (erule base_pair2)
wenzelm@21624
    82
  done
wenzelm@21624
    83
wenzelm@21624
    84
(* Since the unit type has just one value, any state function can be
wenzelm@21624
    85
   regarded as "base". The following axiom can sometimes be useful
wenzelm@21624
    86
   because it gives a trivial solution for "basevars" premises.
wenzelm@21624
    87
*)
wenzelm@21624
    88
lemma unit_base: "basevars (v::unit stfun)"
wenzelm@21624
    89
  apply (unfold basevars_def)
wenzelm@21624
    90
  apply auto
wenzelm@21624
    91
  done
wenzelm@21624
    92
wenzelm@21624
    93
lemma baseE: "[| basevars v; !!x. v x = c ==> Q |] ==> Q"
wenzelm@21624
    94
  apply (erule basevars [THEN exE])
wenzelm@21624
    95
  apply blast
wenzelm@21624
    96
  done
wenzelm@21624
    97
wenzelm@21624
    98
wenzelm@21624
    99
(* -------------------------------------------------------------------------------
wenzelm@21624
   100
   The following shows that there should not be duplicates in a "stvars" tuple:
wenzelm@21624
   101
*)
wenzelm@21624
   102
wenzelm@21624
   103
lemma "!!v. basevars (v::bool stfun, v) ==> False"
wenzelm@21624
   104
  apply (erule baseE)
wenzelm@21624
   105
  apply (subgoal_tac "(LIFT (v,v)) x = (True, False)")
wenzelm@21624
   106
   prefer 2
wenzelm@21624
   107
   apply assumption
wenzelm@21624
   108
  apply simp
wenzelm@21624
   109
  done
wenzelm@3807
   110
wenzelm@3807
   111
end