src/HOL/Library/State_Monad.thy
author krauss
Tue Jul 13 11:50:22 2010 +0200 (2010-07-13)
changeset 37791 0d6b64060543
parent 37751 89e16802b6cc
child 37817 71e5546b1965
permissions -rw-r--r--
State_Monad uses Monad_Syntax
haftmann@21192
     1
(*  Title:      HOL/Library/State_Monad.thy
haftmann@21192
     2
    Author:     Florian Haftmann, TU Muenchen
haftmann@21192
     3
*)
haftmann@21192
     4
haftmann@27487
     5
header {* Combinator syntax for generic, open state monads (single threaded monads) *}
haftmann@21192
     6
haftmann@21192
     7
theory State_Monad
krauss@37791
     8
imports Monad_Syntax
haftmann@21192
     9
begin
haftmann@21192
    10
haftmann@21192
    11
subsection {* Motivation *}
haftmann@21192
    12
haftmann@21192
    13
text {*
haftmann@21192
    14
  The logic HOL has no notion of constructor classes, so
haftmann@21192
    15
  it is not possible to model monads the Haskell way
haftmann@21192
    16
  in full genericity in Isabelle/HOL.
haftmann@21192
    17
  
haftmann@21192
    18
  However, this theory provides substantial support for
haftmann@21192
    19
  a very common class of monads: \emph{state monads}
haftmann@21192
    20
  (or \emph{single-threaded monads}, since a state
haftmann@21192
    21
  is transformed single-threaded).
haftmann@21192
    22
haftmann@21192
    23
  To enter from the Haskell world,
haftmann@21192
    24
  \url{http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm}
haftmann@21192
    25
  makes a good motivating start.  Here we just sketch briefly
haftmann@21192
    26
  how those monads enter the game of Isabelle/HOL.
haftmann@21192
    27
*}
haftmann@21192
    28
haftmann@21192
    29
subsection {* State transformations and combinators *}
haftmann@21192
    30
haftmann@21192
    31
text {*
haftmann@21192
    32
  We classify functions operating on states into two categories:
haftmann@21192
    33
haftmann@21192
    34
  \begin{description}
haftmann@21192
    35
    \item[transformations]
haftmann@26266
    36
      with type signature @{text "\<sigma> \<Rightarrow> \<sigma>'"},
haftmann@21192
    37
      transforming a state.
haftmann@21192
    38
    \item[``yielding'' transformations]
haftmann@26266
    39
      with type signature @{text "\<sigma> \<Rightarrow> \<alpha> \<times> \<sigma>'"},
haftmann@21192
    40
      ``yielding'' a side result while transforming a state.
haftmann@21192
    41
    \item[queries]
haftmann@26266
    42
      with type signature @{text "\<sigma> \<Rightarrow> \<alpha>"},
haftmann@21192
    43
      computing a result dependent on a state.
haftmann@21192
    44
  \end{description}
haftmann@21192
    45
haftmann@26266
    46
  By convention we write @{text "\<sigma>"} for types representing states
haftmann@26266
    47
  and @{text "\<alpha>"}, @{text "\<beta>"}, @{text "\<gamma>"}, @{text "\<dots>"}
haftmann@21192
    48
  for types representing side results.  Type changes due
haftmann@21192
    49
  to transformations are not excluded in our scenario.
haftmann@21192
    50
haftmann@26266
    51
  We aim to assert that values of any state type @{text "\<sigma>"}
haftmann@21192
    52
  are used in a single-threaded way: after application
haftmann@26266
    53
  of a transformation on a value of type @{text "\<sigma>"}, the
haftmann@21192
    54
  former value should not be used again.  To achieve this,
haftmann@21192
    55
  we use a set of monad combinators:
haftmann@21192
    56
*}
haftmann@21192
    57
haftmann@37751
    58
notation fcomp (infixl "\<circ>>" 60)
haftmann@37751
    59
notation (xsymbols) fcomp (infixl "\<circ>>" 60)
haftmann@28145
    60
notation scomp (infixl "o->" 60)
haftmann@37751
    61
notation (xsymbols) scomp (infixl "\<circ>\<rightarrow>" 60)
wenzelm@21404
    62
haftmann@26588
    63
abbreviation (input)
haftmann@26588
    64
  "return \<equiv> Pair"
wenzelm@21404
    65
haftmann@21192
    66
text {*
haftmann@21192
    67
  Given two transformations @{term f} and @{term g}, they
haftmann@37751
    68
  may be directly composed using the @{term "op \<circ>>"} combinator,
haftmann@37751
    69
  forming a forward composition: @{prop "(f \<circ>> g) s = f (g s)"}.
haftmann@21192
    70
haftmann@21192
    71
  After any yielding transformation, we bind the side result
haftmann@21192
    72
  immediately using a lambda abstraction.  This 
haftmann@37751
    73
  is the purpose of the @{term "op \<circ>\<rightarrow>"} combinator:
haftmann@37751
    74
  @{prop "(f \<circ>\<rightarrow> (\<lambda>x. g)) s = (let (x, s') = f s in g s')"}.
haftmann@21192
    75
haftmann@21192
    76
  For queries, the existing @{term "Let"} is appropriate.
haftmann@21192
    77
haftmann@21192
    78
  Naturally, a computation may yield a side result by pairing
haftmann@21192
    79
  it to the state from the left;  we introduce the
haftmann@21192
    80
  suggestive abbreviation @{term return} for this purpose.
haftmann@21192
    81
haftmann@21192
    82
  The most crucial distinction to Haskell is that we do
haftmann@21192
    83
  not need to introduce distinguished type constructors
haftmann@21192
    84
  for different kinds of state.  This has two consequences:
haftmann@21192
    85
  \begin{itemize}
haftmann@21192
    86
    \item The monad model does not state anything about
haftmann@21192
    87
       the kind of state; the model for the state is
haftmann@26260
    88
       completely orthogonal and may be
haftmann@26260
    89
       specified completely independently.
haftmann@21192
    90
    \item There is no distinguished type constructor
haftmann@21192
    91
       encapsulating away the state transformation, i.e.~transformations
haftmann@21192
    92
       may be applied directly without using any lifting
haftmann@21192
    93
       or providing and dropping units (``open monad'').
haftmann@21192
    94
    \item The type of states may change due to a transformation.
haftmann@21192
    95
  \end{itemize}
haftmann@21192
    96
*}
haftmann@21192
    97
haftmann@21192
    98
haftmann@21192
    99
subsection {* Monad laws *}
haftmann@21192
   100
haftmann@21192
   101
text {*
haftmann@21192
   102
  The common monadic laws hold and may also be used
haftmann@21192
   103
  as normalization rules for monadic expressions:
haftmann@21192
   104
*}
haftmann@21192
   105
haftmann@28145
   106
lemmas monad_simp = Pair_scomp scomp_Pair id_fcomp fcomp_id
haftmann@28145
   107
  scomp_scomp scomp_fcomp fcomp_scomp fcomp_assoc
haftmann@21192
   108
haftmann@21192
   109
text {*
haftmann@21192
   110
  Evaluation of monadic expressions by force:
haftmann@21192
   111
*}
haftmann@21192
   112
haftmann@28145
   113
lemmas monad_collapse = monad_simp fcomp_apply scomp_apply split_beta
haftmann@26260
   114
krauss@37791
   115
setup {*
krauss@37791
   116
  Adhoc_Overloading.add_variant @{const_name bindM} @{const_name scomp}
haftmann@21192
   117
*}
haftmann@21192
   118
haftmann@21418
   119
text {*
haftmann@31033
   120
  For an example, see HOL/Extraction/Higman.thy.
haftmann@21192
   121
*}
haftmann@21192
   122
wenzelm@22664
   123
end