Quelle  Logic.thy

(*:maxLineLen=78:*)

theory Logic
imports Base
begin

chapter ‹Primitive logic \label{ch:logic}›

text ‹
  The logical foundations of Isabelle/Isar are that of the Pure logic, which
  has been introduced as a Natural Deduction framework in 🍋‹paulson700›.
  This is essentially the same logic as ``‹λHOL›'' in the more abstract
  setting of Pure Type Systems (PTS) 🍋‹"Barendregt-Geuvers:2001"›,
  although there are some key differences in the specific treatment of simple
  types in Isabelle/Pure.

  Following type-theoretic parlance, the Pure logic consists of three levels
  of ‹λ›-calculus with corresponding arrows, ‹==>› for syntactic function space
  (terms depending on terms), ‹∧› for universal quantification (proofs
  depending on terms), and ‹==>› for implication (proofs depending on proofs).

  Derivations are relative to a logical theory, which declares type
  constructors, constants, and axioms. Theory declarations support schematic
  polymorphism, which is strictly speaking outside the logic.🪙‹This is the
  deeper logical reason, why the theory context ‹Θ› is separate from the proof
  context ‹Γ› of the core calculus: type constructors, term constants, and
  facts (proof constants) may involve arbitrary type schemes, but the type of
  a locally fixed term parameter is also fixed!›
›


section ‹Types \label{sec:types}›

text ‹
  The language of types is an uninterpreted order-sorted first-order algebra;
  types are qualified by ordered type classes.
 
  🪙
  A 🪙‹type class› i
  context. The 🪙‹subclass relation› ‹c🪙1 ⊆ c🪙2› is specified by stating an
  acyclic generating relation; the transitive closure is maintained
  internally. The resulting relation is an ordering: reflexive, transitive,
  and antisymmetric.

  A 🪙‹sort› is a list of type classes written as ‹s = {c🪙1, …, c🪙m}›, it
  represents symbolic intersection. Notationally, the curly braces are omitted
  for singleton intersections, i.e.\ any class ‹c› may be read as a sort
  ‹{c}›. The ordering on type classes is extended to sorts according to the
  meaning of intersections: ‹{c🪙1, … c🪙m} ⊆ {d🪙1, …, d🪙n}› iff ‹∀j. ∃i. c🪙i ⊆
  d🪙j›.
  largest element wrt.\ the sort order. Thus ‹{}› represents the ``full
  sort'', not the empty one! The intersection of all (finitely many) classes
  declared in the current theory is the least element wrt.\ the sort ordering.

  🪙
  A 🪙‹fixed type variable› is a pair of a basic name (starting with a ‹'›
  character) and a sort constraint, e.g.\ ‹('a, s)› which is usually printed
  as ‹α🪙s›. A 🪙‹schematic type variable› is a pair of an indexname and a sort
  constraint, e.g.\ ‹(('a, 0), s)› which is usually printed as ‹?α🪙s›.

  Note that 🪙‹all› syntactic components contribute to the identity of type
  variables: basic name, index, and sort constraint. The core logic handles
  type variables with the same name but different sorts as different, although
  the type-inference layer (which is outside the core) rejects anything like
  that.

  A 🪙‹type constructor› ‹κ› is a ‹k›-ary operator on types declared in the
  theory. Type constructor application is written postfix as ‹(α🪙1, …, α🪙k)κ›.
  For ‹k = 0› the argument tuple is omitted, e.g.\ ‹prop› instead of ‹()prop›.
  For ‹k = 1› the parentheses are omitted, e.g.\ ‹α list› instead of
  ‹(α)list›. Further notation is provided for specific constructors, notably
  the right-associative infix ‹α ==> β› instead of ‹(α, β)fun›.

  The logical category 🪙‹type› is defined inductively over type variables and
  type constructors as follows: ‹τ = α🪙s | ?α🪙s | (τ🪙1, …, τ🪙k)κ›.

  A 🪙‹type abbreviation› is a syntactic definition ‹(🪙α)κ = τ› of an
  arbitrary type expression ‹τ› over variables ‹🪙α›. Type abbreviations
  appear as type constructors in the syntax, but are expanded before entering
  the logical core.

  A 🪙‹type arity› declares the image behavior of a type constructor wrt.\ the
  algebra of sorts: ‹κ :: (s🪙1, …, s🪙k)s› means that ‹(τ🪙1, …, τ🪙k)κ› is of
  sort ‹s› if every argument type ‹τ🪙i› is of sort ‹s🪙i›. Arity declarations
  are implicitly completed, i.e.\ ‹κ :: (🪙s)c› entails ‹κ ::
  (🪙s)c'›

  🪙
  The sort algebra is always maintained as 🪙‹coregular›, which means that type
  arities are consistent with the subclass relation: for any type constructor
  ‹κ›, and classes ‹c🪙1 ⊆ c🪙2›, and arities ‹κ :: (🪙s🪙1)c🪙1› and ‹κ ::
  (🪙s🪙2)c🪙2›

  The key property of a coregular order-sorted algebra is that sort
  constraints can be solved in a most general fashion: for each type
  constructor ‹κ› and sort ‹s› there is a most general vector of argument
  sorts ‹(s🪙1, …, s🪙k)› such that a type scheme ‹(α🪙s🪙1🪙, …, α🪙s🪙k🪙)κ› is of
  sort ‹s›. Consequently, type unification has most general solutions (modulo
  equivalence of sorts), so type-inference produces primary types as expected
  🍋‹"nipkow-prehofer"›.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML_type class = string} \\
  @{define_ML_type sort = "class list"} \\
  @{define_ML_type arity = "string * sort list * sort"} \\
  @{define_ML_type typ} \\
  @{define_ML Term.map_atyps: "(typ -> typ) -> typ -> typ"} \\
  @{define_ML Term.fold_atyps: "(typ -> 'a -> 'a) -> typ -> 'a -> 'a"} \\
  \end{mldecls}
  \begin{mldecls}
  @{define_ML Sign.subsort: "theory -> sort * sort -> bool"} \\
  @{define_ML Sign.of_sort: "theory -> typ * sort -> bool"} \\
  @{define_ML Sign.add_type: "Proof.context -> binding * int * mixfix -> theory -> theory"} \\
  @{define_ML Sign.add_type_abbrev: "Proof.context ->
  binding * string list * typ -> theory -> theory"} \\
  @{define_ML Sign.primitive_class: "binding * class list -> theory -> theory"} \\
  @{define_ML Sign.primitive_classrel: "class * class -> theory -> theory"} \\
  @{define_ML Sign.primitive_arity: "arity -> theory -> theory"} \\
  \end{mldecls}
 
  🪙 Type 🪙‹class› r

  🪙 Type 🪙‹sort› represents sorts, i.e.\ finite intersections of
  classes. The empty list 🪙‹[]: sort› refers to the empty class
  intersection, i.e.\ the ``full sort''.

  🪙 Type 🪙‹arity› represents type arities. A triple ‹(κ, 🪙s, s)
  : arity›

  🪙 Type 🪙‹typ› represents types; this is a datatype with constructors
  🪙‹TFree›, 🪙‹TVar›, 🪙‹Type›.

  🪙 🪙‹Term.map_atyps›~‹f τ› applies the mapping ‹f› to all atomic types
  (🪙‹TFree›, 🪙‹TVar›) occurring in ‹τ›.

  🪙 🪙‹Term.fold_atyps›~‹f τ› iterates the operation ‹f› over all
  occurrences of atomic types (🪙‹TFree›, 🪙‹TVar›) in ‹τ›; the type
  structure is traversed from left to right.

  🪙 🪙‹Sign.subsort›~‹thy (s🪙1, s🪙2)› tests the subsort relation ‹s🪙1 ⊆
  s🪙2›.

  🪙 🪙‹Sign.of_sort›~‹thy (τ, s)› tests whether type ‹τ› is of sort ‹s›.

  🪙 🪙‹Sign.add_type›~‹ctxt (κ, k, mx)› declares a new type constructors ‹κ›
  with ‹k› arguments and optional mixfix syntax.

  🪙 🪙‹Sign.add_type_abbrev›~‹ctxt (κ, 🪙α, τ)› defines a new type
  abbreviation ‹(🪙α)κ = τ›.

  🪙 🪙‹Sign.primitive_class›~‹(c, [c🪙1, …, c🪙n])› declares a new class ‹c›,
  together with class relations ‹c ⊆ c🪙i›, for ‹i = 1, …, n›.

  🪙 🪙‹Sign.primitive_classrel›~‹(c🪙1, c🪙2)› declares the class relation
  ‹c🪙1 ⊆ c🪙2›.

  🪙 🪙‹Sign.primitive_arity›~‹(κ, 🪙s, s)› declares the arity ‹κ ::
  (🪙s)s›.
›

text %mlantiq ‹
  \begin{matharray}{rcl}
  @{ML_antiquotation_def "class"} & : & ‹ML_antiquotation› \
  @{ML_antiquotation_def "sort"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "type_name"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "type_abbrev"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "nonterminal"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "typ"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "Type"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "Type_fn"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  \end{matharray}

  🪙‹
  @@{ML_antiquotation class} embedded
  ;
  @@{ML_antiquotation sort} sort
  ;
  (@@{ML_antiquotation type_name} |
  @@{ML_antiquotation type_abbrev} |
  @@{ML_antiquotation nonterminal}) embedded
  ;
  @@{ML_antiquotation typ} type
  ;
  (@@{ML_antiquotation Type} | @@{ML_antiquotation Type_fn}) embedded
  ›

  🪙 ‹@{class c}› inlines the internalized class ‹c› --- as 🪙‹string›
  literal.

  🪙 ‹@{sort s}› inlines the internalized sort ‹s› --- as 🪙‹string
  list›

  🪙 ‹@{type_name c}› inlines the internalized type constructor ‹c› --- as
  🪙‹string› literal.

  🪙 ‹@{type_abbrev c}› inlines the internalized type abbreviation ‹c› --- as
  🪙‹string› literal.

  🪙 ‹@{nonterminal c}› inlines the internalized syntactic type~/ grammar
  nonterminal ‹c› --- as 🪙‹string› literal.

  🪙 ‹@{typ τ}› inlines the internalized type ‹τ› --- as constructor term for
  datatype 🪙‹typ›.

  🪙 ‹@{Type source}› refers to embedded source text to produce a type
  constructor with name (formally checked) and arguments (inlined ML text).
  The embedded ‹source› follows the syntax category @{syntax type_const}
  defined below.

  🪙 ‹@{Type_fn source}› is similar to ‹@{Type source}›, but produces a partial
  ML function that matches against a type constructor pattern, following
  syntax category @{syntax type_const_fn} below.


  🪙‹
    @{syntax_def type_const}: @{syntax name} (@{syntax embedded_ml}*)
    ;
    @{syntax_def type_const_fn}: @{syntax type_const} @'=>' @{syntax embedded_ml}
    ;
    @{syntax_def embedded_ml}:
      @'_' | @{syntax embedded} | @{syntax control_symbol} @{syntax embedded}
  ›

  The text provided as @{syntax embedded_ml} is treated as regular Isabelle/ML
  source, possibly with nested antiquotations. ML text that only consists of a
  single antiquotation in compact control-cartouche notation, can be written
  without an extra level of nesting embedded text (see the last example
  below).
›

text %mlex ‹
  Here are some minimal examples for type constructor antiquotations.
 ›

ML ‹
  🍋 ‹type constructor without arguments:›
  val natT = 🍋‹nat›;

  🍋 ‹type constructor with arguments:›
  fun mk_funT (A, B) = 🍋‹fun A B›;

  🍋 ‹type constructor decomposition as partial function:›
  val dest_funT = 🍋‹fun A B => ‹(A, B)›\
  🍋 ‹nested type constructors:›
  fun mk_relT A = 🍋‹fun A 🍋‹fun A 🍋‹bool›\›\›;

  🍋 (mk_relT natT = 🍋‹nat ==> nat ==> bool›);
›


section ‹Terms \label{sec:terms}›

text ‹
  The language of terms is that of simply-typed ‹λ›-c
  indices for bound variables (cf.\ 🍋‹debruijn72› or 🍋‹"paulson-ml2"›), with the types being determined by the corresponding
  binders. In contrast, free variables and constants have an explicit name and
  type in each occurrence.

  🪙
  A 🪙‹bound variable› is a natural number ‹b›, which accounts for the number
  of intermediate binders between the variable occurrence in the body and its
  binding position. For example, the de-Bruijn term ‹λ🪙bool🪙. λ🪙bool🪙. 1 ∧ 0›
  would correspond to ‹λx🪙bool🪙. λy🪙bool🪙. x ∧ y› in a named representation.
  Note that a bound variable may be represented by different de-Bruijn indices
  at different occurrences, depending on the nesting of abstractions.

  A 🪙‹loose variable› is a bound variable that is outside the scope of local
  binders. The types (and names) for loose variables can be managed as a
  separate context, that is maintained as a stack of hypothetical binders. The
  core logic operates on closed terms, without any loose variables.

  A 🪙‹fixed variable› is a pair of a basic name and a type, e.g.\ ‹(x, τ)›
  which is usually printed ‹x🪙τ› here. A 🪙‹schematic variable› is a pair of an
  indexname and a type, e.g.\ ‹((x, 0), τ)› which is likewise printed as
  ‹?x🪙τ›.

  🪙
  A 🪙‹constant› is a pair of a basic name and a type, e.g.\ ‹(c, τ)› which is
  usually printed as ‹c🪙τ› here. Constants are declared in the context as
  polymorphic families ‹c :: σ›, meaning that all substitution instances ‹c🪙τ›
  for ‹τ = σ🪙› are valid.

  The vector of 🪙‹type arguments› of constant ‹c🪙τ› wrt.\ the declaration ‹c
  :: σ›
  …, ?α🪙n ↦ τ🪙n}› presented in canonical order ‹(τ🪙1, …, τ🪙n)›, corresponding
  to the left-to-right occurrences of the ‹α🪙i› in ‹σ›. Within a given theory
  context, there is a one-to-one correspondence between any constant ‹c🪙τ› and
  the application ‹c(τ🪙1, …, τ🪙n)› of its type arguments. For example, with
  ‹plus :: α ==> α ==> α›, the instance ‹plus🪙nat ==> nat ==> nat🪙› corresponds to
  ‹plus(nat)›.

  Constant declarations ‹c :: σ› may contain sort constraints for type
  variables in ‹σ›. These are observed by type-inference as expected, but
  🪙‹ignored› by the core logic. This means the primitive logic is able to
  reason with instances of polymorphic constants that the user-level
  type-checker would reject due to violation of type class restrictions.

  🪙
  An 🪙‹atomic term› is either a variable or constant. The logical category
  🪙‹term› is defined inductively over atomic terms, with abstraction and
  application as follows: ‹t = b | x🪙τ | ?x🪙τ | c🪙τ | λ🪙τ. t | t🪙1 t🪙2›.
  Parsing and printing takes care of converting between an external
  representation with named bound variables. Subsequently, we shall use the
  latter notation instead of internal de-Bruijn representation.

  The inductive relation ‹t :: τ› assigns a (unique) type to a term according
  to the structure of atomic terms, abstractions, and applications:
  \[
  \infer{‹a🪙τ :: τ›}{}
  \qquad
  \infer{‹(λx🪙τ. t) :: τ ==> σ›}{‹t :: σ›}
  \qquad
  \infer{‹t u :: σ›}{‹t :: τ ==> σ› & ‹u :: τ›}
  \]
  A 🪙‹well-typed term› is a term that can be typed according to these rules.

  Typing information can be omitted: type-inference is able to reconstruct the
  most general type of a raw term, while assigning most general types to all
  of its variables and constants. Type-inference depends on a context of type
  constraints for fixed variables, and declarations for polymorphic constants.

  The identity of atomic terms consists both of the name and the type
  component. This means that different variables ‹x🪙τ🪙1🪙› and ‹x🪙τ🪙2🪙› may
  become the same after type instantiation. Type-inference rejects variables
  of the same name, but different types. In contrast, mixed instances of
  polymorphic constants occur routinely.

  🪙
  The 🪙‹hidden polymorphism› of a term ‹t :: σ› is the set of type variables
  occurring in ‹t›, but not in its type ‹σ›. This means that the term
  implicitly depends on type arguments that are not accounted in the result
  type, i.e.\ there are different type instances ‹t🪙 :: σ› and
  ‹t🪙' :: σ› with the same type. This slightly pathological
  situation notoriously demands additional care.

  🪙
  A 🪙‹term abbreviation› is a syntactic definition ‹c🪙σ ≡ t› of a closed term
  ‹t› of type ‹σ›, without any hidden polymorphism. A term abbreviation looks
  like a constant in the syntax, but is expanded before entering the logical
  core. Abbreviations are usually reverted when printing terms, using ‹t →
  c🪙σ›

  🪙
  Canonical operations on ‹λ›-terms include ‹αβ🪙›-conversion: ‹α›-conversion
  refers to capture-free renaming of bound variables; ‹β›-conversion contracts
  an abstraction applied to an argument term, substituting the argument in the
  body: ‹(λx. b)a› becomes ‹b[a/x]›; ‹🪙›-conversion contracts vacuous
  application-abstraction: ‹λx. f x› becomes ‹f›, provided that the bound
  variable does not occur in ‹f›.

  Terms are normally treated modulo ‹α›-conversion, which is implicit in the
  de-Bruijn representation. Names for bound variables in abstractions are
  maintained separately as (meaningless) comments, mostly for parsing and
  printing. Full ‹αβ🪙›-conversion is commonplace in various standard
  operations (\secref{sec:obj-rules}) that are based on higher-order
  unification and matching.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML_type term} \\
  @{define_ML_infix "aconv": "term * term -> bool"} \\
  @{define_ML Term.map_types: "(typ -> typ) -> term -> term"} \\
  @{define_ML Term.fold_types: "(typ -> 'a -> 'a) -> term -> 'a -> 'a"} \\
  @{define_ML Term.map_aterms: "(term -> term) -> term -> term"} \\
  @{define_ML Term.fold_aterms: "(term -> 'a -> 'a) -> term -> 'a -> 'a"} \\
  \end{mldecls}
  \begin{mldecls}
  @{define_ML fastype_of: "term -> typ"} \\
  @{define_ML lambda: "term -> term -> term"} \\
  @{define_ML betapply: "term * term -> term"} \\
  @{define_ML incr_boundvars: "int -> term -> term"} \\
  @{define_ML Sign.declare_const: "Proof.context ->
  (binding * typ) * mixfix -> theory -> term * theory"} \\
  @{define_ML Sign.add_abbrev: "string -> binding * term ->
  theory -> (term * term) * theory"} \\
  @{define_ML Sign.const_typargs: "theory -> string * typ -> typ list"} \\
  @{define_ML Sign.const_instance: "theory -> string * typ list -> typ"} \\
  \end{mldecls}
 
  🪙 Type 🪙‹term› r
  abstractions, and explicitly named free variables and constants; this is a
  datatype with constructors @{define_ML Bound}, @{define_ML Free}, @{define_ML
  Var}, @{define_ML Const}, @{define_ML Abs}, @{define_ML_infix "$"}.

  🪙 ‹t›~🪙‹aconv›~‹u› checks ‹α›-equivalence of two terms. This is the
  basic equality relation on type 🪙‹term›; raw datatype equality
  should only be used for operations related to parsing or printing!

  🪙 🪙‹Term.map_types›~‹f t› applies the mapping ‹f› to all types occurring
  in ‹t›.

  🪙 🪙‹Term.fold_types›~‹f t› iterates the operation ‹f› over all
  occurrences of types in ‹t›; the term structure is traversed from left to
  right.

  🪙 🪙‹Term.map_aterms›~‹f t› applies the mapping ‹f› to all atomic terms
  (🪙‹Bound›, 🪙‹Free›, 🪙‹Var›, 🪙‹Const›) occurring in ‹t›.

  🪙 🪙‹Term.fold_aterms›~‹f t› iterates the operation ‹f› over all
  occurrences of atomic terms (🪙‹Bound›, 🪙‹Free›, 🪙‹Var›, 🪙‹Const›) in ‹t›; the term structure is traversed from left to right.

  🪙 🪙‹fastype_of›~‹t› determines the type of a well-typed term. This
  operation is relatively slow, despite the omission of any sanity checks.

  🪙 🪙‹lambda›~‹a b› produces an abstraction ‹λa. b›, where occurrences of
  the atomic term ‹a› in the body ‹b› are replaced by bound variables.

  🪙 🪙‹betapply›~‹(t, u)› produces an application ‹t u›, with topmost
  ‹β›-conversion if ‹t› is an abstraction.

  🪙 🪙‹incr_boundvars›~‹j› increments a term's dangling bound variables by
  the offset ‹j›. This is required when moving a subterm into a context where
  it is enclosed by a different number of abstractions. Bound variables with a
  matching abstraction are unaffected.

  🪙 🪙‹Sign.declare_const›~‹ctxt ((c, σ), mx)› declares a new constant ‹c ::
  σ›

  🪙 🪙‹Sign.add_abbrev›~‹print_mode (c, t)› introduces a new term
  abbreviation ‹c ≡ t›.

  🪙 🪙‹Sign.const_typargs›~‹thy (c, τ)› and 🪙‹Sign.const_instance›~‹thy
  (c, [τ🪙1, …, τ🪙n])›
  constants: full type instance vs.\ compact type arguments form.
›

text %mlantiq ‹
  \begin{matharray}{rcl}
  @{ML_antiquotation_def "const_name"} & : & ‹ML_antiquotation› \
  @{ML_antiquotation_def "const_abbrev"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "const"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "term"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "prop"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "Const"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "Const_"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "Const_fn"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  \end{matharray}

  🪙‹
  (@@{ML_antiquotation const_name} |
  @@{ML_antiquotation const_abbrev}) embedded
  ;
  @@{ML_antiquotation const} ('(' (type + ',') ')')?
  ;
  @@{ML_antiquotation term} term
  ;
  @@{ML_antiquotation prop} prop
  ;
  (@@{ML_antiquotation Const} | @@{ML_antiquotation Const_} | @@{ML_antiquotation Const_fn})
  embedded
  ›

  🪙 ‹@{const_name c}› inlines the internalized logical constant name ‹c› ---
  as 🪙‹string› literal.

  🪙 ‹@{const_abbrev c}› inlines the internalized abbreviated constant name ‹c›
  --- as 🪙‹string› literal.

  🪙 ‹@{const c(🪙τ)}› inlines the internalized constant ‹c› with precise
  type instantiation in the sense of 🪙‹Sign.const_instance› --- as 🪙‹Const› constructor term for datatype 🪙‹term›.

  🪙 ‹@{term t}› inlines the internalized term ‹t› --- as constructor term for
  datatype 🪙‹term›.

  🪙 ‹@{prop φ}› inlines the internalized proposition ‹φ› --- as constructor
  term for datatype 🪙‹term›.

  🪙 ‹@{Const source}› refers to embedded source text to produce a term
  constructor with name (formally checked), type arguments and term arguments
  (inlined ML text). The embedded ‹source› follows the syntax category
  @{syntax term_const} defined below, using @{syntax embedded_ml} from
  antiquotation @{ML_antiquotation Type} (\secref{sec:types}).

  🪙 ‹@{Const_ source}› is similar to ‹@{Const source}› for patterns instead of
  closed values. This distinction is required due to redundant type
  information within term constants: subtrees with duplicate ML pattern
  variable need to be suppressed (replaced by dummy patterns). The embedded ‹source› follows
  the syntax category @{syntax term_const} defined below.

  🪙 ‹@{Const_fn source}› is similar to ‹@{Const_ source}›, but produces a
  proper 🍋‹fn› expression with function body. The embedded ‹source› follows
  the syntax category @{syntax term_const_fn} defined below.


  🪙‹
  @{syntax_def term_const}:
      @{syntax name} (@{syntax embedded_ml}*)
    ;
    @{syntax_def term_const_fn}:
      @{syntax term_const} @'=>' @{syntax embedded_ml}
    ;
    @{syntax_def for_args}: @'for' (@{syntax embedded_ml}+)
  ›
›

text %mlex ‹
  Here are some minimal examples for term constant antiquotations. Type
  arguments for constants are analogous to type constructors
  (\secref{sec:types}). Term arguments are different: a flexible number of
  arguments is inserted via curried applications (🪙‹op $›).
›

ML ‹
  🍋 ‹constant without type argument:›
  fun mk_conj (A, B) = 🍋‹conj for A B›;
  val dest_conj = 🍋‹conj for A B => ‹(A, B)›\
  🍋 ‹constant with type argument:›
  fun mk_eq T (t, u) = 🍋‹HOL.eq T for t u›;
  val dest_eq = 🍋‹HOL.eq T for t u => ‹(T, (t, u))›\›;

  🍋 ‹constant with variable number of term arguments:›
  val c = Const (🍋‹conj›, 🍋‹bool ==> bool ==> bool›);
  val P = 🍋‹P::bool›;
  val Q = 🍋‹Q::bool›;
  🍋 (🍋‹conj› = c);
  🍋 (🍋‹conj for P› = c $ P);
  🍋 (🍋‹conj for P Q› = c $ P $ Q);
›


section ‹Theorems \label{sec:thms}›

text ‹
  A 🪙‹proposition› i
  proven proposition (depending on a context of hypotheses and the background
  theory). Primitive inferences include plain Natural Deduction rules for the
  primary connectives ‹∧› and ‹==>› of the framework. There is also a builtin
  notion of equality/equivalence ‹≡›.
›


subsection ‹Primitive connectives and rules \label{sec:prim-rules}›

text ‹
  The theory ‹Pure› c
  connectives ‹∧›, ‹==>›, and ‹≡› of the logical framework, see
  \figref{fig:pure-connectives}. The derivability judgment ‹A🪙1, …, A🪙n ⊨ B›
  is defined inductively by the primitive inferences given in
  \figref{fig:prim-rules}, with the global restriction that the hypotheses
  must 🪙‹not› contain any schematic variables. The builtin equality is
  conceptually axiomatized as shown in \figref{fig:pure-equality}, although
  the implementation works directly with derived inferences.

  \begin{figure}[htb]
  \begin{center}
  \begin{tabular}{ll}
  ‹all :: (α ==> prop) ==> prop› & universal quantification (binder ‹∧›) java.lang.NullPointerException
  ‹==> :: prop ==> prop ==> prop› & implication (right associative infix) java.lang.NullPointerException
  ‹≡ :: α ==> α ==> prop› & equality relation (infix) java.lang.NullPointerException
  \end{tabular}
  \caption{Primitive connectives of Pure}\label{fig:pure-connectives}
  \end{center}
  \end{figure}

  \begin{figure}[htb]
  \begin{center}
  \[
  \infer[‹(axiom)›]{‹⊨ A›}{‹A ∈ Θ›}
  \qquad
  \infer[‹(assume)›]{‹A ⊨ A›}{}
  \]
  \[
  \infer[‹(∧🍋intro)›]{‹Γ ⊨ ∧x. B[x]›}{‹Γ ⊨ B[x]› & ‹x ∉ Γ›}
  \qquad
  \infer[‹(∧🍋elim)›]{‹Γ ⊨ B[a]›}{‹Γ ⊨ ∧x. B[x]›}
  \]
  \[
  \infer[‹(==>🍋intro)›]{‹Γ - A ⊨ A ==> B›}{‹Γ ⊨ B›}
  \qquad
  \infer[‹(==>🍋elim)›]{‹Γ🪙1 ∪ Γ🪙2 ⊨ B›}{‹Γ🪙1 ⊨ A ==> B› & ‹Γ🪙2 ⊨ A›}
  \]
  \caption{Primitive inferences of Pure}\label{fig:prim-rules}
  \end{center}
  \end{figure}

  \begin{figure}[htb]
  \begin{center}
  \begin{tabular}{ll}
  ‹⊨ (λx. b[x]) a ≡ b[a]› & ‹β›-conversion java.lang.NullPointerException
  ‹⊨ x ≡ x› & reflexivity java.lang.NullPointerException
  ‹⊨ x ≡ y ==> P x ==> P y› & substitution java.lang.NullPointerException
  ‹⊨ (∧x. f x ≡ g x) ==> f ≡ g› & extensionality java.lang.NullPointerException
  ‹⊨ (A ==> B) ==> (B ==> A) ==> A ≡ B› & logical equivalence java.lang.NullPointerException
  \end{tabular}
  \caption{Conceptual axiomatization of Pure equality}\label{fig:pure-equality}
  \end{center}
  \end{figure}

  The introduction and elimination rules for ‹∧› and ‹==>› are analogous to
  formation of dependently typed ‹λ›-terms representing the underlying proof
  objects. Proof terms are irrelevant in the Pure logic, though; they cannot
  occur within propositions. The system provides a runtime option to record
  explicit proof terms for primitive inferences, see also
  \secref{sec:proof-terms}. Thus all three levels of ‹λ›-calculus become
  explicit: ‹==>› for terms, and ‹∧/==>› for proofs (cf.\ 🍋‹"Berghofer-Nipkow:2000:TPHOL"›).

  Observe that locally fixed parameters (as in ‹∧🍋intro›) need not be recorded
  in the hypotheses, because the simple syntactic types of Pure are always
  inhabitable. ``Assumptions'' ‹x :: τ› for type-membership are only present
  as long as some ‹x🪙τ› occurs in the statement body.🪙‹This is the key
  difference to ``‹λHOL›'' in the PTS framework 🍋‹"Barendregt-Geuvers:2001"›, where hypotheses ‹x : A› are treated uniformly
  for propositions and types.›

  🪙
  The axiomatization of a theory is implicitly closed by forming all instances
  of type and term variables: ‹⊨ A🪙› holds for any substitution
  instance of an axiom ‹⊨ A›. By pushing substitutions through derivations
  inductively, we also get admissible ‹generalize› and ‹instantiate› rules as
  shown in \figref{fig:subst-rules}.

  \begin{figure}[htb]
  \begin{center}
  \[
  \infer{‹Γ ⊨ B[?α]›}{‹Γ ⊨ B[α]› & ‹α ∉ Γ›}
  \quad
  \infer[\quad‹(generalize)›]{‹Γ ⊨ B[?x]›}{‹Γ ⊨ B[x]› & ‹x ∉ Γ›}
  \]
  \[
  \infer{‹Γ ⊨ B[τ]›}{‹Γ ⊨ B[?α]›}
  \quad
  \infer[\quad‹(instantiate)›]{‹Γ ⊨ B[t]›}{‹Γ ⊨ B[?x]›}
  \]
  \caption{Admissible substitution rules}\label{fig:subst-rules}
  \end{center}
  \end{figure}

  Note that ‹instantiate› does not require an explicit side-condition, because
  ‹Γ› may never contain schematic variables.

  In principle, variables could be substituted in hypotheses as well, but this
  would disrupt the monotonicity of reasoning: deriving ‹Γ🪙 ⊨
  B🪙›
  necessarily hold: the result belongs to a different proof context.

  🪙 An 🪙‹oracle› is a function that produces axioms on the fly. Logically,
  this is an instance of the ‹axiom› rule (\figref{fig:prim-rules}), but there
  is an operational difference. The inference kernel records oracle
  invocations within derivations of theorems by a unique tag. This also
  includes implicit type-class reasoning via the order-sorted algebra of class
  relations and type arities (see also @{command_ref instantiation} and
  @{command_ref instance}).

  Axiomatizations should be limited to the bare minimum, typically as part of
  the initial logical basis of an object-logic formalization. Later on,
  theories are usually developed in a strictly definitional fashion, by
  stating only certain equalities over new constants.

  A 🪙‹simple definition› consists of a constant declaration ‹c :: σ› together
  with an axiom ‹⊨ c ≡ t›, where ‹t :: σ› is a closed term without any hidden
  polymorphism. The RHS may depend on further defined constants, but not ‹c›
  itself. Definitions of functions may be presented as ‹c 🪙x ≡ t›
  instead of the puristic ‹c ≡ λ🪙x. t›.

  An 🪙‹overloaded definition› consists of a collection of axioms for the same
  constant, with zero or one equations ‹c((🪙α)κ) ≡ t› for each type
  constructor ‹κ› (for distinct variables ‹🪙α›). The RHS may mention
  previously defined constants as above, or arbitrary constants ‹d(α🪙i)› for
  some ‹α🪙i› projected from ‹🪙α›. Thus overloaded definitions
  essentially work by primitive recursion over the syntactic structure of a
  single type argument. See also 🍋‹‹\S4.3› in
  "Haftmann-Wenzel:2006:classes"›.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Logic.all: "term -> term -> term"} \\
  @{define_ML Logic.mk_implies: "term * term -> term"} \\
  \end{mldecls}
  \begin{mldecls}
  @{define_ML_type ctyp} \\
  @{define_ML_type cterm} \\
  @{define_ML Thm.ctyp_of: "Proof.context -> typ -> ctyp"} \\
  @{define_ML Thm.cterm_of: "Proof.context -> term -> cterm"} \\
  @{define_ML Thm.apply: "cterm -> cterm -> cterm"} \\
  @{define_ML Thm.lambda: "cterm -> cterm -> cterm"} \\
  @{define_ML Thm.all: "Proof.context -> cterm -> cterm -> cterm"} \\
  @{define_ML Drule.mk_implies: "cterm * cterm -> cterm"} \\
  \end{mldecls}
  \begin{mldecls}
  @{define_ML_type thm} \\
  @{define_ML Thm.transfer: "theory -> thm -> thm"} \\
  @{define_ML Thm.assume: "cterm -> thm"} \\
  @{define_ML Thm.forall_intr: "cterm -> thm -> thm"} \\
  @{define_ML Thm.forall_elim: "cterm -> thm -> thm"} \\
  @{define_ML Thm.implies_intr: "cterm -> thm -> thm"} \\
  @{define_ML Thm.implies_elim: "thm -> thm -> thm"} \\
  @{define_ML Thm.generalize: "Names.set * Names.set -> int -> thm -> thm"} \\
  @{define_ML Thm.instantiate: "ctyp TVars.table * cterm Vars.table -> thm -> thm"} \\
  @{define_ML Thm.add_axiom: "Proof.context ->
  binding * term -> theory -> (string * thm) * theory"} \\
  @{define_ML Thm.add_oracle: "binding * ('a -> cterm) -> theory ->
  (string * ('a -> thm)) * theory"} \\
  @{define_ML Thm.add_def: "Defs.context -> bool -> bool ->
  binding * term -> theory -> (string * thm) * theory"} \\
  \end{mldecls}
  \begin{mldecls}
  @{define_ML Theory.add_deps: "Defs.context -> string ->
  Defs.entry -> Defs.entry list -> theory -> theory"} \\
  @{define_ML Thm_Deps.all_oracles: "thm list -> Proofterm.oracle list"} \\
  \end{mldecls}
 
  🪙 🪙‹Logic.all›~\
  occurrences of the atomic term ‹a› in the body proposition ‹B› are replaced
  by bound variables. (See also 🪙‹lambda› on terms.)

  🪙 🪙‹Logic.mk_implies›~‹(A, B)› produces a Pure implication ‹A ==> B›.

  🪙 Types 🪙‹ctyp› and 🪙‹cterm› represent certified types and
  terms, respectively. These are abstract datatypes that guarantee that its
  values have passed the full well-formedness (and well-typedness) checks,
  relative to the declarations of type constructors, constants etc.\ in the
  background theory. The abstract types 🪙‹ctyp› and 🪙‹cterm›
  are part of the same inference kernel that is mainly responsible for
  🪙‹thm›. Thus syntactic operations on 🪙‹ctyp› and 🪙‹cterm› are located in the 🪙‹Thm› module, even though theorems
  are not yet involved at that stage.

  🪙 🪙‹Thm.ctyp_of›~‹ctxt τ› and 🪙‹Thm.cterm_of›~‹ctxt t› explicitly
  check types and terms, respectively. This also involves some basic
  normalizations, such expansion of type and term abbreviations from the
  underlying theory context. Full re-certification is relatively slow and
  should be avoided in tight reasoning loops.

  🪙 🪙‹Thm.apply›, 🪙‹Thm.lambda›, 🪙‹Thm.all›, 🪙‹Drule.mk_implies›
  etc.\ compose certified terms (or propositions) incrementally. This is
  equivalent to 🪙‹Thm.cterm_of› after unchecked 🪙‹$›, 🪙‹lambda›,
  🪙‹Logic.all›, 🪙‹Logic.mk_implies› etc., but there can be a big
  difference in performance when large existing entities are composed by a few
  extra constructions on top. There are separate operations to decompose
  certified terms and theorems to produce certified terms again.

  🪙 Type 🪙‹thm› represents proven propositions. This is an abstract
  datatype that guarantees that its values have been constructed by basic
  principles of the 🪙‹Thm› module. Every 🪙‹thm› value
  refers its background theory, cf.\ \secref{sec:context-theory}.

  🪙 🪙‹Thm.transfer›~‹thy thm› transfers the given theorem to a 🪙‹larger›
  theory, see also \secref{sec:context}. This formal adjustment of the
  background context has no logical significance, but is occasionally required
  for formal reasons, e.g.\ when theorems that are imported from more basic
  theories are used in the current situation.

  🪙 🪙‹Thm.assume›, 🪙‹Thm.forall_intr›, 🪙‹Thm.forall_elim›, 🪙‹Thm.implies_intr›, and 🪙‹Thm.implies_elim› correspond to the primitive
  inferences of \figref{fig:prim-rules}.

  🪙 🪙‹Thm.generalize›~‹(🪙α, 🪙x)› corresponds to the
  ‹generalize› rules of \figref{fig:subst-rules}. Here collections of type and
  term variables are generalized simultaneously, specified by the given sets of
  basic names.

  🪙 🪙‹Thm.instantiate›~‹(🪙α🪙s, 🪙x🪙τ)› corresponds to the
  ‹instantiate› rules of \figref{fig:subst-rules}. Type variables are
  substituted before term variables. Note that the types in ‹🪙x🪙τ› refer
  to the instantiated versions.

  🪙 🪙‹Thm.add_axiom›~‹ctxt (name, A)› declares an arbitrary proposition as
  axiom, and retrieves it as a theorem from the resulting theory, cf.\ ‹axiom›
  in \figref{fig:prim-rules}. Note that the low-level representation in the
  axiom table may differ slightly from the returned theorem.

  🪙 🪙‹Thm.add_oracle›~‹(binding, oracle)› produces a named oracle rule,
  essentially generating arbitrary axioms on the fly, cf.\ ‹axiom› in
  \figref{fig:prim-rules}.

  🪙 🪙‹Thm.add_def›~‹ctxt unchecked overloaded (name, c 🪙x ≡ t)›
  states a definitional axiom for an existing constant ‹c›. Dependencies are
  recorded via 🪙‹Theory.add_deps›, unless the ‹unchecked› option is set.
  Note that the low-level representation in the axiom table may differ
  slightly from the returned theorem.

  🪙 🪙‹Theory.add_deps›~‹ctxt name c🪙τ 🪙d🪙σ› declares dependencies of
  a named specification for constant ‹c🪙τ›, relative to existing
  specifications for constants ‹🪙d🪙σ›. This also works for type
  constructors.

  🪙 🪙‹Thm_Deps.all_oracles›~‹thms› returns all oracles used in the
  internal derivation of the given theorems; this covers the full graph of
  transitive dependencies. The result contains an authentic oracle name; if
  @{ML Proofterm.proofs} was at least @{ML 1} during the oracle inference, it
  also contains the position of the oracle invocation and its proposition. See
  also the command @{command_ref "thm_oracles"}.
›

text %mlantiq ‹
  \begin{matharray}{rcl}
  @{ML_antiquotation_def "ctyp"} & : & ‹ML_antiquotation› \
  @{ML_antiquotation_def "cterm"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "cprop"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "thm"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "thms"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "lemma"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  @{ML_antiquotation_def "oracle_name"} & : & ‹ML_antiquotation› java.lang.NullPointerException
  \end{matharray}

  🪙‹
  @@{ML_antiquotation ctyp} typ
  ;
  @@{ML_antiquotation cterm} term
  ;
  @@{ML_antiquotation cprop} prop
  ;
  @@{ML_antiquotation thm} thm
  ;
  @@{ML_antiquotation thms} thms
  ;
  @@{ML_antiquotation lemma} @{syntax embedded_lemma}
  ;
  @{syntax_def embedded_lemma} ('(' @'open' ')')? ((prop +) + @'and') 🍋
  @{syntax for_fixes} @'by' method method?
  ;
  @@{ML_antiquotation oracle_name} embedded
  ›

  🪙 ‹@{ctyp τ}› produces a certified type wrt.\ the current background theory
  --- as abstract value of type 🪙‹ctyp›.

  🪙 ‹@{cterm t}› and ‹@{cprop φ}› produce a certified term wrt.\ the current
  background theory --- as abstract value of type 🪙‹cterm›.

  🪙 ‹@{thm a}› produces a singleton fact --- as abstract value of type
  🪙‹thm›.

  🪙 ‹@{thms a}› produces a general fact --- as abstract value of type
  🪙‹thm list›.

  🪙 ‹@{lemma φ by meth}› produces a fact that is proven on the spot according
  to the minimal proof, which imitates a terminal Isar proof. The result is an
  abstract value of type 🪙‹thm› or 🪙‹thm list›, depending on
  the number of propositions given here.

  The internal derivation object lacks a proper theorem name, but it is
  formally closed, unless the ‹(open)› option is specified (this may impact
  performance of applications with proof terms).

  Since ML antiquotations are always evaluated at compile-time, there is no
  run-time overhead even for non-trivial proofs. Nonetheless, the
  justification is syntactically limited to a single @{command "by"} step.
  More complex Isar proofs should be done in regular theory source, before
  compiling the corresponding ML text that uses the result.

  🪙 ‹@{oracle_name a}› inlines the internalized oracle name ‹a› --- as
  🪙‹string› literal.
›


subsection ‹Auxiliary connectives \label{sec:logic-aux}›

text ‹
  Theory ‹Pure› p
  of the primitive ones, see \figref{fig:pure-aux}. These special constants
  are useful in certain internal encodings, and are normally not directly
  exposed to the user.

  \begin{figure}[htb]
  \begin{center}
  \begin{tabular}{ll}
  ‹conjunction :: prop ==> prop ==> prop› & (infix ‹&&&›) java.lang.NullPointerException
  ‹⊨ A &&& B ≡ (∧C. (A ==> B ==> C) ==> C)› \[1ex]
  ‹prop :: prop ==> prop› & (prefix ‹#›, suppressed) java.lang.NullPointerException
  ‹#A ≡ A› \[1ex]
  ‹term :: α ==> prop› & (prefix ‹TERM›) java.lang.NullPointerException
  ‹term x ≡ (∧A. A ==> A)› \[1ex]
  ‹type :: α itself› & (prefix ‹TYPE›) java.lang.NullPointerException
  ‹(unspecified)› java.lang.NullPointerException
  \end{tabular}
  \caption{Definitions of auxiliary connectives}\label{fig:pure-aux}
  \end{center}
  \end{figure}

  The introduction ‹A ==> B ==> A &&& B›, and eliminations (projections) ‹A &&& B
  ==> A›
  treat simultaneous assumptions and conclusions uniformly, e.g.\ consider ‹A
  ==> B ==> C &&& D›.
  as explicit conjunction internally, but this is refined (via backwards
  introduction) into separate sub-goals before the user commences the proof;
  the final result is projected into a list of theorems using eliminations
  (cf.\ \secref{sec:tactical-goals}).

  The ‹prop› marker (‹#›) makes arbitrarily complex propositions appear as
  atomic, without changing the meaning: ‹Γ ⊨ A› and ‹Γ ⊨ #A› are
  interchangeable. See \secref{sec:tactical-goals} for specific operations.

  The ‹term› marker turns any well-typed term into a derivable proposition: ‹⊨
  TERM t›
  to treat terms and proofs uniformly, similar to a type-theoretic framework.

  The ‹TYPE› constructor is the canonical representative of the unspecified
  type ‹α itself›; it essentially injects the language of types into that of
  terms. There is specific notation ‹TYPE(τ)› for ‹TYPE🪙τ itself🪙›. Although
  being devoid of any particular meaning, the term ‹TYPE(τ)› accounts for the
  type ‹τ› within the term language. In particular, ‹TYPE(α)› may be used as
  formal argument in primitive definitions, in order to circumvent hidden
  polymorphism (cf.\ \secref{sec:terms}). For example, ‹c TYPE(α) ≡ A[α]›
  defines ‹c :: α itself ==> prop› in terms of a proposition ‹A› that depends on
  an additional type argument, which is essentially a predicate on types.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Conjunction.intr: "thm -> thm -> thm"} \\
  @{define_ML Conjunction.elim: "thm -> thm * thm"} \\
  @{define_ML Drule.mk_term: "cterm -> thm"} \\
  @{define_ML Drule.dest_term: "thm -> cterm"} \\
  @{define_ML Logic.mk_type: "typ -> term"} \\
  @{define_ML Logic.dest_type: "term -> typ"} \\
  \end{mldecls}
 
  🪙 🪙‹Conjunction.intr› d

  🪙 🪙‹Conjunction.elim› derives ‹A› and ‹B› from ‹A &&& B›.

  🪙 🪙‹Drule.mk_term› derives ‹TERM t›.

  🪙 🪙‹Drule.dest_term› recovers term ‹t› from ‹TERM t›.

  🪙 🪙‹Logic.mk_type›~‹τ› produces the term ‹TYPE(τ)›.

  🪙 🪙‹Logic.dest_type›~‹TYPE(τ)› recovers the type ‹τ›.
›


subsection ‹Sort hypotheses›

text ‹
  Type variables are decorated with sorts, as explained in \secref{sec:types}.
  This constrains type instantiation to certain ranges of types: variable
  ‹α🪙s› m
  logic, sort constraints act like implicit preconditions on the result ‹(α🪙1
  : s🪙1), …, (α🪙n : s🪙n), Γ ⊨ φ›
  the propositions ‹Γ›, ‹φ›, as well as the proof of ‹Γ ⊨ φ›.

  These 🪙‹sort hypothesis› of a theorem are passed monotonically through
  further derivations. They are redundant, as long as the statement of a
  theorem still contains the type variables that are accounted here. The
  logical significance of sort hypotheses is limited to the boundary case
  where type variables disappear from the proposition, e.g.\ ‹(α🪙s : s) ⊨ φ›.
  Since such dangling type variables can be renamed arbitrarily without
  changing the proposition ‹φ›, the inference kernel maintains sort hypotheses
  in anonymous form ‹s ⊨ φ›.

  In most practical situations, such extra sort hypotheses may be stripped in
  a final bookkeeping step, e.g.\ at the end of a proof: they are typically
  left over from intermediate reasoning with type classes that can be
  satisfied by some concrete type ‹τ› of sort ‹s› to replace the hypothetical
  type variable ‹α🪙s›.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Thm.extra_shyps: "thm -> sort list"} \\
  @{define_ML Thm.strip_shyps: "thm -> thm"} \\
  \end{mldecls}
 
  🪙 🪙‹Thm.extra_shyps›~\
  the given theorem, i.e.\ the sorts that are not present within type
  variables of the statement.

  🪙 🪙‹Thm.strip_shyps›~‹thm› removes any extraneous sort hypotheses that
  can be witnessed from the type signature.
›

text %mlex ‹
  The following artificial example demonstrates the derivation of 🍋‹False› w
›

class empty =
  assumes bad: "∧(x::'a) y. x ≠ y"

theorem (in empty) false: False
  using bad by blast

ML_val ‹🍋 (Thm.extra_shyps @{thm false} = [🍋‹empty›])›

text ‹
  Thanks to the inference kernel managing sort hypothesis according to their
  logical significance, this example is merely an instance of 🪙‹ex falso
  quodlibet consequitur›
›


section ‹Object-level rules \label{sec:obj-rules}›

text ‹
  The primitive inferences covered so far mostly serve foundational purposes.
  User-level reasoning usually works via object-level rules that are
  represented as theorems of Pure. Composition of rules involves
  🪙‹backchaining›,
  ‹λ›-terms, and so-called 🪙‹lifting› of rules into a context of ‹∧› and ‹==>›
  connectives. Thus the full power of higher-order Natural Deduction in
  Isabelle/Pure becomes readily available.
›


subsection ‹Hereditary Harrop Formulae›

text ‹
  The idea of object-level rules is to model Natural Deduction inferences in
  the style of Gentzen 🍋‹"Gentzen:1935"›,
  similar to 🍋‹"Schroeder-Heister:1984"›. The most basic rule format is
  that of a 🪙‹Horn Clause›:
  \[
  \infer{‹A›}{‹A🪙1› & ‹…› & ‹A🪙n›}
  \]
  where ‹A, A🪙1, …, A🪙n› are atomic propositions of the framework, usually of
  the form ‹Trueprop B›, where ‹B› is a (compound) object-level statement.
  This object-level inference corresponds to an iterated implication in Pure
  like this:
  \[
  ‹A🪙1 ==> … A🪙n ==> A›
  \]
  As an example consider conjunction introduction: ‹A ==> B ==> A ∧ B›. Any
  parameters occurring in such rule statements are conceptionally treated as
  arbitrary:
  \[
  ‹∧x🪙1 … x🪙m. A🪙1 x🪙1 … x🪙m ==> … A🪙n x🪙1 … x🪙m ==> A x🪙1 … x🪙m›
  \]

  Nesting of rules means that the positions of ‹A🪙i› may again hold compound
  rules, not just atomic propositions. Propositions of this format are called
  🪙‹Hereditary Harrop Formulae› in the literature 🍋‹"Miller:1991"›. Here
  we give an inductive characterization as follows:

  🪙
  \begin{tabular}{ll}
  ‹🪙x› & set of variables java.lang.NullPointerException
  ‹🪙A› & set of atomic propositions java.lang.NullPointerException
  ‹🪙H = ∧🪙x🪙*. 🪙H🪙* ==> 🪙A› & set of Hereditary Harrop Formulas java.lang.NullPointerException
  \end{tabular}
  🪙

  Thus we essentially impose nesting levels on propositions formed from ‹∧›
  and ‹==>›. At each level there is a prefix of parameters and compound
  premises, concluding an atomic proposition. Typical examples are
  ‹⟶›-introduction ‹(A ==> B) ==> A ⟶ B› or mathematical induction ‹P 0 ==> (∧n. P n
  ==> P (Suc n)) ==> P n›.
  ‹(∧x. (∧y. y ≺ x ==> P y) ==> P x) ==> P x›, but this already marks the limit of
  rule complexity that is usually seen in practice.

  🪙
  Regular user-level inferences in Isabelle/Pure always maintain the following
  canonical form of results:

  🪙 Normalization by ‹(A ==> (∧x. B x)) ≡ (∧x. A ==> B x)›, which is a theorem of
  Pure, means that quantifiers are pushed in front of implication at each
  level of nesting. The normal form is a Hereditary Harrop Formula.

  🪙 The outermost prefix of parameters is represented via schematic variables:
  instead of ‹∧🪙x. 🪙H 🪙x ==> A 🪙x› we have ‹🪙H
  ?🪙x ==> A ?🪙x›.
  about the order of parameters, and vacuous quantifiers vanish automatically.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Simplifier.norm_hhf: "Proof.context -> thm -> thm"} \\
  \end{mldecls}
 
  🪙 🪙‹Simplifier.norm_hhf›~\
  according to the canonical form specified above. This is occasionally
  helpful to repair some low-level tools that do not handle Hereditary Harrop
  Formulae properly.
›


subsection ‹Rule composition›

text ‹
  The rule calculus of Isabelle/Pure provides two main inferences: @{inference
  resolution} (i.e.\ back-chaining of rules) and @{inference assumption}
  (i.e.\ closing a branch), both modulo higher-order unification. There are
  also combined variants, notably @{inference elim_resolution} and @{inference
  dest_resolution}.
 
  To understand the all-important @{inference resolution} principle, we first
  consider raw @{inference_def composition} (modulo higher-order unification
  with substitution ‹🪙›):
  \[
  \infer[(@{inference_def composition})]{‹🪙A🪙 ==> C🪙›}
  {‹🪙A ==> B› & ‹B' ==> C› & ‹B🪙 = B'🪙›}
  \]
  Here the conclusion of the first rule is unified with the premise of the
  second; the resulting rule instance inherits the premises of the first and
  conclusion of the second. Note that ‹C› can again consist of iterated
  implications. We can also permute the premises of the second rule
  back-and-forth in order to compose with ‹B'› in any position (subsequently
  we shall always refer to position 1 w.l.o.g.).

  In @{inference composition} the internal structure of the common part ‹B›
  and ‹B'› is not taken into account. For proper @{inference resolution} we
  require ‹B› to be atomic, and explicitly observe the structure ‹∧🪙x.
  🪙H 🪙x ==> B' 🪙x›
  is to adapt the first rule by ``lifting'' it into this context, by means of
  iterated application of the following inferences:
  \[
  \infer[(@{inference_def imp_lift})]{‹(🪙H ==> 🪙A) ==> (🪙H ==> B)›}{‹🪙A ==> B›}
  \]
  \[
  \infer[(@{inference_def all_lift})]{‹(∧🪙x. 🪙A (?🪙a 🪙x)) ==> (∧🪙x. B (?🪙a 🪙x))›}{‹🪙A ?🪙a ==> B ?🪙a›}
  \]
  By combining raw composition with lifting, we get full @{inference
  resolution} as follows:
  \[
  \infer[(@{inference_def resolution})]
  {‹(∧🪙x. 🪙H 🪙x ==> 🪙A (?🪙a 🪙x))🪙 ==> C🪙›}
  {\begin{tabular}{l}
    ‹🪙A ?🪙a ==> B ?🪙a› java.lang.NullPointerException
    ‹(∧🪙x. 🪙H 🪙x ==> B' 🪙x) ==> C› java.lang.NullPointerException
    ‹(λ🪙x. B (?🪙a 🪙x))🪙 = B'🪙› java.lang.NullPointerException
   \end{tabular}}
  \]

  Continued resolution of rules allows to back-chain a problem towards more
  and sub-problems. Branches are closed either by resolving with a rule of 0
  premises, or by producing a ``short-circuit'' within a solved situation
  (again modulo unification):
  \[
  \infer[(@{inference_def assumption})]{‹C🪙›}
  {‹(∧🪙x. 🪙H 🪙x ==> A 🪙x) ==> C› & ‹A🪙 = H🪙i🪙›~~\mbox{(for some~‹i›)}}
  \]

  %FIXME @{inference_def elim_resolution}, @{inference_def dest_resolution}
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML_infix "RSN": "thm * (int * thm) -> thm"} \\
  @{define_ML_infix "RS": "thm * thm -> thm"} \\
 
  @{define_ML_infix "RLN": "thm list * (int * thm list) -> thm list"} \\
  @{define_ML_infix "RL": "thm list * thm list -> thm list"} \\
 
  @{define_ML_infix "MRS": "thm list * thm -> thm"} \\
  @{define_ML_infix "OF": "thm * thm list -> thm"} \\
  \end{mldecls}
 
  🪙 ‹rule🪙1 RSN (i, rule🪙2)› r
  ‹i›-th premise of ‹rule🪙2›, according to the @{inference resolution}
  principle explained above. Unless there is precisely one resolvent it raises
  exception 🪙‹THM›.

  This corresponds to the rule attribute @{attribute THEN} in Isar source
  language.

  🪙 ‹rule🪙1 RS rule🪙2› abbreviates ‹rule🪙1 RSN (1, rule🪙2)›.

  🪙 ‹rules🪙1 RLN (i, rules🪙2)› joins lists of rules. For every ‹rule🪙1› in
  ‹rules🪙1› and ‹rule🪙2› in ‹rules🪙2›, it resolves the conclusion of ‹rule🪙1›
  with the ‹i›-th premise of ‹rule🪙2›, accumulating multiple results in one
  big list. Note that such strict enumerations of higher-order unifications
  can be inefficient compared to the lazy variant seen in elementary tactics
  like 🪙‹resolve_tac›.

  🪙 ‹rules🪙1 RL rules🪙2› abbreviates ‹rules🪙1 RLN (1, rules🪙2)›.

  🪙 ‹[rule🪙1, …, rule🪙n] MRS rule› resolves ‹rule🪙i› against premise ‹i› of
  ‹rule›, for ‹i = n, …, 1›. By working from right to left, newly emerging
  premises are concatenated in the result, without interfering.

  🪙 ‹rule OF rules› is an alternative notation for ‹rules MRS rule›, which
  makes rule composition look more like function application. Note that the
  argument ‹rules› need not be atomic.

  This corresponds to the rule attribute @{attribute OF} in Isar source
  language.
›


section ‹Proof terms \label{sec:proof-terms}›

text ‹
  The Isabelle/Pure inference kernel can record the proof of each theorem as a
  proof term that contains all logical inferences in detail. Rule composition
  by resolution (\secref{sec:obj-rules}) and type-class reasoning is broken
  down to primitive rules of the logical framework. The proof term can be
  inspected by a separate proof-checker, for example.
 
  According to the well-known 🪙‹Curry-Howard isomorphism›,
  viewed as a ‹λ›-term. Following this idea, proofs in Isabelle are internally
  represented by a datatype similar to the one for terms described in
  \secref{sec:terms}. On top of these syntactic terms, two more layers of
  ‹λ›-calculus are added, which correspond to ‹∧x :: α. B x› and ‹A ==> B›
  according to the propositions-as-types principle. The resulting 3-level
  ‹λ›-calculus resembles ``‹λHOL›'' in the more abstract setting of Pure Type
  Systems (PTS) 🍋‹"Barendregt-Geuvers:2001"›, if some fine points like
  schematic polymorphism and type classes are ignored.

  🪙
  🪙‹Proof abstractions› of the form ‹🪙λx :: α. prf› or ‹🪙λp : A. prf›
  correspond to introduction of ‹∧›/‹==>›, and 🪙‹proof applications› of the form
  ‹p ⋅ t› or ‹p ∙ q› correspond to elimination of ‹∧›/‹==>›. Actual types ‹α›,
  propositions ‹A›, and terms ‹t› might be suppressed and reconstructed from
  the overall proof term.

  🪙
  Various atomic proofs indicate special situations within the proof
  construction as follows.

  A 🪙‹bound proof variable› is a natural number ‹b› that acts as de-Bruijn
  index for proof term abstractions.

  A 🪙‹minimal proof› ``‹?›'' is a dummy proof term. This indicates some
  unrecorded part of the proof.

  ‹Hyp A› refers to some pending hypothesis by giving its proposition. This
  indicates an open context of implicit hypotheses, similar to loose bound
  variables or free variables within a term (\secref{sec:terms}).

  An 🪙‹axiom› or 🪙‹oracle› ‹a : A[🪙τ]› refers some postulated ‹proof
  constant›,
  the particular type instantiation may be given explicitly. The vector of
  types ‹🪙τ› refers to the schematic type variables in the generic
  proposition ‹A› in canonical order.

  A 🪙‹proof promise› ‹a : A[🪙τ]› is a placeholder for some proof of
  polymorphic proposition ‹A›, with explicit type instantiation as given by
  the vector ‹🪙τ›, as above. Unlike axioms or oracles, proof promises
  may be 🪙‹fulfilled› eventually, by substituting ‹a› by some particular proof
  ‹q› at the corresponding type instance. This acts like Hindley-Milner
  ‹let›-polymorphism: a generic local proof definition may get used at
  different type instances, and is replaced by the concrete instance
  eventually.

  A 🪙‹named theorem› wraps up some concrete proof as a closed formal entity,
  in the manner of constant definitions for proof terms. The 🪙‹proof body› of
  such boxed theorems involves some digest about oracles and promises
  occurring in the original proof. This allows the inference kernel to manage
  this critical information without the full overhead of explicit proof terms.
›


subsection ‹Reconstructing and checking proof terms›

text ‹
  Fully explicit proof terms can be large, but most of this information is
  redundant and can be reconstructed from the context. Therefore, the
  Isabelle/Pure inference kernel records only 🪙‹implicit› p
  omitting all typing information in terms, all term and type labels of proof
  abstractions, and some argument terms of applications ‹p ⋅ t› (if possible).

  There are separate operations to reconstruct the full proof term later on,
  using 🪙‹higher-order pattern unification› 🍋‹"nipkow-patterns" and
  "Berghofer-Nipkow:2000:TPHOL"›.

  The 🪙‹proof checker› expects a fully reconstructed proof term, and can turn
  it into a theorem by replaying its primitive inferences within the kernel.
›


subsection ‹Concrete syntax of proof terms›

text ‹
  The concrete syntax of proof terms is a slight extension of the regular
  inner syntax of Isabelle/Pure 🍋‹"isabelle-isar-ref"›.
  syntactic category @{syntax (inner) proof} is defined as follows:

  \begin{center}
  \begin{supertabular}{rclr}

  @{syntax_def (inner) proof} & = & ‹🪙λ› ‹params› 🍋‹.› ‹proof› java.lang.NullPointerException
    & ‹|› & ‹proof› ‹⋅› ‹any› java.lang.NullPointerException
    & ‹|› & ‹proof› ‹∙› ‹proof› java.lang.NullPointerException
    & ‹|› & ‹id | longid› java.lang.NullPointerException
  java.lang.NullPointerException

  ‹param› & = & ‹idt› java.lang.NullPointerException
    & ‹|› & ‹idt› 🍋‹:› ‹prop› java.lang.NullPointerException
    & ‹|› & 🍋‹(› ‹param› 🍋‹)› java.lang.NullPointerException
  java.lang.NullPointerException

  ‹params› & = & ‹param› java.lang.NullPointerException
    & ‹|› & ‹param› ‹params› java.lang.NullPointerException

  \end{supertabular}
  \end{center}

  Implicit term arguments in partial proofs are indicated by ``‹_›''. Type
  arguments for theorems and axioms may be specified using ‹p ⋅ TYPE(type)›
  (they must appear before any other term argument of a theorem or axiom, but
  may be omitted altogether).

  🪙
  There are separate read and print operations for proof terms, in order to
  avoid conflicts with the regular term language.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML_type proof} \\
  @{define_ML_type proof_body} \\
  @{define_ML Proofterm.proofs: "int Unsynchronized.ref"} \\
  @{define_ML Proofterm.reconstruct_proof:
  "theory -> term -> proof -> proof"} \\
  @{define_ML Proofterm.expand_proof: "theory ->
  (Proofterm.thm_header -> Thm_Name.P option) -> proof -> proof"} \\
  @{define_ML Proof_Checker.thm_of_proof: "theory -> proof -> thm"} \\
  @{define_ML Proof_Syntax.read_proof: "theory -> bool -> bool -> string -> proof"} \\
  @{define_ML Proof_Syntax.pretty_proof: "Proof.context -> proof -> Pretty.T"} \\
  \end{mldecls}
 
  🪙 Type 🪙‹proof› r
  constructors @{define_ML Abst}, @{define_ML AbsP}, @{define_ML_infix "%"},
  @{define_ML_infix "%%"}, @{define_ML PBound}, @{define_ML MinProof}, @{define_ML
  Hyp}, @{define_ML PAxm}, @{define_ML Oracle}, @{define_ML PThm} as explained
  above. %FIXME PClass (!?)

  🪙 Type 🪙‹proof_body› represents the nested proof information of a
  named theorem, consisting of a digest of oracles and named theorem over some
  proof term. The digest only covers the directly visible part of the proof:
  in order to get the full information, the implicit graph of nested theorems
  needs to be traversed (e.g.\ using 🪙‹Proofterm.fold_body_thms›).

  🪙 🪙‹Thm.proof_of›~‹thm› and 🪙‹Thm.proof_body_of›~‹thm› produce the
  proof term or proof body (with digest of oracles and theorems) from a given
  theorem. Note that this involves a full join of internal futures that
  fulfill pending proof promises, and thus disrupts the natural bottom-up
  construction of proofs by introducing dynamic ad-hoc dependencies. Parallel
  performance may suffer by inspecting proof terms at run-time.

  🪙 🪙‹Proofterm.proofs› specifies the detail of proof recording within
  🪙‹thm› values produced by the inference kernel: 🪙‹0› records only
  the names of oracles, 🪙‹1› records oracle names and propositions, 🪙‹2›
  additionally records full proof terms. Officially named theorems that
  contribute to a result are recorded in any case.

  🪙 🪙‹Proofterm.reconstruct_proof›~‹thy prop prf› turns the implicit
  proof term ‹prf› into a full proof of the given proposition.

  Reconstruction may fail if ‹prf› is not a proof of ‹prop›, or if it does not
  contain sufficient information for reconstruction. Failure may only happen
  for proofs that are constructed manually, but not for those produced
  automatically by the inference kernel.

  🪙 🪙‹Proofterm.expand_proof›~‹thy expand prf› reconstructs and expands
  the proofs of nested theorems according to the given ‹expand› function: a
  result of @{ML ‹SOME ""›} means full expansion, @{ML ‹SOME›}~‹name› means to
  keep the theorem node but replace its internal name, @{ML NONE} means no
  change.

  🪙 🪙‹Proof_Checker.thm_of_proof›~‹thy prf› turns the given (full) proof
  into a theorem, by replaying it using only primitive rules of the inference
  kernel.

  🪙 🪙‹Proof_Syntax.read_proof›~‹thy b🪙1 b🪙2 s› reads in a proof term. The
  Boolean flags indicate the use of sort and type information. Usually, typing
  information is left implicit and is inferred during proof reconstruction.
  %FIXME eliminate flags!?

  🪙 🪙‹Proof_Syntax.pretty_proof›~‹ctxt prf› pretty-prints the given proof
  term.
›

text %mlex ‹
  🪙 🍋‹~~/src/HOL/Proofs/ex/Proof_Terms.thy› p
  proof terms.

  🪙 🍋‹~~/src/HOL/Proofs/ex/XML_Data.thy› demonstrates export and import of
  proof terms via XML/ML data representation.
›

section ‹Instantiation of formal entities \label{sec:instantiation}›

text ‹
  The construction of formal entities (types, terms, theorems) in Isabelle/ML
  can be tedious, error-prone, and costly at run-time. Repeated certification
  of types/terms, or proof steps for theorems should be minimized, when
  performance is relevant.
 
  For example, consider a proof-producing decision procedure that refers to
  certain term schemes and derived rules that need to be applied repeatedly. A
  reasonably efficient approach is the subsequent separation of Isabelle/ML
  🪙‹compile-time› v
  loaded into the theory context to provide a tool as proof method, to be used
  later in a different context.

    🪙 At compile-time, the ML module constructs templates for relevant formal
    entities, e.g. as certified types/terms and proven theorems (with
    parameters). This uses the source notation for types, terms, propositions,
    inlined into Isabelle/ML. Formal parameters are taken from the template,
    and turned into ML names (as in 🍋‹let› expressions).

    🪙 At run-time, the ML tool takes concrete entities from the application
    context, and instantiates the above templates accordingly. The formal
    parameters of the compile-time template get assigned to concrete ML
    values. ML names and types have already been properly checked by the ML
    compiler, and the running program cannot go wrong in that respect. (It
    🪙‹can› go wrong, concerning types of the implemented logic, though).

  This approach is supported by ML antiquotations as follows.
›

text %mlantiq ‹
  \begin{matharray}{rcl}
  @{ML_antiquotation_def "instantiate"} & : & ‹ML_antiquotation› \
  \end{matharray}

  🪙‹
  @@{ML_antiquotation instantiate} embedded
  ›

  🪙 ‹@{instantiation source}› refers to embedded source text to produce an
  instantiation for a logical entity that is given literally in the text. The
  content of the @{syntax embedded} argument follows the syntax category
  @{syntax instantiation} defined below, using @{syntax embedded_ml} from
  antiquotation @{ML_antiquotation Type} (\secref{sec:types}), and @{syntax
  embedded_lemma} from antiquotation @{ML_antiquotation lemma}
  (\secref{sec:thms}).

  🪙‹
  @{syntax_def instantiation}: no_beta? (inst + @'and') @'in' @{syntax body}
  ;
  no_beta: '(' 'no_beta' ')'
  ;
  schematic: '(' 'schematic' ')'
  ;
  inst: ((type_ident | name) ((@'=' @{syntax embedded_ml}))?)
  ;
  body: body_type | body_term | body_prop | body_lemma
  ;
  body_type: ('typ' | 'ctyp') schematic? embedded
  ;
  body_term: ('term' | 'cterm') schematic? embedded
  ;
  body_prop: ('prop' | 'cprop') schematic? embedded
  ;
  body_lemma: 'lemma' schematic? @{syntax embedded_lemma}
  ›

    🪙 An @{syntax inst} entry assigns a type/term variable to a suitable ML
    value, given as ML expression in the current program context. The ML type
    of the expression needs to fit to the situation: 🍋‹'a =›~‹ty› refers to
    ‹ty›\<^verbatim>‹: typ› or ‹ty›\<^verbatim>‹: ctyp›, and 🍋‹a =›~‹tm› refers to ‹tm›\<^verbatim>‹: term› or
    ‹tm›\<^verbatim>‹: cterm›. Only a body for uncertified 🍋‹typ› / 🍋‹term› / 🍋‹prop›
    admits uncertified 🪙‹typ› or 🪙‹term› parameters. The
    other cases require certified 🪙‹ctyp› or 🪙‹cterm›
    parameters.

    If the RHS of the @{syntax inst} entry is omitted, it defaults to the LHS:
    🍋‹a› becomes 🍋‹a = a›. This only works for term variables that happen to
    be legal ML identifiers, and not for type variables.

    🪙 The ``‹(schematic)›'' option disables the usual check that all LHS names
    in @{syntax inst} are exactly those present as free variables in the body
    entity (type, term, prop, lemma statement). By default, omitted variables
    cause an error, but with ``‹(schematic)›'' they remain as schematic
    variables. The latter needs to be used with care, because unexpected
    variables may emerge, when the theory name space for constants changes
    over time.

    🪙 The ``‹(no_beta)›'' option disables the usual ‹β›-normalization for
    ‹body_term› / ‹body_prop› / ‹body_lemma›, but has no effect on
    ‹body_type›. This is occasionally useful for low-level applications, where
    ‹β›-conversion is treated explicitly in primitive inferences.
›

text %mlex ‹
  Below are some examples that demonstrate the antiquotation syntax.
  Real-world applications may be found in the Isabelle sources, by searching
  for the literal text ``🍋‹🍋›''
›

ML ‹
  🍋 ‹uncertified type parameters›
  fun make_assoc_type (A: typ, B: typ) : typ =
    🍋‹'a = A and 'b = B in typ ‹('a × 'b) list›\›;

  🍋 ‹uncertified term parameters›
  val make_assoc_list : (term * term) list -> term list =
    map (fn (x, y) =>
      🍋‹'a = ‹fastype_of x› and 'b = ‹fastype_of y› and
  x and y in term ‹(x, y)› for x :: 'a and y :: 'b›)

  🍋 ‹theorem with certified term parameters›
  fun symmetry (x: cterm) (y: cterm) : thm =
    🍋‹'a = ‹Thm.ctyp_of_cterm x› and x and y in
  lemma ‹x = y ==> y = x› for x y :: 'a by simp›

  🍋 ‹theorem with certified type parameter, and schematic result›
  fun symmetry_schematic (A: ctyp) : thm =
    🍋‹'a = A in
  lemma (schematic) ‹x = y ==> y = x› for x y :: 'a by simp›
›


end