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