doc-src/IsarRef/Thy/HOL_Specific.thy
changeset 44112 eb94cfaaf5d4
parent 44111 dfd4ef8e73f6
child 44113 66b189dc5b83
     1.1 --- a/doc-src/IsarRef/Thy/HOL_Specific.thy	Wed May 25 22:12:46 2011 +0200
     1.2 +++ b/doc-src/IsarRef/Thy/HOL_Specific.thy	Wed May 25 22:21:38 2011 +0200
     1.3 @@ -4,6 +4,754 @@
     1.4  
     1.5  chapter {* Isabelle/HOL \label{ch:hol} *}
     1.6  
     1.7 +section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
     1.8 +
     1.9 +text {*
    1.10 +  An \textbf{inductive definition} specifies the least predicate (or
    1.11 +  set) @{text R} closed under given rules: applying a rule to elements
    1.12 +  of @{text R} yields a result within @{text R}.  For example, a
    1.13 +  structural operational semantics is an inductive definition of an
    1.14 +  evaluation relation.
    1.15 +
    1.16 +  Dually, a \textbf{coinductive definition} specifies the greatest
    1.17 +  predicate~/ set @{text R} that is consistent with given rules: every
    1.18 +  element of @{text R} can be seen as arising by applying a rule to
    1.19 +  elements of @{text R}.  An important example is using bisimulation
    1.20 +  relations to formalise equivalence of processes and infinite data
    1.21 +  structures.
    1.22 +
    1.23 +  \medskip The HOL package is related to the ZF one, which is
    1.24 +  described in a separate paper,\footnote{It appeared in CADE
    1.25 +  \cite{paulson-CADE}; a longer version is distributed with Isabelle.}
    1.26 +  which you should refer to in case of difficulties.  The package is
    1.27 +  simpler than that of ZF thanks to implicit type-checking in HOL.
    1.28 +  The types of the (co)inductive predicates (or sets) determine the
    1.29 +  domain of the fixedpoint definition, and the package does not have
    1.30 +  to use inference rules for type-checking.
    1.31 +
    1.32 +  \begin{matharray}{rcl}
    1.33 +    @{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
    1.34 +    @{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
    1.35 +    @{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
    1.36 +    @{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
    1.37 +    @{attribute_def (HOL) mono} & : & @{text attribute} \\
    1.38 +  \end{matharray}
    1.39 +
    1.40 +  @{rail "
    1.41 +    (@@{command (HOL) inductive} | @@{command (HOL) inductive_set} |
    1.42 +      @@{command (HOL) coinductive} | @@{command (HOL) coinductive_set})
    1.43 +    @{syntax target}? @{syntax \"fixes\"} (@'for' @{syntax \"fixes\"})? \\
    1.44 +    (@'where' clauses)? (@'monos' @{syntax thmrefs})?
    1.45 +    ;
    1.46 +    clauses: (@{syntax thmdecl}? @{syntax prop} + '|')
    1.47 +    ;
    1.48 +    @@{attribute (HOL) mono} (() | 'add' | 'del')
    1.49 +  "}
    1.50 +
    1.51 +  \begin{description}
    1.52 +
    1.53 +  \item @{command (HOL) "inductive"} and @{command (HOL)
    1.54 +  "coinductive"} define (co)inductive predicates from the
    1.55 +  introduction rules given in the @{keyword "where"} part.  The
    1.56 +  optional @{keyword "for"} part contains a list of parameters of the
    1.57 +  (co)inductive predicates that remain fixed throughout the
    1.58 +  definition.  The optional @{keyword "monos"} section contains
    1.59 +  \emph{monotonicity theorems}, which are required for each operator
    1.60 +  applied to a recursive set in the introduction rules.  There
    1.61 +  \emph{must} be a theorem of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"},
    1.62 +  for each premise @{text "M R\<^sub>i t"} in an introduction rule!
    1.63 +
    1.64 +  \item @{command (HOL) "inductive_set"} and @{command (HOL)
    1.65 +  "coinductive_set"} are wrappers for to the previous commands,
    1.66 +  allowing the definition of (co)inductive sets.
    1.67 +
    1.68 +  \item @{attribute (HOL) mono} declares monotonicity rules.  These
    1.69 +  rule are involved in the automated monotonicity proof of @{command
    1.70 +  (HOL) "inductive"}.
    1.71 +
    1.72 +  \end{description}
    1.73 +*}
    1.74 +
    1.75 +
    1.76 +subsection {* Derived rules *}
    1.77 +
    1.78 +text {*
    1.79 +  Each (co)inductive definition @{text R} adds definitions to the
    1.80 +  theory and also proves some theorems:
    1.81 +
    1.82 +  \begin{description}
    1.83 +
    1.84 +  \item @{text R.intros} is the list of introduction rules as proven
    1.85 +  theorems, for the recursive predicates (or sets).  The rules are
    1.86 +  also available individually, using the names given them in the
    1.87 +  theory file;
    1.88 +
    1.89 +  \item @{text R.cases} is the case analysis (or elimination) rule;
    1.90 +
    1.91 +  \item @{text R.induct} or @{text R.coinduct} is the (co)induction
    1.92 +  rule.
    1.93 +
    1.94 +  \end{description}
    1.95 +
    1.96 +  When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
    1.97 +  defined simultaneously, the list of introduction rules is called
    1.98 +  @{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
    1.99 +  called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
   1.100 +  of mutual induction rules is called @{text
   1.101 +  "R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
   1.102 +*}
   1.103 +
   1.104 +
   1.105 +subsection {* Monotonicity theorems *}
   1.106 +
   1.107 +text {*
   1.108 +  Each theory contains a default set of theorems that are used in
   1.109 +  monotonicity proofs.  New rules can be added to this set via the
   1.110 +  @{attribute (HOL) mono} attribute.  The HOL theory @{text Inductive}
   1.111 +  shows how this is done.  In general, the following monotonicity
   1.112 +  theorems may be added:
   1.113 +
   1.114 +  \begin{itemize}
   1.115 +
   1.116 +  \item Theorems of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"}, for proving
   1.117 +  monotonicity of inductive definitions whose introduction rules have
   1.118 +  premises involving terms such as @{text "M R\<^sub>i t"}.
   1.119 +
   1.120 +  \item Monotonicity theorems for logical operators, which are of the
   1.121 +  general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}.  For example, in
   1.122 +  the case of the operator @{text "\<or>"}, the corresponding theorem is
   1.123 +  \[
   1.124 +  \infer{@{text "P\<^sub>1 \<or> P\<^sub>2 \<longrightarrow> Q\<^sub>1 \<or> Q\<^sub>2"}}{@{text "P\<^sub>1 \<longrightarrow> Q\<^sub>1"} & @{text "P\<^sub>2 \<longrightarrow> Q\<^sub>2"}}
   1.125 +  \]
   1.126 +
   1.127 +  \item De Morgan style equations for reasoning about the ``polarity''
   1.128 +  of expressions, e.g.
   1.129 +  \[
   1.130 +  @{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
   1.131 +  @{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
   1.132 +  \]
   1.133 +
   1.134 +  \item Equations for reducing complex operators to more primitive
   1.135 +  ones whose monotonicity can easily be proved, e.g.
   1.136 +  \[
   1.137 +  @{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
   1.138 +  @{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
   1.139 +  \]
   1.140 +
   1.141 +  \end{itemize}
   1.142 +
   1.143 +  %FIXME: Example of an inductive definition
   1.144 +*}
   1.145 +
   1.146 +
   1.147 +section {* Recursive functions \label{sec:recursion} *}
   1.148 +
   1.149 +text {*
   1.150 +  \begin{matharray}{rcl}
   1.151 +    @{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
   1.152 +    @{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
   1.153 +    @{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
   1.154 +    @{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
   1.155 +  \end{matharray}
   1.156 +
   1.157 +  @{rail "
   1.158 +    @@{command (HOL) primrec} @{syntax target}? @{syntax \"fixes\"} @'where' equations
   1.159 +    ;
   1.160 +    (@@{command (HOL) fun} | @@{command (HOL) function}) @{syntax target}? functionopts?
   1.161 +      @{syntax \"fixes\"} \\ @'where' equations
   1.162 +    ;
   1.163 +
   1.164 +    equations: (@{syntax thmdecl}? @{syntax prop} + '|')
   1.165 +    ;
   1.166 +    functionopts: '(' (('sequential' | 'domintros') + ',') ')'
   1.167 +    ;
   1.168 +    @@{command (HOL) termination} @{syntax term}?
   1.169 +  "}
   1.170 +
   1.171 +  \begin{description}
   1.172 +
   1.173 +  \item @{command (HOL) "primrec"} defines primitive recursive
   1.174 +  functions over datatypes, see also \cite{isabelle-HOL}.
   1.175 +
   1.176 +  \item @{command (HOL) "function"} defines functions by general
   1.177 +  wellfounded recursion. A detailed description with examples can be
   1.178 +  found in \cite{isabelle-function}. The function is specified by a
   1.179 +  set of (possibly conditional) recursive equations with arbitrary
   1.180 +  pattern matching. The command generates proof obligations for the
   1.181 +  completeness and the compatibility of patterns.
   1.182 +
   1.183 +  The defined function is considered partial, and the resulting
   1.184 +  simplification rules (named @{text "f.psimps"}) and induction rule
   1.185 +  (named @{text "f.pinduct"}) are guarded by a generated domain
   1.186 +  predicate @{text "f_dom"}. The @{command (HOL) "termination"}
   1.187 +  command can then be used to establish that the function is total.
   1.188 +
   1.189 +  \item @{command (HOL) "fun"} is a shorthand notation for ``@{command
   1.190 +  (HOL) "function"}~@{text "(sequential)"}, followed by automated
   1.191 +  proof attempts regarding pattern matching and termination.  See
   1.192 +  \cite{isabelle-function} for further details.
   1.193 +
   1.194 +  \item @{command (HOL) "termination"}~@{text f} commences a
   1.195 +  termination proof for the previously defined function @{text f}.  If
   1.196 +  this is omitted, the command refers to the most recent function
   1.197 +  definition.  After the proof is closed, the recursive equations and
   1.198 +  the induction principle is established.
   1.199 +
   1.200 +  \end{description}
   1.201 +
   1.202 +  Recursive definitions introduced by the @{command (HOL) "function"}
   1.203 +  command accommodate
   1.204 +  reasoning by induction (cf.\ \secref{sec:cases-induct}): rule @{text
   1.205 +  "c.induct"} (where @{text c} is the name of the function definition)
   1.206 +  refers to a specific induction rule, with parameters named according
   1.207 +  to the user-specified equations. Cases are numbered (starting from 1).
   1.208 +
   1.209 +  For @{command (HOL) "primrec"}, the induction principle coincides
   1.210 +  with structural recursion on the datatype the recursion is carried
   1.211 +  out.
   1.212 +
   1.213 +  The equations provided by these packages may be referred later as
   1.214 +  theorem list @{text "f.simps"}, where @{text f} is the (collective)
   1.215 +  name of the functions defined.  Individual equations may be named
   1.216 +  explicitly as well.
   1.217 +
   1.218 +  The @{command (HOL) "function"} command accepts the following
   1.219 +  options.
   1.220 +
   1.221 +  \begin{description}
   1.222 +
   1.223 +  \item @{text sequential} enables a preprocessor which disambiguates
   1.224 +  overlapping patterns by making them mutually disjoint.  Earlier
   1.225 +  equations take precedence over later ones.  This allows to give the
   1.226 +  specification in a format very similar to functional programming.
   1.227 +  Note that the resulting simplification and induction rules
   1.228 +  correspond to the transformed specification, not the one given
   1.229 +  originally. This usually means that each equation given by the user
   1.230 +  may result in several theorems.  Also note that this automatic
   1.231 +  transformation only works for ML-style datatype patterns.
   1.232 +
   1.233 +  \item @{text domintros} enables the automated generation of
   1.234 +  introduction rules for the domain predicate. While mostly not
   1.235 +  needed, they can be helpful in some proofs about partial functions.
   1.236 +
   1.237 +  \end{description}
   1.238 +*}
   1.239 +
   1.240 +
   1.241 +subsection {* Proof methods related to recursive definitions *}
   1.242 +
   1.243 +text {*
   1.244 +  \begin{matharray}{rcl}
   1.245 +    @{method_def (HOL) pat_completeness} & : & @{text method} \\
   1.246 +    @{method_def (HOL) relation} & : & @{text method} \\
   1.247 +    @{method_def (HOL) lexicographic_order} & : & @{text method} \\
   1.248 +    @{method_def (HOL) size_change} & : & @{text method} \\
   1.249 +  \end{matharray}
   1.250 +
   1.251 +  @{rail "
   1.252 +    @@{method (HOL) relation} @{syntax term}
   1.253 +    ;
   1.254 +    @@{method (HOL) lexicographic_order} (@{syntax clasimpmod} * )
   1.255 +    ;
   1.256 +    @@{method (HOL) size_change} ( orders (@{syntax clasimpmod} * ) )
   1.257 +    ;
   1.258 +    orders: ( 'max' | 'min' | 'ms' ) *
   1.259 +  "}
   1.260 +
   1.261 +  \begin{description}
   1.262 +
   1.263 +  \item @{method (HOL) pat_completeness} is a specialized method to
   1.264 +  solve goals regarding the completeness of pattern matching, as
   1.265 +  required by the @{command (HOL) "function"} package (cf.\
   1.266 +  \cite{isabelle-function}).
   1.267 +
   1.268 +  \item @{method (HOL) relation}~@{text R} introduces a termination
   1.269 +  proof using the relation @{text R}.  The resulting proof state will
   1.270 +  contain goals expressing that @{text R} is wellfounded, and that the
   1.271 +  arguments of recursive calls decrease with respect to @{text R}.
   1.272 +  Usually, this method is used as the initial proof step of manual
   1.273 +  termination proofs.
   1.274 +
   1.275 +  \item @{method (HOL) "lexicographic_order"} attempts a fully
   1.276 +  automated termination proof by searching for a lexicographic
   1.277 +  combination of size measures on the arguments of the function. The
   1.278 +  method accepts the same arguments as the @{method auto} method,
   1.279 +  which it uses internally to prove local descents.  The same context
   1.280 +  modifiers as for @{method auto} are accepted, see
   1.281 +  \secref{sec:clasimp}.
   1.282 +
   1.283 +  In case of failure, extensive information is printed, which can help
   1.284 +  to analyse the situation (cf.\ \cite{isabelle-function}).
   1.285 +
   1.286 +  \item @{method (HOL) "size_change"} also works on termination goals,
   1.287 +  using a variation of the size-change principle, together with a
   1.288 +  graph decomposition technique (see \cite{krauss_phd} for details).
   1.289 +  Three kinds of orders are used internally: @{text max}, @{text min},
   1.290 +  and @{text ms} (multiset), which is only available when the theory
   1.291 +  @{text Multiset} is loaded. When no order kinds are given, they are
   1.292 +  tried in order. The search for a termination proof uses SAT solving
   1.293 +  internally.
   1.294 +
   1.295 + For local descent proofs, the same context modifiers as for @{method
   1.296 +  auto} are accepted, see \secref{sec:clasimp}.
   1.297 +
   1.298 +  \end{description}
   1.299 +*}
   1.300 +
   1.301 +
   1.302 +subsection {* Functions with explicit partiality *}
   1.303 +
   1.304 +text {*
   1.305 +  \begin{matharray}{rcl}
   1.306 +    @{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
   1.307 +    @{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
   1.308 +  \end{matharray}
   1.309 +
   1.310 +  @{rail "
   1.311 +    @@{command (HOL) partial_function} @{syntax target}?
   1.312 +      '(' @{syntax nameref} ')' @{syntax \"fixes\"} \\
   1.313 +      @'where' @{syntax thmdecl}? @{syntax prop}
   1.314 +  "}
   1.315 +
   1.316 +  \begin{description}
   1.317 +
   1.318 +  \item @{command (HOL) "partial_function"}~@{text "(mode)"} defines
   1.319 +  recursive functions based on fixpoints in complete partial
   1.320 +  orders. No termination proof is required from the user or
   1.321 +  constructed internally. Instead, the possibility of non-termination
   1.322 +  is modelled explicitly in the result type, which contains an
   1.323 +  explicit bottom element.
   1.324 +
   1.325 +  Pattern matching and mutual recursion are currently not supported.
   1.326 +  Thus, the specification consists of a single function described by a
   1.327 +  single recursive equation.
   1.328 +
   1.329 +  There are no fixed syntactic restrictions on the body of the
   1.330 +  function, but the induced functional must be provably monotonic
   1.331 +  wrt.\ the underlying order.  The monotonicitity proof is performed
   1.332 +  internally, and the definition is rejected when it fails. The proof
   1.333 +  can be influenced by declaring hints using the
   1.334 +  @{attribute (HOL) partial_function_mono} attribute.
   1.335 +
   1.336 +  The mandatory @{text mode} argument specifies the mode of operation
   1.337 +  of the command, which directly corresponds to a complete partial
   1.338 +  order on the result type. By default, the following modes are
   1.339 +  defined:
   1.340 +
   1.341 +  \begin{description}
   1.342 +  \item @{text option} defines functions that map into the @{type
   1.343 +  option} type. Here, the value @{term None} is used to model a
   1.344 +  non-terminating computation. Monotonicity requires that if @{term
   1.345 +  None} is returned by a recursive call, then the overall result
   1.346 +  must also be @{term None}. This is best achieved through the use of
   1.347 +  the monadic operator @{const "Option.bind"}.
   1.348 +
   1.349 +  \item @{text tailrec} defines functions with an arbitrary result
   1.350 +  type and uses the slightly degenerated partial order where @{term
   1.351 +  "undefined"} is the bottom element.  Now, monotonicity requires that
   1.352 +  if @{term undefined} is returned by a recursive call, then the
   1.353 +  overall result must also be @{term undefined}. In practice, this is
   1.354 +  only satisfied when each recursive call is a tail call, whose result
   1.355 +  is directly returned. Thus, this mode of operation allows the
   1.356 +  definition of arbitrary tail-recursive functions.
   1.357 +  \end{description}
   1.358 +
   1.359 +  Experienced users may define new modes by instantiating the locale
   1.360 +  @{const "partial_function_definitions"} appropriately.
   1.361 +
   1.362 +  \item @{attribute (HOL) partial_function_mono} declares rules for
   1.363 +  use in the internal monononicity proofs of partial function
   1.364 +  definitions.
   1.365 +
   1.366 +  \end{description}
   1.367 +
   1.368 +*}
   1.369 +
   1.370 +
   1.371 +subsection {* Old-style recursive function definitions (TFL) *}
   1.372 +
   1.373 +text {*
   1.374 +  The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
   1.375 +  "recdef_tc"} for defining recursive are mostly obsolete; @{command
   1.376 +  (HOL) "function"} or @{command (HOL) "fun"} should be used instead.
   1.377 +
   1.378 +  \begin{matharray}{rcl}
   1.379 +    @{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
   1.380 +    @{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
   1.381 +  \end{matharray}
   1.382 +
   1.383 +  @{rail "
   1.384 +    @@{command (HOL) recdef} ('(' @'permissive' ')')? \\
   1.385 +      @{syntax name} @{syntax term} (@{syntax prop} +) hints?
   1.386 +    ;
   1.387 +    recdeftc @{syntax thmdecl}? tc
   1.388 +    ;
   1.389 +    hints: '(' @'hints' ( recdefmod * ) ')'
   1.390 +    ;
   1.391 +    recdefmod: (('recdef_simp' | 'recdef_cong' | 'recdef_wf')
   1.392 +      (() | 'add' | 'del') ':' @{syntax thmrefs}) | @{syntax clasimpmod}
   1.393 +    ;
   1.394 +    tc: @{syntax nameref} ('(' @{syntax nat} ')')?
   1.395 +  "}
   1.396 +
   1.397 +  \begin{description}
   1.398 +
   1.399 +  \item @{command (HOL) "recdef"} defines general well-founded
   1.400 +  recursive functions (using the TFL package), see also
   1.401 +  \cite{isabelle-HOL}.  The ``@{text "(permissive)"}'' option tells
   1.402 +  TFL to recover from failed proof attempts, returning unfinished
   1.403 +  results.  The @{text recdef_simp}, @{text recdef_cong}, and @{text
   1.404 +  recdef_wf} hints refer to auxiliary rules to be used in the internal
   1.405 +  automated proof process of TFL.  Additional @{syntax clasimpmod}
   1.406 +  declarations (cf.\ \secref{sec:clasimp}) may be given to tune the
   1.407 +  context of the Simplifier (cf.\ \secref{sec:simplifier}) and
   1.408 +  Classical reasoner (cf.\ \secref{sec:classical}).
   1.409 +
   1.410 +  \item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
   1.411 +  proof for leftover termination condition number @{text i} (default
   1.412 +  1) as generated by a @{command (HOL) "recdef"} definition of
   1.413 +  constant @{text c}.
   1.414 +
   1.415 +  Note that in most cases, @{command (HOL) "recdef"} is able to finish
   1.416 +  its internal proofs without manual intervention.
   1.417 +
   1.418 +  \end{description}
   1.419 +
   1.420 +  \medskip Hints for @{command (HOL) "recdef"} may be also declared
   1.421 +  globally, using the following attributes.
   1.422 +
   1.423 +  \begin{matharray}{rcl}
   1.424 +    @{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
   1.425 +    @{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
   1.426 +    @{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
   1.427 +  \end{matharray}
   1.428 +
   1.429 +  @{rail "
   1.430 +    (@@{attribute (HOL) recdef_simp} | @@{attribute (HOL) recdef_cong} |
   1.431 +      @@{attribute (HOL) recdef_wf}) (() | 'add' | 'del')
   1.432 +  "}
   1.433 +*}
   1.434 +
   1.435 +
   1.436 +section {* Datatypes \label{sec:hol-datatype} *}
   1.437 +
   1.438 +text {*
   1.439 +  \begin{matharray}{rcl}
   1.440 +    @{command_def (HOL) "datatype"} & : & @{text "theory \<rightarrow> theory"} \\
   1.441 +    @{command_def (HOL) "rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
   1.442 +  \end{matharray}
   1.443 +
   1.444 +  @{rail "
   1.445 +    @@{command (HOL) datatype} (spec + @'and')
   1.446 +    ;
   1.447 +    @@{command (HOL) rep_datatype} ('(' (@{syntax name} +) ')')? (@{syntax term} +)
   1.448 +    ;
   1.449 +
   1.450 +    spec: @{syntax parname}? @{syntax typespec} @{syntax mixfix}? '=' (cons + '|')
   1.451 +    ;
   1.452 +    cons: @{syntax name} (@{syntax type} * ) @{syntax mixfix}?
   1.453 +  "}
   1.454 +
   1.455 +  \begin{description}
   1.456 +
   1.457 +  \item @{command (HOL) "datatype"} defines inductive datatypes in
   1.458 +  HOL.
   1.459 +
   1.460 +  \item @{command (HOL) "rep_datatype"} represents existing types as
   1.461 +  inductive ones, generating the standard infrastructure of derived
   1.462 +  concepts (primitive recursion etc.).
   1.463 +
   1.464 +  \end{description}
   1.465 +
   1.466 +  The induction and exhaustion theorems generated provide case names
   1.467 +  according to the constructors involved, while parameters are named
   1.468 +  after the types (see also \secref{sec:cases-induct}).
   1.469 +
   1.470 +  See \cite{isabelle-HOL} for more details on datatypes, but beware of
   1.471 +  the old-style theory syntax being used there!  Apart from proper
   1.472 +  proof methods for case-analysis and induction, there are also
   1.473 +  emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
   1.474 +  induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
   1.475 +  to refer directly to the internal structure of subgoals (including
   1.476 +  internally bound parameters).
   1.477 +*}
   1.478 +
   1.479 +
   1.480 +section {* Records \label{sec:hol-record} *}
   1.481 +
   1.482 +text {*
   1.483 +  In principle, records merely generalize the concept of tuples, where
   1.484 +  components may be addressed by labels instead of just position.  The
   1.485 +  logical infrastructure of records in Isabelle/HOL is slightly more
   1.486 +  advanced, though, supporting truly extensible record schemes.  This
   1.487 +  admits operations that are polymorphic with respect to record
   1.488 +  extension, yielding ``object-oriented'' effects like (single)
   1.489 +  inheritance.  See also \cite{NaraschewskiW-TPHOLs98} for more
   1.490 +  details on object-oriented verification and record subtyping in HOL.
   1.491 +*}
   1.492 +
   1.493 +
   1.494 +subsection {* Basic concepts *}
   1.495 +
   1.496 +text {*
   1.497 +  Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
   1.498 +  at the level of terms and types.  The notation is as follows:
   1.499 +
   1.500 +  \begin{center}
   1.501 +  \begin{tabular}{l|l|l}
   1.502 +    & record terms & record types \\ \hline
   1.503 +    fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
   1.504 +    schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
   1.505 +      @{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
   1.506 +  \end{tabular}
   1.507 +  \end{center}
   1.508 +
   1.509 +  \noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
   1.510 +  "(| x = a |)"}.
   1.511 +
   1.512 +  A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
   1.513 +  @{text a} and field @{text y} of value @{text b}.  The corresponding
   1.514 +  type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
   1.515 +  and @{text "b :: B"}.
   1.516 +
   1.517 +  A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
   1.518 +  @{text x} and @{text y} as before, but also possibly further fields
   1.519 +  as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
   1.520 +  of the syntax).  The improper field ``@{text "\<dots>"}'' of a record
   1.521 +  scheme is called the \emph{more part}.  Logically it is just a free
   1.522 +  variable, which is occasionally referred to as ``row variable'' in
   1.523 +  the literature.  The more part of a record scheme may be
   1.524 +  instantiated by zero or more further components.  For example, the
   1.525 +  previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
   1.526 +  c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
   1.527 +  Fixed records are special instances of record schemes, where
   1.528 +  ``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
   1.529 +  element.  In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
   1.530 +  for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
   1.531 +
   1.532 +  \medskip Two key observations make extensible records in a simply
   1.533 +  typed language like HOL work out:
   1.534 +
   1.535 +  \begin{enumerate}
   1.536 +
   1.537 +  \item the more part is internalized, as a free term or type
   1.538 +  variable,
   1.539 +
   1.540 +  \item field names are externalized, they cannot be accessed within
   1.541 +  the logic as first-class values.
   1.542 +
   1.543 +  \end{enumerate}
   1.544 +
   1.545 +  \medskip In Isabelle/HOL record types have to be defined explicitly,
   1.546 +  fixing their field names and types, and their (optional) parent
   1.547 +  record.  Afterwards, records may be formed using above syntax, while
   1.548 +  obeying the canonical order of fields as given by their declaration.
   1.549 +  The record package provides several standard operations like
   1.550 +  selectors and updates.  The common setup for various generic proof
   1.551 +  tools enable succinct reasoning patterns.  See also the Isabelle/HOL
   1.552 +  tutorial \cite{isabelle-hol-book} for further instructions on using
   1.553 +  records in practice.
   1.554 +*}
   1.555 +
   1.556 +
   1.557 +subsection {* Record specifications *}
   1.558 +
   1.559 +text {*
   1.560 +  \begin{matharray}{rcl}
   1.561 +    @{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
   1.562 +  \end{matharray}
   1.563 +
   1.564 +  @{rail "
   1.565 +    @@{command (HOL) record} @{syntax typespec_sorts} '=' \\
   1.566 +      (@{syntax type} '+')? (@{syntax constdecl} +)
   1.567 +  "}
   1.568 +
   1.569 +  \begin{description}
   1.570 +
   1.571 +  \item @{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1
   1.572 +  \<dots> c\<^sub>n :: \<sigma>\<^sub>n"} defines extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
   1.573 +  derived from the optional parent record @{text "\<tau>"} by adding new
   1.574 +  field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
   1.575 +
   1.576 +  The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
   1.577 +  covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
   1.578 +  \<alpha>\<^sub>m"}.  Type constructor @{text t} has to be new, while @{text
   1.579 +  \<tau>} needs to specify an instance of an existing record type.  At
   1.580 +  least one new field @{text "c\<^sub>i"} has to be specified.
   1.581 +  Basically, field names need to belong to a unique record.  This is
   1.582 +  not a real restriction in practice, since fields are qualified by
   1.583 +  the record name internally.
   1.584 +
   1.585 +  The parent record specification @{text \<tau>} is optional; if omitted
   1.586 +  @{text t} becomes a root record.  The hierarchy of all records
   1.587 +  declared within a theory context forms a forest structure, i.e.\ a
   1.588 +  set of trees starting with a root record each.  There is no way to
   1.589 +  merge multiple parent records!
   1.590 +
   1.591 +  For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
   1.592 +  type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
   1.593 +  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
   1.594 +  "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
   1.595 +  @{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
   1.596 +  \<zeta>\<rparr>"}.
   1.597 +
   1.598 +  \end{description}
   1.599 +*}
   1.600 +
   1.601 +
   1.602 +subsection {* Record operations *}
   1.603 +
   1.604 +text {*
   1.605 +  Any record definition of the form presented above produces certain
   1.606 +  standard operations.  Selectors and updates are provided for any
   1.607 +  field, including the improper one ``@{text more}''.  There are also
   1.608 +  cumulative record constructor functions.  To simplify the
   1.609 +  presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
   1.610 +  \<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
   1.611 +  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
   1.612 +
   1.613 +  \medskip \textbf{Selectors} and \textbf{updates} are available for
   1.614 +  any field (including ``@{text more}''):
   1.615 +
   1.616 +  \begin{matharray}{lll}
   1.617 +    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
   1.618 +    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
   1.619 +  \end{matharray}
   1.620 +
   1.621 +  There is special syntax for application of updates: @{text "r\<lparr>x :=
   1.622 +  a\<rparr>"} abbreviates term @{text "x_update a r"}.  Further notation for
   1.623 +  repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
   1.624 +  c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}.  Note that
   1.625 +  because of postfix notation the order of fields shown here is
   1.626 +  reverse than in the actual term.  Since repeated updates are just
   1.627 +  function applications, fields may be freely permuted in @{text "\<lparr>x
   1.628 +  := a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
   1.629 +  Thus commutativity of independent updates can be proven within the
   1.630 +  logic for any two fields, but not as a general theorem.
   1.631 +
   1.632 +  \medskip The \textbf{make} operation provides a cumulative record
   1.633 +  constructor function:
   1.634 +
   1.635 +  \begin{matharray}{lll}
   1.636 +    @{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.637 +  \end{matharray}
   1.638 +
   1.639 +  \medskip We now reconsider the case of non-root records, which are
   1.640 +  derived of some parent.  In general, the latter may depend on
   1.641 +  another parent as well, resulting in a list of \emph{ancestor
   1.642 +  records}.  Appending the lists of fields of all ancestors results in
   1.643 +  a certain field prefix.  The record package automatically takes care
   1.644 +  of this by lifting operations over this context of ancestor fields.
   1.645 +  Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
   1.646 +  fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
   1.647 +  the above record operations will get the following types:
   1.648 +
   1.649 +  \medskip
   1.650 +  \begin{tabular}{lll}
   1.651 +    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
   1.652 +    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow>
   1.653 +      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
   1.654 +      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
   1.655 +    @{text "t.make"} & @{text "::"} & @{text "\<rho>\<^sub>1 \<Rightarrow> \<dots> \<rho>\<^sub>k \<Rightarrow> \<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow>
   1.656 +      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.657 +  \end{tabular}
   1.658 +  \medskip
   1.659 +
   1.660 +  \noindent Some further operations address the extension aspect of a
   1.661 +  derived record scheme specifically: @{text "t.fields"} produces a
   1.662 +  record fragment consisting of exactly the new fields introduced here
   1.663 +  (the result may serve as a more part elsewhere); @{text "t.extend"}
   1.664 +  takes a fixed record and adds a given more part; @{text
   1.665 +  "t.truncate"} restricts a record scheme to a fixed record.
   1.666 +
   1.667 +  \medskip
   1.668 +  \begin{tabular}{lll}
   1.669 +    @{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.670 +    @{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
   1.671 +      \<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
   1.672 +    @{text "t.truncate"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.673 +  \end{tabular}
   1.674 +  \medskip
   1.675 +
   1.676 +  \noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
   1.677 +  for root records.
   1.678 +*}
   1.679 +
   1.680 +
   1.681 +subsection {* Derived rules and proof tools *}
   1.682 +
   1.683 +text {*
   1.684 +  The record package proves several results internally, declaring
   1.685 +  these facts to appropriate proof tools.  This enables users to
   1.686 +  reason about record structures quite conveniently.  Assume that
   1.687 +  @{text t} is a record type as specified above.
   1.688 +
   1.689 +  \begin{enumerate}
   1.690 +
   1.691 +  \item Standard conversions for selectors or updates applied to
   1.692 +  record constructor terms are made part of the default Simplifier
   1.693 +  context; thus proofs by reduction of basic operations merely require
   1.694 +  the @{method simp} method without further arguments.  These rules
   1.695 +  are available as @{text "t.simps"}, too.
   1.696 +
   1.697 +  \item Selectors applied to updated records are automatically reduced
   1.698 +  by an internal simplification procedure, which is also part of the
   1.699 +  standard Simplifier setup.
   1.700 +
   1.701 +  \item Inject equations of a form analogous to @{prop "(x, y) = (x',
   1.702 +  y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
   1.703 +  Reasoner as @{attribute iff} rules.  These rules are available as
   1.704 +  @{text "t.iffs"}.
   1.705 +
   1.706 +  \item The introduction rule for record equality analogous to @{text
   1.707 +  "x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
   1.708 +  and as the basic rule context as ``@{attribute intro}@{text "?"}''.
   1.709 +  The rule is called @{text "t.equality"}.
   1.710 +
   1.711 +  \item Representations of arbitrary record expressions as canonical
   1.712 +  constructor terms are provided both in @{method cases} and @{method
   1.713 +  induct} format (cf.\ the generic proof methods of the same name,
   1.714 +  \secref{sec:cases-induct}).  Several variations are available, for
   1.715 +  fixed records, record schemes, more parts etc.
   1.716 +
   1.717 +  The generic proof methods are sufficiently smart to pick the most
   1.718 +  sensible rule according to the type of the indicated record
   1.719 +  expression: users just need to apply something like ``@{text "(cases
   1.720 +  r)"}'' to a certain proof problem.
   1.721 +
   1.722 +  \item The derived record operations @{text "t.make"}, @{text
   1.723 +  "t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
   1.724 +  treated automatically, but usually need to be expanded by hand,
   1.725 +  using the collective fact @{text "t.defs"}.
   1.726 +
   1.727 +  \end{enumerate}
   1.728 +*}
   1.729 +
   1.730 +
   1.731 +section {* Adhoc tuples *}
   1.732 +
   1.733 +text {*
   1.734 +  \begin{matharray}{rcl}
   1.735 +    @{attribute_def (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
   1.736 +  \end{matharray}
   1.737 +
   1.738 +  @{rail "
   1.739 +    @@{attribute (HOL) split_format} ('(' 'complete' ')')?
   1.740 +  "}
   1.741 +
   1.742 +  \begin{description}
   1.743 +
   1.744 +  \item @{attribute (HOL) split_format}\ @{text "(complete)"} causes
   1.745 +  arguments in function applications to be represented canonically
   1.746 +  according to their tuple type structure.
   1.747 +
   1.748 +  Note that this operation tends to invent funny names for new local
   1.749 +  parameters introduced.
   1.750 +
   1.751 +  \end{description}
   1.752 +*}
   1.753 +
   1.754 +
   1.755  section {* Typedef axiomatization \label{sec:hol-typedef} *}
   1.756  
   1.757  text {* A Gordon/HOL-style type definition is a certain axiom scheme
   1.758 @@ -155,325 +903,6 @@
   1.759    primitive @{command typedef} above. *}
   1.760  
   1.761  
   1.762 -section {* Adhoc tuples *}
   1.763 -
   1.764 -text {*
   1.765 -  \begin{matharray}{rcl}
   1.766 -    @{attribute_def (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
   1.767 -  \end{matharray}
   1.768 -
   1.769 -  @{rail "
   1.770 -    @@{attribute (HOL) split_format} ('(' 'complete' ')')?
   1.771 -  "}
   1.772 -
   1.773 -  \begin{description}
   1.774 -
   1.775 -  \item @{attribute (HOL) split_format}\ @{text "(complete)"} causes
   1.776 -  arguments in function applications to be represented canonically
   1.777 -  according to their tuple type structure.
   1.778 -
   1.779 -  Note that this operation tends to invent funny names for new local
   1.780 -  parameters introduced.
   1.781 -
   1.782 -  \end{description}
   1.783 -*}
   1.784 -
   1.785 -
   1.786 -section {* Records \label{sec:hol-record} *}
   1.787 -
   1.788 -text {*
   1.789 -  In principle, records merely generalize the concept of tuples, where
   1.790 -  components may be addressed by labels instead of just position.  The
   1.791 -  logical infrastructure of records in Isabelle/HOL is slightly more
   1.792 -  advanced, though, supporting truly extensible record schemes.  This
   1.793 -  admits operations that are polymorphic with respect to record
   1.794 -  extension, yielding ``object-oriented'' effects like (single)
   1.795 -  inheritance.  See also \cite{NaraschewskiW-TPHOLs98} for more
   1.796 -  details on object-oriented verification and record subtyping in HOL.
   1.797 -*}
   1.798 -
   1.799 -
   1.800 -subsection {* Basic concepts *}
   1.801 -
   1.802 -text {*
   1.803 -  Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
   1.804 -  at the level of terms and types.  The notation is as follows:
   1.805 -
   1.806 -  \begin{center}
   1.807 -  \begin{tabular}{l|l|l}
   1.808 -    & record terms & record types \\ \hline
   1.809 -    fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
   1.810 -    schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
   1.811 -      @{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
   1.812 -  \end{tabular}
   1.813 -  \end{center}
   1.814 -
   1.815 -  \noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
   1.816 -  "(| x = a |)"}.
   1.817 -
   1.818 -  A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
   1.819 -  @{text a} and field @{text y} of value @{text b}.  The corresponding
   1.820 -  type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
   1.821 -  and @{text "b :: B"}.
   1.822 -
   1.823 -  A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
   1.824 -  @{text x} and @{text y} as before, but also possibly further fields
   1.825 -  as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
   1.826 -  of the syntax).  The improper field ``@{text "\<dots>"}'' of a record
   1.827 -  scheme is called the \emph{more part}.  Logically it is just a free
   1.828 -  variable, which is occasionally referred to as ``row variable'' in
   1.829 -  the literature.  The more part of a record scheme may be
   1.830 -  instantiated by zero or more further components.  For example, the
   1.831 -  previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
   1.832 -  c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
   1.833 -  Fixed records are special instances of record schemes, where
   1.834 -  ``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
   1.835 -  element.  In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
   1.836 -  for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
   1.837 -
   1.838 -  \medskip Two key observations make extensible records in a simply
   1.839 -  typed language like HOL work out:
   1.840 -
   1.841 -  \begin{enumerate}
   1.842 -
   1.843 -  \item the more part is internalized, as a free term or type
   1.844 -  variable,
   1.845 -
   1.846 -  \item field names are externalized, they cannot be accessed within
   1.847 -  the logic as first-class values.
   1.848 -
   1.849 -  \end{enumerate}
   1.850 -
   1.851 -  \medskip In Isabelle/HOL record types have to be defined explicitly,
   1.852 -  fixing their field names and types, and their (optional) parent
   1.853 -  record.  Afterwards, records may be formed using above syntax, while
   1.854 -  obeying the canonical order of fields as given by their declaration.
   1.855 -  The record package provides several standard operations like
   1.856 -  selectors and updates.  The common setup for various generic proof
   1.857 -  tools enable succinct reasoning patterns.  See also the Isabelle/HOL
   1.858 -  tutorial \cite{isabelle-hol-book} for further instructions on using
   1.859 -  records in practice.
   1.860 -*}
   1.861 -
   1.862 -
   1.863 -subsection {* Record specifications *}
   1.864 -
   1.865 -text {*
   1.866 -  \begin{matharray}{rcl}
   1.867 -    @{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
   1.868 -  \end{matharray}
   1.869 -
   1.870 -  @{rail "
   1.871 -    @@{command (HOL) record} @{syntax typespec_sorts} '=' \\
   1.872 -      (@{syntax type} '+')? (@{syntax constdecl} +)
   1.873 -  "}
   1.874 -
   1.875 -  \begin{description}
   1.876 -
   1.877 -  \item @{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1
   1.878 -  \<dots> c\<^sub>n :: \<sigma>\<^sub>n"} defines extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
   1.879 -  derived from the optional parent record @{text "\<tau>"} by adding new
   1.880 -  field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
   1.881 -
   1.882 -  The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
   1.883 -  covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
   1.884 -  \<alpha>\<^sub>m"}.  Type constructor @{text t} has to be new, while @{text
   1.885 -  \<tau>} needs to specify an instance of an existing record type.  At
   1.886 -  least one new field @{text "c\<^sub>i"} has to be specified.
   1.887 -  Basically, field names need to belong to a unique record.  This is
   1.888 -  not a real restriction in practice, since fields are qualified by
   1.889 -  the record name internally.
   1.890 -
   1.891 -  The parent record specification @{text \<tau>} is optional; if omitted
   1.892 -  @{text t} becomes a root record.  The hierarchy of all records
   1.893 -  declared within a theory context forms a forest structure, i.e.\ a
   1.894 -  set of trees starting with a root record each.  There is no way to
   1.895 -  merge multiple parent records!
   1.896 -
   1.897 -  For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
   1.898 -  type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
   1.899 -  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
   1.900 -  "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
   1.901 -  @{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
   1.902 -  \<zeta>\<rparr>"}.
   1.903 -
   1.904 -  \end{description}
   1.905 -*}
   1.906 -
   1.907 -
   1.908 -subsection {* Record operations *}
   1.909 -
   1.910 -text {*
   1.911 -  Any record definition of the form presented above produces certain
   1.912 -  standard operations.  Selectors and updates are provided for any
   1.913 -  field, including the improper one ``@{text more}''.  There are also
   1.914 -  cumulative record constructor functions.  To simplify the
   1.915 -  presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
   1.916 -  \<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
   1.917 -  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
   1.918 -
   1.919 -  \medskip \textbf{Selectors} and \textbf{updates} are available for
   1.920 -  any field (including ``@{text more}''):
   1.921 -
   1.922 -  \begin{matharray}{lll}
   1.923 -    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
   1.924 -    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
   1.925 -  \end{matharray}
   1.926 -
   1.927 -  There is special syntax for application of updates: @{text "r\<lparr>x :=
   1.928 -  a\<rparr>"} abbreviates term @{text "x_update a r"}.  Further notation for
   1.929 -  repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
   1.930 -  c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}.  Note that
   1.931 -  because of postfix notation the order of fields shown here is
   1.932 -  reverse than in the actual term.  Since repeated updates are just
   1.933 -  function applications, fields may be freely permuted in @{text "\<lparr>x
   1.934 -  := a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
   1.935 -  Thus commutativity of independent updates can be proven within the
   1.936 -  logic for any two fields, but not as a general theorem.
   1.937 -
   1.938 -  \medskip The \textbf{make} operation provides a cumulative record
   1.939 -  constructor function:
   1.940 -
   1.941 -  \begin{matharray}{lll}
   1.942 -    @{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.943 -  \end{matharray}
   1.944 -
   1.945 -  \medskip We now reconsider the case of non-root records, which are
   1.946 -  derived of some parent.  In general, the latter may depend on
   1.947 -  another parent as well, resulting in a list of \emph{ancestor
   1.948 -  records}.  Appending the lists of fields of all ancestors results in
   1.949 -  a certain field prefix.  The record package automatically takes care
   1.950 -  of this by lifting operations over this context of ancestor fields.
   1.951 -  Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
   1.952 -  fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
   1.953 -  the above record operations will get the following types:
   1.954 -
   1.955 -  \medskip
   1.956 -  \begin{tabular}{lll}
   1.957 -    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
   1.958 -    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow>
   1.959 -      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
   1.960 -      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
   1.961 -    @{text "t.make"} & @{text "::"} & @{text "\<rho>\<^sub>1 \<Rightarrow> \<dots> \<rho>\<^sub>k \<Rightarrow> \<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow>
   1.962 -      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.963 -  \end{tabular}
   1.964 -  \medskip
   1.965 -
   1.966 -  \noindent Some further operations address the extension aspect of a
   1.967 -  derived record scheme specifically: @{text "t.fields"} produces a
   1.968 -  record fragment consisting of exactly the new fields introduced here
   1.969 -  (the result may serve as a more part elsewhere); @{text "t.extend"}
   1.970 -  takes a fixed record and adds a given more part; @{text
   1.971 -  "t.truncate"} restricts a record scheme to a fixed record.
   1.972 -
   1.973 -  \medskip
   1.974 -  \begin{tabular}{lll}
   1.975 -    @{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.976 -    @{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
   1.977 -      \<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
   1.978 -    @{text "t.truncate"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
   1.979 -  \end{tabular}
   1.980 -  \medskip
   1.981 -
   1.982 -  \noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
   1.983 -  for root records.
   1.984 -*}
   1.985 -
   1.986 -
   1.987 -subsection {* Derived rules and proof tools *}
   1.988 -
   1.989 -text {*
   1.990 -  The record package proves several results internally, declaring
   1.991 -  these facts to appropriate proof tools.  This enables users to
   1.992 -  reason about record structures quite conveniently.  Assume that
   1.993 -  @{text t} is a record type as specified above.
   1.994 -
   1.995 -  \begin{enumerate}
   1.996 -
   1.997 -  \item Standard conversions for selectors or updates applied to
   1.998 -  record constructor terms are made part of the default Simplifier
   1.999 -  context; thus proofs by reduction of basic operations merely require
  1.1000 -  the @{method simp} method without further arguments.  These rules
  1.1001 -  are available as @{text "t.simps"}, too.
  1.1002 -
  1.1003 -  \item Selectors applied to updated records are automatically reduced
  1.1004 -  by an internal simplification procedure, which is also part of the
  1.1005 -  standard Simplifier setup.
  1.1006 -
  1.1007 -  \item Inject equations of a form analogous to @{prop "(x, y) = (x',
  1.1008 -  y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
  1.1009 -  Reasoner as @{attribute iff} rules.  These rules are available as
  1.1010 -  @{text "t.iffs"}.
  1.1011 -
  1.1012 -  \item The introduction rule for record equality analogous to @{text
  1.1013 -  "x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
  1.1014 -  and as the basic rule context as ``@{attribute intro}@{text "?"}''.
  1.1015 -  The rule is called @{text "t.equality"}.
  1.1016 -
  1.1017 -  \item Representations of arbitrary record expressions as canonical
  1.1018 -  constructor terms are provided both in @{method cases} and @{method
  1.1019 -  induct} format (cf.\ the generic proof methods of the same name,
  1.1020 -  \secref{sec:cases-induct}).  Several variations are available, for
  1.1021 -  fixed records, record schemes, more parts etc.
  1.1022 -
  1.1023 -  The generic proof methods are sufficiently smart to pick the most
  1.1024 -  sensible rule according to the type of the indicated record
  1.1025 -  expression: users just need to apply something like ``@{text "(cases
  1.1026 -  r)"}'' to a certain proof problem.
  1.1027 -
  1.1028 -  \item The derived record operations @{text "t.make"}, @{text
  1.1029 -  "t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
  1.1030 -  treated automatically, but usually need to be expanded by hand,
  1.1031 -  using the collective fact @{text "t.defs"}.
  1.1032 -
  1.1033 -  \end{enumerate}
  1.1034 -*}
  1.1035 -
  1.1036 -
  1.1037 -section {* Datatypes \label{sec:hol-datatype} *}
  1.1038 -
  1.1039 -text {*
  1.1040 -  \begin{matharray}{rcl}
  1.1041 -    @{command_def (HOL) "datatype"} & : & @{text "theory \<rightarrow> theory"} \\
  1.1042 -    @{command_def (HOL) "rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
  1.1043 -  \end{matharray}
  1.1044 -
  1.1045 -  @{rail "
  1.1046 -    @@{command (HOL) datatype} (spec + @'and')
  1.1047 -    ;
  1.1048 -    @@{command (HOL) rep_datatype} ('(' (@{syntax name} +) ')')? (@{syntax term} +)
  1.1049 -    ;
  1.1050 -
  1.1051 -    spec: @{syntax parname}? @{syntax typespec} @{syntax mixfix}? '=' (cons + '|')
  1.1052 -    ;
  1.1053 -    cons: @{syntax name} (@{syntax type} * ) @{syntax mixfix}?
  1.1054 -  "}
  1.1055 -
  1.1056 -  \begin{description}
  1.1057 -
  1.1058 -  \item @{command (HOL) "datatype"} defines inductive datatypes in
  1.1059 -  HOL.
  1.1060 -
  1.1061 -  \item @{command (HOL) "rep_datatype"} represents existing types as
  1.1062 -  inductive ones, generating the standard infrastructure of derived
  1.1063 -  concepts (primitive recursion etc.).
  1.1064 -
  1.1065 -  \end{description}
  1.1066 -
  1.1067 -  The induction and exhaustion theorems generated provide case names
  1.1068 -  according to the constructors involved, while parameters are named
  1.1069 -  after the types (see also \secref{sec:cases-induct}).
  1.1070 -
  1.1071 -  See \cite{isabelle-HOL} for more details on datatypes, but beware of
  1.1072 -  the old-style theory syntax being used there!  Apart from proper
  1.1073 -  proof methods for case-analysis and induction, there are also
  1.1074 -  emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
  1.1075 -  induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
  1.1076 -  to refer directly to the internal structure of subgoals (including
  1.1077 -  internally bound parameters).
  1.1078 -*}
  1.1079 -
  1.1080 -
  1.1081  section {* Functorial structure of types *}
  1.1082  
  1.1083  text {*
  1.1084 @@ -517,433 +946,6 @@
  1.1085  *}
  1.1086  
  1.1087  
  1.1088 -section {* Recursive functions \label{sec:recursion} *}
  1.1089 -
  1.1090 -text {*
  1.1091 -  \begin{matharray}{rcl}
  1.1092 -    @{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1093 -    @{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1094 -    @{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
  1.1095 -    @{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
  1.1096 -  \end{matharray}
  1.1097 -
  1.1098 -  @{rail "
  1.1099 -    @@{command (HOL) primrec} @{syntax target}? @{syntax \"fixes\"} @'where' equations
  1.1100 -    ;
  1.1101 -    (@@{command (HOL) fun} | @@{command (HOL) function}) @{syntax target}? functionopts?
  1.1102 -      @{syntax \"fixes\"} \\ @'where' equations
  1.1103 -    ;
  1.1104 -
  1.1105 -    equations: (@{syntax thmdecl}? @{syntax prop} + '|')
  1.1106 -    ;
  1.1107 -    functionopts: '(' (('sequential' | 'domintros') + ',') ')'
  1.1108 -    ;
  1.1109 -    @@{command (HOL) termination} @{syntax term}?
  1.1110 -  "}
  1.1111 -
  1.1112 -  \begin{description}
  1.1113 -
  1.1114 -  \item @{command (HOL) "primrec"} defines primitive recursive
  1.1115 -  functions over datatypes, see also \cite{isabelle-HOL}.
  1.1116 -
  1.1117 -  \item @{command (HOL) "function"} defines functions by general
  1.1118 -  wellfounded recursion. A detailed description with examples can be
  1.1119 -  found in \cite{isabelle-function}. The function is specified by a
  1.1120 -  set of (possibly conditional) recursive equations with arbitrary
  1.1121 -  pattern matching. The command generates proof obligations for the
  1.1122 -  completeness and the compatibility of patterns.
  1.1123 -
  1.1124 -  The defined function is considered partial, and the resulting
  1.1125 -  simplification rules (named @{text "f.psimps"}) and induction rule
  1.1126 -  (named @{text "f.pinduct"}) are guarded by a generated domain
  1.1127 -  predicate @{text "f_dom"}. The @{command (HOL) "termination"}
  1.1128 -  command can then be used to establish that the function is total.
  1.1129 -
  1.1130 -  \item @{command (HOL) "fun"} is a shorthand notation for ``@{command
  1.1131 -  (HOL) "function"}~@{text "(sequential)"}, followed by automated
  1.1132 -  proof attempts regarding pattern matching and termination.  See
  1.1133 -  \cite{isabelle-function} for further details.
  1.1134 -
  1.1135 -  \item @{command (HOL) "termination"}~@{text f} commences a
  1.1136 -  termination proof for the previously defined function @{text f}.  If
  1.1137 -  this is omitted, the command refers to the most recent function
  1.1138 -  definition.  After the proof is closed, the recursive equations and
  1.1139 -  the induction principle is established.
  1.1140 -
  1.1141 -  \end{description}
  1.1142 -
  1.1143 -  Recursive definitions introduced by the @{command (HOL) "function"}
  1.1144 -  command accommodate
  1.1145 -  reasoning by induction (cf.\ \secref{sec:cases-induct}): rule @{text
  1.1146 -  "c.induct"} (where @{text c} is the name of the function definition)
  1.1147 -  refers to a specific induction rule, with parameters named according
  1.1148 -  to the user-specified equations. Cases are numbered (starting from 1).
  1.1149 -
  1.1150 -  For @{command (HOL) "primrec"}, the induction principle coincides
  1.1151 -  with structural recursion on the datatype the recursion is carried
  1.1152 -  out.
  1.1153 -
  1.1154 -  The equations provided by these packages may be referred later as
  1.1155 -  theorem list @{text "f.simps"}, where @{text f} is the (collective)
  1.1156 -  name of the functions defined.  Individual equations may be named
  1.1157 -  explicitly as well.
  1.1158 -
  1.1159 -  The @{command (HOL) "function"} command accepts the following
  1.1160 -  options.
  1.1161 -
  1.1162 -  \begin{description}
  1.1163 -
  1.1164 -  \item @{text sequential} enables a preprocessor which disambiguates
  1.1165 -  overlapping patterns by making them mutually disjoint.  Earlier
  1.1166 -  equations take precedence over later ones.  This allows to give the
  1.1167 -  specification in a format very similar to functional programming.
  1.1168 -  Note that the resulting simplification and induction rules
  1.1169 -  correspond to the transformed specification, not the one given
  1.1170 -  originally. This usually means that each equation given by the user
  1.1171 -  may result in several theorems.  Also note that this automatic
  1.1172 -  transformation only works for ML-style datatype patterns.
  1.1173 -
  1.1174 -  \item @{text domintros} enables the automated generation of
  1.1175 -  introduction rules for the domain predicate. While mostly not
  1.1176 -  needed, they can be helpful in some proofs about partial functions.
  1.1177 -
  1.1178 -  \end{description}
  1.1179 -*}
  1.1180 -
  1.1181 -
  1.1182 -subsection {* Proof methods related to recursive definitions *}
  1.1183 -
  1.1184 -text {*
  1.1185 -  \begin{matharray}{rcl}
  1.1186 -    @{method_def (HOL) pat_completeness} & : & @{text method} \\
  1.1187 -    @{method_def (HOL) relation} & : & @{text method} \\
  1.1188 -    @{method_def (HOL) lexicographic_order} & : & @{text method} \\
  1.1189 -    @{method_def (HOL) size_change} & : & @{text method} \\
  1.1190 -  \end{matharray}
  1.1191 -
  1.1192 -  @{rail "
  1.1193 -    @@{method (HOL) relation} @{syntax term}
  1.1194 -    ;
  1.1195 -    @@{method (HOL) lexicographic_order} (@{syntax clasimpmod} * )
  1.1196 -    ;
  1.1197 -    @@{method (HOL) size_change} ( orders (@{syntax clasimpmod} * ) )
  1.1198 -    ;
  1.1199 -    orders: ( 'max' | 'min' | 'ms' ) *
  1.1200 -  "}
  1.1201 -
  1.1202 -  \begin{description}
  1.1203 -
  1.1204 -  \item @{method (HOL) pat_completeness} is a specialized method to
  1.1205 -  solve goals regarding the completeness of pattern matching, as
  1.1206 -  required by the @{command (HOL) "function"} package (cf.\
  1.1207 -  \cite{isabelle-function}).
  1.1208 -
  1.1209 -  \item @{method (HOL) relation}~@{text R} introduces a termination
  1.1210 -  proof using the relation @{text R}.  The resulting proof state will
  1.1211 -  contain goals expressing that @{text R} is wellfounded, and that the
  1.1212 -  arguments of recursive calls decrease with respect to @{text R}.
  1.1213 -  Usually, this method is used as the initial proof step of manual
  1.1214 -  termination proofs.
  1.1215 -
  1.1216 -  \item @{method (HOL) "lexicographic_order"} attempts a fully
  1.1217 -  automated termination proof by searching for a lexicographic
  1.1218 -  combination of size measures on the arguments of the function. The
  1.1219 -  method accepts the same arguments as the @{method auto} method,
  1.1220 -  which it uses internally to prove local descents.  The same context
  1.1221 -  modifiers as for @{method auto} are accepted, see
  1.1222 -  \secref{sec:clasimp}.
  1.1223 -
  1.1224 -  In case of failure, extensive information is printed, which can help
  1.1225 -  to analyse the situation (cf.\ \cite{isabelle-function}).
  1.1226 -
  1.1227 -  \item @{method (HOL) "size_change"} also works on termination goals,
  1.1228 -  using a variation of the size-change principle, together with a
  1.1229 -  graph decomposition technique (see \cite{krauss_phd} for details).
  1.1230 -  Three kinds of orders are used internally: @{text max}, @{text min},
  1.1231 -  and @{text ms} (multiset), which is only available when the theory
  1.1232 -  @{text Multiset} is loaded. When no order kinds are given, they are
  1.1233 -  tried in order. The search for a termination proof uses SAT solving
  1.1234 -  internally.
  1.1235 -
  1.1236 - For local descent proofs, the same context modifiers as for @{method
  1.1237 -  auto} are accepted, see \secref{sec:clasimp}.
  1.1238 -
  1.1239 -  \end{description}
  1.1240 -*}
  1.1241 -
  1.1242 -subsection {* Functions with explicit partiality *}
  1.1243 -
  1.1244 -text {*
  1.1245 -  \begin{matharray}{rcl}
  1.1246 -    @{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1247 -    @{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
  1.1248 -  \end{matharray}
  1.1249 -
  1.1250 -  @{rail "
  1.1251 -    @@{command (HOL) partial_function} @{syntax target}?
  1.1252 -      '(' @{syntax nameref} ')' @{syntax \"fixes\"} \\
  1.1253 -      @'where' @{syntax thmdecl}? @{syntax prop}
  1.1254 -  "}
  1.1255 -
  1.1256 -  \begin{description}
  1.1257 -
  1.1258 -  \item @{command (HOL) "partial_function"}~@{text "(mode)"} defines
  1.1259 -  recursive functions based on fixpoints in complete partial
  1.1260 -  orders. No termination proof is required from the user or
  1.1261 -  constructed internally. Instead, the possibility of non-termination
  1.1262 -  is modelled explicitly in the result type, which contains an
  1.1263 -  explicit bottom element.
  1.1264 -
  1.1265 -  Pattern matching and mutual recursion are currently not supported.
  1.1266 -  Thus, the specification consists of a single function described by a
  1.1267 -  single recursive equation.
  1.1268 -
  1.1269 -  There are no fixed syntactic restrictions on the body of the
  1.1270 -  function, but the induced functional must be provably monotonic
  1.1271 -  wrt.\ the underlying order.  The monotonicitity proof is performed
  1.1272 -  internally, and the definition is rejected when it fails. The proof
  1.1273 -  can be influenced by declaring hints using the
  1.1274 -  @{attribute (HOL) partial_function_mono} attribute.
  1.1275 -
  1.1276 -  The mandatory @{text mode} argument specifies the mode of operation
  1.1277 -  of the command, which directly corresponds to a complete partial
  1.1278 -  order on the result type. By default, the following modes are
  1.1279 -  defined:
  1.1280 -
  1.1281 -  \begin{description}
  1.1282 -  \item @{text option} defines functions that map into the @{type
  1.1283 -  option} type. Here, the value @{term None} is used to model a
  1.1284 -  non-terminating computation. Monotonicity requires that if @{term
  1.1285 -  None} is returned by a recursive call, then the overall result
  1.1286 -  must also be @{term None}. This is best achieved through the use of
  1.1287 -  the monadic operator @{const "Option.bind"}.
  1.1288 -
  1.1289 -  \item @{text tailrec} defines functions with an arbitrary result
  1.1290 -  type and uses the slightly degenerated partial order where @{term
  1.1291 -  "undefined"} is the bottom element.  Now, monotonicity requires that
  1.1292 -  if @{term undefined} is returned by a recursive call, then the
  1.1293 -  overall result must also be @{term undefined}. In practice, this is
  1.1294 -  only satisfied when each recursive call is a tail call, whose result
  1.1295 -  is directly returned. Thus, this mode of operation allows the
  1.1296 -  definition of arbitrary tail-recursive functions.
  1.1297 -  \end{description}
  1.1298 -
  1.1299 -  Experienced users may define new modes by instantiating the locale
  1.1300 -  @{const "partial_function_definitions"} appropriately.
  1.1301 -
  1.1302 -  \item @{attribute (HOL) partial_function_mono} declares rules for
  1.1303 -  use in the internal monononicity proofs of partial function
  1.1304 -  definitions.
  1.1305 -
  1.1306 -  \end{description}
  1.1307 -
  1.1308 -*}
  1.1309 -
  1.1310 -subsection {* Old-style recursive function definitions (TFL) *}
  1.1311 -
  1.1312 -text {*
  1.1313 -  The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
  1.1314 -  "recdef_tc"} for defining recursive are mostly obsolete; @{command
  1.1315 -  (HOL) "function"} or @{command (HOL) "fun"} should be used instead.
  1.1316 -
  1.1317 -  \begin{matharray}{rcl}
  1.1318 -    @{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
  1.1319 -    @{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
  1.1320 -  \end{matharray}
  1.1321 -
  1.1322 -  @{rail "
  1.1323 -    @@{command (HOL) recdef} ('(' @'permissive' ')')? \\
  1.1324 -      @{syntax name} @{syntax term} (@{syntax prop} +) hints?
  1.1325 -    ;
  1.1326 -    recdeftc @{syntax thmdecl}? tc
  1.1327 -    ;
  1.1328 -    hints: '(' @'hints' ( recdefmod * ) ')'
  1.1329 -    ;
  1.1330 -    recdefmod: (('recdef_simp' | 'recdef_cong' | 'recdef_wf')
  1.1331 -      (() | 'add' | 'del') ':' @{syntax thmrefs}) | @{syntax clasimpmod}
  1.1332 -    ;
  1.1333 -    tc: @{syntax nameref} ('(' @{syntax nat} ')')?
  1.1334 -  "}
  1.1335 -
  1.1336 -  \begin{description}
  1.1337 -
  1.1338 -  \item @{command (HOL) "recdef"} defines general well-founded
  1.1339 -  recursive functions (using the TFL package), see also
  1.1340 -  \cite{isabelle-HOL}.  The ``@{text "(permissive)"}'' option tells
  1.1341 -  TFL to recover from failed proof attempts, returning unfinished
  1.1342 -  results.  The @{text recdef_simp}, @{text recdef_cong}, and @{text
  1.1343 -  recdef_wf} hints refer to auxiliary rules to be used in the internal
  1.1344 -  automated proof process of TFL.  Additional @{syntax clasimpmod}
  1.1345 -  declarations (cf.\ \secref{sec:clasimp}) may be given to tune the
  1.1346 -  context of the Simplifier (cf.\ \secref{sec:simplifier}) and
  1.1347 -  Classical reasoner (cf.\ \secref{sec:classical}).
  1.1348 -
  1.1349 -  \item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
  1.1350 -  proof for leftover termination condition number @{text i} (default
  1.1351 -  1) as generated by a @{command (HOL) "recdef"} definition of
  1.1352 -  constant @{text c}.
  1.1353 -
  1.1354 -  Note that in most cases, @{command (HOL) "recdef"} is able to finish
  1.1355 -  its internal proofs without manual intervention.
  1.1356 -
  1.1357 -  \end{description}
  1.1358 -
  1.1359 -  \medskip Hints for @{command (HOL) "recdef"} may be also declared
  1.1360 -  globally, using the following attributes.
  1.1361 -
  1.1362 -  \begin{matharray}{rcl}
  1.1363 -    @{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
  1.1364 -    @{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
  1.1365 -    @{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
  1.1366 -  \end{matharray}
  1.1367 -
  1.1368 -  @{rail "
  1.1369 -    (@@{attribute (HOL) recdef_simp} | @@{attribute (HOL) recdef_cong} |
  1.1370 -      @@{attribute (HOL) recdef_wf}) (() | 'add' | 'del')
  1.1371 -  "}
  1.1372 -*}
  1.1373 -
  1.1374 -
  1.1375 -section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
  1.1376 -
  1.1377 -text {*
  1.1378 -  An \textbf{inductive definition} specifies the least predicate (or
  1.1379 -  set) @{text R} closed under given rules: applying a rule to elements
  1.1380 -  of @{text R} yields a result within @{text R}.  For example, a
  1.1381 -  structural operational semantics is an inductive definition of an
  1.1382 -  evaluation relation.
  1.1383 -
  1.1384 -  Dually, a \textbf{coinductive definition} specifies the greatest
  1.1385 -  predicate~/ set @{text R} that is consistent with given rules: every
  1.1386 -  element of @{text R} can be seen as arising by applying a rule to
  1.1387 -  elements of @{text R}.  An important example is using bisimulation
  1.1388 -  relations to formalise equivalence of processes and infinite data
  1.1389 -  structures.
  1.1390 -
  1.1391 -  \medskip The HOL package is related to the ZF one, which is
  1.1392 -  described in a separate paper,\footnote{It appeared in CADE
  1.1393 -  \cite{paulson-CADE}; a longer version is distributed with Isabelle.}
  1.1394 -  which you should refer to in case of difficulties.  The package is
  1.1395 -  simpler than that of ZF thanks to implicit type-checking in HOL.
  1.1396 -  The types of the (co)inductive predicates (or sets) determine the
  1.1397 -  domain of the fixedpoint definition, and the package does not have
  1.1398 -  to use inference rules for type-checking.
  1.1399 -
  1.1400 -  \begin{matharray}{rcl}
  1.1401 -    @{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1402 -    @{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1403 -    @{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1404 -    @{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
  1.1405 -    @{attribute_def (HOL) mono} & : & @{text attribute} \\
  1.1406 -  \end{matharray}
  1.1407 -
  1.1408 -  @{rail "
  1.1409 -    (@@{command (HOL) inductive} | @@{command (HOL) inductive_set} |
  1.1410 -      @@{command (HOL) coinductive} | @@{command (HOL) coinductive_set})
  1.1411 -    @{syntax target}? @{syntax \"fixes\"} (@'for' @{syntax \"fixes\"})? \\
  1.1412 -    (@'where' clauses)? (@'monos' @{syntax thmrefs})?
  1.1413 -    ;
  1.1414 -    clauses: (@{syntax thmdecl}? @{syntax prop} + '|')
  1.1415 -    ;
  1.1416 -    @@{attribute (HOL) mono} (() | 'add' | 'del')
  1.1417 -  "}
  1.1418 -
  1.1419 -  \begin{description}
  1.1420 -
  1.1421 -  \item @{command (HOL) "inductive"} and @{command (HOL)
  1.1422 -  "coinductive"} define (co)inductive predicates from the
  1.1423 -  introduction rules given in the @{keyword "where"} part.  The
  1.1424 -  optional @{keyword "for"} part contains a list of parameters of the
  1.1425 -  (co)inductive predicates that remain fixed throughout the
  1.1426 -  definition.  The optional @{keyword "monos"} section contains
  1.1427 -  \emph{monotonicity theorems}, which are required for each operator
  1.1428 -  applied to a recursive set in the introduction rules.  There
  1.1429 -  \emph{must} be a theorem of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"},
  1.1430 -  for each premise @{text "M R\<^sub>i t"} in an introduction rule!
  1.1431 -
  1.1432 -  \item @{command (HOL) "inductive_set"} and @{command (HOL)
  1.1433 -  "coinductive_set"} are wrappers for to the previous commands,
  1.1434 -  allowing the definition of (co)inductive sets.
  1.1435 -
  1.1436 -  \item @{attribute (HOL) mono} declares monotonicity rules.  These
  1.1437 -  rule are involved in the automated monotonicity proof of @{command
  1.1438 -  (HOL) "inductive"}.
  1.1439 -
  1.1440 -  \end{description}
  1.1441 -*}
  1.1442 -
  1.1443 -
  1.1444 -subsection {* Derived rules *}
  1.1445 -
  1.1446 -text {*
  1.1447 -  Each (co)inductive definition @{text R} adds definitions to the
  1.1448 -  theory and also proves some theorems:
  1.1449 -
  1.1450 -  \begin{description}
  1.1451 -
  1.1452 -  \item @{text R.intros} is the list of introduction rules as proven
  1.1453 -  theorems, for the recursive predicates (or sets).  The rules are
  1.1454 -  also available individually, using the names given them in the
  1.1455 -  theory file;
  1.1456 -
  1.1457 -  \item @{text R.cases} is the case analysis (or elimination) rule;
  1.1458 -
  1.1459 -  \item @{text R.induct} or @{text R.coinduct} is the (co)induction
  1.1460 -  rule.
  1.1461 -
  1.1462 -  \end{description}
  1.1463 -
  1.1464 -  When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
  1.1465 -  defined simultaneously, the list of introduction rules is called
  1.1466 -  @{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
  1.1467 -  called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
  1.1468 -  of mutual induction rules is called @{text
  1.1469 -  "R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
  1.1470 -*}
  1.1471 -
  1.1472 -
  1.1473 -subsection {* Monotonicity theorems *}
  1.1474 -
  1.1475 -text {*
  1.1476 -  Each theory contains a default set of theorems that are used in
  1.1477 -  monotonicity proofs.  New rules can be added to this set via the
  1.1478 -  @{attribute (HOL) mono} attribute.  The HOL theory @{text Inductive}
  1.1479 -  shows how this is done.  In general, the following monotonicity
  1.1480 -  theorems may be added:
  1.1481 -
  1.1482 -  \begin{itemize}
  1.1483 -
  1.1484 -  \item Theorems of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"}, for proving
  1.1485 -  monotonicity of inductive definitions whose introduction rules have
  1.1486 -  premises involving terms such as @{text "M R\<^sub>i t"}.
  1.1487 -
  1.1488 -  \item Monotonicity theorems for logical operators, which are of the
  1.1489 -  general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}.  For example, in
  1.1490 -  the case of the operator @{text "\<or>"}, the corresponding theorem is
  1.1491 -  \[
  1.1492 -  \infer{@{text "P\<^sub>1 \<or> P\<^sub>2 \<longrightarrow> Q\<^sub>1 \<or> Q\<^sub>2"}}{@{text "P\<^sub>1 \<longrightarrow> Q\<^sub>1"} & @{text "P\<^sub>2 \<longrightarrow> Q\<^sub>2"}}
  1.1493 -  \]
  1.1494 -
  1.1495 -  \item De Morgan style equations for reasoning about the ``polarity''
  1.1496 -  of expressions, e.g.
  1.1497 -  \[
  1.1498 -  @{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
  1.1499 -  @{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
  1.1500 -  \]
  1.1501 -
  1.1502 -  \item Equations for reducing complex operators to more primitive
  1.1503 -  ones whose monotonicity can easily be proved, e.g.
  1.1504 -  \[
  1.1505 -  @{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
  1.1506 -  @{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
  1.1507 -  \]
  1.1508 -
  1.1509 -  \end{itemize}
  1.1510 -
  1.1511 -  %FIXME: Example of an inductive definition
  1.1512 -*}
  1.1513 -
  1.1514 -
  1.1515  section {* Arithmetic proof support *}
  1.1516  
  1.1517  text {*