src/Doc/Implementation/Logic.thy
author wenzelm
Tue Oct 20 23:53:40 2015 +0200 (2015-10-20)
changeset 61493 0debd22f0c0e
parent 61477 e467ae7aa808
child 61503 28e788ca2c5d
permissions -rw-r--r--
isabelle update_cartouches -t;
wenzelm@29755
     1
theory Logic
wenzelm@29755
     2
imports Base
wenzelm@29755
     3
begin
wenzelm@18537
     4
wenzelm@58618
     5
chapter \<open>Primitive logic \label{ch:logic}\<close>
wenzelm@18537
     6
wenzelm@58618
     7
text \<open>
wenzelm@20480
     8
  The logical foundations of Isabelle/Isar are that of the Pure logic,
wenzelm@29774
     9
  which has been introduced as a Natural Deduction framework in
wenzelm@61493
    10
  @{cite paulson700}.  This is essentially the same logic as ``\<open>\<lambda>HOL\<close>'' in the more abstract setting of Pure Type Systems (PTS)
wenzelm@58555
    11
  @{cite "Barendregt-Geuvers:2001"}, although there are some key
wenzelm@20491
    12
  differences in the specific treatment of simple types in
wenzelm@20491
    13
  Isabelle/Pure.
wenzelm@20480
    14
wenzelm@20480
    15
  Following type-theoretic parlance, the Pure logic consists of three
wenzelm@61493
    16
  levels of \<open>\<lambda>\<close>-calculus with corresponding arrows, \<open>\<Rightarrow>\<close> for syntactic function space (terms depending on terms), \<open>\<And>\<close> for universal quantification (proofs depending on terms), and
wenzelm@61493
    17
  \<open>\<Longrightarrow>\<close> for implication (proofs depending on proofs).
wenzelm@20480
    18
wenzelm@20537
    19
  Derivations are relative to a logical theory, which declares type
wenzelm@20537
    20
  constructors, constants, and axioms.  Theory declarations support
wenzelm@20537
    21
  schematic polymorphism, which is strictly speaking outside the
wenzelm@20537
    22
  logic.\footnote{This is the deeper logical reason, why the theory
wenzelm@61493
    23
  context \<open>\<Theta>\<close> is separate from the proof context \<open>\<Gamma>\<close>
wenzelm@34929
    24
  of the core calculus: type constructors, term constants, and facts
wenzelm@34929
    25
  (proof constants) may involve arbitrary type schemes, but the type
wenzelm@34929
    26
  of a locally fixed term parameter is also fixed!}
wenzelm@58618
    27
\<close>
wenzelm@20480
    28
wenzelm@20480
    29
wenzelm@58618
    30
section \<open>Types \label{sec:types}\<close>
wenzelm@20437
    31
wenzelm@58618
    32
text \<open>
wenzelm@20480
    33
  The language of types is an uninterpreted order-sorted first-order
wenzelm@20480
    34
  algebra; types are qualified by ordered type classes.
wenzelm@20480
    35
wenzelm@61416
    36
  \<^medskip>
wenzelm@61477
    37
  A \<^emph>\<open>type class\<close> is an abstract syntactic entity
wenzelm@61493
    38
  declared in the theory context.  The \<^emph>\<open>subclass relation\<close> \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close> is specified by stating an acyclic
wenzelm@20491
    39
  generating relation; the transitive closure is maintained
wenzelm@20491
    40
  internally.  The resulting relation is an ordering: reflexive,
wenzelm@20491
    41
  transitive, and antisymmetric.
wenzelm@20451
    42
wenzelm@61493
    43
  A \<^emph>\<open>sort\<close> is a list of type classes written as \<open>s = {c\<^sub>1,
wenzelm@61493
    44
  \<dots>, c\<^sub>m}\<close>, it represents symbolic intersection.  Notationally, the
wenzelm@34929
    45
  curly braces are omitted for singleton intersections, i.e.\ any
wenzelm@61493
    46
  class \<open>c\<close> may be read as a sort \<open>{c}\<close>.  The ordering
wenzelm@34929
    47
  on type classes is extended to sorts according to the meaning of
wenzelm@61493
    48
  intersections: \<open>{c\<^sub>1, \<dots> c\<^sub>m} \<subseteq> {d\<^sub>1, \<dots>, d\<^sub>n}\<close> iff \<open>\<forall>j. \<exists>i. c\<^sub>i \<subseteq> d\<^sub>j\<close>.  The empty intersection \<open>{}\<close> refers to
wenzelm@34929
    49
  the universal sort, which is the largest element wrt.\ the sort
wenzelm@61493
    50
  order.  Thus \<open>{}\<close> represents the ``full sort'', not the
wenzelm@34929
    51
  empty one!  The intersection of all (finitely many) classes declared
wenzelm@34929
    52
  in the current theory is the least element wrt.\ the sort ordering.
wenzelm@20480
    53
wenzelm@61416
    54
  \<^medskip>
wenzelm@61477
    55
  A \<^emph>\<open>fixed type variable\<close> is a pair of a basic name
wenzelm@61493
    56
  (starting with a \<open>'\<close> character) and a sort constraint, e.g.\
wenzelm@61493
    57
  \<open>('a, s)\<close> which is usually printed as \<open>\<alpha>\<^sub>s\<close>.
wenzelm@61477
    58
  A \<^emph>\<open>schematic type variable\<close> is a pair of an indexname and a
wenzelm@61493
    59
  sort constraint, e.g.\ \<open>(('a, 0), s)\<close> which is usually
wenzelm@61493
    60
  printed as \<open>?\<alpha>\<^sub>s\<close>.
wenzelm@20451
    61
wenzelm@61477
    62
  Note that \<^emph>\<open>all\<close> syntactic components contribute to the identity
wenzelm@34929
    63
  of type variables: basic name, index, and sort constraint.  The core
wenzelm@34929
    64
  logic handles type variables with the same name but different sorts
wenzelm@34929
    65
  as different, although the type-inference layer (which is outside
wenzelm@34929
    66
  the core) rejects anything like that.
wenzelm@20451
    67
wenzelm@61493
    68
  A \<^emph>\<open>type constructor\<close> \<open>\<kappa>\<close> is a \<open>k\<close>-ary operator
wenzelm@20493
    69
  on types declared in the theory.  Type constructor application is
wenzelm@61493
    70
  written postfix as \<open>(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>k)\<kappa>\<close>.  For
wenzelm@61493
    71
  \<open>k = 0\<close> the argument tuple is omitted, e.g.\ \<open>prop\<close>
wenzelm@61493
    72
  instead of \<open>()prop\<close>.  For \<open>k = 1\<close> the parentheses
wenzelm@61493
    73
  are omitted, e.g.\ \<open>\<alpha> list\<close> instead of \<open>(\<alpha>)list\<close>.
wenzelm@20537
    74
  Further notation is provided for specific constructors, notably the
wenzelm@61493
    75
  right-associative infix \<open>\<alpha> \<Rightarrow> \<beta>\<close> instead of \<open>(\<alpha>,
wenzelm@61493
    76
  \<beta>)fun\<close>.
wenzelm@20480
    77
  
wenzelm@61477
    78
  The logical category \<^emph>\<open>type\<close> is defined inductively over type
wenzelm@61493
    79
  variables and type constructors as follows: \<open>\<tau> = \<alpha>\<^sub>s | ?\<alpha>\<^sub>s |
wenzelm@61493
    80
  (\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>\<close>.
wenzelm@20451
    81
wenzelm@61493
    82
  A \<^emph>\<open>type abbreviation\<close> is a syntactic definition \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close> of an arbitrary type expression \<open>\<tau>\<close> over
wenzelm@61493
    83
  variables \<open>\<^vec>\<alpha>\<close>.  Type abbreviations appear as type
wenzelm@20537
    84
  constructors in the syntax, but are expanded before entering the
wenzelm@20537
    85
  logical core.
wenzelm@20480
    86
wenzelm@61477
    87
  A \<^emph>\<open>type arity\<close> declares the image behavior of a type
wenzelm@61493
    88
  constructor wrt.\ the algebra of sorts: \<open>\<kappa> :: (s\<^sub>1, \<dots>,
wenzelm@61493
    89
  s\<^sub>k)s\<close> means that \<open>(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>\<close> is
wenzelm@61493
    90
  of sort \<open>s\<close> if every argument type \<open>\<tau>\<^sub>i\<close> is
wenzelm@61493
    91
  of sort \<open>s\<^sub>i\<close>.  Arity declarations are implicitly
wenzelm@61493
    92
  completed, i.e.\ \<open>\<kappa> :: (\<^vec>s)c\<close> entails \<open>\<kappa> ::
wenzelm@61493
    93
  (\<^vec>s)c'\<close> for any \<open>c' \<supseteq> c\<close>.
wenzelm@20491
    94
wenzelm@61416
    95
  \<^medskip>
wenzelm@61477
    96
  The sort algebra is always maintained as \<^emph>\<open>coregular\<close>,
wenzelm@20491
    97
  which means that type arities are consistent with the subclass
wenzelm@61493
    98
  relation: for any type constructor \<open>\<kappa>\<close>, and classes \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close>, and arities \<open>\<kappa> ::
wenzelm@61493
    99
  (\<^vec>s\<^sub>1)c\<^sub>1\<close> and \<open>\<kappa> ::
wenzelm@61493
   100
  (\<^vec>s\<^sub>2)c\<^sub>2\<close> holds \<open>\<^vec>s\<^sub>1 \<subseteq>
wenzelm@61493
   101
  \<^vec>s\<^sub>2\<close> component-wise.
wenzelm@20451
   102
wenzelm@20491
   103
  The key property of a coregular order-sorted algebra is that sort
wenzelm@20537
   104
  constraints can be solved in a most general fashion: for each type
wenzelm@61493
   105
  constructor \<open>\<kappa>\<close> and sort \<open>s\<close> there is a most general
wenzelm@61493
   106
  vector of argument sorts \<open>(s\<^sub>1, \<dots>, s\<^sub>k)\<close> such
wenzelm@61493
   107
  that a type scheme \<open>(\<alpha>\<^bsub>s\<^sub>1\<^esub>, \<dots>,
wenzelm@61493
   108
  \<alpha>\<^bsub>s\<^sub>k\<^esub>)\<kappa>\<close> is of sort \<open>s\<close>.
wenzelm@20543
   109
  Consequently, type unification has most general solutions (modulo
wenzelm@20543
   110
  equivalence of sorts), so type-inference produces primary types as
wenzelm@58555
   111
  expected @{cite "nipkow-prehofer"}.
wenzelm@58618
   112
\<close>
wenzelm@20451
   113
wenzelm@58618
   114
text %mlref \<open>
wenzelm@20480
   115
  \begin{mldecls}
wenzelm@34921
   116
  @{index_ML_type class: string} \\
wenzelm@34921
   117
  @{index_ML_type sort: "class list"} \\
wenzelm@34921
   118
  @{index_ML_type arity: "string * sort list * sort"} \\
wenzelm@20480
   119
  @{index_ML_type typ} \\
wenzelm@39846
   120
  @{index_ML Term.map_atyps: "(typ -> typ) -> typ -> typ"} \\
wenzelm@39846
   121
  @{index_ML Term.fold_atyps: "(typ -> 'a -> 'a) -> typ -> 'a -> 'a"} \\
wenzelm@20547
   122
  \end{mldecls}
wenzelm@20547
   123
  \begin{mldecls}
wenzelm@20480
   124
  @{index_ML Sign.subsort: "theory -> sort * sort -> bool"} \\
wenzelm@20480
   125
  @{index_ML Sign.of_sort: "theory -> typ * sort -> bool"} \\
wenzelm@47174
   126
  @{index_ML Sign.add_type: "Proof.context -> binding * int * mixfix -> theory -> theory"} \\
wenzelm@42401
   127
  @{index_ML Sign.add_type_abbrev: "Proof.context ->
wenzelm@42401
   128
  binding * string list * typ -> theory -> theory"} \\
wenzelm@30355
   129
  @{index_ML Sign.primitive_class: "binding * class list -> theory -> theory"} \\
wenzelm@20480
   130
  @{index_ML Sign.primitive_classrel: "class * class -> theory -> theory"} \\
wenzelm@20480
   131
  @{index_ML Sign.primitive_arity: "arity -> theory -> theory"} \\
wenzelm@20480
   132
  \end{mldecls}
wenzelm@20480
   133
wenzelm@61439
   134
  \<^descr> Type @{ML_type class} represents type classes.
wenzelm@20480
   135
wenzelm@61439
   136
  \<^descr> Type @{ML_type sort} represents sorts, i.e.\ finite
wenzelm@39864
   137
  intersections of classes.  The empty list @{ML "[]: sort"} refers to
wenzelm@39864
   138
  the empty class intersection, i.e.\ the ``full sort''.
wenzelm@20451
   139
wenzelm@61439
   140
  \<^descr> Type @{ML_type arity} represents type arities.  A triple
wenzelm@61493
   141
  \<open>(\<kappa>, \<^vec>s, s) : arity\<close> represents \<open>\<kappa> ::
wenzelm@61493
   142
  (\<^vec>s)s\<close> as described above.
wenzelm@20480
   143
wenzelm@61439
   144
  \<^descr> Type @{ML_type typ} represents types; this is a datatype with
wenzelm@20480
   145
  constructors @{ML TFree}, @{ML TVar}, @{ML Type}.
wenzelm@20480
   146
wenzelm@61493
   147
  \<^descr> @{ML Term.map_atyps}~\<open>f \<tau>\<close> applies the mapping \<open>f\<close> to all atomic types (@{ML TFree}, @{ML TVar}) occurring in
wenzelm@61493
   148
  \<open>\<tau>\<close>.
wenzelm@20519
   149
wenzelm@61493
   150
  \<^descr> @{ML Term.fold_atyps}~\<open>f \<tau>\<close> iterates the operation
wenzelm@61493
   151
  \<open>f\<close> over all occurrences of atomic types (@{ML TFree}, @{ML
wenzelm@61493
   152
  TVar}) in \<open>\<tau>\<close>; the type structure is traversed from left to
wenzelm@39846
   153
  right.
wenzelm@20494
   154
wenzelm@61493
   155
  \<^descr> @{ML Sign.subsort}~\<open>thy (s\<^sub>1, s\<^sub>2)\<close>
wenzelm@61493
   156
  tests the subsort relation \<open>s\<^sub>1 \<subseteq> s\<^sub>2\<close>.
wenzelm@20480
   157
wenzelm@61493
   158
  \<^descr> @{ML Sign.of_sort}~\<open>thy (\<tau>, s)\<close> tests whether type
wenzelm@61493
   159
  \<open>\<tau>\<close> is of sort \<open>s\<close>.
wenzelm@20480
   160
wenzelm@61493
   161
  \<^descr> @{ML Sign.add_type}~\<open>ctxt (\<kappa>, k, mx)\<close> declares a
wenzelm@61493
   162
  new type constructors \<open>\<kappa>\<close> with \<open>k\<close> arguments and
wenzelm@20480
   163
  optional mixfix syntax.
wenzelm@20451
   164
wenzelm@61493
   165
  \<^descr> @{ML Sign.add_type_abbrev}~\<open>ctxt (\<kappa>, \<^vec>\<alpha>, \<tau>)\<close>
wenzelm@61493
   166
  defines a new type abbreviation \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close>.
wenzelm@20480
   167
wenzelm@61493
   168
  \<^descr> @{ML Sign.primitive_class}~\<open>(c, [c\<^sub>1, \<dots>,
wenzelm@61493
   169
  c\<^sub>n])\<close> declares a new class \<open>c\<close>, together with class
wenzelm@61493
   170
  relations \<open>c \<subseteq> c\<^sub>i\<close>, for \<open>i = 1, \<dots>, n\<close>.
wenzelm@20480
   171
wenzelm@61493
   172
  \<^descr> @{ML Sign.primitive_classrel}~\<open>(c\<^sub>1,
wenzelm@61493
   173
  c\<^sub>2)\<close> declares the class relation \<open>c\<^sub>1 \<subseteq>
wenzelm@61493
   174
  c\<^sub>2\<close>.
wenzelm@20480
   175
wenzelm@61493
   176
  \<^descr> @{ML Sign.primitive_arity}~\<open>(\<kappa>, \<^vec>s, s)\<close> declares
wenzelm@61493
   177
  the arity \<open>\<kappa> :: (\<^vec>s)s\<close>.
wenzelm@58618
   178
\<close>
wenzelm@20437
   179
wenzelm@58618
   180
text %mlantiq \<open>
wenzelm@39832
   181
  \begin{matharray}{rcl}
wenzelm@61493
   182
  @{ML_antiquotation_def "class"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   183
  @{ML_antiquotation_def "sort"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   184
  @{ML_antiquotation_def "type_name"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   185
  @{ML_antiquotation_def "type_abbrev"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   186
  @{ML_antiquotation_def "nonterminal"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   187
  @{ML_antiquotation_def "typ"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@39832
   188
  \end{matharray}
wenzelm@39832
   189
wenzelm@55112
   190
  @{rail \<open>
wenzelm@42510
   191
  @@{ML_antiquotation class} nameref
wenzelm@39832
   192
  ;
wenzelm@42510
   193
  @@{ML_antiquotation sort} sort
wenzelm@39832
   194
  ;
wenzelm@42510
   195
  (@@{ML_antiquotation type_name} |
wenzelm@42510
   196
   @@{ML_antiquotation type_abbrev} |
wenzelm@42510
   197
   @@{ML_antiquotation nonterminal}) nameref
wenzelm@39832
   198
  ;
wenzelm@42510
   199
  @@{ML_antiquotation typ} type
wenzelm@55112
   200
  \<close>}
wenzelm@39832
   201
wenzelm@61493
   202
  \<^descr> \<open>@{class c}\<close> inlines the internalized class \<open>c\<close> --- as @{ML_type string} literal.
wenzelm@39832
   203
wenzelm@61493
   204
  \<^descr> \<open>@{sort s}\<close> inlines the internalized sort \<open>s\<close>
wenzelm@39832
   205
  --- as @{ML_type "string list"} literal.
wenzelm@39832
   206
wenzelm@61493
   207
  \<^descr> \<open>@{type_name c}\<close> inlines the internalized type
wenzelm@61493
   208
  constructor \<open>c\<close> --- as @{ML_type string} literal.
wenzelm@39832
   209
wenzelm@61493
   210
  \<^descr> \<open>@{type_abbrev c}\<close> inlines the internalized type
wenzelm@61493
   211
  abbreviation \<open>c\<close> --- as @{ML_type string} literal.
wenzelm@39832
   212
wenzelm@61493
   213
  \<^descr> \<open>@{nonterminal c}\<close> inlines the internalized syntactic
wenzelm@61493
   214
  type~/ grammar nonterminal \<open>c\<close> --- as @{ML_type string}
wenzelm@39832
   215
  literal.
wenzelm@39832
   216
wenzelm@61493
   217
  \<^descr> \<open>@{typ \<tau>}\<close> inlines the internalized type \<open>\<tau>\<close>
wenzelm@39832
   218
  --- as constructor term for datatype @{ML_type typ}.
wenzelm@58618
   219
\<close>
wenzelm@39832
   220
wenzelm@20437
   221
wenzelm@58618
   222
section \<open>Terms \label{sec:terms}\<close>
wenzelm@18537
   223
wenzelm@58618
   224
text \<open>
wenzelm@61493
   225
  The language of terms is that of simply-typed \<open>\<lambda>\<close>-calculus
wenzelm@58555
   226
  with de-Bruijn indices for bound variables (cf.\ @{cite debruijn72}
wenzelm@58555
   227
  or @{cite "paulson-ml2"}), with the types being determined by the
wenzelm@29761
   228
  corresponding binders.  In contrast, free variables and constants
wenzelm@34929
   229
  have an explicit name and type in each occurrence.
wenzelm@20514
   230
wenzelm@61416
   231
  \<^medskip>
wenzelm@61493
   232
  A \<^emph>\<open>bound variable\<close> is a natural number \<open>b\<close>,
wenzelm@20537
   233
  which accounts for the number of intermediate binders between the
wenzelm@20537
   234
  variable occurrence in the body and its binding position.  For
wenzelm@61493
   235
  example, the de-Bruijn term \<open>\<lambda>\<^bsub>bool\<^esub>. \<lambda>\<^bsub>bool\<^esub>. 1 \<and> 0\<close> would
wenzelm@61493
   236
  correspond to \<open>\<lambda>x\<^bsub>bool\<^esub>. \<lambda>y\<^bsub>bool\<^esub>. x \<and> y\<close> in a named
wenzelm@20543
   237
  representation.  Note that a bound variable may be represented by
wenzelm@20543
   238
  different de-Bruijn indices at different occurrences, depending on
wenzelm@20543
   239
  the nesting of abstractions.
wenzelm@20537
   240
wenzelm@61477
   241
  A \<^emph>\<open>loose variable\<close> is a bound variable that is outside the
wenzelm@20537
   242
  scope of local binders.  The types (and names) for loose variables
wenzelm@20543
   243
  can be managed as a separate context, that is maintained as a stack
wenzelm@20543
   244
  of hypothetical binders.  The core logic operates on closed terms,
wenzelm@20543
   245
  without any loose variables.
wenzelm@20514
   246
wenzelm@61477
   247
  A \<^emph>\<open>fixed variable\<close> is a pair of a basic name and a type, e.g.\
wenzelm@61493
   248
  \<open>(x, \<tau>)\<close> which is usually printed \<open>x\<^sub>\<tau>\<close> here.  A
wenzelm@61477
   249
  \<^emph>\<open>schematic variable\<close> is a pair of an indexname and a type,
wenzelm@61493
   250
  e.g.\ \<open>((x, 0), \<tau>)\<close> which is likewise printed as \<open>?x\<^sub>\<tau>\<close>.
wenzelm@20491
   251
wenzelm@61416
   252
  \<^medskip>
wenzelm@61477
   253
  A \<^emph>\<open>constant\<close> is a pair of a basic name and a type,
wenzelm@61493
   254
  e.g.\ \<open>(c, \<tau>)\<close> which is usually printed as \<open>c\<^sub>\<tau>\<close>
wenzelm@34929
   255
  here.  Constants are declared in the context as polymorphic families
wenzelm@61493
   256
  \<open>c :: \<sigma>\<close>, meaning that all substitution instances \<open>c\<^sub>\<tau>\<close> for \<open>\<tau> = \<sigma>\<vartheta>\<close> are valid.
wenzelm@20514
   257
wenzelm@61493
   258
  The vector of \<^emph>\<open>type arguments\<close> of constant \<open>c\<^sub>\<tau>\<close> wrt.\
wenzelm@61493
   259
  the declaration \<open>c :: \<sigma>\<close> is defined as the codomain of the
wenzelm@61493
   260
  matcher \<open>\<vartheta> = {?\<alpha>\<^sub>1 \<mapsto> \<tau>\<^sub>1, \<dots>, ?\<alpha>\<^sub>n \<mapsto> \<tau>\<^sub>n}\<close> presented in
wenzelm@61493
   261
  canonical order \<open>(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n)\<close>, corresponding to the
wenzelm@61493
   262
  left-to-right occurrences of the \<open>\<alpha>\<^sub>i\<close> in \<open>\<sigma>\<close>.
wenzelm@34929
   263
  Within a given theory context, there is a one-to-one correspondence
wenzelm@61493
   264
  between any constant \<open>c\<^sub>\<tau>\<close> and the application \<open>c(\<tau>\<^sub>1,
wenzelm@61493
   265
  \<dots>, \<tau>\<^sub>n)\<close> of its type arguments.  For example, with \<open>plus :: \<alpha>
wenzelm@61493
   266
  \<Rightarrow> \<alpha> \<Rightarrow> \<alpha>\<close>, the instance \<open>plus\<^bsub>nat \<Rightarrow> nat \<Rightarrow> nat\<^esub>\<close> corresponds to
wenzelm@61493
   267
  \<open>plus(nat)\<close>.
wenzelm@20480
   268
wenzelm@61493
   269
  Constant declarations \<open>c :: \<sigma>\<close> may contain sort constraints
wenzelm@61493
   270
  for type variables in \<open>\<sigma>\<close>.  These are observed by
wenzelm@61477
   271
  type-inference as expected, but \<^emph>\<open>ignored\<close> by the core logic.
wenzelm@20514
   272
  This means the primitive logic is able to reason with instances of
wenzelm@20537
   273
  polymorphic constants that the user-level type-checker would reject
wenzelm@20537
   274
  due to violation of type class restrictions.
wenzelm@20480
   275
wenzelm@61416
   276
  \<^medskip>
wenzelm@61477
   277
  An \<^emph>\<open>atomic term\<close> is either a variable or constant.
wenzelm@61477
   278
  The logical category \<^emph>\<open>term\<close> is defined inductively over atomic
wenzelm@61493
   279
  terms, with abstraction and application as follows: \<open>t = b |
wenzelm@61493
   280
  x\<^sub>\<tau> | ?x\<^sub>\<tau> | c\<^sub>\<tau> | \<lambda>\<^sub>\<tau>. t | t\<^sub>1 t\<^sub>2\<close>.  Parsing and printing takes care of
wenzelm@34929
   281
  converting between an external representation with named bound
wenzelm@34929
   282
  variables.  Subsequently, we shall use the latter notation instead
wenzelm@34929
   283
  of internal de-Bruijn representation.
wenzelm@20498
   284
wenzelm@61493
   285
  The inductive relation \<open>t :: \<tau>\<close> assigns a (unique) type to a
wenzelm@20537
   286
  term according to the structure of atomic terms, abstractions, and
wenzelm@56579
   287
  applications:
wenzelm@20498
   288
  \[
wenzelm@61493
   289
  \infer{\<open>a\<^sub>\<tau> :: \<tau>\<close>}{}
wenzelm@20498
   290
  \qquad
wenzelm@61493
   291
  \infer{\<open>(\<lambda>x\<^sub>\<tau>. t) :: \<tau> \<Rightarrow> \<sigma>\<close>}{\<open>t :: \<sigma>\<close>}
wenzelm@20501
   292
  \qquad
wenzelm@61493
   293
  \infer{\<open>t u :: \<sigma>\<close>}{\<open>t :: \<tau> \<Rightarrow> \<sigma>\<close> & \<open>u :: \<tau>\<close>}
wenzelm@20498
   294
  \]
wenzelm@61477
   295
  A \<^emph>\<open>well-typed term\<close> is a term that can be typed according to these rules.
wenzelm@20498
   296
wenzelm@20514
   297
  Typing information can be omitted: type-inference is able to
wenzelm@20514
   298
  reconstruct the most general type of a raw term, while assigning
wenzelm@20514
   299
  most general types to all of its variables and constants.
wenzelm@20514
   300
  Type-inference depends on a context of type constraints for fixed
wenzelm@20514
   301
  variables, and declarations for polymorphic constants.
wenzelm@20514
   302
wenzelm@20537
   303
  The identity of atomic terms consists both of the name and the type
wenzelm@61493
   304
  component.  This means that different variables \<open>x\<^bsub>\<tau>\<^sub>1\<^esub>\<close> and \<open>x\<^bsub>\<tau>\<^sub>2\<^esub>\<close> may become the same after
wenzelm@34929
   305
  type instantiation.  Type-inference rejects variables of the same
wenzelm@34929
   306
  name, but different types.  In contrast, mixed instances of
wenzelm@34929
   307
  polymorphic constants occur routinely.
wenzelm@20514
   308
wenzelm@61416
   309
  \<^medskip>
wenzelm@61493
   310
  The \<^emph>\<open>hidden polymorphism\<close> of a term \<open>t :: \<sigma>\<close>
wenzelm@61493
   311
  is the set of type variables occurring in \<open>t\<close>, but not in
wenzelm@61493
   312
  its type \<open>\<sigma>\<close>.  This means that the term implicitly depends
wenzelm@34929
   313
  on type arguments that are not accounted in the result type, i.e.\
wenzelm@61493
   314
  there are different type instances \<open>t\<vartheta> :: \<sigma>\<close> and
wenzelm@61493
   315
  \<open>t\<vartheta>' :: \<sigma>\<close> with the same type.  This slightly
wenzelm@20543
   316
  pathological situation notoriously demands additional care.
wenzelm@20514
   317
wenzelm@61416
   318
  \<^medskip>
wenzelm@61493
   319
  A \<^emph>\<open>term abbreviation\<close> is a syntactic definition \<open>c\<^sub>\<sigma> \<equiv> t\<close> of a closed term \<open>t\<close> of type \<open>\<sigma>\<close>,
wenzelm@20537
   320
  without any hidden polymorphism.  A term abbreviation looks like a
wenzelm@20543
   321
  constant in the syntax, but is expanded before entering the logical
wenzelm@20543
   322
  core.  Abbreviations are usually reverted when printing terms, using
wenzelm@61493
   323
  \<open>t \<rightarrow> c\<^sub>\<sigma>\<close> as rules for higher-order rewriting.
wenzelm@20519
   324
wenzelm@61416
   325
  \<^medskip>
wenzelm@61493
   326
  Canonical operations on \<open>\<lambda>\<close>-terms include \<open>\<alpha>\<beta>\<eta>\<close>-conversion: \<open>\<alpha>\<close>-conversion refers to capture-free
wenzelm@61493
   327
  renaming of bound variables; \<open>\<beta>\<close>-conversion contracts an
wenzelm@20537
   328
  abstraction applied to an argument term, substituting the argument
wenzelm@61493
   329
  in the body: \<open>(\<lambda>x. b)a\<close> becomes \<open>b[a/x]\<close>; \<open>\<eta>\<close>-conversion contracts vacuous application-abstraction: \<open>\<lambda>x. f x\<close> becomes \<open>f\<close>, provided that the bound variable
wenzelm@61493
   330
  does not occur in \<open>f\<close>.
wenzelm@20519
   331
wenzelm@61493
   332
  Terms are normally treated modulo \<open>\<alpha>\<close>-conversion, which is
wenzelm@20537
   333
  implicit in the de-Bruijn representation.  Names for bound variables
wenzelm@20537
   334
  in abstractions are maintained separately as (meaningless) comments,
wenzelm@61493
   335
  mostly for parsing and printing.  Full \<open>\<alpha>\<beta>\<eta>\<close>-conversion is
wenzelm@28784
   336
  commonplace in various standard operations (\secref{sec:obj-rules})
wenzelm@28784
   337
  that are based on higher-order unification and matching.
wenzelm@58618
   338
\<close>
wenzelm@18537
   339
wenzelm@58618
   340
text %mlref \<open>
wenzelm@20514
   341
  \begin{mldecls}
wenzelm@20514
   342
  @{index_ML_type term} \\
wenzelm@46262
   343
  @{index_ML_op "aconv": "term * term -> bool"} \\
wenzelm@39846
   344
  @{index_ML Term.map_types: "(typ -> typ) -> term -> term"} \\
wenzelm@39846
   345
  @{index_ML Term.fold_types: "(typ -> 'a -> 'a) -> term -> 'a -> 'a"} \\
wenzelm@39846
   346
  @{index_ML Term.map_aterms: "(term -> term) -> term -> term"} \\
wenzelm@39846
   347
  @{index_ML Term.fold_aterms: "(term -> 'a -> 'a) -> term -> 'a -> 'a"} \\
wenzelm@20547
   348
  \end{mldecls}
wenzelm@20547
   349
  \begin{mldecls}
wenzelm@20514
   350
  @{index_ML fastype_of: "term -> typ"} \\
wenzelm@20519
   351
  @{index_ML lambda: "term -> term -> term"} \\
wenzelm@20519
   352
  @{index_ML betapply: "term * term -> term"} \\
wenzelm@42934
   353
  @{index_ML incr_boundvars: "int -> term -> term"} \\
wenzelm@42401
   354
  @{index_ML Sign.declare_const: "Proof.context ->
wenzelm@42401
   355
  (binding * typ) * mixfix -> theory -> term * theory"} \\
haftmann@33174
   356
  @{index_ML Sign.add_abbrev: "string -> binding * term ->
wenzelm@24972
   357
  theory -> (term * term) * theory"} \\
wenzelm@20519
   358
  @{index_ML Sign.const_typargs: "theory -> string * typ -> typ list"} \\
wenzelm@20519
   359
  @{index_ML Sign.const_instance: "theory -> string * typ list -> typ"} \\
wenzelm@20514
   360
  \end{mldecls}
wenzelm@18537
   361
wenzelm@61439
   362
  \<^descr> Type @{ML_type term} represents de-Bruijn terms, with comments
wenzelm@39864
   363
  in abstractions, and explicitly named free variables and constants;
wenzelm@52408
   364
  this is a datatype with constructors @{index_ML Bound}, @{index_ML
wenzelm@52408
   365
  Free}, @{index_ML Var}, @{index_ML Const}, @{index_ML Abs},
wenzelm@52408
   366
  @{index_ML_op "$"}.
wenzelm@20519
   367
wenzelm@61493
   368
  \<^descr> \<open>t\<close>~@{ML_text aconv}~\<open>u\<close> checks \<open>\<alpha>\<close>-equivalence of two terms.  This is the basic equality relation
wenzelm@20519
   369
  on type @{ML_type term}; raw datatype equality should only be used
wenzelm@20519
   370
  for operations related to parsing or printing!
wenzelm@20519
   371
wenzelm@61493
   372
  \<^descr> @{ML Term.map_types}~\<open>f t\<close> applies the mapping \<open>f\<close> to all types occurring in \<open>t\<close>.
wenzelm@20537
   373
wenzelm@61493
   374
  \<^descr> @{ML Term.fold_types}~\<open>f t\<close> iterates the operation
wenzelm@61493
   375
  \<open>f\<close> over all occurrences of types in \<open>t\<close>; the term
wenzelm@20537
   376
  structure is traversed from left to right.
wenzelm@20519
   377
wenzelm@61493
   378
  \<^descr> @{ML Term.map_aterms}~\<open>f t\<close> applies the mapping \<open>f\<close> to all atomic terms (@{ML Bound}, @{ML Free}, @{ML Var}, @{ML
wenzelm@61493
   379
  Const}) occurring in \<open>t\<close>.
wenzelm@20537
   380
wenzelm@61493
   381
  \<^descr> @{ML Term.fold_aterms}~\<open>f t\<close> iterates the operation
wenzelm@61493
   382
  \<open>f\<close> over all occurrences of atomic terms (@{ML Bound}, @{ML
wenzelm@61493
   383
  Free}, @{ML Var}, @{ML Const}) in \<open>t\<close>; the term structure is
wenzelm@20519
   384
  traversed from left to right.
wenzelm@20519
   385
wenzelm@61493
   386
  \<^descr> @{ML fastype_of}~\<open>t\<close> determines the type of a
wenzelm@20537
   387
  well-typed term.  This operation is relatively slow, despite the
wenzelm@20537
   388
  omission of any sanity checks.
wenzelm@20519
   389
wenzelm@61493
   390
  \<^descr> @{ML lambda}~\<open>a b\<close> produces an abstraction \<open>\<lambda>a. b\<close>, where occurrences of the atomic term \<open>a\<close> in the
wenzelm@61493
   391
  body \<open>b\<close> are replaced by bound variables.
wenzelm@20519
   392
wenzelm@61493
   393
  \<^descr> @{ML betapply}~\<open>(t, u)\<close> produces an application \<open>t u\<close>, with topmost \<open>\<beta>\<close>-conversion if \<open>t\<close> is an
wenzelm@20537
   394
  abstraction.
wenzelm@20519
   395
wenzelm@61493
   396
  \<^descr> @{ML incr_boundvars}~\<open>j\<close> increments a term's dangling
wenzelm@61493
   397
  bound variables by the offset \<open>j\<close>.  This is required when
wenzelm@42934
   398
  moving a subterm into a context where it is enclosed by a different
wenzelm@42934
   399
  number of abstractions.  Bound variables with a matching abstraction
wenzelm@42934
   400
  are unaffected.
wenzelm@42934
   401
wenzelm@61493
   402
  \<^descr> @{ML Sign.declare_const}~\<open>ctxt ((c, \<sigma>), mx)\<close> declares
wenzelm@61493
   403
  a new constant \<open>c :: \<sigma>\<close> with optional mixfix syntax.
wenzelm@20519
   404
wenzelm@61493
   405
  \<^descr> @{ML Sign.add_abbrev}~\<open>print_mode (c, t)\<close>
wenzelm@61493
   406
  introduces a new term abbreviation \<open>c \<equiv> t\<close>.
wenzelm@20519
   407
wenzelm@61493
   408
  \<^descr> @{ML Sign.const_typargs}~\<open>thy (c, \<tau>)\<close> and @{ML
wenzelm@61493
   409
  Sign.const_instance}~\<open>thy (c, [\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n])\<close>
wenzelm@20543
   410
  convert between two representations of polymorphic constants: full
wenzelm@20543
   411
  type instance vs.\ compact type arguments form.
wenzelm@58618
   412
\<close>
wenzelm@18537
   413
wenzelm@58618
   414
text %mlantiq \<open>
wenzelm@39832
   415
  \begin{matharray}{rcl}
wenzelm@61493
   416
  @{ML_antiquotation_def "const_name"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   417
  @{ML_antiquotation_def "const_abbrev"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   418
  @{ML_antiquotation_def "const"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   419
  @{ML_antiquotation_def "term"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   420
  @{ML_antiquotation_def "prop"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@39832
   421
  \end{matharray}
wenzelm@39832
   422
wenzelm@55112
   423
  @{rail \<open>
wenzelm@42510
   424
  (@@{ML_antiquotation const_name} |
wenzelm@42510
   425
   @@{ML_antiquotation const_abbrev}) nameref
wenzelm@39832
   426
  ;
wenzelm@42510
   427
  @@{ML_antiquotation const} ('(' (type + ',') ')')?
wenzelm@39832
   428
  ;
wenzelm@42510
   429
  @@{ML_antiquotation term} term
wenzelm@39832
   430
  ;
wenzelm@42510
   431
  @@{ML_antiquotation prop} prop
wenzelm@55112
   432
  \<close>}
wenzelm@39832
   433
wenzelm@61493
   434
  \<^descr> \<open>@{const_name c}\<close> inlines the internalized logical
wenzelm@61493
   435
  constant name \<open>c\<close> --- as @{ML_type string} literal.
wenzelm@39832
   436
wenzelm@61493
   437
  \<^descr> \<open>@{const_abbrev c}\<close> inlines the internalized
wenzelm@61493
   438
  abbreviated constant name \<open>c\<close> --- as @{ML_type string}
wenzelm@39832
   439
  literal.
wenzelm@39832
   440
wenzelm@61493
   441
  \<^descr> \<open>@{const c(\<^vec>\<tau>)}\<close> inlines the internalized
wenzelm@61493
   442
  constant \<open>c\<close> with precise type instantiation in the sense of
wenzelm@39832
   443
  @{ML Sign.const_instance} --- as @{ML Const} constructor term for
wenzelm@39832
   444
  datatype @{ML_type term}.
wenzelm@39832
   445
wenzelm@61493
   446
  \<^descr> \<open>@{term t}\<close> inlines the internalized term \<open>t\<close>
wenzelm@39832
   447
  --- as constructor term for datatype @{ML_type term}.
wenzelm@39832
   448
wenzelm@61493
   449
  \<^descr> \<open>@{prop \<phi>}\<close> inlines the internalized proposition
wenzelm@61493
   450
  \<open>\<phi>\<close> --- as constructor term for datatype @{ML_type term}.
wenzelm@58618
   451
\<close>
wenzelm@39832
   452
wenzelm@18537
   453
wenzelm@58618
   454
section \<open>Theorems \label{sec:thms}\<close>
wenzelm@18537
   455
wenzelm@58618
   456
text \<open>
wenzelm@61493
   457
  A \<^emph>\<open>proposition\<close> is a well-typed term of type \<open>prop\<close>, a
wenzelm@61477
   458
  \<^emph>\<open>theorem\<close> is a proven proposition (depending on a context of
wenzelm@20521
   459
  hypotheses and the background theory).  Primitive inferences include
wenzelm@61493
   460
  plain Natural Deduction rules for the primary connectives \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> of the framework.  There is also a builtin
wenzelm@61493
   461
  notion of equality/equivalence \<open>\<equiv>\<close>.
wenzelm@58618
   462
\<close>
wenzelm@20521
   463
wenzelm@29758
   464
wenzelm@58618
   465
subsection \<open>Primitive connectives and rules \label{sec:prim-rules}\<close>
wenzelm@18537
   466
wenzelm@58618
   467
text \<open>
wenzelm@61493
   468
  The theory \<open>Pure\<close> contains constant declarations for the
wenzelm@61493
   469
  primitive connectives \<open>\<And>\<close>, \<open>\<Longrightarrow>\<close>, and \<open>\<equiv>\<close> of
wenzelm@20543
   470
  the logical framework, see \figref{fig:pure-connectives}.  The
wenzelm@61493
   471
  derivability judgment \<open>A\<^sub>1, \<dots>, A\<^sub>n \<turnstile> B\<close> is
wenzelm@20543
   472
  defined inductively by the primitive inferences given in
wenzelm@20543
   473
  \figref{fig:prim-rules}, with the global restriction that the
wenzelm@61477
   474
  hypotheses must \<^emph>\<open>not\<close> contain any schematic variables.  The
wenzelm@20543
   475
  builtin equality is conceptually axiomatized as shown in
wenzelm@20521
   476
  \figref{fig:pure-equality}, although the implementation works
wenzelm@20543
   477
  directly with derived inferences.
wenzelm@20521
   478
wenzelm@20521
   479
  \begin{figure}[htb]
wenzelm@20521
   480
  \begin{center}
wenzelm@20501
   481
  \begin{tabular}{ll}
wenzelm@61493
   482
  \<open>all :: (\<alpha> \<Rightarrow> prop) \<Rightarrow> prop\<close> & universal quantification (binder \<open>\<And>\<close>) \\
wenzelm@61493
   483
  \<open>\<Longrightarrow> :: prop \<Rightarrow> prop \<Rightarrow> prop\<close> & implication (right associative infix) \\
wenzelm@61493
   484
  \<open>\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop\<close> & equality relation (infix) \\
wenzelm@20501
   485
  \end{tabular}
wenzelm@20537
   486
  \caption{Primitive connectives of Pure}\label{fig:pure-connectives}
wenzelm@20521
   487
  \end{center}
wenzelm@20521
   488
  \end{figure}
wenzelm@18537
   489
wenzelm@20501
   490
  \begin{figure}[htb]
wenzelm@20501
   491
  \begin{center}
wenzelm@20498
   492
  \[
wenzelm@61493
   493
  \infer[\<open>(axiom)\<close>]{\<open>\<turnstile> A\<close>}{\<open>A \<in> \<Theta>\<close>}
wenzelm@20498
   494
  \qquad
wenzelm@61493
   495
  \infer[\<open>(assume)\<close>]{\<open>A \<turnstile> A\<close>}{}
wenzelm@20498
   496
  \]
wenzelm@20498
   497
  \[
wenzelm@61493
   498
  \infer[\<open>(\<And>\<hyphen>intro)\<close>]{\<open>\<Gamma> \<turnstile> \<And>x. B[x]\<close>}{\<open>\<Gamma> \<turnstile> B[x]\<close> & \<open>x \<notin> \<Gamma>\<close>}
wenzelm@20498
   499
  \qquad
wenzelm@61493
   500
  \infer[\<open>(\<And>\<hyphen>elim)\<close>]{\<open>\<Gamma> \<turnstile> B[a]\<close>}{\<open>\<Gamma> \<turnstile> \<And>x. B[x]\<close>}
wenzelm@20498
   501
  \]
wenzelm@20498
   502
  \[
wenzelm@61493
   503
  \infer[\<open>(\<Longrightarrow>\<hyphen>intro)\<close>]{\<open>\<Gamma> - A \<turnstile> A \<Longrightarrow> B\<close>}{\<open>\<Gamma> \<turnstile> B\<close>}
wenzelm@20498
   504
  \qquad
wenzelm@61493
   505
  \infer[\<open>(\<Longrightarrow>\<hyphen>elim)\<close>]{\<open>\<Gamma>\<^sub>1 \<union> \<Gamma>\<^sub>2 \<turnstile> B\<close>}{\<open>\<Gamma>\<^sub>1 \<turnstile> A \<Longrightarrow> B\<close> & \<open>\<Gamma>\<^sub>2 \<turnstile> A\<close>}
wenzelm@20498
   506
  \]
wenzelm@20521
   507
  \caption{Primitive inferences of Pure}\label{fig:prim-rules}
wenzelm@20521
   508
  \end{center}
wenzelm@20521
   509
  \end{figure}
wenzelm@20521
   510
wenzelm@20521
   511
  \begin{figure}[htb]
wenzelm@20521
   512
  \begin{center}
wenzelm@20521
   513
  \begin{tabular}{ll}
wenzelm@61493
   514
  \<open>\<turnstile> (\<lambda>x. b[x]) a \<equiv> b[a]\<close> & \<open>\<beta>\<close>-conversion \\
wenzelm@61493
   515
  \<open>\<turnstile> x \<equiv> x\<close> & reflexivity \\
wenzelm@61493
   516
  \<open>\<turnstile> x \<equiv> y \<Longrightarrow> P x \<Longrightarrow> P y\<close> & substitution \\
wenzelm@61493
   517
  \<open>\<turnstile> (\<And>x. f x \<equiv> g x) \<Longrightarrow> f \<equiv> g\<close> & extensionality \\
wenzelm@61493
   518
  \<open>\<turnstile> (A \<Longrightarrow> B) \<Longrightarrow> (B \<Longrightarrow> A) \<Longrightarrow> A \<equiv> B\<close> & logical equivalence \\
wenzelm@20521
   519
  \end{tabular}
wenzelm@20542
   520
  \caption{Conceptual axiomatization of Pure equality}\label{fig:pure-equality}
wenzelm@20501
   521
  \end{center}
wenzelm@20501
   522
  \end{figure}
wenzelm@18537
   523
wenzelm@61493
   524
  The introduction and elimination rules for \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> are analogous to formation of dependently typed \<open>\<lambda>\<close>-terms representing the underlying proof objects.  Proof terms
wenzelm@20543
   525
  are irrelevant in the Pure logic, though; they cannot occur within
wenzelm@20543
   526
  propositions.  The system provides a runtime option to record
wenzelm@52408
   527
  explicit proof terms for primitive inferences, see also
wenzelm@61493
   528
  \secref{sec:proof-terms}.  Thus all three levels of \<open>\<lambda>\<close>-calculus become explicit: \<open>\<Rightarrow>\<close> for terms, and \<open>\<And>/\<Longrightarrow>\<close> for proofs (cf.\ @{cite "Berghofer-Nipkow:2000:TPHOL"}).
wenzelm@20491
   529
wenzelm@61493
   530
  Observe that locally fixed parameters (as in \<open>\<And>\<hyphen>intro\<close>) need not be recorded in the hypotheses, because
wenzelm@34929
   531
  the simple syntactic types of Pure are always inhabitable.
wenzelm@61493
   532
  ``Assumptions'' \<open>x :: \<tau>\<close> for type-membership are only
wenzelm@61493
   533
  present as long as some \<open>x\<^sub>\<tau>\<close> occurs in the statement
wenzelm@61493
   534
  body.\footnote{This is the key difference to ``\<open>\<lambda>HOL\<close>'' in
wenzelm@58555
   535
  the PTS framework @{cite "Barendregt-Geuvers:2001"}, where hypotheses
wenzelm@61493
   536
  \<open>x : A\<close> are treated uniformly for propositions and types.}
wenzelm@20501
   537
wenzelm@61416
   538
  \<^medskip>
wenzelm@61416
   539
  The axiomatization of a theory is implicitly closed by
wenzelm@61493
   540
  forming all instances of type and term variables: \<open>\<turnstile>
wenzelm@61493
   541
  A\<vartheta>\<close> holds for any substitution instance of an axiom
wenzelm@61493
   542
  \<open>\<turnstile> A\<close>.  By pushing substitutions through derivations
wenzelm@61493
   543
  inductively, we also get admissible \<open>generalize\<close> and \<open>instantiate\<close> rules as shown in \figref{fig:subst-rules}.
wenzelm@20501
   544
wenzelm@20501
   545
  \begin{figure}[htb]
wenzelm@20501
   546
  \begin{center}
wenzelm@20498
   547
  \[
wenzelm@61493
   548
  \infer{\<open>\<Gamma> \<turnstile> B[?\<alpha>]\<close>}{\<open>\<Gamma> \<turnstile> B[\<alpha>]\<close> & \<open>\<alpha> \<notin> \<Gamma>\<close>}
wenzelm@20501
   549
  \quad
wenzelm@61493
   550
  \infer[\quad\<open>(generalize)\<close>]{\<open>\<Gamma> \<turnstile> B[?x]\<close>}{\<open>\<Gamma> \<turnstile> B[x]\<close> & \<open>x \<notin> \<Gamma>\<close>}
wenzelm@20498
   551
  \]
wenzelm@20498
   552
  \[
wenzelm@61493
   553
  \infer{\<open>\<Gamma> \<turnstile> B[\<tau>]\<close>}{\<open>\<Gamma> \<turnstile> B[?\<alpha>]\<close>}
wenzelm@20501
   554
  \quad
wenzelm@61493
   555
  \infer[\quad\<open>(instantiate)\<close>]{\<open>\<Gamma> \<turnstile> B[t]\<close>}{\<open>\<Gamma> \<turnstile> B[?x]\<close>}
wenzelm@20498
   556
  \]
wenzelm@20501
   557
  \caption{Admissible substitution rules}\label{fig:subst-rules}
wenzelm@20501
   558
  \end{center}
wenzelm@20501
   559
  \end{figure}
wenzelm@18537
   560
wenzelm@61493
   561
  Note that \<open>instantiate\<close> does not require an explicit
wenzelm@61493
   562
  side-condition, because \<open>\<Gamma>\<close> may never contain schematic
wenzelm@20537
   563
  variables.
wenzelm@20537
   564
wenzelm@20537
   565
  In principle, variables could be substituted in hypotheses as well,
wenzelm@20543
   566
  but this would disrupt the monotonicity of reasoning: deriving
wenzelm@61493
   567
  \<open>\<Gamma>\<vartheta> \<turnstile> B\<vartheta>\<close> from \<open>\<Gamma> \<turnstile> B\<close> is
wenzelm@61493
   568
  correct, but \<open>\<Gamma>\<vartheta> \<supseteq> \<Gamma>\<close> does not necessarily hold:
wenzelm@20543
   569
  the result belongs to a different proof context.
wenzelm@20542
   570
wenzelm@61416
   571
  \<^medskip>
wenzelm@61477
   572
  An \<^emph>\<open>oracle\<close> is a function that produces axioms on the
wenzelm@61493
   573
  fly.  Logically, this is an instance of the \<open>axiom\<close> rule
wenzelm@20543
   574
  (\figref{fig:prim-rules}), but there is an operational difference.
wenzelm@20543
   575
  The system always records oracle invocations within derivations of
wenzelm@29768
   576
  theorems by a unique tag.
wenzelm@20542
   577
wenzelm@20542
   578
  Axiomatizations should be limited to the bare minimum, typically as
wenzelm@20542
   579
  part of the initial logical basis of an object-logic formalization.
wenzelm@20543
   580
  Later on, theories are usually developed in a strictly definitional
wenzelm@20543
   581
  fashion, by stating only certain equalities over new constants.
wenzelm@20542
   582
wenzelm@61493
   583
  A \<^emph>\<open>simple definition\<close> consists of a constant declaration \<open>c :: \<sigma>\<close> together with an axiom \<open>\<turnstile> c \<equiv> t\<close>, where \<open>t
wenzelm@61493
   584
  :: \<sigma>\<close> is a closed term without any hidden polymorphism.  The RHS
wenzelm@61493
   585
  may depend on further defined constants, but not \<open>c\<close> itself.
wenzelm@61493
   586
  Definitions of functions may be presented as \<open>c \<^vec>x \<equiv>
wenzelm@61493
   587
  t\<close> instead of the puristic \<open>c \<equiv> \<lambda>\<^vec>x. t\<close>.
wenzelm@20542
   588
wenzelm@61477
   589
  An \<^emph>\<open>overloaded definition\<close> consists of a collection of axioms
wenzelm@61493
   590
  for the same constant, with zero or one equations \<open>c((\<^vec>\<alpha>)\<kappa>) \<equiv> t\<close> for each type constructor \<open>\<kappa>\<close> (for
wenzelm@61493
   591
  distinct variables \<open>\<^vec>\<alpha>\<close>).  The RHS may mention
wenzelm@61493
   592
  previously defined constants as above, or arbitrary constants \<open>d(\<alpha>\<^sub>i)\<close> for some \<open>\<alpha>\<^sub>i\<close> projected from \<open>\<^vec>\<alpha>\<close>.  Thus overloaded definitions essentially work by
wenzelm@20543
   593
  primitive recursion over the syntactic structure of a single type
wenzelm@58555
   594
  argument.  See also @{cite \<open>\S4.3\<close> "Haftmann-Wenzel:2006:classes"}.
wenzelm@58618
   595
\<close>
wenzelm@20498
   596
wenzelm@58618
   597
text %mlref \<open>
wenzelm@20521
   598
  \begin{mldecls}
wenzelm@46253
   599
  @{index_ML Logic.all: "term -> term -> term"} \\
wenzelm@46253
   600
  @{index_ML Logic.mk_implies: "term * term -> term"} \\
wenzelm@46253
   601
  \end{mldecls}
wenzelm@46253
   602
  \begin{mldecls}
wenzelm@20521
   603
  @{index_ML_type ctyp} \\
wenzelm@20521
   604
  @{index_ML_type cterm} \\
wenzelm@59621
   605
  @{index_ML Thm.ctyp_of: "Proof.context -> typ -> ctyp"} \\
wenzelm@59621
   606
  @{index_ML Thm.cterm_of: "Proof.context -> term -> cterm"} \\
wenzelm@46497
   607
  @{index_ML Thm.apply: "cterm -> cterm -> cterm"} \\
wenzelm@46497
   608
  @{index_ML Thm.lambda: "cterm -> cterm -> cterm"} \\
wenzelm@60938
   609
  @{index_ML Thm.all: "Proof.context -> cterm -> cterm -> cterm"} \\
wenzelm@46253
   610
  @{index_ML Drule.mk_implies: "cterm * cterm -> cterm"} \\
wenzelm@20547
   611
  \end{mldecls}
wenzelm@20547
   612
  \begin{mldecls}
wenzelm@20521
   613
  @{index_ML_type thm} \\
wenzelm@50126
   614
  @{index_ML Thm.peek_status: "thm -> {oracle: bool, unfinished: bool, failed: bool}"} \\
wenzelm@42933
   615
  @{index_ML Thm.transfer: "theory -> thm -> thm"} \\
wenzelm@20542
   616
  @{index_ML Thm.assume: "cterm -> thm"} \\
wenzelm@20542
   617
  @{index_ML Thm.forall_intr: "cterm -> thm -> thm"} \\
wenzelm@20542
   618
  @{index_ML Thm.forall_elim: "cterm -> thm -> thm"} \\
wenzelm@20542
   619
  @{index_ML Thm.implies_intr: "cterm -> thm -> thm"} \\
wenzelm@20542
   620
  @{index_ML Thm.implies_elim: "thm -> thm -> thm"} \\
wenzelm@20542
   621
  @{index_ML Thm.generalize: "string list * string list -> int -> thm -> thm"} \\
wenzelm@60642
   622
  @{index_ML Thm.instantiate: "((indexname * sort) * ctyp) list * ((indexname * typ) * cterm) list
wenzelm@60642
   623
  -> thm -> thm"} \\
wenzelm@42401
   624
  @{index_ML Thm.add_axiom: "Proof.context ->
wenzelm@42401
   625
  binding * term -> theory -> (string * thm) * theory"} \\
wenzelm@39821
   626
  @{index_ML Thm.add_oracle: "binding * ('a -> cterm) -> theory ->
wenzelm@39821
   627
  (string * ('a -> thm)) * theory"} \\
wenzelm@61261
   628
  @{index_ML Thm.add_def: "Defs.context -> bool -> bool ->
wenzelm@42401
   629
  binding * term -> theory -> (string * thm) * theory"} \\
wenzelm@20547
   630
  \end{mldecls}
wenzelm@20547
   631
  \begin{mldecls}
wenzelm@61261
   632
  @{index_ML Theory.add_deps: "Defs.context -> string ->
wenzelm@61255
   633
  Defs.entry -> Defs.entry list -> theory -> theory"} \\
wenzelm@20521
   634
  \end{mldecls}
wenzelm@20521
   635
wenzelm@61493
   636
  \<^descr> @{ML Thm.peek_status}~\<open>thm\<close> informs about the current
wenzelm@50126
   637
  status of the derivation object behind the given theorem.  This is a
wenzelm@50126
   638
  snapshot of a potentially ongoing (parallel) evaluation of proofs.
wenzelm@50126
   639
  The three Boolean values indicate the following: @{verbatim oracle}
wenzelm@50126
   640
  if the finished part contains some oracle invocation; @{verbatim
wenzelm@50126
   641
  unfinished} if some future proofs are still pending; @{verbatim
wenzelm@50126
   642
  failed} if some future proof has failed, rendering the theorem
wenzelm@50126
   643
  invalid!
wenzelm@50126
   644
wenzelm@61493
   645
  \<^descr> @{ML Logic.all}~\<open>a B\<close> produces a Pure quantification
wenzelm@61493
   646
  \<open>\<And>a. B\<close>, where occurrences of the atomic term \<open>a\<close> in
wenzelm@61493
   647
  the body proposition \<open>B\<close> are replaced by bound variables.
wenzelm@46253
   648
  (See also @{ML lambda} on terms.)
wenzelm@46253
   649
wenzelm@61493
   650
  \<^descr> @{ML Logic.mk_implies}~\<open>(A, B)\<close> produces a Pure
wenzelm@61493
   651
  implication \<open>A \<Longrightarrow> B\<close>.
wenzelm@46253
   652
wenzelm@61439
   653
  \<^descr> Types @{ML_type ctyp} and @{ML_type cterm} represent certified
wenzelm@39864
   654
  types and terms, respectively.  These are abstract datatypes that
wenzelm@20542
   655
  guarantee that its values have passed the full well-formedness (and
wenzelm@20542
   656
  well-typedness) checks, relative to the declarations of type
wenzelm@46253
   657
  constructors, constants etc.\ in the background theory.  The
wenzelm@46253
   658
  abstract types @{ML_type ctyp} and @{ML_type cterm} are part of the
wenzelm@46253
   659
  same inference kernel that is mainly responsible for @{ML_type thm}.
wenzelm@46253
   660
  Thus syntactic operations on @{ML_type ctyp} and @{ML_type cterm}
wenzelm@55837
   661
  are located in the @{ML_structure Thm} module, even though theorems are
wenzelm@46253
   662
  not yet involved at that stage.
wenzelm@20542
   663
wenzelm@61493
   664
  \<^descr> @{ML Thm.ctyp_of}~\<open>ctxt \<tau>\<close> and @{ML
wenzelm@61493
   665
  Thm.cterm_of}~\<open>ctxt t\<close> explicitly check types and terms,
wenzelm@29768
   666
  respectively.  This also involves some basic normalizations, such
wenzelm@59621
   667
  expansion of type and term abbreviations from the underlying
wenzelm@59621
   668
  theory context.
wenzelm@46253
   669
  Full re-certification is relatively slow and should be avoided in
wenzelm@46253
   670
  tight reasoning loops.
wenzelm@20547
   671
wenzelm@61439
   672
  \<^descr> @{ML Thm.apply}, @{ML Thm.lambda}, @{ML Thm.all}, @{ML
wenzelm@46253
   673
  Drule.mk_implies} etc.\ compose certified terms (or propositions)
wenzelm@46253
   674
  incrementally.  This is equivalent to @{ML Thm.cterm_of} after
wenzelm@46262
   675
  unchecked @{ML_op "$"}, @{ML lambda}, @{ML Logic.all}, @{ML
wenzelm@46253
   676
  Logic.mk_implies} etc., but there can be a big difference in
wenzelm@46253
   677
  performance when large existing entities are composed by a few extra
wenzelm@46253
   678
  constructions on top.  There are separate operations to decompose
wenzelm@46253
   679
  certified terms and theorems to produce certified terms again.
wenzelm@20542
   680
wenzelm@61439
   681
  \<^descr> Type @{ML_type thm} represents proven propositions.  This is
wenzelm@39864
   682
  an abstract datatype that guarantees that its values have been
wenzelm@55837
   683
  constructed by basic principles of the @{ML_structure Thm} module.
wenzelm@52788
   684
  Every @{ML_type thm} value refers its background theory,
wenzelm@52788
   685
  cf.\ \secref{sec:context-theory}.
wenzelm@20542
   686
wenzelm@61493
   687
  \<^descr> @{ML Thm.transfer}~\<open>thy thm\<close> transfers the given
wenzelm@61477
   688
  theorem to a \<^emph>\<open>larger\<close> theory, see also \secref{sec:context}.
wenzelm@42933
   689
  This formal adjustment of the background context has no logical
wenzelm@42933
   690
  significance, but is occasionally required for formal reasons, e.g.\
wenzelm@42933
   691
  when theorems that are imported from more basic theories are used in
wenzelm@42933
   692
  the current situation.
wenzelm@42933
   693
wenzelm@61439
   694
  \<^descr> @{ML Thm.assume}, @{ML Thm.forall_intr}, @{ML
wenzelm@20542
   695
  Thm.forall_elim}, @{ML Thm.implies_intr}, and @{ML Thm.implies_elim}
wenzelm@20542
   696
  correspond to the primitive inferences of \figref{fig:prim-rules}.
wenzelm@20542
   697
wenzelm@61493
   698
  \<^descr> @{ML Thm.generalize}~\<open>(\<^vec>\<alpha>, \<^vec>x)\<close>
wenzelm@61493
   699
  corresponds to the \<open>generalize\<close> rules of
wenzelm@20543
   700
  \figref{fig:subst-rules}.  Here collections of type and term
wenzelm@20543
   701
  variables are generalized simultaneously, specified by the given
wenzelm@20543
   702
  basic names.
wenzelm@20521
   703
wenzelm@61493
   704
  \<^descr> @{ML Thm.instantiate}~\<open>(\<^vec>\<alpha>\<^sub>s,
wenzelm@61493
   705
  \<^vec>x\<^sub>\<tau>)\<close> corresponds to the \<open>instantiate\<close> rules
wenzelm@20542
   706
  of \figref{fig:subst-rules}.  Type variables are substituted before
wenzelm@61493
   707
  term variables.  Note that the types in \<open>\<^vec>x\<^sub>\<tau>\<close>
wenzelm@20542
   708
  refer to the instantiated versions.
wenzelm@20542
   709
wenzelm@61493
   710
  \<^descr> @{ML Thm.add_axiom}~\<open>ctxt (name, A)\<close> declares an
wenzelm@35927
   711
  arbitrary proposition as axiom, and retrieves it as a theorem from
wenzelm@61493
   712
  the resulting theory, cf.\ \<open>axiom\<close> in
wenzelm@35927
   713
  \figref{fig:prim-rules}.  Note that the low-level representation in
wenzelm@35927
   714
  the axiom table may differ slightly from the returned theorem.
wenzelm@20542
   715
wenzelm@61493
   716
  \<^descr> @{ML Thm.add_oracle}~\<open>(binding, oracle)\<close> produces a named
wenzelm@28290
   717
  oracle rule, essentially generating arbitrary axioms on the fly,
wenzelm@61493
   718
  cf.\ \<open>axiom\<close> in \figref{fig:prim-rules}.
wenzelm@20521
   719
wenzelm@61493
   720
  \<^descr> @{ML Thm.add_def}~\<open>ctxt unchecked overloaded (name, c
wenzelm@61493
   721
  \<^vec>x \<equiv> t)\<close> states a definitional axiom for an existing constant
wenzelm@61493
   722
  \<open>c\<close>.  Dependencies are recorded via @{ML Theory.add_deps},
wenzelm@61493
   723
  unless the \<open>unchecked\<close> option is set.  Note that the
wenzelm@35927
   724
  low-level representation in the axiom table may differ slightly from
wenzelm@35927
   725
  the returned theorem.
wenzelm@20542
   726
wenzelm@61493
   727
  \<^descr> @{ML Theory.add_deps}~\<open>ctxt name c\<^sub>\<tau> \<^vec>d\<^sub>\<sigma>\<close>
wenzelm@61493
   728
  declares dependencies of a named specification for constant \<open>c\<^sub>\<tau>\<close>, relative to existing specifications for constants \<open>\<^vec>d\<^sub>\<sigma>\<close>.  This also works for type constructors.
wenzelm@58618
   729
\<close>
wenzelm@20521
   730
wenzelm@20521
   731
wenzelm@58618
   732
text %mlantiq \<open>
wenzelm@39832
   733
  \begin{matharray}{rcl}
wenzelm@61493
   734
  @{ML_antiquotation_def "ctyp"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   735
  @{ML_antiquotation_def "cterm"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   736
  @{ML_antiquotation_def "cprop"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   737
  @{ML_antiquotation_def "thm"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   738
  @{ML_antiquotation_def "thms"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@61493
   739
  @{ML_antiquotation_def "lemma"} & : & \<open>ML_antiquotation\<close> \\
wenzelm@39832
   740
  \end{matharray}
wenzelm@39832
   741
wenzelm@55112
   742
  @{rail \<open>
wenzelm@42510
   743
  @@{ML_antiquotation ctyp} typ
wenzelm@39832
   744
  ;
wenzelm@42510
   745
  @@{ML_antiquotation cterm} term
wenzelm@39832
   746
  ;
wenzelm@42510
   747
  @@{ML_antiquotation cprop} prop
wenzelm@39832
   748
  ;
wenzelm@42510
   749
  @@{ML_antiquotation thm} thmref
wenzelm@42510
   750
  ;
wenzelm@42510
   751
  @@{ML_antiquotation thms} thmrefs
wenzelm@39832
   752
  ;
wenzelm@55029
   753
  @@{ML_antiquotation lemma} ('(' @'open' ')')? ((prop +) + @'and') \<newline>
wenzelm@42517
   754
    @'by' method method?
wenzelm@55112
   755
  \<close>}
wenzelm@39832
   756
wenzelm@61493
   757
  \<^descr> \<open>@{ctyp \<tau>}\<close> produces a certified type wrt.\ the
wenzelm@39832
   758
  current background theory --- as abstract value of type @{ML_type
wenzelm@39832
   759
  ctyp}.
wenzelm@39832
   760
wenzelm@61493
   761
  \<^descr> \<open>@{cterm t}\<close> and \<open>@{cprop \<phi>}\<close> produce a
wenzelm@39832
   762
  certified term wrt.\ the current background theory --- as abstract
wenzelm@39832
   763
  value of type @{ML_type cterm}.
wenzelm@39832
   764
wenzelm@61493
   765
  \<^descr> \<open>@{thm a}\<close> produces a singleton fact --- as abstract
wenzelm@39832
   766
  value of type @{ML_type thm}.
wenzelm@39832
   767
wenzelm@61493
   768
  \<^descr> \<open>@{thms a}\<close> produces a general fact --- as abstract
wenzelm@39832
   769
  value of type @{ML_type "thm list"}.
wenzelm@39832
   770
wenzelm@61493
   771
  \<^descr> \<open>@{lemma \<phi> by meth}\<close> produces a fact that is proven on
wenzelm@39832
   772
  the spot according to the minimal proof, which imitates a terminal
wenzelm@39832
   773
  Isar proof.  The result is an abstract value of type @{ML_type thm}
wenzelm@39832
   774
  or @{ML_type "thm list"}, depending on the number of propositions
wenzelm@39832
   775
  given here.
wenzelm@39832
   776
wenzelm@39832
   777
  The internal derivation object lacks a proper theorem name, but it
wenzelm@61493
   778
  is formally closed, unless the \<open>(open)\<close> option is specified
wenzelm@39832
   779
  (this may impact performance of applications with proof terms).
wenzelm@39832
   780
wenzelm@39832
   781
  Since ML antiquotations are always evaluated at compile-time, there
wenzelm@39832
   782
  is no run-time overhead even for non-trivial proofs.  Nonetheless,
wenzelm@39832
   783
  the justification is syntactically limited to a single @{command
wenzelm@39832
   784
  "by"} step.  More complex Isar proofs should be done in regular
wenzelm@39832
   785
  theory source, before compiling the corresponding ML text that uses
wenzelm@39832
   786
  the result.
wenzelm@58618
   787
\<close>
wenzelm@39832
   788
wenzelm@39832
   789
wenzelm@58618
   790
subsection \<open>Auxiliary connectives \label{sec:logic-aux}\<close>
wenzelm@20521
   791
wenzelm@61493
   792
text \<open>Theory \<open>Pure\<close> provides a few auxiliary connectives
wenzelm@46254
   793
  that are defined on top of the primitive ones, see
wenzelm@46254
   794
  \figref{fig:pure-aux}.  These special constants are useful in
wenzelm@46254
   795
  certain internal encodings, and are normally not directly exposed to
wenzelm@46254
   796
  the user.
wenzelm@20501
   797
wenzelm@20501
   798
  \begin{figure}[htb]
wenzelm@20501
   799
  \begin{center}
wenzelm@20498
   800
  \begin{tabular}{ll}
wenzelm@61493
   801
  \<open>conjunction :: prop \<Rightarrow> prop \<Rightarrow> prop\<close> & (infix \<open>&&&\<close>) \\
wenzelm@61493
   802
  \<open>\<turnstile> A &&& B \<equiv> (\<And>C. (A \<Longrightarrow> B \<Longrightarrow> C) \<Longrightarrow> C)\<close> \\[1ex]
wenzelm@61493
   803
  \<open>prop :: prop \<Rightarrow> prop\<close> & (prefix \<open>#\<close>, suppressed) \\
wenzelm@61493
   804
  \<open>#A \<equiv> A\<close> \\[1ex]
wenzelm@61493
   805
  \<open>term :: \<alpha> \<Rightarrow> prop\<close> & (prefix \<open>TERM\<close>) \\
wenzelm@61493
   806
  \<open>term x \<equiv> (\<And>A. A \<Longrightarrow> A)\<close> \\[1ex]
wenzelm@61493
   807
  \<open>type :: \<alpha> itself\<close> & (prefix \<open>TYPE\<close>) \\
wenzelm@61493
   808
  \<open>(unspecified)\<close> \\
wenzelm@20498
   809
  \end{tabular}
wenzelm@20521
   810
  \caption{Definitions of auxiliary connectives}\label{fig:pure-aux}
wenzelm@20501
   811
  \end{center}
wenzelm@20501
   812
  \end{figure}
wenzelm@20501
   813
wenzelm@61493
   814
  The introduction \<open>A \<Longrightarrow> B \<Longrightarrow> A &&& B\<close>, and eliminations
wenzelm@61493
   815
  (projections) \<open>A &&& B \<Longrightarrow> A\<close> and \<open>A &&& B \<Longrightarrow> B\<close> are
wenzelm@34929
   816
  available as derived rules.  Conjunction allows to treat
wenzelm@34929
   817
  simultaneous assumptions and conclusions uniformly, e.g.\ consider
wenzelm@61493
   818
  \<open>A \<Longrightarrow> B \<Longrightarrow> C &&& D\<close>.  In particular, the goal mechanism
wenzelm@34929
   819
  represents multiple claims as explicit conjunction internally, but
wenzelm@34929
   820
  this is refined (via backwards introduction) into separate sub-goals
wenzelm@34929
   821
  before the user commences the proof; the final result is projected
wenzelm@34929
   822
  into a list of theorems using eliminations (cf.\
wenzelm@20537
   823
  \secref{sec:tactical-goals}).
wenzelm@20498
   824
wenzelm@61493
   825
  The \<open>prop\<close> marker (\<open>#\<close>) makes arbitrarily complex
wenzelm@61493
   826
  propositions appear as atomic, without changing the meaning: \<open>\<Gamma> \<turnstile> A\<close> and \<open>\<Gamma> \<turnstile> #A\<close> are interchangeable.  See
wenzelm@20537
   827
  \secref{sec:tactical-goals} for specific operations.
wenzelm@20521
   828
wenzelm@61493
   829
  The \<open>term\<close> marker turns any well-typed term into a derivable
wenzelm@61493
   830
  proposition: \<open>\<turnstile> TERM t\<close> holds unconditionally.  Although
wenzelm@20543
   831
  this is logically vacuous, it allows to treat terms and proofs
wenzelm@20543
   832
  uniformly, similar to a type-theoretic framework.
wenzelm@20498
   833
wenzelm@61493
   834
  The \<open>TYPE\<close> constructor is the canonical representative of
wenzelm@61493
   835
  the unspecified type \<open>\<alpha> itself\<close>; it essentially injects the
wenzelm@20537
   836
  language of types into that of terms.  There is specific notation
wenzelm@61493
   837
  \<open>TYPE(\<tau>)\<close> for \<open>TYPE\<^bsub>\<tau> itself\<^esub>\<close>.
wenzelm@61493
   838
  Although being devoid of any particular meaning, the term \<open>TYPE(\<tau>)\<close> accounts for the type \<open>\<tau>\<close> within the term
wenzelm@61493
   839
  language.  In particular, \<open>TYPE(\<alpha>)\<close> may be used as formal
wenzelm@20537
   840
  argument in primitive definitions, in order to circumvent hidden
wenzelm@61493
   841
  polymorphism (cf.\ \secref{sec:terms}).  For example, \<open>c
wenzelm@61493
   842
  TYPE(\<alpha>) \<equiv> A[\<alpha>]\<close> defines \<open>c :: \<alpha> itself \<Rightarrow> prop\<close> in terms of
wenzelm@61493
   843
  a proposition \<open>A\<close> that depends on an additional type
wenzelm@20537
   844
  argument, which is essentially a predicate on types.
wenzelm@58618
   845
\<close>
wenzelm@20501
   846
wenzelm@58618
   847
text %mlref \<open>
wenzelm@20521
   848
  \begin{mldecls}
wenzelm@20521
   849
  @{index_ML Conjunction.intr: "thm -> thm -> thm"} \\
wenzelm@20521
   850
  @{index_ML Conjunction.elim: "thm -> thm * thm"} \\
wenzelm@20521
   851
  @{index_ML Drule.mk_term: "cterm -> thm"} \\
wenzelm@20521
   852
  @{index_ML Drule.dest_term: "thm -> cterm"} \\
wenzelm@20521
   853
  @{index_ML Logic.mk_type: "typ -> term"} \\
wenzelm@20521
   854
  @{index_ML Logic.dest_type: "term -> typ"} \\
wenzelm@20521
   855
  \end{mldecls}
wenzelm@20521
   856
wenzelm@61493
   857
  \<^descr> @{ML Conjunction.intr} derives \<open>A &&& B\<close> from \<open>A\<close> and \<open>B\<close>.
wenzelm@20542
   858
wenzelm@61493
   859
  \<^descr> @{ML Conjunction.elim} derives \<open>A\<close> and \<open>B\<close>
wenzelm@61493
   860
  from \<open>A &&& B\<close>.
wenzelm@20542
   861
wenzelm@61493
   862
  \<^descr> @{ML Drule.mk_term} derives \<open>TERM t\<close>.
wenzelm@20542
   863
wenzelm@61493
   864
  \<^descr> @{ML Drule.dest_term} recovers term \<open>t\<close> from \<open>TERM t\<close>.
wenzelm@20542
   865
wenzelm@61493
   866
  \<^descr> @{ML Logic.mk_type}~\<open>\<tau>\<close> produces the term \<open>TYPE(\<tau>)\<close>.
wenzelm@20542
   867
wenzelm@61493
   868
  \<^descr> @{ML Logic.dest_type}~\<open>TYPE(\<tau>)\<close> recovers the type
wenzelm@61493
   869
  \<open>\<tau>\<close>.
wenzelm@58618
   870
\<close>
wenzelm@18537
   871
wenzelm@20480
   872
wenzelm@58618
   873
subsection \<open>Sort hypotheses\<close>
wenzelm@52406
   874
wenzelm@58618
   875
text \<open>Type variables are decorated with sorts, as explained in
wenzelm@52406
   876
  \secref{sec:types}.  This constrains type instantiation to certain
wenzelm@61493
   877
  ranges of types: variable \<open>\<alpha>\<^sub>s\<close> may only be assigned to types
wenzelm@61493
   878
  \<open>\<tau>\<close> that belong to sort \<open>s\<close>.  Within the logic, sort
wenzelm@61493
   879
  constraints act like implicit preconditions on the result \<open>\<lparr>\<alpha>\<^sub>1 : s\<^sub>1\<rparr>, \<dots>, \<lparr>\<alpha>\<^sub>n : s\<^sub>n\<rparr>, \<Gamma> \<turnstile> \<phi>\<close> where the type variables \<open>\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n\<close> cover the propositions \<open>\<Gamma>\<close>, \<open>\<phi>\<close>, as
wenzelm@61493
   880
  well as the proof of \<open>\<Gamma> \<turnstile> \<phi>\<close>.
wenzelm@52406
   881
wenzelm@61477
   882
  These \<^emph>\<open>sort hypothesis\<close> of a theorem are passed monotonically
wenzelm@52406
   883
  through further derivations.  They are redundant, as long as the
wenzelm@52406
   884
  statement of a theorem still contains the type variables that are
wenzelm@52406
   885
  accounted here.  The logical significance of sort hypotheses is
wenzelm@52406
   886
  limited to the boundary case where type variables disappear from the
wenzelm@61493
   887
  proposition, e.g.\ \<open>\<lparr>\<alpha>\<^sub>s : s\<rparr> \<turnstile> \<phi>\<close>.  Since such dangling type
wenzelm@52406
   888
  variables can be renamed arbitrarily without changing the
wenzelm@61493
   889
  proposition \<open>\<phi>\<close>, the inference kernel maintains sort
wenzelm@61493
   890
  hypotheses in anonymous form \<open>s \<turnstile> \<phi>\<close>.
wenzelm@52406
   891
wenzelm@52406
   892
  In most practical situations, such extra sort hypotheses may be
wenzelm@52406
   893
  stripped in a final bookkeeping step, e.g.\ at the end of a proof:
wenzelm@52406
   894
  they are typically left over from intermediate reasoning with type
wenzelm@61493
   895
  classes that can be satisfied by some concrete type \<open>\<tau>\<close> of
wenzelm@61493
   896
  sort \<open>s\<close> to replace the hypothetical type variable \<open>\<alpha>\<^sub>s\<close>.\<close>
wenzelm@52406
   897
wenzelm@58618
   898
text %mlref \<open>
wenzelm@52406
   899
  \begin{mldecls}
wenzelm@52406
   900
  @{index_ML Thm.extra_shyps: "thm -> sort list"} \\
wenzelm@52406
   901
  @{index_ML Thm.strip_shyps: "thm -> thm"} \\
wenzelm@52406
   902
  \end{mldecls}
wenzelm@52406
   903
wenzelm@61493
   904
  \<^descr> @{ML Thm.extra_shyps}~\<open>thm\<close> determines the extraneous
wenzelm@52406
   905
  sort hypotheses of the given theorem, i.e.\ the sorts that are not
wenzelm@52406
   906
  present within type variables of the statement.
wenzelm@52406
   907
wenzelm@61493
   908
  \<^descr> @{ML Thm.strip_shyps}~\<open>thm\<close> removes any extraneous
wenzelm@52406
   909
  sort hypotheses that can be witnessed from the type signature.
wenzelm@58618
   910
\<close>
wenzelm@52406
   911
wenzelm@58618
   912
text %mlex \<open>The following artificial example demonstrates the
wenzelm@52406
   913
  derivation of @{prop False} with a pending sort hypothesis involving
wenzelm@58618
   914
  a logically empty sort.\<close>
wenzelm@52406
   915
wenzelm@52406
   916
class empty =
wenzelm@52406
   917
  assumes bad: "\<And>(x::'a) y. x \<noteq> y"
wenzelm@52406
   918
wenzelm@52406
   919
theorem (in empty) false: False
wenzelm@52406
   920
  using bad by blast
wenzelm@52406
   921
wenzelm@59902
   922
ML_val \<open>@{assert} (Thm.extra_shyps @{thm false} = [@{sort empty}])\<close>
wenzelm@52406
   923
wenzelm@58618
   924
text \<open>Thanks to the inference kernel managing sort hypothesis
wenzelm@52406
   925
  according to their logical significance, this example is merely an
wenzelm@61477
   926
  instance of \<^emph>\<open>ex falso quodlibet consequitur\<close> --- not a collapse
wenzelm@58618
   927
  of the logical framework!\<close>
wenzelm@52406
   928
wenzelm@52406
   929
wenzelm@58618
   930
section \<open>Object-level rules \label{sec:obj-rules}\<close>
wenzelm@18537
   931
wenzelm@58618
   932
text \<open>
wenzelm@29768
   933
  The primitive inferences covered so far mostly serve foundational
wenzelm@29768
   934
  purposes.  User-level reasoning usually works via object-level rules
wenzelm@29768
   935
  that are represented as theorems of Pure.  Composition of rules
wenzelm@61477
   936
  involves \<^emph>\<open>backchaining\<close>, \<^emph>\<open>higher-order unification\<close> modulo
wenzelm@61493
   937
  \<open>\<alpha>\<beta>\<eta>\<close>-conversion of \<open>\<lambda>\<close>-terms, and so-called
wenzelm@61493
   938
  \<^emph>\<open>lifting\<close> of rules into a context of \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> connectives.  Thus the full power of higher-order Natural
wenzelm@29774
   939
  Deduction in Isabelle/Pure becomes readily available.
wenzelm@58618
   940
\<close>
wenzelm@20491
   941
wenzelm@29769
   942
wenzelm@58618
   943
subsection \<open>Hereditary Harrop Formulae\<close>
wenzelm@29769
   944
wenzelm@58618
   945
text \<open>
wenzelm@29768
   946
  The idea of object-level rules is to model Natural Deduction
wenzelm@58555
   947
  inferences in the style of Gentzen @{cite "Gentzen:1935"}, but we allow
wenzelm@58555
   948
  arbitrary nesting similar to @{cite extensions91}.  The most basic
wenzelm@61477
   949
  rule format is that of a \<^emph>\<open>Horn Clause\<close>:
wenzelm@29768
   950
  \[
wenzelm@61493
   951
  \infer{\<open>A\<close>}{\<open>A\<^sub>1\<close> & \<open>\<dots>\<close> & \<open>A\<^sub>n\<close>}
wenzelm@29768
   952
  \]
wenzelm@61493
   953
  where \<open>A, A\<^sub>1, \<dots>, A\<^sub>n\<close> are atomic propositions
wenzelm@61493
   954
  of the framework, usually of the form \<open>Trueprop B\<close>, where
wenzelm@61493
   955
  \<open>B\<close> is a (compound) object-level statement.  This
wenzelm@29768
   956
  object-level inference corresponds to an iterated implication in
wenzelm@29768
   957
  Pure like this:
wenzelm@29768
   958
  \[
wenzelm@61493
   959
  \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> A\<close>
wenzelm@29768
   960
  \]
wenzelm@61493
   961
  As an example consider conjunction introduction: \<open>A \<Longrightarrow> B \<Longrightarrow> A \<and>
wenzelm@61493
   962
  B\<close>.  Any parameters occurring in such rule statements are
wenzelm@29769
   963
  conceptionally treated as arbitrary:
wenzelm@29768
   964
  \[
wenzelm@61493
   965
  \<open>\<And>x\<^sub>1 \<dots> x\<^sub>m. A\<^sub>1 x\<^sub>1 \<dots> x\<^sub>m \<Longrightarrow> \<dots> A\<^sub>n x\<^sub>1 \<dots> x\<^sub>m \<Longrightarrow> A x\<^sub>1 \<dots> x\<^sub>m\<close>
wenzelm@29768
   966
  \]
wenzelm@20491
   967
wenzelm@61493
   968
  Nesting of rules means that the positions of \<open>A\<^sub>i\<close> may
wenzelm@29770
   969
  again hold compound rules, not just atomic propositions.
wenzelm@61477
   970
  Propositions of this format are called \<^emph>\<open>Hereditary Harrop
wenzelm@61477
   971
  Formulae\<close> in the literature @{cite "Miller:1991"}.  Here we give an
wenzelm@29769
   972
  inductive characterization as follows:
wenzelm@29768
   973
wenzelm@61416
   974
  \<^medskip>
wenzelm@29768
   975
  \begin{tabular}{ll}
wenzelm@61493
   976
  \<open>\<^bold>x\<close> & set of variables \\
wenzelm@61493
   977
  \<open>\<^bold>A\<close> & set of atomic propositions \\
wenzelm@61493
   978
  \<open>\<^bold>H  =  \<And>\<^bold>x\<^sup>*. \<^bold>H\<^sup>* \<Longrightarrow> \<^bold>A\<close> & set of Hereditary Harrop Formulas \\
wenzelm@29768
   979
  \end{tabular}
wenzelm@61416
   980
  \<^medskip>
wenzelm@29768
   981
wenzelm@39861
   982
  Thus we essentially impose nesting levels on propositions formed
wenzelm@61493
   983
  from \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close>.  At each level there is a prefix
wenzelm@39861
   984
  of parameters and compound premises, concluding an atomic
wenzelm@61493
   985
  proposition.  Typical examples are \<open>\<longrightarrow>\<close>-introduction \<open>(A \<Longrightarrow> B) \<Longrightarrow> A \<longrightarrow> B\<close> or mathematical induction \<open>P 0 \<Longrightarrow> (\<And>n. P n
wenzelm@61493
   986
  \<Longrightarrow> P (Suc n)) \<Longrightarrow> P n\<close>.  Even deeper nesting occurs in well-founded
wenzelm@61493
   987
  induction \<open>(\<And>x. (\<And>y. y \<prec> x \<Longrightarrow> P y) \<Longrightarrow> P x) \<Longrightarrow> P x\<close>, but this
wenzelm@34929
   988
  already marks the limit of rule complexity that is usually seen in
wenzelm@34929
   989
  practice.
wenzelm@29769
   990
wenzelm@61416
   991
  \<^medskip>
wenzelm@61416
   992
  Regular user-level inferences in Isabelle/Pure always
wenzelm@29770
   993
  maintain the following canonical form of results:
wenzelm@29769
   994
wenzelm@61493
   995
  \<^item> Normalization by \<open>(A \<Longrightarrow> (\<And>x. B x)) \<equiv> (\<And>x. A \<Longrightarrow> B x)\<close>,
wenzelm@29774
   996
  which is a theorem of Pure, means that quantifiers are pushed in
wenzelm@29774
   997
  front of implication at each level of nesting.  The normal form is a
wenzelm@29774
   998
  Hereditary Harrop Formula.
wenzelm@29769
   999
wenzelm@61416
  1000
  \<^item> The outermost prefix of parameters is represented via
wenzelm@61493
  1001
  schematic variables: instead of \<open>\<And>\<^vec>x. \<^vec>H \<^vec>x
wenzelm@61493
  1002
  \<Longrightarrow> A \<^vec>x\<close> we have \<open>\<^vec>H ?\<^vec>x \<Longrightarrow> A ?\<^vec>x\<close>.
wenzelm@29774
  1003
  Note that this representation looses information about the order of
wenzelm@29774
  1004
  parameters, and vacuous quantifiers vanish automatically.
wenzelm@58618
  1005
\<close>
wenzelm@29769
  1006
wenzelm@58618
  1007
text %mlref \<open>
wenzelm@29771
  1008
  \begin{mldecls}
wenzelm@54883
  1009
  @{index_ML Simplifier.norm_hhf: "Proof.context -> thm -> thm"} \\
wenzelm@29771
  1010
  \end{mldecls}
wenzelm@29771
  1011
wenzelm@61493
  1012
  \<^descr> @{ML Simplifier.norm_hhf}~\<open>ctxt thm\<close> normalizes the given
wenzelm@29771
  1013
  theorem according to the canonical form specified above.  This is
wenzelm@29771
  1014
  occasionally helpful to repair some low-level tools that do not
wenzelm@29771
  1015
  handle Hereditary Harrop Formulae properly.
wenzelm@58618
  1016
\<close>
wenzelm@29771
  1017
wenzelm@29769
  1018
wenzelm@58618
  1019
subsection \<open>Rule composition\<close>
wenzelm@29769
  1020
wenzelm@58618
  1021
text \<open>
wenzelm@29771
  1022
  The rule calculus of Isabelle/Pure provides two main inferences:
wenzelm@29771
  1023
  @{inference resolution} (i.e.\ back-chaining of rules) and
wenzelm@29771
  1024
  @{inference assumption} (i.e.\ closing a branch), both modulo
wenzelm@29771
  1025
  higher-order unification.  There are also combined variants, notably
wenzelm@29771
  1026
  @{inference elim_resolution} and @{inference dest_resolution}.
wenzelm@20491
  1027
wenzelm@29771
  1028
  To understand the all-important @{inference resolution} principle,
wenzelm@29771
  1029
  we first consider raw @{inference_def composition} (modulo
wenzelm@61493
  1030
  higher-order unification with substitution \<open>\<vartheta>\<close>):
wenzelm@20498
  1031
  \[
wenzelm@61493
  1032
  \infer[(@{inference_def composition})]{\<open>\<^vec>A\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
wenzelm@61493
  1033
  {\<open>\<^vec>A \<Longrightarrow> B\<close> & \<open>B' \<Longrightarrow> C\<close> & \<open>B\<vartheta> = B'\<vartheta>\<close>}
wenzelm@20498
  1034
  \]
wenzelm@29771
  1035
  Here the conclusion of the first rule is unified with the premise of
wenzelm@29771
  1036
  the second; the resulting rule instance inherits the premises of the
wenzelm@61493
  1037
  first and conclusion of the second.  Note that \<open>C\<close> can again
wenzelm@29771
  1038
  consist of iterated implications.  We can also permute the premises
wenzelm@61493
  1039
  of the second rule back-and-forth in order to compose with \<open>B'\<close> in any position (subsequently we shall always refer to
wenzelm@29771
  1040
  position 1 w.l.o.g.).
wenzelm@20498
  1041
wenzelm@29774
  1042
  In @{inference composition} the internal structure of the common
wenzelm@61493
  1043
  part \<open>B\<close> and \<open>B'\<close> is not taken into account.  For
wenzelm@61493
  1044
  proper @{inference resolution} we require \<open>B\<close> to be atomic,
wenzelm@61493
  1045
  and explicitly observe the structure \<open>\<And>\<^vec>x. \<^vec>H
wenzelm@61493
  1046
  \<^vec>x \<Longrightarrow> B' \<^vec>x\<close> of the premise of the second rule.  The
wenzelm@29774
  1047
  idea is to adapt the first rule by ``lifting'' it into this context,
wenzelm@29774
  1048
  by means of iterated application of the following inferences:
wenzelm@20498
  1049
  \[
wenzelm@61493
  1050
  \infer[(@{inference_def imp_lift})]{\<open>(\<^vec>H \<Longrightarrow> \<^vec>A) \<Longrightarrow> (\<^vec>H \<Longrightarrow> B)\<close>}{\<open>\<^vec>A \<Longrightarrow> B\<close>}
wenzelm@20498
  1051
  \]
wenzelm@20498
  1052
  \[
wenzelm@61493
  1053
  \infer[(@{inference_def all_lift})]{\<open>(\<And>\<^vec>x. \<^vec>A (?\<^vec>a \<^vec>x)) \<Longrightarrow> (\<And>\<^vec>x. B (?\<^vec>a \<^vec>x))\<close>}{\<open>\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a\<close>}
wenzelm@20498
  1054
  \]
wenzelm@29771
  1055
  By combining raw composition with lifting, we get full @{inference
wenzelm@29771
  1056
  resolution} as follows:
wenzelm@20498
  1057
  \[
wenzelm@29771
  1058
  \infer[(@{inference_def resolution})]
wenzelm@61493
  1059
  {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>A (?\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
wenzelm@20498
  1060
  {\begin{tabular}{l}
wenzelm@61493
  1061
    \<open>\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a\<close> \\
wenzelm@61493
  1062
    \<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C\<close> \\
wenzelm@61493
  1063
    \<open>(\<lambda>\<^vec>x. B (?\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>\<close> \\
wenzelm@20498
  1064
   \end{tabular}}
wenzelm@20498
  1065
  \]
wenzelm@20498
  1066
wenzelm@29774
  1067
  Continued resolution of rules allows to back-chain a problem towards
wenzelm@29774
  1068
  more and sub-problems.  Branches are closed either by resolving with
wenzelm@29774
  1069
  a rule of 0 premises, or by producing a ``short-circuit'' within a
wenzelm@29774
  1070
  solved situation (again modulo unification):
wenzelm@29771
  1071
  \[
wenzelm@61493
  1072
  \infer[(@{inference_def assumption})]{\<open>C\<vartheta>\<close>}
wenzelm@61493
  1073
  {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> A \<^vec>x) \<Longrightarrow> C\<close> & \<open>A\<vartheta> = H\<^sub>i\<vartheta>\<close>~~\text{(for some~\<open>i\<close>)}}
wenzelm@29771
  1074
  \]
wenzelm@20498
  1075
wenzelm@52422
  1076
  %FIXME @{inference_def elim_resolution}, @{inference_def dest_resolution}
wenzelm@58618
  1077
\<close>
wenzelm@18537
  1078
wenzelm@58618
  1079
text %mlref \<open>
wenzelm@29768
  1080
  \begin{mldecls}
wenzelm@46262
  1081
  @{index_ML_op "RSN": "thm * (int * thm) -> thm"} \\
wenzelm@46262
  1082
  @{index_ML_op "RS": "thm * thm -> thm"} \\
wenzelm@46256
  1083
wenzelm@46262
  1084
  @{index_ML_op "RLN": "thm list * (int * thm list) -> thm list"} \\
wenzelm@46262
  1085
  @{index_ML_op "RL": "thm list * thm list -> thm list"} \\
wenzelm@46256
  1086
wenzelm@46262
  1087
  @{index_ML_op "MRS": "thm list * thm -> thm"} \\
wenzelm@46262
  1088
  @{index_ML_op "OF": "thm * thm list -> thm"} \\
wenzelm@29768
  1089
  \end{mldecls}
wenzelm@29768
  1090
wenzelm@61493
  1091
  \<^descr> \<open>rule\<^sub>1 RSN (i, rule\<^sub>2)\<close> resolves the conclusion of
wenzelm@61493
  1092
  \<open>rule\<^sub>1\<close> with the \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>,
wenzelm@46256
  1093
  according to the @{inference resolution} principle explained above.
wenzelm@46256
  1094
  Unless there is precisely one resolvent it raises exception @{ML
wenzelm@46256
  1095
  THM}.
wenzelm@46256
  1096
wenzelm@46256
  1097
  This corresponds to the rule attribute @{attribute THEN} in Isar
wenzelm@46256
  1098
  source language.
wenzelm@46256
  1099
wenzelm@61493
  1100
  \<^descr> \<open>rule\<^sub>1 RS rule\<^sub>2\<close> abbreviates \<open>rule\<^sub>1 RSN (1,
wenzelm@61493
  1101
  rule\<^sub>2)\<close>.
wenzelm@29768
  1102
wenzelm@61493
  1103
  \<^descr> \<open>rules\<^sub>1 RLN (i, rules\<^sub>2)\<close> joins lists of rules.  For
wenzelm@61493
  1104
  every \<open>rule\<^sub>1\<close> in \<open>rules\<^sub>1\<close> and \<open>rule\<^sub>2\<close> in
wenzelm@61493
  1105
  \<open>rules\<^sub>2\<close>, it resolves the conclusion of \<open>rule\<^sub>1\<close> with
wenzelm@61493
  1106
  the \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>, accumulating multiple
wenzelm@46256
  1107
  results in one big list.  Note that such strict enumerations of
wenzelm@46256
  1108
  higher-order unifications can be inefficient compared to the lazy
wenzelm@46256
  1109
  variant seen in elementary tactics like @{ML resolve_tac}.
wenzelm@46256
  1110
wenzelm@61493
  1111
  \<^descr> \<open>rules\<^sub>1 RL rules\<^sub>2\<close> abbreviates \<open>rules\<^sub>1 RLN (1,
wenzelm@61493
  1112
  rules\<^sub>2)\<close>.
wenzelm@46256
  1113
wenzelm@61493
  1114
  \<^descr> \<open>[rule\<^sub>1, \<dots>, rule\<^sub>n] MRS rule\<close> resolves \<open>rule\<^sub>i\<close>
wenzelm@61493
  1115
  against premise \<open>i\<close> of \<open>rule\<close>, for \<open>i = n, \<dots>,
wenzelm@61493
  1116
  1\<close>.  By working from right to left, newly emerging premises are
wenzelm@46256
  1117
  concatenated in the result, without interfering.
wenzelm@46256
  1118
wenzelm@61493
  1119
  \<^descr> \<open>rule OF rules\<close> is an alternative notation for \<open>rules MRS rule\<close>, which makes rule composition look more like
wenzelm@61493
  1120
  function application.  Note that the argument \<open>rules\<close> need
wenzelm@47498
  1121
  not be atomic.
wenzelm@46256
  1122
wenzelm@46256
  1123
  This corresponds to the rule attribute @{attribute OF} in Isar
wenzelm@46256
  1124
  source language.
wenzelm@58618
  1125
\<close>
wenzelm@30272
  1126
wenzelm@52407
  1127
wenzelm@58618
  1128
section \<open>Proof terms \label{sec:proof-terms}\<close>
wenzelm@52407
  1129
wenzelm@58618
  1130
text \<open>The Isabelle/Pure inference kernel can record the proof of
wenzelm@52407
  1131
  each theorem as a proof term that contains all logical inferences in
wenzelm@52407
  1132
  detail.  Rule composition by resolution (\secref{sec:obj-rules}) and
wenzelm@52407
  1133
  type-class reasoning is broken down to primitive rules of the
wenzelm@52407
  1134
  logical framework.  The proof term can be inspected by a separate
wenzelm@52407
  1135
  proof-checker, for example.
wenzelm@52407
  1136
wenzelm@61477
  1137
  According to the well-known \<^emph>\<open>Curry-Howard isomorphism\<close>, a proof
wenzelm@61493
  1138
  can be viewed as a \<open>\<lambda>\<close>-term. Following this idea, proofs in
wenzelm@52407
  1139
  Isabelle are internally represented by a datatype similar to the one
wenzelm@52407
  1140
  for terms described in \secref{sec:terms}.  On top of these
wenzelm@61493
  1141
  syntactic terms, two more layers of \<open>\<lambda>\<close>-calculus are added,
wenzelm@61493
  1142
  which correspond to \<open>\<And>x :: \<alpha>. B x\<close> and \<open>A \<Longrightarrow> B\<close>
wenzelm@52407
  1143
  according to the propositions-as-types principle.  The resulting
wenzelm@61493
  1144
  3-level \<open>\<lambda>\<close>-calculus resembles ``\<open>\<lambda>HOL\<close>'' in the
wenzelm@52407
  1145
  more abstract setting of Pure Type Systems (PTS)
wenzelm@58555
  1146
  @{cite "Barendregt-Geuvers:2001"}, if some fine points like schematic
wenzelm@52407
  1147
  polymorphism and type classes are ignored.
wenzelm@52407
  1148
wenzelm@61416
  1149
  \<^medskip>
wenzelm@61493
  1150
  \<^emph>\<open>Proof abstractions\<close> of the form \<open>\<^bold>\<lambda>x :: \<alpha>. prf\<close>
wenzelm@61493
  1151
  or \<open>\<^bold>\<lambda>p : A. prf\<close> correspond to introduction of \<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>, and \<^emph>\<open>proof applications\<close> of the form \<open>p \<cdot> t\<close> or \<open>p \<bullet> q\<close> correspond to elimination of \<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>.  Actual types \<open>\<alpha>\<close>, propositions \<open>A\<close>, and terms \<open>t\<close> might be suppressed and reconstructed
wenzelm@52407
  1152
  from the overall proof term.
wenzelm@52407
  1153
wenzelm@61416
  1154
  \<^medskip>
wenzelm@61416
  1155
  Various atomic proofs indicate special situations within
wenzelm@52407
  1156
  the proof construction as follows.
wenzelm@52407
  1157
wenzelm@61493
  1158
  A \<^emph>\<open>bound proof variable\<close> is a natural number \<open>b\<close> that
wenzelm@52407
  1159
  acts as de-Bruijn index for proof term abstractions.
wenzelm@52407
  1160
wenzelm@61493
  1161
  A \<^emph>\<open>minimal proof\<close> ``\<open>?\<close>'' is a dummy proof term.  This
wenzelm@52407
  1162
  indicates some unrecorded part of the proof.
wenzelm@52407
  1163
wenzelm@61493
  1164
  \<open>Hyp A\<close> refers to some pending hypothesis by giving its
wenzelm@52407
  1165
  proposition.  This indicates an open context of implicit hypotheses,
wenzelm@52407
  1166
  similar to loose bound variables or free variables within a term
wenzelm@52407
  1167
  (\secref{sec:terms}).
wenzelm@52407
  1168
wenzelm@61493
  1169
  An \<^emph>\<open>axiom\<close> or \<^emph>\<open>oracle\<close> \<open>a : A[\<^vec>\<tau>]\<close> refers
wenzelm@61493
  1170
  some postulated \<open>proof constant\<close>, which is subject to
wenzelm@52407
  1171
  schematic polymorphism of theory content, and the particular type
wenzelm@61493
  1172
  instantiation may be given explicitly.  The vector of types \<open>\<^vec>\<tau>\<close> refers to the schematic type variables in the generic
wenzelm@61493
  1173
  proposition \<open>A\<close> in canonical order.
wenzelm@52407
  1174
wenzelm@61493
  1175
  A \<^emph>\<open>proof promise\<close> \<open>a : A[\<^vec>\<tau>]\<close> is a placeholder
wenzelm@61493
  1176
  for some proof of polymorphic proposition \<open>A\<close>, with explicit
wenzelm@61493
  1177
  type instantiation as given by the vector \<open>\<^vec>\<tau>\<close>, as
wenzelm@52407
  1178
  above.  Unlike axioms or oracles, proof promises may be
wenzelm@61493
  1179
  \<^emph>\<open>fulfilled\<close> eventually, by substituting \<open>a\<close> by some
wenzelm@61493
  1180
  particular proof \<open>q\<close> at the corresponding type instance.
wenzelm@61493
  1181
  This acts like Hindley-Milner \<open>let\<close>-polymorphism: a generic
wenzelm@52407
  1182
  local proof definition may get used at different type instances, and
wenzelm@52407
  1183
  is replaced by the concrete instance eventually.
wenzelm@52407
  1184
wenzelm@61477
  1185
  A \<^emph>\<open>named theorem\<close> wraps up some concrete proof as a closed
wenzelm@52407
  1186
  formal entity, in the manner of constant definitions for proof
wenzelm@61477
  1187
  terms.  The \<^emph>\<open>proof body\<close> of such boxed theorems involves some
wenzelm@52407
  1188
  digest about oracles and promises occurring in the original proof.
wenzelm@52407
  1189
  This allows the inference kernel to manage this critical information
wenzelm@52407
  1190
  without the full overhead of explicit proof terms.
wenzelm@58618
  1191
\<close>
wenzelm@52407
  1192
wenzelm@52411
  1193
wenzelm@58618
  1194
subsection \<open>Reconstructing and checking proof terms\<close>
wenzelm@52411
  1195
wenzelm@58618
  1196
text \<open>Fully explicit proof terms can be large, but most of this
wenzelm@52411
  1197
  information is redundant and can be reconstructed from the context.
wenzelm@52411
  1198
  Therefore, the Isabelle/Pure inference kernel records only
wenzelm@61477
  1199
  \<^emph>\<open>implicit\<close> proof terms, by omitting all typing information in
wenzelm@52411
  1200
  terms, all term and type labels of proof abstractions, and some
wenzelm@61493
  1201
  argument terms of applications \<open>p \<cdot> t\<close> (if possible).
wenzelm@52411
  1202
wenzelm@52411
  1203
  There are separate operations to reconstruct the full proof term
wenzelm@61477
  1204
  later on, using \<^emph>\<open>higher-order pattern unification\<close>
wenzelm@58555
  1205
  @{cite "nipkow-patterns" and "Berghofer-Nipkow:2000:TPHOL"}.
wenzelm@52411
  1206
wenzelm@61477
  1207
  The \<^emph>\<open>proof checker\<close> expects a fully reconstructed proof term,
wenzelm@52411
  1208
  and can turn it into a theorem by replaying its primitive inferences
wenzelm@58618
  1209
  within the kernel.\<close>
wenzelm@52411
  1210
wenzelm@52412
  1211
wenzelm@58618
  1212
subsection \<open>Concrete syntax of proof terms\<close>
wenzelm@52412
  1213
wenzelm@58618
  1214
text \<open>The concrete syntax of proof terms is a slight extension of
wenzelm@58555
  1215
  the regular inner syntax of Isabelle/Pure @{cite "isabelle-isar-ref"}.
wenzelm@52412
  1216
  Its main syntactic category @{syntax (inner) proof} is defined as
wenzelm@52412
  1217
  follows:
wenzelm@52412
  1218
wenzelm@52412
  1219
  \begin{center}
wenzelm@52412
  1220
  \begin{supertabular}{rclr}
wenzelm@52412
  1221
wenzelm@61493
  1222
  @{syntax_def (inner) proof} & = & @{verbatim Lam} \<open>params\<close> @{verbatim "."} \<open>proof\<close> \\
wenzelm@61493
  1223
    & \<open>|\<close> & \<open>\<^bold>\<lambda>\<close> \<open>params\<close> @{verbatim "."} \<open>proof\<close> \\
wenzelm@61493
  1224
    & \<open>|\<close> & \<open>proof\<close> @{verbatim "%"} \<open>any\<close> \\
wenzelm@61493
  1225
    & \<open>|\<close> & \<open>proof\<close> \<open>\<cdot>\<close> \<open>any\<close> \\
wenzelm@61493
  1226
    & \<open>|\<close> & \<open>proof\<close> @{verbatim "%%"} \<open>proof\<close> \\
wenzelm@61493
  1227
    & \<open>|\<close> & \<open>proof\<close> \<open>\<bullet>\<close> \<open>proof\<close> \\
wenzelm@61493
  1228
    & \<open>|\<close> & \<open>id  |  longid\<close> \\
wenzelm@52412
  1229
  \\
wenzelm@52412
  1230
wenzelm@61493
  1231
  \<open>param\<close> & = & \<open>idt\<close> \\
wenzelm@61493
  1232
    & \<open>|\<close> & \<open>idt\<close> @{verbatim ":"} \<open>prop\<close> \\
wenzelm@61493
  1233
    & \<open>|\<close> & @{verbatim "("} \<open>param\<close> @{verbatim ")"} \\
wenzelm@52412
  1234
  \\
wenzelm@52412
  1235
wenzelm@61493
  1236
  \<open>params\<close> & = & \<open>param\<close> \\
wenzelm@61493
  1237
    & \<open>|\<close> & \<open>param\<close> \<open>params\<close> \\
wenzelm@52412
  1238
wenzelm@52412
  1239
  \end{supertabular}
wenzelm@52412
  1240
  \end{center}
wenzelm@52412
  1241
wenzelm@61493
  1242
  Implicit term arguments in partial proofs are indicated by ``\<open>_\<close>''.  Type arguments for theorems and axioms may be specified
wenzelm@61493
  1243
  using \<open>p \<cdot> TYPE(type)\<close> (they must appear before any other
wenzelm@52412
  1244
  term argument of a theorem or axiom, but may be omitted altogether).
wenzelm@52412
  1245
wenzelm@61416
  1246
  \<^medskip>
wenzelm@61416
  1247
  There are separate read and print operations for proof
wenzelm@52412
  1248
  terms, in order to avoid conflicts with the regular term language.
wenzelm@58618
  1249
\<close>
wenzelm@52412
  1250
wenzelm@58618
  1251
text %mlref \<open>
wenzelm@52408
  1252
  \begin{mldecls}
wenzelm@52408
  1253
  @{index_ML_type proof} \\
wenzelm@52408
  1254
  @{index_ML_type proof_body} \\
wenzelm@52487
  1255
  @{index_ML proofs: "int Unsynchronized.ref"} \\
wenzelm@52411
  1256
  @{index_ML Reconstruct.reconstruct_proof:
wenzelm@52411
  1257
  "theory -> term -> proof -> proof"} \\
wenzelm@52411
  1258
  @{index_ML Reconstruct.expand_proof: "theory ->
wenzelm@52411
  1259
  (string * term option) list -> proof -> proof"} \\
wenzelm@52412
  1260
  @{index_ML Proof_Checker.thm_of_proof: "theory -> proof -> thm"} \\
wenzelm@52412
  1261
  @{index_ML Proof_Syntax.read_proof: "theory -> bool -> bool -> string -> proof"} \\
wenzelm@52412
  1262
  @{index_ML Proof_Syntax.pretty_proof: "Proof.context -> proof -> Pretty.T"} \\
wenzelm@52408
  1263
  \end{mldecls}
wenzelm@52408
  1264
wenzelm@61439
  1265
  \<^descr> Type @{ML_type proof} represents proof terms; this is a
wenzelm@52408
  1266
  datatype with constructors @{index_ML Abst}, @{index_ML AbsP},
wenzelm@52408
  1267
  @{index_ML_op "%"}, @{index_ML_op "%%"}, @{index_ML PBound},
wenzelm@52408
  1268
  @{index_ML MinProof}, @{index_ML Hyp}, @{index_ML PAxm}, @{index_ML
wenzelm@52408
  1269
  Oracle}, @{index_ML Promise}, @{index_ML PThm} as explained above.
wenzelm@52436
  1270
  %FIXME OfClass (!?)
wenzelm@52408
  1271
wenzelm@61439
  1272
  \<^descr> Type @{ML_type proof_body} represents the nested proof
wenzelm@52408
  1273
  information of a named theorem, consisting of a digest of oracles
wenzelm@52408
  1274
  and named theorem over some proof term.  The digest only covers the
wenzelm@52408
  1275
  directly visible part of the proof: in order to get the full
wenzelm@52408
  1276
  information, the implicit graph of nested theorems needs to be
wenzelm@52408
  1277
  traversed (e.g.\ using @{ML Proofterm.fold_body_thms}).
wenzelm@52408
  1278
wenzelm@61493
  1279
  \<^descr> @{ML Thm.proof_of}~\<open>thm\<close> and @{ML
wenzelm@61493
  1280
  Thm.proof_body_of}~\<open>thm\<close> produce the proof term or proof
wenzelm@52408
  1281
  body (with digest of oracles and theorems) from a given theorem.
wenzelm@52408
  1282
  Note that this involves a full join of internal futures that fulfill
wenzelm@52408
  1283
  pending proof promises, and thus disrupts the natural bottom-up
wenzelm@52408
  1284
  construction of proofs by introducing dynamic ad-hoc dependencies.
wenzelm@52408
  1285
  Parallel performance may suffer by inspecting proof terms at
wenzelm@52408
  1286
  run-time.
wenzelm@52408
  1287
wenzelm@61439
  1288
  \<^descr> @{ML proofs} specifies the detail of proof recording within
wenzelm@52487
  1289
  @{ML_type thm} values produced by the inference kernel: @{ML 0}
wenzelm@52487
  1290
  records only the names of oracles, @{ML 1} records oracle names and
wenzelm@52487
  1291
  propositions, @{ML 2} additionally records full proof terms.
wenzelm@52487
  1292
  Officially named theorems that contribute to a result are recorded
wenzelm@52487
  1293
  in any case.
wenzelm@52487
  1294
wenzelm@61493
  1295
  \<^descr> @{ML Reconstruct.reconstruct_proof}~\<open>thy prop prf\<close>
wenzelm@61493
  1296
  turns the implicit proof term \<open>prf\<close> into a full proof of the
wenzelm@52411
  1297
  given proposition.
wenzelm@52411
  1298
wenzelm@61493
  1299
  Reconstruction may fail if \<open>prf\<close> is not a proof of \<open>prop\<close>, or if it does not contain sufficient information for
wenzelm@52411
  1300
  reconstruction.  Failure may only happen for proofs that are
wenzelm@52411
  1301
  constructed manually, but not for those produced automatically by
wenzelm@52411
  1302
  the inference kernel.
wenzelm@52411
  1303
wenzelm@61493
  1304
  \<^descr> @{ML Reconstruct.expand_proof}~\<open>thy [thm\<^sub>1, \<dots>, thm\<^sub>n]
wenzelm@61493
  1305
  prf\<close> expands and reconstructs the proofs of all specified theorems,
wenzelm@52411
  1306
  with the given (full) proof.  Theorems that are not unique specified
wenzelm@52411
  1307
  via their name may be disambiguated by giving their proposition.
wenzelm@52411
  1308
wenzelm@61493
  1309
  \<^descr> @{ML Proof_Checker.thm_of_proof}~\<open>thy prf\<close> turns the
wenzelm@52411
  1310
  given (full) proof into a theorem, by replaying it using only
wenzelm@52411
  1311
  primitive rules of the inference kernel.
wenzelm@52411
  1312
wenzelm@61493
  1313
  \<^descr> @{ML Proof_Syntax.read_proof}~\<open>thy b\<^sub>1 b\<^sub>2 s\<close> reads in a
wenzelm@52412
  1314
  proof term. The Boolean flags indicate the use of sort and type
wenzelm@52412
  1315
  information.  Usually, typing information is left implicit and is
wenzelm@52412
  1316
  inferred during proof reconstruction.  %FIXME eliminate flags!?
wenzelm@52412
  1317
wenzelm@61493
  1318
  \<^descr> @{ML Proof_Syntax.pretty_proof}~\<open>ctxt prf\<close>
wenzelm@52412
  1319
  pretty-prints the given proof term.
wenzelm@58618
  1320
\<close>
wenzelm@52408
  1321
wenzelm@58618
  1322
text %mlex \<open>Detailed proof information of a theorem may be retrieved
wenzelm@58618
  1323
  as follows:\<close>
wenzelm@52410
  1324
wenzelm@52410
  1325
lemma ex: "A \<and> B \<longrightarrow> B \<and> A"
wenzelm@52410
  1326
proof
wenzelm@52410
  1327
  assume "A \<and> B"
wenzelm@52410
  1328
  then obtain B and A ..
wenzelm@52410
  1329
  then show "B \<and> A" ..
wenzelm@52410
  1330
qed
wenzelm@52410
  1331
wenzelm@58618
  1332
ML_val \<open>
wenzelm@52410
  1333
  (*proof body with digest*)
wenzelm@52410
  1334
  val body = Proofterm.strip_thm (Thm.proof_body_of @{thm ex});
wenzelm@52410
  1335
wenzelm@52410
  1336
  (*proof term only*)
wenzelm@52410
  1337
  val prf = Proofterm.proof_of body;
wenzelm@52410
  1338
  Pretty.writeln (Proof_Syntax.pretty_proof @{context} prf);
wenzelm@52410
  1339
wenzelm@52410
  1340
  (*all theorems used in the graph of nested proofs*)
wenzelm@52410
  1341
  val all_thms =
wenzelm@52410
  1342
    Proofterm.fold_body_thms
wenzelm@52410
  1343
      (fn (name, _, _) => insert (op =) name) [body] [];
wenzelm@58618
  1344
\<close>
wenzelm@52410
  1345
wenzelm@58618
  1346
text \<open>The result refers to various basic facts of Isabelle/HOL:
wenzelm@52410
  1347
  @{thm [source] HOL.impI}, @{thm [source] HOL.conjE}, @{thm [source]
wenzelm@52410
  1348
  HOL.conjI} etc.  The combinator @{ML Proofterm.fold_body_thms}
wenzelm@52410
  1349
  recursively explores the graph of the proofs of all theorems being
wenzelm@52410
  1350
  used here.
wenzelm@52410
  1351
wenzelm@61416
  1352
  \<^medskip>
wenzelm@61416
  1353
  Alternatively, we may produce a proof term manually, and
wenzelm@58618
  1354
  turn it into a theorem as follows:\<close>
wenzelm@52410
  1355
wenzelm@58618
  1356
ML_val \<open>
wenzelm@52410
  1357
  val thy = @{theory};
wenzelm@52410
  1358
  val prf =
wenzelm@52410
  1359
    Proof_Syntax.read_proof thy true false
wenzelm@52410
  1360
      "impI \<cdot> _ \<cdot> _ \<bullet> \
wenzelm@52486
  1361
      \   (\<^bold>\<lambda>H: _. \
wenzelm@52410
  1362
      \     conjE \<cdot> _ \<cdot> _ \<cdot> _ \<bullet> H \<bullet> \
wenzelm@52486
  1363
      \       (\<^bold>\<lambda>(H: _) Ha: _. conjI \<cdot> _ \<cdot> _ \<bullet> Ha \<bullet> H))";
wenzelm@52410
  1364
  val thm =
wenzelm@52410
  1365
    prf
wenzelm@52410
  1366
    |> Reconstruct.reconstruct_proof thy @{prop "A \<and> B \<longrightarrow> B \<and> A"}
wenzelm@52410
  1367
    |> Proof_Checker.thm_of_proof thy
wenzelm@52410
  1368
    |> Drule.export_without_context;
wenzelm@58618
  1369
\<close>
wenzelm@52410
  1370
wenzelm@61416
  1371
text \<open>
wenzelm@61416
  1372
  \<^medskip>
wenzelm@61416
  1373
  See also @{file "~~/src/HOL/Proofs/ex/XML_Data.thy"}
wenzelm@52630
  1374
  for further examples, with export and import of proof terms via
wenzelm@52630
  1375
  XML/ML data representation.
wenzelm@58618
  1376
\<close>
wenzelm@52410
  1377
wenzelm@18537
  1378
end