doc-src/IsarRef/Thy/HOL_Specific.thy
author Cezary Kaliszyk <cezarykaliszyk@gmail.com>
Fri Feb 10 09:47:59 2012 +0100 (2012-02-10)
changeset 46448 f1201fac7398
parent 46447 f37da60a8cc6
child 46457 915af80f74b3
permissions -rw-r--r--
more specification of the quotient package in IsarRef
wenzelm@26840
     1
theory HOL_Specific
wenzelm@44055
     2
imports Base Main "~~/src/HOL/Library/Old_Recdef"
wenzelm@26840
     3
begin
wenzelm@26840
     4
wenzelm@26852
     5
chapter {* Isabelle/HOL \label{ch:hol} *}
wenzelm@26849
     6
wenzelm@42914
     7
section {* Higher-Order Logic *}
wenzelm@42914
     8
wenzelm@42914
     9
text {* Isabelle/HOL is based on Higher-Order Logic, a polymorphic
wenzelm@42914
    10
  version of Church's Simple Theory of Types.  HOL can be best
wenzelm@42914
    11
  understood as a simply-typed version of classical set theory.  The
wenzelm@42914
    12
  logic was first implemented in Gordon's HOL system
wenzelm@42914
    13
  \cite{mgordon-hol}.  It extends Church's original logic
wenzelm@42914
    14
  \cite{church40} by explicit type variables (naive polymorphism) and
wenzelm@42914
    15
  a sound axiomatization scheme for new types based on subsets of
wenzelm@42914
    16
  existing types.
wenzelm@42914
    17
wenzelm@42914
    18
  Andrews's book \cite{andrews86} is a full description of the
wenzelm@42914
    19
  original Church-style higher-order logic, with proofs of correctness
wenzelm@42914
    20
  and completeness wrt.\ certain set-theoretic interpretations.  The
wenzelm@42914
    21
  particular extensions of Gordon-style HOL are explained semantically
wenzelm@42914
    22
  in two chapters of the 1993 HOL book \cite{pitts93}.
wenzelm@42914
    23
wenzelm@42914
    24
  Experience with HOL over decades has demonstrated that higher-order
wenzelm@42914
    25
  logic is widely applicable in many areas of mathematics and computer
wenzelm@42914
    26
  science.  In a sense, Higher-Order Logic is simpler than First-Order
wenzelm@42914
    27
  Logic, because there are fewer restrictions and special cases.  Note
wenzelm@42914
    28
  that HOL is \emph{weaker} than FOL with axioms for ZF set theory,
wenzelm@42914
    29
  which is traditionally considered the standard foundation of regular
wenzelm@42914
    30
  mathematics, but for most applications this does not matter.  If you
wenzelm@42914
    31
  prefer ML to Lisp, you will probably prefer HOL to ZF.
wenzelm@42914
    32
wenzelm@42914
    33
  \medskip The syntax of HOL follows @{text "\<lambda>"}-calculus and
wenzelm@42914
    34
  functional programming.  Function application is curried.  To apply
wenzelm@42914
    35
  the function @{text f} of type @{text "\<tau>\<^sub>1 \<Rightarrow> \<tau>\<^sub>2 \<Rightarrow> \<tau>\<^sub>3"} to the
wenzelm@42914
    36
  arguments @{text a} and @{text b} in HOL, you simply write @{text "f
wenzelm@42914
    37
  a b"} (as in ML or Haskell).  There is no ``apply'' operator; the
wenzelm@42914
    38
  existing application of the Pure @{text "\<lambda>"}-calculus is re-used.
wenzelm@42914
    39
  Note that in HOL @{text "f (a, b)"} means ``@{text "f"} applied to
wenzelm@42914
    40
  the pair @{text "(a, b)"} (which is notation for @{text "Pair a
wenzelm@42914
    41
  b"}).  The latter typically introduces extra formal efforts that can
wenzelm@42914
    42
  be avoided by currying functions by default.  Explicit tuples are as
wenzelm@42914
    43
  infrequent in HOL formalizations as in good ML or Haskell programs.
wenzelm@42914
    44
wenzelm@42914
    45
  \medskip Isabelle/HOL has a distinct feel, compared to other
wenzelm@42914
    46
  object-logics like Isabelle/ZF.  It identifies object-level types
wenzelm@42914
    47
  with meta-level types, taking advantage of the default
wenzelm@42914
    48
  type-inference mechanism of Isabelle/Pure.  HOL fully identifies
wenzelm@42914
    49
  object-level functions with meta-level functions, with native
wenzelm@42914
    50
  abstraction and application.
wenzelm@42914
    51
wenzelm@42914
    52
  These identifications allow Isabelle to support HOL particularly
wenzelm@42914
    53
  nicely, but they also mean that HOL requires some sophistication
wenzelm@42914
    54
  from the user.  In particular, an understanding of Hindley-Milner
wenzelm@42914
    55
  type-inference with type-classes, which are both used extensively in
wenzelm@42914
    56
  the standard libraries and applications.  Beginners can set
wenzelm@42914
    57
  @{attribute show_types} or even @{attribute show_sorts} to get more
wenzelm@42914
    58
  explicit information about the result of type-inference.  *}
wenzelm@42914
    59
wenzelm@42914
    60
wenzelm@42908
    61
section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
wenzelm@42908
    62
wenzelm@42913
    63
text {* An \emph{inductive definition} specifies the least predicate
wenzelm@42913
    64
  or set @{text R} closed under given rules: applying a rule to
wenzelm@42913
    65
  elements of @{text R} yields a result within @{text R}.  For
wenzelm@42913
    66
  example, a structural operational semantics is an inductive
wenzelm@42913
    67
  definition of an evaluation relation.
wenzelm@42908
    68
wenzelm@42913
    69
  Dually, a \emph{coinductive definition} specifies the greatest
wenzelm@42913
    70
  predicate or set @{text R} that is consistent with given rules:
wenzelm@42913
    71
  every element of @{text R} can be seen as arising by applying a rule
wenzelm@42913
    72
  to elements of @{text R}.  An important example is using
wenzelm@42913
    73
  bisimulation relations to formalise equivalence of processes and
wenzelm@42913
    74
  infinite data structures.
wenzelm@42913
    75
  
wenzelm@42913
    76
  Both inductive and coinductive definitions are based on the
wenzelm@42913
    77
  Knaster-Tarski fixed-point theorem for complete lattices.  The
wenzelm@42913
    78
  collection of introduction rules given by the user determines a
wenzelm@42913
    79
  functor on subsets of set-theoretic relations.  The required
wenzelm@42913
    80
  monotonicity of the recursion scheme is proven as a prerequisite to
wenzelm@42913
    81
  the fixed-point definition and the resulting consequences.  This
wenzelm@42913
    82
  works by pushing inclusion through logical connectives and any other
wenzelm@42913
    83
  operator that might be wrapped around recursive occurrences of the
wenzelm@42913
    84
  defined relation: there must be a monotonicity theorem of the form
wenzelm@42913
    85
  @{text "A \<le> B \<Longrightarrow> \<M> A \<le> \<M> B"}, for each premise @{text "\<M> R t"} in an
wenzelm@42913
    86
  introduction rule.  The default rule declarations of Isabelle/HOL
wenzelm@42913
    87
  already take care of most common situations.
wenzelm@42907
    88
wenzelm@26849
    89
  \begin{matharray}{rcl}
wenzelm@42908
    90
    @{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
    91
    @{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
    92
    @{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
    93
    @{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
    94
    @{attribute_def (HOL) mono} & : & @{text attribute} \\
wenzelm@26849
    95
  \end{matharray}
wenzelm@26849
    96
wenzelm@42596
    97
  @{rail "
wenzelm@42908
    98
    (@@{command (HOL) inductive} | @@{command (HOL) inductive_set} |
wenzelm@42908
    99
      @@{command (HOL) coinductive} | @@{command (HOL) coinductive_set})
wenzelm@42913
   100
    @{syntax target}? \\
wenzelm@42913
   101
    @{syntax \"fixes\"} (@'for' @{syntax \"fixes\"})? (@'where' clauses)? \\
wenzelm@42913
   102
    (@'monos' @{syntax thmrefs})?
wenzelm@42908
   103
    ;
wenzelm@42908
   104
    clauses: (@{syntax thmdecl}? @{syntax prop} + '|')
wenzelm@42908
   105
    ;
wenzelm@42908
   106
    @@{attribute (HOL) mono} (() | 'add' | 'del')
wenzelm@42908
   107
  "}
wenzelm@42908
   108
wenzelm@42908
   109
  \begin{description}
wenzelm@42908
   110
wenzelm@42908
   111
  \item @{command (HOL) "inductive"} and @{command (HOL)
wenzelm@42913
   112
  "coinductive"} define (co)inductive predicates from the introduction
wenzelm@42913
   113
  rules.
wenzelm@42913
   114
wenzelm@42913
   115
  The propositions given as @{text "clauses"} in the @{keyword
wenzelm@42913
   116
  "where"} part are either rules of the usual @{text "\<And>/\<Longrightarrow>"} format
wenzelm@42913
   117
  (with arbitrary nesting), or equalities using @{text "\<equiv>"}.  The
wenzelm@42913
   118
  latter specifies extra-logical abbreviations in the sense of
wenzelm@42913
   119
  @{command_ref abbreviation}.  Introducing abstract syntax
wenzelm@42913
   120
  simultaneously with the actual introduction rules is occasionally
wenzelm@42913
   121
  useful for complex specifications.
wenzelm@42913
   122
wenzelm@42913
   123
  The optional @{keyword "for"} part contains a list of parameters of
wenzelm@42913
   124
  the (co)inductive predicates that remain fixed throughout the
wenzelm@42913
   125
  definition, in contrast to arguments of the relation that may vary
wenzelm@42913
   126
  in each occurrence within the given @{text "clauses"}.
wenzelm@42913
   127
wenzelm@42913
   128
  The optional @{keyword "monos"} declaration contains additional
wenzelm@42908
   129
  \emph{monotonicity theorems}, which are required for each operator
wenzelm@42913
   130
  applied to a recursive set in the introduction rules.
wenzelm@42908
   131
wenzelm@42908
   132
  \item @{command (HOL) "inductive_set"} and @{command (HOL)
wenzelm@42913
   133
  "coinductive_set"} are wrappers for to the previous commands for
wenzelm@42913
   134
  native HOL predicates.  This allows to define (co)inductive sets,
wenzelm@42913
   135
  where multiple arguments are simulated via tuples.
wenzelm@42908
   136
wenzelm@42913
   137
  \item @{attribute (HOL) mono} declares monotonicity rules in the
wenzelm@42913
   138
  context.  These rule are involved in the automated monotonicity
wenzelm@42913
   139
  proof of the above inductive and coinductive definitions.
wenzelm@42908
   140
wenzelm@42908
   141
  \end{description}
wenzelm@42908
   142
*}
wenzelm@42908
   143
wenzelm@42908
   144
wenzelm@42908
   145
subsection {* Derived rules *}
wenzelm@42908
   146
wenzelm@42913
   147
text {* A (co)inductive definition of @{text R} provides the following
wenzelm@42913
   148
  main theorems:
wenzelm@42908
   149
wenzelm@42908
   150
  \begin{description}
wenzelm@42908
   151
wenzelm@42908
   152
  \item @{text R.intros} is the list of introduction rules as proven
wenzelm@42908
   153
  theorems, for the recursive predicates (or sets).  The rules are
wenzelm@42908
   154
  also available individually, using the names given them in the
wenzelm@42908
   155
  theory file;
wenzelm@42908
   156
wenzelm@42908
   157
  \item @{text R.cases} is the case analysis (or elimination) rule;
wenzelm@42908
   158
wenzelm@42908
   159
  \item @{text R.induct} or @{text R.coinduct} is the (co)induction
bulwahn@44273
   160
  rule;
bulwahn@44273
   161
bulwahn@44273
   162
  \item @{text R.simps} is the equation unrolling the fixpoint of the
bulwahn@44273
   163
  predicate one step.
bulwahn@44273
   164
 
wenzelm@42908
   165
  \end{description}
wenzelm@42908
   166
wenzelm@42908
   167
  When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
wenzelm@42908
   168
  defined simultaneously, the list of introduction rules is called
wenzelm@42908
   169
  @{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
wenzelm@42908
   170
  called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
wenzelm@42908
   171
  of mutual induction rules is called @{text
wenzelm@42908
   172
  "R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
wenzelm@42908
   173
*}
wenzelm@42908
   174
wenzelm@42908
   175
wenzelm@42908
   176
subsection {* Monotonicity theorems *}
wenzelm@42908
   177
wenzelm@42913
   178
text {* The context maintains a default set of theorems that are used
wenzelm@42913
   179
  in monotonicity proofs.  New rules can be declared via the
wenzelm@42913
   180
  @{attribute (HOL) mono} attribute.  See the main Isabelle/HOL
wenzelm@42913
   181
  sources for some examples.  The general format of such monotonicity
wenzelm@42913
   182
  theorems is as follows:
wenzelm@42908
   183
wenzelm@42908
   184
  \begin{itemize}
wenzelm@42908
   185
wenzelm@42913
   186
  \item Theorems of the form @{text "A \<le> B \<Longrightarrow> \<M> A \<le> \<M> B"}, for proving
wenzelm@42908
   187
  monotonicity of inductive definitions whose introduction rules have
wenzelm@42913
   188
  premises involving terms such as @{text "\<M> R t"}.
wenzelm@42908
   189
wenzelm@42908
   190
  \item Monotonicity theorems for logical operators, which are of the
wenzelm@42908
   191
  general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}.  For example, in
wenzelm@42908
   192
  the case of the operator @{text "\<or>"}, the corresponding theorem is
wenzelm@42908
   193
  \[
wenzelm@42908
   194
  \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"}}
wenzelm@42908
   195
  \]
wenzelm@42908
   196
wenzelm@42908
   197
  \item De Morgan style equations for reasoning about the ``polarity''
wenzelm@42908
   198
  of expressions, e.g.
wenzelm@42908
   199
  \[
wenzelm@42908
   200
  @{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
wenzelm@42908
   201
  @{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
wenzelm@42908
   202
  \]
wenzelm@42908
   203
wenzelm@42908
   204
  \item Equations for reducing complex operators to more primitive
wenzelm@42908
   205
  ones whose monotonicity can easily be proved, e.g.
wenzelm@42908
   206
  \[
wenzelm@42908
   207
  @{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
wenzelm@42908
   208
  @{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
wenzelm@42908
   209
  \]
wenzelm@42908
   210
wenzelm@42908
   211
  \end{itemize}
wenzelm@42913
   212
*}
wenzelm@42908
   213
wenzelm@42913
   214
subsubsection {* Examples *}
wenzelm@42913
   215
wenzelm@42913
   216
text {* The finite powerset operator can be defined inductively like this: *}
wenzelm@42913
   217
wenzelm@42913
   218
inductive_set Fin :: "'a set \<Rightarrow> 'a set set" for A :: "'a set"
wenzelm@42913
   219
where
wenzelm@42913
   220
  empty: "{} \<in> Fin A"
wenzelm@42913
   221
| insert: "a \<in> A \<Longrightarrow> B \<in> Fin A \<Longrightarrow> insert a B \<in> Fin A"
wenzelm@42913
   222
wenzelm@42913
   223
text {* The accessible part of a relation is defined as follows: *}
wenzelm@42913
   224
wenzelm@42913
   225
inductive acc :: "('a \<Rightarrow> 'a \<Rightarrow> bool) \<Rightarrow> 'a \<Rightarrow> bool"
wenzelm@42913
   226
  for r :: "'a \<Rightarrow> 'a \<Rightarrow> bool"  (infix "\<prec>" 50)
wenzelm@42913
   227
where acc: "(\<And>y. y \<prec> x \<Longrightarrow> acc r y) \<Longrightarrow> acc r x"
wenzelm@42913
   228
wenzelm@42913
   229
text {* Common logical connectives can be easily characterized as
wenzelm@42913
   230
non-recursive inductive definitions with parameters, but without
wenzelm@42913
   231
arguments. *}
wenzelm@42913
   232
wenzelm@42913
   233
inductive AND for A B :: bool
wenzelm@42913
   234
where "A \<Longrightarrow> B \<Longrightarrow> AND A B"
wenzelm@42913
   235
wenzelm@42913
   236
inductive OR for A B :: bool
wenzelm@42913
   237
where "A \<Longrightarrow> OR A B"
wenzelm@42913
   238
  | "B \<Longrightarrow> OR A B"
wenzelm@42913
   239
wenzelm@42913
   240
inductive EXISTS for B :: "'a \<Rightarrow> bool"
wenzelm@42913
   241
where "B a \<Longrightarrow> EXISTS B"
wenzelm@42913
   242
wenzelm@42913
   243
text {* Here the @{text "cases"} or @{text "induct"} rules produced by
wenzelm@42913
   244
  the @{command inductive} package coincide with the expected
wenzelm@42913
   245
  elimination rules for Natural Deduction.  Already in the original
wenzelm@42913
   246
  article by Gerhard Gentzen \cite{Gentzen:1935} there is a hint that
wenzelm@42913
   247
  each connective can be characterized by its introductions, and the
wenzelm@42913
   248
  elimination can be constructed systematically. *}
wenzelm@42908
   249
wenzelm@42908
   250
wenzelm@42908
   251
section {* Recursive functions \label{sec:recursion} *}
wenzelm@42908
   252
wenzelm@42908
   253
text {*
wenzelm@42908
   254
  \begin{matharray}{rcl}
wenzelm@42908
   255
    @{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   256
    @{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   257
    @{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   258
    @{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   259
  \end{matharray}
wenzelm@42908
   260
wenzelm@42908
   261
  @{rail "
wenzelm@42908
   262
    @@{command (HOL) primrec} @{syntax target}? @{syntax \"fixes\"} @'where' equations
wenzelm@42908
   263
    ;
wenzelm@42908
   264
    (@@{command (HOL) fun} | @@{command (HOL) function}) @{syntax target}? functionopts?
wenzelm@42908
   265
      @{syntax \"fixes\"} \\ @'where' equations
wenzelm@26849
   266
    ;
wenzelm@26849
   267
wenzelm@42908
   268
    equations: (@{syntax thmdecl}? @{syntax prop} + '|')
wenzelm@26849
   269
    ;
wenzelm@42908
   270
    functionopts: '(' (('sequential' | 'domintros') + ',') ')'
wenzelm@26849
   271
    ;
wenzelm@42908
   272
    @@{command (HOL) termination} @{syntax term}?
wenzelm@42596
   273
  "}
wenzelm@26849
   274
wenzelm@28760
   275
  \begin{description}
wenzelm@42123
   276
wenzelm@42908
   277
  \item @{command (HOL) "primrec"} defines primitive recursive
wenzelm@42912
   278
  functions over datatypes (see also @{command_ref (HOL) datatype} and
wenzelm@42912
   279
  @{command_ref (HOL) rep_datatype}).  The given @{text equations}
wenzelm@42912
   280
  specify reduction rules that are produced by instantiating the
wenzelm@42912
   281
  generic combinator for primitive recursion that is available for
wenzelm@42912
   282
  each datatype.
wenzelm@42912
   283
wenzelm@42912
   284
  Each equation needs to be of the form:
wenzelm@42912
   285
wenzelm@42912
   286
  @{text [display] "f x\<^sub>1 \<dots> x\<^sub>m (C y\<^sub>1 \<dots> y\<^sub>k) z\<^sub>1 \<dots> z\<^sub>n = rhs"}
wenzelm@42912
   287
wenzelm@42912
   288
  such that @{text C} is a datatype constructor, @{text rhs} contains
wenzelm@42912
   289
  only the free variables on the left-hand side (or from the context),
wenzelm@42912
   290
  and all recursive occurrences of @{text "f"} in @{text "rhs"} are of
wenzelm@42912
   291
  the form @{text "f \<dots> y\<^sub>i \<dots>"} for some @{text i}.  At most one
wenzelm@42912
   292
  reduction rule for each constructor can be given.  The order does
wenzelm@42912
   293
  not matter.  For missing constructors, the function is defined to
wenzelm@42912
   294
  return a default value, but this equation is made difficult to
wenzelm@42912
   295
  access for users.
wenzelm@42912
   296
wenzelm@42912
   297
  The reduction rules are declared as @{attribute simp} by default,
wenzelm@42912
   298
  which enables standard proof methods like @{method simp} and
wenzelm@42912
   299
  @{method auto} to normalize expressions of @{text "f"} applied to
wenzelm@42912
   300
  datatype constructions, by simulating symbolic computation via
wenzelm@42912
   301
  rewriting.
wenzelm@35744
   302
wenzelm@42908
   303
  \item @{command (HOL) "function"} defines functions by general
wenzelm@42908
   304
  wellfounded recursion. A detailed description with examples can be
wenzelm@42908
   305
  found in \cite{isabelle-function}. The function is specified by a
wenzelm@42908
   306
  set of (possibly conditional) recursive equations with arbitrary
wenzelm@42908
   307
  pattern matching. The command generates proof obligations for the
wenzelm@42908
   308
  completeness and the compatibility of patterns.
wenzelm@42907
   309
wenzelm@42908
   310
  The defined function is considered partial, and the resulting
wenzelm@42908
   311
  simplification rules (named @{text "f.psimps"}) and induction rule
wenzelm@42908
   312
  (named @{text "f.pinduct"}) are guarded by a generated domain
wenzelm@42908
   313
  predicate @{text "f_dom"}. The @{command (HOL) "termination"}
wenzelm@42908
   314
  command can then be used to establish that the function is total.
wenzelm@42123
   315
wenzelm@42908
   316
  \item @{command (HOL) "fun"} is a shorthand notation for ``@{command
wenzelm@42908
   317
  (HOL) "function"}~@{text "(sequential)"}, followed by automated
wenzelm@42908
   318
  proof attempts regarding pattern matching and termination.  See
wenzelm@42908
   319
  \cite{isabelle-function} for further details.
wenzelm@42123
   320
wenzelm@42908
   321
  \item @{command (HOL) "termination"}~@{text f} commences a
wenzelm@42908
   322
  termination proof for the previously defined function @{text f}.  If
wenzelm@42908
   323
  this is omitted, the command refers to the most recent function
wenzelm@42908
   324
  definition.  After the proof is closed, the recursive equations and
wenzelm@42908
   325
  the induction principle is established.
wenzelm@26849
   326
wenzelm@28760
   327
  \end{description}
wenzelm@42907
   328
wenzelm@42908
   329
  Recursive definitions introduced by the @{command (HOL) "function"}
wenzelm@42912
   330
  command accommodate reasoning by induction (cf.\ @{method induct}):
wenzelm@42912
   331
  rule @{text "f.induct"} refers to a specific induction rule, with
wenzelm@42912
   332
  parameters named according to the user-specified equations. Cases
wenzelm@42912
   333
  are numbered starting from 1.  For @{command (HOL) "primrec"}, the
wenzelm@42912
   334
  induction principle coincides with structural recursion on the
wenzelm@42912
   335
  datatype where the recursion is carried out.
wenzelm@42908
   336
wenzelm@42908
   337
  The equations provided by these packages may be referred later as
wenzelm@42908
   338
  theorem list @{text "f.simps"}, where @{text f} is the (collective)
wenzelm@42908
   339
  name of the functions defined.  Individual equations may be named
wenzelm@42908
   340
  explicitly as well.
wenzelm@42908
   341
wenzelm@42908
   342
  The @{command (HOL) "function"} command accepts the following
wenzelm@42908
   343
  options.
wenzelm@42908
   344
wenzelm@42908
   345
  \begin{description}
wenzelm@42908
   346
wenzelm@42908
   347
  \item @{text sequential} enables a preprocessor which disambiguates
wenzelm@42908
   348
  overlapping patterns by making them mutually disjoint.  Earlier
wenzelm@42908
   349
  equations take precedence over later ones.  This allows to give the
wenzelm@42908
   350
  specification in a format very similar to functional programming.
wenzelm@42908
   351
  Note that the resulting simplification and induction rules
wenzelm@42908
   352
  correspond to the transformed specification, not the one given
wenzelm@42908
   353
  originally. This usually means that each equation given by the user
wenzelm@42908
   354
  may result in several theorems.  Also note that this automatic
wenzelm@42908
   355
  transformation only works for ML-style datatype patterns.
wenzelm@42908
   356
wenzelm@42908
   357
  \item @{text domintros} enables the automated generation of
wenzelm@42908
   358
  introduction rules for the domain predicate. While mostly not
wenzelm@42908
   359
  needed, they can be helpful in some proofs about partial functions.
wenzelm@42908
   360
wenzelm@42908
   361
  \end{description}
wenzelm@26849
   362
*}
wenzelm@26849
   363
wenzelm@42912
   364
subsubsection {* Example: evaluation of expressions *}
wenzelm@42912
   365
wenzelm@42912
   366
text {* Subsequently, we define mutual datatypes for arithmetic and
wenzelm@42912
   367
  boolean expressions, and use @{command primrec} for evaluation
wenzelm@42912
   368
  functions that follow the same recursive structure. *}
wenzelm@42912
   369
wenzelm@42912
   370
datatype 'a aexp =
wenzelm@42912
   371
    IF "'a bexp"  "'a aexp"  "'a aexp"
wenzelm@42912
   372
  | Sum "'a aexp"  "'a aexp"
wenzelm@42912
   373
  | Diff "'a aexp"  "'a aexp"
wenzelm@42912
   374
  | Var 'a
wenzelm@42912
   375
  | Num nat
wenzelm@42912
   376
and 'a bexp =
wenzelm@42912
   377
    Less "'a aexp"  "'a aexp"
wenzelm@42912
   378
  | And "'a bexp"  "'a bexp"
wenzelm@42912
   379
  | Neg "'a bexp"
wenzelm@42912
   380
wenzelm@42912
   381
wenzelm@42912
   382
text {* \medskip Evaluation of arithmetic and boolean expressions *}
wenzelm@42912
   383
wenzelm@42912
   384
primrec evala :: "('a \<Rightarrow> nat) \<Rightarrow> 'a aexp \<Rightarrow> nat"
wenzelm@42912
   385
  and evalb :: "('a \<Rightarrow> nat) \<Rightarrow> 'a bexp \<Rightarrow> bool"
wenzelm@42912
   386
where
wenzelm@42912
   387
  "evala env (IF b a1 a2) = (if evalb env b then evala env a1 else evala env a2)"
wenzelm@42912
   388
| "evala env (Sum a1 a2) = evala env a1 + evala env a2"
wenzelm@42912
   389
| "evala env (Diff a1 a2) = evala env a1 - evala env a2"
wenzelm@42912
   390
| "evala env (Var v) = env v"
wenzelm@42912
   391
| "evala env (Num n) = n"
wenzelm@42912
   392
| "evalb env (Less a1 a2) = (evala env a1 < evala env a2)"
wenzelm@42912
   393
| "evalb env (And b1 b2) = (evalb env b1 \<and> evalb env b2)"
wenzelm@42912
   394
| "evalb env (Neg b) = (\<not> evalb env b)"
wenzelm@42912
   395
wenzelm@42912
   396
text {* Since the value of an expression depends on the value of its
wenzelm@42912
   397
  variables, the functions @{const evala} and @{const evalb} take an
wenzelm@42912
   398
  additional parameter, an \emph{environment} that maps variables to
wenzelm@42912
   399
  their values.
wenzelm@42912
   400
wenzelm@42912
   401
  \medskip Substitution on expressions can be defined similarly.  The
wenzelm@42912
   402
  mapping @{text f} of type @{typ "'a \<Rightarrow> 'a aexp"} given as a
wenzelm@42912
   403
  parameter is lifted canonically on the types @{typ "'a aexp"} and
wenzelm@42912
   404
  @{typ "'a bexp"}, respectively.
wenzelm@42912
   405
*}
wenzelm@42912
   406
wenzelm@42912
   407
primrec substa :: "('a \<Rightarrow> 'b aexp) \<Rightarrow> 'a aexp \<Rightarrow> 'b aexp"
wenzelm@42912
   408
  and substb :: "('a \<Rightarrow> 'b aexp) \<Rightarrow> 'a bexp \<Rightarrow> 'b bexp"
wenzelm@42912
   409
where
wenzelm@42912
   410
  "substa f (IF b a1 a2) = IF (substb f b) (substa f a1) (substa f a2)"
wenzelm@42912
   411
| "substa f (Sum a1 a2) = Sum (substa f a1) (substa f a2)"
wenzelm@42912
   412
| "substa f (Diff a1 a2) = Diff (substa f a1) (substa f a2)"
wenzelm@42912
   413
| "substa f (Var v) = f v"
wenzelm@42912
   414
| "substa f (Num n) = Num n"
wenzelm@42912
   415
| "substb f (Less a1 a2) = Less (substa f a1) (substa f a2)"
wenzelm@42912
   416
| "substb f (And b1 b2) = And (substb f b1) (substb f b2)"
wenzelm@42912
   417
| "substb f (Neg b) = Neg (substb f b)"
wenzelm@42912
   418
wenzelm@42912
   419
text {* In textbooks about semantics one often finds substitution
wenzelm@42912
   420
  theorems, which express the relationship between substitution and
wenzelm@42912
   421
  evaluation.  For @{typ "'a aexp"} and @{typ "'a bexp"}, we can prove
wenzelm@42912
   422
  such a theorem by mutual induction, followed by simplification.
wenzelm@42912
   423
*}
wenzelm@42912
   424
wenzelm@42912
   425
lemma subst_one:
wenzelm@42912
   426
  "evala env (substa (Var (v := a')) a) = evala (env (v := evala env a')) a"
wenzelm@42912
   427
  "evalb env (substb (Var (v := a')) b) = evalb (env (v := evala env a')) b"
wenzelm@42912
   428
  by (induct a and b) simp_all
wenzelm@42912
   429
wenzelm@42912
   430
lemma subst_all:
wenzelm@42912
   431
  "evala env (substa s a) = evala (\<lambda>x. evala env (s x)) a"
wenzelm@42912
   432
  "evalb env (substb s b) = evalb (\<lambda>x. evala env (s x)) b"
wenzelm@42912
   433
  by (induct a and b) simp_all
wenzelm@42912
   434
wenzelm@42912
   435
wenzelm@42912
   436
subsubsection {* Example: a substitution function for terms *}
wenzelm@42912
   437
wenzelm@42912
   438
text {* Functions on datatypes with nested recursion are also defined
wenzelm@42912
   439
  by mutual primitive recursion. *}
wenzelm@42912
   440
wenzelm@42912
   441
datatype ('a, 'b) "term" = Var 'a | App 'b "('a, 'b) term list"
wenzelm@42912
   442
wenzelm@42912
   443
text {* A substitution function on type @{typ "('a, 'b) term"} can be
wenzelm@42912
   444
  defined as follows, by working simultaneously on @{typ "('a, 'b)
wenzelm@42912
   445
  term list"}: *}
wenzelm@42912
   446
wenzelm@42912
   447
primrec subst_term :: "('a \<Rightarrow> ('a, 'b) term) \<Rightarrow> ('a, 'b) term \<Rightarrow> ('a, 'b) term" and
wenzelm@42912
   448
  subst_term_list :: "('a \<Rightarrow> ('a, 'b) term) \<Rightarrow> ('a, 'b) term list \<Rightarrow> ('a, 'b) term list"
wenzelm@42912
   449
where
wenzelm@42912
   450
  "subst_term f (Var a) = f a"
wenzelm@42912
   451
| "subst_term f (App b ts) = App b (subst_term_list f ts)"
wenzelm@42912
   452
| "subst_term_list f [] = []"
wenzelm@42912
   453
| "subst_term_list f (t # ts) = subst_term f t # subst_term_list f ts"
wenzelm@42912
   454
wenzelm@42912
   455
text {* The recursion scheme follows the structure of the unfolded
wenzelm@42912
   456
  definition of type @{typ "('a, 'b) term"}.  To prove properties of this
wenzelm@42912
   457
  substitution function, mutual induction is needed:
wenzelm@42912
   458
*}
wenzelm@42912
   459
wenzelm@42912
   460
lemma "subst_term (subst_term f1 \<circ> f2) t = subst_term f1 (subst_term f2 t)" and
wenzelm@42912
   461
  "subst_term_list (subst_term f1 \<circ> f2) ts = subst_term_list f1 (subst_term_list f2 ts)"
wenzelm@42912
   462
  by (induct t and ts) simp_all
wenzelm@42912
   463
wenzelm@42912
   464
wenzelm@42912
   465
subsubsection {* Example: a map function for infinitely branching trees *}
wenzelm@42912
   466
wenzelm@42912
   467
text {* Defining functions on infinitely branching datatypes by
wenzelm@42912
   468
  primitive recursion is just as easy.
wenzelm@42912
   469
*}
wenzelm@42912
   470
wenzelm@42912
   471
datatype 'a tree = Atom 'a | Branch "nat \<Rightarrow> 'a tree"
wenzelm@42912
   472
wenzelm@42912
   473
primrec map_tree :: "('a \<Rightarrow> 'b) \<Rightarrow> 'a tree \<Rightarrow> 'b tree"
wenzelm@42912
   474
where
wenzelm@42912
   475
  "map_tree f (Atom a) = Atom (f a)"
wenzelm@42912
   476
| "map_tree f (Branch ts) = Branch (\<lambda>x. map_tree f (ts x))"
wenzelm@42912
   477
wenzelm@42912
   478
text {* Note that all occurrences of functions such as @{text ts}
wenzelm@42912
   479
  above must be applied to an argument.  In particular, @{term
wenzelm@42912
   480
  "map_tree f \<circ> ts"} is not allowed here. *}
wenzelm@42912
   481
wenzelm@42912
   482
text {* Here is a simple composition lemma for @{term map_tree}: *}
wenzelm@42912
   483
wenzelm@42912
   484
lemma "map_tree g (map_tree f t) = map_tree (g \<circ> f) t"
wenzelm@42912
   485
  by (induct t) simp_all
wenzelm@42912
   486
wenzelm@42907
   487
wenzelm@42908
   488
subsection {* Proof methods related to recursive definitions *}
wenzelm@26849
   489
wenzelm@26849
   490
text {*
wenzelm@26849
   491
  \begin{matharray}{rcl}
wenzelm@42908
   492
    @{method_def (HOL) pat_completeness} & : & @{text method} \\
wenzelm@42908
   493
    @{method_def (HOL) relation} & : & @{text method} \\
wenzelm@42908
   494
    @{method_def (HOL) lexicographic_order} & : & @{text method} \\
wenzelm@42908
   495
    @{method_def (HOL) size_change} & : & @{text method} \\
bulwahn@45944
   496
    @{method_def (HOL) induction_schema} & : & @{text method} \\
wenzelm@26849
   497
  \end{matharray}
wenzelm@26849
   498
wenzelm@42596
   499
  @{rail "
wenzelm@42908
   500
    @@{method (HOL) relation} @{syntax term}
wenzelm@42908
   501
    ;
wenzelm@42908
   502
    @@{method (HOL) lexicographic_order} (@{syntax clasimpmod} * )
wenzelm@42908
   503
    ;
wenzelm@42908
   504
    @@{method (HOL) size_change} ( orders (@{syntax clasimpmod} * ) )
wenzelm@42908
   505
    ;
bulwahn@45944
   506
    @@{method (HOL) induction_schema}
bulwahn@45944
   507
    ;
wenzelm@42908
   508
    orders: ( 'max' | 'min' | 'ms' ) *
wenzelm@42908
   509
  "}
wenzelm@42908
   510
wenzelm@42908
   511
  \begin{description}
wenzelm@42908
   512
wenzelm@42908
   513
  \item @{method (HOL) pat_completeness} is a specialized method to
wenzelm@42908
   514
  solve goals regarding the completeness of pattern matching, as
wenzelm@42908
   515
  required by the @{command (HOL) "function"} package (cf.\
wenzelm@42908
   516
  \cite{isabelle-function}).
wenzelm@42908
   517
wenzelm@42908
   518
  \item @{method (HOL) relation}~@{text R} introduces a termination
wenzelm@42908
   519
  proof using the relation @{text R}.  The resulting proof state will
wenzelm@42908
   520
  contain goals expressing that @{text R} is wellfounded, and that the
wenzelm@42908
   521
  arguments of recursive calls decrease with respect to @{text R}.
wenzelm@42908
   522
  Usually, this method is used as the initial proof step of manual
wenzelm@42908
   523
  termination proofs.
wenzelm@42908
   524
wenzelm@42908
   525
  \item @{method (HOL) "lexicographic_order"} attempts a fully
wenzelm@42908
   526
  automated termination proof by searching for a lexicographic
wenzelm@42908
   527
  combination of size measures on the arguments of the function. The
wenzelm@42908
   528
  method accepts the same arguments as the @{method auto} method,
wenzelm@42930
   529
  which it uses internally to prove local descents.  The @{syntax
wenzelm@42930
   530
  clasimpmod} modifiers are accepted (as for @{method auto}).
wenzelm@42908
   531
wenzelm@42908
   532
  In case of failure, extensive information is printed, which can help
wenzelm@42908
   533
  to analyse the situation (cf.\ \cite{isabelle-function}).
wenzelm@42908
   534
wenzelm@42908
   535
  \item @{method (HOL) "size_change"} also works on termination goals,
wenzelm@42908
   536
  using a variation of the size-change principle, together with a
wenzelm@42908
   537
  graph decomposition technique (see \cite{krauss_phd} for details).
wenzelm@42908
   538
  Three kinds of orders are used internally: @{text max}, @{text min},
wenzelm@42908
   539
  and @{text ms} (multiset), which is only available when the theory
wenzelm@42908
   540
  @{text Multiset} is loaded. When no order kinds are given, they are
wenzelm@42908
   541
  tried in order. The search for a termination proof uses SAT solving
wenzelm@42908
   542
  internally.
wenzelm@42908
   543
wenzelm@42930
   544
  For local descent proofs, the @{syntax clasimpmod} modifiers are
wenzelm@42930
   545
  accepted (as for @{method auto}).
wenzelm@42908
   546
bulwahn@45944
   547
  \item @{method (HOL) induction_schema} derives user-specified
bulwahn@45944
   548
   induction rules from well-founded induction and completeness of
bulwahn@45944
   549
   patterns. This factors out some operations that are done internally
bulwahn@45944
   550
   by the function package and makes them available separately. See
bulwahn@45944
   551
   @{file "~~/src/HOL/ex/Induction_Schema.thy"} for examples.
bulwahn@45944
   552
wenzelm@42908
   553
  \end{description}
wenzelm@42908
   554
*}
wenzelm@42908
   555
wenzelm@42908
   556
wenzelm@42908
   557
subsection {* Functions with explicit partiality *}
wenzelm@42908
   558
wenzelm@42908
   559
text {*
wenzelm@42908
   560
  \begin{matharray}{rcl}
wenzelm@42908
   561
    @{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   562
    @{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
wenzelm@42908
   563
  \end{matharray}
wenzelm@42908
   564
wenzelm@42908
   565
  @{rail "
wenzelm@42908
   566
    @@{command (HOL) partial_function} @{syntax target}?
wenzelm@42908
   567
      '(' @{syntax nameref} ')' @{syntax \"fixes\"} \\
wenzelm@42908
   568
      @'where' @{syntax thmdecl}? @{syntax prop}
wenzelm@42596
   569
  "}
wenzelm@26849
   570
wenzelm@28760
   571
  \begin{description}
wenzelm@42123
   572
wenzelm@42908
   573
  \item @{command (HOL) "partial_function"}~@{text "(mode)"} defines
wenzelm@42908
   574
  recursive functions based on fixpoints in complete partial
wenzelm@42908
   575
  orders. No termination proof is required from the user or
wenzelm@42908
   576
  constructed internally. Instead, the possibility of non-termination
wenzelm@42908
   577
  is modelled explicitly in the result type, which contains an
wenzelm@42908
   578
  explicit bottom element.
wenzelm@42908
   579
wenzelm@42908
   580
  Pattern matching and mutual recursion are currently not supported.
wenzelm@42908
   581
  Thus, the specification consists of a single function described by a
wenzelm@42908
   582
  single recursive equation.
wenzelm@42908
   583
wenzelm@42908
   584
  There are no fixed syntactic restrictions on the body of the
wenzelm@42908
   585
  function, but the induced functional must be provably monotonic
wenzelm@42908
   586
  wrt.\ the underlying order.  The monotonicitity proof is performed
wenzelm@42908
   587
  internally, and the definition is rejected when it fails. The proof
wenzelm@42908
   588
  can be influenced by declaring hints using the
wenzelm@42908
   589
  @{attribute (HOL) partial_function_mono} attribute.
wenzelm@42908
   590
wenzelm@42908
   591
  The mandatory @{text mode} argument specifies the mode of operation
wenzelm@42908
   592
  of the command, which directly corresponds to a complete partial
wenzelm@42908
   593
  order on the result type. By default, the following modes are
wenzelm@42908
   594
  defined:
wenzelm@26849
   595
wenzelm@42908
   596
  \begin{description}
wenzelm@42908
   597
  \item @{text option} defines functions that map into the @{type
wenzelm@42908
   598
  option} type. Here, the value @{term None} is used to model a
wenzelm@42908
   599
  non-terminating computation. Monotonicity requires that if @{term
wenzelm@42908
   600
  None} is returned by a recursive call, then the overall result
wenzelm@42908
   601
  must also be @{term None}. This is best achieved through the use of
wenzelm@42908
   602
  the monadic operator @{const "Option.bind"}.
wenzelm@42908
   603
wenzelm@42908
   604
  \item @{text tailrec} defines functions with an arbitrary result
wenzelm@42908
   605
  type and uses the slightly degenerated partial order where @{term
wenzelm@42908
   606
  "undefined"} is the bottom element.  Now, monotonicity requires that
wenzelm@42908
   607
  if @{term undefined} is returned by a recursive call, then the
wenzelm@42908
   608
  overall result must also be @{term undefined}. In practice, this is
wenzelm@42908
   609
  only satisfied when each recursive call is a tail call, whose result
wenzelm@42908
   610
  is directly returned. Thus, this mode of operation allows the
wenzelm@42908
   611
  definition of arbitrary tail-recursive functions.
wenzelm@42908
   612
  \end{description}
wenzelm@42908
   613
wenzelm@42908
   614
  Experienced users may define new modes by instantiating the locale
wenzelm@42908
   615
  @{const "partial_function_definitions"} appropriately.
wenzelm@42908
   616
wenzelm@42908
   617
  \item @{attribute (HOL) partial_function_mono} declares rules for
wenzelm@42908
   618
  use in the internal monononicity proofs of partial function
wenzelm@42908
   619
  definitions.
wenzelm@26849
   620
wenzelm@28760
   621
  \end{description}
wenzelm@42908
   622
wenzelm@42908
   623
*}
wenzelm@42908
   624
wenzelm@42908
   625
wenzelm@42908
   626
subsection {* Old-style recursive function definitions (TFL) *}
wenzelm@42908
   627
wenzelm@42908
   628
text {*
wenzelm@42908
   629
  The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
wenzelm@42908
   630
  "recdef_tc"} for defining recursive are mostly obsolete; @{command
wenzelm@42908
   631
  (HOL) "function"} or @{command (HOL) "fun"} should be used instead.
wenzelm@42908
   632
wenzelm@42908
   633
  \begin{matharray}{rcl}
wenzelm@42908
   634
    @{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
wenzelm@42908
   635
    @{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   636
  \end{matharray}
wenzelm@42908
   637
wenzelm@42908
   638
  @{rail "
wenzelm@42908
   639
    @@{command (HOL) recdef} ('(' @'permissive' ')')? \\
wenzelm@42908
   640
      @{syntax name} @{syntax term} (@{syntax prop} +) hints?
wenzelm@42908
   641
    ;
wenzelm@42908
   642
    recdeftc @{syntax thmdecl}? tc
wenzelm@42908
   643
    ;
wenzelm@42908
   644
    hints: '(' @'hints' ( recdefmod * ) ')'
wenzelm@42908
   645
    ;
wenzelm@42908
   646
    recdefmod: (('recdef_simp' | 'recdef_cong' | 'recdef_wf')
wenzelm@42908
   647
      (() | 'add' | 'del') ':' @{syntax thmrefs}) | @{syntax clasimpmod}
wenzelm@42908
   648
    ;
wenzelm@42908
   649
    tc: @{syntax nameref} ('(' @{syntax nat} ')')?
wenzelm@42908
   650
  "}
wenzelm@42908
   651
wenzelm@42908
   652
  \begin{description}
wenzelm@42908
   653
wenzelm@42908
   654
  \item @{command (HOL) "recdef"} defines general well-founded
wenzelm@42908
   655
  recursive functions (using the TFL package), see also
wenzelm@42908
   656
  \cite{isabelle-HOL}.  The ``@{text "(permissive)"}'' option tells
wenzelm@42908
   657
  TFL to recover from failed proof attempts, returning unfinished
wenzelm@42908
   658
  results.  The @{text recdef_simp}, @{text recdef_cong}, and @{text
wenzelm@42908
   659
  recdef_wf} hints refer to auxiliary rules to be used in the internal
wenzelm@42908
   660
  automated proof process of TFL.  Additional @{syntax clasimpmod}
wenzelm@42930
   661
  declarations may be given to tune the context of the Simplifier
wenzelm@42930
   662
  (cf.\ \secref{sec:simplifier}) and Classical reasoner (cf.\
wenzelm@42930
   663
  \secref{sec:classical}).
wenzelm@42908
   664
wenzelm@42908
   665
  \item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
wenzelm@42908
   666
  proof for leftover termination condition number @{text i} (default
wenzelm@42908
   667
  1) as generated by a @{command (HOL) "recdef"} definition of
wenzelm@42908
   668
  constant @{text c}.
wenzelm@42908
   669
wenzelm@42908
   670
  Note that in most cases, @{command (HOL) "recdef"} is able to finish
wenzelm@42908
   671
  its internal proofs without manual intervention.
wenzelm@42908
   672
wenzelm@42908
   673
  \end{description}
wenzelm@42908
   674
wenzelm@42908
   675
  \medskip Hints for @{command (HOL) "recdef"} may be also declared
wenzelm@42908
   676
  globally, using the following attributes.
wenzelm@42908
   677
wenzelm@42908
   678
  \begin{matharray}{rcl}
wenzelm@42908
   679
    @{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
wenzelm@42908
   680
    @{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
wenzelm@42908
   681
    @{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
wenzelm@42908
   682
  \end{matharray}
wenzelm@42908
   683
wenzelm@42908
   684
  @{rail "
wenzelm@42908
   685
    (@@{attribute (HOL) recdef_simp} | @@{attribute (HOL) recdef_cong} |
wenzelm@42908
   686
      @@{attribute (HOL) recdef_wf}) (() | 'add' | 'del')
wenzelm@42908
   687
  "}
wenzelm@42908
   688
*}
wenzelm@42908
   689
wenzelm@42908
   690
wenzelm@42908
   691
section {* Datatypes \label{sec:hol-datatype} *}
wenzelm@42908
   692
wenzelm@42908
   693
text {*
wenzelm@42908
   694
  \begin{matharray}{rcl}
wenzelm@42908
   695
    @{command_def (HOL) "datatype"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@42908
   696
    @{command_def (HOL) "rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   697
  \end{matharray}
wenzelm@42908
   698
wenzelm@42908
   699
  @{rail "
wenzelm@42908
   700
    @@{command (HOL) datatype} (spec + @'and')
wenzelm@42908
   701
    ;
wenzelm@42908
   702
    @@{command (HOL) rep_datatype} ('(' (@{syntax name} +) ')')? (@{syntax term} +)
wenzelm@42908
   703
    ;
wenzelm@42908
   704
wenzelm@45839
   705
    spec: @{syntax typespec_sorts} @{syntax mixfix}? '=' (cons + '|')
wenzelm@42908
   706
    ;
wenzelm@42908
   707
    cons: @{syntax name} (@{syntax type} * ) @{syntax mixfix}?
wenzelm@42908
   708
  "}
wenzelm@42908
   709
wenzelm@42908
   710
  \begin{description}
wenzelm@42908
   711
wenzelm@42908
   712
  \item @{command (HOL) "datatype"} defines inductive datatypes in
wenzelm@42908
   713
  HOL.
wenzelm@42908
   714
wenzelm@42908
   715
  \item @{command (HOL) "rep_datatype"} represents existing types as
wenzelm@42909
   716
  datatypes.
wenzelm@42909
   717
wenzelm@42909
   718
  For foundational reasons, some basic types such as @{typ nat}, @{typ
wenzelm@42909
   719
  "'a \<times> 'b"}, @{typ "'a + 'b"}, @{typ bool} and @{typ unit} are
wenzelm@42909
   720
  introduced by more primitive means using @{command_ref typedef}.  To
wenzelm@42909
   721
  recover the rich infrastructure of @{command datatype} (e.g.\ rules
wenzelm@42909
   722
  for @{method cases} and @{method induct} and the primitive recursion
wenzelm@42909
   723
  combinators), such types may be represented as actual datatypes
wenzelm@42909
   724
  later.  This is done by specifying the constructors of the desired
wenzelm@42909
   725
  type, and giving a proof of the induction rule, distinctness and
wenzelm@42909
   726
  injectivity of constructors.
wenzelm@42909
   727
wenzelm@42909
   728
  For example, see @{file "~~/src/HOL/Sum_Type.thy"} for the
wenzelm@42909
   729
  representation of the primitive sum type as fully-featured datatype.
wenzelm@42908
   730
wenzelm@42908
   731
  \end{description}
wenzelm@42908
   732
wenzelm@42909
   733
  The generated rules for @{method induct} and @{method cases} provide
wenzelm@42909
   734
  case names according to the given constructors, while parameters are
wenzelm@42909
   735
  named after the types (see also \secref{sec:cases-induct}).
wenzelm@42908
   736
wenzelm@42908
   737
  See \cite{isabelle-HOL} for more details on datatypes, but beware of
wenzelm@42908
   738
  the old-style theory syntax being used there!  Apart from proper
wenzelm@42908
   739
  proof methods for case-analysis and induction, there are also
wenzelm@42908
   740
  emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
wenzelm@42908
   741
  induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
wenzelm@42908
   742
  to refer directly to the internal structure of subgoals (including
wenzelm@42908
   743
  internally bound parameters).
wenzelm@26849
   744
*}
wenzelm@26849
   745
wenzelm@26849
   746
wenzelm@42910
   747
subsubsection {* Examples *}
wenzelm@42910
   748
wenzelm@42910
   749
text {* We define a type of finite sequences, with slightly different
wenzelm@42910
   750
  names than the existing @{typ "'a list"} that is already in @{theory
wenzelm@42910
   751
  Main}: *}
wenzelm@42910
   752
wenzelm@42910
   753
datatype 'a seq = Empty | Seq 'a "'a seq"
wenzelm@42910
   754
wenzelm@42910
   755
text {* We can now prove some simple lemma by structural induction: *}
wenzelm@42910
   756
wenzelm@42910
   757
lemma "Seq x xs \<noteq> xs"
wenzelm@42910
   758
proof (induct xs arbitrary: x)
wenzelm@42910
   759
  case Empty
wenzelm@42910
   760
  txt {* This case can be proved using the simplifier: the freeness
wenzelm@42910
   761
    properties of the datatype are already declared as @{attribute
wenzelm@42910
   762
    simp} rules. *}
wenzelm@42910
   763
  show "Seq x Empty \<noteq> Empty"
wenzelm@42910
   764
    by simp
wenzelm@42910
   765
next
wenzelm@42910
   766
  case (Seq y ys)
wenzelm@42910
   767
  txt {* The step case is proved similarly. *}
wenzelm@42910
   768
  show "Seq x (Seq y ys) \<noteq> Seq y ys"
wenzelm@42910
   769
    using `Seq y ys \<noteq> ys` by simp
wenzelm@42910
   770
qed
wenzelm@42910
   771
wenzelm@42910
   772
text {* Here is a more succinct version of the same proof: *}
wenzelm@42910
   773
wenzelm@42910
   774
lemma "Seq x xs \<noteq> xs"
wenzelm@42910
   775
  by (induct xs arbitrary: x) simp_all
wenzelm@42910
   776
wenzelm@42910
   777
wenzelm@26849
   778
section {* Records \label{sec:hol-record} *}
wenzelm@26849
   779
wenzelm@26849
   780
text {*
wenzelm@26849
   781
  In principle, records merely generalize the concept of tuples, where
wenzelm@26849
   782
  components may be addressed by labels instead of just position.  The
wenzelm@26849
   783
  logical infrastructure of records in Isabelle/HOL is slightly more
wenzelm@26849
   784
  advanced, though, supporting truly extensible record schemes.  This
wenzelm@26849
   785
  admits operations that are polymorphic with respect to record
wenzelm@26849
   786
  extension, yielding ``object-oriented'' effects like (single)
wenzelm@26849
   787
  inheritance.  See also \cite{NaraschewskiW-TPHOLs98} for more
wenzelm@26849
   788
  details on object-oriented verification and record subtyping in HOL.
wenzelm@26849
   789
*}
wenzelm@26849
   790
wenzelm@26849
   791
wenzelm@26849
   792
subsection {* Basic concepts *}
wenzelm@26849
   793
wenzelm@26849
   794
text {*
wenzelm@26849
   795
  Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
wenzelm@26849
   796
  at the level of terms and types.  The notation is as follows:
wenzelm@26849
   797
wenzelm@26849
   798
  \begin{center}
wenzelm@26849
   799
  \begin{tabular}{l|l|l}
wenzelm@26849
   800
    & record terms & record types \\ \hline
wenzelm@26849
   801
    fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
wenzelm@26849
   802
    schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
wenzelm@26849
   803
      @{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
wenzelm@26849
   804
  \end{tabular}
wenzelm@26849
   805
  \end{center}
wenzelm@26849
   806
wenzelm@26849
   807
  \noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
wenzelm@26849
   808
  "(| x = a |)"}.
wenzelm@26849
   809
wenzelm@26849
   810
  A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
wenzelm@26849
   811
  @{text a} and field @{text y} of value @{text b}.  The corresponding
wenzelm@26849
   812
  type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
wenzelm@26849
   813
  and @{text "b :: B"}.
wenzelm@26849
   814
wenzelm@26849
   815
  A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
wenzelm@26849
   816
  @{text x} and @{text y} as before, but also possibly further fields
wenzelm@26849
   817
  as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
wenzelm@26849
   818
  of the syntax).  The improper field ``@{text "\<dots>"}'' of a record
wenzelm@26849
   819
  scheme is called the \emph{more part}.  Logically it is just a free
wenzelm@26849
   820
  variable, which is occasionally referred to as ``row variable'' in
wenzelm@26849
   821
  the literature.  The more part of a record scheme may be
wenzelm@26849
   822
  instantiated by zero or more further components.  For example, the
wenzelm@26849
   823
  previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
wenzelm@26852
   824
  c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
wenzelm@26849
   825
  Fixed records are special instances of record schemes, where
wenzelm@26849
   826
  ``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
wenzelm@26849
   827
  element.  In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
wenzelm@26849
   828
  for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
wenzelm@42123
   829
wenzelm@26849
   830
  \medskip Two key observations make extensible records in a simply
wenzelm@26849
   831
  typed language like HOL work out:
wenzelm@26849
   832
wenzelm@26849
   833
  \begin{enumerate}
wenzelm@26849
   834
wenzelm@26849
   835
  \item the more part is internalized, as a free term or type
wenzelm@26849
   836
  variable,
wenzelm@26849
   837
wenzelm@26852
   838
  \item field names are externalized, they cannot be accessed within
wenzelm@26852
   839
  the logic as first-class values.
wenzelm@26849
   840
wenzelm@26849
   841
  \end{enumerate}
wenzelm@26849
   842
wenzelm@26849
   843
  \medskip In Isabelle/HOL record types have to be defined explicitly,
wenzelm@26849
   844
  fixing their field names and types, and their (optional) parent
wenzelm@26849
   845
  record.  Afterwards, records may be formed using above syntax, while
wenzelm@26849
   846
  obeying the canonical order of fields as given by their declaration.
wenzelm@26849
   847
  The record package provides several standard operations like
wenzelm@26849
   848
  selectors and updates.  The common setup for various generic proof
wenzelm@26849
   849
  tools enable succinct reasoning patterns.  See also the Isabelle/HOL
wenzelm@26849
   850
  tutorial \cite{isabelle-hol-book} for further instructions on using
wenzelm@26849
   851
  records in practice.
wenzelm@26849
   852
*}
wenzelm@26849
   853
wenzelm@26849
   854
wenzelm@26849
   855
subsection {* Record specifications *}
wenzelm@26849
   856
wenzelm@26849
   857
text {*
wenzelm@26849
   858
  \begin{matharray}{rcl}
wenzelm@28761
   859
    @{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@26849
   860
  \end{matharray}
wenzelm@26849
   861
wenzelm@42596
   862
  @{rail "
wenzelm@42705
   863
    @@{command (HOL) record} @{syntax typespec_sorts} '=' \\
wenzelm@42704
   864
      (@{syntax type} '+')? (@{syntax constdecl} +)
wenzelm@42596
   865
  "}
wenzelm@26849
   866
wenzelm@28760
   867
  \begin{description}
wenzelm@26849
   868
wenzelm@28760
   869
  \item @{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1
wenzelm@28760
   870
  \<dots> c\<^sub>n :: \<sigma>\<^sub>n"} defines extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
wenzelm@26849
   871
  derived from the optional parent record @{text "\<tau>"} by adding new
wenzelm@26849
   872
  field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
wenzelm@26849
   873
wenzelm@26849
   874
  The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
wenzelm@26849
   875
  covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
wenzelm@26849
   876
  \<alpha>\<^sub>m"}.  Type constructor @{text t} has to be new, while @{text
wenzelm@26849
   877
  \<tau>} needs to specify an instance of an existing record type.  At
wenzelm@26849
   878
  least one new field @{text "c\<^sub>i"} has to be specified.
wenzelm@26849
   879
  Basically, field names need to belong to a unique record.  This is
wenzelm@26849
   880
  not a real restriction in practice, since fields are qualified by
wenzelm@26849
   881
  the record name internally.
wenzelm@26849
   882
wenzelm@26849
   883
  The parent record specification @{text \<tau>} is optional; if omitted
wenzelm@26849
   884
  @{text t} becomes a root record.  The hierarchy of all records
wenzelm@26849
   885
  declared within a theory context forms a forest structure, i.e.\ a
wenzelm@26849
   886
  set of trees starting with a root record each.  There is no way to
wenzelm@26849
   887
  merge multiple parent records!
wenzelm@26849
   888
wenzelm@26849
   889
  For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
wenzelm@26849
   890
  type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
wenzelm@26849
   891
  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
wenzelm@26849
   892
  "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
wenzelm@26849
   893
  @{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
wenzelm@26849
   894
  \<zeta>\<rparr>"}.
wenzelm@26849
   895
wenzelm@28760
   896
  \end{description}
wenzelm@26849
   897
*}
wenzelm@26849
   898
wenzelm@26849
   899
wenzelm@26849
   900
subsection {* Record operations *}
wenzelm@26849
   901
wenzelm@26849
   902
text {*
wenzelm@26849
   903
  Any record definition of the form presented above produces certain
wenzelm@26849
   904
  standard operations.  Selectors and updates are provided for any
wenzelm@26849
   905
  field, including the improper one ``@{text more}''.  There are also
wenzelm@26849
   906
  cumulative record constructor functions.  To simplify the
wenzelm@26849
   907
  presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
wenzelm@26849
   908
  \<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
wenzelm@26849
   909
  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
wenzelm@26849
   910
wenzelm@26849
   911
  \medskip \textbf{Selectors} and \textbf{updates} are available for
wenzelm@26849
   912
  any field (including ``@{text more}''):
wenzelm@26849
   913
wenzelm@26849
   914
  \begin{matharray}{lll}
wenzelm@26852
   915
    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
wenzelm@26852
   916
    @{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>"} \\
wenzelm@26849
   917
  \end{matharray}
wenzelm@26849
   918
wenzelm@26849
   919
  There is special syntax for application of updates: @{text "r\<lparr>x :=
wenzelm@26849
   920
  a\<rparr>"} abbreviates term @{text "x_update a r"}.  Further notation for
wenzelm@26849
   921
  repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
wenzelm@26849
   922
  c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}.  Note that
wenzelm@26849
   923
  because of postfix notation the order of fields shown here is
wenzelm@26849
   924
  reverse than in the actual term.  Since repeated updates are just
wenzelm@26849
   925
  function applications, fields may be freely permuted in @{text "\<lparr>x
wenzelm@26849
   926
  := a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
wenzelm@26849
   927
  Thus commutativity of independent updates can be proven within the
wenzelm@26849
   928
  logic for any two fields, but not as a general theorem.
wenzelm@26849
   929
wenzelm@26849
   930
  \medskip The \textbf{make} operation provides a cumulative record
wenzelm@26849
   931
  constructor function:
wenzelm@26849
   932
wenzelm@26849
   933
  \begin{matharray}{lll}
wenzelm@26852
   934
    @{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26849
   935
  \end{matharray}
wenzelm@26849
   936
wenzelm@26849
   937
  \medskip We now reconsider the case of non-root records, which are
wenzelm@26849
   938
  derived of some parent.  In general, the latter may depend on
wenzelm@26849
   939
  another parent as well, resulting in a list of \emph{ancestor
wenzelm@26849
   940
  records}.  Appending the lists of fields of all ancestors results in
wenzelm@26849
   941
  a certain field prefix.  The record package automatically takes care
wenzelm@26849
   942
  of this by lifting operations over this context of ancestor fields.
wenzelm@26849
   943
  Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
wenzelm@26849
   944
  fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
wenzelm@26849
   945
  the above record operations will get the following types:
wenzelm@26849
   946
wenzelm@26852
   947
  \medskip
wenzelm@26852
   948
  \begin{tabular}{lll}
wenzelm@26852
   949
    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
wenzelm@42123
   950
    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow>
wenzelm@26852
   951
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
wenzelm@26852
   952
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
wenzelm@26852
   953
    @{text "t.make"} & @{text "::"} & @{text "\<rho>\<^sub>1 \<Rightarrow> \<dots> \<rho>\<^sub>k \<Rightarrow> \<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow>
wenzelm@26852
   954
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26852
   955
  \end{tabular}
wenzelm@26852
   956
  \medskip
wenzelm@26849
   957
wenzelm@26852
   958
  \noindent Some further operations address the extension aspect of a
wenzelm@26849
   959
  derived record scheme specifically: @{text "t.fields"} produces a
wenzelm@26849
   960
  record fragment consisting of exactly the new fields introduced here
wenzelm@26849
   961
  (the result may serve as a more part elsewhere); @{text "t.extend"}
wenzelm@26849
   962
  takes a fixed record and adds a given more part; @{text
wenzelm@26849
   963
  "t.truncate"} restricts a record scheme to a fixed record.
wenzelm@26849
   964
wenzelm@26852
   965
  \medskip
wenzelm@26852
   966
  \begin{tabular}{lll}
wenzelm@26852
   967
    @{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26852
   968
    @{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
wenzelm@26852
   969
      \<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
wenzelm@26852
   970
    @{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>"} \\
wenzelm@26852
   971
  \end{tabular}
wenzelm@26852
   972
  \medskip
wenzelm@26849
   973
wenzelm@26849
   974
  \noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
wenzelm@26849
   975
  for root records.
wenzelm@26849
   976
*}
wenzelm@26849
   977
wenzelm@26849
   978
wenzelm@26849
   979
subsection {* Derived rules and proof tools *}
wenzelm@26849
   980
wenzelm@26849
   981
text {*
wenzelm@26849
   982
  The record package proves several results internally, declaring
wenzelm@26849
   983
  these facts to appropriate proof tools.  This enables users to
wenzelm@26849
   984
  reason about record structures quite conveniently.  Assume that
wenzelm@26849
   985
  @{text t} is a record type as specified above.
wenzelm@26849
   986
wenzelm@26849
   987
  \begin{enumerate}
wenzelm@42123
   988
wenzelm@26849
   989
  \item Standard conversions for selectors or updates applied to
wenzelm@26849
   990
  record constructor terms are made part of the default Simplifier
wenzelm@26849
   991
  context; thus proofs by reduction of basic operations merely require
wenzelm@26849
   992
  the @{method simp} method without further arguments.  These rules
wenzelm@26849
   993
  are available as @{text "t.simps"}, too.
wenzelm@42123
   994
wenzelm@26849
   995
  \item Selectors applied to updated records are automatically reduced
wenzelm@26849
   996
  by an internal simplification procedure, which is also part of the
wenzelm@26849
   997
  standard Simplifier setup.
wenzelm@26849
   998
wenzelm@26849
   999
  \item Inject equations of a form analogous to @{prop "(x, y) = (x',
wenzelm@26849
  1000
  y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
wenzelm@26849
  1001
  Reasoner as @{attribute iff} rules.  These rules are available as
wenzelm@26849
  1002
  @{text "t.iffs"}.
wenzelm@26849
  1003
wenzelm@26849
  1004
  \item The introduction rule for record equality analogous to @{text
wenzelm@26849
  1005
  "x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
wenzelm@26849
  1006
  and as the basic rule context as ``@{attribute intro}@{text "?"}''.
wenzelm@26849
  1007
  The rule is called @{text "t.equality"}.
wenzelm@26849
  1008
wenzelm@26849
  1009
  \item Representations of arbitrary record expressions as canonical
wenzelm@26849
  1010
  constructor terms are provided both in @{method cases} and @{method
wenzelm@26849
  1011
  induct} format (cf.\ the generic proof methods of the same name,
wenzelm@26849
  1012
  \secref{sec:cases-induct}).  Several variations are available, for
wenzelm@26849
  1013
  fixed records, record schemes, more parts etc.
wenzelm@42123
  1014
wenzelm@26849
  1015
  The generic proof methods are sufficiently smart to pick the most
wenzelm@26849
  1016
  sensible rule according to the type of the indicated record
wenzelm@26849
  1017
  expression: users just need to apply something like ``@{text "(cases
wenzelm@26849
  1018
  r)"}'' to a certain proof problem.
wenzelm@26849
  1019
wenzelm@26849
  1020
  \item The derived record operations @{text "t.make"}, @{text
wenzelm@26849
  1021
  "t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
wenzelm@26849
  1022
  treated automatically, but usually need to be expanded by hand,
wenzelm@26849
  1023
  using the collective fact @{text "t.defs"}.
wenzelm@26849
  1024
wenzelm@26849
  1025
  \end{enumerate}
wenzelm@26849
  1026
*}
wenzelm@26849
  1027
wenzelm@26849
  1028
wenzelm@42911
  1029
subsubsection {* Examples *}
wenzelm@42911
  1030
wenzelm@42911
  1031
text {* See @{file "~~/src/HOL/ex/Records.thy"}, for example. *}
wenzelm@42911
  1032
wenzelm@42911
  1033
wenzelm@42908
  1034
section {* Adhoc tuples *}
wenzelm@26849
  1035
wenzelm@26849
  1036
text {*
wenzelm@26849
  1037
  \begin{matharray}{rcl}
wenzelm@42908
  1038
    @{attribute_def (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
wenzelm@26849
  1039
  \end{matharray}
wenzelm@26849
  1040
wenzelm@42596
  1041
  @{rail "
wenzelm@42908
  1042
    @@{attribute (HOL) split_format} ('(' 'complete' ')')?
wenzelm@42908
  1043
  "}
wenzelm@42908
  1044
wenzelm@42908
  1045
  \begin{description}
wenzelm@42908
  1046
wenzelm@42908
  1047
  \item @{attribute (HOL) split_format}\ @{text "(complete)"} causes
wenzelm@42908
  1048
  arguments in function applications to be represented canonically
wenzelm@42908
  1049
  according to their tuple type structure.
wenzelm@42908
  1050
wenzelm@42908
  1051
  Note that this operation tends to invent funny names for new local
wenzelm@42908
  1052
  parameters introduced.
wenzelm@42908
  1053
wenzelm@42908
  1054
  \end{description}
wenzelm@42908
  1055
*}
wenzelm@42908
  1056
wenzelm@42908
  1057
wenzelm@42908
  1058
section {* Typedef axiomatization \label{sec:hol-typedef} *}
wenzelm@42908
  1059
wenzelm@42908
  1060
text {* A Gordon/HOL-style type definition is a certain axiom scheme
wenzelm@42908
  1061
  that identifies a new type with a subset of an existing type.  More
wenzelm@42908
  1062
  precisely, the new type is defined by exhibiting an existing type
wenzelm@42908
  1063
  @{text \<tau>}, a set @{text "A :: \<tau> set"}, and a theorem that proves
wenzelm@42908
  1064
  @{prop "\<exists>x. x \<in> A"}.  Thus @{text A} is a non-empty subset of @{text
wenzelm@42908
  1065
  \<tau>}, and the new type denotes this subset.  New functions are
wenzelm@42908
  1066
  postulated that establish an isomorphism between the new type and
wenzelm@42908
  1067
  the subset.  In general, the type @{text \<tau>} may involve type
wenzelm@42908
  1068
  variables @{text "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} which means that the type definition
wenzelm@42908
  1069
  produces a type constructor @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t"} depending on
wenzelm@42908
  1070
  those type arguments.
wenzelm@42908
  1071
wenzelm@42908
  1072
  The axiomatization can be considered a ``definition'' in the sense
wenzelm@42908
  1073
  of the particular set-theoretic interpretation of HOL
wenzelm@42908
  1074
  \cite{pitts93}, where the universe of types is required to be
wenzelm@42908
  1075
  downwards-closed wrt.\ arbitrary non-empty subsets.  Thus genuinely
wenzelm@42908
  1076
  new types introduced by @{command "typedef"} stay within the range
wenzelm@42908
  1077
  of HOL models by construction.  Note that @{command_ref
wenzelm@42908
  1078
  type_synonym} from Isabelle/Pure merely introduces syntactic
wenzelm@42908
  1079
  abbreviations, without any logical significance.
wenzelm@42908
  1080
  
wenzelm@42908
  1081
  \begin{matharray}{rcl}
wenzelm@42908
  1082
    @{command_def (HOL) "typedef"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
  1083
  \end{matharray}
wenzelm@42908
  1084
wenzelm@42908
  1085
  @{rail "
wenzelm@42908
  1086
    @@{command (HOL) typedef} alt_name? abs_type '=' rep_set
wenzelm@26849
  1087
    ;
wenzelm@26849
  1088
wenzelm@42908
  1089
    alt_name: '(' (@{syntax name} | @'open' | @'open' @{syntax name}) ')'
wenzelm@26849
  1090
    ;
wenzelm@42908
  1091
    abs_type: @{syntax typespec_sorts} @{syntax mixfix}?
wenzelm@42908
  1092
    ;
wenzelm@42908
  1093
    rep_set: @{syntax term} (@'morphisms' @{syntax name} @{syntax name})?
wenzelm@42596
  1094
  "}
wenzelm@26849
  1095
wenzelm@28760
  1096
  \begin{description}
wenzelm@26849
  1097
wenzelm@42908
  1098
  \item @{command (HOL) "typedef"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t = A"}
wenzelm@42908
  1099
  axiomatizes a type definition in the background theory of the
wenzelm@42908
  1100
  current context, depending on a non-emptiness result of the set
wenzelm@42908
  1101
  @{text A} that needs to be proven here.  The set @{text A} may
wenzelm@42908
  1102
  contain type variables @{text "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} as specified on the LHS,
wenzelm@42908
  1103
  but no term variables.
wenzelm@42908
  1104
wenzelm@42908
  1105
  Even though a local theory specification, the newly introduced type
wenzelm@42908
  1106
  constructor cannot depend on parameters or assumptions of the
wenzelm@42908
  1107
  context: this is structurally impossible in HOL.  In contrast, the
wenzelm@42908
  1108
  non-emptiness proof may use local assumptions in unusual situations,
wenzelm@42908
  1109
  which could result in different interpretations in target contexts:
wenzelm@42908
  1110
  the meaning of the bijection between the representing set @{text A}
wenzelm@42908
  1111
  and the new type @{text t} may then change in different application
wenzelm@42908
  1112
  contexts.
wenzelm@42908
  1113
wenzelm@42908
  1114
  By default, @{command (HOL) "typedef"} defines both a type
wenzelm@42908
  1115
  constructor @{text t} for the new type, and a term constant @{text
wenzelm@42908
  1116
  t} for the representing set within the old type.  Use the ``@{text
wenzelm@42908
  1117
  "(open)"}'' option to suppress a separate constant definition
wenzelm@42908
  1118
  altogether.  The injection from type to set is called @{text Rep_t},
wenzelm@42908
  1119
  its inverse @{text Abs_t}, unless explicit @{keyword (HOL)
wenzelm@42908
  1120
  "morphisms"} specification provides alternative names.
wenzelm@26849
  1121
wenzelm@42908
  1122
  The core axiomatization uses the locale predicate @{const
wenzelm@42908
  1123
  type_definition} as defined in Isabelle/HOL.  Various basic
wenzelm@42908
  1124
  consequences of that are instantiated accordingly, re-using the
wenzelm@42908
  1125
  locale facts with names derived from the new type constructor.  Thus
wenzelm@42908
  1126
  the generic @{thm type_definition.Rep} is turned into the specific
wenzelm@42908
  1127
  @{text "Rep_t"}, for example.
wenzelm@42908
  1128
wenzelm@42908
  1129
  Theorems @{thm type_definition.Rep}, @{thm
wenzelm@42908
  1130
  type_definition.Rep_inverse}, and @{thm type_definition.Abs_inverse}
wenzelm@42908
  1131
  provide the most basic characterization as a corresponding
wenzelm@42908
  1132
  injection/surjection pair (in both directions).  The derived rules
wenzelm@42908
  1133
  @{thm type_definition.Rep_inject} and @{thm
wenzelm@42908
  1134
  type_definition.Abs_inject} provide a more convenient version of
wenzelm@42908
  1135
  injectivity, suitable for automated proof tools (e.g.\ in
wenzelm@42908
  1136
  declarations involving @{attribute simp} or @{attribute iff}).
wenzelm@42908
  1137
  Furthermore, the rules @{thm type_definition.Rep_cases}~/ @{thm
wenzelm@42908
  1138
  type_definition.Rep_induct}, and @{thm type_definition.Abs_cases}~/
wenzelm@42908
  1139
  @{thm type_definition.Abs_induct} provide alternative views on
wenzelm@42908
  1140
  surjectivity.  These rules are already declared as set or type rules
wenzelm@42908
  1141
  for the generic @{method cases} and @{method induct} methods,
wenzelm@42908
  1142
  respectively.
wenzelm@42908
  1143
wenzelm@42908
  1144
  An alternative name for the set definition (and other derived
wenzelm@42908
  1145
  entities) may be specified in parentheses; the default is to use
wenzelm@42908
  1146
  @{text t} directly.
wenzelm@26849
  1147
wenzelm@28760
  1148
  \end{description}
wenzelm@26849
  1149
wenzelm@42908
  1150
  \begin{warn}
wenzelm@42908
  1151
  If you introduce a new type axiomatically, i.e.\ via @{command_ref
wenzelm@42908
  1152
  typedecl} and @{command_ref axiomatization}, the minimum requirement
wenzelm@42908
  1153
  is that it has a non-empty model, to avoid immediate collapse of the
wenzelm@42908
  1154
  HOL logic.  Moreover, one needs to demonstrate that the
wenzelm@42908
  1155
  interpretation of such free-form axiomatizations can coexist with
wenzelm@42908
  1156
  that of the regular @{command_def typedef} scheme, and any extension
wenzelm@42908
  1157
  that other people might have introduced elsewhere (e.g.\ in HOLCF
wenzelm@42908
  1158
  \cite{MuellerNvOS99}).
wenzelm@42908
  1159
  \end{warn}
wenzelm@42908
  1160
*}
wenzelm@42908
  1161
wenzelm@42908
  1162
subsubsection {* Examples *}
wenzelm@42908
  1163
wenzelm@42908
  1164
text {* Type definitions permit the introduction of abstract data
wenzelm@42908
  1165
  types in a safe way, namely by providing models based on already
wenzelm@42908
  1166
  existing types.  Given some abstract axiomatic description @{text P}
wenzelm@42908
  1167
  of a type, this involves two steps:
wenzelm@42908
  1168
wenzelm@42908
  1169
  \begin{enumerate}
wenzelm@42908
  1170
wenzelm@42908
  1171
  \item Find an appropriate type @{text \<tau>} and subset @{text A} which
wenzelm@42908
  1172
  has the desired properties @{text P}, and make a type definition
wenzelm@42908
  1173
  based on this representation.
wenzelm@42908
  1174
wenzelm@42908
  1175
  \item Prove that @{text P} holds for @{text \<tau>} by lifting @{text P}
wenzelm@42908
  1176
  from the representation.
wenzelm@26849
  1177
wenzelm@42908
  1178
  \end{enumerate}
wenzelm@42908
  1179
wenzelm@42908
  1180
  You can later forget about the representation and work solely in
wenzelm@42908
  1181
  terms of the abstract properties @{text P}.
wenzelm@42908
  1182
wenzelm@42908
  1183
  \medskip The following trivial example pulls a three-element type
wenzelm@42908
  1184
  into existence within the formal logical environment of HOL. *}
wenzelm@42908
  1185
wenzelm@42908
  1186
typedef three = "{(True, True), (True, False), (False, True)}"
wenzelm@42908
  1187
  by blast
wenzelm@42908
  1188
wenzelm@42908
  1189
definition "One = Abs_three (True, True)"
wenzelm@42908
  1190
definition "Two = Abs_three (True, False)"
wenzelm@42908
  1191
definition "Three = Abs_three (False, True)"
wenzelm@42908
  1192
wenzelm@42908
  1193
lemma three_distinct: "One \<noteq> Two"  "One \<noteq> Three"  "Two \<noteq> Three"
wenzelm@42908
  1194
  by (simp_all add: One_def Two_def Three_def Abs_three_inject three_def)
wenzelm@42908
  1195
wenzelm@42908
  1196
lemma three_cases:
wenzelm@42908
  1197
  fixes x :: three obtains "x = One" | "x = Two" | "x = Three"
wenzelm@42908
  1198
  by (cases x) (auto simp: One_def Two_def Three_def Abs_three_inject three_def)
wenzelm@42908
  1199
wenzelm@42908
  1200
text {* Note that such trivial constructions are better done with
wenzelm@42908
  1201
  derived specification mechanisms such as @{command datatype}: *}
wenzelm@42908
  1202
wenzelm@42908
  1203
datatype three' = One' | Two' | Three'
wenzelm@42908
  1204
wenzelm@42908
  1205
text {* This avoids re-doing basic definitions and proofs from the
wenzelm@42908
  1206
  primitive @{command typedef} above. *}
wenzelm@26849
  1207
wenzelm@26849
  1208
haftmann@41396
  1209
section {* Functorial structure of types *}
haftmann@41396
  1210
haftmann@41396
  1211
text {*
haftmann@41396
  1212
  \begin{matharray}{rcl}
haftmann@41505
  1213
    @{command_def (HOL) "enriched_type"} & : & @{text "local_theory \<rightarrow> proof(prove)"}
haftmann@41396
  1214
  \end{matharray}
haftmann@41396
  1215
wenzelm@42596
  1216
  @{rail "
wenzelm@42617
  1217
    @@{command (HOL) enriched_type} (@{syntax name} ':')? @{syntax term}
haftmann@41396
  1218
    ;
wenzelm@42617
  1219
  "}
haftmann@41396
  1220
haftmann@41396
  1221
  \begin{description}
haftmann@41396
  1222
wenzelm@42617
  1223
  \item @{command (HOL) "enriched_type"}~@{text "prefix: m"} allows to
wenzelm@42617
  1224
  prove and register properties about the functorial structure of type
wenzelm@42617
  1225
  constructors.  These properties then can be used by other packages
wenzelm@42617
  1226
  to deal with those type constructors in certain type constructions.
wenzelm@42617
  1227
  Characteristic theorems are noted in the current local theory.  By
wenzelm@42617
  1228
  default, they are prefixed with the base name of the type
wenzelm@42617
  1229
  constructor, an explicit prefix can be given alternatively.
haftmann@41396
  1230
haftmann@41396
  1231
  The given term @{text "m"} is considered as \emph{mapper} for the
haftmann@41396
  1232
  corresponding type constructor and must conform to the following
haftmann@41396
  1233
  type pattern:
haftmann@41396
  1234
haftmann@41396
  1235
  \begin{matharray}{lll}
haftmann@41396
  1236
    @{text "m"} & @{text "::"} &
haftmann@41396
  1237
      @{text "\<sigma>\<^isub>1 \<Rightarrow> \<dots> \<sigma>\<^isub>k \<Rightarrow> (\<^vec>\<alpha>\<^isub>n) t \<Rightarrow> (\<^vec>\<beta>\<^isub>n) t"} \\
haftmann@41396
  1238
  \end{matharray}
haftmann@41396
  1239
haftmann@41396
  1240
  \noindent where @{text t} is the type constructor, @{text
haftmann@41396
  1241
  "\<^vec>\<alpha>\<^isub>n"} and @{text "\<^vec>\<beta>\<^isub>n"} are distinct
haftmann@41396
  1242
  type variables free in the local theory and @{text "\<sigma>\<^isub>1"},
haftmann@41396
  1243
  \ldots, @{text "\<sigma>\<^isub>k"} is a subsequence of @{text "\<alpha>\<^isub>1 \<Rightarrow>
haftmann@41396
  1244
  \<beta>\<^isub>1"}, @{text "\<beta>\<^isub>1 \<Rightarrow> \<alpha>\<^isub>1"}, \ldots,
haftmann@41396
  1245
  @{text "\<alpha>\<^isub>n \<Rightarrow> \<beta>\<^isub>n"}, @{text "\<beta>\<^isub>n \<Rightarrow>
haftmann@41396
  1246
  \<alpha>\<^isub>n"}.
haftmann@41396
  1247
haftmann@41396
  1248
  \end{description}
haftmann@41396
  1249
*}
haftmann@41396
  1250
bulwahn@43993
  1251
section {* Quotient types *}
bulwahn@43993
  1252
bulwahn@43993
  1253
text {*
bulwahn@43993
  1254
  The quotient package defines a new quotient type given a raw type
bulwahn@43993
  1255
  and a partial equivalence relation.
bulwahn@43993
  1256
  It also includes automation for transporting definitions and theorems.
bulwahn@43993
  1257
  It can automatically produce definitions and theorems on the quotient type,
bulwahn@43993
  1258
  given the corresponding constants and facts on the raw type.
bulwahn@43993
  1259
bulwahn@43993
  1260
  \begin{matharray}{rcl}
bulwahn@43993
  1261
    @{command_def (HOL) "quotient_type"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
bulwahn@43993
  1262
    @{command_def (HOL) "quotient_definition"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
bulwahn@43993
  1263
    @{command_def (HOL) "print_quotmaps"} & : & @{text "context \<rightarrow>"}\\
bulwahn@43993
  1264
    @{command_def (HOL) "print_quotients"} & : & @{text "context \<rightarrow>"}\\
bulwahn@43993
  1265
    @{command_def (HOL) "print_quotconsts"} & : & @{text "context \<rightarrow>"}\\
cezarykaliszyk@46447
  1266
    @{method_def (HOL) "lifting"} & : & @{text method} \\
cezarykaliszyk@46447
  1267
    @{method_def (HOL) "lifting_setup"} & : & @{text method} \\
cezarykaliszyk@46447
  1268
    @{method_def (HOL) "descending"} & : & @{text method} \\
cezarykaliszyk@46447
  1269
    @{method_def (HOL) "descending_setup"} & : & @{text method} \\
cezarykaliszyk@46447
  1270
    @{method_def (HOL) "partiality_descending"} & : & @{text method} \\
cezarykaliszyk@46447
  1271
    @{method_def (HOL) "partiality_descending_setup"} & : & @{text method} \\
cezarykaliszyk@46447
  1272
    @{method_def (HOL) "regularize"} & : & @{text method} \\
cezarykaliszyk@46447
  1273
    @{method_def (HOL) "injection"} & : & @{text method} \\
cezarykaliszyk@46447
  1274
    @{method_def (HOL) "cleaning"} & : & @{text method} \\
cezarykaliszyk@46448
  1275
    @{attribute_def (HOL) "quot_thm"} & : & @{text attribute} \\
cezarykaliszyk@46447
  1276
    @{attribute_def (HOL) "quot_lifted"} & : & @{text attribute} \\
cezarykaliszyk@46447
  1277
    @{attribute_def (HOL) "quot_respect"} & : & @{text attribute} \\
cezarykaliszyk@46447
  1278
    @{attribute_def (HOL) "quot_preserve"} & : & @{text attribute} \\
bulwahn@43993
  1279
  \end{matharray}
bulwahn@43993
  1280
bulwahn@43993
  1281
  @{rail "
bulwahn@43993
  1282
    @@{command (HOL) quotient_type} (spec + @'and');
bulwahn@43993
  1283
bulwahn@43993
  1284
    spec: @{syntax typespec} @{syntax mixfix}? '=' \\
kuncar@45678
  1285
     @{syntax type} '/' ('partial' ':')? @{syntax term} \\
kuncar@45678
  1286
     (@'morphisms' @{syntax name} @{syntax name})?; 
bulwahn@43993
  1287
  "}
bulwahn@43993
  1288
bulwahn@43993
  1289
  @{rail "
bulwahn@43993
  1290
    @@{command (HOL) quotient_definition} constdecl? @{syntax thmdecl}? \\
bulwahn@43993
  1291
    @{syntax term} 'is' @{syntax term};
cezarykaliszyk@46447
  1292
bulwahn@43993
  1293
    constdecl: @{syntax name} ('::' @{syntax type})? @{syntax mixfix}?
bulwahn@43993
  1294
  "}
bulwahn@43993
  1295
cezarykaliszyk@46447
  1296
  @{rail "
cezarykaliszyk@46447
  1297
    @@{method (HOL) lifting} @{syntax thmrefs}?
cezarykaliszyk@46447
  1298
    ;
cezarykaliszyk@46447
  1299
cezarykaliszyk@46447
  1300
    @@{method (HOL) lifting_setup} @{syntax thmrefs}?
cezarykaliszyk@46447
  1301
    ;
cezarykaliszyk@46447
  1302
  "}
cezarykaliszyk@46447
  1303
bulwahn@43993
  1304
  \begin{description}
cezarykaliszyk@46447
  1305
kuncar@45767
  1306
  \item @{command (HOL) "quotient_type"} defines quotient types. The injection from a quotient type 
kuncar@45767
  1307
  to a raw type is called @{text rep_t}, its inverse @{text abs_t} unless explicit @{keyword (HOL)
cezarykaliszyk@46447
  1308
  "morphisms"} specification provides alternative names. @{command (HOL) "quotient_type"} requires
cezarykaliszyk@46447
  1309
  the user to prove that the relation is an equivalence relation (predicate @{text equivp}), unless
cezarykaliszyk@46447
  1310
  the user specifies explicitely @{text partial} in which case the obligation is @{text part_equivp}.
cezarykaliszyk@46447
  1311
  A quotient defined with @{text partial} is weaker in the sense that less things can be proved
cezarykaliszyk@46447
  1312
  automatically.
bulwahn@43993
  1313
bulwahn@43993
  1314
  \item @{command (HOL) "quotient_definition"} defines a constant on the quotient type.
bulwahn@43993
  1315
bulwahn@43993
  1316
  \item @{command (HOL) "print_quotmaps"} prints quotient map functions.
bulwahn@43993
  1317
bulwahn@43993
  1318
  \item @{command (HOL) "print_quotients"} prints quotients.
bulwahn@43993
  1319
bulwahn@43993
  1320
  \item @{command (HOL) "print_quotconsts"} prints quotient constants.
bulwahn@43993
  1321
cezarykaliszyk@46447
  1322
  \item @{method (HOL) "lifting"} and @{method (HOL) "lifting_setup"}
cezarykaliszyk@46447
  1323
    methods match the current goal with the given raw theorem to be
cezarykaliszyk@46447
  1324
    lifted producing three new subgoals: regularization, injection and
cezarykaliszyk@46447
  1325
    cleaning subgoals. @{method (HOL) "lifting"} tries to apply the
cezarykaliszyk@46447
  1326
    heuristics for automatically solving these three subgoals and
cezarykaliszyk@46447
  1327
    leaves only the subgoals unsolved by the heuristics to the user as
cezarykaliszyk@46447
  1328
    opposed to @{method (HOL) "lifting_setup"} which leaves the three
cezarykaliszyk@46447
  1329
    subgoals unsolved.
cezarykaliszyk@46447
  1330
cezarykaliszyk@46447
  1331
  \item @{method (HOL) "descending"} and @{method (HOL)
cezarykaliszyk@46447
  1332
    "descending_setup"} try to guess a raw statement that would lift
cezarykaliszyk@46447
  1333
    to the current subgoal. Such statement is assumed as a new subgoal
cezarykaliszyk@46447
  1334
    and @{method (HOL) "descending"} continues in the same way as
cezarykaliszyk@46447
  1335
    @{method (HOL) "lifting"} does. @{method (HOL) "descending"} tries
cezarykaliszyk@46447
  1336
    to solve the arising regularization, injection and cleaning
cezarykaliszyk@46447
  1337
    subgoals with the analoguous method @{method (HOL)
cezarykaliszyk@46447
  1338
    "descending_setup"} which leaves the four unsolved subgoals.
cezarykaliszyk@46447
  1339
cezarykaliszyk@46447
  1340
  \item @{method (HOL) "partiality_descending"} finds the regularized
cezarykaliszyk@46447
  1341
    theorem that would lift to the current subgoal, lifts it and
cezarykaliszyk@46447
  1342
    leaves as a subgoal. This method can be used with partial
cezarykaliszyk@46447
  1343
    equivalence quotients where the non regularized statements would
cezarykaliszyk@46447
  1344
    not be true. @{method (HOL) "partiality_descending_setup"} leaves
cezarykaliszyk@46447
  1345
    the injection and cleaning subgoals unchanged.
cezarykaliszyk@46447
  1346
cezarykaliszyk@46447
  1347
  \item @{method (HOL) "regularize"} applies the regularization
cezarykaliszyk@46447
  1348
    heuristics to the current subgoal.
cezarykaliszyk@46447
  1349
cezarykaliszyk@46447
  1350
  \item @{method (HOL) "injection"} applies the injection heuristics
cezarykaliszyk@46447
  1351
    to the current goal using the stored quotient respectfulness
cezarykaliszyk@46447
  1352
    theorems.
cezarykaliszyk@46447
  1353
cezarykaliszyk@46447
  1354
  \item @{method (HOL) "cleaning"} applies the injection cleaning
cezarykaliszyk@46447
  1355
    heuristics to the current subgoal using the stored quotient
cezarykaliszyk@46447
  1356
    preservation theorems.
cezarykaliszyk@46447
  1357
cezarykaliszyk@46447
  1358
  \item @{attribute (HOL) quot_lifted} attribute tries to
cezarykaliszyk@46447
  1359
    automatically transport the theorem to the quotient type.
cezarykaliszyk@46447
  1360
    The attribute uses all the defined quotients types and quotient
cezarykaliszyk@46447
  1361
    constants often producing undesired results or theorems that
cezarykaliszyk@46447
  1362
    cannot be lifted.
cezarykaliszyk@46447
  1363
cezarykaliszyk@46447
  1364
  \item @{attribute (HOL) quot_respect} and @{attribute (HOL)
cezarykaliszyk@46447
  1365
    quot_preserve} attributes declare a theorem as a respectfulness
cezarykaliszyk@46447
  1366
    and preservation theorem respectively.  These are stored in the
cezarykaliszyk@46447
  1367
    local theory store and used by the @{method (HOL) "injection"}
cezarykaliszyk@46447
  1368
    and @{method (HOL) "cleaning"} methods respectively.
cezarykaliszyk@46447
  1369
cezarykaliszyk@46448
  1370
  \item @{attribute (HOL) quot_thm} declares that a certain theorem
cezarykaliszyk@46448
  1371
    is a quotient extension theorem. Quotient extension theorems
cezarykaliszyk@46448
  1372
    allow for quotienting inside container types. Given a polymorphic
cezarykaliszyk@46448
  1373
    type that serves as a container, a map function defined for this
cezarykaliszyk@46448
  1374
    container  using @{command (HOL) "enriched_type"} and a relation
cezarykaliszyk@46448
  1375
    map defined for for the container type, the quotient extension
cezarykaliszyk@46448
  1376
    theorem should be @{term "Quotient R Abs Rep \<Longrightarrow> Quotient
cezarykaliszyk@46448
  1377
    (rel_map R) (map Abs) (map Rep)"}. Quotient extension theorems
cezarykaliszyk@46448
  1378
    are stored in a database and are used all the steps of lifting
cezarykaliszyk@46448
  1379
    theorems.
cezarykaliszyk@46448
  1380
bulwahn@43993
  1381
  \end{description}
bulwahn@43993
  1382
bulwahn@43993
  1383
*}
haftmann@41396
  1384
noschinl@43994
  1385
section {* Coercive subtyping *}
noschinl@43994
  1386
noschinl@43994
  1387
text {*
noschinl@43994
  1388
  \begin{matharray}{rcl}
noschinl@43994
  1389
    @{attribute_def (HOL) coercion} & : & @{text attribute} \\
noschinl@43994
  1390
    @{attribute_def (HOL) coercion_enabled} & : & @{text attribute} \\
noschinl@43994
  1391
    @{attribute_def (HOL) coercion_map} & : & @{text attribute} \\
noschinl@43994
  1392
  \end{matharray}
noschinl@43994
  1393
noschinl@43994
  1394
  @{rail "
noschinl@43994
  1395
    @@{attribute (HOL) coercion} (@{syntax term})?
noschinl@43994
  1396
    ;
noschinl@43994
  1397
  "}
noschinl@43994
  1398
  @{rail "
noschinl@43994
  1399
    @@{attribute (HOL) coercion_map} (@{syntax term})?
noschinl@43994
  1400
    ;
noschinl@43994
  1401
  "}
noschinl@43994
  1402
noschinl@43994
  1403
  Coercive subtyping allows the user to omit explicit type conversions,
noschinl@43994
  1404
  also called \emph{coercions}.  Type inference will add them as
noschinl@43994
  1405
  necessary when parsing a term. See
noschinl@43994
  1406
  \cite{traytel-berghofer-nipkow-2011} for details.
noschinl@43994
  1407
noschinl@43994
  1408
  \begin{description}
noschinl@43994
  1409
noschinl@43994
  1410
  \item @{attribute (HOL) "coercion"}~@{text "f"} registers a new
noschinl@43994
  1411
  coercion function @{text "f :: \<sigma>\<^isub>1 \<Rightarrow>
noschinl@43994
  1412
  \<sigma>\<^isub>2"} where @{text "\<sigma>\<^isub>1"} and @{text
noschinl@43994
  1413
  "\<sigma>\<^isub>2"} are nullary type constructors. Coercions are
noschinl@43994
  1414
  composed by the inference algorithm if needed. Note that the type
noschinl@43994
  1415
  inference algorithm is complete only if the registered coercions form
noschinl@43994
  1416
  a lattice.
noschinl@43994
  1417
noschinl@43994
  1418
noschinl@43994
  1419
  \item @{attribute (HOL) "coercion_map"}~@{text "map"} registers a new
noschinl@43994
  1420
  map function to lift coercions through type constructors. The function
noschinl@43994
  1421
  @{text "map"} must conform to the following type pattern
noschinl@43994
  1422
noschinl@43994
  1423
  \begin{matharray}{lll}
noschinl@43994
  1424
    @{text "map"} & @{text "::"} &
noschinl@43994
  1425
      @{text "f\<^isub>1 \<Rightarrow> \<dots> \<Rightarrow> f\<^isub>n \<Rightarrow> (\<alpha>\<^isub>1, \<dots>, \<alpha>\<^isub>n) t \<Rightarrow> (\<beta>\<^isub>1, \<dots>, \<beta>\<^isub>n) t"} \\
noschinl@43994
  1426
  \end{matharray}
noschinl@43994
  1427
noschinl@43994
  1428
  where @{text "t"} is a type constructor and @{text "f\<^isub>i"} is of
noschinl@43994
  1429
  type @{text "\<alpha>\<^isub>i \<Rightarrow> \<beta>\<^isub>i"} or
noschinl@43994
  1430
  @{text "\<beta>\<^isub>i \<Rightarrow> \<alpha>\<^isub>i"}.
noschinl@43994
  1431
  Registering a map function overwrites any existing map function for
noschinl@43994
  1432
  this particular type constructor.
noschinl@43994
  1433
noschinl@43994
  1434
noschinl@43994
  1435
  \item @{attribute (HOL) "coercion_enabled"} enables the coercion
noschinl@43994
  1436
  inference algorithm.
noschinl@43994
  1437
noschinl@43994
  1438
  \end{description}
noschinl@43994
  1439
noschinl@43994
  1440
*}
noschinl@43994
  1441
wenzelm@26849
  1442
section {* Arithmetic proof support *}
wenzelm@26849
  1443
wenzelm@26849
  1444
text {*
wenzelm@26849
  1445
  \begin{matharray}{rcl}
wenzelm@28761
  1446
    @{method_def (HOL) arith} & : & @{text method} \\
nipkow@30863
  1447
    @{attribute_def (HOL) arith} & : & @{text attribute} \\
wenzelm@28761
  1448
    @{attribute_def (HOL) arith_split} & : & @{text attribute} \\
wenzelm@26849
  1449
  \end{matharray}
wenzelm@26849
  1450
wenzelm@26849
  1451
  The @{method (HOL) arith} method decides linear arithmetic problems
wenzelm@26849
  1452
  (on types @{text nat}, @{text int}, @{text real}).  Any current
wenzelm@26849
  1453
  facts are inserted into the goal before running the procedure.
wenzelm@26849
  1454
nipkow@30863
  1455
  The @{attribute (HOL) arith} attribute declares facts that are
nipkow@30863
  1456
  always supplied to the arithmetic provers implicitly.
wenzelm@26849
  1457
nipkow@30863
  1458
  The @{attribute (HOL) arith_split} attribute declares case split
wenzelm@30865
  1459
  rules to be expanded before @{method (HOL) arith} is invoked.
nipkow@30863
  1460
nipkow@30863
  1461
  Note that a simpler (but faster) arithmetic prover is
nipkow@30863
  1462
  already invoked by the Simplifier.
wenzelm@26849
  1463
*}
wenzelm@26849
  1464
wenzelm@26849
  1465
wenzelm@30169
  1466
section {* Intuitionistic proof search *}
wenzelm@30169
  1467
wenzelm@30169
  1468
text {*
wenzelm@30169
  1469
  \begin{matharray}{rcl}
wenzelm@30171
  1470
    @{method_def (HOL) iprover} & : & @{text method} \\
wenzelm@30169
  1471
  \end{matharray}
wenzelm@30169
  1472
wenzelm@42596
  1473
  @{rail "
wenzelm@42596
  1474
    @@{method (HOL) iprover} ( @{syntax rulemod} * )
wenzelm@42596
  1475
  "}
wenzelm@30169
  1476
wenzelm@30171
  1477
  The @{method (HOL) iprover} method performs intuitionistic proof
wenzelm@30171
  1478
  search, depending on specifically declared rules from the context,
wenzelm@30171
  1479
  or given as explicit arguments.  Chained facts are inserted into the
wenzelm@35613
  1480
  goal before commencing proof search.
wenzelm@35613
  1481
wenzelm@30169
  1482
  Rules need to be classified as @{attribute (Pure) intro},
wenzelm@30169
  1483
  @{attribute (Pure) elim}, or @{attribute (Pure) dest}; here the
wenzelm@30169
  1484
  ``@{text "!"}'' indicator refers to ``safe'' rules, which may be
wenzelm@30169
  1485
  applied aggressively (without considering back-tracking later).
wenzelm@30169
  1486
  Rules declared with ``@{text "?"}'' are ignored in proof search (the
wenzelm@42626
  1487
  single-step @{method (Pure) rule} method still observes these).  An
wenzelm@30169
  1488
  explicit weight annotation may be given as well; otherwise the
wenzelm@30169
  1489
  number of rule premises will be taken into account here.
wenzelm@30169
  1490
*}
wenzelm@30169
  1491
blanchet@43578
  1492
section {* Model Elimination and Resolution *}
blanchet@43578
  1493
blanchet@43578
  1494
text {*
blanchet@43578
  1495
  \begin{matharray}{rcl}
blanchet@43578
  1496
    @{method_def (HOL) "meson"} & : & @{text method} \\
blanchet@43578
  1497
    @{method_def (HOL) "metis"} & : & @{text method} \\
blanchet@43578
  1498
  \end{matharray}
blanchet@43578
  1499
blanchet@43578
  1500
  @{rail "
blanchet@43578
  1501
    @@{method (HOL) meson} @{syntax thmrefs}?
blanchet@43578
  1502
    ;
blanchet@43578
  1503
blanchet@43578
  1504
    @@{method (HOL) metis} ( '(' ('partial_types' | 'full_types' | 'no_types'
blanchet@43578
  1505
                                  | @{syntax name}) ')' )? @{syntax thmrefs}?
blanchet@43578
  1506
  "}
blanchet@43578
  1507
blanchet@43578
  1508
  The @{method (HOL) meson} method implements Loveland's model elimination
blanchet@43578
  1509
  procedure \cite{loveland-78}. See @{file "~~/src/HOL/ex/Meson_Test.thy"} for
blanchet@43578
  1510
  examples.
blanchet@43578
  1511
blanchet@43578
  1512
  The @{method (HOL) metis} method combines ordered resolution and ordered
blanchet@43578
  1513
  paramodulation to find first-order (or mildly higher-order) proofs. The first
blanchet@43578
  1514
  optional argument specifies a type encoding; see the Sledgehammer manual
blanchet@43578
  1515
  \cite{isabelle-sledgehammer} for details. The @{file
blanchet@43578
  1516
  "~~/src/HOL/Metis_Examples"} directory contains several small theories
blanchet@43578
  1517
  developed to a large extent using Metis.
blanchet@43578
  1518
*}
wenzelm@30169
  1519
wenzelm@30171
  1520
section {* Coherent Logic *}
wenzelm@30171
  1521
wenzelm@30171
  1522
text {*
wenzelm@30171
  1523
  \begin{matharray}{rcl}
wenzelm@30171
  1524
    @{method_def (HOL) "coherent"} & : & @{text method} \\
wenzelm@30171
  1525
  \end{matharray}
wenzelm@30171
  1526
wenzelm@42596
  1527
  @{rail "
wenzelm@42596
  1528
    @@{method (HOL) coherent} @{syntax thmrefs}?
wenzelm@42596
  1529
  "}
wenzelm@30171
  1530
wenzelm@30171
  1531
  The @{method (HOL) coherent} method solves problems of
wenzelm@30171
  1532
  \emph{Coherent Logic} \cite{Bezem-Coquand:2005}, which covers
wenzelm@30171
  1533
  applications in confluence theory, lattice theory and projective
wenzelm@40800
  1534
  geometry.  See @{file "~~/src/HOL/ex/Coherent.thy"} for some
wenzelm@30171
  1535
  examples.
wenzelm@30171
  1536
*}
wenzelm@30171
  1537
wenzelm@30171
  1538
blanchet@42215
  1539
section {* Proving propositions *}
blanchet@42215
  1540
blanchet@42215
  1541
text {*
blanchet@42215
  1542
  In addition to the standard proof methods, a number of diagnosis
blanchet@42215
  1543
  tools search for proofs and provide an Isar proof snippet on success.
blanchet@42215
  1544
  These tools are available via the following commands.
blanchet@42215
  1545
blanchet@42215
  1546
  \begin{matharray}{rcl}
blanchet@42215
  1547
    @{command_def (HOL) "solve_direct"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  1548
    @{command_def (HOL) "try"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@43016
  1549
    @{command_def (HOL) "try_methods"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  1550
    @{command_def (HOL) "sledgehammer"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  1551
    @{command_def (HOL) "sledgehammer_params"} & : & @{text "theory \<rightarrow> theory"}
blanchet@42215
  1552
  \end{matharray}
blanchet@42215
  1553
wenzelm@42596
  1554
  @{rail "
blanchet@43040
  1555
    @@{command (HOL) try}
blanchet@43040
  1556
    ;
blanchet@43040
  1557
blanchet@43016
  1558
    @@{command (HOL) try_methods} ( ( ( 'simp' | 'intro' | 'elim' | 'dest' ) ':' @{syntax thmrefs} ) + ) ?
wenzelm@42596
  1559
      @{syntax nat}?
blanchet@42215
  1560
    ;
blanchet@43040
  1561
wenzelm@42596
  1562
    @@{command (HOL) sledgehammer} ( '[' args ']' )? facts? @{syntax nat}?
blanchet@42215
  1563
    ;
blanchet@42215
  1564
wenzelm@42596
  1565
    @@{command (HOL) sledgehammer_params} ( ( '[' args ']' ) ? )
blanchet@42215
  1566
    ;
blanchet@42215
  1567
wenzelm@42596
  1568
    args: ( @{syntax name} '=' value + ',' )
blanchet@42215
  1569
    ;
blanchet@42215
  1570
wenzelm@42596
  1571
    facts: '(' ( ( ( ( 'add' | 'del' ) ':' ) ? @{syntax thmrefs} ) + ) ? ')'
blanchet@42215
  1572
    ;
blanchet@43019
  1573
  "} % FIXME check args "value"
blanchet@42215
  1574
blanchet@42215
  1575
  \begin{description}
blanchet@42215
  1576
blanchet@42215
  1577
  \item @{command (HOL) "solve_direct"} checks whether the current subgoals can
blanchet@42215
  1578
    be solved directly by an existing theorem. Duplicate lemmas can be detected
blanchet@42215
  1579
    in this way.
blanchet@42215
  1580
blanchet@43016
  1581
  \item @{command (HOL) "try_methods"} attempts to prove a subgoal using a combination
blanchet@42215
  1582
    of standard proof methods (@{text auto}, @{text simp}, @{text blast}, etc.).
blanchet@42215
  1583
    Additional facts supplied via @{text "simp:"}, @{text "intro:"},
blanchet@42215
  1584
    @{text "elim:"}, and @{text "dest:"} are passed to the appropriate proof
blanchet@42215
  1585
    methods.
blanchet@42215
  1586
bulwahn@43914
  1587
  \item @{command (HOL) "try"} attempts to prove or disprove a subgoal
bulwahn@43914
  1588
    using a combination of provers and disprovers (@{text "solve_direct"},
bulwahn@43914
  1589
    @{text "quickcheck"}, @{text "try_methods"}, @{text "sledgehammer"},
bulwahn@43914
  1590
    @{text "nitpick"}).
bulwahn@43914
  1591
blanchet@42215
  1592
  \item @{command (HOL) "sledgehammer"} attempts to prove a subgoal using external
blanchet@42215
  1593
    automatic provers (resolution provers and SMT solvers). See the Sledgehammer
blanchet@42215
  1594
    manual \cite{isabelle-sledgehammer} for details.
blanchet@42215
  1595
blanchet@42215
  1596
  \item @{command (HOL) "sledgehammer_params"} changes
blanchet@42215
  1597
    @{command (HOL) "sledgehammer"} configuration options persistently.
blanchet@42215
  1598
blanchet@42215
  1599
  \end{description}
blanchet@42215
  1600
*}
blanchet@42215
  1601
blanchet@42215
  1602
haftmann@31912
  1603
section {* Checking and refuting propositions *}
haftmann@31912
  1604
haftmann@31912
  1605
text {*
haftmann@31912
  1606
  Identifying incorrect propositions usually involves evaluation of
blanchet@42215
  1607
  particular assignments and systematic counterexample search.  This
haftmann@31912
  1608
  is supported by the following commands.
haftmann@31912
  1609
haftmann@31912
  1610
  \begin{matharray}{rcl}
haftmann@31912
  1611
    @{command_def (HOL) "value"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
bulwahn@45409
  1612
    @{command_def (HOL) "values"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@31912
  1613
    @{command_def (HOL) "quickcheck"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  1614
    @{command_def (HOL) "refute"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  1615
    @{command_def (HOL) "nitpick"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  1616
    @{command_def (HOL) "quickcheck_params"} & : & @{text "theory \<rightarrow> theory"} \\
blanchet@42215
  1617
    @{command_def (HOL) "refute_params"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45943
  1618
    @{command_def (HOL) "nitpick_params"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45943
  1619
    @{command_def (HOL) "quickcheck_generator"} & : & @{text "theory \<rightarrow> theory"}
haftmann@31912
  1620
  \end{matharray}
haftmann@31912
  1621
wenzelm@42596
  1622
  @{rail "
wenzelm@42596
  1623
    @@{command (HOL) value} ( '[' name ']' )? modes? @{syntax term}
haftmann@31912
  1624
    ;
haftmann@31912
  1625
bulwahn@45409
  1626
    @@{command (HOL) values} modes? @{syntax nat}? @{syntax term}
bulwahn@45409
  1627
    ;
bulwahn@45409
  1628
wenzelm@42596
  1629
    (@@{command (HOL) quickcheck} | @@{command (HOL) refute} | @@{command (HOL) nitpick})
wenzelm@42596
  1630
      ( '[' args ']' )? @{syntax nat}?
haftmann@31912
  1631
    ;
haftmann@31912
  1632
wenzelm@42596
  1633
    (@@{command (HOL) quickcheck_params} | @@{command (HOL) refute_params} |
wenzelm@42596
  1634
      @@{command (HOL) nitpick_params}) ( '[' args ']' )?
haftmann@31912
  1635
    ;
bulwahn@45943
  1636
    @@{command (HOL) quickcheck_generator} typeconstructor \\
bulwahn@45943
  1637
      'operations:' ( @{syntax term} +)
bulwahn@45943
  1638
    ;
haftmann@31912
  1639
wenzelm@42596
  1640
    modes: '(' (@{syntax name} +) ')'
haftmann@31912
  1641
    ;
haftmann@31912
  1642
wenzelm@42596
  1643
    args: ( @{syntax name} '=' value + ',' )
haftmann@31912
  1644
    ;
wenzelm@42596
  1645
  "} % FIXME check "value"
haftmann@31912
  1646
haftmann@31912
  1647
  \begin{description}
haftmann@31912
  1648
haftmann@31912
  1649
  \item @{command (HOL) "value"}~@{text t} evaluates and prints a
haftmann@31912
  1650
    term; optionally @{text modes} can be specified, which are
wenzelm@42926
  1651
    appended to the current print mode; see \secref{sec:print-modes}.
haftmann@31912
  1652
    Internally, the evaluation is performed by registered evaluators,
haftmann@31912
  1653
    which are invoked sequentially until a result is returned.
haftmann@31912
  1654
    Alternatively a specific evaluator can be selected using square
haftmann@37444
  1655
    brackets; typical evaluators use the current set of code equations
wenzelm@42926
  1656
    to normalize and include @{text simp} for fully symbolic
wenzelm@42926
  1657
    evaluation using the simplifier, @{text nbe} for
wenzelm@42926
  1658
    \emph{normalization by evaluation} and \emph{code} for code
wenzelm@42926
  1659
    generation in SML.
haftmann@31912
  1660
bulwahn@45409
  1661
  \item @{command (HOL) "values"}~@{text t} enumerates a set comprehension
bulwahn@45409
  1662
    by evaluation and prints its values up to the given number of solutions;  
bulwahn@45409
  1663
    optionally @{text modes} can be specified, which are
bulwahn@45409
  1664
    appended to the current print mode; see \secref{sec:print-modes}.
bulwahn@45409
  1665
haftmann@31912
  1666
  \item @{command (HOL) "quickcheck"} tests the current goal for
blanchet@42215
  1667
    counterexamples using a series of assignments for its
haftmann@31912
  1668
    free variables; by default the first subgoal is tested, an other
haftmann@31912
  1669
    can be selected explicitly using an optional goal index.
bulwahn@40918
  1670
    Assignments can be chosen exhausting the search space upto a given
bulwahn@43914
  1671
    size, or using a fixed number of random assignments in the search space,
bulwahn@43914
  1672
    or exploring the search space symbolically using narrowing.
bulwahn@40918
  1673
    By default, quickcheck uses exhaustive testing.
haftmann@31912
  1674
    A number of configuration options are supported for
haftmann@31912
  1675
    @{command (HOL) "quickcheck"}, notably:
haftmann@31912
  1676
haftmann@31912
  1677
    \begin{description}
haftmann@31912
  1678
bulwahn@43914
  1679
    \item[@{text tester}] specifies which testing approach to apply.
bulwahn@43914
  1680
      There are three testers, @{text exhaustive},
bulwahn@43914
  1681
      @{text random}, and @{text narrowing}.
bulwahn@40918
  1682
      An unknown configuration option is treated as an argument to tester,
bulwahn@40918
  1683
      making @{text "tester ="} optional.
bulwahn@43914
  1684
      When multiple testers are given, these are applied in parallel. 
bulwahn@43914
  1685
      If no tester is specified, quickcheck uses the testers that are
bulwahn@43914
  1686
      set active, i.e., configurations
bulwahn@43914
  1687
      @{text quickcheck_exhaustive_active}, @{text quickcheck_random_active},
bulwahn@43914
  1688
      @{text quickcheck_narrowing_active} are set to true.
wenzelm@40254
  1689
    \item[@{text size}] specifies the maximum size of the search space
wenzelm@40254
  1690
    for assignment values.
haftmann@31912
  1691
bulwahn@45758
  1692
    \item[@{text genuine_only}] sets quickcheck only to return genuine
bulwahn@45758
  1693
      counterexample, but not potentially spurious counterexamples due
bulwahn@45758
  1694
      to underspecified functions.
bulwahn@45758
  1695
    
bulwahn@42092
  1696
    \item[@{text eval}] takes a term or a list of terms and evaluates
bulwahn@42092
  1697
      these terms under the variable assignment found by quickcheck.
wenzelm@42123
  1698
wenzelm@40254
  1699
    \item[@{text iterations}] sets how many sets of assignments are
wenzelm@40254
  1700
    generated for each particular size.
haftmann@31912
  1701
wenzelm@40254
  1702
    \item[@{text no_assms}] specifies whether assumptions in
wenzelm@40254
  1703
    structured proofs should be ignored.
blanchet@35331
  1704
wenzelm@40254
  1705
    \item[@{text timeout}] sets the time limit in seconds.
bulwahn@40245
  1706
wenzelm@40254
  1707
    \item[@{text default_type}] sets the type(s) generally used to
wenzelm@40254
  1708
    instantiate type variables.
bulwahn@40245
  1709
wenzelm@40254
  1710
    \item[@{text report}] if set quickcheck reports how many tests
wenzelm@40254
  1711
    fulfilled the preconditions.
bulwahn@40245
  1712
bulwahn@45766
  1713
    \item[@{text quiet}] if set quickcheck does not output anything
bulwahn@45766
  1714
    while testing.
bulwahn@45766
  1715
    
bulwahn@45766
  1716
    \item[@{text verbose}] if set quickcheck informs about the
bulwahn@45766
  1717
    current size and cardinality while testing.
bulwahn@40245
  1718
wenzelm@40254
  1719
    \item[@{text expect}] can be used to check if the user's
wenzelm@40254
  1720
    expectation was met (@{text no_expectation}, @{text
wenzelm@40254
  1721
    no_counterexample}, or @{text counterexample}).
bulwahn@40245
  1722
haftmann@31912
  1723
    \end{description}
haftmann@31912
  1724
haftmann@31912
  1725
    These option can be given within square brackets.
haftmann@31912
  1726
blanchet@42215
  1727
  \item @{command (HOL) "quickcheck_params"} changes
blanchet@42215
  1728
    @{command (HOL) "quickcheck"} configuration options persistently.
blanchet@42215
  1729
bulwahn@45943
  1730
  \item @{command (HOL) "quickcheck_generator"} creates random and
bulwahn@45943
  1731
    exhaustive value generators for a given type and operations.
bulwahn@45943
  1732
    It generates values by using the operations as if they were
bulwahn@45943
  1733
    constructors of that type.
bulwahn@45943
  1734
blanchet@42215
  1735
  \item @{command (HOL) "refute"} tests the current goal for
blanchet@42215
  1736
    counterexamples using a reduction to SAT. The following configuration
blanchet@42215
  1737
    options are supported:
blanchet@42215
  1738
blanchet@42215
  1739
    \begin{description}
blanchet@42215
  1740
blanchet@42215
  1741
    \item[@{text minsize}] specifies the minimum size (cardinality) of the
blanchet@42215
  1742
      models to search for.
blanchet@42215
  1743
blanchet@42215
  1744
    \item[@{text maxsize}] specifies the maximum size (cardinality) of the
blanchet@42215
  1745
      models to search for. Nonpositive values mean $\infty$.
blanchet@42215
  1746
blanchet@42215
  1747
    \item[@{text maxvars}] specifies the maximum number of Boolean variables
blanchet@42215
  1748
    to use when transforming the term into a propositional formula.
blanchet@42215
  1749
    Nonpositive values mean $\infty$.
blanchet@42215
  1750
blanchet@42215
  1751
    \item[@{text satsolver}] specifies the SAT solver to use.
blanchet@42215
  1752
blanchet@42215
  1753
    \item[@{text no_assms}] specifies whether assumptions in
blanchet@42215
  1754
    structured proofs should be ignored.
blanchet@42215
  1755
blanchet@42215
  1756
    \item[@{text maxtime}] sets the time limit in seconds.
blanchet@42215
  1757
blanchet@42215
  1758
    \item[@{text expect}] can be used to check if the user's
blanchet@42215
  1759
    expectation was met (@{text genuine}, @{text potential},
blanchet@42215
  1760
    @{text none}, or @{text unknown}).
blanchet@42215
  1761
blanchet@42215
  1762
    \end{description}
blanchet@42215
  1763
blanchet@42215
  1764
    These option can be given within square brackets.
blanchet@42215
  1765
blanchet@42215
  1766
  \item @{command (HOL) "refute_params"} changes
blanchet@42215
  1767
    @{command (HOL) "refute"} configuration options persistently.
blanchet@42215
  1768
blanchet@42215
  1769
  \item @{command (HOL) "nitpick"} tests the current goal for counterexamples
blanchet@42215
  1770
    using a reduction to first-order relational logic. See the Nitpick manual
blanchet@42215
  1771
    \cite{isabelle-nitpick} for details.
blanchet@42215
  1772
blanchet@42215
  1773
  \item @{command (HOL) "nitpick_params"} changes
blanchet@42215
  1774
    @{command (HOL) "nitpick"} configuration options persistently.
haftmann@31912
  1775
haftmann@31912
  1776
  \end{description}
haftmann@31912
  1777
*}
haftmann@31912
  1778
haftmann@31912
  1779
wenzelm@28752
  1780
section {* Unstructured case analysis and induction \label{sec:hol-induct-tac} *}
wenzelm@26849
  1781
wenzelm@26849
  1782
text {*
wenzelm@27123
  1783
  The following tools of Isabelle/HOL support cases analysis and
wenzelm@27123
  1784
  induction in unstructured tactic scripts; see also
wenzelm@27123
  1785
  \secref{sec:cases-induct} for proper Isar versions of similar ideas.
wenzelm@26849
  1786
wenzelm@26849
  1787
  \begin{matharray}{rcl}
wenzelm@28761
  1788
    @{method_def (HOL) case_tac}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
  1789
    @{method_def (HOL) induct_tac}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
  1790
    @{method_def (HOL) ind_cases}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
  1791
    @{command_def (HOL) "inductive_cases"}@{text "\<^sup>*"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@26849
  1792
  \end{matharray}
wenzelm@26849
  1793
wenzelm@42596
  1794
  @{rail "
wenzelm@42705
  1795
    @@{method (HOL) case_tac} @{syntax goal_spec}? @{syntax term} rule?
wenzelm@26849
  1796
    ;
wenzelm@42705
  1797
    @@{method (HOL) induct_tac} @{syntax goal_spec}? (@{syntax insts} * @'and') rule?
wenzelm@26849
  1798
    ;
wenzelm@42596
  1799
    @@{method (HOL) ind_cases} (@{syntax prop}+) (@'for' (@{syntax name}+))?
wenzelm@26849
  1800
    ;
wenzelm@42596
  1801
    @@{command (HOL) inductive_cases} (@{syntax thmdecl}? (@{syntax prop}+) + @'and')
wenzelm@26849
  1802
    ;
wenzelm@26849
  1803
wenzelm@42596
  1804
    rule: 'rule' ':' @{syntax thmref}
wenzelm@42596
  1805
  "}
wenzelm@26849
  1806
wenzelm@28760
  1807
  \begin{description}
wenzelm@26849
  1808
wenzelm@28760
  1809
  \item @{method (HOL) case_tac} and @{method (HOL) induct_tac} admit
wenzelm@28760
  1810
  to reason about inductive types.  Rules are selected according to
wenzelm@28760
  1811
  the declarations by the @{attribute cases} and @{attribute induct}
wenzelm@28760
  1812
  attributes, cf.\ \secref{sec:cases-induct}.  The @{command (HOL)
wenzelm@28760
  1813
  datatype} package already takes care of this.
wenzelm@27123
  1814
wenzelm@27123
  1815
  These unstructured tactics feature both goal addressing and dynamic
wenzelm@26849
  1816
  instantiation.  Note that named rule cases are \emph{not} provided
wenzelm@27123
  1817
  as would be by the proper @{method cases} and @{method induct} proof
wenzelm@27123
  1818
  methods (see \secref{sec:cases-induct}).  Unlike the @{method
wenzelm@27123
  1819
  induct} method, @{method induct_tac} does not handle structured rule
wenzelm@27123
  1820
  statements, only the compact object-logic conclusion of the subgoal
wenzelm@27123
  1821
  being addressed.
wenzelm@42123
  1822
wenzelm@28760
  1823
  \item @{method (HOL) ind_cases} and @{command (HOL)
wenzelm@28760
  1824
  "inductive_cases"} provide an interface to the internal @{ML_text
wenzelm@26860
  1825
  mk_cases} operation.  Rules are simplified in an unrestricted
wenzelm@26860
  1826
  forward manner.
wenzelm@26849
  1827
wenzelm@26849
  1828
  While @{method (HOL) ind_cases} is a proof method to apply the
wenzelm@26849
  1829
  result immediately as elimination rules, @{command (HOL)
wenzelm@26849
  1830
  "inductive_cases"} provides case split theorems at the theory level
wenzelm@26849
  1831
  for later use.  The @{keyword "for"} argument of the @{method (HOL)
wenzelm@26849
  1832
  ind_cases} method allows to specify a list of variables that should
wenzelm@26849
  1833
  be generalized before applying the resulting rule.
wenzelm@26849
  1834
wenzelm@28760
  1835
  \end{description}
wenzelm@26849
  1836
*}
wenzelm@26849
  1837
wenzelm@26849
  1838
wenzelm@26849
  1839
section {* Executable code *}
wenzelm@26849
  1840
wenzelm@42627
  1841
text {* For validation purposes, it is often useful to \emph{execute}
wenzelm@42627
  1842
  specifications.  In principle, execution could be simulated by
wenzelm@42627
  1843
  Isabelle's inference kernel, i.e. by a combination of resolution and
wenzelm@42627
  1844
  simplification.  Unfortunately, this approach is rather inefficient.
wenzelm@42627
  1845
  A more efficient way of executing specifications is to translate
wenzelm@42627
  1846
  them into a functional programming language such as ML.
wenzelm@26849
  1847
wenzelm@45192
  1848
  Isabelle provides a generic framework to support code generation
wenzelm@42627
  1849
  from executable specifications.  Isabelle/HOL instantiates these
wenzelm@45192
  1850
  mechanisms in a way that is amenable to end-user applications.  Code
wenzelm@45192
  1851
  can be generated for functional programs (including overloading
wenzelm@45192
  1852
  using type classes) targeting SML \cite{SML}, OCaml \cite{OCaml},
wenzelm@45192
  1853
  Haskell \cite{haskell-revised-report} and Scala
wenzelm@42627
  1854
  \cite{scala-overview-tech-report}.  Conceptually, code generation is
wenzelm@42627
  1855
  split up in three steps: \emph{selection} of code theorems,
wenzelm@42627
  1856
  \emph{translation} into an abstract executable view and
wenzelm@42627
  1857
  \emph{serialization} to a specific \emph{target language}.
wenzelm@42627
  1858
  Inductive specifications can be executed using the predicate
wenzelm@42627
  1859
  compiler which operates within HOL.  See \cite{isabelle-codegen} for
wenzelm@42627
  1860
  an introduction.
haftmann@37422
  1861
haftmann@37422
  1862
  \begin{matharray}{rcl}
haftmann@37422
  1863
    @{command_def (HOL) "export_code"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1864
    @{attribute_def (HOL) code} & : & @{text attribute} \\
haftmann@37422
  1865
    @{command_def (HOL) "code_abort"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1866
    @{command_def (HOL) "code_datatype"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1867
    @{command_def (HOL) "print_codesetup"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
bulwahn@45232
  1868
    @{attribute_def (HOL) code_unfold} & : & @{text attribute} \\
haftmann@37422
  1869
    @{attribute_def (HOL) code_post} & : & @{text attribute} \\
haftmann@46028
  1870
    @{attribute_def (HOL) code_abbrev} & : & @{text attribute} \\
haftmann@37422
  1871
    @{command_def (HOL) "print_codeproc"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1872
    @{command_def (HOL) "code_thms"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1873
    @{command_def (HOL) "code_deps"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1874
    @{command_def (HOL) "code_const"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1875
    @{command_def (HOL) "code_type"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1876
    @{command_def (HOL) "code_class"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1877
    @{command_def (HOL) "code_instance"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1878
    @{command_def (HOL) "code_reserved"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1879
    @{command_def (HOL) "code_monad"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1880
    @{command_def (HOL) "code_include"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1881
    @{command_def (HOL) "code_modulename"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45408
  1882
    @{command_def (HOL) "code_reflect"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45408
  1883
    @{command_def (HOL) "code_pred"} & : & @{text "theory \<rightarrow> proof(prove)"}
haftmann@37422
  1884
  \end{matharray}
haftmann@37422
  1885
wenzelm@42596
  1886
  @{rail "
wenzelm@42596
  1887
    @@{command (HOL) export_code} ( constexpr + ) \\
wenzelm@42596
  1888
       ( ( @'in' target ( @'module_name' @{syntax string} ) ? \\
wenzelm@42596
  1889
        ( @'file' ( @{syntax string} | '-' ) ) ? ( '(' args ')' ) ?) + ) ?
haftmann@37422
  1890
    ;
haftmann@37422
  1891
wenzelm@42596
  1892
    const: @{syntax term}
haftmann@37422
  1893
    ;
haftmann@37422
  1894
haftmann@40711
  1895
    constexpr: ( const | 'name._' | '_' )
haftmann@37422
  1896
    ;
haftmann@37422
  1897
wenzelm@42596
  1898
    typeconstructor: @{syntax nameref}
haftmann@37422
  1899
    ;
haftmann@37422
  1900
wenzelm@42596
  1901
    class: @{syntax nameref}
haftmann@37422
  1902
    ;
haftmann@37422
  1903
haftmann@38814
  1904
    target: 'SML' | 'OCaml' | 'Haskell' | 'Scala'
haftmann@37422
  1905
    ;
haftmann@37422
  1906
wenzelm@42596
  1907
    @@{attribute (HOL) code} ( 'del' | 'abstype' | 'abstract' )?
haftmann@37422
  1908
    ;
haftmann@37422
  1909
wenzelm@42596
  1910
    @@{command (HOL) code_abort} ( const + )
haftmann@37422
  1911
    ;
haftmann@37422
  1912
wenzelm@42596
  1913
    @@{command (HOL) code_datatype} ( const + )
haftmann@37422
  1914
    ;
haftmann@37422
  1915
bulwahn@45232
  1916
    @@{attribute (HOL) code_unfold} ( 'del' ) ?
haftmann@37422
  1917
    ;
haftmann@37422
  1918
wenzelm@42596
  1919
    @@{attribute (HOL) code_post} ( 'del' ) ?
haftmann@37422
  1920
    ;
haftmann@37422
  1921
haftmann@46028
  1922
    @@{attribute (HOL) code_abbrev}
bulwahn@45232
  1923
    ;
bulwahn@45232
  1924
wenzelm@42596
  1925
    @@{command (HOL) code_thms} ( constexpr + ) ?
haftmann@37422
  1926
    ;
haftmann@37422
  1927
wenzelm@42596
  1928
    @@{command (HOL) code_deps} ( constexpr + ) ?
haftmann@37422
  1929
    ;
haftmann@37422
  1930
wenzelm@42596
  1931
    @@{command (HOL) code_const} (const + @'and') \\
wenzelm@42596
  1932
      ( ( '(' target ( syntax ? + @'and' ) ')' ) + )
haftmann@37422
  1933
    ;
haftmann@37422
  1934
wenzelm@42596
  1935
    @@{command (HOL) code_type} (typeconstructor + @'and') \\
wenzelm@42596
  1936
      ( ( '(' target ( syntax ? + @'and' ) ')' ) + )
haftmann@37422
  1937
    ;
haftmann@37422
  1938
wenzelm@42596
  1939
    @@{command (HOL) code_class} (class + @'and') \\
wenzelm@42596
  1940
      ( ( '(' target \\ ( @{syntax string} ? + @'and' ) ')' ) + )
haftmann@37422
  1941
    ;
haftmann@37422
  1942
wenzelm@42596
  1943
    @@{command (HOL) code_instance} (( typeconstructor '::' class ) + @'and') \\
wenzelm@42596
  1944
      ( ( '(' target ( '-' ? + @'and' ) ')' ) + )
haftmann@37422
  1945
    ;
haftmann@37422
  1946
wenzelm@42596
  1947
    @@{command (HOL) code_reserved} target ( @{syntax string} + )
haftmann@37422
  1948
    ;
haftmann@37422
  1949
wenzelm@42596
  1950
    @@{command (HOL) code_monad} const const target
haftmann@37422
  1951
    ;
haftmann@37422
  1952
wenzelm@42596
  1953
    @@{command (HOL) code_include} target ( @{syntax string} ( @{syntax string} | '-') )
haftmann@37422
  1954
    ;
haftmann@37422
  1955
wenzelm@42596
  1956
    @@{command (HOL) code_modulename} target ( ( @{syntax string} @{syntax string} ) + )
haftmann@39608
  1957
    ;
haftmann@39608
  1958
wenzelm@42596
  1959
    @@{command (HOL) code_reflect} @{syntax string} \\
wenzelm@42596
  1960
      ( @'datatypes' ( @{syntax string} '=' ( '_' | ( @{syntax string} + '|' ) + @'and' ) ) ) ? \\
wenzelm@42596
  1961
      ( @'functions' ( @{syntax string} + ) ) ? ( @'file' @{syntax string} ) ?
haftmann@37422
  1962
    ;
haftmann@37422
  1963
bulwahn@45408
  1964
    @@{command (HOL) code_pred} \\( '(' @'modes' ':' modedecl ')')? \\ const
bulwahn@45408
  1965
    ;
bulwahn@45408
  1966
wenzelm@42596
  1967
    syntax: @{syntax string} | ( @'infix' | @'infixl' | @'infixr' ) @{syntax nat} @{syntax string}
bulwahn@45408
  1968
    ;
bulwahn@45408
  1969
    
bulwahn@45408
  1970
    modedecl: (modes | ((const ':' modes) \\
bulwahn@45408
  1971
         (@'and' ((const ':' modes @'and') +))?))
bulwahn@45408
  1972
    ;
bulwahn@45408
  1973
    
bulwahn@45408
  1974
    modes: mode @'as' const
wenzelm@42596
  1975
  "}
haftmann@37422
  1976
haftmann@37422
  1977
  \begin{description}
haftmann@37422
  1978
haftmann@37422
  1979
  \item @{command (HOL) "export_code"} generates code for a given list
haftmann@39608
  1980
  of constants in the specified target language(s).  If no
haftmann@39608
  1981
  serialization instruction is given, only abstract code is generated
haftmann@39608
  1982
  internally.
haftmann@37422
  1983
haftmann@37422
  1984
  Constants may be specified by giving them literally, referring to
haftmann@37422
  1985
  all executable contants within a certain theory by giving @{text
haftmann@37422
  1986
  "name.*"}, or referring to \emph{all} executable constants currently
haftmann@37422
  1987
  available by giving @{text "*"}.
haftmann@37422
  1988
haftmann@37422
  1989
  By default, for each involved theory one corresponding name space
haftmann@37422
  1990
  module is generated.  Alternativly, a module name may be specified
haftmann@37422
  1991
  after the @{keyword "module_name"} keyword; then \emph{all} code is
haftmann@37422
  1992
  placed in this module.
haftmann@37422
  1993
haftmann@39608
  1994
  For \emph{SML}, \emph{OCaml} and \emph{Scala} the file specification
haftmann@39608
  1995
  refers to a single file; for \emph{Haskell}, it refers to a whole
haftmann@39608
  1996
  directory, where code is generated in multiple files reflecting the
haftmann@39608
  1997
  module hierarchy.  Omitting the file specification denotes standard
haftmann@37749
  1998
  output.
haftmann@37422
  1999
haftmann@37422
  2000
  Serializers take an optional list of arguments in parentheses.  For
haftmann@37422
  2001
  \emph{SML} and \emph{OCaml}, ``@{text no_signatures}`` omits
haftmann@37422
  2002
  explicit module signatures.
wenzelm@42123
  2003
haftmann@39608
  2004
  For \emph{Haskell} a module name prefix may be given using the
haftmann@39608
  2005
  ``@{text "root:"}'' argument; ``@{text string_classes}'' adds a
haftmann@39608
  2006
  ``@{verbatim "deriving (Read, Show)"}'' clause to each appropriate
haftmann@39608
  2007
  datatype declaration.
haftmann@37422
  2008
haftmann@37422
  2009
  \item @{attribute (HOL) code} explicitly selects (or with option
haftmann@38462
  2010
  ``@{text "del"}'' deselects) a code equation for code generation.
haftmann@38462
  2011
  Usually packages introducing code equations provide a reasonable
haftmann@38462
  2012
  default setup for selection.  Variants @{text "code abstype"} and
haftmann@38462
  2013
  @{text "code abstract"} declare abstract datatype certificates or
haftmann@38462
  2014
  code equations on abstract datatype representations respectively.
haftmann@37422
  2015
haftmann@37422
  2016
  \item @{command (HOL) "code_abort"} declares constants which are not
haftmann@39608
  2017
  required to have a definition by means of code equations; if needed
haftmann@39608
  2018
  these are implemented by program abort instead.
haftmann@37422
  2019
haftmann@37422
  2020
  \item @{command (HOL) "code_datatype"} specifies a constructor set
haftmann@37422
  2021
  for a logical type.
haftmann@37422
  2022
haftmann@37422
  2023
  \item @{command (HOL) "print_codesetup"} gives an overview on
haftmann@37422
  2024
  selected code equations and code generator datatypes.
haftmann@37422
  2025
bulwahn@45232
  2026
  \item @{attribute (HOL) code_unfold} declares (or with option
haftmann@46028
  2027
  ``@{text "del"}'' removes) theorems which during preprocessing
haftmann@46028
  2028
  are applied as rewrite rules to any code equation or evaluation
haftmann@46028
  2029
  input.
haftmann@37422
  2030
haftmann@39608
  2031
  \item @{attribute (HOL) code_post} declares (or with option ``@{text
haftmann@39608
  2032
  "del"}'' removes) theorems which are applied as rewrite rules to any
haftmann@39608
  2033
  result of an evaluation.
haftmann@37422
  2034
haftmann@46028
  2035
  \item @{attribute (HOL) code_abbrev} declares equations which are
haftmann@46028
  2036
  applied as rewrite rules to any result of an evaluation and
haftmann@46028
  2037
  symmetrically during preprocessing to any code equation or evaluation
haftmann@46028
  2038
  input.
haftmann@46028
  2039
haftmann@39608
  2040
  \item @{command (HOL) "print_codeproc"} prints the setup of the code
haftmann@39608
  2041
  generator preprocessor.
haftmann@37422
  2042
haftmann@37422
  2043
  \item @{command (HOL) "code_thms"} prints a list of theorems
haftmann@37422
  2044
  representing the corresponding program containing all given
haftmann@37422
  2045
  constants after preprocessing.
haftmann@37422
  2046
haftmann@37422
  2047
  \item @{command (HOL) "code_deps"} visualizes dependencies of
haftmann@37422
  2048
  theorems representing the corresponding program containing all given
haftmann@37422
  2049
  constants after preprocessing.
haftmann@37422
  2050
haftmann@37422
  2051
  \item @{command (HOL) "code_const"} associates a list of constants
haftmann@37422
  2052
  with target-specific serializations; omitting a serialization
haftmann@37422
  2053
  deletes an existing serialization.
haftmann@37422
  2054
haftmann@37422
  2055
  \item @{command (HOL) "code_type"} associates a list of type
haftmann@37422
  2056
  constructors with target-specific serializations; omitting a
haftmann@37422
  2057
  serialization deletes an existing serialization.
haftmann@37422
  2058
haftmann@37422
  2059
  \item @{command (HOL) "code_class"} associates a list of classes
haftmann@37422
  2060
  with target-specific class names; omitting a serialization deletes
haftmann@37422
  2061
  an existing serialization.  This applies only to \emph{Haskell}.
haftmann@37422
  2062
haftmann@37422
  2063
  \item @{command (HOL) "code_instance"} declares a list of type
haftmann@37422
  2064
  constructor / class instance relations as ``already present'' for a
haftmann@37422
  2065
  given target.  Omitting a ``@{text "-"}'' deletes an existing
haftmann@37422
  2066
  ``already present'' declaration.  This applies only to
haftmann@37422
  2067
  \emph{Haskell}.
haftmann@37422
  2068
haftmann@37422
  2069
  \item @{command (HOL) "code_reserved"} declares a list of names as
haftmann@37422
  2070
  reserved for a given target, preventing it to be shadowed by any
haftmann@37422
  2071
  generated code.
haftmann@37422
  2072
haftmann@37422
  2073
  \item @{command (HOL) "code_monad"} provides an auxiliary mechanism
haftmann@37422
  2074
  to generate monadic code for Haskell.
haftmann@37422
  2075
haftmann@37422
  2076
  \item @{command (HOL) "code_include"} adds arbitrary named content
haftmann@37422
  2077
  (``include'') to generated code.  A ``@{text "-"}'' as last argument
haftmann@37422
  2078
  will remove an already added ``include''.
haftmann@37422
  2079
haftmann@37422
  2080
  \item @{command (HOL) "code_modulename"} declares aliasings from one
haftmann@37422
  2081
  module name onto another.
haftmann@37422
  2082
haftmann@39608
  2083
  \item @{command (HOL) "code_reflect"} without a ``@{text "file"}''
haftmann@39608
  2084
  argument compiles code into the system runtime environment and
haftmann@39608
  2085
  modifies the code generator setup that future invocations of system
haftmann@39608
  2086
  runtime code generation referring to one of the ``@{text
haftmann@39608
  2087
  "datatypes"}'' or ``@{text "functions"}'' entities use these precompiled
haftmann@39608
  2088
  entities.  With a ``@{text "file"}'' argument, the corresponding code
haftmann@39608
  2089
  is generated into that specified file without modifying the code
haftmann@39608
  2090
  generator setup.
haftmann@39608
  2091
bulwahn@45408
  2092
  \item @{command (HOL) "code_pred"} creates code equations for a predicate
bulwahn@45408
  2093
    given a set of introduction rules. Optional mode annotations determine
bulwahn@45408
  2094
    which arguments are supposed to be input or output. If alternative 
bulwahn@45408
  2095
    introduction rules are declared, one must prove a corresponding elimination
bulwahn@45408
  2096
    rule.
bulwahn@45408
  2097
haftmann@37422
  2098
  \end{description}
wenzelm@42627
  2099
*}
haftmann@37422
  2100
wenzelm@42627
  2101
wenzelm@27045
  2102
section {* Definition by specification \label{sec:hol-specification} *}
wenzelm@27045
  2103
wenzelm@27045
  2104
text {*
wenzelm@27045
  2105
  \begin{matharray}{rcl}
wenzelm@28761
  2106
    @{command_def (HOL) "specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@28761
  2107
    @{command_def (HOL) "ax_specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@27045
  2108
  \end{matharray}
wenzelm@27045
  2109
wenzelm@42596
  2110
  @{rail "
wenzelm@42596
  2111
  (@@{command (HOL) specification} | @@{command (HOL) ax_specification})
wenzelm@42596
  2112
    '(' (decl +) ')' \\ (@{syntax thmdecl}? @{syntax prop} +)
wenzelm@27045
  2113
  ;
wenzelm@42596
  2114
  decl: ((@{syntax name} ':')? @{syntax term} '(' @'overloaded' ')'?)
wenzelm@42596
  2115
  "}
wenzelm@27045
  2116
wenzelm@28760
  2117
  \begin{description}
wenzelm@27045
  2118
wenzelm@28760
  2119
  \item @{command (HOL) "specification"}~@{text "decls \<phi>"} sets up a
wenzelm@27045
  2120
  goal stating the existence of terms with the properties specified to
wenzelm@27045
  2121
  hold for the constants given in @{text decls}.  After finishing the
wenzelm@27045
  2122
  proof, the theory will be augmented with definitions for the given
wenzelm@27045
  2123
  constants, as well as with theorems stating the properties for these
wenzelm@27045
  2124
  constants.
wenzelm@27045
  2125
wenzelm@28760
  2126
  \item @{command (HOL) "ax_specification"}~@{text "decls \<phi>"} sets up
wenzelm@28760
  2127
  a goal stating the existence of terms with the properties specified
wenzelm@28760
  2128
  to hold for the constants given in @{text decls}.  After finishing
wenzelm@28760
  2129
  the proof, the theory will be augmented with axioms expressing the
wenzelm@28760
  2130
  properties given in the first place.
wenzelm@27045
  2131
wenzelm@28760
  2132
  \item @{text decl} declares a constant to be defined by the
wenzelm@27045
  2133
  specification given.  The definition for the constant @{text c} is
wenzelm@27045
  2134
  bound to the name @{text c_def} unless a theorem name is given in
wenzelm@27045
  2135
  the declaration.  Overloaded constants should be declared as such.
wenzelm@27045
  2136
wenzelm@28760
  2137
  \end{description}
wenzelm@27045
  2138
wenzelm@27045
  2139
  Whether to use @{command (HOL) "specification"} or @{command (HOL)
wenzelm@27045
  2140
  "ax_specification"} is to some extent a matter of style.  @{command
wenzelm@27045
  2141
  (HOL) "specification"} introduces no new axioms, and so by
wenzelm@27045
  2142
  construction cannot introduce inconsistencies, whereas @{command
wenzelm@27045
  2143
  (HOL) "ax_specification"} does introduce axioms, but only after the
wenzelm@27045
  2144
  user has explicitly proven it to be safe.  A practical issue must be
wenzelm@27045
  2145
  considered, though: After introducing two constants with the same
wenzelm@27045
  2146
  properties using @{command (HOL) "specification"}, one can prove
wenzelm@27045
  2147
  that the two constants are, in fact, equal.  If this might be a
wenzelm@27045
  2148
  problem, one should use @{command (HOL) "ax_specification"}.
wenzelm@27045
  2149
*}
wenzelm@27045
  2150
wenzelm@26840
  2151
end