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