doc-src/IsarRef/Thy/HOL_Specific.thy
author haftmann
Fri Nov 26 12:03:18 2010 +0100 (2010-11-26)
changeset 40711 81bc73585eec
parent 40709 b29c70cd5c93
child 40800 330eb65c9469
permissions -rw-r--r--
globbing constant expressions use more idiomatic underscore rather than star
wenzelm@26840
     1
theory HOL_Specific
wenzelm@26849
     2
imports Main
wenzelm@26840
     3
begin
wenzelm@26840
     4
wenzelm@26852
     5
chapter {* Isabelle/HOL \label{ch:hol} *}
wenzelm@26849
     6
wenzelm@35744
     7
section {* Typedef axiomatization \label{sec:hol-typedef} *}
wenzelm@26849
     8
wenzelm@26849
     9
text {*
wenzelm@26849
    10
  \begin{matharray}{rcl}
wenzelm@35744
    11
    @{command_def (HOL) "typedef"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@26849
    12
  \end{matharray}
wenzelm@26849
    13
wenzelm@26849
    14
  \begin{rail}
wenzelm@26849
    15
    'typedef' altname? abstype '=' repset
wenzelm@26849
    16
    ;
wenzelm@26849
    17
wenzelm@26849
    18
    altname: '(' (name | 'open' | 'open' name) ')'
wenzelm@26849
    19
    ;
wenzelm@35841
    20
    abstype: typespecsorts mixfix?
wenzelm@26849
    21
    ;
wenzelm@26849
    22
    repset: term ('morphisms' name name)?
wenzelm@26849
    23
    ;
wenzelm@26849
    24
  \end{rail}
wenzelm@26849
    25
wenzelm@28760
    26
  \begin{description}
wenzelm@26849
    27
  
wenzelm@35744
    28
  \item @{command (HOL) "typedef"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t = A"}
wenzelm@35744
    29
  axiomatizes a Gordon/HOL-style type definition in the background
wenzelm@35744
    30
  theory of the current context, depending on a non-emptiness result
wenzelm@35744
    31
  of the set @{text A} (which needs to be proven interactively).
wenzelm@35744
    32
wenzelm@35744
    33
  The raw type may not depend on parameters or assumptions of the
wenzelm@35744
    34
  context --- this is logically impossible in Isabelle/HOL --- but the
wenzelm@35744
    35
  non-emptiness property can be local, potentially resulting in
wenzelm@35744
    36
  multiple interpretations in target contexts.  Thus the established
wenzelm@35744
    37
  bijection between the representing set @{text A} and the new type
wenzelm@35744
    38
  @{text t} may semantically depend on local assumptions.
wenzelm@26849
    39
  
wenzelm@35744
    40
  By default, @{command (HOL) "typedef"} defines both a type @{text t}
wenzelm@35744
    41
  and a set (term constant) of the same name, unless an alternative
wenzelm@35744
    42
  base name is given in parentheses, or the ``@{text "(open)"}''
wenzelm@35744
    43
  declaration is used to suppress a separate constant definition
wenzelm@35744
    44
  altogether.  The injection from type to set is called @{text Rep_t},
wenzelm@35744
    45
  its inverse @{text Abs_t} --- this may be changed via an explicit
wenzelm@35744
    46
  @{keyword (HOL) "morphisms"} declaration.
wenzelm@26849
    47
  
wenzelm@26849
    48
  Theorems @{text Rep_t}, @{text Rep_t_inverse}, and @{text
wenzelm@26849
    49
  Abs_t_inverse} provide the most basic characterization as a
wenzelm@26849
    50
  corresponding injection/surjection pair (in both directions).  Rules
wenzelm@26849
    51
  @{text Rep_t_inject} and @{text Abs_t_inject} provide a slightly
wenzelm@26849
    52
  more convenient view on the injectivity part, suitable for automated
wenzelm@26894
    53
  proof tools (e.g.\ in @{attribute simp} or @{attribute iff}
wenzelm@26894
    54
  declarations).  Rules @{text Rep_t_cases}/@{text Rep_t_induct}, and
wenzelm@26894
    55
  @{text Abs_t_cases}/@{text Abs_t_induct} provide alternative views
wenzelm@26894
    56
  on surjectivity; these are already declared as set or type rules for
wenzelm@26849
    57
  the generic @{method cases} and @{method induct} methods.
wenzelm@26849
    58
  
wenzelm@35744
    59
  An alternative name for the set definition (and other derived
wenzelm@35744
    60
  entities) may be specified in parentheses; the default is to use
wenzelm@35744
    61
  @{text t} as indicated before.
wenzelm@26849
    62
wenzelm@28760
    63
  \end{description}
wenzelm@26849
    64
*}
wenzelm@26849
    65
wenzelm@26849
    66
wenzelm@26849
    67
section {* Adhoc tuples *}
wenzelm@26849
    68
wenzelm@26849
    69
text {*
wenzelm@26849
    70
  \begin{matharray}{rcl}
wenzelm@28761
    71
    @{attribute (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
wenzelm@26849
    72
  \end{matharray}
wenzelm@26849
    73
wenzelm@26849
    74
  \begin{rail}
krauss@40388
    75
    'split_format' '(' 'complete' ')'
wenzelm@26849
    76
    ;
wenzelm@26849
    77
  \end{rail}
wenzelm@26849
    78
wenzelm@28760
    79
  \begin{description}
wenzelm@26849
    80
  
krauss@40388
    81
  \item @{attribute (HOL) split_format}\ @{text "(complete)"} causes
wenzelm@28760
    82
  arguments in function applications to be represented canonically
wenzelm@28760
    83
  according to their tuple type structure.
wenzelm@26849
    84
krauss@40388
    85
  Note that this operation tends to invent funny names for new local
krauss@40388
    86
  parameters introduced.
wenzelm@26849
    87
wenzelm@28760
    88
  \end{description}
wenzelm@26849
    89
*}
wenzelm@26849
    90
wenzelm@26849
    91
wenzelm@26849
    92
section {* Records \label{sec:hol-record} *}
wenzelm@26849
    93
wenzelm@26849
    94
text {*
wenzelm@26849
    95
  In principle, records merely generalize the concept of tuples, where
wenzelm@26849
    96
  components may be addressed by labels instead of just position.  The
wenzelm@26849
    97
  logical infrastructure of records in Isabelle/HOL is slightly more
wenzelm@26849
    98
  advanced, though, supporting truly extensible record schemes.  This
wenzelm@26849
    99
  admits operations that are polymorphic with respect to record
wenzelm@26849
   100
  extension, yielding ``object-oriented'' effects like (single)
wenzelm@26849
   101
  inheritance.  See also \cite{NaraschewskiW-TPHOLs98} for more
wenzelm@26849
   102
  details on object-oriented verification and record subtyping in HOL.
wenzelm@26849
   103
*}
wenzelm@26849
   104
wenzelm@26849
   105
wenzelm@26849
   106
subsection {* Basic concepts *}
wenzelm@26849
   107
wenzelm@26849
   108
text {*
wenzelm@26849
   109
  Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
wenzelm@26849
   110
  at the level of terms and types.  The notation is as follows:
wenzelm@26849
   111
wenzelm@26849
   112
  \begin{center}
wenzelm@26849
   113
  \begin{tabular}{l|l|l}
wenzelm@26849
   114
    & record terms & record types \\ \hline
wenzelm@26849
   115
    fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
wenzelm@26849
   116
    schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
wenzelm@26849
   117
      @{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
wenzelm@26849
   118
  \end{tabular}
wenzelm@26849
   119
  \end{center}
wenzelm@26849
   120
wenzelm@26849
   121
  \noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
wenzelm@26849
   122
  "(| x = a |)"}.
wenzelm@26849
   123
wenzelm@26849
   124
  A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
wenzelm@26849
   125
  @{text a} and field @{text y} of value @{text b}.  The corresponding
wenzelm@26849
   126
  type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
wenzelm@26849
   127
  and @{text "b :: B"}.
wenzelm@26849
   128
wenzelm@26849
   129
  A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
wenzelm@26849
   130
  @{text x} and @{text y} as before, but also possibly further fields
wenzelm@26849
   131
  as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
wenzelm@26849
   132
  of the syntax).  The improper field ``@{text "\<dots>"}'' of a record
wenzelm@26849
   133
  scheme is called the \emph{more part}.  Logically it is just a free
wenzelm@26849
   134
  variable, which is occasionally referred to as ``row variable'' in
wenzelm@26849
   135
  the literature.  The more part of a record scheme may be
wenzelm@26849
   136
  instantiated by zero or more further components.  For example, the
wenzelm@26849
   137
  previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
wenzelm@26852
   138
  c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
wenzelm@26849
   139
  Fixed records are special instances of record schemes, where
wenzelm@26849
   140
  ``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
wenzelm@26849
   141
  element.  In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
wenzelm@26849
   142
  for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
wenzelm@26849
   143
  
wenzelm@26849
   144
  \medskip Two key observations make extensible records in a simply
wenzelm@26849
   145
  typed language like HOL work out:
wenzelm@26849
   146
wenzelm@26849
   147
  \begin{enumerate}
wenzelm@26849
   148
wenzelm@26849
   149
  \item the more part is internalized, as a free term or type
wenzelm@26849
   150
  variable,
wenzelm@26849
   151
wenzelm@26852
   152
  \item field names are externalized, they cannot be accessed within
wenzelm@26852
   153
  the logic as first-class values.
wenzelm@26849
   154
wenzelm@26849
   155
  \end{enumerate}
wenzelm@26849
   156
wenzelm@26849
   157
  \medskip In Isabelle/HOL record types have to be defined explicitly,
wenzelm@26849
   158
  fixing their field names and types, and their (optional) parent
wenzelm@26849
   159
  record.  Afterwards, records may be formed using above syntax, while
wenzelm@26849
   160
  obeying the canonical order of fields as given by their declaration.
wenzelm@26849
   161
  The record package provides several standard operations like
wenzelm@26849
   162
  selectors and updates.  The common setup for various generic proof
wenzelm@26849
   163
  tools enable succinct reasoning patterns.  See also the Isabelle/HOL
wenzelm@26849
   164
  tutorial \cite{isabelle-hol-book} for further instructions on using
wenzelm@26849
   165
  records in practice.
wenzelm@26849
   166
*}
wenzelm@26849
   167
wenzelm@26849
   168
wenzelm@26849
   169
subsection {* Record specifications *}
wenzelm@26849
   170
wenzelm@26849
   171
text {*
wenzelm@26849
   172
  \begin{matharray}{rcl}
wenzelm@28761
   173
    @{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@26849
   174
  \end{matharray}
wenzelm@26849
   175
wenzelm@26849
   176
  \begin{rail}
wenzelm@36158
   177
    'record' typespecsorts '=' (type '+')? (constdecl +)
wenzelm@26849
   178
    ;
wenzelm@26849
   179
  \end{rail}
wenzelm@26849
   180
wenzelm@28760
   181
  \begin{description}
wenzelm@26849
   182
wenzelm@28760
   183
  \item @{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1
wenzelm@28760
   184
  \<dots> c\<^sub>n :: \<sigma>\<^sub>n"} defines extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
wenzelm@26849
   185
  derived from the optional parent record @{text "\<tau>"} by adding new
wenzelm@26849
   186
  field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
wenzelm@26849
   187
wenzelm@26849
   188
  The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
wenzelm@26849
   189
  covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
wenzelm@26849
   190
  \<alpha>\<^sub>m"}.  Type constructor @{text t} has to be new, while @{text
wenzelm@26849
   191
  \<tau>} needs to specify an instance of an existing record type.  At
wenzelm@26849
   192
  least one new field @{text "c\<^sub>i"} has to be specified.
wenzelm@26849
   193
  Basically, field names need to belong to a unique record.  This is
wenzelm@26849
   194
  not a real restriction in practice, since fields are qualified by
wenzelm@26849
   195
  the record name internally.
wenzelm@26849
   196
wenzelm@26849
   197
  The parent record specification @{text \<tau>} is optional; if omitted
wenzelm@26849
   198
  @{text t} becomes a root record.  The hierarchy of all records
wenzelm@26849
   199
  declared within a theory context forms a forest structure, i.e.\ a
wenzelm@26849
   200
  set of trees starting with a root record each.  There is no way to
wenzelm@26849
   201
  merge multiple parent records!
wenzelm@26849
   202
wenzelm@26849
   203
  For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
wenzelm@26849
   204
  type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
wenzelm@26849
   205
  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
wenzelm@26849
   206
  "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
wenzelm@26849
   207
  @{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
wenzelm@26849
   208
  \<zeta>\<rparr>"}.
wenzelm@26849
   209
wenzelm@28760
   210
  \end{description}
wenzelm@26849
   211
*}
wenzelm@26849
   212
wenzelm@26849
   213
wenzelm@26849
   214
subsection {* Record operations *}
wenzelm@26849
   215
wenzelm@26849
   216
text {*
wenzelm@26849
   217
  Any record definition of the form presented above produces certain
wenzelm@26849
   218
  standard operations.  Selectors and updates are provided for any
wenzelm@26849
   219
  field, including the improper one ``@{text more}''.  There are also
wenzelm@26849
   220
  cumulative record constructor functions.  To simplify the
wenzelm@26849
   221
  presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
wenzelm@26849
   222
  \<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
wenzelm@26849
   223
  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
wenzelm@26849
   224
wenzelm@26849
   225
  \medskip \textbf{Selectors} and \textbf{updates} are available for
wenzelm@26849
   226
  any field (including ``@{text more}''):
wenzelm@26849
   227
wenzelm@26849
   228
  \begin{matharray}{lll}
wenzelm@26852
   229
    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
wenzelm@26852
   230
    @{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
   231
  \end{matharray}
wenzelm@26849
   232
wenzelm@26849
   233
  There is special syntax for application of updates: @{text "r\<lparr>x :=
wenzelm@26849
   234
  a\<rparr>"} abbreviates term @{text "x_update a r"}.  Further notation for
wenzelm@26849
   235
  repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
wenzelm@26849
   236
  c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}.  Note that
wenzelm@26849
   237
  because of postfix notation the order of fields shown here is
wenzelm@26849
   238
  reverse than in the actual term.  Since repeated updates are just
wenzelm@26849
   239
  function applications, fields may be freely permuted in @{text "\<lparr>x
wenzelm@26849
   240
  := a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
wenzelm@26849
   241
  Thus commutativity of independent updates can be proven within the
wenzelm@26849
   242
  logic for any two fields, but not as a general theorem.
wenzelm@26849
   243
wenzelm@26849
   244
  \medskip The \textbf{make} operation provides a cumulative record
wenzelm@26849
   245
  constructor function:
wenzelm@26849
   246
wenzelm@26849
   247
  \begin{matharray}{lll}
wenzelm@26852
   248
    @{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26849
   249
  \end{matharray}
wenzelm@26849
   250
wenzelm@26849
   251
  \medskip We now reconsider the case of non-root records, which are
wenzelm@26849
   252
  derived of some parent.  In general, the latter may depend on
wenzelm@26849
   253
  another parent as well, resulting in a list of \emph{ancestor
wenzelm@26849
   254
  records}.  Appending the lists of fields of all ancestors results in
wenzelm@26849
   255
  a certain field prefix.  The record package automatically takes care
wenzelm@26849
   256
  of this by lifting operations over this context of ancestor fields.
wenzelm@26849
   257
  Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
wenzelm@26849
   258
  fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
wenzelm@26849
   259
  the above record operations will get the following types:
wenzelm@26849
   260
wenzelm@26852
   261
  \medskip
wenzelm@26852
   262
  \begin{tabular}{lll}
wenzelm@26852
   263
    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
wenzelm@26849
   264
    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow> 
wenzelm@26852
   265
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
wenzelm@26852
   266
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
wenzelm@26852
   267
    @{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
   268
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26852
   269
  \end{tabular}
wenzelm@26852
   270
  \medskip
wenzelm@26849
   271
wenzelm@26852
   272
  \noindent Some further operations address the extension aspect of a
wenzelm@26849
   273
  derived record scheme specifically: @{text "t.fields"} produces a
wenzelm@26849
   274
  record fragment consisting of exactly the new fields introduced here
wenzelm@26849
   275
  (the result may serve as a more part elsewhere); @{text "t.extend"}
wenzelm@26849
   276
  takes a fixed record and adds a given more part; @{text
wenzelm@26849
   277
  "t.truncate"} restricts a record scheme to a fixed record.
wenzelm@26849
   278
wenzelm@26852
   279
  \medskip
wenzelm@26852
   280
  \begin{tabular}{lll}
wenzelm@26852
   281
    @{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26852
   282
    @{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
wenzelm@26852
   283
      \<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
wenzelm@26852
   284
    @{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
   285
  \end{tabular}
wenzelm@26852
   286
  \medskip
wenzelm@26849
   287
wenzelm@26849
   288
  \noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
wenzelm@26849
   289
  for root records.
wenzelm@26849
   290
*}
wenzelm@26849
   291
wenzelm@26849
   292
wenzelm@26849
   293
subsection {* Derived rules and proof tools *}
wenzelm@26849
   294
wenzelm@26849
   295
text {*
wenzelm@26849
   296
  The record package proves several results internally, declaring
wenzelm@26849
   297
  these facts to appropriate proof tools.  This enables users to
wenzelm@26849
   298
  reason about record structures quite conveniently.  Assume that
wenzelm@26849
   299
  @{text t} is a record type as specified above.
wenzelm@26849
   300
wenzelm@26849
   301
  \begin{enumerate}
wenzelm@26849
   302
  
wenzelm@26849
   303
  \item Standard conversions for selectors or updates applied to
wenzelm@26849
   304
  record constructor terms are made part of the default Simplifier
wenzelm@26849
   305
  context; thus proofs by reduction of basic operations merely require
wenzelm@26849
   306
  the @{method simp} method without further arguments.  These rules
wenzelm@26849
   307
  are available as @{text "t.simps"}, too.
wenzelm@26849
   308
  
wenzelm@26849
   309
  \item Selectors applied to updated records are automatically reduced
wenzelm@26849
   310
  by an internal simplification procedure, which is also part of the
wenzelm@26849
   311
  standard Simplifier setup.
wenzelm@26849
   312
wenzelm@26849
   313
  \item Inject equations of a form analogous to @{prop "(x, y) = (x',
wenzelm@26849
   314
  y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
wenzelm@26849
   315
  Reasoner as @{attribute iff} rules.  These rules are available as
wenzelm@26849
   316
  @{text "t.iffs"}.
wenzelm@26849
   317
wenzelm@26849
   318
  \item The introduction rule for record equality analogous to @{text
wenzelm@26849
   319
  "x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
wenzelm@26849
   320
  and as the basic rule context as ``@{attribute intro}@{text "?"}''.
wenzelm@26849
   321
  The rule is called @{text "t.equality"}.
wenzelm@26849
   322
wenzelm@26849
   323
  \item Representations of arbitrary record expressions as canonical
wenzelm@26849
   324
  constructor terms are provided both in @{method cases} and @{method
wenzelm@26849
   325
  induct} format (cf.\ the generic proof methods of the same name,
wenzelm@26849
   326
  \secref{sec:cases-induct}).  Several variations are available, for
wenzelm@26849
   327
  fixed records, record schemes, more parts etc.
wenzelm@26849
   328
  
wenzelm@26849
   329
  The generic proof methods are sufficiently smart to pick the most
wenzelm@26849
   330
  sensible rule according to the type of the indicated record
wenzelm@26849
   331
  expression: users just need to apply something like ``@{text "(cases
wenzelm@26849
   332
  r)"}'' to a certain proof problem.
wenzelm@26849
   333
wenzelm@26849
   334
  \item The derived record operations @{text "t.make"}, @{text
wenzelm@26849
   335
  "t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
wenzelm@26849
   336
  treated automatically, but usually need to be expanded by hand,
wenzelm@26849
   337
  using the collective fact @{text "t.defs"}.
wenzelm@26849
   338
wenzelm@26849
   339
  \end{enumerate}
wenzelm@26849
   340
*}
wenzelm@26849
   341
wenzelm@26849
   342
wenzelm@26849
   343
section {* Datatypes \label{sec:hol-datatype} *}
wenzelm@26849
   344
wenzelm@26849
   345
text {*
wenzelm@26849
   346
  \begin{matharray}{rcl}
wenzelm@28761
   347
    @{command_def (HOL) "datatype"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@28761
   348
  @{command_def (HOL) "rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@26849
   349
  \end{matharray}
wenzelm@26849
   350
wenzelm@26849
   351
  \begin{rail}
wenzelm@26849
   352
    'datatype' (dtspec + 'and')
wenzelm@26849
   353
    ;
wenzelm@40255
   354
    'rep_datatype' ('(' (name +) ')')? (term +)
wenzelm@26849
   355
    ;
wenzelm@26849
   356
wenzelm@35351
   357
    dtspec: parname? typespec mixfix? '=' (cons + '|')
wenzelm@26849
   358
    ;
haftmann@31912
   359
    cons: name ( type * ) mixfix?
wenzelm@26849
   360
  \end{rail}
wenzelm@26849
   361
wenzelm@28760
   362
  \begin{description}
wenzelm@26849
   363
wenzelm@28760
   364
  \item @{command (HOL) "datatype"} defines inductive datatypes in
wenzelm@26849
   365
  HOL.
wenzelm@26849
   366
wenzelm@28760
   367
  \item @{command (HOL) "rep_datatype"} represents existing types as
wenzelm@26849
   368
  inductive ones, generating the standard infrastructure of derived
wenzelm@26849
   369
  concepts (primitive recursion etc.).
wenzelm@26849
   370
wenzelm@28760
   371
  \end{description}
wenzelm@26849
   372
wenzelm@26849
   373
  The induction and exhaustion theorems generated provide case names
wenzelm@26849
   374
  according to the constructors involved, while parameters are named
wenzelm@26849
   375
  after the types (see also \secref{sec:cases-induct}).
wenzelm@26849
   376
wenzelm@26849
   377
  See \cite{isabelle-HOL} for more details on datatypes, but beware of
wenzelm@26849
   378
  the old-style theory syntax being used there!  Apart from proper
wenzelm@26849
   379
  proof methods for case-analysis and induction, there are also
wenzelm@26849
   380
  emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
wenzelm@26849
   381
  induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
wenzelm@26849
   382
  to refer directly to the internal structure of subgoals (including
wenzelm@26849
   383
  internally bound parameters).
wenzelm@26849
   384
*}
wenzelm@26849
   385
wenzelm@26849
   386
wenzelm@26849
   387
section {* Recursive functions \label{sec:recursion} *}
wenzelm@26849
   388
wenzelm@26849
   389
text {*
wenzelm@26849
   390
  \begin{matharray}{rcl}
wenzelm@28761
   391
    @{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@28761
   392
    @{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@28761
   393
    @{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@28761
   394
    @{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
wenzelm@26849
   395
  \end{matharray}
wenzelm@26849
   396
wenzelm@26849
   397
  \begin{rail}
wenzelm@26849
   398
    'primrec' target? fixes 'where' equations
wenzelm@26849
   399
    ;
krauss@40170
   400
    ('fun' | 'function') target? functionopts? fixes \\ 'where' equations
wenzelm@26849
   401
    ;
krauss@40170
   402
    equations: (thmdecl? prop + '|')
wenzelm@26849
   403
    ;
wenzelm@26985
   404
    functionopts: '(' (('sequential' | 'domintros' | 'tailrec' | 'default' term) + ',') ')'
wenzelm@26849
   405
    ;
wenzelm@26849
   406
    'termination' ( term )?
wenzelm@26849
   407
  \end{rail}
wenzelm@26849
   408
wenzelm@28760
   409
  \begin{description}
wenzelm@26849
   410
wenzelm@28760
   411
  \item @{command (HOL) "primrec"} defines primitive recursive
wenzelm@26849
   412
  functions over datatypes, see also \cite{isabelle-HOL}.
wenzelm@26849
   413
wenzelm@28760
   414
  \item @{command (HOL) "function"} defines functions by general
wenzelm@26849
   415
  wellfounded recursion. A detailed description with examples can be
wenzelm@26849
   416
  found in \cite{isabelle-function}. The function is specified by a
wenzelm@26849
   417
  set of (possibly conditional) recursive equations with arbitrary
wenzelm@26849
   418
  pattern matching. The command generates proof obligations for the
wenzelm@26849
   419
  completeness and the compatibility of patterns.
wenzelm@26849
   420
wenzelm@26849
   421
  The defined function is considered partial, and the resulting
wenzelm@26849
   422
  simplification rules (named @{text "f.psimps"}) and induction rule
wenzelm@26849
   423
  (named @{text "f.pinduct"}) are guarded by a generated domain
wenzelm@26849
   424
  predicate @{text "f_dom"}. The @{command (HOL) "termination"}
wenzelm@26849
   425
  command can then be used to establish that the function is total.
wenzelm@26849
   426
wenzelm@28760
   427
  \item @{command (HOL) "fun"} is a shorthand notation for ``@{command
wenzelm@28760
   428
  (HOL) "function"}~@{text "(sequential)"}, followed by automated
wenzelm@28760
   429
  proof attempts regarding pattern matching and termination.  See
wenzelm@28760
   430
  \cite{isabelle-function} for further details.
wenzelm@26849
   431
wenzelm@28760
   432
  \item @{command (HOL) "termination"}~@{text f} commences a
wenzelm@26849
   433
  termination proof for the previously defined function @{text f}.  If
wenzelm@26849
   434
  this is omitted, the command refers to the most recent function
wenzelm@26849
   435
  definition.  After the proof is closed, the recursive equations and
wenzelm@26849
   436
  the induction principle is established.
wenzelm@26849
   437
wenzelm@28760
   438
  \end{description}
wenzelm@26849
   439
haftmann@27452
   440
  Recursive definitions introduced by the @{command (HOL) "function"}
haftmann@27452
   441
  command accommodate
wenzelm@26849
   442
  reasoning by induction (cf.\ \secref{sec:cases-induct}): rule @{text
wenzelm@26849
   443
  "c.induct"} (where @{text c} is the name of the function definition)
wenzelm@26849
   444
  refers to a specific induction rule, with parameters named according
krauss@33857
   445
  to the user-specified equations. Cases are numbered (starting from 1).
krauss@33857
   446
krauss@33857
   447
  For @{command (HOL) "primrec"}, the induction principle coincides
haftmann@27452
   448
  with structural recursion on the datatype the recursion is carried
haftmann@27452
   449
  out.
wenzelm@26849
   450
wenzelm@26849
   451
  The equations provided by these packages may be referred later as
wenzelm@26849
   452
  theorem list @{text "f.simps"}, where @{text f} is the (collective)
wenzelm@26849
   453
  name of the functions defined.  Individual equations may be named
wenzelm@26849
   454
  explicitly as well.
wenzelm@26849
   455
wenzelm@26849
   456
  The @{command (HOL) "function"} command accepts the following
wenzelm@26849
   457
  options.
wenzelm@26849
   458
wenzelm@28760
   459
  \begin{description}
wenzelm@26849
   460
wenzelm@28760
   461
  \item @{text sequential} enables a preprocessor which disambiguates
wenzelm@28760
   462
  overlapping patterns by making them mutually disjoint.  Earlier
wenzelm@28760
   463
  equations take precedence over later ones.  This allows to give the
wenzelm@28760
   464
  specification in a format very similar to functional programming.
wenzelm@28760
   465
  Note that the resulting simplification and induction rules
wenzelm@28760
   466
  correspond to the transformed specification, not the one given
wenzelm@26849
   467
  originally. This usually means that each equation given by the user
hoelzl@36139
   468
  may result in several theorems.  Also note that this automatic
wenzelm@26849
   469
  transformation only works for ML-style datatype patterns.
wenzelm@26849
   470
wenzelm@28760
   471
  \item @{text domintros} enables the automated generation of
wenzelm@26849
   472
  introduction rules for the domain predicate. While mostly not
wenzelm@26849
   473
  needed, they can be helpful in some proofs about partial functions.
wenzelm@26849
   474
wenzelm@28760
   475
  \item @{text tailrec} generates the unconstrained recursive
wenzelm@26849
   476
  equations even without a termination proof, provided that the
wenzelm@26849
   477
  function is tail-recursive. This currently only works
wenzelm@26849
   478
wenzelm@28760
   479
  \item @{text "default d"} allows to specify a default value for a
wenzelm@26849
   480
  (partial) function, which will ensure that @{text "f x = d x"}
wenzelm@26849
   481
  whenever @{text "x \<notin> f_dom"}.
wenzelm@26849
   482
wenzelm@28760
   483
  \end{description}
wenzelm@26849
   484
*}
wenzelm@26849
   485
wenzelm@26849
   486
wenzelm@26849
   487
subsection {* Proof methods related to recursive definitions *}
wenzelm@26849
   488
wenzelm@26849
   489
text {*
wenzelm@26849
   490
  \begin{matharray}{rcl}
wenzelm@28761
   491
    @{method_def (HOL) pat_completeness} & : & @{text method} \\
wenzelm@28761
   492
    @{method_def (HOL) relation} & : & @{text method} \\
wenzelm@28761
   493
    @{method_def (HOL) lexicographic_order} & : & @{text method} \\
krauss@33858
   494
    @{method_def (HOL) size_change} & : & @{text method} \\
wenzelm@26849
   495
  \end{matharray}
wenzelm@26849
   496
wenzelm@26849
   497
  \begin{rail}
wenzelm@26849
   498
    'relation' term
wenzelm@26849
   499
    ;
wenzelm@40255
   500
    'lexicographic_order' ( clasimpmod * )
wenzelm@26849
   501
    ;
wenzelm@40255
   502
    'size_change' ( orders ( clasimpmod * ) )
krauss@33858
   503
    ;
krauss@33858
   504
    orders: ( 'max' | 'min' | 'ms' ) *
wenzelm@26849
   505
  \end{rail}
wenzelm@26849
   506
wenzelm@28760
   507
  \begin{description}
wenzelm@26849
   508
wenzelm@28760
   509
  \item @{method (HOL) pat_completeness} is a specialized method to
wenzelm@26849
   510
  solve goals regarding the completeness of pattern matching, as
wenzelm@26849
   511
  required by the @{command (HOL) "function"} package (cf.\
wenzelm@26849
   512
  \cite{isabelle-function}).
wenzelm@26849
   513
wenzelm@28760
   514
  \item @{method (HOL) relation}~@{text R} introduces a termination
wenzelm@26849
   515
  proof using the relation @{text R}.  The resulting proof state will
wenzelm@26849
   516
  contain goals expressing that @{text R} is wellfounded, and that the
wenzelm@26849
   517
  arguments of recursive calls decrease with respect to @{text R}.
wenzelm@26849
   518
  Usually, this method is used as the initial proof step of manual
wenzelm@26849
   519
  termination proofs.
wenzelm@26849
   520
wenzelm@28760
   521
  \item @{method (HOL) "lexicographic_order"} attempts a fully
wenzelm@26849
   522
  automated termination proof by searching for a lexicographic
wenzelm@26849
   523
  combination of size measures on the arguments of the function. The
wenzelm@26849
   524
  method accepts the same arguments as the @{method auto} method,
wenzelm@26849
   525
  which it uses internally to prove local descents.  The same context
wenzelm@26849
   526
  modifiers as for @{method auto} are accepted, see
wenzelm@26849
   527
  \secref{sec:clasimp}.
wenzelm@26849
   528
wenzelm@26849
   529
  In case of failure, extensive information is printed, which can help
wenzelm@26849
   530
  to analyse the situation (cf.\ \cite{isabelle-function}).
wenzelm@26849
   531
krauss@33858
   532
  \item @{method (HOL) "size_change"} also works on termination goals,
krauss@33858
   533
  using a variation of the size-change principle, together with a
krauss@33858
   534
  graph decomposition technique (see \cite{krauss_phd} for details).
krauss@33858
   535
  Three kinds of orders are used internally: @{text max}, @{text min},
krauss@33858
   536
  and @{text ms} (multiset), which is only available when the theory
krauss@33858
   537
  @{text Multiset} is loaded. When no order kinds are given, they are
krauss@33858
   538
  tried in order. The search for a termination proof uses SAT solving
krauss@33858
   539
  internally.
krauss@33858
   540
krauss@33858
   541
 For local descent proofs, the same context modifiers as for @{method
krauss@33858
   542
  auto} are accepted, see \secref{sec:clasimp}.
krauss@33858
   543
wenzelm@28760
   544
  \end{description}
wenzelm@26849
   545
*}
wenzelm@26849
   546
krauss@40171
   547
subsection {* Functions with explicit partiality *}
krauss@40171
   548
krauss@40171
   549
text {*
krauss@40171
   550
  \begin{matharray}{rcl}
krauss@40171
   551
    @{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
krauss@40171
   552
    @{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
krauss@40171
   553
  \end{matharray}
krauss@40171
   554
krauss@40171
   555
  \begin{rail}
krauss@40171
   556
    'partial_function' target? '(' mode ')' fixes \\ 'where' thmdecl? prop
krauss@40171
   557
  \end{rail}
krauss@40171
   558
krauss@40171
   559
  \begin{description}
krauss@40171
   560
krauss@40171
   561
  \item @{command (HOL) "partial_function"} defines recursive
krauss@40171
   562
  functions based on fixpoints in complete partial orders. No
krauss@40171
   563
  termination proof is required from the user or constructed
krauss@40171
   564
  internally. Instead, the possibility of non-termination is modelled
krauss@40171
   565
  explicitly in the result type, which contains an explicit bottom
krauss@40171
   566
  element.
krauss@40171
   567
krauss@40171
   568
  Pattern matching and mutual recursion are currently not supported.
krauss@40171
   569
  Thus, the specification consists of a single function described by a
krauss@40171
   570
  single recursive equation.
krauss@40171
   571
krauss@40171
   572
  There are no fixed syntactic restrictions on the body of the
krauss@40171
   573
  function, but the induced functional must be provably monotonic
krauss@40171
   574
  wrt.\ the underlying order.  The monotonicitity proof is performed
krauss@40171
   575
  internally, and the definition is rejected when it fails. The proof
krauss@40171
   576
  can be influenced by declaring hints using the
krauss@40171
   577
  @{attribute (HOL) partial_function_mono} attribute.
krauss@40171
   578
krauss@40171
   579
  The mandatory @{text mode} argument specifies the mode of operation
krauss@40171
   580
  of the command, which directly corresponds to a complete partial
krauss@40171
   581
  order on the result type. By default, the following modes are
krauss@40171
   582
  defined: 
krauss@40171
   583
krauss@40171
   584
  \begin{description}
krauss@40171
   585
  \item @{text option} defines functions that map into the @{type
krauss@40171
   586
  option} type. Here, the value @{term None} is used to model a
krauss@40171
   587
  non-terminating computation. Monotonicity requires that if @{term
krauss@40171
   588
  None} is returned by a recursive call, then the overall result
krauss@40171
   589
  must also be @{term None}. This is best achieved through the use of
krauss@40171
   590
  the monadic operator @{const "Option.bind"}.
krauss@40171
   591
  
krauss@40171
   592
  \item @{text tailrec} defines functions with an arbitrary result
krauss@40171
   593
  type and uses the slightly degenerated partial order where @{term
krauss@40171
   594
  "undefined"} is the bottom element.  Now, monotonicity requires that
krauss@40171
   595
  if @{term undefined} is returned by a recursive call, then the
krauss@40171
   596
  overall result must also be @{term undefined}. In practice, this is
krauss@40171
   597
  only satisfied when each recursive call is a tail call, whose result
krauss@40171
   598
  is directly returned. Thus, this mode of operation allows the
krauss@40171
   599
  definition of arbitrary tail-recursive functions.
krauss@40171
   600
  \end{description}
krauss@40171
   601
krauss@40171
   602
  Experienced users may define new modes by instantiating the locale
krauss@40171
   603
  @{const "partial_function_definitions"} appropriately.
krauss@40171
   604
krauss@40171
   605
  \item @{attribute (HOL) partial_function_mono} declares rules for
krauss@40171
   606
  use in the internal monononicity proofs of partial function
krauss@40171
   607
  definitions.
krauss@40171
   608
krauss@40171
   609
  \end{description}
krauss@40171
   610
krauss@40171
   611
*}
wenzelm@26849
   612
wenzelm@26849
   613
subsection {* Old-style recursive function definitions (TFL) *}
wenzelm@26849
   614
wenzelm@26849
   615
text {*
wenzelm@26849
   616
  The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
wenzelm@26849
   617
  "recdef_tc"} for defining recursive are mostly obsolete; @{command
wenzelm@26849
   618
  (HOL) "function"} or @{command (HOL) "fun"} should be used instead.
wenzelm@26849
   619
wenzelm@26849
   620
  \begin{matharray}{rcl}
wenzelm@28761
   621
    @{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
wenzelm@28761
   622
    @{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@26849
   623
  \end{matharray}
wenzelm@26849
   624
wenzelm@26849
   625
  \begin{rail}
wenzelm@26849
   626
    'recdef' ('(' 'permissive' ')')? \\ name term (prop +) hints?
wenzelm@26849
   627
    ;
wenzelm@26849
   628
    recdeftc thmdecl? tc
wenzelm@26849
   629
    ;
haftmann@31912
   630
    hints: '(' 'hints' ( recdefmod * ) ')'
wenzelm@26849
   631
    ;
wenzelm@40255
   632
    recdefmod: (('recdef_simp' | 'recdef_cong' | 'recdef_wf') (() | 'add' | 'del') ':' thmrefs) | clasimpmod
wenzelm@26849
   633
    ;
wenzelm@26849
   634
    tc: nameref ('(' nat ')')?
wenzelm@26849
   635
    ;
wenzelm@26849
   636
  \end{rail}
wenzelm@26849
   637
wenzelm@28760
   638
  \begin{description}
wenzelm@26849
   639
  
wenzelm@28760
   640
  \item @{command (HOL) "recdef"} defines general well-founded
wenzelm@26849
   641
  recursive functions (using the TFL package), see also
wenzelm@26849
   642
  \cite{isabelle-HOL}.  The ``@{text "(permissive)"}'' option tells
wenzelm@26849
   643
  TFL to recover from failed proof attempts, returning unfinished
wenzelm@26849
   644
  results.  The @{text recdef_simp}, @{text recdef_cong}, and @{text
wenzelm@26849
   645
  recdef_wf} hints refer to auxiliary rules to be used in the internal
wenzelm@26849
   646
  automated proof process of TFL.  Additional @{syntax clasimpmod}
wenzelm@26849
   647
  declarations (cf.\ \secref{sec:clasimp}) may be given to tune the
wenzelm@26849
   648
  context of the Simplifier (cf.\ \secref{sec:simplifier}) and
wenzelm@26849
   649
  Classical reasoner (cf.\ \secref{sec:classical}).
wenzelm@26849
   650
  
wenzelm@28760
   651
  \item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
wenzelm@26849
   652
  proof for leftover termination condition number @{text i} (default
wenzelm@26849
   653
  1) as generated by a @{command (HOL) "recdef"} definition of
wenzelm@26849
   654
  constant @{text c}.
wenzelm@26849
   655
  
wenzelm@26849
   656
  Note that in most cases, @{command (HOL) "recdef"} is able to finish
wenzelm@26849
   657
  its internal proofs without manual intervention.
wenzelm@26849
   658
wenzelm@28760
   659
  \end{description}
wenzelm@26849
   660
wenzelm@26849
   661
  \medskip Hints for @{command (HOL) "recdef"} may be also declared
wenzelm@26849
   662
  globally, using the following attributes.
wenzelm@26849
   663
wenzelm@26849
   664
  \begin{matharray}{rcl}
wenzelm@28761
   665
    @{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
wenzelm@28761
   666
    @{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
wenzelm@28761
   667
    @{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
wenzelm@26849
   668
  \end{matharray}
wenzelm@26849
   669
wenzelm@26849
   670
  \begin{rail}
wenzelm@40255
   671
    ('recdef_simp' | 'recdef_cong' | 'recdef_wf') (() | 'add' | 'del')
wenzelm@26849
   672
    ;
wenzelm@26849
   673
  \end{rail}
wenzelm@26849
   674
*}
wenzelm@26849
   675
wenzelm@26849
   676
wenzelm@26849
   677
section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
wenzelm@26849
   678
wenzelm@26849
   679
text {*
wenzelm@26849
   680
  An \textbf{inductive definition} specifies the least predicate (or
wenzelm@26849
   681
  set) @{text R} closed under given rules: applying a rule to elements
wenzelm@26849
   682
  of @{text R} yields a result within @{text R}.  For example, a
wenzelm@26849
   683
  structural operational semantics is an inductive definition of an
wenzelm@26849
   684
  evaluation relation.
wenzelm@26849
   685
wenzelm@26849
   686
  Dually, a \textbf{coinductive definition} specifies the greatest
wenzelm@26849
   687
  predicate~/ set @{text R} that is consistent with given rules: every
wenzelm@26849
   688
  element of @{text R} can be seen as arising by applying a rule to
wenzelm@26849
   689
  elements of @{text R}.  An important example is using bisimulation
wenzelm@26849
   690
  relations to formalise equivalence of processes and infinite data
wenzelm@26849
   691
  structures.
wenzelm@26849
   692
wenzelm@26849
   693
  \medskip The HOL package is related to the ZF one, which is
wenzelm@26849
   694
  described in a separate paper,\footnote{It appeared in CADE
wenzelm@26849
   695
  \cite{paulson-CADE}; a longer version is distributed with Isabelle.}
wenzelm@26849
   696
  which you should refer to in case of difficulties.  The package is
wenzelm@26849
   697
  simpler than that of ZF thanks to implicit type-checking in HOL.
wenzelm@26849
   698
  The types of the (co)inductive predicates (or sets) determine the
wenzelm@26849
   699
  domain of the fixedpoint definition, and the package does not have
wenzelm@26849
   700
  to use inference rules for type-checking.
wenzelm@26849
   701
wenzelm@26849
   702
  \begin{matharray}{rcl}
wenzelm@28761
   703
    @{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@28761
   704
    @{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@28761
   705
    @{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@28761
   706
    @{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@28761
   707
    @{attribute_def (HOL) mono} & : & @{text attribute} \\
wenzelm@26849
   708
  \end{matharray}
wenzelm@26849
   709
wenzelm@26849
   710
  \begin{rail}
wenzelm@40255
   711
    ('inductive' | 'inductive_set' | 'coinductive' | 'coinductive_set') target? fixes ('for' fixes)? \\
wenzelm@26849
   712
    ('where' clauses)? ('monos' thmrefs)?
wenzelm@26849
   713
    ;
wenzelm@26849
   714
    clauses: (thmdecl? prop + '|')
wenzelm@26849
   715
    ;
wenzelm@26849
   716
    'mono' (() | 'add' | 'del')
wenzelm@26849
   717
    ;
wenzelm@26849
   718
  \end{rail}
wenzelm@26849
   719
wenzelm@28760
   720
  \begin{description}
wenzelm@26849
   721
wenzelm@28760
   722
  \item @{command (HOL) "inductive"} and @{command (HOL)
wenzelm@28760
   723
  "coinductive"} define (co)inductive predicates from the
wenzelm@26849
   724
  introduction rules given in the @{keyword "where"} part.  The
wenzelm@26849
   725
  optional @{keyword "for"} part contains a list of parameters of the
wenzelm@26849
   726
  (co)inductive predicates that remain fixed throughout the
wenzelm@26849
   727
  definition.  The optional @{keyword "monos"} section contains
wenzelm@26849
   728
  \emph{monotonicity theorems}, which are required for each operator
wenzelm@26849
   729
  applied to a recursive set in the introduction rules.  There
wenzelm@26849
   730
  \emph{must} be a theorem of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"},
wenzelm@26849
   731
  for each premise @{text "M R\<^sub>i t"} in an introduction rule!
wenzelm@26849
   732
wenzelm@28760
   733
  \item @{command (HOL) "inductive_set"} and @{command (HOL)
wenzelm@28760
   734
  "coinductive_set"} are wrappers for to the previous commands,
wenzelm@26849
   735
  allowing the definition of (co)inductive sets.
wenzelm@26849
   736
wenzelm@28760
   737
  \item @{attribute (HOL) mono} declares monotonicity rules.  These
wenzelm@26849
   738
  rule are involved in the automated monotonicity proof of @{command
wenzelm@26849
   739
  (HOL) "inductive"}.
wenzelm@26849
   740
wenzelm@28760
   741
  \end{description}
wenzelm@26849
   742
*}
wenzelm@26849
   743
wenzelm@26849
   744
wenzelm@26849
   745
subsection {* Derived rules *}
wenzelm@26849
   746
wenzelm@26849
   747
text {*
wenzelm@26849
   748
  Each (co)inductive definition @{text R} adds definitions to the
wenzelm@26849
   749
  theory and also proves some theorems:
wenzelm@26849
   750
wenzelm@26849
   751
  \begin{description}
wenzelm@26849
   752
wenzelm@28760
   753
  \item @{text R.intros} is the list of introduction rules as proven
wenzelm@26849
   754
  theorems, for the recursive predicates (or sets).  The rules are
wenzelm@26849
   755
  also available individually, using the names given them in the
wenzelm@26849
   756
  theory file;
wenzelm@26849
   757
wenzelm@28760
   758
  \item @{text R.cases} is the case analysis (or elimination) rule;
wenzelm@26849
   759
wenzelm@28760
   760
  \item @{text R.induct} or @{text R.coinduct} is the (co)induction
wenzelm@26849
   761
  rule.
wenzelm@26849
   762
wenzelm@26849
   763
  \end{description}
wenzelm@26849
   764
wenzelm@26849
   765
  When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
wenzelm@26849
   766
  defined simultaneously, the list of introduction rules is called
wenzelm@26849
   767
  @{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
wenzelm@26849
   768
  called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
wenzelm@26849
   769
  of mutual induction rules is called @{text
wenzelm@26849
   770
  "R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
wenzelm@26849
   771
*}
wenzelm@26849
   772
wenzelm@26849
   773
wenzelm@26849
   774
subsection {* Monotonicity theorems *}
wenzelm@26849
   775
wenzelm@26849
   776
text {*
wenzelm@26849
   777
  Each theory contains a default set of theorems that are used in
wenzelm@26849
   778
  monotonicity proofs.  New rules can be added to this set via the
wenzelm@26849
   779
  @{attribute (HOL) mono} attribute.  The HOL theory @{text Inductive}
wenzelm@26849
   780
  shows how this is done.  In general, the following monotonicity
wenzelm@26849
   781
  theorems may be added:
wenzelm@26849
   782
wenzelm@26849
   783
  \begin{itemize}
wenzelm@26849
   784
wenzelm@26849
   785
  \item Theorems of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"}, for proving
wenzelm@26849
   786
  monotonicity of inductive definitions whose introduction rules have
wenzelm@26849
   787
  premises involving terms such as @{text "M R\<^sub>i t"}.
wenzelm@26849
   788
wenzelm@26849
   789
  \item Monotonicity theorems for logical operators, which are of the
wenzelm@26849
   790
  general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}.  For example, in
wenzelm@26849
   791
  the case of the operator @{text "\<or>"}, the corresponding theorem is
wenzelm@26849
   792
  \[
wenzelm@26849
   793
  \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@26849
   794
  \]
wenzelm@26849
   795
wenzelm@26849
   796
  \item De Morgan style equations for reasoning about the ``polarity''
wenzelm@26849
   797
  of expressions, e.g.
wenzelm@26849
   798
  \[
wenzelm@26849
   799
  @{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
wenzelm@26849
   800
  @{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
wenzelm@26849
   801
  \]
wenzelm@26849
   802
wenzelm@26849
   803
  \item Equations for reducing complex operators to more primitive
wenzelm@26849
   804
  ones whose monotonicity can easily be proved, e.g.
wenzelm@26849
   805
  \[
wenzelm@26849
   806
  @{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
wenzelm@26849
   807
  @{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
wenzelm@26849
   808
  \]
wenzelm@26849
   809
wenzelm@26849
   810
  \end{itemize}
wenzelm@26849
   811
wenzelm@26849
   812
  %FIXME: Example of an inductive definition
wenzelm@26849
   813
*}
wenzelm@26849
   814
wenzelm@26849
   815
wenzelm@26849
   816
section {* Arithmetic proof support *}
wenzelm@26849
   817
wenzelm@26849
   818
text {*
wenzelm@26849
   819
  \begin{matharray}{rcl}
wenzelm@28761
   820
    @{method_def (HOL) arith} & : & @{text method} \\
nipkow@30863
   821
    @{attribute_def (HOL) arith} & : & @{text attribute} \\
wenzelm@28761
   822
    @{attribute_def (HOL) arith_split} & : & @{text attribute} \\
wenzelm@26849
   823
  \end{matharray}
wenzelm@26849
   824
wenzelm@26849
   825
  The @{method (HOL) arith} method decides linear arithmetic problems
wenzelm@26849
   826
  (on types @{text nat}, @{text int}, @{text real}).  Any current
wenzelm@26849
   827
  facts are inserted into the goal before running the procedure.
wenzelm@26849
   828
nipkow@30863
   829
  The @{attribute (HOL) arith} attribute declares facts that are
nipkow@30863
   830
  always supplied to the arithmetic provers implicitly.
wenzelm@26849
   831
nipkow@30863
   832
  The @{attribute (HOL) arith_split} attribute declares case split
wenzelm@30865
   833
  rules to be expanded before @{method (HOL) arith} is invoked.
nipkow@30863
   834
nipkow@30863
   835
  Note that a simpler (but faster) arithmetic prover is
nipkow@30863
   836
  already invoked by the Simplifier.
wenzelm@26849
   837
*}
wenzelm@26849
   838
wenzelm@26849
   839
wenzelm@30169
   840
section {* Intuitionistic proof search *}
wenzelm@30169
   841
wenzelm@30169
   842
text {*
wenzelm@30169
   843
  \begin{matharray}{rcl}
wenzelm@30171
   844
    @{method_def (HOL) iprover} & : & @{text method} \\
wenzelm@30169
   845
  \end{matharray}
wenzelm@30169
   846
wenzelm@30169
   847
  \begin{rail}
wenzelm@35613
   848
    'iprover' ( rulemod * )
wenzelm@30169
   849
    ;
wenzelm@30169
   850
  \end{rail}
wenzelm@30169
   851
wenzelm@30171
   852
  The @{method (HOL) iprover} method performs intuitionistic proof
wenzelm@30171
   853
  search, depending on specifically declared rules from the context,
wenzelm@30171
   854
  or given as explicit arguments.  Chained facts are inserted into the
wenzelm@35613
   855
  goal before commencing proof search.
wenzelm@35613
   856
wenzelm@30169
   857
  Rules need to be classified as @{attribute (Pure) intro},
wenzelm@30169
   858
  @{attribute (Pure) elim}, or @{attribute (Pure) dest}; here the
wenzelm@30169
   859
  ``@{text "!"}'' indicator refers to ``safe'' rules, which may be
wenzelm@30169
   860
  applied aggressively (without considering back-tracking later).
wenzelm@30169
   861
  Rules declared with ``@{text "?"}'' are ignored in proof search (the
wenzelm@30169
   862
  single-step @{method rule} method still observes these).  An
wenzelm@30169
   863
  explicit weight annotation may be given as well; otherwise the
wenzelm@30169
   864
  number of rule premises will be taken into account here.
wenzelm@30169
   865
*}
wenzelm@30169
   866
wenzelm@30169
   867
wenzelm@30171
   868
section {* Coherent Logic *}
wenzelm@30171
   869
wenzelm@30171
   870
text {*
wenzelm@30171
   871
  \begin{matharray}{rcl}
wenzelm@30171
   872
    @{method_def (HOL) "coherent"} & : & @{text method} \\
wenzelm@30171
   873
  \end{matharray}
wenzelm@30171
   874
wenzelm@30171
   875
  \begin{rail}
wenzelm@30171
   876
    'coherent' thmrefs?
wenzelm@30171
   877
    ;
wenzelm@30171
   878
  \end{rail}
wenzelm@30171
   879
wenzelm@30171
   880
  The @{method (HOL) coherent} method solves problems of
wenzelm@30171
   881
  \emph{Coherent Logic} \cite{Bezem-Coquand:2005}, which covers
wenzelm@30171
   882
  applications in confluence theory, lattice theory and projective
wenzelm@30171
   883
  geometry.  See @{"file" "~~/src/HOL/ex/Coherent.thy"} for some
wenzelm@30171
   884
  examples.
wenzelm@30171
   885
*}
wenzelm@30171
   886
wenzelm@30171
   887
haftmann@31912
   888
section {* Checking and refuting propositions *}
haftmann@31912
   889
haftmann@31912
   890
text {*
haftmann@31912
   891
  Identifying incorrect propositions usually involves evaluation of
haftmann@31912
   892
  particular assignments and systematic counter example search.  This
haftmann@31912
   893
  is supported by the following commands.
haftmann@31912
   894
haftmann@31912
   895
  \begin{matharray}{rcl}
haftmann@31912
   896
    @{command_def (HOL) "value"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@31912
   897
    @{command_def (HOL) "quickcheck"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
haftmann@31912
   898
    @{command_def (HOL) "quickcheck_params"} & : & @{text "theory \<rightarrow> theory"}
haftmann@31912
   899
  \end{matharray}
haftmann@31912
   900
haftmann@31912
   901
  \begin{rail}
haftmann@31912
   902
    'value' ( ( '[' name ']' ) ? ) modes? term
haftmann@31912
   903
    ;
haftmann@31912
   904
haftmann@31912
   905
    'quickcheck' ( ( '[' args ']' ) ? ) nat?
haftmann@31912
   906
    ;
haftmann@31912
   907
haftmann@31912
   908
    'quickcheck_params' ( ( '[' args ']' ) ? )
haftmann@31912
   909
    ;
haftmann@31912
   910
haftmann@31912
   911
    modes: '(' (name + ) ')'
haftmann@31912
   912
    ;
haftmann@31912
   913
haftmann@31912
   914
    args: ( name '=' value + ',' )
haftmann@31912
   915
    ;
haftmann@31912
   916
  \end{rail}
haftmann@31912
   917
haftmann@31912
   918
  \begin{description}
haftmann@31912
   919
haftmann@31912
   920
  \item @{command (HOL) "value"}~@{text t} evaluates and prints a
haftmann@31912
   921
    term; optionally @{text modes} can be specified, which are
haftmann@31912
   922
    appended to the current print mode (see also \cite{isabelle-ref}).
haftmann@31912
   923
    Internally, the evaluation is performed by registered evaluators,
haftmann@31912
   924
    which are invoked sequentially until a result is returned.
haftmann@31912
   925
    Alternatively a specific evaluator can be selected using square
haftmann@37444
   926
    brackets; typical evaluators use the current set of code equations
haftmann@37444
   927
    to normalize and include @{text simp} for fully symbolic evaluation
haftmann@37444
   928
    using the simplifier, @{text nbe} for \emph{normalization by evaluation}
haftmann@37444
   929
    and \emph{code} for code generation in SML.
haftmann@31912
   930
haftmann@31912
   931
  \item @{command (HOL) "quickcheck"} tests the current goal for
haftmann@31912
   932
    counter examples using a series of arbitrary assignments for its
haftmann@31912
   933
    free variables; by default the first subgoal is tested, an other
haftmann@31912
   934
    can be selected explicitly using an optional goal index.
haftmann@31912
   935
    A number of configuration options are supported for
haftmann@31912
   936
    @{command (HOL) "quickcheck"}, notably:
haftmann@31912
   937
haftmann@31912
   938
    \begin{description}
haftmann@31912
   939
wenzelm@40254
   940
    \item[@{text size}] specifies the maximum size of the search space
wenzelm@40254
   941
    for assignment values.
haftmann@31912
   942
wenzelm@40254
   943
    \item[@{text iterations}] sets how many sets of assignments are
wenzelm@40254
   944
    generated for each particular size.
haftmann@31912
   945
wenzelm@40254
   946
    \item[@{text no_assms}] specifies whether assumptions in
wenzelm@40254
   947
    structured proofs should be ignored.
blanchet@35331
   948
wenzelm@40254
   949
    \item[@{text timeout}] sets the time limit in seconds.
bulwahn@40245
   950
wenzelm@40254
   951
    \item[@{text default_type}] sets the type(s) generally used to
wenzelm@40254
   952
    instantiate type variables.
bulwahn@40245
   953
wenzelm@40254
   954
    \item[@{text report}] if set quickcheck reports how many tests
wenzelm@40254
   955
    fulfilled the preconditions.
bulwahn@40245
   956
wenzelm@40254
   957
    \item[@{text quiet}] if not set quickcheck informs about the
wenzelm@40254
   958
    current size for assignment values.
bulwahn@40245
   959
wenzelm@40254
   960
    \item[@{text expect}] can be used to check if the user's
wenzelm@40254
   961
    expectation was met (@{text no_expectation}, @{text
wenzelm@40254
   962
    no_counterexample}, or @{text counterexample}).
bulwahn@40245
   963
haftmann@31912
   964
    \end{description}
haftmann@31912
   965
haftmann@31912
   966
    These option can be given within square brackets.
haftmann@31912
   967
haftmann@31912
   968
  \item @{command (HOL) "quickcheck_params"} changes quickcheck
haftmann@31912
   969
    configuration options persitently.
haftmann@31912
   970
haftmann@31912
   971
  \end{description}
haftmann@31912
   972
*}
haftmann@31912
   973
haftmann@31912
   974
wenzelm@28752
   975
section {* Unstructured case analysis and induction \label{sec:hol-induct-tac} *}
wenzelm@26849
   976
wenzelm@26849
   977
text {*
wenzelm@27123
   978
  The following tools of Isabelle/HOL support cases analysis and
wenzelm@27123
   979
  induction in unstructured tactic scripts; see also
wenzelm@27123
   980
  \secref{sec:cases-induct} for proper Isar versions of similar ideas.
wenzelm@26849
   981
wenzelm@26849
   982
  \begin{matharray}{rcl}
wenzelm@28761
   983
    @{method_def (HOL) case_tac}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
   984
    @{method_def (HOL) induct_tac}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
   985
    @{method_def (HOL) ind_cases}@{text "\<^sup>*"} & : & @{text method} \\
wenzelm@28761
   986
    @{command_def (HOL) "inductive_cases"}@{text "\<^sup>*"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
wenzelm@26849
   987
  \end{matharray}
wenzelm@26849
   988
wenzelm@26849
   989
  \begin{rail}
wenzelm@40255
   990
    'case_tac' goalspec? term rule?
wenzelm@26849
   991
    ;
wenzelm@40255
   992
    'induct_tac' goalspec? (insts * 'and') rule?
wenzelm@26849
   993
    ;
wenzelm@40255
   994
    'ind_cases' (prop +) ('for' (name +)) ?
wenzelm@26849
   995
    ;
wenzelm@40255
   996
    'inductive_cases' (thmdecl? (prop +) + 'and')
wenzelm@26849
   997
    ;
wenzelm@26849
   998
wenzelm@26849
   999
    rule: ('rule' ':' thmref)
wenzelm@26849
  1000
    ;
wenzelm@26849
  1001
  \end{rail}
wenzelm@26849
  1002
wenzelm@28760
  1003
  \begin{description}
wenzelm@26849
  1004
wenzelm@28760
  1005
  \item @{method (HOL) case_tac} and @{method (HOL) induct_tac} admit
wenzelm@28760
  1006
  to reason about inductive types.  Rules are selected according to
wenzelm@28760
  1007
  the declarations by the @{attribute cases} and @{attribute induct}
wenzelm@28760
  1008
  attributes, cf.\ \secref{sec:cases-induct}.  The @{command (HOL)
wenzelm@28760
  1009
  datatype} package already takes care of this.
wenzelm@27123
  1010
wenzelm@27123
  1011
  These unstructured tactics feature both goal addressing and dynamic
wenzelm@26849
  1012
  instantiation.  Note that named rule cases are \emph{not} provided
wenzelm@27123
  1013
  as would be by the proper @{method cases} and @{method induct} proof
wenzelm@27123
  1014
  methods (see \secref{sec:cases-induct}).  Unlike the @{method
wenzelm@27123
  1015
  induct} method, @{method induct_tac} does not handle structured rule
wenzelm@27123
  1016
  statements, only the compact object-logic conclusion of the subgoal
wenzelm@27123
  1017
  being addressed.
wenzelm@26849
  1018
  
wenzelm@28760
  1019
  \item @{method (HOL) ind_cases} and @{command (HOL)
wenzelm@28760
  1020
  "inductive_cases"} provide an interface to the internal @{ML_text
wenzelm@26860
  1021
  mk_cases} operation.  Rules are simplified in an unrestricted
wenzelm@26860
  1022
  forward manner.
wenzelm@26849
  1023
wenzelm@26849
  1024
  While @{method (HOL) ind_cases} is a proof method to apply the
wenzelm@26849
  1025
  result immediately as elimination rules, @{command (HOL)
wenzelm@26849
  1026
  "inductive_cases"} provides case split theorems at the theory level
wenzelm@26849
  1027
  for later use.  The @{keyword "for"} argument of the @{method (HOL)
wenzelm@26849
  1028
  ind_cases} method allows to specify a list of variables that should
wenzelm@26849
  1029
  be generalized before applying the resulting rule.
wenzelm@26849
  1030
wenzelm@28760
  1031
  \end{description}
wenzelm@26849
  1032
*}
wenzelm@26849
  1033
wenzelm@26849
  1034
wenzelm@26849
  1035
section {* Executable code *}
wenzelm@26849
  1036
wenzelm@26849
  1037
text {*
wenzelm@26849
  1038
  Isabelle/Pure provides two generic frameworks to support code
wenzelm@26849
  1039
  generation from executable specifications.  Isabelle/HOL
wenzelm@26849
  1040
  instantiates these mechanisms in a way that is amenable to end-user
wenzelm@26849
  1041
  applications.
wenzelm@26849
  1042
haftmann@37422
  1043
  \medskip One framework generates code from functional programs
haftmann@37422
  1044
  (including overloading using type classes) to SML \cite{SML}, OCaml
haftmann@38814
  1045
  \cite{OCaml}, Haskell \cite{haskell-revised-report} and Scala
haftmann@38814
  1046
  \cite{scala-overview-tech-report}.
haftmann@37422
  1047
  Conceptually, code generation is split up in three steps:
haftmann@37422
  1048
  \emph{selection} of code theorems, \emph{translation} into an
haftmann@37422
  1049
  abstract executable view and \emph{serialization} to a specific
haftmann@37422
  1050
  \emph{target language}.  Inductive specifications can be executed
haftmann@37422
  1051
  using the predicate compiler which operates within HOL.
haftmann@37422
  1052
  See \cite{isabelle-codegen} for an introduction.
haftmann@37422
  1053
haftmann@37422
  1054
  \begin{matharray}{rcl}
haftmann@37422
  1055
    @{command_def (HOL) "export_code"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1056
    @{attribute_def (HOL) code} & : & @{text attribute} \\
haftmann@37422
  1057
    @{command_def (HOL) "code_abort"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1058
    @{command_def (HOL) "code_datatype"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1059
    @{command_def (HOL) "print_codesetup"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1060
    @{attribute_def (HOL) code_inline} & : & @{text attribute} \\
haftmann@37422
  1061
    @{attribute_def (HOL) code_post} & : & @{text attribute} \\
haftmann@37422
  1062
    @{command_def (HOL) "print_codeproc"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1063
    @{command_def (HOL) "code_thms"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1064
    @{command_def (HOL) "code_deps"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
haftmann@37422
  1065
    @{command_def (HOL) "code_const"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1066
    @{command_def (HOL) "code_type"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1067
    @{command_def (HOL) "code_class"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1068
    @{command_def (HOL) "code_instance"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1069
    @{command_def (HOL) "code_reserved"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1070
    @{command_def (HOL) "code_monad"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1071
    @{command_def (HOL) "code_include"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@37422
  1072
    @{command_def (HOL) "code_modulename"} & : & @{text "theory \<rightarrow> theory"} \\
haftmann@39608
  1073
    @{command_def (HOL) "code_reflect"} & : & @{text "theory \<rightarrow> theory"}
haftmann@37422
  1074
  \end{matharray}
haftmann@37422
  1075
haftmann@37422
  1076
  \begin{rail}
wenzelm@40255
  1077
     'export_code' ( constexpr + ) \\
wenzelm@40255
  1078
       ( ( 'in' target ( 'module_name' string ) ? \\
haftmann@37820
  1079
        ( 'file' ( string | '-' ) ) ? ( '(' args ')' ) ?) + ) ?
haftmann@37422
  1080
    ;
haftmann@37422
  1081
haftmann@37422
  1082
    const: term
haftmann@37422
  1083
    ;
haftmann@37422
  1084
haftmann@40711
  1085
    constexpr: ( const | 'name._' | '_' )
haftmann@37422
  1086
    ;
haftmann@37422
  1087
haftmann@37422
  1088
    typeconstructor: nameref
haftmann@37422
  1089
    ;
haftmann@37422
  1090
haftmann@37422
  1091
    class: nameref
haftmann@37422
  1092
    ;
haftmann@37422
  1093
haftmann@38814
  1094
    target: 'SML' | 'OCaml' | 'Haskell' | 'Scala'
haftmann@37422
  1095
    ;
haftmann@37422
  1096
haftmann@38462
  1097
    'code' ( 'del' | 'abstype' | 'abstract' ) ?
haftmann@37422
  1098
    ;
haftmann@37422
  1099
wenzelm@40255
  1100
    'code_abort' ( const + )
haftmann@37422
  1101
    ;
haftmann@37422
  1102
wenzelm@40255
  1103
    'code_datatype' ( const + )
haftmann@37422
  1104
    ;
haftmann@37422
  1105
haftmann@37422
  1106
    'code_inline' ( 'del' ) ?
haftmann@37422
  1107
    ;
haftmann@37422
  1108
haftmann@37422
  1109
    'code_post' ( 'del' ) ?
haftmann@37422
  1110
    ;
haftmann@37422
  1111
wenzelm@40255
  1112
    'code_thms' ( constexpr + ) ?
haftmann@37422
  1113
    ;
haftmann@37422
  1114
wenzelm@40255
  1115
    'code_deps' ( constexpr + ) ?
haftmann@37422
  1116
    ;
haftmann@37422
  1117
wenzelm@40255
  1118
    'code_const' (const + 'and') \\
haftmann@37422
  1119
      ( ( '(' target ( syntax ? + 'and' ) ')' ) + )
haftmann@37422
  1120
    ;
haftmann@37422
  1121
wenzelm@40255
  1122
    'code_type' (typeconstructor + 'and') \\
haftmann@37422
  1123
      ( ( '(' target ( syntax ? + 'and' ) ')' ) + )
haftmann@37422
  1124
    ;
haftmann@37422
  1125
wenzelm@40255
  1126
    'code_class' (class + 'and') \\
haftmann@37422
  1127
      ( ( '(' target \\ ( string ? + 'and' ) ')' ) + )
haftmann@37422
  1128
    ;
haftmann@37422
  1129
wenzelm@40255
  1130
    'code_instance' (( typeconstructor '::' class ) + 'and') \\
haftmann@37422
  1131
      ( ( '(' target ( '-' ? + 'and' ) ')' ) + )
haftmann@37422
  1132
    ;
haftmann@37422
  1133
wenzelm@40255
  1134
    'code_reserved' target ( string + )
haftmann@37422
  1135
    ;
haftmann@37422
  1136
wenzelm@40255
  1137
    'code_monad' const const target
haftmann@37422
  1138
    ;
haftmann@37422
  1139
wenzelm@40255
  1140
    'code_include' target ( string ( string | '-') )
haftmann@37422
  1141
    ;
haftmann@37422
  1142
wenzelm@40255
  1143
    'code_modulename' target ( ( string string ) + )
haftmann@37422
  1144
    ;
haftmann@37422
  1145
haftmann@40709
  1146
    'code_reflect' string \\
haftmann@40711
  1147
      ( 'datatypes' ( string '=' ( '_' | ( string + '|' ) + 'and' ) ) ) ? \\
haftmann@39608
  1148
      ( 'functions' ( string + ) ) ? ( 'file' string ) ?
haftmann@39608
  1149
    ;
haftmann@39608
  1150
haftmann@37422
  1151
    syntax: string | ( 'infix' | 'infixl' | 'infixr' ) nat string
haftmann@37422
  1152
    ;
haftmann@37422
  1153
haftmann@37422
  1154
  \end{rail}
haftmann@37422
  1155
haftmann@37422
  1156
  \begin{description}
haftmann@37422
  1157
haftmann@37422
  1158
  \item @{command (HOL) "export_code"} generates code for a given list
haftmann@39608
  1159
  of constants in the specified target language(s).  If no
haftmann@39608
  1160
  serialization instruction is given, only abstract code is generated
haftmann@39608
  1161
  internally.
haftmann@37422
  1162
haftmann@37422
  1163
  Constants may be specified by giving them literally, referring to
haftmann@37422
  1164
  all executable contants within a certain theory by giving @{text
haftmann@37422
  1165
  "name.*"}, or referring to \emph{all} executable constants currently
haftmann@37422
  1166
  available by giving @{text "*"}.
haftmann@37422
  1167
haftmann@37422
  1168
  By default, for each involved theory one corresponding name space
haftmann@37422
  1169
  module is generated.  Alternativly, a module name may be specified
haftmann@37422
  1170
  after the @{keyword "module_name"} keyword; then \emph{all} code is
haftmann@37422
  1171
  placed in this module.
haftmann@37422
  1172
haftmann@39608
  1173
  For \emph{SML}, \emph{OCaml} and \emph{Scala} the file specification
haftmann@39608
  1174
  refers to a single file; for \emph{Haskell}, it refers to a whole
haftmann@39608
  1175
  directory, where code is generated in multiple files reflecting the
haftmann@39608
  1176
  module hierarchy.  Omitting the file specification denotes standard
haftmann@37749
  1177
  output.
haftmann@37422
  1178
haftmann@37422
  1179
  Serializers take an optional list of arguments in parentheses.  For
haftmann@37422
  1180
  \emph{SML} and \emph{OCaml}, ``@{text no_signatures}`` omits
haftmann@37422
  1181
  explicit module signatures.
haftmann@37422
  1182
  
haftmann@39608
  1183
  For \emph{Haskell} a module name prefix may be given using the
haftmann@39608
  1184
  ``@{text "root:"}'' argument; ``@{text string_classes}'' adds a
haftmann@39608
  1185
  ``@{verbatim "deriving (Read, Show)"}'' clause to each appropriate
haftmann@39608
  1186
  datatype declaration.
haftmann@37422
  1187
haftmann@37422
  1188
  \item @{attribute (HOL) code} explicitly selects (or with option
haftmann@38462
  1189
  ``@{text "del"}'' deselects) a code equation for code generation.
haftmann@38462
  1190
  Usually packages introducing code equations provide a reasonable
haftmann@38462
  1191
  default setup for selection.  Variants @{text "code abstype"} and
haftmann@38462
  1192
  @{text "code abstract"} declare abstract datatype certificates or
haftmann@38462
  1193
  code equations on abstract datatype representations respectively.
haftmann@37422
  1194
haftmann@37422
  1195
  \item @{command (HOL) "code_abort"} declares constants which are not
haftmann@39608
  1196
  required to have a definition by means of code equations; if needed
haftmann@39608
  1197
  these are implemented by program abort instead.
haftmann@37422
  1198
haftmann@37422
  1199
  \item @{command (HOL) "code_datatype"} specifies a constructor set
haftmann@37422
  1200
  for a logical type.
haftmann@37422
  1201
haftmann@37422
  1202
  \item @{command (HOL) "print_codesetup"} gives an overview on
haftmann@37422
  1203
  selected code equations and code generator datatypes.
haftmann@37422
  1204
haftmann@39608
  1205
  \item @{attribute (HOL) code_inline} declares (or with option
haftmann@39608
  1206
  ``@{text "del"}'' removes) inlining theorems which are applied as
haftmann@39608
  1207
  rewrite rules to any code equation during preprocessing.
haftmann@37422
  1208
haftmann@39608
  1209
  \item @{attribute (HOL) code_post} declares (or with option ``@{text
haftmann@39608
  1210
  "del"}'' removes) theorems which are applied as rewrite rules to any
haftmann@39608
  1211
  result of an evaluation.
haftmann@37422
  1212
haftmann@39608
  1213
  \item @{command (HOL) "print_codeproc"} prints the setup of the code
haftmann@39608
  1214
  generator preprocessor.
haftmann@37422
  1215
haftmann@37422
  1216
  \item @{command (HOL) "code_thms"} prints a list of theorems
haftmann@37422
  1217
  representing the corresponding program containing all given
haftmann@37422
  1218
  constants after preprocessing.
haftmann@37422
  1219
haftmann@37422
  1220
  \item @{command (HOL) "code_deps"} visualizes dependencies of
haftmann@37422
  1221
  theorems representing the corresponding program containing all given
haftmann@37422
  1222
  constants after preprocessing.
haftmann@37422
  1223
haftmann@37422
  1224
  \item @{command (HOL) "code_const"} associates a list of constants
haftmann@37422
  1225
  with target-specific serializations; omitting a serialization
haftmann@37422
  1226
  deletes an existing serialization.
haftmann@37422
  1227
haftmann@37422
  1228
  \item @{command (HOL) "code_type"} associates a list of type
haftmann@37422
  1229
  constructors with target-specific serializations; omitting a
haftmann@37422
  1230
  serialization deletes an existing serialization.
haftmann@37422
  1231
haftmann@37422
  1232
  \item @{command (HOL) "code_class"} associates a list of classes
haftmann@37422
  1233
  with target-specific class names; omitting a serialization deletes
haftmann@37422
  1234
  an existing serialization.  This applies only to \emph{Haskell}.
haftmann@37422
  1235
haftmann@37422
  1236
  \item @{command (HOL) "code_instance"} declares a list of type
haftmann@37422
  1237
  constructor / class instance relations as ``already present'' for a
haftmann@37422
  1238
  given target.  Omitting a ``@{text "-"}'' deletes an existing
haftmann@37422
  1239
  ``already present'' declaration.  This applies only to
haftmann@37422
  1240
  \emph{Haskell}.
haftmann@37422
  1241
haftmann@37422
  1242
  \item @{command (HOL) "code_reserved"} declares a list of names as
haftmann@37422
  1243
  reserved for a given target, preventing it to be shadowed by any
haftmann@37422
  1244
  generated code.
haftmann@37422
  1245
haftmann@37422
  1246
  \item @{command (HOL) "code_monad"} provides an auxiliary mechanism
haftmann@37422
  1247
  to generate monadic code for Haskell.
haftmann@37422
  1248
haftmann@37422
  1249
  \item @{command (HOL) "code_include"} adds arbitrary named content
haftmann@37422
  1250
  (``include'') to generated code.  A ``@{text "-"}'' as last argument
haftmann@37422
  1251
  will remove an already added ``include''.
haftmann@37422
  1252
haftmann@37422
  1253
  \item @{command (HOL) "code_modulename"} declares aliasings from one
haftmann@37422
  1254
  module name onto another.
haftmann@37422
  1255
haftmann@39608
  1256
  \item @{command (HOL) "code_reflect"} without a ``@{text "file"}''
haftmann@39608
  1257
  argument compiles code into the system runtime environment and
haftmann@39608
  1258
  modifies the code generator setup that future invocations of system
haftmann@39608
  1259
  runtime code generation referring to one of the ``@{text
haftmann@39608
  1260
  "datatypes"}'' or ``@{text "functions"}'' entities use these precompiled
haftmann@39608
  1261
  entities.  With a ``@{text "file"}'' argument, the corresponding code
haftmann@39608
  1262
  is generated into that specified file without modifying the code
haftmann@39608
  1263
  generator setup.
haftmann@39608
  1264
haftmann@37422
  1265
  \end{description}
haftmann@37422
  1266
haftmann@39608
  1267
  The other framework generates code from both functional and
haftmann@39608
  1268
  relational programs to SML.  See \cite{isabelle-HOL} for further
haftmann@39608
  1269
  information (this actually covers the new-style theory format as
haftmann@39608
  1270
  well).
wenzelm@26849
  1271
wenzelm@26849
  1272
  \begin{matharray}{rcl}
wenzelm@28761
  1273
    @{command_def (HOL) "code_module"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@28761
  1274
    @{command_def (HOL) "code_library"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@28761
  1275
    @{command_def (HOL) "consts_code"} & : & @{text "theory \<rightarrow> theory"} \\
wenzelm@28761
  1276
    @{command_def (HOL) "types_code"} & : & @{text "theory \<rightarrow> theory"} \\  
wenzelm@28761
  1277
    @{attribute_def (HOL) code} & : & @{text attribute} \\
wenzelm@26849
  1278
  \end{matharray}
wenzelm@26849
  1279
wenzelm@26849
  1280
  \begin{rail}
wenzelm@40255
  1281
  ( 'code_module' | 'code_library' ) modespec ? name ? \\
wenzelm@26849
  1282
    ( 'file' name ) ? ( 'imports' ( name + ) ) ? \\
wenzelm@26849
  1283
    'contains' ( ( name '=' term ) + | term + )
wenzelm@26849
  1284
  ;
wenzelm@26849
  1285
wenzelm@26849
  1286
  modespec: '(' ( name * ) ')'
wenzelm@26849
  1287
  ;
wenzelm@26849
  1288
wenzelm@40255
  1289
  'consts_code' (codespec +)
wenzelm@26849
  1290
  ;
wenzelm@26849
  1291
wenzelm@26849
  1292
  codespec: const template attachment ?
wenzelm@26849
  1293
  ;
wenzelm@26849
  1294
wenzelm@40255
  1295
  'types_code' (tycodespec +)
wenzelm@26849
  1296
  ;
wenzelm@26849
  1297
wenzelm@26849
  1298
  tycodespec: name template attachment ?
wenzelm@26849
  1299
  ;
wenzelm@26849
  1300
wenzelm@26849
  1301
  const: term
wenzelm@26849
  1302
  ;
wenzelm@26849
  1303
wenzelm@26849
  1304
  template: '(' string ')'
wenzelm@26849
  1305
  ;
wenzelm@26849
  1306
wenzelm@26849
  1307
  attachment: 'attach' modespec ? verblbrace text verbrbrace
wenzelm@26849
  1308
  ;
wenzelm@26849
  1309
wenzelm@26849
  1310
  'code' (name)?
wenzelm@26849
  1311
  ;
wenzelm@26849
  1312
  \end{rail}
wenzelm@26849
  1313
wenzelm@26849
  1314
*}
wenzelm@26849
  1315
wenzelm@27045
  1316
wenzelm@27045
  1317
section {* Definition by specification \label{sec:hol-specification} *}
wenzelm@27045
  1318
wenzelm@27045
  1319
text {*
wenzelm@27045
  1320
  \begin{matharray}{rcl}
wenzelm@28761
  1321
    @{command_def (HOL) "specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@28761
  1322
    @{command_def (HOL) "ax_specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
wenzelm@27045
  1323
  \end{matharray}
wenzelm@27045
  1324
wenzelm@27045
  1325
  \begin{rail}
wenzelm@40255
  1326
  ('specification' | 'ax_specification') '(' (decl +) ')' \\ (thmdecl? prop +)
wenzelm@27045
  1327
  ;
wenzelm@27045
  1328
  decl: ((name ':')? term '(' 'overloaded' ')'?)
wenzelm@27045
  1329
  \end{rail}
wenzelm@27045
  1330
wenzelm@28760
  1331
  \begin{description}
wenzelm@27045
  1332
wenzelm@28760
  1333
  \item @{command (HOL) "specification"}~@{text "decls \<phi>"} sets up a
wenzelm@27045
  1334
  goal stating the existence of terms with the properties specified to
wenzelm@27045
  1335
  hold for the constants given in @{text decls}.  After finishing the
wenzelm@27045
  1336
  proof, the theory will be augmented with definitions for the given
wenzelm@27045
  1337
  constants, as well as with theorems stating the properties for these
wenzelm@27045
  1338
  constants.
wenzelm@27045
  1339
wenzelm@28760
  1340
  \item @{command (HOL) "ax_specification"}~@{text "decls \<phi>"} sets up
wenzelm@28760
  1341
  a goal stating the existence of terms with the properties specified
wenzelm@28760
  1342
  to hold for the constants given in @{text decls}.  After finishing
wenzelm@28760
  1343
  the proof, the theory will be augmented with axioms expressing the
wenzelm@28760
  1344
  properties given in the first place.
wenzelm@27045
  1345
wenzelm@28760
  1346
  \item @{text decl} declares a constant to be defined by the
wenzelm@27045
  1347
  specification given.  The definition for the constant @{text c} is
wenzelm@27045
  1348
  bound to the name @{text c_def} unless a theorem name is given in
wenzelm@27045
  1349
  the declaration.  Overloaded constants should be declared as such.
wenzelm@27045
  1350
wenzelm@28760
  1351
  \end{description}
wenzelm@27045
  1352
wenzelm@27045
  1353
  Whether to use @{command (HOL) "specification"} or @{command (HOL)
wenzelm@27045
  1354
  "ax_specification"} is to some extent a matter of style.  @{command
wenzelm@27045
  1355
  (HOL) "specification"} introduces no new axioms, and so by
wenzelm@27045
  1356
  construction cannot introduce inconsistencies, whereas @{command
wenzelm@27045
  1357
  (HOL) "ax_specification"} does introduce axioms, but only after the
wenzelm@27045
  1358
  user has explicitly proven it to be safe.  A practical issue must be
wenzelm@27045
  1359
  considered, though: After introducing two constants with the same
wenzelm@27045
  1360
  properties using @{command (HOL) "specification"}, one can prove
wenzelm@27045
  1361
  that the two constants are, in fact, equal.  If this might be a
wenzelm@27045
  1362
  problem, one should use @{command (HOL) "ax_specification"}.
wenzelm@27045
  1363
*}
wenzelm@27045
  1364
wenzelm@26840
  1365
end