src/Doc/Isar_Ref/HOL_Specific.thy
author wenzelm
Wed Mar 25 11:39:52 2015 +0100 (2015-03-25)
changeset 59809 87641097d0f3
parent 59785 4e6ab5831cc0
child 59845 fafb4d12c307
permissions -rw-r--r--
tuned signature;
wenzelm@26840
     1
theory HOL_Specific
blanchet@58372
     2
imports Base "~~/src/HOL/Library/Old_Datatype" "~~/src/HOL/Library/Old_Recdef"
blanchet@58372
     3
  "~~/src/Tools/Adhoc_Overloading"
wenzelm@26840
     4
begin
wenzelm@26840
     5
wenzelm@58618
     6
chapter \<open>Higher-Order Logic\<close>
wenzelm@58618
     7
wenzelm@58618
     8
text \<open>Isabelle/HOL is based on Higher-Order Logic, a polymorphic
wenzelm@42914
     9
  version of Church's Simple Theory of Types.  HOL can be best
wenzelm@42914
    10
  understood as a simply-typed version of classical set theory.  The
wenzelm@42914
    11
  logic was first implemented in Gordon's HOL system
wenzelm@58552
    12
  @{cite "mgordon-hol"}.  It extends Church's original logic
wenzelm@58552
    13
  @{cite "church40"} by explicit type variables (naive polymorphism) and
wenzelm@42914
    14
  a sound axiomatization scheme for new types based on subsets of
wenzelm@42914
    15
  existing types.
wenzelm@42914
    16
wenzelm@58552
    17
  Andrews's book @{cite andrews86} is a full description of the
wenzelm@42914
    18
  original Church-style higher-order logic, with proofs of correctness
wenzelm@42914
    19
  and completeness wrt.\ certain set-theoretic interpretations.  The
wenzelm@42914
    20
  particular extensions of Gordon-style HOL are explained semantically
wenzelm@58552
    21
  in two chapters of the 1993 HOL book @{cite pitts93}.
wenzelm@42914
    22
wenzelm@42914
    23
  Experience with HOL over decades has demonstrated that higher-order
wenzelm@42914
    24
  logic is widely applicable in many areas of mathematics and computer
wenzelm@42914
    25
  science.  In a sense, Higher-Order Logic is simpler than First-Order
wenzelm@42914
    26
  Logic, because there are fewer restrictions and special cases.  Note
wenzelm@42914
    27
  that HOL is \emph{weaker} than FOL with axioms for ZF set theory,
wenzelm@42914
    28
  which is traditionally considered the standard foundation of regular
wenzelm@42914
    29
  mathematics, but for most applications this does not matter.  If you
wenzelm@42914
    30
  prefer ML to Lisp, you will probably prefer HOL to ZF.
wenzelm@42914
    31
wenzelm@42914
    32
  \medskip The syntax of HOL follows @{text "\<lambda>"}-calculus and
wenzelm@42914
    33
  functional programming.  Function application is curried.  To apply
wenzelm@42914
    34
  the function @{text f} of type @{text "\<tau>\<^sub>1 \<Rightarrow> \<tau>\<^sub>2 \<Rightarrow> \<tau>\<^sub>3"} to the
wenzelm@42914
    35
  arguments @{text a} and @{text b} in HOL, you simply write @{text "f
wenzelm@42914
    36
  a b"} (as in ML or Haskell).  There is no ``apply'' operator; the
wenzelm@42914
    37
  existing application of the Pure @{text "\<lambda>"}-calculus is re-used.
wenzelm@42914
    38
  Note that in HOL @{text "f (a, b)"} means ``@{text "f"} applied to
wenzelm@42914
    39
  the pair @{text "(a, b)"} (which is notation for @{text "Pair a
wenzelm@42914
    40
  b"}).  The latter typically introduces extra formal efforts that can
wenzelm@42914
    41
  be avoided by currying functions by default.  Explicit tuples are as
wenzelm@42914
    42
  infrequent in HOL formalizations as in good ML or Haskell programs.
wenzelm@42914
    43
wenzelm@42914
    44
  \medskip Isabelle/HOL has a distinct feel, compared to other
wenzelm@42914
    45
  object-logics like Isabelle/ZF.  It identifies object-level types
wenzelm@42914
    46
  with meta-level types, taking advantage of the default
wenzelm@42914
    47
  type-inference mechanism of Isabelle/Pure.  HOL fully identifies
wenzelm@42914
    48
  object-level functions with meta-level functions, with native
wenzelm@42914
    49
  abstraction and application.
wenzelm@42914
    50
wenzelm@42914
    51
  These identifications allow Isabelle to support HOL particularly
wenzelm@42914
    52
  nicely, but they also mean that HOL requires some sophistication
wenzelm@42914
    53
  from the user.  In particular, an understanding of Hindley-Milner
wenzelm@42914
    54
  type-inference with type-classes, which are both used extensively in
wenzelm@42914
    55
  the standard libraries and applications.  Beginners can set
wenzelm@42914
    56
  @{attribute show_types} or even @{attribute show_sorts} to get more
wenzelm@58618
    57
  explicit information about the result of type-inference.\<close>
wenzelm@58618
    58
wenzelm@58618
    59
wenzelm@58618
    60
chapter \<open>Derived specification elements\<close>
wenzelm@58618
    61
wenzelm@58618
    62
section \<open>Inductive and coinductive definitions \label{sec:hol-inductive}\<close>
wenzelm@58618
    63
wenzelm@58618
    64
text \<open>
wenzelm@46280
    65
  \begin{matharray}{rcl}
wenzelm@46280
    66
    @{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@46280
    67
    @{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@46280
    68
    @{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@46280
    69
    @{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@50302
    70
    @{command_def "print_inductives"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
wenzelm@46280
    71
    @{attribute_def (HOL) mono} & : & @{text attribute} \\
wenzelm@46280
    72
  \end{matharray}
wenzelm@46280
    73
wenzelm@46280
    74
  An \emph{inductive definition} specifies the least predicate or set
wenzelm@46280
    75
  @{text R} closed under given rules: applying a rule to elements of
wenzelm@46280
    76
  @{text R} yields a result within @{text R}.  For example, a
wenzelm@46280
    77
  structural operational semantics is an inductive definition of an
wenzelm@46280
    78
  evaluation relation.
wenzelm@42908
    79
wenzelm@42913
    80
  Dually, a \emph{coinductive definition} specifies the greatest
wenzelm@42913
    81
  predicate or set @{text R} that is consistent with given rules:
wenzelm@42913
    82
  every element of @{text R} can be seen as arising by applying a rule
wenzelm@42913
    83
  to elements of @{text R}.  An important example is using
wenzelm@42913
    84
  bisimulation relations to formalise equivalence of processes and
wenzelm@42913
    85
  infinite data structures.
wenzelm@47859
    86
wenzelm@42913
    87
  Both inductive and coinductive definitions are based on the
wenzelm@42913
    88
  Knaster-Tarski fixed-point theorem for complete lattices.  The
wenzelm@42913
    89
  collection of introduction rules given by the user determines a
wenzelm@42913
    90
  functor on subsets of set-theoretic relations.  The required
wenzelm@42913
    91
  monotonicity of the recursion scheme is proven as a prerequisite to
wenzelm@42913
    92
  the fixed-point definition and the resulting consequences.  This
wenzelm@42913
    93
  works by pushing inclusion through logical connectives and any other
wenzelm@42913
    94
  operator that might be wrapped around recursive occurrences of the
wenzelm@42913
    95
  defined relation: there must be a monotonicity theorem of the form
wenzelm@42913
    96
  @{text "A \<le> B \<Longrightarrow> \<M> A \<le> \<M> B"}, for each premise @{text "\<M> R t"} in an
wenzelm@42913
    97
  introduction rule.  The default rule declarations of Isabelle/HOL
wenzelm@42913
    98
  already take care of most common situations.
wenzelm@42907
    99
wenzelm@55112
   100
  @{rail \<open>
wenzelm@42908
   101
    (@@{command (HOL) inductive} | @@{command (HOL) inductive_set} |
wenzelm@59785
   102
      @@{command (HOL) coinductive} | @@{command (HOL) coinductive_set})
wenzelm@59785
   103
      @{syntax "fixes"} @{syntax "for_fixes"} \<newline>
wenzelm@59785
   104
      (@'where' clauses)? (@'monos' @{syntax thmrefs})?
wenzelm@42908
   105
    ;
wenzelm@42908
   106
    clauses: (@{syntax thmdecl}? @{syntax prop} + '|')
wenzelm@42908
   107
    ;
wenzelm@42908
   108
    @@{attribute (HOL) mono} (() | 'add' | 'del')
wenzelm@55112
   109
  \<close>}
wenzelm@42908
   110
wenzelm@42908
   111
  \begin{description}
wenzelm@42908
   112
wenzelm@42908
   113
  \item @{command (HOL) "inductive"} and @{command (HOL)
wenzelm@42913
   114
  "coinductive"} define (co)inductive predicates from the introduction
wenzelm@42913
   115
  rules.
wenzelm@42913
   116
wenzelm@42913
   117
  The propositions given as @{text "clauses"} in the @{keyword
wenzelm@42913
   118
  "where"} part are either rules of the usual @{text "\<And>/\<Longrightarrow>"} format
wenzelm@42913
   119
  (with arbitrary nesting), or equalities using @{text "\<equiv>"}.  The
wenzelm@42913
   120
  latter specifies extra-logical abbreviations in the sense of
wenzelm@42913
   121
  @{command_ref abbreviation}.  Introducing abstract syntax
wenzelm@42913
   122
  simultaneously with the actual introduction rules is occasionally
wenzelm@42913
   123
  useful for complex specifications.
wenzelm@42913
   124
wenzelm@42913
   125
  The optional @{keyword "for"} part contains a list of parameters of
wenzelm@42913
   126
  the (co)inductive predicates that remain fixed throughout the
wenzelm@42913
   127
  definition, in contrast to arguments of the relation that may vary
wenzelm@42913
   128
  in each occurrence within the given @{text "clauses"}.
wenzelm@42913
   129
wenzelm@42913
   130
  The optional @{keyword "monos"} declaration contains additional
wenzelm@42908
   131
  \emph{monotonicity theorems}, which are required for each operator
wenzelm@42913
   132
  applied to a recursive set in the introduction rules.
wenzelm@42908
   133
wenzelm@42908
   134
  \item @{command (HOL) "inductive_set"} and @{command (HOL)
wenzelm@42913
   135
  "coinductive_set"} are wrappers for to the previous commands for
wenzelm@42913
   136
  native HOL predicates.  This allows to define (co)inductive sets,
wenzelm@42913
   137
  where multiple arguments are simulated via tuples.
wenzelm@42908
   138
wenzelm@50302
   139
  \item @{command "print_inductives"} prints (co)inductive definitions and
wenzelm@50302
   140
  monotonicity rules.
wenzelm@50302
   141
wenzelm@42913
   142
  \item @{attribute (HOL) mono} declares monotonicity rules in the
wenzelm@42913
   143
  context.  These rule are involved in the automated monotonicity
wenzelm@42913
   144
  proof of the above inductive and coinductive definitions.
wenzelm@42908
   145
wenzelm@42908
   146
  \end{description}
wenzelm@58618
   147
\<close>
wenzelm@58618
   148
wenzelm@58618
   149
wenzelm@58618
   150
subsection \<open>Derived rules\<close>
wenzelm@58618
   151
wenzelm@58618
   152
text \<open>A (co)inductive definition of @{text R} provides the following
wenzelm@42913
   153
  main theorems:
wenzelm@42908
   154
wenzelm@42908
   155
  \begin{description}
wenzelm@42908
   156
wenzelm@42908
   157
  \item @{text R.intros} is the list of introduction rules as proven
wenzelm@42908
   158
  theorems, for the recursive predicates (or sets).  The rules are
wenzelm@42908
   159
  also available individually, using the names given them in the
wenzelm@42908
   160
  theory file;
wenzelm@42908
   161
wenzelm@42908
   162
  \item @{text R.cases} is the case analysis (or elimination) rule;
wenzelm@42908
   163
wenzelm@42908
   164
  \item @{text R.induct} or @{text R.coinduct} is the (co)induction
bulwahn@44273
   165
  rule;
bulwahn@44273
   166
bulwahn@44273
   167
  \item @{text R.simps} is the equation unrolling the fixpoint of the
bulwahn@44273
   168
  predicate one step.
wenzelm@47859
   169
wenzelm@42908
   170
  \end{description}
wenzelm@42908
   171
wenzelm@42908
   172
  When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
wenzelm@42908
   173
  defined simultaneously, the list of introduction rules is called
wenzelm@42908
   174
  @{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
wenzelm@42908
   175
  called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
wenzelm@42908
   176
  of mutual induction rules is called @{text
wenzelm@42908
   177
  "R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
wenzelm@58618
   178
\<close>
wenzelm@58618
   179
wenzelm@58618
   180
wenzelm@58618
   181
subsection \<open>Monotonicity theorems\<close>
wenzelm@58618
   182
wenzelm@58618
   183
text \<open>The context maintains a default set of theorems that are used
wenzelm@42913
   184
  in monotonicity proofs.  New rules can be declared via the
wenzelm@42913
   185
  @{attribute (HOL) mono} attribute.  See the main Isabelle/HOL
wenzelm@42913
   186
  sources for some examples.  The general format of such monotonicity
wenzelm@42913
   187
  theorems is as follows:
wenzelm@42908
   188
wenzelm@42908
   189
  \begin{itemize}
wenzelm@42908
   190
wenzelm@42913
   191
  \item Theorems of the form @{text "A \<le> B \<Longrightarrow> \<M> A \<le> \<M> B"}, for proving
wenzelm@42908
   192
  monotonicity of inductive definitions whose introduction rules have
wenzelm@42913
   193
  premises involving terms such as @{text "\<M> R t"}.
wenzelm@42908
   194
wenzelm@42908
   195
  \item Monotonicity theorems for logical operators, which are of the
wenzelm@42908
   196
  general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}.  For example, in
wenzelm@42908
   197
  the case of the operator @{text "\<or>"}, the corresponding theorem is
wenzelm@42908
   198
  \[
wenzelm@42908
   199
  \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
   200
  \]
wenzelm@42908
   201
wenzelm@42908
   202
  \item De Morgan style equations for reasoning about the ``polarity''
wenzelm@42908
   203
  of expressions, e.g.
wenzelm@42908
   204
  \[
wenzelm@42908
   205
  @{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
wenzelm@42908
   206
  @{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
wenzelm@42908
   207
  \]
wenzelm@42908
   208
wenzelm@42908
   209
  \item Equations for reducing complex operators to more primitive
wenzelm@42908
   210
  ones whose monotonicity can easily be proved, e.g.
wenzelm@42908
   211
  \[
wenzelm@42908
   212
  @{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
wenzelm@42908
   213
  @{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
wenzelm@42908
   214
  \]
wenzelm@42908
   215
wenzelm@42908
   216
  \end{itemize}
wenzelm@58618
   217
\<close>
wenzelm@58618
   218
wenzelm@58618
   219
subsubsection \<open>Examples\<close>
wenzelm@58618
   220
wenzelm@58618
   221
text \<open>The finite powerset operator can be defined inductively like this:\<close>
wenzelm@42913
   222
wenzelm@42913
   223
inductive_set Fin :: "'a set \<Rightarrow> 'a set set" for A :: "'a set"
wenzelm@42913
   224
where
wenzelm@42913
   225
  empty: "{} \<in> Fin A"
wenzelm@42913
   226
| insert: "a \<in> A \<Longrightarrow> B \<in> Fin A \<Longrightarrow> insert a B \<in> Fin A"
wenzelm@42913
   227
wenzelm@58618
   228
text \<open>The accessible part of a relation is defined as follows:\<close>
wenzelm@42913
   229
wenzelm@42913
   230
inductive acc :: "('a \<Rightarrow> 'a \<Rightarrow> bool) \<Rightarrow> 'a \<Rightarrow> bool"
wenzelm@42913
   231
  for r :: "'a \<Rightarrow> 'a \<Rightarrow> bool"  (infix "\<prec>" 50)
wenzelm@42913
   232
where acc: "(\<And>y. y \<prec> x \<Longrightarrow> acc r y) \<Longrightarrow> acc r x"
wenzelm@42913
   233
wenzelm@58618
   234
text \<open>Common logical connectives can be easily characterized as
wenzelm@42913
   235
non-recursive inductive definitions with parameters, but without
wenzelm@58618
   236
arguments.\<close>
wenzelm@42913
   237
wenzelm@42913
   238
inductive AND for A B :: bool
wenzelm@42913
   239
where "A \<Longrightarrow> B \<Longrightarrow> AND A B"
wenzelm@42913
   240
wenzelm@42913
   241
inductive OR for A B :: bool
wenzelm@42913
   242
where "A \<Longrightarrow> OR A B"
wenzelm@42913
   243
  | "B \<Longrightarrow> OR A B"
wenzelm@42913
   244
wenzelm@42913
   245
inductive EXISTS for B :: "'a \<Rightarrow> bool"
wenzelm@42913
   246
where "B a \<Longrightarrow> EXISTS B"
wenzelm@42913
   247
wenzelm@58618
   248
text \<open>Here the @{text "cases"} or @{text "induct"} rules produced by
wenzelm@42913
   249
  the @{command inductive} package coincide with the expected
wenzelm@42913
   250
  elimination rules for Natural Deduction.  Already in the original
wenzelm@58552
   251
  article by Gerhard Gentzen @{cite "Gentzen:1935"} there is a hint that
wenzelm@42913
   252
  each connective can be characterized by its introductions, and the
wenzelm@58618
   253
  elimination can be constructed systematically.\<close>
wenzelm@58618
   254
wenzelm@58618
   255
wenzelm@58618
   256
section \<open>Recursive functions \label{sec:recursion}\<close>
wenzelm@58618
   257
wenzelm@58618
   258
text \<open>
wenzelm@42908
   259
  \begin{matharray}{rcl}
wenzelm@42908
   260
    @{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   261
    @{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   262
    @{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   263
    @{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
krauss@54017
   264
    @{command_def (HOL) "fun_cases"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   265
  \end{matharray}
wenzelm@42908
   266
wenzelm@55112
   267
  @{rail \<open>
wenzelm@59783
   268
    @@{command (HOL) primrec} @{syntax "fixes"} @'where' equations
wenzelm@42908
   269
    ;
wenzelm@59783
   270
    (@@{command (HOL) fun} | @@{command (HOL) function}) functionopts?
wenzelm@55112
   271
      @{syntax "fixes"} \<newline> @'where' equations
wenzelm@26849
   272
    ;
wenzelm@26849
   273
wenzelm@42908
   274
    equations: (@{syntax thmdecl}? @{syntax prop} + '|')
wenzelm@26849
   275
    ;
wenzelm@42908
   276
    functionopts: '(' (('sequential' | 'domintros') + ',') ')'
wenzelm@26849
   277
    ;
wenzelm@42908
   278
    @@{command (HOL) termination} @{syntax term}?
krauss@54017
   279
    ;
krauss@54017
   280
    @@{command (HOL) fun_cases} (@{syntax thmdecl}? @{syntax prop} + @'and')
wenzelm@55112
   281
  \<close>}
wenzelm@26849
   282
wenzelm@28760
   283
  \begin{description}
wenzelm@42123
   284
wenzelm@42908
   285
  \item @{command (HOL) "primrec"} defines primitive recursive
blanchet@58310
   286
  functions over datatypes (see also @{command_ref (HOL) datatype}).
blanchet@58305
   287
  The given @{text equations} specify reduction rules that are produced
blanchet@58305
   288
  by instantiating the generic combinator for primitive recursion that
blanchet@58305
   289
  is available for each datatype.
wenzelm@42912
   290
wenzelm@42912
   291
  Each equation needs to be of the form:
wenzelm@42912
   292
wenzelm@42912
   293
  @{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
   294
wenzelm@42912
   295
  such that @{text C} is a datatype constructor, @{text rhs} contains
wenzelm@42912
   296
  only the free variables on the left-hand side (or from the context),
wenzelm@42912
   297
  and all recursive occurrences of @{text "f"} in @{text "rhs"} are of
wenzelm@42912
   298
  the form @{text "f \<dots> y\<^sub>i \<dots>"} for some @{text i}.  At most one
wenzelm@42912
   299
  reduction rule for each constructor can be given.  The order does
wenzelm@42912
   300
  not matter.  For missing constructors, the function is defined to
wenzelm@42912
   301
  return a default value, but this equation is made difficult to
wenzelm@42912
   302
  access for users.
wenzelm@42912
   303
wenzelm@42912
   304
  The reduction rules are declared as @{attribute simp} by default,
wenzelm@42912
   305
  which enables standard proof methods like @{method simp} and
wenzelm@42912
   306
  @{method auto} to normalize expressions of @{text "f"} applied to
wenzelm@42912
   307
  datatype constructions, by simulating symbolic computation via
wenzelm@42912
   308
  rewriting.
wenzelm@35744
   309
wenzelm@42908
   310
  \item @{command (HOL) "function"} defines functions by general
wenzelm@42908
   311
  wellfounded recursion. A detailed description with examples can be
wenzelm@58552
   312
  found in @{cite "isabelle-function"}. The function is specified by a
wenzelm@42908
   313
  set of (possibly conditional) recursive equations with arbitrary
wenzelm@42908
   314
  pattern matching. The command generates proof obligations for the
wenzelm@42908
   315
  completeness and the compatibility of patterns.
wenzelm@42907
   316
wenzelm@42908
   317
  The defined function is considered partial, and the resulting
wenzelm@42908
   318
  simplification rules (named @{text "f.psimps"}) and induction rule
wenzelm@42908
   319
  (named @{text "f.pinduct"}) are guarded by a generated domain
wenzelm@42908
   320
  predicate @{text "f_dom"}. The @{command (HOL) "termination"}
wenzelm@42908
   321
  command can then be used to establish that the function is total.
wenzelm@42123
   322
wenzelm@42908
   323
  \item @{command (HOL) "fun"} is a shorthand notation for ``@{command
wenzelm@59785
   324
  (HOL) "function"}~@{text "(sequential)"}'', followed by automated
wenzelm@42908
   325
  proof attempts regarding pattern matching and termination.  See
wenzelm@58552
   326
  @{cite "isabelle-function"} for further details.
wenzelm@42123
   327
wenzelm@42908
   328
  \item @{command (HOL) "termination"}~@{text f} commences a
wenzelm@42908
   329
  termination proof for the previously defined function @{text f}.  If
wenzelm@42908
   330
  this is omitted, the command refers to the most recent function
wenzelm@42908
   331
  definition.  After the proof is closed, the recursive equations and
wenzelm@42908
   332
  the induction principle is established.
wenzelm@26849
   333
krauss@54017
   334
  \item @{command (HOL) "fun_cases"} generates specialized elimination
krauss@54017
   335
  rules for function equations. It expects one or more function equations
krauss@54017
   336
  and produces rules that eliminate the given equalities, following the cases
krauss@54017
   337
  given in the function definition.
wenzelm@28760
   338
  \end{description}
wenzelm@42907
   339
wenzelm@42908
   340
  Recursive definitions introduced by the @{command (HOL) "function"}
wenzelm@42912
   341
  command accommodate reasoning by induction (cf.\ @{method induct}):
wenzelm@42912
   342
  rule @{text "f.induct"} refers to a specific induction rule, with
wenzelm@42912
   343
  parameters named according to the user-specified equations. Cases
wenzelm@42912
   344
  are numbered starting from 1.  For @{command (HOL) "primrec"}, the
wenzelm@42912
   345
  induction principle coincides with structural recursion on the
wenzelm@42912
   346
  datatype where the recursion is carried out.
wenzelm@42908
   347
wenzelm@42908
   348
  The equations provided by these packages may be referred later as
wenzelm@42908
   349
  theorem list @{text "f.simps"}, where @{text f} is the (collective)
wenzelm@42908
   350
  name of the functions defined.  Individual equations may be named
wenzelm@42908
   351
  explicitly as well.
wenzelm@42908
   352
wenzelm@42908
   353
  The @{command (HOL) "function"} command accepts the following
wenzelm@42908
   354
  options.
wenzelm@42908
   355
wenzelm@42908
   356
  \begin{description}
wenzelm@42908
   357
wenzelm@42908
   358
  \item @{text sequential} enables a preprocessor which disambiguates
wenzelm@42908
   359
  overlapping patterns by making them mutually disjoint.  Earlier
wenzelm@42908
   360
  equations take precedence over later ones.  This allows to give the
wenzelm@42908
   361
  specification in a format very similar to functional programming.
wenzelm@42908
   362
  Note that the resulting simplification and induction rules
wenzelm@42908
   363
  correspond to the transformed specification, not the one given
wenzelm@42908
   364
  originally. This usually means that each equation given by the user
wenzelm@42908
   365
  may result in several theorems.  Also note that this automatic
wenzelm@42908
   366
  transformation only works for ML-style datatype patterns.
wenzelm@42908
   367
wenzelm@42908
   368
  \item @{text domintros} enables the automated generation of
wenzelm@42908
   369
  introduction rules for the domain predicate. While mostly not
wenzelm@42908
   370
  needed, they can be helpful in some proofs about partial functions.
wenzelm@42908
   371
wenzelm@42908
   372
  \end{description}
wenzelm@58618
   373
\<close>
wenzelm@58618
   374
wenzelm@58618
   375
subsubsection \<open>Example: evaluation of expressions\<close>
wenzelm@58618
   376
wenzelm@58618
   377
text \<open>Subsequently, we define mutual datatypes for arithmetic and
wenzelm@42912
   378
  boolean expressions, and use @{command primrec} for evaluation
wenzelm@58618
   379
  functions that follow the same recursive structure.\<close>
wenzelm@42912
   380
blanchet@58310
   381
datatype 'a aexp =
wenzelm@42912
   382
    IF "'a bexp"  "'a aexp"  "'a aexp"
wenzelm@42912
   383
  | Sum "'a aexp"  "'a aexp"
wenzelm@42912
   384
  | Diff "'a aexp"  "'a aexp"
wenzelm@42912
   385
  | Var 'a
wenzelm@42912
   386
  | Num nat
wenzelm@42912
   387
and 'a bexp =
wenzelm@42912
   388
    Less "'a aexp"  "'a aexp"
wenzelm@42912
   389
  | And "'a bexp"  "'a bexp"
wenzelm@42912
   390
  | Neg "'a bexp"
wenzelm@42912
   391
wenzelm@42912
   392
wenzelm@58618
   393
text \<open>\medskip Evaluation of arithmetic and boolean expressions\<close>
wenzelm@42912
   394
wenzelm@42912
   395
primrec evala :: "('a \<Rightarrow> nat) \<Rightarrow> 'a aexp \<Rightarrow> nat"
wenzelm@42912
   396
  and evalb :: "('a \<Rightarrow> nat) \<Rightarrow> 'a bexp \<Rightarrow> bool"
wenzelm@42912
   397
where
wenzelm@42912
   398
  "evala env (IF b a1 a2) = (if evalb env b then evala env a1 else evala env a2)"
wenzelm@42912
   399
| "evala env (Sum a1 a2) = evala env a1 + evala env a2"
wenzelm@42912
   400
| "evala env (Diff a1 a2) = evala env a1 - evala env a2"
wenzelm@42912
   401
| "evala env (Var v) = env v"
wenzelm@42912
   402
| "evala env (Num n) = n"
wenzelm@42912
   403
| "evalb env (Less a1 a2) = (evala env a1 < evala env a2)"
wenzelm@42912
   404
| "evalb env (And b1 b2) = (evalb env b1 \<and> evalb env b2)"
wenzelm@42912
   405
| "evalb env (Neg b) = (\<not> evalb env b)"
wenzelm@42912
   406
wenzelm@58618
   407
text \<open>Since the value of an expression depends on the value of its
wenzelm@42912
   408
  variables, the functions @{const evala} and @{const evalb} take an
wenzelm@42912
   409
  additional parameter, an \emph{environment} that maps variables to
wenzelm@42912
   410
  their values.
wenzelm@42912
   411
wenzelm@42912
   412
  \medskip Substitution on expressions can be defined similarly.  The
wenzelm@42912
   413
  mapping @{text f} of type @{typ "'a \<Rightarrow> 'a aexp"} given as a
wenzelm@42912
   414
  parameter is lifted canonically on the types @{typ "'a aexp"} and
wenzelm@42912
   415
  @{typ "'a bexp"}, respectively.
wenzelm@58618
   416
\<close>
wenzelm@42912
   417
wenzelm@42912
   418
primrec substa :: "('a \<Rightarrow> 'b aexp) \<Rightarrow> 'a aexp \<Rightarrow> 'b aexp"
wenzelm@42912
   419
  and substb :: "('a \<Rightarrow> 'b aexp) \<Rightarrow> 'a bexp \<Rightarrow> 'b bexp"
wenzelm@42912
   420
where
wenzelm@42912
   421
  "substa f (IF b a1 a2) = IF (substb f b) (substa f a1) (substa f a2)"
wenzelm@42912
   422
| "substa f (Sum a1 a2) = Sum (substa f a1) (substa f a2)"
wenzelm@42912
   423
| "substa f (Diff a1 a2) = Diff (substa f a1) (substa f a2)"
wenzelm@42912
   424
| "substa f (Var v) = f v"
wenzelm@42912
   425
| "substa f (Num n) = Num n"
wenzelm@42912
   426
| "substb f (Less a1 a2) = Less (substa f a1) (substa f a2)"
wenzelm@42912
   427
| "substb f (And b1 b2) = And (substb f b1) (substb f b2)"
wenzelm@42912
   428
| "substb f (Neg b) = Neg (substb f b)"
wenzelm@42912
   429
wenzelm@58618
   430
text \<open>In textbooks about semantics one often finds substitution
wenzelm@42912
   431
  theorems, which express the relationship between substitution and
wenzelm@42912
   432
  evaluation.  For @{typ "'a aexp"} and @{typ "'a bexp"}, we can prove
wenzelm@42912
   433
  such a theorem by mutual induction, followed by simplification.
wenzelm@58618
   434
\<close>
wenzelm@42912
   435
wenzelm@42912
   436
lemma subst_one:
wenzelm@42912
   437
  "evala env (substa (Var (v := a')) a) = evala (env (v := evala env a')) a"
wenzelm@42912
   438
  "evalb env (substb (Var (v := a')) b) = evalb (env (v := evala env a')) b"
wenzelm@42912
   439
  by (induct a and b) simp_all
wenzelm@42912
   440
wenzelm@42912
   441
lemma subst_all:
wenzelm@42912
   442
  "evala env (substa s a) = evala (\<lambda>x. evala env (s x)) a"
wenzelm@42912
   443
  "evalb env (substb s b) = evalb (\<lambda>x. evala env (s x)) b"
wenzelm@42912
   444
  by (induct a and b) simp_all
wenzelm@42912
   445
wenzelm@42912
   446
wenzelm@58618
   447
subsubsection \<open>Example: a substitution function for terms\<close>
wenzelm@58618
   448
wenzelm@58618
   449
text \<open>Functions on datatypes with nested recursion are also defined
wenzelm@58618
   450
  by mutual primitive recursion.\<close>
wenzelm@42912
   451
blanchet@58310
   452
datatype ('a, 'b) "term" = Var 'a | App 'b "('a, 'b) term list"
wenzelm@42912
   453
wenzelm@58618
   454
text \<open>A substitution function on type @{typ "('a, 'b) term"} can be
wenzelm@42912
   455
  defined as follows, by working simultaneously on @{typ "('a, 'b)
wenzelm@58618
   456
  term list"}:\<close>
wenzelm@42912
   457
wenzelm@42912
   458
primrec subst_term :: "('a \<Rightarrow> ('a, 'b) term) \<Rightarrow> ('a, 'b) term \<Rightarrow> ('a, 'b) term" and
wenzelm@42912
   459
  subst_term_list :: "('a \<Rightarrow> ('a, 'b) term) \<Rightarrow> ('a, 'b) term list \<Rightarrow> ('a, 'b) term list"
wenzelm@42912
   460
where
wenzelm@42912
   461
  "subst_term f (Var a) = f a"
wenzelm@42912
   462
| "subst_term f (App b ts) = App b (subst_term_list f ts)"
wenzelm@42912
   463
| "subst_term_list f [] = []"
wenzelm@42912
   464
| "subst_term_list f (t # ts) = subst_term f t # subst_term_list f ts"
wenzelm@42912
   465
wenzelm@58618
   466
text \<open>The recursion scheme follows the structure of the unfolded
wenzelm@42912
   467
  definition of type @{typ "('a, 'b) term"}.  To prove properties of this
wenzelm@42912
   468
  substitution function, mutual induction is needed:
wenzelm@58618
   469
\<close>
wenzelm@42912
   470
wenzelm@42912
   471
lemma "subst_term (subst_term f1 \<circ> f2) t = subst_term f1 (subst_term f2 t)" and
wenzelm@42912
   472
  "subst_term_list (subst_term f1 \<circ> f2) ts = subst_term_list f1 (subst_term_list f2 ts)"
blanchet@58305
   473
  by (induct t and ts rule: subst_term.induct subst_term_list.induct) simp_all
wenzelm@42912
   474
wenzelm@42912
   475
wenzelm@58618
   476
subsubsection \<open>Example: a map function for infinitely branching trees\<close>
wenzelm@58618
   477
wenzelm@58618
   478
text \<open>Defining functions on infinitely branching datatypes by
wenzelm@42912
   479
  primitive recursion is just as easy.
wenzelm@58618
   480
\<close>
wenzelm@42912
   481
blanchet@58310
   482
datatype 'a tree = Atom 'a | Branch "nat \<Rightarrow> 'a tree"
wenzelm@42912
   483
wenzelm@42912
   484
primrec map_tree :: "('a \<Rightarrow> 'b) \<Rightarrow> 'a tree \<Rightarrow> 'b tree"
wenzelm@42912
   485
where
wenzelm@42912
   486
  "map_tree f (Atom a) = Atom (f a)"
wenzelm@42912
   487
| "map_tree f (Branch ts) = Branch (\<lambda>x. map_tree f (ts x))"
wenzelm@42912
   488
wenzelm@58618
   489
text \<open>Note that all occurrences of functions such as @{text ts}
wenzelm@42912
   490
  above must be applied to an argument.  In particular, @{term
wenzelm@58618
   491
  "map_tree f \<circ> ts"} is not allowed here.\<close>
wenzelm@58618
   492
wenzelm@58618
   493
text \<open>Here is a simple composition lemma for @{term map_tree}:\<close>
wenzelm@42912
   494
wenzelm@42912
   495
lemma "map_tree g (map_tree f t) = map_tree (g \<circ> f) t"
wenzelm@42912
   496
  by (induct t) simp_all
wenzelm@42912
   497
wenzelm@42907
   498
wenzelm@58618
   499
subsection \<open>Proof methods related to recursive definitions\<close>
wenzelm@58618
   500
wenzelm@58618
   501
text \<open>
wenzelm@26849
   502
  \begin{matharray}{rcl}
wenzelm@42908
   503
    @{method_def (HOL) pat_completeness} & : & @{text method} \\
wenzelm@42908
   504
    @{method_def (HOL) relation} & : & @{text method} \\
wenzelm@42908
   505
    @{method_def (HOL) lexicographic_order} & : & @{text method} \\
wenzelm@42908
   506
    @{method_def (HOL) size_change} & : & @{text method} \\
bulwahn@45944
   507
    @{method_def (HOL) induction_schema} & : & @{text method} \\
wenzelm@26849
   508
  \end{matharray}
wenzelm@26849
   509
wenzelm@55112
   510
  @{rail \<open>
wenzelm@42908
   511
    @@{method (HOL) relation} @{syntax term}
wenzelm@42908
   512
    ;
wenzelm@42908
   513
    @@{method (HOL) lexicographic_order} (@{syntax clasimpmod} * )
wenzelm@42908
   514
    ;
wenzelm@42908
   515
    @@{method (HOL) size_change} ( orders (@{syntax clasimpmod} * ) )
wenzelm@42908
   516
    ;
bulwahn@45944
   517
    @@{method (HOL) induction_schema}
bulwahn@45944
   518
    ;
wenzelm@42908
   519
    orders: ( 'max' | 'min' | 'ms' ) *
wenzelm@55112
   520
  \<close>}
wenzelm@42908
   521
wenzelm@42908
   522
  \begin{description}
wenzelm@42908
   523
wenzelm@42908
   524
  \item @{method (HOL) pat_completeness} is a specialized method to
wenzelm@42908
   525
  solve goals regarding the completeness of pattern matching, as
wenzelm@42908
   526
  required by the @{command (HOL) "function"} package (cf.\
wenzelm@58552
   527
  @{cite "isabelle-function"}).
wenzelm@42908
   528
wenzelm@42908
   529
  \item @{method (HOL) relation}~@{text R} introduces a termination
wenzelm@42908
   530
  proof using the relation @{text R}.  The resulting proof state will
wenzelm@42908
   531
  contain goals expressing that @{text R} is wellfounded, and that the
wenzelm@42908
   532
  arguments of recursive calls decrease with respect to @{text R}.
wenzelm@42908
   533
  Usually, this method is used as the initial proof step of manual
wenzelm@42908
   534
  termination proofs.
wenzelm@42908
   535
wenzelm@42908
   536
  \item @{method (HOL) "lexicographic_order"} attempts a fully
wenzelm@42908
   537
  automated termination proof by searching for a lexicographic
wenzelm@42908
   538
  combination of size measures on the arguments of the function. The
wenzelm@42908
   539
  method accepts the same arguments as the @{method auto} method,
wenzelm@42930
   540
  which it uses internally to prove local descents.  The @{syntax
wenzelm@42930
   541
  clasimpmod} modifiers are accepted (as for @{method auto}).
wenzelm@42908
   542
wenzelm@42908
   543
  In case of failure, extensive information is printed, which can help
wenzelm@58552
   544
  to analyse the situation (cf.\ @{cite "isabelle-function"}).
wenzelm@42908
   545
wenzelm@42908
   546
  \item @{method (HOL) "size_change"} also works on termination goals,
wenzelm@42908
   547
  using a variation of the size-change principle, together with a
wenzelm@58552
   548
  graph decomposition technique (see @{cite krauss_phd} for details).
wenzelm@42908
   549
  Three kinds of orders are used internally: @{text max}, @{text min},
wenzelm@42908
   550
  and @{text ms} (multiset), which is only available when the theory
wenzelm@42908
   551
  @{text Multiset} is loaded. When no order kinds are given, they are
wenzelm@42908
   552
  tried in order. The search for a termination proof uses SAT solving
wenzelm@42908
   553
  internally.
wenzelm@42908
   554
wenzelm@42930
   555
  For local descent proofs, the @{syntax clasimpmod} modifiers are
wenzelm@42930
   556
  accepted (as for @{method auto}).
wenzelm@42908
   557
bulwahn@45944
   558
  \item @{method (HOL) induction_schema} derives user-specified
wenzelm@46283
   559
  induction rules from well-founded induction and completeness of
wenzelm@46283
   560
  patterns. This factors out some operations that are done internally
wenzelm@46283
   561
  by the function package and makes them available separately. See
wenzelm@46283
   562
  @{file "~~/src/HOL/ex/Induction_Schema.thy"} for examples.
bulwahn@45944
   563
wenzelm@42908
   564
  \end{description}
wenzelm@58618
   565
\<close>
wenzelm@58618
   566
wenzelm@58618
   567
wenzelm@58618
   568
subsection \<open>Functions with explicit partiality\<close>
wenzelm@58618
   569
wenzelm@58618
   570
text \<open>
wenzelm@42908
   571
  \begin{matharray}{rcl}
wenzelm@42908
   572
    @{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@42908
   573
    @{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
wenzelm@42908
   574
  \end{matharray}
wenzelm@42908
   575
wenzelm@55112
   576
  @{rail \<open>
wenzelm@59783
   577
    @@{command (HOL) partial_function} '(' @{syntax nameref} ')' @{syntax "fixes"} \<newline>
wenzelm@42908
   578
      @'where' @{syntax thmdecl}? @{syntax prop}
wenzelm@55112
   579
  \<close>}
wenzelm@26849
   580
wenzelm@28760
   581
  \begin{description}
wenzelm@42123
   582
wenzelm@42908
   583
  \item @{command (HOL) "partial_function"}~@{text "(mode)"} defines
wenzelm@42908
   584
  recursive functions based on fixpoints in complete partial
wenzelm@42908
   585
  orders. No termination proof is required from the user or
wenzelm@42908
   586
  constructed internally. Instead, the possibility of non-termination
wenzelm@42908
   587
  is modelled explicitly in the result type, which contains an
wenzelm@42908
   588
  explicit bottom element.
wenzelm@42908
   589
wenzelm@42908
   590
  Pattern matching and mutual recursion are currently not supported.
wenzelm@42908
   591
  Thus, the specification consists of a single function described by a
wenzelm@42908
   592
  single recursive equation.
wenzelm@42908
   593
wenzelm@42908
   594
  There are no fixed syntactic restrictions on the body of the
wenzelm@42908
   595
  function, but the induced functional must be provably monotonic
Christian@52895
   596
  wrt.\ the underlying order.  The monotonicity proof is performed
wenzelm@42908
   597
  internally, and the definition is rejected when it fails. The proof
wenzelm@42908
   598
  can be influenced by declaring hints using the
wenzelm@42908
   599
  @{attribute (HOL) partial_function_mono} attribute.
wenzelm@42908
   600
wenzelm@42908
   601
  The mandatory @{text mode} argument specifies the mode of operation
wenzelm@42908
   602
  of the command, which directly corresponds to a complete partial
wenzelm@42908
   603
  order on the result type. By default, the following modes are
wenzelm@42908
   604
  defined:
wenzelm@26849
   605
wenzelm@42908
   606
  \begin{description}
wenzelm@46283
   607
wenzelm@42908
   608
  \item @{text option} defines functions that map into the @{type
wenzelm@42908
   609
  option} type. Here, the value @{term None} is used to model a
wenzelm@42908
   610
  non-terminating computation. Monotonicity requires that if @{term
wenzelm@46283
   611
  None} is returned by a recursive call, then the overall result must
wenzelm@46283
   612
  also be @{term None}. This is best achieved through the use of the
wenzelm@46283
   613
  monadic operator @{const "Option.bind"}.
wenzelm@42908
   614
wenzelm@42908
   615
  \item @{text tailrec} defines functions with an arbitrary result
wenzelm@42908
   616
  type and uses the slightly degenerated partial order where @{term
wenzelm@42908
   617
  "undefined"} is the bottom element.  Now, monotonicity requires that
wenzelm@42908
   618
  if @{term undefined} is returned by a recursive call, then the
wenzelm@42908
   619
  overall result must also be @{term undefined}. In practice, this is
wenzelm@42908
   620
  only satisfied when each recursive call is a tail call, whose result
wenzelm@42908
   621
  is directly returned. Thus, this mode of operation allows the
wenzelm@42908
   622
  definition of arbitrary tail-recursive functions.
wenzelm@46283
   623
wenzelm@42908
   624
  \end{description}
wenzelm@42908
   625
wenzelm@42908
   626
  Experienced users may define new modes by instantiating the locale
wenzelm@42908
   627
  @{const "partial_function_definitions"} appropriately.
wenzelm@42908
   628
wenzelm@42908
   629
  \item @{attribute (HOL) partial_function_mono} declares rules for
Christian@52895
   630
  use in the internal monotonicity proofs of partial function
wenzelm@42908
   631
  definitions.
wenzelm@26849
   632
wenzelm@28760
   633
  \end{description}
wenzelm@42908
   634
wenzelm@58618
   635
\<close>
wenzelm@58618
   636
wenzelm@58618
   637
wenzelm@58618
   638
subsection \<open>Old-style recursive function definitions (TFL)\<close>
wenzelm@58618
   639
wenzelm@58618
   640
text \<open>
wenzelm@42908
   641
  \begin{matharray}{rcl}
wenzelm@42908
   642
    @{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
wenzelm@42908
   643
    @{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   644
  \end{matharray}
wenzelm@42908
   645
wenzelm@46280
   646
  The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
wenzelm@46280
   647
  "recdef_tc"} for defining recursive are mostly obsolete; @{command
wenzelm@46280
   648
  (HOL) "function"} or @{command (HOL) "fun"} should be used instead.
wenzelm@46280
   649
wenzelm@55112
   650
  @{rail \<open>
wenzelm@55029
   651
    @@{command (HOL) recdef} ('(' @'permissive' ')')? \<newline>
wenzelm@42908
   652
      @{syntax name} @{syntax term} (@{syntax prop} +) hints?
wenzelm@42908
   653
    ;
wenzelm@42908
   654
    recdeftc @{syntax thmdecl}? tc
wenzelm@42908
   655
    ;
wenzelm@42908
   656
    hints: '(' @'hints' ( recdefmod * ) ')'
wenzelm@42908
   657
    ;
wenzelm@42908
   658
    recdefmod: (('recdef_simp' | 'recdef_cong' | 'recdef_wf')
wenzelm@42908
   659
      (() | 'add' | 'del') ':' @{syntax thmrefs}) | @{syntax clasimpmod}
wenzelm@42908
   660
    ;
wenzelm@42908
   661
    tc: @{syntax nameref} ('(' @{syntax nat} ')')?
wenzelm@55112
   662
  \<close>}
wenzelm@42908
   663
wenzelm@42908
   664
  \begin{description}
wenzelm@42908
   665
wenzelm@42908
   666
  \item @{command (HOL) "recdef"} defines general well-founded
wenzelm@42908
   667
  recursive functions (using the TFL package), see also
wenzelm@58552
   668
  @{cite "isabelle-HOL"}.  The ``@{text "(permissive)"}'' option tells
wenzelm@42908
   669
  TFL to recover from failed proof attempts, returning unfinished
wenzelm@42908
   670
  results.  The @{text recdef_simp}, @{text recdef_cong}, and @{text
wenzelm@42908
   671
  recdef_wf} hints refer to auxiliary rules to be used in the internal
wenzelm@42908
   672
  automated proof process of TFL.  Additional @{syntax clasimpmod}
wenzelm@42930
   673
  declarations may be given to tune the context of the Simplifier
wenzelm@42930
   674
  (cf.\ \secref{sec:simplifier}) and Classical reasoner (cf.\
wenzelm@42930
   675
  \secref{sec:classical}).
wenzelm@42908
   676
wenzelm@42908
   677
  \item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
wenzelm@42908
   678
  proof for leftover termination condition number @{text i} (default
wenzelm@42908
   679
  1) as generated by a @{command (HOL) "recdef"} definition of
wenzelm@42908
   680
  constant @{text c}.
wenzelm@42908
   681
wenzelm@42908
   682
  Note that in most cases, @{command (HOL) "recdef"} is able to finish
wenzelm@42908
   683
  its internal proofs without manual intervention.
wenzelm@42908
   684
wenzelm@42908
   685
  \end{description}
wenzelm@42908
   686
wenzelm@42908
   687
  \medskip Hints for @{command (HOL) "recdef"} may be also declared
wenzelm@42908
   688
  globally, using the following attributes.
wenzelm@42908
   689
wenzelm@42908
   690
  \begin{matharray}{rcl}
wenzelm@42908
   691
    @{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
wenzelm@42908
   692
    @{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
wenzelm@42908
   693
    @{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
wenzelm@42908
   694
  \end{matharray}
wenzelm@42908
   695
wenzelm@55112
   696
  @{rail \<open>
wenzelm@42908
   697
    (@@{attribute (HOL) recdef_simp} | @@{attribute (HOL) recdef_cong} |
wenzelm@42908
   698
      @@{attribute (HOL) recdef_wf}) (() | 'add' | 'del')
wenzelm@55112
   699
  \<close>}
wenzelm@58618
   700
\<close>
wenzelm@58618
   701
wenzelm@58618
   702
wenzelm@58618
   703
section \<open>Old-style datatypes \label{sec:hol-datatype}\<close>
wenzelm@58618
   704
wenzelm@58618
   705
text \<open>
wenzelm@42908
   706
  \begin{matharray}{rcl}
blanchet@58305
   707
    @{command_def (HOL) "old_datatype"} & : & @{text "theory \<rightarrow> theory"} \\
blanchet@58306
   708
    @{command_def (HOL) "old_rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@42908
   709
  \end{matharray}
wenzelm@42908
   710
wenzelm@55112
   711
  @{rail \<open>
blanchet@58305
   712
    @@{command (HOL) old_datatype} (spec + @'and')
wenzelm@42908
   713
    ;
blanchet@58306
   714
    @@{command (HOL) old_rep_datatype} ('(' (@{syntax name} +) ')')? (@{syntax term} +)
wenzelm@42908
   715
    ;
wenzelm@42908
   716
wenzelm@45839
   717
    spec: @{syntax typespec_sorts} @{syntax mixfix}? '=' (cons + '|')
wenzelm@42908
   718
    ;
wenzelm@42908
   719
    cons: @{syntax name} (@{syntax type} * ) @{syntax mixfix}?
wenzelm@55112
   720
  \<close>}
wenzelm@42908
   721
wenzelm@42908
   722
  \begin{description}
wenzelm@42908
   723
blanchet@58305
   724
  \item @{command (HOL) "old_datatype"} defines old-style inductive
blanchet@58305
   725
  datatypes in HOL.
wenzelm@42908
   726
blanchet@58306
   727
  \item @{command (HOL) "old_rep_datatype"} represents existing types as
blanchet@58305
   728
  old-style datatypes.
wenzelm@42908
   729
wenzelm@42908
   730
  \end{description}
wenzelm@42908
   731
blanchet@58305
   732
  These commands are mostly obsolete; @{command (HOL) "datatype"}
blanchet@58305
   733
  should be used instead.
wenzelm@42908
   734
wenzelm@58552
   735
  See @{cite "isabelle-HOL"} for more details on datatypes, but beware of
wenzelm@42908
   736
  the old-style theory syntax being used there!  Apart from proper
wenzelm@42908
   737
  proof methods for case-analysis and induction, there are also
wenzelm@42908
   738
  emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
wenzelm@42908
   739
  induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
wenzelm@42908
   740
  to refer directly to the internal structure of subgoals (including
wenzelm@42908
   741
  internally bound parameters).
wenzelm@58618
   742
\<close>
wenzelm@58618
   743
wenzelm@58618
   744
wenzelm@58618
   745
subsubsection \<open>Examples\<close>
wenzelm@58618
   746
wenzelm@58618
   747
text \<open>We define a type of finite sequences, with slightly different
wenzelm@42910
   748
  names than the existing @{typ "'a list"} that is already in @{theory
wenzelm@58618
   749
  Main}:\<close>
wenzelm@42910
   750
blanchet@58310
   751
datatype 'a seq = Empty | Seq 'a "'a seq"
wenzelm@42910
   752
wenzelm@58618
   753
text \<open>We can now prove some simple lemma by structural induction:\<close>
wenzelm@42910
   754
wenzelm@42910
   755
lemma "Seq x xs \<noteq> xs"
wenzelm@42910
   756
proof (induct xs arbitrary: x)
wenzelm@42910
   757
  case Empty
wenzelm@58618
   758
  txt \<open>This case can be proved using the simplifier: the freeness
wenzelm@42910
   759
    properties of the datatype are already declared as @{attribute
wenzelm@58618
   760
    simp} rules.\<close>
wenzelm@42910
   761
  show "Seq x Empty \<noteq> Empty"
wenzelm@42910
   762
    by simp
wenzelm@42910
   763
next
wenzelm@42910
   764
  case (Seq y ys)
wenzelm@58618
   765
  txt \<open>The step case is proved similarly.\<close>
wenzelm@42910
   766
  show "Seq x (Seq y ys) \<noteq> Seq y ys"
wenzelm@58618
   767
    using \<open>Seq y ys \<noteq> ys\<close> by simp
wenzelm@42910
   768
qed
wenzelm@42910
   769
wenzelm@58618
   770
text \<open>Here is a more succinct version of the same proof:\<close>
wenzelm@42910
   771
wenzelm@42910
   772
lemma "Seq x xs \<noteq> xs"
wenzelm@42910
   773
  by (induct xs arbitrary: x) simp_all
wenzelm@42910
   774
wenzelm@42910
   775
wenzelm@58618
   776
section \<open>Records \label{sec:hol-record}\<close>
wenzelm@58618
   777
wenzelm@58618
   778
text \<open>
wenzelm@26849
   779
  In principle, records merely generalize the concept of tuples, where
wenzelm@26849
   780
  components may be addressed by labels instead of just position.  The
wenzelm@26849
   781
  logical infrastructure of records in Isabelle/HOL is slightly more
wenzelm@26849
   782
  advanced, though, supporting truly extensible record schemes.  This
wenzelm@26849
   783
  admits operations that are polymorphic with respect to record
wenzelm@26849
   784
  extension, yielding ``object-oriented'' effects like (single)
wenzelm@58552
   785
  inheritance.  See also @{cite "NaraschewskiW-TPHOLs98"} for more
wenzelm@26849
   786
  details on object-oriented verification and record subtyping in HOL.
wenzelm@58618
   787
\<close>
wenzelm@58618
   788
wenzelm@58618
   789
wenzelm@58618
   790
subsection \<open>Basic concepts\<close>
wenzelm@58618
   791
wenzelm@58618
   792
text \<open>
wenzelm@26849
   793
  Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
wenzelm@26849
   794
  at the level of terms and types.  The notation is as follows:
wenzelm@26849
   795
wenzelm@26849
   796
  \begin{center}
wenzelm@26849
   797
  \begin{tabular}{l|l|l}
wenzelm@26849
   798
    & record terms & record types \\ \hline
wenzelm@26849
   799
    fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
wenzelm@26849
   800
    schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
wenzelm@26849
   801
      @{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
wenzelm@26849
   802
  \end{tabular}
wenzelm@26849
   803
  \end{center}
wenzelm@26849
   804
wenzelm@26849
   805
  \noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
wenzelm@26849
   806
  "(| x = a |)"}.
wenzelm@26849
   807
wenzelm@26849
   808
  A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
wenzelm@26849
   809
  @{text a} and field @{text y} of value @{text b}.  The corresponding
wenzelm@26849
   810
  type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
wenzelm@26849
   811
  and @{text "b :: B"}.
wenzelm@26849
   812
wenzelm@26849
   813
  A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
wenzelm@26849
   814
  @{text x} and @{text y} as before, but also possibly further fields
wenzelm@26849
   815
  as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
wenzelm@26849
   816
  of the syntax).  The improper field ``@{text "\<dots>"}'' of a record
wenzelm@26849
   817
  scheme is called the \emph{more part}.  Logically it is just a free
wenzelm@26849
   818
  variable, which is occasionally referred to as ``row variable'' in
wenzelm@26849
   819
  the literature.  The more part of a record scheme may be
wenzelm@26849
   820
  instantiated by zero or more further components.  For example, the
wenzelm@26849
   821
  previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
wenzelm@26852
   822
  c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
wenzelm@26849
   823
  Fixed records are special instances of record schemes, where
wenzelm@26849
   824
  ``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
wenzelm@26849
   825
  element.  In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
wenzelm@26849
   826
  for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
wenzelm@42123
   827
wenzelm@26849
   828
  \medskip Two key observations make extensible records in a simply
wenzelm@26849
   829
  typed language like HOL work out:
wenzelm@26849
   830
wenzelm@26849
   831
  \begin{enumerate}
wenzelm@26849
   832
wenzelm@26849
   833
  \item the more part is internalized, as a free term or type
wenzelm@26849
   834
  variable,
wenzelm@26849
   835
wenzelm@26852
   836
  \item field names are externalized, they cannot be accessed within
wenzelm@26852
   837
  the logic as first-class values.
wenzelm@26849
   838
wenzelm@26849
   839
  \end{enumerate}
wenzelm@26849
   840
wenzelm@26849
   841
  \medskip In Isabelle/HOL record types have to be defined explicitly,
wenzelm@26849
   842
  fixing their field names and types, and their (optional) parent
wenzelm@26849
   843
  record.  Afterwards, records may be formed using above syntax, while
wenzelm@26849
   844
  obeying the canonical order of fields as given by their declaration.
wenzelm@26849
   845
  The record package provides several standard operations like
wenzelm@26849
   846
  selectors and updates.  The common setup for various generic proof
wenzelm@26849
   847
  tools enable succinct reasoning patterns.  See also the Isabelle/HOL
wenzelm@58552
   848
  tutorial @{cite "isabelle-hol-book"} for further instructions on using
wenzelm@26849
   849
  records in practice.
wenzelm@58618
   850
\<close>
wenzelm@58618
   851
wenzelm@58618
   852
wenzelm@58618
   853
subsection \<open>Record specifications\<close>
wenzelm@58618
   854
wenzelm@58618
   855
text \<open>
wenzelm@26849
   856
  \begin{matharray}{rcl}
wenzelm@28761
   857
    @{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@26849
   858
  \end{matharray}
wenzelm@26849
   859
wenzelm@55112
   860
  @{rail \<open>
wenzelm@55029
   861
    @@{command (HOL) record} @{syntax typespec_sorts} '=' \<newline>
wenzelm@46494
   862
      (@{syntax type} '+')? (constdecl +)
wenzelm@46494
   863
    ;
wenzelm@46494
   864
    constdecl: @{syntax name} '::' @{syntax type} @{syntax mixfix}?
wenzelm@55112
   865
  \<close>}
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@58618
   897
\<close>
wenzelm@58618
   898
wenzelm@58618
   899
wenzelm@58618
   900
subsection \<open>Record operations\<close>
wenzelm@58618
   901
wenzelm@58618
   902
text \<open>
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@58618
   976
\<close>
wenzelm@58618
   977
wenzelm@58618
   978
wenzelm@58618
   979
subsection \<open>Derived rules and proof tools\<close>
wenzelm@58618
   980
wenzelm@58618
   981
text \<open>
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@58618
  1026
\<close>
wenzelm@58618
  1027
wenzelm@58618
  1028
wenzelm@58618
  1029
subsubsection \<open>Examples\<close>
wenzelm@58618
  1030
wenzelm@58618
  1031
text \<open>See @{file "~~/src/HOL/ex/Records.thy"}, for example.\<close>
wenzelm@58618
  1032
wenzelm@58618
  1033
section \<open>Typedef axiomatization \label{sec:hol-typedef}\<close>
wenzelm@58618
  1034
wenzelm@58618
  1035
text \<open>
wenzelm@46280
  1036
  \begin{matharray}{rcl}
wenzelm@46280
  1037
    @{command_def (HOL) "typedef"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@46280
  1038
  \end{matharray}
wenzelm@46280
  1039
wenzelm@46280
  1040
  A Gordon/HOL-style type definition is a certain axiom scheme that
wenzelm@46280
  1041
  identifies a new type with a subset of an existing type.  More
wenzelm@42908
  1042
  precisely, the new type is defined by exhibiting an existing type
wenzelm@42908
  1043
  @{text \<tau>}, a set @{text "A :: \<tau> set"}, and a theorem that proves
wenzelm@42908
  1044
  @{prop "\<exists>x. x \<in> A"}.  Thus @{text A} is a non-empty subset of @{text
wenzelm@42908
  1045
  \<tau>}, and the new type denotes this subset.  New functions are
wenzelm@42908
  1046
  postulated that establish an isomorphism between the new type and
wenzelm@42908
  1047
  the subset.  In general, the type @{text \<tau>} may involve type
wenzelm@42908
  1048
  variables @{text "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} which means that the type definition
wenzelm@42908
  1049
  produces a type constructor @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t"} depending on
wenzelm@42908
  1050
  those type arguments.
wenzelm@42908
  1051
wenzelm@57480
  1052
  The axiomatization can be considered a ``definition'' in the sense of the
wenzelm@58552
  1053
  particular set-theoretic interpretation of HOL @{cite pitts93}, where the
wenzelm@57480
  1054
  universe of types is required to be downwards-closed wrt.\ arbitrary
wenzelm@57480
  1055
  non-empty subsets. Thus genuinely new types introduced by @{command
wenzelm@57480
  1056
  "typedef"} stay within the range of HOL models by construction.
wenzelm@57480
  1057
wenzelm@57480
  1058
  In contrast, the command @{command_ref type_synonym} from Isabelle/Pure
wenzelm@57480
  1059
  merely introduces syntactic abbreviations, without any logical
wenzelm@57480
  1060
  significance. Thus it is more faithful to the idea of a genuine type
wenzelm@57480
  1061
  definition, but less powerful in practice.
wenzelm@47859
  1062
wenzelm@55112
  1063
  @{rail \<open>
wenzelm@49836
  1064
    @@{command (HOL) typedef} abs_type '=' rep_set
wenzelm@26849
  1065
    ;
wenzelm@42908
  1066
    abs_type: @{syntax typespec_sorts} @{syntax mixfix}?
wenzelm@42908
  1067
    ;
wenzelm@42908
  1068
    rep_set: @{syntax term} (@'morphisms' @{syntax name} @{syntax name})?
wenzelm@55112
  1069
  \<close>}
wenzelm@26849
  1070
wenzelm@28760
  1071
  \begin{description}
wenzelm@26849
  1072
wenzelm@57480
  1073
  \item @{command (HOL) "typedef"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t = A"} produces an
wenzelm@57487
  1074
  axiomatization (\secref{sec:axiomatizations}) for a type definition in the
wenzelm@57480
  1075
  background theory of the current context, depending on a non-emptiness
wenzelm@57480
  1076
  result of the set @{text A} that needs to be proven here. The set @{text
wenzelm@57480
  1077
  A} may contain type variables @{text "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} as specified on the
wenzelm@57480
  1078
  LHS, but no term variables.
wenzelm@42908
  1079
wenzelm@42908
  1080
  Even though a local theory specification, the newly introduced type
wenzelm@42908
  1081
  constructor cannot depend on parameters or assumptions of the
wenzelm@42908
  1082
  context: this is structurally impossible in HOL.  In contrast, the
wenzelm@42908
  1083
  non-emptiness proof may use local assumptions in unusual situations,
wenzelm@42908
  1084
  which could result in different interpretations in target contexts:
wenzelm@42908
  1085
  the meaning of the bijection between the representing set @{text A}
wenzelm@42908
  1086
  and the new type @{text t} may then change in different application
wenzelm@42908
  1087
  contexts.
wenzelm@42908
  1088
wenzelm@49836
  1089
  For @{command (HOL) "typedef"}~@{text "t = A"} the newly introduced
wenzelm@49836
  1090
  type @{text t} is accompanied by a pair of morphisms to relate it to
wenzelm@49836
  1091
  the representing set over the old type.  By default, the injection
wenzelm@49836
  1092
  from type to set is called @{text Rep_t} and its inverse @{text
wenzelm@49836
  1093
  Abs_t}: An explicit @{keyword (HOL) "morphisms"} specification
wenzelm@49836
  1094
  allows to provide alternative names.
wenzelm@26849
  1095
wenzelm@42908
  1096
  The core axiomatization uses the locale predicate @{const
wenzelm@42908
  1097
  type_definition} as defined in Isabelle/HOL.  Various basic
wenzelm@42908
  1098
  consequences of that are instantiated accordingly, re-using the
wenzelm@42908
  1099
  locale facts with names derived from the new type constructor.  Thus
wenzelm@42908
  1100
  the generic @{thm type_definition.Rep} is turned into the specific
wenzelm@42908
  1101
  @{text "Rep_t"}, for example.
wenzelm@42908
  1102
wenzelm@42908
  1103
  Theorems @{thm type_definition.Rep}, @{thm
wenzelm@42908
  1104
  type_definition.Rep_inverse}, and @{thm type_definition.Abs_inverse}
wenzelm@42908
  1105
  provide the most basic characterization as a corresponding
wenzelm@42908
  1106
  injection/surjection pair (in both directions).  The derived rules
wenzelm@42908
  1107
  @{thm type_definition.Rep_inject} and @{thm
wenzelm@42908
  1108
  type_definition.Abs_inject} provide a more convenient version of
wenzelm@42908
  1109
  injectivity, suitable for automated proof tools (e.g.\ in
wenzelm@42908
  1110
  declarations involving @{attribute simp} or @{attribute iff}).
wenzelm@42908
  1111
  Furthermore, the rules @{thm type_definition.Rep_cases}~/ @{thm
wenzelm@42908
  1112
  type_definition.Rep_induct}, and @{thm type_definition.Abs_cases}~/
wenzelm@42908
  1113
  @{thm type_definition.Abs_induct} provide alternative views on
wenzelm@42908
  1114
  surjectivity.  These rules are already declared as set or type rules
wenzelm@42908
  1115
  for the generic @{method cases} and @{method induct} methods,
wenzelm@42908
  1116
  respectively.
wenzelm@42908
  1117
wenzelm@28760
  1118
  \end{description}
wenzelm@58618
  1119
\<close>
wenzelm@58618
  1120
wenzelm@58618
  1121
subsubsection \<open>Examples\<close>
wenzelm@58618
  1122
wenzelm@58618
  1123
text \<open>Type definitions permit the introduction of abstract data
wenzelm@42908
  1124
  types in a safe way, namely by providing models based on already
wenzelm@42908
  1125
  existing types.  Given some abstract axiomatic description @{text P}
wenzelm@42908
  1126
  of a type, this involves two steps:
wenzelm@42908
  1127
wenzelm@42908
  1128
  \begin{enumerate}
wenzelm@42908
  1129
wenzelm@42908
  1130
  \item Find an appropriate type @{text \<tau>} and subset @{text A} which
wenzelm@42908
  1131
  has the desired properties @{text P}, and make a type definition
wenzelm@42908
  1132
  based on this representation.
wenzelm@42908
  1133
wenzelm@42908
  1134
  \item Prove that @{text P} holds for @{text \<tau>} by lifting @{text P}
wenzelm@42908
  1135
  from the representation.
wenzelm@26849
  1136
wenzelm@42908
  1137
  \end{enumerate}
wenzelm@42908
  1138
wenzelm@42908
  1139
  You can later forget about the representation and work solely in
wenzelm@42908
  1140
  terms of the abstract properties @{text P}.
wenzelm@42908
  1141
wenzelm@42908
  1142
  \medskip The following trivial example pulls a three-element type
wenzelm@58618
  1143
  into existence within the formal logical environment of HOL.\<close>
wenzelm@42908
  1144
wenzelm@49834
  1145
typedef three = "{(True, True), (True, False), (False, True)}"
wenzelm@42908
  1146
  by blast
wenzelm@42908
  1147
wenzelm@42908
  1148
definition "One = Abs_three (True, True)"
wenzelm@42908
  1149
definition "Two = Abs_three (True, False)"
wenzelm@42908
  1150
definition "Three = Abs_three (False, True)"
wenzelm@42908
  1151
wenzelm@42908
  1152
lemma three_distinct: "One \<noteq> Two"  "One \<noteq> Three"  "Two \<noteq> Three"
wenzelm@49812
  1153
  by (simp_all add: One_def Two_def Three_def Abs_three_inject)
wenzelm@42908
  1154
wenzelm@42908
  1155
lemma three_cases:
wenzelm@42908
  1156
  fixes x :: three obtains "x = One" | "x = Two" | "x = Three"
wenzelm@49812
  1157
  by (cases x) (auto simp: One_def Two_def Three_def Abs_three_inject)
wenzelm@42908
  1158
wenzelm@58618
  1159
text \<open>Note that such trivial constructions are better done with
wenzelm@58618
  1160
  derived specification mechanisms such as @{command datatype}:\<close>
blanchet@58310
  1161
blanchet@58310
  1162
datatype three' = One' | Two' | Three'
wenzelm@42908
  1163
wenzelm@58618
  1164
text \<open>This avoids re-doing basic definitions and proofs from the
wenzelm@58618
  1165
  primitive @{command typedef} above.\<close>
wenzelm@58618
  1166
wenzelm@58618
  1167
wenzelm@58618
  1168
wenzelm@58618
  1169
section \<open>Functorial structure of types\<close>
wenzelm@58618
  1170
wenzelm@58618
  1171
text \<open>
haftmann@41396
  1172
  \begin{matharray}{rcl}
blanchet@55467
  1173
    @{command_def (HOL) "functor"} & : & @{text "local_theory \<rightarrow> proof(prove)"}
haftmann@41396
  1174
  \end{matharray}
haftmann@41396
  1175
wenzelm@55112
  1176
  @{rail \<open>
blanchet@55467
  1177
    @@{command (HOL) functor} (@{syntax name} ':')? @{syntax term}
wenzelm@55112
  1178
  \<close>}
haftmann@41396
  1179
haftmann@41396
  1180
  \begin{description}
haftmann@41396
  1181
blanchet@55467
  1182
  \item @{command (HOL) "functor"}~@{text "prefix: m"} allows to
wenzelm@42617
  1183
  prove and register properties about the functorial structure of type
wenzelm@42617
  1184
  constructors.  These properties then can be used by other packages
wenzelm@42617
  1185
  to deal with those type constructors in certain type constructions.
wenzelm@42617
  1186
  Characteristic theorems are noted in the current local theory.  By
wenzelm@42617
  1187
  default, they are prefixed with the base name of the type
wenzelm@42617
  1188
  constructor, an explicit prefix can be given alternatively.
haftmann@41396
  1189
haftmann@41396
  1190
  The given term @{text "m"} is considered as \emph{mapper} for the
haftmann@41396
  1191
  corresponding type constructor and must conform to the following
haftmann@41396
  1192
  type pattern:
haftmann@41396
  1193
haftmann@41396
  1194
  \begin{matharray}{lll}
haftmann@41396
  1195
    @{text "m"} & @{text "::"} &
wenzelm@53015
  1196
      @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>k \<Rightarrow> (\<^vec>\<alpha>\<^sub>n) t \<Rightarrow> (\<^vec>\<beta>\<^sub>n) t"} \\
haftmann@41396
  1197
  \end{matharray}
haftmann@41396
  1198
haftmann@41396
  1199
  \noindent where @{text t} is the type constructor, @{text
wenzelm@53015
  1200
  "\<^vec>\<alpha>\<^sub>n"} and @{text "\<^vec>\<beta>\<^sub>n"} are distinct
wenzelm@53015
  1201
  type variables free in the local theory and @{text "\<sigma>\<^sub>1"},
wenzelm@53015
  1202
  \ldots, @{text "\<sigma>\<^sub>k"} is a subsequence of @{text "\<alpha>\<^sub>1 \<Rightarrow>
wenzelm@53015
  1203
  \<beta>\<^sub>1"}, @{text "\<beta>\<^sub>1 \<Rightarrow> \<alpha>\<^sub>1"}, \ldots,
wenzelm@53015
  1204
  @{text "\<alpha>\<^sub>n \<Rightarrow> \<beta>\<^sub>n"}, @{text "\<beta>\<^sub>n \<Rightarrow>
wenzelm@53015
  1205
  \<alpha>\<^sub>n"}.
haftmann@41396
  1206
haftmann@41396
  1207
  \end{description}
wenzelm@58618
  1208
\<close>
wenzelm@58618
  1209
wenzelm@58618
  1210
wenzelm@58618
  1211
section \<open>Quotient types\<close>
wenzelm@58618
  1212
wenzelm@58618
  1213
text \<open>
wenzelm@50109
  1214
  \begin{matharray}{rcl}
wenzelm@50109
  1215
    @{command_def (HOL) "quotient_type"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
wenzelm@50109
  1216
    @{command_def (HOL) "quotient_definition"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
wenzelm@50109
  1217
    @{command_def (HOL) "print_quotmapsQ3"} & : & @{text "context \<rightarrow>"}\\
wenzelm@50109
  1218
    @{command_def (HOL) "print_quotientsQ3"} & : & @{text "context \<rightarrow>"}\\
wenzelm@50109
  1219
    @{command_def (HOL) "print_quotconsts"} & : & @{text "context \<rightarrow>"}\\
wenzelm@50109
  1220
    @{method_def (HOL) "lifting"} & : & @{text method} \\
wenzelm@50109
  1221
    @{method_def (HOL) "lifting_setup"} & : & @{text method} \\
wenzelm@50109
  1222
    @{method_def (HOL) "descending"} & : & @{text method} \\
wenzelm@50109
  1223
    @{method_def (HOL) "descending_setup"} & : & @{text method} \\
wenzelm@50109
  1224
    @{method_def (HOL) "partiality_descending"} & : & @{text method} \\
wenzelm@50109
  1225
    @{method_def (HOL) "partiality_descending_setup"} & : & @{text method} \\
wenzelm@50109
  1226
    @{method_def (HOL) "regularize"} & : & @{text method} \\
wenzelm@50109
  1227
    @{method_def (HOL) "injection"} & : & @{text method} \\
wenzelm@50109
  1228
    @{method_def (HOL) "cleaning"} & : & @{text method} \\
wenzelm@50109
  1229
    @{attribute_def (HOL) "quot_thm"} & : & @{text attribute} \\
wenzelm@50109
  1230
    @{attribute_def (HOL) "quot_lifted"} & : & @{text attribute} \\
wenzelm@50109
  1231
    @{attribute_def (HOL) "quot_respect"} & : & @{text attribute} \\
wenzelm@50109
  1232
    @{attribute_def (HOL) "quot_preserve"} & : & @{text attribute} \\
wenzelm@50109
  1233
  \end{matharray}
wenzelm@50109
  1234
wenzelm@50109
  1235
  The quotient package defines a new quotient type given a raw type
kuncar@54334
  1236
  and a partial equivalence relation. The package also historically 
kuncar@54334
  1237
  includes automation for transporting definitions and theorems. 
kuncar@54334
  1238
  But most of this automation was superseded by the Lifting and Transfer
kuncar@54334
  1239
  packages. The user should consider using these two new packages for
kuncar@54334
  1240
  lifting definitions and transporting theorems.
wenzelm@50109
  1241
wenzelm@55112
  1242
  @{rail \<open>
wenzelm@55112
  1243
    @@{command (HOL) quotient_type} (spec)
wenzelm@55112
  1244
    ;
wenzelm@55029
  1245
    spec: @{syntax typespec} @{syntax mixfix}? '=' \<newline>
wenzelm@55029
  1246
     @{syntax type} '/' ('partial' ':')? @{syntax term} \<newline>
wenzelm@55112
  1247
     (@'morphisms' @{syntax name} @{syntax name})? (@'parametric' @{syntax thmref})?
wenzelm@55112
  1248
  \<close>}
wenzelm@55112
  1249
wenzelm@55112
  1250
  @{rail \<open>
wenzelm@55029
  1251
    @@{command (HOL) quotient_definition} constdecl? @{syntax thmdecl}? \<newline>
wenzelm@55112
  1252
    @{syntax term} 'is' @{syntax term}
wenzelm@55112
  1253
    ;
wenzelm@50109
  1254
    constdecl: @{syntax name} ('::' @{syntax type})? @{syntax mixfix}?
wenzelm@55112
  1255
  \<close>}
wenzelm@55112
  1256
wenzelm@55112
  1257
  @{rail \<open>
wenzelm@50109
  1258
    @@{method (HOL) lifting} @{syntax thmrefs}?
wenzelm@50109
  1259
    ;
wenzelm@50109
  1260
    @@{method (HOL) lifting_setup} @{syntax thmrefs}?
wenzelm@55112
  1261
  \<close>}
wenzelm@50109
  1262
wenzelm@50109
  1263
  \begin{description}
wenzelm@50109
  1264
kuncar@54334
  1265
  \item @{command (HOL) "quotient_type"} defines a new quotient type @{text \<tau>}. The
wenzelm@50109
  1266
  injection from a quotient type to a raw type is called @{text
kuncar@54334
  1267
  rep_\<tau>}, its inverse @{text abs_\<tau>} unless explicit @{keyword (HOL)
wenzelm@50109
  1268
  "morphisms"} specification provides alternative names. @{command
wenzelm@50109
  1269
  (HOL) "quotient_type"} requires the user to prove that the relation
wenzelm@50109
  1270
  is an equivalence relation (predicate @{text equivp}), unless the
Christian@52895
  1271
  user specifies explicitly @{text partial} in which case the
wenzelm@50109
  1272
  obligation is @{text part_equivp}.  A quotient defined with @{text
wenzelm@50109
  1273
  partial} is weaker in the sense that less things can be proved
wenzelm@50109
  1274
  automatically.
wenzelm@50109
  1275
kuncar@54334
  1276
  The command internally proves a Quotient theorem and sets up the Lifting
kuncar@54334
  1277
  package by the command @{command (HOL) setup_lifting}. Thus the Lifting 
kuncar@54334
  1278
  and Transfer packages can be used also with quotient types defined by
kuncar@54334
  1279
  @{command (HOL) "quotient_type"} without any extra set-up. The parametricity 
kuncar@54334
  1280
  theorem for the equivalence relation R can be provided as an extra argument 
kuncar@54334
  1281
  of the command and is passed to the corresponding internal call of @{command (HOL) setup_lifting}.
kuncar@54334
  1282
  This theorem allows the Lifting package to generate a stronger transfer rule for equality.
kuncar@54334
  1283
  
kuncar@54334
  1284
  \end{description}
kuncar@54334
  1285
kuncar@54334
  1286
  The most of the rest of the package was superseded by the Lifting and Transfer
kuncar@54334
  1287
  packages. The user should consider using these two new packages for
kuncar@54334
  1288
  lifting definitions and transporting theorems.
kuncar@54334
  1289
kuncar@54334
  1290
  \begin{description}  
kuncar@54334
  1291
wenzelm@50109
  1292
  \item @{command (HOL) "quotient_definition"} defines a constant on
wenzelm@50109
  1293
  the quotient type.
wenzelm@50109
  1294
wenzelm@50109
  1295
  \item @{command (HOL) "print_quotmapsQ3"} prints quotient map
wenzelm@50109
  1296
  functions.
wenzelm@50109
  1297
wenzelm@50109
  1298
  \item @{command (HOL) "print_quotientsQ3"} prints quotients.
wenzelm@50109
  1299
wenzelm@50109
  1300
  \item @{command (HOL) "print_quotconsts"} prints quotient constants.
wenzelm@50109
  1301
wenzelm@50109
  1302
  \item @{method (HOL) "lifting"} and @{method (HOL) "lifting_setup"}
wenzelm@50109
  1303
    methods match the current goal with the given raw theorem to be
wenzelm@50109
  1304
    lifted producing three new subgoals: regularization, injection and
wenzelm@50109
  1305
    cleaning subgoals. @{method (HOL) "lifting"} tries to apply the
wenzelm@50109
  1306
    heuristics for automatically solving these three subgoals and
wenzelm@50109
  1307
    leaves only the subgoals unsolved by the heuristics to the user as
wenzelm@50109
  1308
    opposed to @{method (HOL) "lifting_setup"} which leaves the three
wenzelm@50109
  1309
    subgoals unsolved.
wenzelm@50109
  1310
wenzelm@50109
  1311
  \item @{method (HOL) "descending"} and @{method (HOL)
wenzelm@50109
  1312
    "descending_setup"} try to guess a raw statement that would lift
wenzelm@50109
  1313
    to the current subgoal. Such statement is assumed as a new subgoal
wenzelm@50109
  1314
    and @{method (HOL) "descending"} continues in the same way as
wenzelm@50109
  1315
    @{method (HOL) "lifting"} does. @{method (HOL) "descending"} tries
wenzelm@50109
  1316
    to solve the arising regularization, injection and cleaning
Christian@52895
  1317
    subgoals with the analogous method @{method (HOL)
wenzelm@50109
  1318
    "descending_setup"} which leaves the four unsolved subgoals.
wenzelm@50109
  1319
wenzelm@50109
  1320
  \item @{method (HOL) "partiality_descending"} finds the regularized
wenzelm@50109
  1321
    theorem that would lift to the current subgoal, lifts it and
wenzelm@50109
  1322
    leaves as a subgoal. This method can be used with partial
wenzelm@50109
  1323
    equivalence quotients where the non regularized statements would
wenzelm@50109
  1324
    not be true. @{method (HOL) "partiality_descending_setup"} leaves
wenzelm@50109
  1325
    the injection and cleaning subgoals unchanged.
wenzelm@50109
  1326
wenzelm@50109
  1327
  \item @{method (HOL) "regularize"} applies the regularization
wenzelm@50109
  1328
    heuristics to the current subgoal.
wenzelm@50109
  1329
wenzelm@50109
  1330
  \item @{method (HOL) "injection"} applies the injection heuristics
wenzelm@50109
  1331
    to the current goal using the stored quotient respectfulness
wenzelm@50109
  1332
    theorems.
wenzelm@50109
  1333
wenzelm@50109
  1334
  \item @{method (HOL) "cleaning"} applies the injection cleaning
wenzelm@50109
  1335
    heuristics to the current subgoal using the stored quotient
wenzelm@50109
  1336
    preservation theorems.
wenzelm@50109
  1337
wenzelm@50109
  1338
  \item @{attribute (HOL) quot_lifted} attribute tries to
wenzelm@50109
  1339
    automatically transport the theorem to the quotient type.
wenzelm@50109
  1340
    The attribute uses all the defined quotients types and quotient
wenzelm@50109
  1341
    constants often producing undesired results or theorems that
wenzelm@50109
  1342
    cannot be lifted.
wenzelm@50109
  1343
wenzelm@50109
  1344
  \item @{attribute (HOL) quot_respect} and @{attribute (HOL)
wenzelm@50109
  1345
    quot_preserve} attributes declare a theorem as a respectfulness
wenzelm@50109
  1346
    and preservation theorem respectively.  These are stored in the
wenzelm@50109
  1347
    local theory store and used by the @{method (HOL) "injection"}
wenzelm@50109
  1348
    and @{method (HOL) "cleaning"} methods respectively.
wenzelm@50109
  1349
wenzelm@50109
  1350
  \item @{attribute (HOL) quot_thm} declares that a certain theorem
wenzelm@50109
  1351
    is a quotient extension theorem. Quotient extension theorems
wenzelm@50109
  1352
    allow for quotienting inside container types. Given a polymorphic
wenzelm@50109
  1353
    type that serves as a container, a map function defined for this
blanchet@55467
  1354
    container using @{command (HOL) "functor"} and a relation
wenzelm@50109
  1355
    map defined for for the container type, the quotient extension
wenzelm@50109
  1356
    theorem should be @{term "Quotient3 R Abs Rep \<Longrightarrow> Quotient3
wenzelm@50109
  1357
    (rel_map R) (map Abs) (map Rep)"}. Quotient extension theorems
wenzelm@50109
  1358
    are stored in a database and are used all the steps of lifting
wenzelm@50109
  1359
    theorems.
wenzelm@50109
  1360
wenzelm@50109
  1361
  \end{description}
wenzelm@58618
  1362
\<close>
wenzelm@58618
  1363
wenzelm@58618
  1364
wenzelm@58618
  1365
section \<open>Definition by specification \label{sec:hol-specification}\<close>
wenzelm@58618
  1366
wenzelm@58618
  1367
text \<open>
wenzelm@50109
  1368
  \begin{matharray}{rcl}
wenzelm@50109
  1369
    @{command_def (HOL) "specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@50109
  1370
  \end{matharray}
wenzelm@50109
  1371
wenzelm@55112
  1372
  @{rail \<open>
wenzelm@56270
  1373
    @@{command (HOL) specification} '(' (decl +) ')' \<newline>
wenzelm@56270
  1374
      (@{syntax thmdecl}? @{syntax prop} +)
wenzelm@55112
  1375
    ;
wenzelm@56270
  1376
    decl: (@{syntax name} ':')? @{syntax term} ('(' @'overloaded' ')')?
wenzelm@55112
  1377
  \<close>}
wenzelm@50109
  1378
wenzelm@50109
  1379
  \begin{description}
wenzelm@50109
  1380
wenzelm@50109
  1381
  \item @{command (HOL) "specification"}~@{text "decls \<phi>"} sets up a
wenzelm@50109
  1382
  goal stating the existence of terms with the properties specified to
wenzelm@50109
  1383
  hold for the constants given in @{text decls}.  After finishing the
wenzelm@50109
  1384
  proof, the theory will be augmented with definitions for the given
wenzelm@50109
  1385
  constants, as well as with theorems stating the properties for these
wenzelm@50109
  1386
  constants.
wenzelm@50109
  1387
wenzelm@56270
  1388
  @{text decl} declares a constant to be defined by the
wenzelm@50109
  1389
  specification given.  The definition for the constant @{text c} is
wenzelm@50109
  1390
  bound to the name @{text c_def} unless a theorem name is given in
wenzelm@50109
  1391
  the declaration.  Overloaded constants should be declared as such.
wenzelm@50109
  1392
wenzelm@50109
  1393
  \end{description}
wenzelm@58618
  1394
\<close>
wenzelm@58618
  1395
wenzelm@58618
  1396
wenzelm@58618
  1397
section \<open>Adhoc overloading of constants\<close>
wenzelm@58618
  1398
wenzelm@58618
  1399
text \<open>
Christian@52895
  1400
  \begin{tabular}{rcll}
Christian@52895
  1401
  @{command_def "adhoc_overloading"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
Christian@52895
  1402
  @{command_def "no_adhoc_overloading"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
Christian@52895
  1403
  @{attribute_def "show_variants"} & : & @{text "attribute"} & default @{text false} \\
Christian@52895
  1404
  \end{tabular}
Christian@52895
  1405
Christian@52895
  1406
  \medskip
Christian@52895
  1407
Christian@52895
  1408
  Adhoc overloading allows to overload a constant depending on
Christian@52895
  1409
  its type. Typically this involves the introduction of an
Christian@52895
  1410
  uninterpreted constant (used for input and output) and the addition
Christian@52895
  1411
  of some variants (used internally). For examples see
Christian@52895
  1412
  @{file "~~/src/HOL/ex/Adhoc_Overloading_Examples.thy"} and
Christian@52895
  1413
  @{file "~~/src/HOL/Library/Monad_Syntax.thy"}.
Christian@52895
  1414
wenzelm@55112
  1415
  @{rail \<open>
Christian@52895
  1416
    (@@{command adhoc_overloading} | @@{command no_adhoc_overloading})
wenzelm@55112
  1417
      (@{syntax nameref} (@{syntax term} + ) + @'and')
wenzelm@55112
  1418
  \<close>}
Christian@52895
  1419
Christian@52895
  1420
  \begin{description}
Christian@52895
  1421
wenzelm@53015
  1422
  \item @{command "adhoc_overloading"}~@{text "c v\<^sub>1 ... v\<^sub>n"}
Christian@52895
  1423
  associates variants with an existing constant.
Christian@52895
  1424
Christian@52895
  1425
  \item @{command "no_adhoc_overloading"} is similar to
Christian@52895
  1426
  @{command "adhoc_overloading"}, but removes the specified variants
Christian@52895
  1427
  from the present context.
Christian@52895
  1428
  
Christian@52895
  1429
  \item @{attribute "show_variants"} controls printing of variants
Christian@52895
  1430
  of overloaded constants. If enabled, the internally used variants
Christian@52895
  1431
  are printed instead of their respective overloaded constants. This
Christian@52895
  1432
  is occasionally useful to check whether the system agrees with a
Christian@52895
  1433
  user's expectations about derived variants.
Christian@52895
  1434
Christian@52895
  1435
  \end{description}
wenzelm@58618
  1436
\<close>
wenzelm@58618
  1437
wenzelm@58618
  1438
wenzelm@58618
  1439
chapter \<open>Proof tools\<close>
wenzelm@58618
  1440
wenzelm@58618
  1441
section \<open>Adhoc tuples\<close>
wenzelm@58618
  1442
wenzelm@58618
  1443
text \<open>
wenzelm@50109
  1444
  \begin{matharray}{rcl}
wenzelm@50109
  1445
    @{attribute_def (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
wenzelm@50109
  1446
  \end{matharray}
wenzelm@50109
  1447
wenzelm@55112
  1448
  @{rail \<open>
wenzelm@50109
  1449
    @@{attribute (HOL) split_format} ('(' 'complete' ')')?
wenzelm@55112
  1450
  \<close>}
wenzelm@50109
  1451
wenzelm@50109
  1452
  \begin{description}
wenzelm@50109
  1453
wenzelm@50109
  1454
  \item @{attribute (HOL) split_format}\ @{text "(complete)"} causes
wenzelm@50109
  1455
  arguments in function applications to be represented canonically
wenzelm@50109
  1456
  according to their tuple type structure.
wenzelm@50109
  1457
wenzelm@50109
  1458
  Note that this operation tends to invent funny names for new local
wenzelm@50109
  1459
  parameters introduced.
wenzelm@50109
  1460
wenzelm@50109
  1461
  \end{description}
wenzelm@58618
  1462
\<close>
wenzelm@58618
  1463
wenzelm@58618
  1464
wenzelm@58618
  1465
section \<open>Transfer package\<close>
wenzelm@58618
  1466
wenzelm@58618
  1467
text \<open>
huffman@47821
  1468
  \begin{matharray}{rcl}
huffman@47821
  1469
    @{method_def (HOL) "transfer"} & : & @{text method} \\
huffman@47821
  1470
    @{method_def (HOL) "transfer'"} & : & @{text method} \\
huffman@47821
  1471
    @{method_def (HOL) "transfer_prover"} & : & @{text method} \\
kuncar@54334
  1472
    @{attribute_def (HOL) "Transfer.transferred"} & : & @{text attribute} \\
kuncar@54334
  1473
    @{attribute_def (HOL) "untransferred"} & : & @{text attribute} \\
huffman@47821
  1474
    @{attribute_def (HOL) "transfer_rule"} & : & @{text attribute} \\
kuncar@54334
  1475
    @{attribute_def (HOL) "transfer_domain_rule"} & : & @{text attribute} \\
huffman@47821
  1476
    @{attribute_def (HOL) "relator_eq"} & : & @{text attribute} \\
kuncar@54334
  1477
    @{attribute_def (HOL) "relator_domain"} & : & @{text attribute} \\
huffman@47821
  1478
  \end{matharray}
huffman@47821
  1479
huffman@47821
  1480
  \begin{description}
huffman@47821
  1481
huffman@47821
  1482
  \item @{method (HOL) "transfer"} method replaces the current subgoal
huffman@47821
  1483
    with a logically equivalent one that uses different types and
huffman@47821
  1484
    constants. The replacement of types and constants is guided by the
huffman@47821
  1485
    database of transfer rules. Goals are generalized over all free
huffman@47821
  1486
    variables by default; this is necessary for variables whose types
huffman@47821
  1487
    change, but can be overridden for specific variables with e.g.
huffman@47821
  1488
    @{text "transfer fixing: x y z"}.
huffman@47821
  1489
huffman@47821
  1490
  \item @{method (HOL) "transfer'"} is a variant of @{method (HOL)
huffman@47821
  1491
    transfer} that allows replacing a subgoal with one that is
huffman@47821
  1492
    logically stronger (rather than equivalent). For example, a
huffman@47821
  1493
    subgoal involving equality on a quotient type could be replaced
huffman@47821
  1494
    with a subgoal involving equality (instead of the corresponding
huffman@47821
  1495
    equivalence relation) on the underlying raw type.
huffman@47821
  1496
huffman@47821
  1497
  \item @{method (HOL) "transfer_prover"} method assists with proving
huffman@47821
  1498
    a transfer rule for a new constant, provided the constant is
huffman@47821
  1499
    defined in terms of other constants that already have transfer
huffman@47821
  1500
    rules. It should be applied after unfolding the constant
huffman@47821
  1501
    definitions.
huffman@47821
  1502
kuncar@54334
  1503
  \item @{attribute (HOL) "untransferred"} proves the same equivalent theorem
kuncar@54334
  1504
     as @{method (HOL) "transfer"} internally does.
kuncar@54334
  1505
kuncar@54334
  1506
  \item @{attribute (HOL) Transfer.transferred} works in the opposite
kuncar@54334
  1507
    direction than @{method (HOL) "transfer'"}. E.g., given the transfer
kuncar@54334
  1508
    relation @{text "ZN x n \<equiv> (x = int n)"}, corresponding transfer rules and the theorem
kuncar@54334
  1509
    @{text "\<forall>x::int \<in> {0..}. x < x + 1"}, the attribute would prove 
kuncar@54334
  1510
    @{text "\<forall>n::nat. n < n + 1"}. The attribute is still in experimental
kuncar@54334
  1511
    phase of development.
kuncar@54334
  1512
huffman@47821
  1513
  \item @{attribute (HOL) "transfer_rule"} attribute maintains a
huffman@47821
  1514
    collection of transfer rules, which relate constants at two
huffman@47821
  1515
    different types. Typical transfer rules may relate different type
huffman@47821
  1516
    instances of the same polymorphic constant, or they may relate an
huffman@47821
  1517
    operation on a raw type to a corresponding operation on an
huffman@47821
  1518
    abstract type (quotient or subtype). For example:
huffman@47821
  1519
huffman@47821
  1520
    @{text "((A ===> B) ===> list_all2 A ===> list_all2 B) map map"}\\
huffman@47821
  1521
    @{text "(cr_int ===> cr_int ===> cr_int) (\<lambda>(x,y) (u,v). (x+u, y+v)) plus"}
huffman@47821
  1522
huffman@47821
  1523
    Lemmas involving predicates on relations can also be registered
huffman@47821
  1524
    using the same attribute. For example:
huffman@47821
  1525
huffman@47821
  1526
    @{text "bi_unique A \<Longrightarrow> (list_all2 A ===> op =) distinct distinct"}\\
blanchet@55944
  1527
    @{text "\<lbrakk>bi_unique A; bi_unique B\<rbrakk> \<Longrightarrow> bi_unique (rel_prod A B)"}
huffman@47821
  1528
kuncar@57829
  1529
    Preservation of predicates on relations (@{text "bi_unique, bi_total,
kuncar@57829
  1530
    right_unique, right_total, left_unique, left_total"}) with the respect to a relator
wenzelm@58552
  1531
    is proved automatically if the involved type is BNF
wenzelm@58552
  1532
    @{cite "isabelle-datatypes"} without dead variables.
kuncar@57829
  1533
kuncar@54334
  1534
  \item @{attribute (HOL) "transfer_domain_rule"} attribute maintains a collection
kuncar@54334
  1535
    of rules, which specify a domain of a transfer relation by a predicate.
kuncar@54334
  1536
    E.g., given the transfer relation @{text "ZN x n \<equiv> (x = int n)"}, 
kuncar@54334
  1537
    one can register the following transfer domain rule: 
kuncar@54334
  1538
    @{text "Domainp ZN = (\<lambda>x. x \<ge> 0)"}. The rules allow the package to produce
kuncar@54334
  1539
    more readable transferred goals, e.g., when quantifiers are transferred.
kuncar@54334
  1540
huffman@47821
  1541
  \item @{attribute (HOL) relator_eq} attribute collects identity laws
kuncar@57829
  1542
    for relators of various type constructors, e.g. @{term "rel_set
huffman@47821
  1543
    (op =) = (op =)"}. The @{method (HOL) transfer} method uses these
huffman@47821
  1544
    lemmas to infer transfer rules for non-polymorphic constants on
kuncar@57829
  1545
    the fly. For examples see @{file
kuncar@57829
  1546
    "~~/src/HOL/Lifting_Set.thy"} or @{file "~~/src/HOL/Lifting.thy"}. 
kuncar@57829
  1547
    This property is proved automatically if the involved type is BNF without dead variables.
huffman@47821
  1548
kuncar@54334
  1549
  \item @{attribute_def (HOL) "relator_domain"} attribute collects rules 
kuncar@57829
  1550
    describing domains of relators by predicators. E.g., 
kuncar@57829
  1551
    @{term "Domainp (rel_set T) = (\<lambda>A. Ball A (Domainp T))"}. This allows the package 
kuncar@57829
  1552
    to lift transfer domain rules through type constructors. For examples see @{file
kuncar@57829
  1553
    "~~/src/HOL/Lifting_Set.thy"} or @{file "~~/src/HOL/Lifting.thy"}.
kuncar@57829
  1554
    This property is proved automatically if the involved type is BNF without dead variables.
kuncar@54334
  1555
huffman@47821
  1556
  \end{description}
huffman@47821
  1557
wenzelm@58552
  1558
  Theoretical background can be found in @{cite "Huffman-Kuncar:2013:lifting_transfer"}.
wenzelm@58618
  1559
\<close>
wenzelm@58618
  1560
wenzelm@58618
  1561
wenzelm@58618
  1562
section \<open>Lifting package\<close>
wenzelm@58618
  1563
wenzelm@58618
  1564
text \<open>
kuncar@54334
  1565
  The Lifting package allows users to lift terms of the raw type to the abstract type, which is 
kuncar@54334
  1566
  a necessary step in building a library for an abstract type. Lifting defines a new constant 
kuncar@54334
  1567
  by combining coercion functions (Abs and Rep) with the raw term. It also proves an appropriate 
kuncar@54334
  1568
  transfer rule for the Transfer package and, if possible, an equation for the code generator.
kuncar@54334
  1569
kuncar@54334
  1570
  The Lifting package provides two main commands: @{command (HOL) "setup_lifting"} for initializing 
kuncar@54334
  1571
  the package to work with a new type, and @{command (HOL) "lift_definition"} for lifting constants. 
kuncar@54334
  1572
  The Lifting package works with all four kinds of type abstraction: type copies, subtypes, 
kuncar@54334
  1573
  total quotients and partial quotients.
kuncar@54334
  1574
wenzelm@58552
  1575
  Theoretical background can be found in @{cite "Huffman-Kuncar:2013:lifting_transfer"}.
kuncar@54334
  1576
kuncar@47802
  1577
  \begin{matharray}{rcl}
kuncar@47802
  1578
    @{command_def (HOL) "setup_lifting"} & : & @{text "local_theory \<rightarrow> local_theory"}\\
kuncar@47802
  1579
    @{command_def (HOL) "lift_definition"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
kuncar@54334
  1580
    @{command_def (HOL) "lifting_forget"} & : & @{text "local_theory \<rightarrow> local_theory"}\\
kuncar@54334
  1581
    @{command_def (HOL) "lifting_update"} & : & @{text "local_theory \<rightarrow> local_theory"}\\
kuncar@53219
  1582
    @{command_def (HOL) "print_quot_maps"} & : & @{text "context \<rightarrow>"}\\
kuncar@47802
  1583
    @{command_def (HOL) "print_quotients"} & : & @{text "context \<rightarrow>"}\\
kuncar@47802
  1584
    @{attribute_def (HOL) "quot_map"} & : & @{text attribute} \\
kuncar@56519
  1585
    @{attribute_def (HOL) "relator_eq_onp"} & : & @{text attribute} \\
kuncar@54334
  1586
    @{attribute_def (HOL) "relator_mono"} & : & @{text attribute} \\
kuncar@54334
  1587
    @{attribute_def (HOL) "relator_distr"} & : & @{text attribute} \\
kuncar@54334
  1588
    @{attribute_def (HOL) "quot_del"} & : & @{text attribute} \\
kuncar@54334
  1589
    @{attribute_def (HOL) "lifting_restore"} & : & @{text attribute} \\   
kuncar@47802
  1590
  \end{matharray}
kuncar@47802
  1591
wenzelm@55112
  1592
  @{rail \<open>
wenzelm@59783
  1593
    @@{command (HOL) setup_lifting} @{syntax thmref} @{syntax thmref}? \<newline>
wenzelm@59783
  1594
      (@'parametric' @{syntax thmref})?
wenzelm@55112
  1595
  \<close>}
wenzelm@55112
  1596
wenzelm@55112
  1597
  @{rail \<open>
wenzelm@55029
  1598
    @@{command (HOL) lift_definition} @{syntax name} '::' @{syntax type}  @{syntax mixfix}? \<newline>
wenzelm@59783
  1599
      'is' @{syntax term} (@'parametric' (@{syntax thmref}+))?
wenzelm@55112
  1600
  \<close>}
wenzelm@55112
  1601
wenzelm@55112
  1602
  @{rail \<open>
wenzelm@59783
  1603
    @@{command (HOL) lifting_forget} @{syntax nameref}
wenzelm@55112
  1604
  \<close>}
wenzelm@55112
  1605
wenzelm@55112
  1606
  @{rail \<open>
wenzelm@59783
  1607
    @@{command (HOL) lifting_update} @{syntax nameref}
wenzelm@55112
  1608
  \<close>}
wenzelm@55112
  1609
wenzelm@55112
  1610
  @{rail \<open>
wenzelm@59783
  1611
    @@{attribute (HOL) lifting_restore} @{syntax thmref} (@{syntax thmref} @{syntax thmref})?
wenzelm@55112
  1612
  \<close>}
kuncar@47802
  1613
kuncar@47802
  1614
  \begin{description}
kuncar@47802
  1615
wenzelm@47859
  1616
  \item @{command (HOL) "setup_lifting"} Sets up the Lifting package
kuncar@54334
  1617
    to work with a user-defined type. 
kuncar@54334
  1618
    The command supports two modes. The first one is a low-level mode when 
kuncar@54334
  1619
    the user must provide as a first
kuncar@54334
  1620
    argument of @{command (HOL) "setup_lifting"} a
kuncar@57829
  1621
    quotient theorem @{term "Quotient R Abs Rep T"}. The
kuncar@54334
  1622
    package configures a transfer rule for equality, a domain transfer
kuncar@54334
  1623
    rules and sets up the @{command_def (HOL) "lift_definition"}
kuncar@57829
  1624
    command to work with the abstract type. An optional theorem @{term "reflp R"}, which certifies that 
kuncar@54334
  1625
    the equivalence relation R is total,
kuncar@54334
  1626
    can be provided as a second argument. This allows the package to generate stronger transfer
kuncar@54334
  1627
    rules. And finally, the parametricity theorem for R can be provided as a third argument.
kuncar@54334
  1628
    This allows the package to generate a stronger transfer rule for equality.
kuncar@54334
  1629
kuncar@54334
  1630
    Users generally will not prove the @{text Quotient} theorem manually for 
kuncar@54334
  1631
    new types, as special commands exist to automate the process.
kuncar@54334
  1632
    
kuncar@54334
  1633
    When a new subtype is defined by @{command (HOL) typedef}, @{command (HOL) "lift_definition"} 
kuncar@54334
  1634
    can be used in its
kuncar@54334
  1635
    second mode, where only the type_definition theorem @{text "type_definition Rep Abs A"}
kuncar@54334
  1636
    is used as an argument of the command. The command internally proves the corresponding 
kuncar@54334
  1637
    Quotient theorem and registers it with @{command (HOL) setup_lifting} using its first mode.
kuncar@54334
  1638
kuncar@54334
  1639
    For quotients, the command @{command (HOL) quotient_type} can be used. The command defines 
kuncar@54334
  1640
    a new quotient type and similarly to the previous case, the corresponding Quotient theorem is proved 
kuncar@54334
  1641
    and registered by @{command (HOL) setup_lifting}.
kuncar@54334
  1642
    
kuncar@54334
  1643
    The command @{command (HOL) "setup_lifting"} also sets up the code generator
kuncar@54334
  1644
    for the new type. Later on, when a new constant is defined by @{command (HOL) "lift_definition"},
kuncar@54334
  1645
    the Lifting package proves and registers a code equation (if there is one) for the new constant.
kuncar@54334
  1646
kuncar@54334
  1647
  \item @{command (HOL) "lift_definition"} @{text "f :: \<tau>"} @{keyword (HOL) "is"} @{text t}
wenzelm@47859
  1648
    Defines a new function @{text f} with an abstract type @{text \<tau>}
wenzelm@47859
  1649
    in terms of a corresponding operation @{text t} on a
kuncar@54334
  1650
    representation type. More formally, if @{text "t :: \<sigma>"}, then
kuncar@54334
  1651
    the command builds a term @{text "F"} as a corresponding combination of abstraction 
kuncar@54334
  1652
    and representation functions such that @{text "F :: \<sigma> \<Rightarrow> \<tau>" } and 
kuncar@54334
  1653
    defines @{text f} is as @{text "f \<equiv> F t"}.
kuncar@54334
  1654
    The term @{text t} does not have to be necessarily a constant but it can be any term.
kuncar@54334
  1655
kuncar@54334
  1656
    The command opens a proof environment and the user must discharge 
kuncar@54334
  1657
    a respectfulness proof obligation. For a type copy, i.e., a typedef with @{text
kuncar@54334
  1658
    UNIV}, the obligation is discharged automatically. The proof goal is
kuncar@47802
  1659
    presented in a user-friendly, readable form. A respectfulness
wenzelm@47859
  1660
    theorem in the standard format @{text f.rsp} and a transfer rule
kuncar@54334
  1661
    @{text f.transfer} for the Transfer package are generated by the
wenzelm@47859
  1662
    package.
kuncar@47802
  1663
kuncar@57829
  1664
    The user can specify a parametricity theorems for @{text t} after the keyword 
kuncar@54334
  1665
    @{keyword "parametric"}, which allows the command
kuncar@57829
  1666
    to generate parametric transfer rules for @{text f}.
kuncar@54334
  1667
kuncar@50879
  1668
    For each constant defined through trivial quotients (type copies or
kuncar@50879
  1669
    subtypes) @{text f.rep_eq} is generated. The equation is a code certificate
kuncar@50879
  1670
    that defines @{text f} using the representation function.
kuncar@50879
  1671
kuncar@50879
  1672
    For each constant @{text f.abs_eq} is generated. The equation is unconditional
kuncar@50879
  1673
    for total quotients. The equation defines @{text f} using
kuncar@50879
  1674
    the abstraction function.
kuncar@50879
  1675
kuncar@54334
  1676
    Integration with [@{attribute code} abstract]: For subtypes (e.g.,
wenzelm@47859
  1677
    corresponding to a datatype invariant, such as dlist), @{command
kuncar@50879
  1678
    (HOL) "lift_definition"} uses a code certificate theorem
kuncar@50879
  1679
    @{text f.rep_eq} as a code equation.
kuncar@50879
  1680
kuncar@54334
  1681
    Integration with [@{attribute code} equation]: For total quotients, @{command
kuncar@50879
  1682
    (HOL) "lift_definition"} uses @{text f.abs_eq} as a code equation.
kuncar@47802
  1683
kuncar@54334
  1684
  \item @{command (HOL) lifting_forget} and  @{command (HOL) lifting_update}
kuncar@54334
  1685
    These two commands serve for storing and deleting the set-up of
kuncar@54334
  1686
    the Lifting package and corresponding transfer rules defined by this package.
kuncar@54334
  1687
    This is useful for hiding of type construction details of an abstract type 
kuncar@54334
  1688
    when the construction is finished but it still allows additions to this construction
kuncar@54334
  1689
    when this is later necessary.
kuncar@54334
  1690
kuncar@54334
  1691
    Whenever the Lifting package is set up with a new abstract type @{text "\<tau>"} by  
kuncar@54334
  1692
    @{command_def (HOL) "lift_definition"}, the package defines a new bundle
kuncar@54334
  1693
    that is called @{text "\<tau>.lifting"}. This bundle already includes set-up for the Lifting package. 
kuncar@54334
  1694
    The new transfer rules
kuncar@54334
  1695
    introduced by @{command (HOL) "lift_definition"} can be stored in the bundle by
kuncar@54334
  1696
    the command @{command (HOL) "lifting_update"} @{text "\<tau>.lifting"}.
kuncar@54334
  1697
kuncar@54334
  1698
    The command @{command (HOL) "lifting_forget"} @{text "\<tau>.lifting"} deletes set-up of the Lifting 
kuncar@54334
  1699
    package
kuncar@54334
  1700
    for @{text \<tau>} and deletes all the transfer rules that were introduced
kuncar@54334
  1701
    by @{command (HOL) "lift_definition"} using @{text \<tau>} as an abstract type.
kuncar@54334
  1702
kuncar@54334
  1703
    The stored set-up in a bundle can be reintroduced by the Isar commands for including a bundle
kuncar@54334
  1704
    (@{command "include"}, @{keyword "includes"} and @{command "including"}).
kuncar@54334
  1705
kuncar@53219
  1706
  \item @{command (HOL) "print_quot_maps"} prints stored quotient map
wenzelm@47859
  1707
    theorems.
wenzelm@47859
  1708
wenzelm@47859
  1709
  \item @{command (HOL) "print_quotients"} prints stored quotient
wenzelm@47859
  1710
    theorems.
wenzelm@47859
  1711
wenzelm@47859
  1712
  \item @{attribute (HOL) quot_map} registers a quotient map
kuncar@57829
  1713
    theorem, a theorem showing how to "lift" quotients over type constructors. 
kuncar@57829
  1714
    E.g., @{term "Quotient R Abs Rep T \<Longrightarrow> 
kuncar@57829
  1715
    Quotient (rel_set R) (image Abs) (image Rep) (rel_set T)"}. 
kuncar@54334
  1716
    For examples see @{file
kuncar@57829
  1717
    "~~/src/HOL/Lifting_Set.thy"} or @{file "~~/src/HOL/Lifting.thy"}.
kuncar@57829
  1718
    This property is proved automatically if the involved type is BNF without dead variables.
wenzelm@47859
  1719
kuncar@56519
  1720
  \item @{attribute (HOL) relator_eq_onp} registers a theorem that
kuncar@57829
  1721
    shows that a relator applied to an equality restricted by a predicate @{term P} (i.e., @{term
kuncar@57829
  1722
    "eq_onp P"}) is equal 
kuncar@57829
  1723
    to a predicator applied to the @{term P}. The combinator @{const eq_onp} is used for 
kuncar@57829
  1724
    internal encoding of proper subtypes. Such theorems allows the package to hide @{text
kuncar@56519
  1725
    eq_onp} from a user in a user-readable form of a
wenzelm@47859
  1726
    respectfulness theorem. For examples see @{file
kuncar@57829
  1727
    "~~/src/HOL/Lifting_Set.thy"} or @{file "~~/src/HOL/Lifting.thy"}.
kuncar@57829
  1728
    This property is proved automatically if the involved type is BNF without dead variables.
kuncar@47802
  1729
kuncar@54334
  1730
  \item @{attribute (HOL) "relator_mono"} registers a property describing a monotonicity of a relator.
kuncar@57829
  1731
    E.g., @{term "A \<le> B \<Longrightarrow> rel_set A \<le> rel_set B"}. 
kuncar@54334
  1732
    This property is needed for proving a stronger transfer rule in @{command_def (HOL) "lift_definition"}
kuncar@57829
  1733
    when a parametricity theorem for the raw term is specified and also for the reflexivity prover.
kuncar@57829
  1734
    For examples see @{file
kuncar@57829
  1735
    "~~/src/HOL/Lifting_Set.thy"} or @{file "~~/src/HOL/Lifting.thy"}.
kuncar@57829
  1736
    This property is proved automatically if the involved type is BNF without dead variables.
kuncar@54334
  1737
kuncar@54334
  1738
  \item @{attribute (HOL) "relator_distr"} registers a property describing a distributivity
kuncar@54334
  1739
    of the relation composition and a relator. E.g., 
kuncar@57829
  1740
    @{text "rel_set R \<circ>\<circ> rel_set S = rel_set (R \<circ>\<circ> S)"}. 
kuncar@54334
  1741
    This property is needed for proving a stronger transfer rule in @{command_def (HOL) "lift_definition"}
kuncar@54334
  1742
    when a parametricity theorem for the raw term is specified.
kuncar@54334
  1743
    When this equality does not hold unconditionally (e.g., for the function type), the user can specified
kuncar@54334
  1744
    each direction separately and also register multiple theorems with different set of assumptions.
kuncar@54334
  1745
    This attribute can be used only after the monotonicity property was already registered by
kuncar@57829
  1746
    @{attribute (HOL) "relator_mono"}. For examples see @{file
kuncar@57829
  1747
    "~~/src/HOL/Lifting_Set.thy"} or @{file "~~/src/HOL/Lifting.thy"}.
kuncar@57829
  1748
    This property is proved automatically if the involved type is BNF without dead variables.
kuncar@50877
  1749
kuncar@50877
  1750
  \item @{attribute (HOL) quot_del} deletes a corresponding Quotient theorem
kuncar@50877
  1751
    from the Lifting infrastructure and thus de-register the corresponding quotient. 
kuncar@50877
  1752
    This effectively causes that @{command (HOL) lift_definition}  will not
kuncar@54334
  1753
    do any lifting for the corresponding type. This attribute is rather used for low-level
kuncar@54334
  1754
    manipulation with set-up of the Lifting package because @{command (HOL) lifting_forget} is
kuncar@54334
  1755
    preferred for normal usage.
kuncar@54334
  1756
kuncar@54334
  1757
  \item @{attribute (HOL) lifting_restore} @{text "Quotient_thm pcr_def pcr_cr_eq_thm"} 
kuncar@54334
  1758
    registers the Quotient theorem @{text Quotient_thm} in the Lifting infrastructure 
kuncar@54334
  1759
    and thus sets up lifting for an abstract type @{text \<tau>} (that is defined by @{text Quotient_thm}).
kuncar@54334
  1760
    Optional theorems @{text pcr_def} and @{text pcr_cr_eq_thm} can be specified to register 
kuncar@54334
  1761
    the parametrized
kuncar@54334
  1762
    correspondence relation for @{text \<tau>}. E.g., for @{text "'a dlist"}, @{text pcr_def} is
kuncar@54334
  1763
    @{text "pcr_dlist A \<equiv> list_all2 A \<circ>\<circ> cr_dlist"} and @{text pcr_cr_eq_thm} is 
kuncar@54334
  1764
    @{text "pcr_dlist op= = op="}.
kuncar@54334
  1765
    This attribute is rather used for low-level
kuncar@54334
  1766
    manipulation with set-up of the Lifting package because using of the bundle @{text \<tau>.lifting} 
kuncar@54334
  1767
    together with the commands @{command (HOL) lifting_forget} and @{command (HOL) lifting_update} is
kuncar@54334
  1768
    preferred for normal usage.
kuncar@54334
  1769
wenzelm@58552
  1770
  \item Integration with the BNF package @{cite "isabelle-datatypes"}:
kuncar@57829
  1771
    As already mentioned, the theorems that are registered
kuncar@57829
  1772
    by the following attributes are proved and registered automatically if the involved type
kuncar@57829
  1773
    is BNF without dead variables: @{attribute (HOL) quot_map}, @{attribute (HOL) relator_eq_onp}, 
kuncar@57829
  1774
    @{attribute (HOL) "relator_mono"}, @{attribute (HOL) "relator_distr"}. Also the definition of a 
kuncar@57829
  1775
    relator and predicator is provided automatically. Moreover, if the BNF represents a datatype, 
kuncar@57829
  1776
    simplification rules for a predicator are again proved automatically.
kuncar@57829
  1777
  
kuncar@47802
  1778
  \end{description}
wenzelm@58618
  1779
\<close>
wenzelm@58618
  1780
wenzelm@58618
  1781
wenzelm@58618
  1782
section \<open>Coercive subtyping\<close>
wenzelm@58618
  1783
wenzelm@58618
  1784
text \<open>
noschinl@43994
  1785
  \begin{matharray}{rcl}
noschinl@43994
  1786
    @{attribute_def (HOL) coercion} & : & @{text attribute} \\
noschinl@43994
  1787
    @{attribute_def (HOL) coercion_enabled} & : & @{text attribute} \\
noschinl@43994
  1788
    @{attribute_def (HOL) coercion_map} & : & @{text attribute} \\
noschinl@43994
  1789
  \end{matharray}
noschinl@43994
  1790
wenzelm@46280
  1791
  Coercive subtyping allows the user to omit explicit type
wenzelm@46280
  1792
  conversions, also called \emph{coercions}.  Type inference will add
wenzelm@46280
  1793
  them as necessary when parsing a term. See
wenzelm@58552
  1794
  @{cite "traytel-berghofer-nipkow-2011"} for details.
wenzelm@46280
  1795
wenzelm@55112
  1796
  @{rail \<open>
noschinl@43994
  1797
    @@{attribute (HOL) coercion} (@{syntax term})?
noschinl@43994
  1798
    ;
noschinl@43994
  1799
    @@{attribute (HOL) coercion_map} (@{syntax term})?
wenzelm@55112
  1800
  \<close>}
noschinl@43994
  1801
noschinl@43994
  1802
  \begin{description}
noschinl@43994
  1803
noschinl@43994
  1804
  \item @{attribute (HOL) "coercion"}~@{text "f"} registers a new
wenzelm@53015
  1805
  coercion function @{text "f :: \<sigma>\<^sub>1 \<Rightarrow> \<sigma>\<^sub>2"} where @{text "\<sigma>\<^sub>1"} and
wenzelm@53015
  1806
  @{text "\<sigma>\<^sub>2"} are type constructors without arguments.  Coercions are
wenzelm@46280
  1807
  composed by the inference algorithm if needed.  Note that the type
wenzelm@46280
  1808
  inference algorithm is complete only if the registered coercions
wenzelm@46280
  1809
  form a lattice.
noschinl@43994
  1810
wenzelm@46280
  1811
  \item @{attribute (HOL) "coercion_map"}~@{text "map"} registers a
wenzelm@46280
  1812
  new map function to lift coercions through type constructors. The
wenzelm@46280
  1813
  function @{text "map"} must conform to the following type pattern
noschinl@43994
  1814
noschinl@43994
  1815
  \begin{matharray}{lll}
noschinl@43994
  1816
    @{text "map"} & @{text "::"} &
wenzelm@53015
  1817
      @{text "f\<^sub>1 \<Rightarrow> \<dots> \<Rightarrow> f\<^sub>n \<Rightarrow> (\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t \<Rightarrow> (\<beta>\<^sub>1, \<dots>, \<beta>\<^sub>n) t"} \\
noschinl@43994
  1818
  \end{matharray}
noschinl@43994
  1819
wenzelm@53015
  1820
  where @{text "t"} is a type constructor and @{text "f\<^sub>i"} is of type
wenzelm@53015
  1821
  @{text "\<alpha>\<^sub>i \<Rightarrow> \<beta>\<^sub>i"} or @{text "\<beta>\<^sub>i \<Rightarrow> \<alpha>\<^sub>i"}.  Registering a map function
wenzelm@46280
  1822
  overwrites any existing map function for this particular type
wenzelm@46280
  1823
  constructor.
noschinl@43994
  1824
noschinl@43994
  1825
  \item @{attribute (HOL) "coercion_enabled"} enables the coercion
noschinl@43994
  1826
  inference algorithm.
noschinl@43994
  1827
noschinl@43994
  1828
  \end{description}
wenzelm@58618
  1829
\<close>
wenzelm@58618
  1830
wenzelm@58618
  1831
wenzelm@58618
  1832
section \<open>Arithmetic proof support\<close>
wenzelm@58618
  1833
wenzelm@58618
  1834
text \<open>
wenzelm@26849
  1835
  \begin{matharray}{rcl}
wenzelm@28761
  1836
    @{method_def (HOL) arith} & : & @{text method} \\
nipkow@30863
  1837
    @{attribute_def (HOL) arith} & : & @{text attribute} \\
wenzelm@28761
  1838
    @{attribute_def (HOL) arith_split} & : & @{text attribute} \\
wenzelm@26849
  1839
  \end{matharray}
wenzelm@26849
  1840
wenzelm@46280
  1841
  \begin{description}
wenzelm@26849
  1842
wenzelm@46280
  1843
  \item @{method (HOL) arith} decides linear arithmetic problems (on
wenzelm@46280
  1844
  types @{text nat}, @{text int}, @{text real}).  Any current facts
wenzelm@46280
  1845
  are inserted into the goal before running the procedure.
wenzelm@26849
  1846
wenzelm@46280
  1847
  \item @{attribute (HOL) arith} declares facts that are supplied to
wenzelm@46280
  1848
  the arithmetic provers implicitly.
wenzelm@46280
  1849
wenzelm@46280
  1850
  \item @{attribute (HOL) arith_split} attribute declares case split
wenzelm@30865
  1851
  rules to be expanded before @{method (HOL) arith} is invoked.
nipkow@30863
  1852
wenzelm@46280
  1853
  \end{description}
wenzelm@46280
  1854
wenzelm@46280
  1855
  Note that a simpler (but faster) arithmetic prover is already
wenzelm@46280
  1856
  invoked by the Simplifier.
wenzelm@58618
  1857
\<close>
wenzelm@58618
  1858
wenzelm@58618
  1859
wenzelm@58618
  1860
section \<open>Intuitionistic proof search\<close>
wenzelm@58618
  1861
wenzelm@58618
  1862
text \<open>
wenzelm@30169
  1863
  \begin{matharray}{rcl}
wenzelm@30171
  1864
    @{method_def (HOL) iprover} & : & @{text method} \\
wenzelm@30169
  1865
  \end{matharray}
wenzelm@30169
  1866
wenzelm@55112
  1867
  @{rail \<open>
wenzelm@55112
  1868
    @@{method (HOL) iprover} (@{syntax rulemod} *)
wenzelm@55112
  1869
  \<close>}
wenzelm@30169
  1870
wenzelm@46280
  1871
  \begin{description}
wenzelm@46280
  1872
wenzelm@46280
  1873
  \item @{method (HOL) iprover} performs intuitionistic proof search,
wenzelm@46280
  1874
  depending on specifically declared rules from the context, or given
wenzelm@46280
  1875
  as explicit arguments.  Chained facts are inserted into the goal
wenzelm@46280
  1876
  before commencing proof search.
wenzelm@35613
  1877
wenzelm@30169
  1878
  Rules need to be classified as @{attribute (Pure) intro},
wenzelm@30169
  1879
  @{attribute (Pure) elim}, or @{attribute (Pure) dest}; here the
wenzelm@30169
  1880
  ``@{text "!"}'' indicator refers to ``safe'' rules, which may be
wenzelm@30169
  1881
  applied aggressively (without considering back-tracking later).
wenzelm@30169
  1882
  Rules declared with ``@{text "?"}'' are ignored in proof search (the
wenzelm@42626
  1883
  single-step @{method (Pure) rule} method still observes these).  An
wenzelm@30169
  1884
  explicit weight annotation may be given as well; otherwise the
wenzelm@30169
  1885
  number of rule premises will be taken into account here.
wenzelm@46280
  1886
wenzelm@46280
  1887
  \end{description}
wenzelm@58618
  1888
\<close>
wenzelm@58618
  1889
wenzelm@58618
  1890
wenzelm@58618
  1891
section \<open>Model Elimination and Resolution\<close>
wenzelm@58618
  1892
wenzelm@58618
  1893
text \<open>
blanchet@43578
  1894
  \begin{matharray}{rcl}
blanchet@43578
  1895
    @{method_def (HOL) "meson"} & : & @{text method} \\
blanchet@43578
  1896
    @{method_def (HOL) "metis"} & : & @{text method} \\
blanchet@43578
  1897
  \end{matharray}
blanchet@43578
  1898
wenzelm@55112
  1899
  @{rail \<open>
blanchet@43578
  1900
    @@{method (HOL) meson} @{syntax thmrefs}?
blanchet@43578
  1901
    ;
wenzelm@46280
  1902
    @@{method (HOL) metis}
wenzelm@46280
  1903
      ('(' ('partial_types' | 'full_types' | 'no_types' | @{syntax name}) ')')?
wenzelm@46280
  1904
      @{syntax thmrefs}?
wenzelm@55112
  1905
  \<close>}
blanchet@43578
  1906
wenzelm@46280
  1907
  \begin{description}
wenzelm@46280
  1908
wenzelm@46280
  1909
  \item @{method (HOL) meson} implements Loveland's model elimination
wenzelm@58552
  1910
  procedure @{cite "loveland-78"}.  See @{file
wenzelm@46280
  1911
  "~~/src/HOL/ex/Meson_Test.thy"} for examples.
blanchet@43578
  1912
wenzelm@46280
  1913
  \item @{method (HOL) metis} combines ordered resolution and ordered
wenzelm@46280
  1914
  paramodulation to find first-order (or mildly higher-order) proofs.
wenzelm@46280
  1915
  The first optional argument specifies a type encoding; see the
wenzelm@58552
  1916
  Sledgehammer manual @{cite "isabelle-sledgehammer"} for details.  The
wenzelm@46280
  1917
  directory @{file "~~/src/HOL/Metis_Examples"} contains several small
wenzelm@46280
  1918
  theories developed to a large extent using @{method (HOL) metis}.
wenzelm@46280
  1919
wenzelm@46280
  1920
  \end{description}
wenzelm@58618
  1921
\<close>
wenzelm@58618
  1922
wenzelm@58618
  1923
wenzelm@58618
  1924
section \<open>Algebraic reasoning via Gr\"obner bases\<close>
wenzelm@58618
  1925
wenzelm@58618
  1926
text \<open>
wenzelm@50130
  1927
  \begin{matharray}{rcl}
wenzelm@50130
  1928
    @{method_def (HOL) "algebra"} & : & @{text method} \\
wenzelm@50130
  1929
    @{attribute_def (HOL) algebra} & : & @{text attribute} \\
wenzelm@50130
  1930
  \end{matharray}
wenzelm@50130
  1931
wenzelm@55112
  1932
  @{rail \<open>
wenzelm@50130
  1933
    @@{method (HOL) algebra}
wenzelm@50130
  1934
      ('add' ':' @{syntax thmrefs})?
wenzelm@50130
  1935
      ('del' ':' @{syntax thmrefs})?
wenzelm@50130
  1936
    ;
wenzelm@50130
  1937
    @@{attribute (HOL) algebra} (() | 'add' | 'del')
wenzelm@55112
  1938
  \<close>}
wenzelm@50130
  1939
wenzelm@50130
  1940
  \begin{description}
wenzelm@50130
  1941
wenzelm@50130
  1942
  \item @{method (HOL) algebra} performs algebraic reasoning via
wenzelm@58552
  1943
  Gr\"obner bases, see also @{cite "Chaieb-Wenzel:2007"} and
wenzelm@58552
  1944
  @{cite \<open>\S3.2\<close> "Chaieb-thesis"}. The method handles deals with two main
wenzelm@50130
  1945
  classes of problems:
wenzelm@50130
  1946
wenzelm@50130
  1947
  \begin{enumerate}
wenzelm@50130
  1948
wenzelm@50130
  1949
  \item Universal problems over multivariate polynomials in a
wenzelm@50130
  1950
  (semi)-ring/field/idom; the capabilities of the method are augmented
wenzelm@50130
  1951
  according to properties of these structures. For this problem class
wenzelm@50130
  1952
  the method is only complete for algebraically closed fields, since
wenzelm@50130
  1953
  the underlying method is based on Hilbert's Nullstellensatz, where
wenzelm@50130
  1954
  the equivalence only holds for algebraically closed fields.
wenzelm@50130
  1955
wenzelm@50130
  1956
  The problems can contain equations @{text "p = 0"} or inequations
wenzelm@50130
  1957
  @{text "q \<noteq> 0"} anywhere within a universal problem statement.
wenzelm@50130
  1958
wenzelm@50130
  1959
  \item All-exists problems of the following restricted (but useful)
wenzelm@50130
  1960
  form:
wenzelm@50130
  1961
wenzelm@50130
  1962
  @{text [display] "\<forall>x\<^sub>1 \<dots> x\<^sub>n.
wenzelm@50130
  1963
    e\<^sub>1(x\<^sub>1, \<dots>, x\<^sub>n) = 0 \<and> \<dots> \<and> e\<^sub>m(x\<^sub>1, \<dots>, x\<^sub>n) = 0 \<longrightarrow>
wenzelm@50130
  1964
    (\<exists>y\<^sub>1 \<dots> y\<^sub>k.
wenzelm@50130
  1965
      p\<^sub>1\<^sub>1(x\<^sub>1, \<dots> ,x\<^sub>n) * y\<^sub>1 + \<dots> + p\<^sub>1\<^sub>k(x\<^sub>1, \<dots>, x\<^sub>n) * y\<^sub>k = 0 \<and>
wenzelm@50130
  1966
      \<dots> \<and>
wenzelm@50130
  1967
      p\<^sub>t\<^sub>1(x\<^sub>1, \<dots>, x\<^sub>n) * y\<^sub>1 + \<dots> + p\<^sub>t\<^sub>k(x\<^sub>1, \<dots>, x\<^sub>n) * y\<^sub>k = 0)"}
wenzelm@50130
  1968
wenzelm@50130
  1969
  Here @{text "e\<^sub>1, \<dots>, e\<^sub>n"} and the @{text "p\<^sub>i\<^sub>j"} are multivariate
wenzelm@50130
  1970
  polynomials only in the variables mentioned as arguments.
wenzelm@50130
  1971
wenzelm@50130
  1972
  \end{enumerate}
wenzelm@50130
  1973
wenzelm@50130
  1974
  The proof method is preceded by a simplification step, which may be
wenzelm@50130
  1975
  modified by using the form @{text "(algebra add: ths\<^sub>1 del: ths\<^sub>2)"}.
wenzelm@50130
  1976
  This acts like declarations for the Simplifier
wenzelm@50130
  1977
  (\secref{sec:simplifier}) on a private simpset for this tool.
wenzelm@50130
  1978
wenzelm@50130
  1979
  \item @{attribute algebra} (as attribute) manages the default
wenzelm@50130
  1980
  collection of pre-simplification rules of the above proof method.
wenzelm@50130
  1981
wenzelm@50130
  1982
  \end{description}
wenzelm@58618
  1983
\<close>
wenzelm@58618
  1984
wenzelm@58618
  1985
wenzelm@58618
  1986
subsubsection \<open>Example\<close>
wenzelm@58618
  1987
wenzelm@58618
  1988
text \<open>The subsequent example is from geometry: collinearity is
wenzelm@58618
  1989
  invariant by rotation.\<close>
wenzelm@50130
  1990
wenzelm@50130
  1991
type_synonym point = "int \<times> int"
wenzelm@50130
  1992
wenzelm@50130
  1993
fun collinear :: "point \<Rightarrow> point \<Rightarrow> point \<Rightarrow> bool" where
wenzelm@50130
  1994
  "collinear (Ax, Ay) (Bx, By) (Cx, Cy) \<longleftrightarrow>
wenzelm@50130
  1995
    (Ax - Bx) * (By - Cy) = (Ay - By) * (Bx - Cx)"
wenzelm@50130
  1996
wenzelm@50130
  1997
lemma collinear_inv_rotation:
wenzelm@53015
  1998
  assumes "collinear (Ax, Ay) (Bx, By) (Cx, Cy)" and "c\<^sup>2 + s\<^sup>2 = 1"
wenzelm@50130
  1999
  shows "collinear (Ax * c - Ay * s, Ay * c + Ax * s)
wenzelm@50130
  2000
    (Bx * c - By * s, By * c + Bx * s) (Cx * c - Cy * s, Cy * c + Cx * s)"
wenzelm@50130
  2001
  using assms by (algebra add: collinear.simps)
wenzelm@50130
  2002
wenzelm@58618
  2003
text \<open>
wenzelm@53982
  2004
 See also @{file "~~/src/HOL/ex/Groebner_Examples.thy"}.
wenzelm@58618
  2005
\<close>
wenzelm@58618
  2006
wenzelm@58618
  2007
wenzelm@58618
  2008
section \<open>Coherent Logic\<close>
wenzelm@58618
  2009
wenzelm@58618
  2010
text \<open>
wenzelm@30171
  2011
  \begin{matharray}{rcl}
wenzelm@30171
  2012
    @{method_def (HOL) "coherent"} & : & @{text method} \\
wenzelm@30171
  2013
  \end{matharray}
wenzelm@30171
  2014
wenzelm@55112
  2015
  @{rail \<open>
wenzelm@42596
  2016
    @@{method (HOL) coherent} @{syntax thmrefs}?
wenzelm@55112
  2017
  \<close>}
wenzelm@30171
  2018
wenzelm@46280
  2019
  \begin{description}
wenzelm@46280
  2020
wenzelm@46280
  2021
  \item @{method (HOL) coherent} solves problems of \emph{Coherent
wenzelm@58552
  2022
  Logic} @{cite "Bezem-Coquand:2005"}, which covers applications in
wenzelm@46280
  2023
  confluence theory, lattice theory and projective geometry.  See
wenzelm@46280
  2024
  @{file "~~/src/HOL/ex/Coherent.thy"} for some examples.
wenzelm@46280
  2025
wenzelm@46280
  2026
  \end{description}
wenzelm@58618
  2027
\<close>
wenzelm@58618
  2028
wenzelm@58618
  2029
wenzelm@58618
  2030
section \<open>Proving propositions\<close>
wenzelm@58618
  2031
wenzelm@58618
  2032
text \<open>
blanchet@42215
  2033
  In addition to the standard proof methods, a number of diagnosis
blanchet@42215
  2034
  tools search for proofs and provide an Isar proof snippet on success.
blanchet@42215
  2035
  These tools are available via the following commands.
blanchet@42215
  2036
blanchet@42215
  2037
  \begin{matharray}{rcl}
blanchet@42215
  2038
    @{command_def (HOL) "solve_direct"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  2039
    @{command_def (HOL) "try"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@46641
  2040
    @{command_def (HOL) "try0"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  2041
    @{command_def (HOL) "sledgehammer"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  2042
    @{command_def (HOL) "sledgehammer_params"} & : & @{text "theory \<rightarrow> theory"}
blanchet@42215
  2043
  \end{matharray}
blanchet@42215
  2044
wenzelm@55112
  2045
  @{rail \<open>
blanchet@43040
  2046
    @@{command (HOL) try}
blanchet@43040
  2047
    ;
blanchet@43040
  2048
blanchet@46641
  2049
    @@{command (HOL) try0} ( ( ( 'simp' | 'intro' | 'elim' | 'dest' ) ':' @{syntax thmrefs} ) + ) ?
wenzelm@42596
  2050
      @{syntax nat}?
blanchet@42215
  2051
    ;
blanchet@43040
  2052
wenzelm@42596
  2053
    @@{command (HOL) sledgehammer} ( '[' args ']' )? facts? @{syntax nat}?
blanchet@42215
  2054
    ;
blanchet@42215
  2055
wenzelm@42596
  2056
    @@{command (HOL) sledgehammer_params} ( ( '[' args ']' ) ? )
blanchet@42215
  2057
    ;
wenzelm@42596
  2058
    args: ( @{syntax name} '=' value + ',' )
blanchet@42215
  2059
    ;
wenzelm@42596
  2060
    facts: '(' ( ( ( ( 'add' | 'del' ) ':' ) ? @{syntax thmrefs} ) + ) ? ')'
wenzelm@55112
  2061
  \<close>} % FIXME check args "value"
blanchet@42215
  2062
blanchet@42215
  2063
  \begin{description}
blanchet@42215
  2064
wenzelm@46283
  2065
  \item @{command (HOL) "solve_direct"} checks whether the current
wenzelm@46283
  2066
  subgoals can be solved directly by an existing theorem. Duplicate
wenzelm@46283
  2067
  lemmas can be detected in this way.
blanchet@42215
  2068
blanchet@46641
  2069
  \item @{command (HOL) "try0"} attempts to prove a subgoal
wenzelm@46283
  2070
  using a combination of standard proof methods (@{method auto},
wenzelm@46283
  2071
  @{method simp}, @{method blast}, etc.).  Additional facts supplied
wenzelm@46283
  2072
  via @{text "simp:"}, @{text "intro:"}, @{text "elim:"}, and @{text
wenzelm@46283
  2073
  "dest:"} are passed to the appropriate proof methods.
blanchet@42215
  2074
bulwahn@43914
  2075
  \item @{command (HOL) "try"} attempts to prove or disprove a subgoal
wenzelm@46283
  2076
  using a combination of provers and disprovers (@{command (HOL)
wenzelm@46283
  2077
  "solve_direct"}, @{command (HOL) "quickcheck"}, @{command (HOL)
blanchet@46641
  2078
  "try0"}, @{command (HOL) "sledgehammer"}, @{command (HOL)
wenzelm@46283
  2079
  "nitpick"}).
bulwahn@43914
  2080
wenzelm@46283
  2081
  \item @{command (HOL) "sledgehammer"} attempts to prove a subgoal
wenzelm@46283
  2082
  using external automatic provers (resolution provers and SMT
wenzelm@58552
  2083
  solvers). See the Sledgehammer manual @{cite "isabelle-sledgehammer"}
wenzelm@46283
  2084
  for details.
blanchet@42215
  2085
wenzelm@46283
  2086
  \item @{command (HOL) "sledgehammer_params"} changes @{command (HOL)
wenzelm@46283
  2087
  "sledgehammer"} configuration options persistently.
blanchet@42215
  2088
blanchet@42215
  2089
  \end{description}
wenzelm@58618
  2090
\<close>
wenzelm@58618
  2091
wenzelm@58618
  2092
wenzelm@58618
  2093
section \<open>Checking and refuting propositions\<close>
wenzelm@58618
  2094
wenzelm@58618
  2095
text \<open>
haftmann@31912
  2096
  Identifying incorrect propositions usually involves evaluation of
blanchet@42215
  2097
  particular assignments and systematic counterexample search.  This
haftmann@31912
  2098
  is supported by the following commands.
haftmann@31912
  2099
haftmann@31912
  2100
  \begin{matharray}{rcl}
haftmann@31912
  2101
    @{command_def (HOL) "value"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
bulwahn@45409
  2102
    @{command_def (HOL) "values"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@31912
  2103
    @{command_def (HOL) "quickcheck"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  2104
    @{command_def (HOL) "nitpick"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
blanchet@42215
  2105
    @{command_def (HOL) "quickcheck_params"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45943
  2106
    @{command_def (HOL) "nitpick_params"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@46592
  2107
    @{command_def (HOL) "quickcheck_generator"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@46592
  2108
    @{command_def (HOL) "find_unused_assms"} & : & @{text "context \<rightarrow>"}
haftmann@31912
  2109
  \end{matharray}
haftmann@31912
  2110
wenzelm@55112
  2111
  @{rail \<open>
haftmann@58100
  2112
    @@{command (HOL) value} ( '[' @{syntax name} ']' )? modes? @{syntax term}
haftmann@31912
  2113
    ;
haftmann@31912
  2114
bulwahn@45409
  2115
    @@{command (HOL) values} modes? @{syntax nat}? @{syntax term}
bulwahn@45409
  2116
    ;
bulwahn@45409
  2117
blanchet@49993
  2118
    (@@{command (HOL) quickcheck} | @@{command (HOL) nitpick})
wenzelm@42596
  2119
      ( '[' args ']' )? @{syntax nat}?
haftmann@31912
  2120
    ;
haftmann@31912
  2121
blanchet@49993
  2122
    (@@{command (HOL) quickcheck_params} |
wenzelm@42596
  2123
      @@{command (HOL) nitpick_params}) ( '[' args ']' )?
haftmann@31912
  2124
    ;
bulwahn@46592
  2125
wenzelm@55029
  2126
    @@{command (HOL) quickcheck_generator} @{syntax nameref} \<newline>
bulwahn@45943
  2127
      'operations:' ( @{syntax term} +)
bulwahn@45943
  2128
    ;
haftmann@31912
  2129
wenzelm@46628
  2130
    @@{command (HOL) find_unused_assms} @{syntax name}?
bulwahn@46592
  2131
    ;
wenzelm@42596
  2132
    modes: '(' (@{syntax name} +) ')'
haftmann@31912
  2133
    ;
wenzelm@42596
  2134
    args: ( @{syntax name} '=' value + ',' )
wenzelm@55112
  2135
  \<close>} % FIXME check "value"
haftmann@31912
  2136
haftmann@31912
  2137
  \begin{description}
haftmann@31912
  2138
haftmann@31912
  2139
  \item @{command (HOL) "value"}~@{text t} evaluates and prints a
wenzelm@46283
  2140
  term; optionally @{text modes} can be specified, which are appended
wenzelm@46283
  2141
  to the current print mode; see \secref{sec:print-modes}.
haftmann@56927
  2142
  Evaluation is tried first using ML, falling
haftmann@56927
  2143
  back to normalization by evaluation if this fails.
haftmann@58100
  2144
  Alternatively a specific evaluator can be selected using square
haftmann@58100
  2145
  brackets; typical evaluators use the current set of code equations
haftmann@58100
  2146
  to normalize and include @{text simp} for fully symbolic evaluation
haftmann@58100
  2147
  using the simplifier, @{text nbe} for \emph{normalization by
haftmann@58100
  2148
  evaluation} and \emph{code} for code generation in SML.
haftmann@31912
  2149
wenzelm@46283
  2150
  \item @{command (HOL) "values"}~@{text t} enumerates a set
wenzelm@46283
  2151
  comprehension by evaluation and prints its values up to the given
wenzelm@46283
  2152
  number of solutions; optionally @{text modes} can be specified,
wenzelm@46283
  2153
  which are appended to the current print mode; see
wenzelm@46283
  2154
  \secref{sec:print-modes}.
bulwahn@45409
  2155
haftmann@31912
  2156
  \item @{command (HOL) "quickcheck"} tests the current goal for
wenzelm@46283
  2157
  counterexamples using a series of assignments for its free
wenzelm@46283
  2158
  variables; by default the first subgoal is tested, an other can be
wenzelm@46283
  2159
  selected explicitly using an optional goal index.  Assignments can
Christian@52895
  2160
  be chosen exhausting the search space up to a given size, or using a
wenzelm@46283
  2161
  fixed number of random assignments in the search space, or exploring
wenzelm@46283
  2162
  the search space symbolically using narrowing.  By default,
wenzelm@46283
  2163
  quickcheck uses exhaustive testing.  A number of configuration
wenzelm@46283
  2164
  options are supported for @{command (HOL) "quickcheck"}, notably:
haftmann@31912
  2165
haftmann@31912
  2166
    \begin{description}
haftmann@31912
  2167
bulwahn@43914
  2168
    \item[@{text tester}] specifies which testing approach to apply.
wenzelm@46283
  2169
    There are three testers, @{text exhaustive}, @{text random}, and
wenzelm@46283
  2170
    @{text narrowing}.  An unknown configuration option is treated as
wenzelm@46283
  2171
    an argument to tester, making @{text "tester ="} optional.  When
wenzelm@46283
  2172
    multiple testers are given, these are applied in parallel.  If no
wenzelm@46283
  2173
    tester is specified, quickcheck uses the testers that are set
wenzelm@46283
  2174
    active, i.e., configurations @{attribute
wenzelm@46283
  2175
    quickcheck_exhaustive_active}, @{attribute
wenzelm@46283
  2176
    quickcheck_random_active}, @{attribute
wenzelm@46283
  2177
    quickcheck_narrowing_active} are set to true.
wenzelm@46283
  2178
wenzelm@40254
  2179
    \item[@{text size}] specifies the maximum size of the search space
wenzelm@40254
  2180
    for assignment values.
haftmann@31912
  2181
bulwahn@45758
  2182
    \item[@{text genuine_only}] sets quickcheck only to return genuine
wenzelm@46283
  2183
    counterexample, but not potentially spurious counterexamples due
wenzelm@46283
  2184
    to underspecified functions.
bulwahn@46498
  2185
bulwahn@46498
  2186
    \item[@{text abort_potential}] sets quickcheck to abort once it
bulwahn@46498
  2187
    found a potentially spurious counterexample and to not continue
bulwahn@46498
  2188
    to search for a further genuine counterexample.
bulwahn@46498
  2189
    For this option to be effective, the @{text genuine_only} option
bulwahn@46498
  2190
    must be set to false.
wenzelm@47859
  2191
bulwahn@42092
  2192
    \item[@{text eval}] takes a term or a list of terms and evaluates
wenzelm@46283
  2193
    these terms under the variable assignment found by quickcheck.
bulwahn@48159
  2194
    This option is currently only supported by the default
bulwahn@48159
  2195
    (exhaustive) tester.
wenzelm@42123
  2196
wenzelm@40254
  2197
    \item[@{text iterations}] sets how many sets of assignments are
wenzelm@40254
  2198
    generated for each particular size.
haftmann@31912
  2199
wenzelm@40254
  2200
    \item[@{text no_assms}] specifies whether assumptions in
wenzelm@40254
  2201
    structured proofs should be ignored.
blanchet@35331
  2202
bulwahn@47349
  2203
    \item[@{text locale}] specifies how to process conjectures in
bulwahn@47349
  2204
    a locale context, i.e., they can be interpreted or expanded.
bulwahn@47349
  2205
    The option is a whitespace-separated list of the two words
bulwahn@47349
  2206
    @{text interpret} and @{text expand}. The list determines the
wenzelm@47859
  2207
    order they are employed. The default setting is to first use
bulwahn@47349
  2208
    interpretations and then test the expanded conjecture.
bulwahn@47349
  2209
    The option is only provided as attribute declaration, but not
wenzelm@47859
  2210
    as parameter to the command.
bulwahn@47349
  2211
wenzelm@40254
  2212
    \item[@{text timeout}] sets the time limit in seconds.
bulwahn@40245
  2213
wenzelm@40254
  2214
    \item[@{text default_type}] sets the type(s) generally used to
wenzelm@40254
  2215
    instantiate type variables.
bulwahn@40245
  2216
wenzelm@40254
  2217
    \item[@{text report}] if set quickcheck reports how many tests
wenzelm@40254
  2218
    fulfilled the preconditions.
bulwahn@40245
  2219
bulwahn@46592
  2220
    \item[@{text use_subtype}] if set quickcheck automatically lifts
bulwahn@46592
  2221
    conjectures to registered subtypes if possible, and tests the
bulwahn@46592
  2222
    lifted conjecture.
bulwahn@46592
  2223
bulwahn@45766
  2224
    \item[@{text quiet}] if set quickcheck does not output anything
bulwahn@45766
  2225
    while testing.
wenzelm@47859
  2226
wenzelm@46283
  2227
    \item[@{text verbose}] if set quickcheck informs about the current
wenzelm@46283
  2228
    size and cardinality while testing.
bulwahn@40245
  2229
wenzelm@40254
  2230
    \item[@{text expect}] can be used to check if the user's
wenzelm@40254
  2231
    expectation was met (@{text no_expectation}, @{text
wenzelm@40254
  2232
    no_counterexample}, or @{text counterexample}).
bulwahn@40245
  2233
haftmann@31912
  2234
    \end{description}
haftmann@31912
  2235
wenzelm@46283
  2236
  These option can be given within square brackets.
haftmann@31912
  2237
Andreas@56363
  2238
  Using the following type classes, the testers generate values and convert
Andreas@56363
  2239
  them back into Isabelle terms for displaying counterexamples.
Andreas@56363
  2240
    \begin{description}
Andreas@56363
  2241
    \item[@{text exhaustive}] The parameters of the type classes @{class exhaustive}
Andreas@56363
  2242
      and @{class full_exhaustive} implement the testing. They take a 
Andreas@56363
  2243
      testing function as a parameter, which takes a value of type @{typ "'a"}
Andreas@56363
  2244
      and optionally produces a counterexample, and a size parameter for the test values.
Andreas@56363
  2245
      In @{class full_exhaustive}, the testing function parameter additionally 
Andreas@56363
  2246
      expects a lazy term reconstruction in the type @{typ Code_Evaluation.term}
Andreas@56363
  2247
      of the tested value.
Andreas@56363
  2248
Andreas@56363
  2249
      The canonical implementation for @{text exhaustive} testers calls the given
Andreas@56363
  2250
      testing function on all values up to the given size and stops as soon
Andreas@56363
  2251
      as a counterexample is found.
Andreas@56363
  2252
Andreas@56363
  2253
    \item[@{text random}] The operation @{const Quickcheck_Random.random}
Andreas@56363
  2254
      of the type class @{class random} generates a pseudo-random
Andreas@56363
  2255
      value of the given size and a lazy term reconstruction of the value
Andreas@56363
  2256
      in the type @{typ Code_Evaluation.term}. A pseudo-randomness generator
Andreas@56363
  2257
      is defined in theory @{theory Random}.
Andreas@56363
  2258
      
wenzelm@58552
  2259
    \item[@{text narrowing}] implements Haskell's Lazy Smallcheck @{cite "runciman-naylor-lindblad"}
Andreas@56363
  2260
      using the type classes @{class narrowing} and @{class partial_term_of}.
Andreas@56363
  2261
      Variables in the current goal are initially represented as symbolic variables.
Andreas@56363
  2262
      If the execution of the goal tries to evaluate one of them, the test engine
Andreas@56363
  2263
      replaces it with refinements provided by @{const narrowing}.
Andreas@56363
  2264
      Narrowing views every value as a sum-of-products which is expressed using the operations
Andreas@56363
  2265
      @{const Quickcheck_Narrowing.cons} (embedding a value),
Andreas@56363
  2266
      @{const Quickcheck_Narrowing.apply} (product) and @{const Quickcheck_Narrowing.sum} (sum).
Andreas@56363
  2267
      The refinement should enable further evaluation of the goal.
Andreas@56363
  2268
Andreas@56363
  2269
      For example, @{const narrowing} for the list type @{typ "'a :: narrowing list"}
Andreas@56363
  2270
      can be recursively defined as
Andreas@56363
  2271
      @{term "Quickcheck_Narrowing.sum (Quickcheck_Narrowing.cons [])
Andreas@56363
  2272
                (Quickcheck_Narrowing.apply
Andreas@56363
  2273
                  (Quickcheck_Narrowing.apply
Andreas@56363
  2274
                    (Quickcheck_Narrowing.cons (op #))
Andreas@56363
  2275
                    narrowing)
Andreas@56363
  2276
                  narrowing)"}.
Andreas@56363
  2277
      If a symbolic variable of type @{typ "_ list"} is evaluated, it is replaced by (i)~the empty
Andreas@56363
  2278
      list @{term "[]"} and (ii)~by a non-empty list whose head and tail can then be recursively
Andreas@56363
  2279
      refined if needed.
Andreas@56363
  2280
Andreas@56363
  2281
      To reconstruct counterexamples, the operation @{const partial_term_of} transforms
Andreas@56363
  2282
      @{text narrowing}'s deep representation of terms to the type @{typ Code_Evaluation.term}.
Andreas@56363
  2283
      The deep representation models symbolic variables as
Andreas@56363
  2284
      @{const Quickcheck_Narrowing.Narrowing_variable}, which are normally converted to
Andreas@56363
  2285
      @{const Code_Evaluation.Free}, and refined values as
Andreas@56363
  2286
      @{term "Quickcheck_Narrowing.Narrowing_constructor i args"}, where @{term "i :: integer"}
Andreas@56363
  2287
      denotes the index in the sum of refinements. In the above example for lists,
Andreas@56363
  2288
      @{term "0"} corresponds to @{term "[]"} and @{term "1"}
Andreas@56363
  2289
      to @{term "op #"}.
Andreas@56363
  2290
Andreas@56363
  2291
      The command @{command (HOL) "code_datatype"} sets up @{const partial_term_of}
Andreas@56363
  2292
      such that the @{term "i"}-th refinement is interpreted as the @{term "i"}-th constructor,
Andreas@56363
  2293
      but it does not ensures consistency with @{const narrowing}.
Andreas@56363
  2294
    \end{description}
Andreas@56363
  2295
wenzelm@46283
  2296
  \item @{command (HOL) "quickcheck_params"} changes @{command (HOL)
wenzelm@46283
  2297
  "quickcheck"} configuration options persistently.
blanchet@42215
  2298
bulwahn@45943
  2299
  \item @{command (HOL) "quickcheck_generator"} creates random and
wenzelm@46283
  2300
  exhaustive value generators for a given type and operations.  It
wenzelm@46283
  2301
  generates values by using the operations as if they were
wenzelm@46283
  2302
  constructors of that type.
bulwahn@45943
  2303
wenzelm@46283
  2304
  \item @{command (HOL) "nitpick"} tests the current goal for
wenzelm@46283
  2305
  counterexamples using a reduction to first-order relational
wenzelm@58552
  2306
  logic. See the Nitpick manual @{cite "isabelle-nitpick"} for details.
blanchet@42215
  2307
wenzelm@46283
  2308
  \item @{command (HOL) "nitpick_params"} changes @{command (HOL)
wenzelm@46283
  2309
  "nitpick"} configuration options persistently.
haftmann@31912
  2310
bulwahn@46592
  2311
  \item @{command (HOL) "find_unused_assms"} finds potentially superfluous
bulwahn@46592
  2312
  assumptions in theorems using quickcheck.
bulwahn@46592
  2313
  It takes the theory name to be checked for superfluous assumptions as
bulwahn@46592
  2314
  optional argument. If not provided, it checks the current theory.
bulwahn@46592
  2315
  Options to the internal quickcheck invocations can be changed with
bulwahn@46592
  2316
  common configuration declarations.
bulwahn@46592
  2317
haftmann@31912
  2318
  \end{description}
wenzelm@58618
  2319
\<close>
wenzelm@58618
  2320
wenzelm@58618
  2321
wenzelm@58618
  2322
section \<open>Unstructured case analysis and induction \label{sec:hol-induct-tac}\<close>
wenzelm@58618
  2323
wenzelm@58618
  2324
text \<open>
wenzelm@27123
  2325
  The following tools of Isabelle/HOL support cases analysis and
wenzelm@27123
  2326
  induction in unstructured tactic scripts; see also
wenzelm@27123
  2327
  \secref{sec:cases-induct} for proper Isar versions of similar ideas.
wenzelm@26849
  2328
wenzelm@26849
  2329
  \begin{matharray}{rcl}
wenzelm@28761
  2330
    @{method_def (HOL) case_tac}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
  2331
    @{method_def (HOL) induct_tac}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
  2332
    @{method_def (HOL) ind_cases}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
  2333
    @{command_def (HOL) "inductive_cases"}@{text "\<^sup>*"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@26849
  2334
  \end{matharray}
wenzelm@26849
  2335
wenzelm@55112
  2336
  @{rail \<open>
wenzelm@42705
  2337
    @@{method (HOL) case_tac} @{syntax goal_spec}? @{syntax term} rule?
wenzelm@26849
  2338
    ;
wenzelm@42705
  2339
    @@{method (HOL) induct_tac} @{syntax goal_spec}? (@{syntax insts} * @'and') rule?
wenzelm@26849
  2340
    ;
wenzelm@42596
  2341
    @@{method (HOL) ind_cases} (@{syntax prop}+) (@'for' (@{syntax name}+))?
wenzelm@26849
  2342
    ;
wenzelm@42596
  2343
    @@{command (HOL) inductive_cases} (@{syntax thmdecl}? (@{syntax prop}+) + @'and')
wenzelm@26849
  2344
    ;
wenzelm@42596
  2345
    rule: 'rule' ':' @{syntax thmref}
wenzelm@55112
  2346
  \<close>}
wenzelm@26849
  2347
wenzelm@28760
  2348
  \begin{description}
wenzelm@26849
  2349
wenzelm@28760
  2350
  \item @{method (HOL) case_tac} and @{method (HOL) induct_tac} admit
wenzelm@28760
  2351
  to reason about inductive types.  Rules are selected according to
wenzelm@28760
  2352
  the declarations by the @{attribute cases} and @{attribute induct}
wenzelm@28760
  2353
  attributes, cf.\ \secref{sec:cases-induct}.  The @{command (HOL)
blanchet@58310
  2354
  datatype} package already takes care of this.
wenzelm@27123
  2355
wenzelm@27123
  2356
  These unstructured tactics feature both goal addressing and dynamic
wenzelm@26849
  2357
  instantiation.  Note that named rule cases are \emph{not} provided
wenzelm@27123
  2358
  as would be by the proper @{method cases} and @{method induct} proof
wenzelm@27123
  2359
  methods (see \secref{sec:cases-induct}).  Unlike the @{method
wenzelm@27123
  2360
  induct} method, @{method induct_tac} does not handle structured rule
wenzelm@27123
  2361
  statements, only the compact object-logic conclusion of the subgoal
wenzelm@27123
  2362
  being addressed.
wenzelm@42123
  2363
wenzelm@28760
  2364
  \item @{method (HOL) ind_cases} and @{command (HOL)
wenzelm@28760
  2365
  "inductive_cases"} provide an interface to the internal @{ML_text
wenzelm@26860
  2366
  mk_cases} operation.  Rules are simplified in an unrestricted
wenzelm@26860
  2367
  forward manner.
wenzelm@26849
  2368
wenzelm@26849
  2369
  While @{method (HOL) ind_cases} is a proof method to apply the
wenzelm@26849
  2370
  result immediately as elimination rules, @{command (HOL)
wenzelm@26849
  2371
  "inductive_cases"} provides case split theorems at the theory level
wenzelm@26849
  2372
  for later use.  The @{keyword "for"} argument of the @{method (HOL)
wenzelm@26849
  2373
  ind_cases} method allows to specify a list of variables that should
wenzelm@26849
  2374
  be generalized before applying the resulting rule.
wenzelm@26849
  2375
wenzelm@28760
  2376
  \end{description}
wenzelm@58618
  2377
\<close>
wenzelm@58618
  2378
wenzelm@58618
  2379
wenzelm@58618
  2380
chapter \<open>Executable code\<close>
wenzelm@58618
  2381
wenzelm@58618
  2382
text \<open>For validation purposes, it is often useful to \emph{execute}
wenzelm@42627
  2383
  specifications.  In principle, execution could be simulated by
wenzelm@42627
  2384
  Isabelle's inference kernel, i.e. by a combination of resolution and
wenzelm@42627
  2385
  simplification.  Unfortunately, this approach is rather inefficient.
wenzelm@42627
  2386
  A more efficient way of executing specifications is to translate
wenzelm@42627
  2387
  them into a functional programming language such as ML.
wenzelm@26849
  2388
wenzelm@45192
  2389
  Isabelle provides a generic framework to support code generation
wenzelm@42627
  2390
  from executable specifications.  Isabelle/HOL instantiates these
wenzelm@45192
  2391
  mechanisms in a way that is amenable to end-user applications.  Code
wenzelm@45192
  2392
  can be generated for functional programs (including overloading
wenzelm@58552
  2393
  using type classes) targeting SML @{cite SML}, OCaml @{cite OCaml},
wenzelm@58552
  2394
  Haskell @{cite "haskell-revised-report"} and Scala
wenzelm@58552
  2395
  @{cite "scala-overview-tech-report"}.  Conceptually, code generation is
wenzelm@42627
  2396
  split up in three steps: \emph{selection} of code theorems,
wenzelm@42627
  2397
  \emph{translation} into an abstract executable view and
wenzelm@42627
  2398
  \emph{serialization} to a specific \emph{target language}.
wenzelm@42627
  2399
  Inductive specifications can be executed using the predicate
wenzelm@58552
  2400
  compiler which operates within HOL.  See @{cite "isabelle-codegen"} for
wenzelm@42627
  2401
  an introduction.
haftmann@37422
  2402
haftmann@37422
  2403
  \begin{matharray}{rcl}
haftmann@37422
  2404
    @{command_def (HOL) "export_code"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  2405
    @{attribute_def (HOL) code} & : & @{text attribute} \\
haftmann@37422
  2406
    @{command_def (HOL) "code_datatype"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  2407
    @{command_def (HOL) "print_codesetup"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
bulwahn@45232
  2408
    @{attribute_def (HOL) code_unfold} & : & @{text attribute} \\
haftmann@37422
  2409
    @{attribute_def (HOL) code_post} & : & @{text attribute} \\
haftmann@46028
  2410
    @{attribute_def (HOL) code_abbrev} & : & @{text attribute} \\
haftmann@37422
  2411
    @{command_def (HOL) "print_codeproc"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  2412
    @{command_def (HOL) "code_thms"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  2413
    @{command_def (HOL) "code_deps"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@52378
  2414
    @{command_def (HOL) "code_reserved"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@52378
  2415
    @{command_def (HOL) "code_printing"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@52378
  2416
    @{command_def (HOL) "code_identifier"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  2417
    @{command_def (HOL) "code_monad"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45408
  2418
    @{command_def (HOL) "code_reflect"} & : & @{text "theory \<rightarrow> theory"} \\
bulwahn@45408
  2419
    @{command_def (HOL) "code_pred"} & : & @{text "theory \<rightarrow> proof(prove)"}
haftmann@37422
  2420
  \end{matharray}
haftmann@37422
  2421
wenzelm@55112
  2422
  @{rail \<open>
haftmann@55686
  2423
    @@{command (HOL) export_code} ( @'open' ) ? ( constexpr + ) \<newline>
wenzelm@55029
  2424
       ( ( @'in' target ( @'module_name' @{syntax string} ) ? \<newline>
haftmann@52435<