doc-src/IsarRef/Thy/HOL_Specific.thy
author wenzelm
Tue Jun 10 19:15:16 2008 +0200 (2008-06-10)
changeset 27123 11fcdd5897dd
parent 27103 d8549f4d900b
child 27452 5c1fb7d262bf
permissions -rw-r--r--
case_tac/induct_tac: use same declarations as cases/induct;
wenzelm@26840
     1
(* $Id$ *)
wenzelm@26840
     2
wenzelm@26840
     3
theory HOL_Specific
wenzelm@26849
     4
imports Main
wenzelm@26840
     5
begin
wenzelm@26840
     6
wenzelm@26852
     7
chapter {* Isabelle/HOL \label{ch:hol} *}
wenzelm@26849
     8
wenzelm@26849
     9
section {* Primitive types \label{sec:hol-typedef} *}
wenzelm@26849
    10
wenzelm@26849
    11
text {*
wenzelm@26849
    12
  \begin{matharray}{rcl}
wenzelm@26849
    13
    @{command_def (HOL) "typedecl"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
    14
    @{command_def (HOL) "typedef"} & : & \isartrans{theory}{proof(prove)} \\
wenzelm@26849
    15
  \end{matharray}
wenzelm@26849
    16
wenzelm@26849
    17
  \begin{rail}
wenzelm@26849
    18
    'typedecl' typespec infix?
wenzelm@26849
    19
    ;
wenzelm@26849
    20
    'typedef' altname? abstype '=' repset
wenzelm@26849
    21
    ;
wenzelm@26849
    22
wenzelm@26849
    23
    altname: '(' (name | 'open' | 'open' name) ')'
wenzelm@26849
    24
    ;
wenzelm@26849
    25
    abstype: typespec infix?
wenzelm@26849
    26
    ;
wenzelm@26849
    27
    repset: term ('morphisms' name name)?
wenzelm@26849
    28
    ;
wenzelm@26849
    29
  \end{rail}
wenzelm@26849
    30
wenzelm@26849
    31
  \begin{descr}
wenzelm@26849
    32
  
wenzelm@26849
    33
  \item [@{command (HOL) "typedecl"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n)
wenzelm@26849
    34
  t"}] is similar to the original @{command "typedecl"} of
wenzelm@26849
    35
  Isabelle/Pure (see \secref{sec:types-pure}), but also declares type
wenzelm@26849
    36
  arity @{text "t :: (type, \<dots>, type) type"}, making @{text t} an
wenzelm@26849
    37
  actual HOL type constructor.   %FIXME check, update
wenzelm@26849
    38
  
wenzelm@26849
    39
  \item [@{command (HOL) "typedef"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n)
wenzelm@26849
    40
  t = A"}] sets up a goal stating non-emptiness of the set @{text A}.
wenzelm@26849
    41
  After finishing the proof, the theory will be augmented by a
wenzelm@26849
    42
  Gordon/HOL-style type definition, which establishes a bijection
wenzelm@26849
    43
  between the representing set @{text A} and the new type @{text t}.
wenzelm@26849
    44
  
wenzelm@26849
    45
  Technically, @{command (HOL) "typedef"} defines both a type @{text
wenzelm@26849
    46
  t} and a set (term constant) of the same name (an alternative base
wenzelm@26849
    47
  name may be given in parentheses).  The injection from type to set
wenzelm@26849
    48
  is called @{text Rep_t}, its inverse @{text Abs_t} (this may be
wenzelm@26849
    49
  changed via an explicit @{keyword (HOL) "morphisms"} declaration).
wenzelm@26849
    50
  
wenzelm@26849
    51
  Theorems @{text Rep_t}, @{text Rep_t_inverse}, and @{text
wenzelm@26849
    52
  Abs_t_inverse} provide the most basic characterization as a
wenzelm@26849
    53
  corresponding injection/surjection pair (in both directions).  Rules
wenzelm@26849
    54
  @{text Rep_t_inject} and @{text Abs_t_inject} provide a slightly
wenzelm@26849
    55
  more convenient view on the injectivity part, suitable for automated
wenzelm@26894
    56
  proof tools (e.g.\ in @{attribute simp} or @{attribute iff}
wenzelm@26894
    57
  declarations).  Rules @{text Rep_t_cases}/@{text Rep_t_induct}, and
wenzelm@26894
    58
  @{text Abs_t_cases}/@{text Abs_t_induct} provide alternative views
wenzelm@26894
    59
  on surjectivity; these are already declared as set or type rules for
wenzelm@26849
    60
  the generic @{method cases} and @{method induct} methods.
wenzelm@26849
    61
  
wenzelm@26849
    62
  An alternative name may be specified in parentheses; the default is
wenzelm@26849
    63
  to use @{text t} as indicated before.  The ``@{text "(open)"}''
wenzelm@26849
    64
  declaration suppresses a separate constant definition for the
wenzelm@26849
    65
  representing set.
wenzelm@26849
    66
wenzelm@26849
    67
  \end{descr}
wenzelm@26849
    68
wenzelm@26849
    69
  Note that raw type declarations are rarely used in practice; the
wenzelm@26849
    70
  main application is with experimental (or even axiomatic!) theory
wenzelm@26849
    71
  fragments.  Instead of primitive HOL type definitions, user-level
wenzelm@26849
    72
  theories usually refer to higher-level packages such as @{command
wenzelm@26849
    73
  (HOL) "record"} (see \secref{sec:hol-record}) or @{command (HOL)
wenzelm@26849
    74
  "datatype"} (see \secref{sec:hol-datatype}).
wenzelm@26849
    75
*}
wenzelm@26849
    76
wenzelm@26849
    77
wenzelm@26849
    78
section {* Adhoc tuples *}
wenzelm@26849
    79
wenzelm@26849
    80
text {*
wenzelm@26849
    81
  \begin{matharray}{rcl}
wenzelm@26849
    82
    @{attribute (HOL) split_format}@{text "\<^sup>*"} & : & \isaratt \\
wenzelm@26849
    83
  \end{matharray}
wenzelm@26849
    84
wenzelm@26849
    85
  \begin{rail}
wenzelm@26849
    86
    'split\_format' (((name *) + 'and') | ('(' 'complete' ')'))
wenzelm@26849
    87
    ;
wenzelm@26849
    88
  \end{rail}
wenzelm@26849
    89
wenzelm@26849
    90
  \begin{descr}
wenzelm@26849
    91
  
wenzelm@26894
    92
  \item [@{attribute (HOL) split_format}~@{text "p\<^sub>1 \<dots> p\<^sub>m
wenzelm@26849
    93
  \<AND> \<dots> \<AND> q\<^sub>1 \<dots> q\<^sub>n"}] puts expressions of
wenzelm@26849
    94
  low-level tuple types into canonical form as specified by the
wenzelm@26849
    95
  arguments given; the @{text i}-th collection of arguments refers to
wenzelm@26849
    96
  occurrences in premise @{text i} of the rule.  The ``@{text
wenzelm@26849
    97
  "(complete)"}'' option causes \emph{all} arguments in function
wenzelm@26849
    98
  applications to be represented canonically according to their tuple
wenzelm@26849
    99
  type structure.
wenzelm@26849
   100
wenzelm@26849
   101
  Note that these operations tend to invent funny names for new local
wenzelm@26849
   102
  parameters to be introduced.
wenzelm@26849
   103
wenzelm@26849
   104
  \end{descr}
wenzelm@26849
   105
*}
wenzelm@26849
   106
wenzelm@26849
   107
wenzelm@26849
   108
section {* Records \label{sec:hol-record} *}
wenzelm@26849
   109
wenzelm@26849
   110
text {*
wenzelm@26849
   111
  In principle, records merely generalize the concept of tuples, where
wenzelm@26849
   112
  components may be addressed by labels instead of just position.  The
wenzelm@26849
   113
  logical infrastructure of records in Isabelle/HOL is slightly more
wenzelm@26849
   114
  advanced, though, supporting truly extensible record schemes.  This
wenzelm@26849
   115
  admits operations that are polymorphic with respect to record
wenzelm@26849
   116
  extension, yielding ``object-oriented'' effects like (single)
wenzelm@26849
   117
  inheritance.  See also \cite{NaraschewskiW-TPHOLs98} for more
wenzelm@26849
   118
  details on object-oriented verification and record subtyping in HOL.
wenzelm@26849
   119
*}
wenzelm@26849
   120
wenzelm@26849
   121
wenzelm@26849
   122
subsection {* Basic concepts *}
wenzelm@26849
   123
wenzelm@26849
   124
text {*
wenzelm@26849
   125
  Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
wenzelm@26849
   126
  at the level of terms and types.  The notation is as follows:
wenzelm@26849
   127
wenzelm@26849
   128
  \begin{center}
wenzelm@26849
   129
  \begin{tabular}{l|l|l}
wenzelm@26849
   130
    & record terms & record types \\ \hline
wenzelm@26849
   131
    fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
wenzelm@26849
   132
    schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
wenzelm@26849
   133
      @{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
wenzelm@26849
   134
  \end{tabular}
wenzelm@26849
   135
  \end{center}
wenzelm@26849
   136
wenzelm@26849
   137
  \noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
wenzelm@26849
   138
  "(| x = a |)"}.
wenzelm@26849
   139
wenzelm@26849
   140
  A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
wenzelm@26849
   141
  @{text a} and field @{text y} of value @{text b}.  The corresponding
wenzelm@26849
   142
  type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
wenzelm@26849
   143
  and @{text "b :: B"}.
wenzelm@26849
   144
wenzelm@26849
   145
  A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
wenzelm@26849
   146
  @{text x} and @{text y} as before, but also possibly further fields
wenzelm@26849
   147
  as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
wenzelm@26849
   148
  of the syntax).  The improper field ``@{text "\<dots>"}'' of a record
wenzelm@26849
   149
  scheme is called the \emph{more part}.  Logically it is just a free
wenzelm@26849
   150
  variable, which is occasionally referred to as ``row variable'' in
wenzelm@26849
   151
  the literature.  The more part of a record scheme may be
wenzelm@26849
   152
  instantiated by zero or more further components.  For example, the
wenzelm@26849
   153
  previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
wenzelm@26852
   154
  c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
wenzelm@26849
   155
  Fixed records are special instances of record schemes, where
wenzelm@26849
   156
  ``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
wenzelm@26849
   157
  element.  In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
wenzelm@26849
   158
  for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
wenzelm@26849
   159
  
wenzelm@26849
   160
  \medskip Two key observations make extensible records in a simply
wenzelm@26849
   161
  typed language like HOL work out:
wenzelm@26849
   162
wenzelm@26849
   163
  \begin{enumerate}
wenzelm@26849
   164
wenzelm@26849
   165
  \item the more part is internalized, as a free term or type
wenzelm@26849
   166
  variable,
wenzelm@26849
   167
wenzelm@26852
   168
  \item field names are externalized, they cannot be accessed within
wenzelm@26852
   169
  the logic as first-class values.
wenzelm@26849
   170
wenzelm@26849
   171
  \end{enumerate}
wenzelm@26849
   172
wenzelm@26849
   173
  \medskip In Isabelle/HOL record types have to be defined explicitly,
wenzelm@26849
   174
  fixing their field names and types, and their (optional) parent
wenzelm@26849
   175
  record.  Afterwards, records may be formed using above syntax, while
wenzelm@26849
   176
  obeying the canonical order of fields as given by their declaration.
wenzelm@26849
   177
  The record package provides several standard operations like
wenzelm@26849
   178
  selectors and updates.  The common setup for various generic proof
wenzelm@26849
   179
  tools enable succinct reasoning patterns.  See also the Isabelle/HOL
wenzelm@26849
   180
  tutorial \cite{isabelle-hol-book} for further instructions on using
wenzelm@26849
   181
  records in practice.
wenzelm@26849
   182
*}
wenzelm@26849
   183
wenzelm@26849
   184
wenzelm@26849
   185
subsection {* Record specifications *}
wenzelm@26849
   186
wenzelm@26849
   187
text {*
wenzelm@26849
   188
  \begin{matharray}{rcl}
wenzelm@26849
   189
    @{command_def (HOL) "record"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   190
  \end{matharray}
wenzelm@26849
   191
wenzelm@26849
   192
  \begin{rail}
wenzelm@26849
   193
    'record' typespec '=' (type '+')? (constdecl +)
wenzelm@26849
   194
    ;
wenzelm@26849
   195
  \end{rail}
wenzelm@26849
   196
wenzelm@26849
   197
  \begin{descr}
wenzelm@26849
   198
wenzelm@26849
   199
  \item [@{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t
wenzelm@26849
   200
  = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1 \<dots> c\<^sub>n :: \<sigma>\<^sub>n"}] defines
wenzelm@26849
   201
  extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
wenzelm@26849
   202
  derived from the optional parent record @{text "\<tau>"} by adding new
wenzelm@26849
   203
  field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
wenzelm@26849
   204
wenzelm@26849
   205
  The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
wenzelm@26849
   206
  covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
wenzelm@26849
   207
  \<alpha>\<^sub>m"}.  Type constructor @{text t} has to be new, while @{text
wenzelm@26849
   208
  \<tau>} needs to specify an instance of an existing record type.  At
wenzelm@26849
   209
  least one new field @{text "c\<^sub>i"} has to be specified.
wenzelm@26849
   210
  Basically, field names need to belong to a unique record.  This is
wenzelm@26849
   211
  not a real restriction in practice, since fields are qualified by
wenzelm@26849
   212
  the record name internally.
wenzelm@26849
   213
wenzelm@26849
   214
  The parent record specification @{text \<tau>} is optional; if omitted
wenzelm@26849
   215
  @{text t} becomes a root record.  The hierarchy of all records
wenzelm@26849
   216
  declared within a theory context forms a forest structure, i.e.\ a
wenzelm@26849
   217
  set of trees starting with a root record each.  There is no way to
wenzelm@26849
   218
  merge multiple parent records!
wenzelm@26849
   219
wenzelm@26849
   220
  For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
wenzelm@26849
   221
  type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
wenzelm@26849
   222
  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
wenzelm@26849
   223
  "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
wenzelm@26849
   224
  @{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
wenzelm@26849
   225
  \<zeta>\<rparr>"}.
wenzelm@26849
   226
wenzelm@26849
   227
  \end{descr}
wenzelm@26849
   228
*}
wenzelm@26849
   229
wenzelm@26849
   230
wenzelm@26849
   231
subsection {* Record operations *}
wenzelm@26849
   232
wenzelm@26849
   233
text {*
wenzelm@26849
   234
  Any record definition of the form presented above produces certain
wenzelm@26849
   235
  standard operations.  Selectors and updates are provided for any
wenzelm@26849
   236
  field, including the improper one ``@{text more}''.  There are also
wenzelm@26849
   237
  cumulative record constructor functions.  To simplify the
wenzelm@26849
   238
  presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
wenzelm@26849
   239
  \<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
wenzelm@26849
   240
  \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
wenzelm@26849
   241
wenzelm@26849
   242
  \medskip \textbf{Selectors} and \textbf{updates} are available for
wenzelm@26849
   243
  any field (including ``@{text more}''):
wenzelm@26849
   244
wenzelm@26849
   245
  \begin{matharray}{lll}
wenzelm@26852
   246
    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
wenzelm@26852
   247
    @{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
   248
  \end{matharray}
wenzelm@26849
   249
wenzelm@26849
   250
  There is special syntax for application of updates: @{text "r\<lparr>x :=
wenzelm@26849
   251
  a\<rparr>"} abbreviates term @{text "x_update a r"}.  Further notation for
wenzelm@26849
   252
  repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
wenzelm@26849
   253
  c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}.  Note that
wenzelm@26849
   254
  because of postfix notation the order of fields shown here is
wenzelm@26849
   255
  reverse than in the actual term.  Since repeated updates are just
wenzelm@26849
   256
  function applications, fields may be freely permuted in @{text "\<lparr>x
wenzelm@26849
   257
  := a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
wenzelm@26849
   258
  Thus commutativity of independent updates can be proven within the
wenzelm@26849
   259
  logic for any two fields, but not as a general theorem.
wenzelm@26849
   260
wenzelm@26849
   261
  \medskip The \textbf{make} operation provides a cumulative record
wenzelm@26849
   262
  constructor function:
wenzelm@26849
   263
wenzelm@26849
   264
  \begin{matharray}{lll}
wenzelm@26852
   265
    @{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26849
   266
  \end{matharray}
wenzelm@26849
   267
wenzelm@26849
   268
  \medskip We now reconsider the case of non-root records, which are
wenzelm@26849
   269
  derived of some parent.  In general, the latter may depend on
wenzelm@26849
   270
  another parent as well, resulting in a list of \emph{ancestor
wenzelm@26849
   271
  records}.  Appending the lists of fields of all ancestors results in
wenzelm@26849
   272
  a certain field prefix.  The record package automatically takes care
wenzelm@26849
   273
  of this by lifting operations over this context of ancestor fields.
wenzelm@26849
   274
  Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
wenzelm@26849
   275
  fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
wenzelm@26849
   276
  the above record operations will get the following types:
wenzelm@26849
   277
wenzelm@26852
   278
  \medskip
wenzelm@26852
   279
  \begin{tabular}{lll}
wenzelm@26852
   280
    @{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
wenzelm@26849
   281
    @{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow> 
wenzelm@26852
   282
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
wenzelm@26852
   283
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
wenzelm@26852
   284
    @{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
   285
      \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26852
   286
  \end{tabular}
wenzelm@26852
   287
  \medskip
wenzelm@26849
   288
wenzelm@26852
   289
  \noindent Some further operations address the extension aspect of a
wenzelm@26849
   290
  derived record scheme specifically: @{text "t.fields"} produces a
wenzelm@26849
   291
  record fragment consisting of exactly the new fields introduced here
wenzelm@26849
   292
  (the result may serve as a more part elsewhere); @{text "t.extend"}
wenzelm@26849
   293
  takes a fixed record and adds a given more part; @{text
wenzelm@26849
   294
  "t.truncate"} restricts a record scheme to a fixed record.
wenzelm@26849
   295
wenzelm@26852
   296
  \medskip
wenzelm@26852
   297
  \begin{tabular}{lll}
wenzelm@26852
   298
    @{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
wenzelm@26852
   299
    @{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
wenzelm@26852
   300
      \<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
wenzelm@26852
   301
    @{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
   302
  \end{tabular}
wenzelm@26852
   303
  \medskip
wenzelm@26849
   304
wenzelm@26849
   305
  \noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
wenzelm@26849
   306
  for root records.
wenzelm@26849
   307
*}
wenzelm@26849
   308
wenzelm@26849
   309
wenzelm@26849
   310
subsection {* Derived rules and proof tools *}
wenzelm@26849
   311
wenzelm@26849
   312
text {*
wenzelm@26849
   313
  The record package proves several results internally, declaring
wenzelm@26849
   314
  these facts to appropriate proof tools.  This enables users to
wenzelm@26849
   315
  reason about record structures quite conveniently.  Assume that
wenzelm@26849
   316
  @{text t} is a record type as specified above.
wenzelm@26849
   317
wenzelm@26849
   318
  \begin{enumerate}
wenzelm@26849
   319
  
wenzelm@26849
   320
  \item Standard conversions for selectors or updates applied to
wenzelm@26849
   321
  record constructor terms are made part of the default Simplifier
wenzelm@26849
   322
  context; thus proofs by reduction of basic operations merely require
wenzelm@26849
   323
  the @{method simp} method without further arguments.  These rules
wenzelm@26849
   324
  are available as @{text "t.simps"}, too.
wenzelm@26849
   325
  
wenzelm@26849
   326
  \item Selectors applied to updated records are automatically reduced
wenzelm@26849
   327
  by an internal simplification procedure, which is also part of the
wenzelm@26849
   328
  standard Simplifier setup.
wenzelm@26849
   329
wenzelm@26849
   330
  \item Inject equations of a form analogous to @{prop "(x, y) = (x',
wenzelm@26849
   331
  y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
wenzelm@26849
   332
  Reasoner as @{attribute iff} rules.  These rules are available as
wenzelm@26849
   333
  @{text "t.iffs"}.
wenzelm@26849
   334
wenzelm@26849
   335
  \item The introduction rule for record equality analogous to @{text
wenzelm@26849
   336
  "x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
wenzelm@26849
   337
  and as the basic rule context as ``@{attribute intro}@{text "?"}''.
wenzelm@26849
   338
  The rule is called @{text "t.equality"}.
wenzelm@26849
   339
wenzelm@26849
   340
  \item Representations of arbitrary record expressions as canonical
wenzelm@26849
   341
  constructor terms are provided both in @{method cases} and @{method
wenzelm@26849
   342
  induct} format (cf.\ the generic proof methods of the same name,
wenzelm@26849
   343
  \secref{sec:cases-induct}).  Several variations are available, for
wenzelm@26849
   344
  fixed records, record schemes, more parts etc.
wenzelm@26849
   345
  
wenzelm@26849
   346
  The generic proof methods are sufficiently smart to pick the most
wenzelm@26849
   347
  sensible rule according to the type of the indicated record
wenzelm@26849
   348
  expression: users just need to apply something like ``@{text "(cases
wenzelm@26849
   349
  r)"}'' to a certain proof problem.
wenzelm@26849
   350
wenzelm@26849
   351
  \item The derived record operations @{text "t.make"}, @{text
wenzelm@26849
   352
  "t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
wenzelm@26849
   353
  treated automatically, but usually need to be expanded by hand,
wenzelm@26849
   354
  using the collective fact @{text "t.defs"}.
wenzelm@26849
   355
wenzelm@26849
   356
  \end{enumerate}
wenzelm@26849
   357
*}
wenzelm@26849
   358
wenzelm@26849
   359
wenzelm@26849
   360
section {* Datatypes \label{sec:hol-datatype} *}
wenzelm@26849
   361
wenzelm@26849
   362
text {*
wenzelm@26849
   363
  \begin{matharray}{rcl}
wenzelm@26849
   364
    @{command_def (HOL) "datatype"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   365
    @{command_def (HOL) "rep_datatype"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   366
  \end{matharray}
wenzelm@26849
   367
wenzelm@26849
   368
  \begin{rail}
wenzelm@26849
   369
    'datatype' (dtspec + 'and')
wenzelm@26849
   370
    ;
wenzelm@26849
   371
    'rep\_datatype' (name *) dtrules
wenzelm@26849
   372
    ;
wenzelm@26849
   373
wenzelm@26849
   374
    dtspec: parname? typespec infix? '=' (cons + '|')
wenzelm@26849
   375
    ;
wenzelm@26849
   376
    cons: name (type *) mixfix?
wenzelm@26849
   377
    ;
wenzelm@26849
   378
    dtrules: 'distinct' thmrefs 'inject' thmrefs 'induction' thmrefs
wenzelm@26849
   379
  \end{rail}
wenzelm@26849
   380
wenzelm@26849
   381
  \begin{descr}
wenzelm@26849
   382
wenzelm@26849
   383
  \item [@{command (HOL) "datatype"}] defines inductive datatypes in
wenzelm@26849
   384
  HOL.
wenzelm@26849
   385
wenzelm@26849
   386
  \item [@{command (HOL) "rep_datatype"}] represents existing types as
wenzelm@26849
   387
  inductive ones, generating the standard infrastructure of derived
wenzelm@26849
   388
  concepts (primitive recursion etc.).
wenzelm@26849
   389
wenzelm@26849
   390
  \end{descr}
wenzelm@26849
   391
wenzelm@26849
   392
  The induction and exhaustion theorems generated provide case names
wenzelm@26849
   393
  according to the constructors involved, while parameters are named
wenzelm@26849
   394
  after the types (see also \secref{sec:cases-induct}).
wenzelm@26849
   395
wenzelm@26849
   396
  See \cite{isabelle-HOL} for more details on datatypes, but beware of
wenzelm@26849
   397
  the old-style theory syntax being used there!  Apart from proper
wenzelm@26849
   398
  proof methods for case-analysis and induction, there are also
wenzelm@26849
   399
  emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
wenzelm@26849
   400
  induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
wenzelm@26849
   401
  to refer directly to the internal structure of subgoals (including
wenzelm@26849
   402
  internally bound parameters).
wenzelm@26849
   403
*}
wenzelm@26849
   404
wenzelm@26849
   405
wenzelm@26849
   406
section {* Recursive functions \label{sec:recursion} *}
wenzelm@26849
   407
wenzelm@26849
   408
text {*
wenzelm@26849
   409
  \begin{matharray}{rcl}
wenzelm@26849
   410
    @{command_def (HOL) "primrec"} & : & \isarkeep{local{\dsh}theory} \\
wenzelm@26849
   411
    @{command_def (HOL) "fun"} & : & \isarkeep{local{\dsh}theory} \\
wenzelm@26849
   412
    @{command_def (HOL) "function"} & : & \isartrans{local{\dsh}theory}{proof(prove)} \\
wenzelm@26849
   413
    @{command_def (HOL) "termination"} & : & \isartrans{local{\dsh}theory}{proof(prove)} \\
wenzelm@26849
   414
  \end{matharray}
wenzelm@26849
   415
wenzelm@26849
   416
  \begin{rail}
wenzelm@26849
   417
    'primrec' target? fixes 'where' equations
wenzelm@26849
   418
    ;
wenzelm@26849
   419
    equations: (thmdecl? prop + '|')
wenzelm@26849
   420
    ;
wenzelm@26985
   421
    ('fun' | 'function') target? functionopts? fixes 'where' clauses
wenzelm@26849
   422
    ;
wenzelm@26849
   423
    clauses: (thmdecl? prop ('(' 'otherwise' ')')? + '|')
wenzelm@26849
   424
    ;
wenzelm@26985
   425
    functionopts: '(' (('sequential' | 'domintros' | 'tailrec' | 'default' term) + ',') ')'
wenzelm@26849
   426
    ;
wenzelm@26849
   427
    'termination' ( term )?
wenzelm@26849
   428
  \end{rail}
wenzelm@26849
   429
wenzelm@26849
   430
  \begin{descr}
wenzelm@26849
   431
wenzelm@26849
   432
  \item [@{command (HOL) "primrec"}] defines primitive recursive
wenzelm@26849
   433
  functions over datatypes, see also \cite{isabelle-HOL}.
wenzelm@26849
   434
wenzelm@26849
   435
  \item [@{command (HOL) "function"}] defines functions by general
wenzelm@26849
   436
  wellfounded recursion. A detailed description with examples can be
wenzelm@26849
   437
  found in \cite{isabelle-function}. The function is specified by a
wenzelm@26849
   438
  set of (possibly conditional) recursive equations with arbitrary
wenzelm@26849
   439
  pattern matching. The command generates proof obligations for the
wenzelm@26849
   440
  completeness and the compatibility of patterns.
wenzelm@26849
   441
wenzelm@26849
   442
  The defined function is considered partial, and the resulting
wenzelm@26849
   443
  simplification rules (named @{text "f.psimps"}) and induction rule
wenzelm@26849
   444
  (named @{text "f.pinduct"}) are guarded by a generated domain
wenzelm@26849
   445
  predicate @{text "f_dom"}. The @{command (HOL) "termination"}
wenzelm@26849
   446
  command can then be used to establish that the function is total.
wenzelm@26849
   447
wenzelm@26849
   448
  \item [@{command (HOL) "fun"}] is a shorthand notation for
wenzelm@26849
   449
  ``@{command (HOL) "function"}~@{text "(sequential)"}, followed by
wenzelm@26849
   450
  automated proof attempts regarding pattern matching and termination.
wenzelm@26849
   451
  See \cite{isabelle-function} for further details.
wenzelm@26849
   452
wenzelm@26849
   453
  \item [@{command (HOL) "termination"}~@{text f}] commences a
wenzelm@26849
   454
  termination proof for the previously defined function @{text f}.  If
wenzelm@26849
   455
  this is omitted, the command refers to the most recent function
wenzelm@26849
   456
  definition.  After the proof is closed, the recursive equations and
wenzelm@26849
   457
  the induction principle is established.
wenzelm@26849
   458
wenzelm@26849
   459
  \end{descr}
wenzelm@26849
   460
wenzelm@26849
   461
  %FIXME check
wenzelm@26849
   462
wenzelm@26849
   463
  Recursive definitions introduced by both the @{command (HOL)
wenzelm@26849
   464
  "primrec"} and the @{command (HOL) "function"} command accommodate
wenzelm@26849
   465
  reasoning by induction (cf.\ \secref{sec:cases-induct}): rule @{text
wenzelm@26849
   466
  "c.induct"} (where @{text c} is the name of the function definition)
wenzelm@26849
   467
  refers to a specific induction rule, with parameters named according
wenzelm@26849
   468
  to the user-specified equations.  Case names of @{command (HOL)
wenzelm@26849
   469
  "primrec"} are that of the datatypes involved, while those of
wenzelm@26849
   470
  @{command (HOL) "function"} are numbered (starting from 1).
wenzelm@26849
   471
wenzelm@26849
   472
  The equations provided by these packages may be referred later as
wenzelm@26849
   473
  theorem list @{text "f.simps"}, where @{text f} is the (collective)
wenzelm@26849
   474
  name of the functions defined.  Individual equations may be named
wenzelm@26849
   475
  explicitly as well.
wenzelm@26849
   476
wenzelm@26849
   477
  The @{command (HOL) "function"} command accepts the following
wenzelm@26849
   478
  options.
wenzelm@26849
   479
wenzelm@26849
   480
  \begin{descr}
wenzelm@26849
   481
wenzelm@26849
   482
  \item [@{text sequential}] enables a preprocessor which
wenzelm@26849
   483
  disambiguates overlapping patterns by making them mutually disjoint.
wenzelm@26849
   484
  Earlier equations take precedence over later ones.  This allows to
wenzelm@26849
   485
  give the specification in a format very similar to functional
wenzelm@26849
   486
  programming.  Note that the resulting simplification and induction
wenzelm@26849
   487
  rules correspond to the transformed specification, not the one given
wenzelm@26849
   488
  originally. This usually means that each equation given by the user
wenzelm@26849
   489
  may result in several theroems.  Also note that this automatic
wenzelm@26849
   490
  transformation only works for ML-style datatype patterns.
wenzelm@26849
   491
wenzelm@26849
   492
  \item [@{text domintros}] enables the automated generation of
wenzelm@26849
   493
  introduction rules for the domain predicate. While mostly not
wenzelm@26849
   494
  needed, they can be helpful in some proofs about partial functions.
wenzelm@26849
   495
wenzelm@26849
   496
  \item [@{text tailrec}] generates the unconstrained recursive
wenzelm@26849
   497
  equations even without a termination proof, provided that the
wenzelm@26849
   498
  function is tail-recursive. This currently only works
wenzelm@26849
   499
wenzelm@26849
   500
  \item [@{text "default d"}] allows to specify a default value for a
wenzelm@26849
   501
  (partial) function, which will ensure that @{text "f x = d x"}
wenzelm@26849
   502
  whenever @{text "x \<notin> f_dom"}.
wenzelm@26849
   503
wenzelm@26849
   504
  \end{descr}
wenzelm@26849
   505
*}
wenzelm@26849
   506
wenzelm@26849
   507
wenzelm@26849
   508
subsection {* Proof methods related to recursive definitions *}
wenzelm@26849
   509
wenzelm@26849
   510
text {*
wenzelm@26849
   511
  \begin{matharray}{rcl}
wenzelm@26849
   512
    @{method_def (HOL) pat_completeness} & : & \isarmeth \\
wenzelm@26849
   513
    @{method_def (HOL) relation} & : & \isarmeth \\
wenzelm@26849
   514
    @{method_def (HOL) lexicographic_order} & : & \isarmeth \\
wenzelm@26849
   515
  \end{matharray}
wenzelm@26849
   516
wenzelm@26849
   517
  \begin{rail}
wenzelm@26849
   518
    'relation' term
wenzelm@26849
   519
    ;
wenzelm@26849
   520
    'lexicographic\_order' (clasimpmod *)
wenzelm@26849
   521
    ;
wenzelm@26849
   522
  \end{rail}
wenzelm@26849
   523
wenzelm@26849
   524
  \begin{descr}
wenzelm@26849
   525
wenzelm@26849
   526
  \item [@{method (HOL) pat_completeness}] is a specialized method to
wenzelm@26849
   527
  solve goals regarding the completeness of pattern matching, as
wenzelm@26849
   528
  required by the @{command (HOL) "function"} package (cf.\
wenzelm@26849
   529
  \cite{isabelle-function}).
wenzelm@26849
   530
wenzelm@26849
   531
  \item [@{method (HOL) relation}~@{text R}] introduces a termination
wenzelm@26849
   532
  proof using the relation @{text R}.  The resulting proof state will
wenzelm@26849
   533
  contain goals expressing that @{text R} is wellfounded, and that the
wenzelm@26849
   534
  arguments of recursive calls decrease with respect to @{text R}.
wenzelm@26849
   535
  Usually, this method is used as the initial proof step of manual
wenzelm@26849
   536
  termination proofs.
wenzelm@26849
   537
wenzelm@26849
   538
  \item [@{method (HOL) "lexicographic_order"}] attempts a fully
wenzelm@26849
   539
  automated termination proof by searching for a lexicographic
wenzelm@26849
   540
  combination of size measures on the arguments of the function. The
wenzelm@26849
   541
  method accepts the same arguments as the @{method auto} method,
wenzelm@26849
   542
  which it uses internally to prove local descents.  The same context
wenzelm@26849
   543
  modifiers as for @{method auto} are accepted, see
wenzelm@26849
   544
  \secref{sec:clasimp}.
wenzelm@26849
   545
wenzelm@26849
   546
  In case of failure, extensive information is printed, which can help
wenzelm@26849
   547
  to analyse the situation (cf.\ \cite{isabelle-function}).
wenzelm@26849
   548
wenzelm@26849
   549
  \end{descr}
wenzelm@26849
   550
*}
wenzelm@26849
   551
wenzelm@26849
   552
wenzelm@26849
   553
subsection {* Old-style recursive function definitions (TFL) *}
wenzelm@26849
   554
wenzelm@26849
   555
text {*
wenzelm@26849
   556
  The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
wenzelm@26849
   557
  "recdef_tc"} for defining recursive are mostly obsolete; @{command
wenzelm@26849
   558
  (HOL) "function"} or @{command (HOL) "fun"} should be used instead.
wenzelm@26849
   559
wenzelm@26849
   560
  \begin{matharray}{rcl}
wenzelm@26849
   561
    @{command_def (HOL) "recdef"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   562
    @{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & \isartrans{theory}{proof(prove)} \\
wenzelm@26849
   563
  \end{matharray}
wenzelm@26849
   564
wenzelm@26849
   565
  \begin{rail}
wenzelm@26849
   566
    'recdef' ('(' 'permissive' ')')? \\ name term (prop +) hints?
wenzelm@26849
   567
    ;
wenzelm@26849
   568
    recdeftc thmdecl? tc
wenzelm@26849
   569
    ;
wenzelm@26849
   570
    hints: '(' 'hints' (recdefmod *) ')'
wenzelm@26849
   571
    ;
wenzelm@26849
   572
    recdefmod: (('recdef\_simp' | 'recdef\_cong' | 'recdef\_wf') (() | 'add' | 'del') ':' thmrefs) | clasimpmod
wenzelm@26849
   573
    ;
wenzelm@26849
   574
    tc: nameref ('(' nat ')')?
wenzelm@26849
   575
    ;
wenzelm@26849
   576
  \end{rail}
wenzelm@26849
   577
wenzelm@26849
   578
  \begin{descr}
wenzelm@26849
   579
  
wenzelm@26849
   580
  \item [@{command (HOL) "recdef"}] defines general well-founded
wenzelm@26849
   581
  recursive functions (using the TFL package), see also
wenzelm@26849
   582
  \cite{isabelle-HOL}.  The ``@{text "(permissive)"}'' option tells
wenzelm@26849
   583
  TFL to recover from failed proof attempts, returning unfinished
wenzelm@26849
   584
  results.  The @{text recdef_simp}, @{text recdef_cong}, and @{text
wenzelm@26849
   585
  recdef_wf} hints refer to auxiliary rules to be used in the internal
wenzelm@26849
   586
  automated proof process of TFL.  Additional @{syntax clasimpmod}
wenzelm@26849
   587
  declarations (cf.\ \secref{sec:clasimp}) may be given to tune the
wenzelm@26849
   588
  context of the Simplifier (cf.\ \secref{sec:simplifier}) and
wenzelm@26849
   589
  Classical reasoner (cf.\ \secref{sec:classical}).
wenzelm@26849
   590
  
wenzelm@26849
   591
  \item [@{command (HOL) "recdef_tc"}~@{text "c (i)"}] recommences the
wenzelm@26849
   592
  proof for leftover termination condition number @{text i} (default
wenzelm@26849
   593
  1) as generated by a @{command (HOL) "recdef"} definition of
wenzelm@26849
   594
  constant @{text c}.
wenzelm@26849
   595
  
wenzelm@26849
   596
  Note that in most cases, @{command (HOL) "recdef"} is able to finish
wenzelm@26849
   597
  its internal proofs without manual intervention.
wenzelm@26849
   598
wenzelm@26849
   599
  \end{descr}
wenzelm@26849
   600
wenzelm@26849
   601
  \medskip Hints for @{command (HOL) "recdef"} may be also declared
wenzelm@26849
   602
  globally, using the following attributes.
wenzelm@26849
   603
wenzelm@26849
   604
  \begin{matharray}{rcl}
wenzelm@26849
   605
    @{attribute_def (HOL) recdef_simp} & : & \isaratt \\
wenzelm@26849
   606
    @{attribute_def (HOL) recdef_cong} & : & \isaratt \\
wenzelm@26849
   607
    @{attribute_def (HOL) recdef_wf} & : & \isaratt \\
wenzelm@26849
   608
  \end{matharray}
wenzelm@26849
   609
wenzelm@26849
   610
  \begin{rail}
wenzelm@26849
   611
    ('recdef\_simp' | 'recdef\_cong' | 'recdef\_wf') (() | 'add' | 'del')
wenzelm@26849
   612
    ;
wenzelm@26849
   613
  \end{rail}
wenzelm@26849
   614
*}
wenzelm@26849
   615
wenzelm@26849
   616
wenzelm@26849
   617
section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
wenzelm@26849
   618
wenzelm@26849
   619
text {*
wenzelm@26849
   620
  An \textbf{inductive definition} specifies the least predicate (or
wenzelm@26849
   621
  set) @{text R} closed under given rules: applying a rule to elements
wenzelm@26849
   622
  of @{text R} yields a result within @{text R}.  For example, a
wenzelm@26849
   623
  structural operational semantics is an inductive definition of an
wenzelm@26849
   624
  evaluation relation.
wenzelm@26849
   625
wenzelm@26849
   626
  Dually, a \textbf{coinductive definition} specifies the greatest
wenzelm@26849
   627
  predicate~/ set @{text R} that is consistent with given rules: every
wenzelm@26849
   628
  element of @{text R} can be seen as arising by applying a rule to
wenzelm@26849
   629
  elements of @{text R}.  An important example is using bisimulation
wenzelm@26849
   630
  relations to formalise equivalence of processes and infinite data
wenzelm@26849
   631
  structures.
wenzelm@26849
   632
wenzelm@26849
   633
  \medskip The HOL package is related to the ZF one, which is
wenzelm@26849
   634
  described in a separate paper,\footnote{It appeared in CADE
wenzelm@26849
   635
  \cite{paulson-CADE}; a longer version is distributed with Isabelle.}
wenzelm@26849
   636
  which you should refer to in case of difficulties.  The package is
wenzelm@26849
   637
  simpler than that of ZF thanks to implicit type-checking in HOL.
wenzelm@26849
   638
  The types of the (co)inductive predicates (or sets) determine the
wenzelm@26849
   639
  domain of the fixedpoint definition, and the package does not have
wenzelm@26849
   640
  to use inference rules for type-checking.
wenzelm@26849
   641
wenzelm@26849
   642
  \begin{matharray}{rcl}
wenzelm@26849
   643
    @{command_def (HOL) "inductive"} & : & \isarkeep{local{\dsh}theory} \\
wenzelm@26849
   644
    @{command_def (HOL) "inductive_set"} & : & \isarkeep{local{\dsh}theory} \\
wenzelm@26849
   645
    @{command_def (HOL) "coinductive"} & : & \isarkeep{local{\dsh}theory} \\
wenzelm@26849
   646
    @{command_def (HOL) "coinductive_set"} & : & \isarkeep{local{\dsh}theory} \\
wenzelm@26849
   647
    @{attribute_def (HOL) mono} & : & \isaratt \\
wenzelm@26849
   648
  \end{matharray}
wenzelm@26849
   649
wenzelm@26849
   650
  \begin{rail}
wenzelm@26849
   651
    ('inductive' | 'inductive\_set' | 'coinductive' | 'coinductive\_set') target? fixes ('for' fixes)? \\
wenzelm@26849
   652
    ('where' clauses)? ('monos' thmrefs)?
wenzelm@26849
   653
    ;
wenzelm@26849
   654
    clauses: (thmdecl? prop + '|')
wenzelm@26849
   655
    ;
wenzelm@26849
   656
    'mono' (() | 'add' | 'del')
wenzelm@26849
   657
    ;
wenzelm@26849
   658
  \end{rail}
wenzelm@26849
   659
wenzelm@26849
   660
  \begin{descr}
wenzelm@26849
   661
wenzelm@26849
   662
  \item [@{command (HOL) "inductive"} and @{command (HOL)
wenzelm@26849
   663
  "coinductive"}] define (co)inductive predicates from the
wenzelm@26849
   664
  introduction rules given in the @{keyword "where"} part.  The
wenzelm@26849
   665
  optional @{keyword "for"} part contains a list of parameters of the
wenzelm@26849
   666
  (co)inductive predicates that remain fixed throughout the
wenzelm@26849
   667
  definition.  The optional @{keyword "monos"} section contains
wenzelm@26849
   668
  \emph{monotonicity theorems}, which are required for each operator
wenzelm@26849
   669
  applied to a recursive set in the introduction rules.  There
wenzelm@26849
   670
  \emph{must} be a theorem of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"},
wenzelm@26849
   671
  for each premise @{text "M R\<^sub>i t"} in an introduction rule!
wenzelm@26849
   672
wenzelm@26849
   673
  \item [@{command (HOL) "inductive_set"} and @{command (HOL)
wenzelm@26849
   674
  "coinductive_set"}] are wrappers for to the previous commands,
wenzelm@26849
   675
  allowing the definition of (co)inductive sets.
wenzelm@26849
   676
wenzelm@26849
   677
  \item [@{attribute (HOL) mono}] declares monotonicity rules.  These
wenzelm@26849
   678
  rule are involved in the automated monotonicity proof of @{command
wenzelm@26849
   679
  (HOL) "inductive"}.
wenzelm@26849
   680
wenzelm@26849
   681
  \end{descr}
wenzelm@26849
   682
*}
wenzelm@26849
   683
wenzelm@26849
   684
wenzelm@26849
   685
subsection {* Derived rules *}
wenzelm@26849
   686
wenzelm@26849
   687
text {*
wenzelm@26849
   688
  Each (co)inductive definition @{text R} adds definitions to the
wenzelm@26849
   689
  theory and also proves some theorems:
wenzelm@26849
   690
wenzelm@26849
   691
  \begin{description}
wenzelm@26849
   692
wenzelm@26849
   693
  \item [@{text R.intros}] is the list of introduction rules as proven
wenzelm@26849
   694
  theorems, for the recursive predicates (or sets).  The rules are
wenzelm@26849
   695
  also available individually, using the names given them in the
wenzelm@26849
   696
  theory file;
wenzelm@26849
   697
wenzelm@26849
   698
  \item [@{text R.cases}] is the case analysis (or elimination) rule;
wenzelm@26849
   699
wenzelm@26849
   700
  \item [@{text R.induct} or @{text R.coinduct}] is the (co)induction
wenzelm@26849
   701
  rule.
wenzelm@26849
   702
wenzelm@26849
   703
  \end{description}
wenzelm@26849
   704
wenzelm@26849
   705
  When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
wenzelm@26849
   706
  defined simultaneously, the list of introduction rules is called
wenzelm@26849
   707
  @{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
wenzelm@26849
   708
  called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
wenzelm@26849
   709
  of mutual induction rules is called @{text
wenzelm@26849
   710
  "R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
wenzelm@26849
   711
*}
wenzelm@26849
   712
wenzelm@26849
   713
wenzelm@26849
   714
subsection {* Monotonicity theorems *}
wenzelm@26849
   715
wenzelm@26849
   716
text {*
wenzelm@26849
   717
  Each theory contains a default set of theorems that are used in
wenzelm@26849
   718
  monotonicity proofs.  New rules can be added to this set via the
wenzelm@26849
   719
  @{attribute (HOL) mono} attribute.  The HOL theory @{text Inductive}
wenzelm@26849
   720
  shows how this is done.  In general, the following monotonicity
wenzelm@26849
   721
  theorems may be added:
wenzelm@26849
   722
wenzelm@26849
   723
  \begin{itemize}
wenzelm@26849
   724
wenzelm@26849
   725
  \item Theorems of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"}, for proving
wenzelm@26849
   726
  monotonicity of inductive definitions whose introduction rules have
wenzelm@26849
   727
  premises involving terms such as @{text "M R\<^sub>i t"}.
wenzelm@26849
   728
wenzelm@26849
   729
  \item Monotonicity theorems for logical operators, which are of the
wenzelm@26849
   730
  general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}.  For example, in
wenzelm@26849
   731
  the case of the operator @{text "\<or>"}, the corresponding theorem is
wenzelm@26849
   732
  \[
wenzelm@26849
   733
  \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
   734
  \]
wenzelm@26849
   735
wenzelm@26849
   736
  \item De Morgan style equations for reasoning about the ``polarity''
wenzelm@26849
   737
  of expressions, e.g.
wenzelm@26849
   738
  \[
wenzelm@26849
   739
  @{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
wenzelm@26849
   740
  @{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
wenzelm@26849
   741
  \]
wenzelm@26849
   742
wenzelm@26849
   743
  \item Equations for reducing complex operators to more primitive
wenzelm@26849
   744
  ones whose monotonicity can easily be proved, e.g.
wenzelm@26849
   745
  \[
wenzelm@26849
   746
  @{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
wenzelm@26849
   747
  @{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
wenzelm@26849
   748
  \]
wenzelm@26849
   749
wenzelm@26849
   750
  \end{itemize}
wenzelm@26849
   751
wenzelm@26849
   752
  %FIXME: Example of an inductive definition
wenzelm@26849
   753
*}
wenzelm@26849
   754
wenzelm@26849
   755
wenzelm@26849
   756
section {* Arithmetic proof support *}
wenzelm@26849
   757
wenzelm@26849
   758
text {*
wenzelm@26849
   759
  \begin{matharray}{rcl}
wenzelm@26849
   760
    @{method_def (HOL) arith} & : & \isarmeth \\
wenzelm@26894
   761
    @{attribute_def (HOL) arith_split} & : & \isaratt \\
wenzelm@26849
   762
  \end{matharray}
wenzelm@26849
   763
wenzelm@26849
   764
  The @{method (HOL) arith} method decides linear arithmetic problems
wenzelm@26849
   765
  (on types @{text nat}, @{text int}, @{text real}).  Any current
wenzelm@26849
   766
  facts are inserted into the goal before running the procedure.
wenzelm@26849
   767
wenzelm@26894
   768
  The @{attribute (HOL) arith_split} attribute declares case split
wenzelm@26894
   769
  rules to be expanded before the arithmetic procedure is invoked.
wenzelm@26849
   770
wenzelm@26849
   771
  Note that a simpler (but faster) version of arithmetic reasoning is
wenzelm@26849
   772
  already performed by the Simplifier.
wenzelm@26849
   773
*}
wenzelm@26849
   774
wenzelm@26849
   775
wenzelm@27123
   776
section {* Unstructured cases analysis and induction \label{sec:hol-induct-tac} *}
wenzelm@26849
   777
wenzelm@26849
   778
text {*
wenzelm@27123
   779
  The following tools of Isabelle/HOL support cases analysis and
wenzelm@27123
   780
  induction in unstructured tactic scripts; see also
wenzelm@27123
   781
  \secref{sec:cases-induct} for proper Isar versions of similar ideas.
wenzelm@26849
   782
wenzelm@26849
   783
  \begin{matharray}{rcl}
wenzelm@26849
   784
    @{method_def (HOL) case_tac}@{text "\<^sup>*"} & : & \isarmeth \\
wenzelm@26849
   785
    @{method_def (HOL) induct_tac}@{text "\<^sup>*"} & : & \isarmeth \\
wenzelm@26849
   786
    @{method_def (HOL) ind_cases}@{text "\<^sup>*"} & : & \isarmeth \\
wenzelm@27123
   787
    @{command_def (HOL) "inductive_cases"}@{text "\<^sup>*"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   788
  \end{matharray}
wenzelm@26849
   789
wenzelm@26849
   790
  \begin{rail}
wenzelm@26849
   791
    'case\_tac' goalspec? term rule?
wenzelm@26849
   792
    ;
wenzelm@26849
   793
    'induct\_tac' goalspec? (insts * 'and') rule?
wenzelm@26849
   794
    ;
wenzelm@26849
   795
    'ind\_cases' (prop +) ('for' (name +)) ?
wenzelm@26849
   796
    ;
wenzelm@26849
   797
    'inductive\_cases' (thmdecl? (prop +) + 'and')
wenzelm@26849
   798
    ;
wenzelm@26849
   799
wenzelm@26849
   800
    rule: ('rule' ':' thmref)
wenzelm@26849
   801
    ;
wenzelm@26849
   802
  \end{rail}
wenzelm@26849
   803
wenzelm@26849
   804
  \begin{descr}
wenzelm@26849
   805
wenzelm@26849
   806
  \item [@{method (HOL) case_tac} and @{method (HOL) induct_tac}]
wenzelm@27123
   807
  admit to reason about inductive types.  Rules are selected according
wenzelm@27123
   808
  to the declarations by the @{attribute cases} and @{attribute
wenzelm@27123
   809
  induct} attributes, cf.\ \secref{sec:cases-induct}.  The @{command
wenzelm@27123
   810
  (HOL) datatype} package already takes care of this.
wenzelm@27123
   811
wenzelm@27123
   812
  These unstructured tactics feature both goal addressing and dynamic
wenzelm@26849
   813
  instantiation.  Note that named rule cases are \emph{not} provided
wenzelm@27123
   814
  as would be by the proper @{method cases} and @{method induct} proof
wenzelm@27123
   815
  methods (see \secref{sec:cases-induct}).  Unlike the @{method
wenzelm@27123
   816
  induct} method, @{method induct_tac} does not handle structured rule
wenzelm@27123
   817
  statements, only the compact object-logic conclusion of the subgoal
wenzelm@27123
   818
  being addressed.
wenzelm@26849
   819
  
wenzelm@26849
   820
  \item [@{method (HOL) ind_cases} and @{command (HOL)
wenzelm@26860
   821
  "inductive_cases"}] provide an interface to the internal @{ML_text
wenzelm@26860
   822
  mk_cases} operation.  Rules are simplified in an unrestricted
wenzelm@26860
   823
  forward manner.
wenzelm@26849
   824
wenzelm@26849
   825
  While @{method (HOL) ind_cases} is a proof method to apply the
wenzelm@26849
   826
  result immediately as elimination rules, @{command (HOL)
wenzelm@26849
   827
  "inductive_cases"} provides case split theorems at the theory level
wenzelm@26849
   828
  for later use.  The @{keyword "for"} argument of the @{method (HOL)
wenzelm@26849
   829
  ind_cases} method allows to specify a list of variables that should
wenzelm@26849
   830
  be generalized before applying the resulting rule.
wenzelm@26849
   831
wenzelm@26849
   832
  \end{descr}
wenzelm@26849
   833
*}
wenzelm@26849
   834
wenzelm@26849
   835
wenzelm@26849
   836
section {* Executable code *}
wenzelm@26849
   837
wenzelm@26849
   838
text {*
wenzelm@26849
   839
  Isabelle/Pure provides two generic frameworks to support code
wenzelm@26849
   840
  generation from executable specifications.  Isabelle/HOL
wenzelm@26849
   841
  instantiates these mechanisms in a way that is amenable to end-user
wenzelm@26849
   842
  applications.
wenzelm@26849
   843
wenzelm@26849
   844
  One framework generates code from both functional and relational
wenzelm@26849
   845
  programs to SML.  See \cite{isabelle-HOL} for further information
wenzelm@26849
   846
  (this actually covers the new-style theory format as well).
wenzelm@26849
   847
wenzelm@26849
   848
  \begin{matharray}{rcl}
wenzelm@26849
   849
    @{command_def (HOL) "value"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
wenzelm@26849
   850
    @{command_def (HOL) "code_module"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   851
    @{command_def (HOL) "code_library"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   852
    @{command_def (HOL) "consts_code"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   853
    @{command_def (HOL) "types_code"} & : & \isartrans{theory}{theory} \\  
wenzelm@26849
   854
    @{attribute_def (HOL) code} & : & \isaratt \\
wenzelm@26849
   855
  \end{matharray}
wenzelm@26849
   856
wenzelm@26849
   857
  \begin{rail}
wenzelm@26849
   858
  'value' term
wenzelm@26849
   859
  ;
wenzelm@26849
   860
wenzelm@26849
   861
  ( 'code\_module' | 'code\_library' ) modespec ? name ? \\
wenzelm@26849
   862
    ( 'file' name ) ? ( 'imports' ( name + ) ) ? \\
wenzelm@26849
   863
    'contains' ( ( name '=' term ) + | term + )
wenzelm@26849
   864
  ;
wenzelm@26849
   865
wenzelm@26849
   866
  modespec: '(' ( name * ) ')'
wenzelm@26849
   867
  ;
wenzelm@26849
   868
wenzelm@26849
   869
  'consts\_code' (codespec +)
wenzelm@26849
   870
  ;
wenzelm@26849
   871
wenzelm@26849
   872
  codespec: const template attachment ?
wenzelm@26849
   873
  ;
wenzelm@26849
   874
wenzelm@26849
   875
  'types\_code' (tycodespec +)
wenzelm@26849
   876
  ;
wenzelm@26849
   877
wenzelm@26849
   878
  tycodespec: name template attachment ?
wenzelm@26849
   879
  ;
wenzelm@26849
   880
wenzelm@26849
   881
  const: term
wenzelm@26849
   882
  ;
wenzelm@26849
   883
wenzelm@26849
   884
  template: '(' string ')'
wenzelm@26849
   885
  ;
wenzelm@26849
   886
wenzelm@26849
   887
  attachment: 'attach' modespec ? verblbrace text verbrbrace
wenzelm@26849
   888
  ;
wenzelm@26849
   889
wenzelm@26849
   890
  'code' (name)?
wenzelm@26849
   891
  ;
wenzelm@26849
   892
  \end{rail}
wenzelm@26849
   893
wenzelm@26849
   894
  \begin{descr}
wenzelm@26849
   895
wenzelm@26849
   896
  \item [@{command (HOL) "value"}~@{text t}] evaluates and prints a
wenzelm@26849
   897
  term using the code generator.
wenzelm@26849
   898
wenzelm@26849
   899
  \end{descr}
wenzelm@26849
   900
wenzelm@26849
   901
  \medskip The other framework generates code from functional programs
wenzelm@26849
   902
  (including overloading using type classes) to SML \cite{SML}, OCaml
wenzelm@26849
   903
  \cite{OCaml} and Haskell \cite{haskell-revised-report}.
wenzelm@26849
   904
  Conceptually, code generation is split up in three steps:
wenzelm@26849
   905
  \emph{selection} of code theorems, \emph{translation} into an
wenzelm@26849
   906
  abstract executable view and \emph{serialization} to a specific
wenzelm@26849
   907
  \emph{target language}.  See \cite{isabelle-codegen} for an
wenzelm@26849
   908
  introduction on how to use it.
wenzelm@26849
   909
wenzelm@26849
   910
  \begin{matharray}{rcl}
wenzelm@26849
   911
    @{command_def (HOL) "export_code"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
wenzelm@26849
   912
    @{command_def (HOL) "code_thms"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
wenzelm@26849
   913
    @{command_def (HOL) "code_deps"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
wenzelm@26849
   914
    @{command_def (HOL) "code_datatype"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   915
    @{command_def (HOL) "code_const"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   916
    @{command_def (HOL) "code_type"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   917
    @{command_def (HOL) "code_class"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   918
    @{command_def (HOL) "code_instance"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   919
    @{command_def (HOL) "code_monad"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   920
    @{command_def (HOL) "code_reserved"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   921
    @{command_def (HOL) "code_include"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   922
    @{command_def (HOL) "code_modulename"} & : & \isartrans{theory}{theory} \\
haftmann@27103
   923
    @{command_def (HOL) "code_abort"} & : & \isartrans{theory}{theory} \\
wenzelm@26849
   924
    @{command_def (HOL) "print_codesetup"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
wenzelm@26849
   925
    @{attribute_def (HOL) code} & : & \isaratt \\
wenzelm@26849
   926
  \end{matharray}
wenzelm@26849
   927
wenzelm@26849
   928
  \begin{rail}
wenzelm@26849
   929
    'export\_code' ( constexpr + ) ? \\
wenzelm@26849
   930
      ( ( 'in' target ( 'module\_name' string ) ? \\
wenzelm@26849
   931
        ( 'file' ( string | '-' ) ) ? ( '(' args ')' ) ?) + ) ?
wenzelm@26849
   932
    ;
wenzelm@26849
   933
wenzelm@26849
   934
    'code\_thms' ( constexpr + ) ?
wenzelm@26849
   935
    ;
wenzelm@26849
   936
wenzelm@26849
   937
    'code\_deps' ( constexpr + ) ?
wenzelm@26849
   938
    ;
wenzelm@26849
   939
wenzelm@26849
   940
    const: term
wenzelm@26849
   941
    ;
wenzelm@26849
   942
wenzelm@26849
   943
    constexpr: ( const | 'name.*' | '*' )
wenzelm@26849
   944
    ;
wenzelm@26849
   945
wenzelm@26849
   946
    typeconstructor: nameref
wenzelm@26849
   947
    ;
wenzelm@26849
   948
wenzelm@26849
   949
    class: nameref
wenzelm@26849
   950
    ;
wenzelm@26849
   951
wenzelm@26849
   952
    target: 'OCaml' | 'SML' | 'Haskell'
wenzelm@26849
   953
    ;
wenzelm@26849
   954
wenzelm@26849
   955
    'code\_datatype' const +
wenzelm@26849
   956
    ;
wenzelm@26849
   957
wenzelm@26849
   958
    'code\_const' (const + 'and') \\
wenzelm@26849
   959
      ( ( '(' target ( syntax ? + 'and' ) ')' ) + )
wenzelm@26849
   960
    ;
wenzelm@26849
   961
wenzelm@26849
   962
    'code\_type' (typeconstructor + 'and') \\
wenzelm@26849
   963
      ( ( '(' target ( syntax ? + 'and' ) ')' ) + )
wenzelm@26849
   964
    ;
wenzelm@26849
   965
wenzelm@26849
   966
    'code\_class' (class + 'and') \\
wenzelm@26849
   967
      ( ( '(' target \\
wenzelm@26849
   968
        ( ( string ('where' \\
wenzelm@26849
   969
          ( const ( '==' | equiv ) string ) + ) ? ) ? + 'and' ) ')' ) + )
wenzelm@26849
   970
    ;
wenzelm@26849
   971
wenzelm@26849
   972
    'code\_instance' (( typeconstructor '::' class ) + 'and') \\
wenzelm@26849
   973
      ( ( '(' target ( '-' ? + 'and' ) ')' ) + )
wenzelm@26849
   974
    ;
wenzelm@26849
   975
wenzelm@26849
   976
    'code\_monad' const const target
wenzelm@26849
   977
    ;
wenzelm@26849
   978
wenzelm@26849
   979
    'code\_reserved' target ( string + )
wenzelm@26849
   980
    ;
wenzelm@26849
   981
wenzelm@26849
   982
    'code\_include' target ( string ( string | '-') )
wenzelm@26849
   983
    ;
wenzelm@26849
   984
wenzelm@26849
   985
    'code\_modulename' target ( ( string string ) + )
wenzelm@26849
   986
    ;
wenzelm@26849
   987
wenzelm@26849
   988
    'code\_exception' ( const + )
wenzelm@26849
   989
    ;
wenzelm@26849
   990
wenzelm@26849
   991
    syntax: string | ( 'infix' | 'infixl' | 'infixr' ) nat string
wenzelm@26849
   992
    ;
wenzelm@26849
   993
wenzelm@26849
   994
    'code' ('func' | 'inline') ( 'del' )?
wenzelm@26849
   995
    ;
wenzelm@26849
   996
  \end{rail}
wenzelm@26849
   997
wenzelm@26849
   998
  \begin{descr}
wenzelm@26849
   999
wenzelm@26849
  1000
  \item [@{command (HOL) "export_code"}] is the canonical interface
wenzelm@26849
  1001
  for generating and serializing code: for a given list of constants,
wenzelm@26849
  1002
  code is generated for the specified target languages.  Abstract code
wenzelm@26849
  1003
  is cached incrementally.  If no constant is given, the currently
wenzelm@26849
  1004
  cached code is serialized.  If no serialization instruction is
wenzelm@26849
  1005
  given, only abstract code is cached.
wenzelm@26849
  1006
wenzelm@26849
  1007
  Constants may be specified by giving them literally, referring to
wenzelm@26849
  1008
  all executable contants within a certain theory by giving @{text
wenzelm@26849
  1009
  "name.*"}, or referring to \emph{all} executable constants currently
wenzelm@26849
  1010
  available by giving @{text "*"}.
wenzelm@26849
  1011
wenzelm@26849
  1012
  By default, for each involved theory one corresponding name space
wenzelm@26849
  1013
  module is generated.  Alternativly, a module name may be specified
wenzelm@26849
  1014
  after the @{keyword "module_name"} keyword; then \emph{all} code is
wenzelm@26849
  1015
  placed in this module.
wenzelm@26849
  1016
wenzelm@26849
  1017
  For \emph{SML} and \emph{OCaml}, the file specification refers to a
wenzelm@26849
  1018
  single file; for \emph{Haskell}, it refers to a whole directory,
wenzelm@26849
  1019
  where code is generated in multiple files reflecting the module
wenzelm@26849
  1020
  hierarchy.  The file specification ``@{text "-"}'' denotes standard
wenzelm@26849
  1021
  output.  For \emph{SML}, omitting the file specification compiles
wenzelm@26849
  1022
  code internally in the context of the current ML session.
wenzelm@26849
  1023
wenzelm@26849
  1024
  Serializers take an optional list of arguments in parentheses.  For
wenzelm@26849
  1025
  \emph{Haskell} a module name prefix may be given using the ``@{text
wenzelm@26849
  1026
  "root:"}'' argument; ``@{text string_classes}'' adds a ``@{verbatim
wenzelm@26849
  1027
  "deriving (Read, Show)"}'' clause to each appropriate datatype
wenzelm@26849
  1028
  declaration.
wenzelm@26849
  1029
wenzelm@26849
  1030
  \item [@{command (HOL) "code_thms"}] prints a list of theorems
wenzelm@26849
  1031
  representing the corresponding program containing all given
wenzelm@26849
  1032
  constants; if no constants are given, the currently cached code
wenzelm@26849
  1033
  theorems are printed.
wenzelm@26849
  1034
wenzelm@26849
  1035
  \item [@{command (HOL) "code_deps"}] visualizes dependencies of
wenzelm@26849
  1036
  theorems representing the corresponding program containing all given
wenzelm@26849
  1037
  constants; if no constants are given, the currently cached code
wenzelm@26849
  1038
  theorems are visualized.
wenzelm@26849
  1039
wenzelm@26849
  1040
  \item [@{command (HOL) "code_datatype"}] specifies a constructor set
wenzelm@26849
  1041
  for a logical type.
wenzelm@26849
  1042
wenzelm@26849
  1043
  \item [@{command (HOL) "code_const"}] associates a list of constants
wenzelm@26849
  1044
  with target-specific serializations; omitting a serialization
wenzelm@26849
  1045
  deletes an existing serialization.
wenzelm@26849
  1046
wenzelm@26849
  1047
  \item [@{command (HOL) "code_type"}] associates a list of type
wenzelm@26849
  1048
  constructors with target-specific serializations; omitting a
wenzelm@26849
  1049
  serialization deletes an existing serialization.
wenzelm@26849
  1050
wenzelm@26849
  1051
  \item [@{command (HOL) "code_class"}] associates a list of classes
wenzelm@26849
  1052
  with target-specific class names; in addition, constants associated
wenzelm@26849
  1053
  with this class may be given target-specific names used for instance
wenzelm@26849
  1054
  declarations; omitting a serialization deletes an existing
wenzelm@26849
  1055
  serialization.  This applies only to \emph{Haskell}.
wenzelm@26849
  1056
wenzelm@26849
  1057
  \item [@{command (HOL) "code_instance"}] declares a list of type
wenzelm@26849
  1058
  constructor / class instance relations as ``already present'' for a
wenzelm@26849
  1059
  given target.  Omitting a ``@{text "-"}'' deletes an existing
wenzelm@26849
  1060
  ``already present'' declaration.  This applies only to
wenzelm@26849
  1061
  \emph{Haskell}.
wenzelm@26849
  1062
wenzelm@26849
  1063
  \item [@{command (HOL) "code_monad"}] provides an auxiliary
wenzelm@26849
  1064
  mechanism to generate monadic code.
wenzelm@26849
  1065
wenzelm@26849
  1066
  \item [@{command (HOL) "code_reserved"}] declares a list of names as
wenzelm@26849
  1067
  reserved for a given target, preventing it to be shadowed by any
wenzelm@26849
  1068
  generated code.
wenzelm@26849
  1069
wenzelm@26849
  1070
  \item [@{command (HOL) "code_include"}] adds arbitrary named content
wenzelm@26849
  1071
  (``include'') to generated code.  A as last argument ``@{text "-"}''
wenzelm@26849
  1072
  will remove an already added ``include''.
wenzelm@26849
  1073
wenzelm@26849
  1074
  \item [@{command (HOL) "code_modulename"}] declares aliasings from
wenzelm@26849
  1075
  one module name onto another.
wenzelm@26849
  1076
haftmann@27103
  1077
  \item [@{command (HOL) "code_abort"}] declares constants which
haftmann@27103
  1078
  are not required to have a definition by a defining equations;
haftmann@27103
  1079
  if needed these are implemented by program abort instead.
wenzelm@26849
  1080
wenzelm@26849
  1081
  \item [@{attribute (HOL) code}~@{text func}] explicitly selects (or
wenzelm@26849
  1082
  with option ``@{text "del:"}'' deselects) a defining equation for
wenzelm@26849
  1083
  code generation.  Usually packages introducing defining equations
wenzelm@26849
  1084
  provide a resonable default setup for selection.
wenzelm@26849
  1085
wenzelm@26849
  1086
  \item [@{attribute (HOL) code}@{text inline}] declares (or with
wenzelm@26849
  1087
  option ``@{text "del:"}'' removes) inlining theorems which are
wenzelm@26849
  1088
  applied as rewrite rules to any defining equation during
wenzelm@26849
  1089
  preprocessing.
wenzelm@26849
  1090
wenzelm@26849
  1091
  \item [@{command (HOL) "print_codesetup"}] gives an overview on
wenzelm@26849
  1092
  selected defining equations, code generator datatypes and
wenzelm@26849
  1093
  preprocessor setup.
wenzelm@26849
  1094
wenzelm@26849
  1095
  \end{descr}
wenzelm@26849
  1096
*}
wenzelm@26849
  1097
wenzelm@27045
  1098
wenzelm@27045
  1099
section {* Definition by specification \label{sec:hol-specification} *}
wenzelm@27045
  1100
wenzelm@27045
  1101
text {*
wenzelm@27045
  1102
  \begin{matharray}{rcl}
wenzelm@27045
  1103
    @{command_def (HOL) "specification"} & : & \isartrans{theory}{proof(prove)} \\
wenzelm@27045
  1104
    @{command_def (HOL) "ax_specification"} & : & \isartrans{theory}{proof(prove)} \\
wenzelm@27045
  1105
  \end{matharray}
wenzelm@27045
  1106
wenzelm@27045
  1107
  \begin{rail}
wenzelm@27045
  1108
  ('specification' | 'ax\_specification') '(' (decl +) ')' \\ (thmdecl? prop +)
wenzelm@27045
  1109
  ;
wenzelm@27045
  1110
  decl: ((name ':')? term '(' 'overloaded' ')'?)
wenzelm@27045
  1111
  \end{rail}
wenzelm@27045
  1112
wenzelm@27045
  1113
  \begin{descr}
wenzelm@27045
  1114
wenzelm@27045
  1115
  \item [@{command (HOL) "specification"}~@{text "decls \<phi>"}] sets up a
wenzelm@27045
  1116
  goal stating the existence of terms with the properties specified to
wenzelm@27045
  1117
  hold for the constants given in @{text decls}.  After finishing the
wenzelm@27045
  1118
  proof, the theory will be augmented with definitions for the given
wenzelm@27045
  1119
  constants, as well as with theorems stating the properties for these
wenzelm@27045
  1120
  constants.
wenzelm@27045
  1121
wenzelm@27045
  1122
  \item [@{command (HOL) "ax_specification"}~@{text "decls \<phi>"}] sets
wenzelm@27045
  1123
  up a goal stating the existence of terms with the properties
wenzelm@27045
  1124
  specified to hold for the constants given in @{text decls}.  After
wenzelm@27045
  1125
  finishing the proof, the theory will be augmented with axioms
wenzelm@27045
  1126
  expressing the properties given in the first place.
wenzelm@27045
  1127
wenzelm@27045
  1128
  \item [@{text decl}] declares a constant to be defined by the
wenzelm@27045
  1129
  specification given.  The definition for the constant @{text c} is
wenzelm@27045
  1130
  bound to the name @{text c_def} unless a theorem name is given in
wenzelm@27045
  1131
  the declaration.  Overloaded constants should be declared as such.
wenzelm@27045
  1132
wenzelm@27045
  1133
  \end{descr}
wenzelm@27045
  1134
wenzelm@27045
  1135
  Whether to use @{command (HOL) "specification"} or @{command (HOL)
wenzelm@27045
  1136
  "ax_specification"} is to some extent a matter of style.  @{command
wenzelm@27045
  1137
  (HOL) "specification"} introduces no new axioms, and so by
wenzelm@27045
  1138
  construction cannot introduce inconsistencies, whereas @{command
wenzelm@27045
  1139
  (HOL) "ax_specification"} does introduce axioms, but only after the
wenzelm@27045
  1140
  user has explicitly proven it to be safe.  A practical issue must be
wenzelm@27045
  1141
  considered, though: After introducing two constants with the same
wenzelm@27045
  1142
  properties using @{command (HOL) "specification"}, one can prove
wenzelm@27045
  1143
  that the two constants are, in fact, equal.  If this might be a
wenzelm@27045
  1144
  problem, one should use @{command (HOL) "ax_specification"}.
wenzelm@27045
  1145
*}
wenzelm@27045
  1146
wenzelm@26840
  1147
end