diff --git a/src/Doc/Implementation/Logic.thy b/src/Doc/Implementation/Logic.thy
--- a/src/Doc/Implementation/Logic.thy
+++ b/src/Doc/Implementation/Logic.thy
@@ -1,1259 +1,1259 @@
 (*:maxLineLen=78:*)
 
 theory Logic
 imports Base
 begin
 
 chapter \<open>Primitive logic \label{ch:logic}\<close>
 
 text \<open>
   The logical foundations of Isabelle/Isar are that of the Pure logic, which
   has been introduced as a Natural Deduction framework in @{cite paulson700}.
   This is essentially the same logic as ``\<open>\<lambda>HOL\<close>'' in the more abstract
   setting of Pure Type Systems (PTS) @{cite "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 \<open>\<lambda>\<close>-calculus with corresponding arrows, \<open>\<Rightarrow>\<close> for syntactic function space
   (terms depending on terms), \<open>\<And>\<close> for universal quantification (proofs
   depending on terms), and \<open>\<Longrightarrow>\<close> 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.\<^footnote>\<open>This is the
   deeper logical reason, why the theory context \<open>\<Theta>\<close> is separate from the proof
   context \<open>\<Gamma>\<close> 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!\<close>
 \<close>
 
 
 section \<open>Types \label{sec:types}\<close>
 
 text \<open>
   The language of types is an uninterpreted order-sorted first-order algebra;
   types are qualified by ordered type classes.
 
   \<^medskip>
   A \<^emph>\<open>type class\<close> is an abstract syntactic entity declared in the theory
   context. The \<^emph>\<open>subclass relation\<close> \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close> is specified by stating an
   acyclic generating relation; the transitive closure is maintained
   internally. The resulting relation is an ordering: reflexive, transitive,
   and antisymmetric.
 
   A \<^emph>\<open>sort\<close> is a list of type classes written as \<open>s = {c\<^sub>1, \<dots>, c\<^sub>m}\<close>, it
   represents symbolic intersection. Notationally, the curly braces are omitted
   for singleton intersections, i.e.\ any class \<open>c\<close> may be read as a sort
   \<open>{c}\<close>. The ordering on type classes is extended to sorts according to the
   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>
   d\<^sub>j\<close>. The empty intersection \<open>{}\<close> refers to the universal sort, which is the
   largest element wrt.\ the sort order. Thus \<open>{}\<close> 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.
 
   \<^medskip>
   A \<^emph>\<open>fixed type variable\<close> is a pair of a basic name (starting with a \<open>'\<close>
   character) and a sort constraint, e.g.\ \<open>('a, s)\<close> which is usually printed
   as \<open>\<alpha>\<^sub>s\<close>. A \<^emph>\<open>schematic type variable\<close> is a pair of an indexname and a sort
   constraint, e.g.\ \<open>(('a, 0), s)\<close> which is usually printed as \<open>?\<alpha>\<^sub>s\<close>.
 
   Note that \<^emph>\<open>all\<close> 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 \<^emph>\<open>type constructor\<close> \<open>\<kappa>\<close> is a \<open>k\<close>-ary operator on types declared in the
   theory. Type constructor application is written postfix as \<open>(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>k)\<kappa>\<close>.
   For \<open>k = 0\<close> the argument tuple is omitted, e.g.\ \<open>prop\<close> instead of \<open>()prop\<close>.
   For \<open>k = 1\<close> the parentheses are omitted, e.g.\ \<open>\<alpha> list\<close> instead of
   \<open>(\<alpha>)list\<close>. Further notation is provided for specific constructors, notably
   the right-associative infix \<open>\<alpha> \<Rightarrow> \<beta>\<close> instead of \<open>(\<alpha>, \<beta>)fun\<close>.
 
   The logical category \<^emph>\<open>type\<close> is defined inductively over type variables and
   type constructors as follows: \<open>\<tau> = \<alpha>\<^sub>s | ?\<alpha>\<^sub>s | (\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>\<close>.
 
   A \<^emph>\<open>type abbreviation\<close> is a syntactic definition \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close> of an
   arbitrary type expression \<open>\<tau>\<close> over variables \<open>\<^vec>\<alpha>\<close>. Type abbreviations
   appear as type constructors in the syntax, but are expanded before entering
   the logical core.
 
   A \<^emph>\<open>type arity\<close> declares the image behavior of a type constructor wrt.\ the
   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
   sort \<open>s\<close> if every argument type \<open>\<tau>\<^sub>i\<close> is of sort \<open>s\<^sub>i\<close>. Arity declarations
   are implicitly completed, i.e.\ \<open>\<kappa> :: (\<^vec>s)c\<close> entails \<open>\<kappa> ::
   (\<^vec>s)c'\<close> for any \<open>c' \<supseteq> c\<close>.
 
   \<^medskip>
   The sort algebra is always maintained as \<^emph>\<open>coregular\<close>, which means that type
   arities are consistent with the subclass relation: for any type constructor
   \<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> ::
   (\<^vec>s\<^sub>2)c\<^sub>2\<close> holds \<open>\<^vec>s\<^sub>1 \<subseteq> \<^vec>s\<^sub>2\<close> component-wise.
 
   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 \<open>\<kappa>\<close> and sort \<open>s\<close> there is a most general vector of argument
   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
   sort \<open>s\<close>. Consequently, type unification has most general solutions (modulo
   equivalence of sorts), so type-inference produces primary types as expected
   @{cite "nipkow-prehofer"}.
 \<close>
 
 text %mlref \<open>
   \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}
 
   \<^descr> Type \<^ML_type>\<open>class\<close> represents type classes.
 
   \<^descr> Type \<^ML_type>\<open>sort\<close> represents sorts, i.e.\ finite intersections of
   classes. The empty list \<^ML>\<open>[]: sort\<close> refers to the empty class
   intersection, i.e.\ the ``full sort''.
 
   \<^descr> Type \<^ML_type>\<open>arity\<close> represents type arities. A triple \<open>(\<kappa>, \<^vec>s, s)
   : arity\<close> represents \<open>\<kappa> :: (\<^vec>s)s\<close> as described above.
 
   \<^descr> Type \<^ML_type>\<open>typ\<close> represents types; this is a datatype with constructors
   \<^ML>\<open>TFree\<close>, \<^ML>\<open>TVar\<close>, \<^ML>\<open>Type\<close>.
 
   \<^descr> \<^ML>\<open>Term.map_atyps\<close>~\<open>f \<tau>\<close> applies the mapping \<open>f\<close> to all atomic types
   (\<^ML>\<open>TFree\<close>, \<^ML>\<open>TVar\<close>) occurring in \<open>\<tau>\<close>.
 
   \<^descr> \<^ML>\<open>Term.fold_atyps\<close>~\<open>f \<tau>\<close> iterates the operation \<open>f\<close> over all
   occurrences of atomic types (\<^ML>\<open>TFree\<close>, \<^ML>\<open>TVar\<close>) in \<open>\<tau>\<close>; the type
   structure is traversed from left to right.
 
   \<^descr> \<^ML>\<open>Sign.subsort\<close>~\<open>thy (s\<^sub>1, s\<^sub>2)\<close> tests the subsort relation \<open>s\<^sub>1 \<subseteq>
   s\<^sub>2\<close>.
 
   \<^descr> \<^ML>\<open>Sign.of_sort\<close>~\<open>thy (\<tau>, s)\<close> tests whether type \<open>\<tau>\<close> is of sort \<open>s\<close>.
 
   \<^descr> \<^ML>\<open>Sign.add_type\<close>~\<open>ctxt (\<kappa>, k, mx)\<close> declares a new type constructors \<open>\<kappa>\<close>
   with \<open>k\<close> arguments and optional mixfix syntax.
 
   \<^descr> \<^ML>\<open>Sign.add_type_abbrev\<close>~\<open>ctxt (\<kappa>, \<^vec>\<alpha>, \<tau>)\<close> defines a new type
   abbreviation \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close>.
 
   \<^descr> \<^ML>\<open>Sign.primitive_class\<close>~\<open>(c, [c\<^sub>1, \<dots>, c\<^sub>n])\<close> declares a new class \<open>c\<close>,
   together with class relations \<open>c \<subseteq> c\<^sub>i\<close>, for \<open>i = 1, \<dots>, n\<close>.
 
   \<^descr> \<^ML>\<open>Sign.primitive_classrel\<close>~\<open>(c\<^sub>1, c\<^sub>2)\<close> declares the class relation
   \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close>.
 
   \<^descr> \<^ML>\<open>Sign.primitive_arity\<close>~\<open>(\<kappa>, \<^vec>s, s)\<close> declares the arity \<open>\<kappa> ::
   (\<^vec>s)s\<close>.
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "class"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "sort"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "type_name"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "type_abbrev"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "nonterminal"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "typ"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
   @@{ML_antiquotation class} embedded
   ;
   @@{ML_antiquotation sort} sort
   ;
   (@@{ML_antiquotation type_name} |
    @@{ML_antiquotation type_abbrev} |
    @@{ML_antiquotation nonterminal}) embedded
   ;
   @@{ML_antiquotation typ} type
   \<close>
 
   \<^descr> \<open>@{class c}\<close> inlines the internalized class \<open>c\<close> --- as \<^ML_type>\<open>string\<close>
   literal.
 
   \<^descr> \<open>@{sort s}\<close> inlines the internalized sort \<open>s\<close> --- as \<^ML_type>\<open>string
   list\<close> literal.
 
   \<^descr> \<open>@{type_name c}\<close> inlines the internalized type constructor \<open>c\<close> --- as
   \<^ML_type>\<open>string\<close> literal.
 
   \<^descr> \<open>@{type_abbrev c}\<close> inlines the internalized type abbreviation \<open>c\<close> --- as
   \<^ML_type>\<open>string\<close> literal.
 
   \<^descr> \<open>@{nonterminal c}\<close> inlines the internalized syntactic type~/ grammar
   nonterminal \<open>c\<close> --- as \<^ML_type>\<open>string\<close> literal.
 
   \<^descr> \<open>@{typ \<tau>}\<close> inlines the internalized type \<open>\<tau>\<close> --- as constructor term for
   datatype \<^ML_type>\<open>typ\<close>.
 \<close>
 
 
 section \<open>Terms \label{sec:terms}\<close>
 
 text \<open>
   The language of terms is that of simply-typed \<open>\<lambda>\<close>-calculus with de-Bruijn
   indices for bound variables (cf.\ @{cite debruijn72} or @{cite
   "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.
 
   \<^medskip>
   A \<^emph>\<open>bound variable\<close> is a natural number \<open>b\<close>, 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 \<open>\<lambda>\<^bsub>bool\<^esub>. \<lambda>\<^bsub>bool\<^esub>. 1 \<and> 0\<close>
   would correspond to \<open>\<lambda>x\<^bsub>bool\<^esub>. \<lambda>y\<^bsub>bool\<^esub>. x \<and> y\<close> 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 \<^emph>\<open>loose variable\<close> 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 \<^emph>\<open>fixed variable\<close> is a pair of a basic name and a type, e.g.\ \<open>(x, \<tau>)\<close>
   which is usually printed \<open>x\<^sub>\<tau>\<close> here. A \<^emph>\<open>schematic variable\<close> is a pair of an
   indexname and a type, e.g.\ \<open>((x, 0), \<tau>)\<close> which is likewise printed as
   \<open>?x\<^sub>\<tau>\<close>.
 
   \<^medskip>
   A \<^emph>\<open>constant\<close> is a pair of a basic name and a type, e.g.\ \<open>(c, \<tau>)\<close> which is
   usually printed as \<open>c\<^sub>\<tau>\<close> here. Constants are declared in the context as
   polymorphic families \<open>c :: \<sigma>\<close>, meaning that all substitution instances \<open>c\<^sub>\<tau>\<close>
   for \<open>\<tau> = \<sigma>\<vartheta>\<close> are valid.
 
   The vector of \<^emph>\<open>type arguments\<close> of constant \<open>c\<^sub>\<tau>\<close> wrt.\ the declaration \<open>c
   :: \<sigma>\<close> is defined as the codomain of the matcher \<open>\<vartheta> = {?\<alpha>\<^sub>1 \<mapsto> \<tau>\<^sub>1,
   \<dots>, ?\<alpha>\<^sub>n \<mapsto> \<tau>\<^sub>n}\<close> presented in canonical order \<open>(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n)\<close>, corresponding
   to the left-to-right occurrences of the \<open>\<alpha>\<^sub>i\<close> in \<open>\<sigma>\<close>. Within a given theory
   context, there is a one-to-one correspondence between any constant \<open>c\<^sub>\<tau>\<close> and
   the application \<open>c(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n)\<close> of its type arguments. For example, with
   \<open>plus :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> \<alpha>\<close>, the instance \<open>plus\<^bsub>nat \<Rightarrow> nat \<Rightarrow> nat\<^esub>\<close> corresponds to
   \<open>plus(nat)\<close>.
 
   Constant declarations \<open>c :: \<sigma>\<close> may contain sort constraints for type
   variables in \<open>\<sigma>\<close>. These are observed by type-inference as expected, but
   \<^emph>\<open>ignored\<close> 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.
 
   \<^medskip>
   An \<^emph>\<open>atomic term\<close> is either a variable or constant. The logical category
   \<^emph>\<open>term\<close> is defined inductively over atomic terms, with abstraction and
   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>.
   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 \<open>t :: \<tau>\<close> assigns a (unique) type to a term according
   to the structure of atomic terms, abstractions, and applications:
   \[
   \infer{\<open>a\<^sub>\<tau> :: \<tau>\<close>}{}
   \qquad
   \infer{\<open>(\<lambda>x\<^sub>\<tau>. t) :: \<tau> \<Rightarrow> \<sigma>\<close>}{\<open>t :: \<sigma>\<close>}
   \qquad
   \infer{\<open>t u :: \<sigma>\<close>}{\<open>t :: \<tau> \<Rightarrow> \<sigma>\<close> & \<open>u :: \<tau>\<close>}
   \]
   A \<^emph>\<open>well-typed term\<close> 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 \<open>x\<^bsub>\<tau>\<^sub>1\<^esub>\<close> and \<open>x\<^bsub>\<tau>\<^sub>2\<^esub>\<close> 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.
 
   \<^medskip>
   The \<^emph>\<open>hidden polymorphism\<close> of a term \<open>t :: \<sigma>\<close> is the set of type variables
   occurring in \<open>t\<close>, but not in its type \<open>\<sigma>\<close>. 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 \<open>t\<vartheta> :: \<sigma>\<close> and
   \<open>t\<vartheta>' :: \<sigma>\<close> with the same type. This slightly pathological
   situation notoriously demands additional care.
 
   \<^medskip>
   A \<^emph>\<open>term abbreviation\<close> is a syntactic definition \<open>c\<^sub>\<sigma> \<equiv> t\<close> of a closed term
   \<open>t\<close> of type \<open>\<sigma>\<close>, 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 \<open>t \<rightarrow>
   c\<^sub>\<sigma>\<close> as rules for higher-order rewriting.
 
   \<^medskip>
   Canonical operations on \<open>\<lambda>\<close>-terms include \<open>\<alpha>\<beta>\<eta>\<close>-conversion: \<open>\<alpha>\<close>-conversion
   refers to capture-free renaming of bound variables; \<open>\<beta>\<close>-conversion contracts
   an abstraction applied to an argument term, substituting the argument in the
   body: \<open>(\<lambda>x. b)a\<close> becomes \<open>b[a/x]\<close>; \<open>\<eta>\<close>-conversion contracts vacuous
   application-abstraction: \<open>\<lambda>x. f x\<close> becomes \<open>f\<close>, provided that the bound
   variable does not occur in \<open>f\<close>.
 
   Terms are normally treated modulo \<open>\<alpha>\<close>-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 \<open>\<alpha>\<beta>\<eta>\<close>-conversion is commonplace in various standard
   operations (\secref{sec:obj-rules}) that are based on higher-order
   unification and matching.
 \<close>
 
 text %mlref \<open>
   \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}
 
   \<^descr> Type \<^ML_type>\<open>term\<close> represents de-Bruijn terms, with comments in
   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 "$"}.
 
   \<^descr> \<open>t\<close>~\<^ML_text>\<open>aconv\<close>~\<open>u\<close> checks \<open>\<alpha>\<close>-equivalence of two terms. This is the
   basic equality relation on type \<^ML_type>\<open>term\<close>; raw datatype equality
   should only be used for operations related to parsing or printing!
 
   \<^descr> \<^ML>\<open>Term.map_types\<close>~\<open>f t\<close> applies the mapping \<open>f\<close> to all types occurring
   in \<open>t\<close>.
 
   \<^descr> \<^ML>\<open>Term.fold_types\<close>~\<open>f t\<close> iterates the operation \<open>f\<close> over all
   occurrences of types in \<open>t\<close>; the term structure is traversed from left to
   right.
 
   \<^descr> \<^ML>\<open>Term.map_aterms\<close>~\<open>f t\<close> applies the mapping \<open>f\<close> to all atomic terms
   (\<^ML>\<open>Bound\<close>, \<^ML>\<open>Free\<close>, \<^ML>\<open>Var\<close>, \<^ML>\<open>Const\<close>) occurring in \<open>t\<close>.
 
   \<^descr> \<^ML>\<open>Term.fold_aterms\<close>~\<open>f t\<close> iterates the operation \<open>f\<close> over all
   occurrences of atomic terms (\<^ML>\<open>Bound\<close>, \<^ML>\<open>Free\<close>, \<^ML>\<open>Var\<close>, \<^ML>\<open>Const\<close>) in \<open>t\<close>; the term structure is traversed from left to right.
 
   \<^descr> \<^ML>\<open>fastype_of\<close>~\<open>t\<close> determines the type of a well-typed term. This
   operation is relatively slow, despite the omission of any sanity checks.
 
   \<^descr> \<^ML>\<open>lambda\<close>~\<open>a b\<close> produces an abstraction \<open>\<lambda>a. b\<close>, where occurrences of
   the atomic term \<open>a\<close> in the body \<open>b\<close> are replaced by bound variables.
 
   \<^descr> \<^ML>\<open>betapply\<close>~\<open>(t, u)\<close> produces an application \<open>t u\<close>, with topmost
   \<open>\<beta>\<close>-conversion if \<open>t\<close> is an abstraction.
 
   \<^descr> \<^ML>\<open>incr_boundvars\<close>~\<open>j\<close> increments a term's dangling bound variables by
   the offset \<open>j\<close>. 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.
 
   \<^descr> \<^ML>\<open>Sign.declare_const\<close>~\<open>ctxt ((c, \<sigma>), mx)\<close> declares a new constant \<open>c ::
   \<sigma>\<close> with optional mixfix syntax.
 
   \<^descr> \<^ML>\<open>Sign.add_abbrev\<close>~\<open>print_mode (c, t)\<close> introduces a new term
   abbreviation \<open>c \<equiv> t\<close>.
 
   \<^descr> \<^ML>\<open>Sign.const_typargs\<close>~\<open>thy (c, \<tau>)\<close> and \<^ML>\<open>Sign.const_instance\<close>~\<open>thy
   (c, [\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n])\<close> convert between two representations of polymorphic
   constants: full type instance vs.\ compact type arguments form.
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "const_name"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "const_abbrev"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "const"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "term"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "prop"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
   (@@{ML_antiquotation const_name} |
    @@{ML_antiquotation const_abbrev}) embedded
   ;
   @@{ML_antiquotation const} ('(' (type + ',') ')')?
   ;
   @@{ML_antiquotation term} term
   ;
   @@{ML_antiquotation prop} prop
   \<close>
 
   \<^descr> \<open>@{const_name c}\<close> inlines the internalized logical constant name \<open>c\<close> ---
   as \<^ML_type>\<open>string\<close> literal.
 
   \<^descr> \<open>@{const_abbrev c}\<close> inlines the internalized abbreviated constant name \<open>c\<close>
   --- as \<^ML_type>\<open>string\<close> literal.
 
   \<^descr> \<open>@{const c(\<^vec>\<tau>)}\<close> inlines the internalized constant \<open>c\<close> with precise
   type instantiation in the sense of \<^ML>\<open>Sign.const_instance\<close> --- as \<^ML>\<open>Const\<close> constructor term for datatype \<^ML_type>\<open>term\<close>.
 
   \<^descr> \<open>@{term t}\<close> inlines the internalized term \<open>t\<close> --- as constructor term for
   datatype \<^ML_type>\<open>term\<close>.
 
   \<^descr> \<open>@{prop \<phi>}\<close> inlines the internalized proposition \<open>\<phi>\<close> --- as constructor
   term for datatype \<^ML_type>\<open>term\<close>.
 \<close>
 
 
 section \<open>Theorems \label{sec:thms}\<close>
 
 text \<open>
   A \<^emph>\<open>proposition\<close> is a well-typed term of type \<open>prop\<close>, a \<^emph>\<open>theorem\<close> is a
   proven proposition (depending on a context of hypotheses and the background
   theory). Primitive inferences include plain Natural Deduction rules for the
   primary connectives \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> of the framework. There is also a builtin
   notion of equality/equivalence \<open>\<equiv>\<close>.
 \<close>
 
 
 subsection \<open>Primitive connectives and rules \label{sec:prim-rules}\<close>
 
 text \<open>
   The theory \<open>Pure\<close> contains constant declarations for the primitive
   connectives \<open>\<And>\<close>, \<open>\<Longrightarrow>\<close>, and \<open>\<equiv>\<close> of the logical framework, see
   \figref{fig:pure-connectives}. The derivability judgment \<open>A\<^sub>1, \<dots>, A\<^sub>n \<turnstile> B\<close>
   is defined inductively by the primitive inferences given in
   \figref{fig:prim-rules}, with the global restriction that the hypotheses
   must \<^emph>\<open>not\<close> 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}
   \<open>all :: (\<alpha> \<Rightarrow> prop) \<Rightarrow> prop\<close> & universal quantification (binder \<open>\<And>\<close>) \\
   \<open>\<Longrightarrow> :: prop \<Rightarrow> prop \<Rightarrow> prop\<close> & implication (right associative infix) \\
   \<open>\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop\<close> & equality relation (infix) \\
   \end{tabular}
   \caption{Primitive connectives of Pure}\label{fig:pure-connectives}
   \end{center}
   \end{figure}
 
   \begin{figure}[htb]
   \begin{center}
   \[
   \infer[\<open>(axiom)\<close>]{\<open>\<turnstile> A\<close>}{\<open>A \<in> \<Theta>\<close>}
   \qquad
   \infer[\<open>(assume)\<close>]{\<open>A \<turnstile> A\<close>}{}
   \]
   \[
   \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>}
   \qquad
   \infer[\<open>(\<And>\<hyphen>elim)\<close>]{\<open>\<Gamma> \<turnstile> B[a]\<close>}{\<open>\<Gamma> \<turnstile> \<And>x. B[x]\<close>}
   \]
   \[
   \infer[\<open>(\<Longrightarrow>\<hyphen>intro)\<close>]{\<open>\<Gamma> - A \<turnstile> A \<Longrightarrow> B\<close>}{\<open>\<Gamma> \<turnstile> B\<close>}
   \qquad
   \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>}
   \]
   \caption{Primitive inferences of Pure}\label{fig:prim-rules}
   \end{center}
   \end{figure}
 
   \begin{figure}[htb]
   \begin{center}
   \begin{tabular}{ll}
   \<open>\<turnstile> (\<lambda>x. b[x]) a \<equiv> b[a]\<close> & \<open>\<beta>\<close>-conversion \\
   \<open>\<turnstile> x \<equiv> x\<close> & reflexivity \\
   \<open>\<turnstile> x \<equiv> y \<Longrightarrow> P x \<Longrightarrow> P y\<close> & substitution \\
   \<open>\<turnstile> (\<And>x. f x \<equiv> g x) \<Longrightarrow> f \<equiv> g\<close> & extensionality \\
   \<open>\<turnstile> (A \<Longrightarrow> B) \<Longrightarrow> (B \<Longrightarrow> A) \<Longrightarrow> A \<equiv> B\<close> & logical equivalence \\
   \end{tabular}
   \caption{Conceptual axiomatization of Pure equality}\label{fig:pure-equality}
   \end{center}
   \end{figure}
 
   The introduction and elimination rules for \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> are analogous to
   formation of dependently typed \<open>\<lambda>\<close>-terms representing the underlying proof
   objects. Proof terms 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 \<open>\<lambda>\<close>-calculus become
   explicit: \<open>\<Rightarrow>\<close> for terms, and \<open>\<And>/\<Longrightarrow>\<close> for proofs (cf.\ @{cite
   "Berghofer-Nipkow:2000:TPHOL"}).
 
   Observe that locally fixed parameters (as in \<open>\<And>\<hyphen>intro\<close>) need not be recorded
   in the hypotheses, because the simple syntactic types of Pure are always
   inhabitable. ``Assumptions'' \<open>x :: \<tau>\<close> for type-membership are only present
   as long as some \<open>x\<^sub>\<tau>\<close> occurs in the statement body.\<^footnote>\<open>This is the key
   difference to ``\<open>\<lambda>HOL\<close>'' in the PTS framework @{cite
   "Barendregt-Geuvers:2001"}, where hypotheses \<open>x : A\<close> are treated uniformly
   for propositions and types.\<close>
 
   \<^medskip>
   The axiomatization of a theory is implicitly closed by forming all instances
   of type and term variables: \<open>\<turnstile> A\<vartheta>\<close> holds for any substitution
   instance of an axiom \<open>\<turnstile> A\<close>. By pushing substitutions through derivations
   inductively, we also get admissible \<open>generalize\<close> and \<open>instantiate\<close> rules as
   shown in \figref{fig:subst-rules}.
 
   \begin{figure}[htb]
   \begin{center}
   \[
   \infer{\<open>\<Gamma> \<turnstile> B[?\<alpha>]\<close>}{\<open>\<Gamma> \<turnstile> B[\<alpha>]\<close> & \<open>\<alpha> \<notin> \<Gamma>\<close>}
   \quad
   \infer[\quad\<open>(generalize)\<close>]{\<open>\<Gamma> \<turnstile> B[?x]\<close>}{\<open>\<Gamma> \<turnstile> B[x]\<close> & \<open>x \<notin> \<Gamma>\<close>}
   \]
   \[
   \infer{\<open>\<Gamma> \<turnstile> B[\<tau>]\<close>}{\<open>\<Gamma> \<turnstile> B[?\<alpha>]\<close>}
   \quad
   \infer[\quad\<open>(instantiate)\<close>]{\<open>\<Gamma> \<turnstile> B[t]\<close>}{\<open>\<Gamma> \<turnstile> B[?x]\<close>}
   \]
   \caption{Admissible substitution rules}\label{fig:subst-rules}
   \end{center}
   \end{figure}
 
   Note that \<open>instantiate\<close> does not require an explicit side-condition, because
   \<open>\<Gamma>\<close> may never contain schematic variables.
 
   In principle, variables could be substituted in hypotheses as well, but this
   would disrupt the monotonicity of reasoning: deriving \<open>\<Gamma>\<vartheta> \<turnstile>
   B\<vartheta>\<close> from \<open>\<Gamma> \<turnstile> B\<close> is correct, but \<open>\<Gamma>\<vartheta> \<supseteq> \<Gamma>\<close> does not
   necessarily hold: the result belongs to a different proof context.
 
   \<^medskip> An \<^emph>\<open>oracle\<close> is a function that produces axioms on the fly. Logically,
   this is an instance of the \<open>axiom\<close> 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 \<^emph>\<open>simple definition\<close> consists of a constant declaration \<open>c :: \<sigma>\<close> together
   with an axiom \<open>\<turnstile> c \<equiv> t\<close>, where \<open>t :: \<sigma>\<close> is a closed term without any hidden
   polymorphism. The RHS may depend on further defined constants, but not \<open>c\<close>
   itself. Definitions of functions may be presented as \<open>c \<^vec>x \<equiv> t\<close>
   instead of the puristic \<open>c \<equiv> \<lambda>\<^vec>x. t\<close>.
 
   An \<^emph>\<open>overloaded definition\<close> consists of a collection of axioms for the same
   constant, with zero or one equations \<open>c((\<^vec>\<alpha>)\<kappa>) \<equiv> t\<close> for each type
   constructor \<open>\<kappa>\<close> (for distinct variables \<open>\<^vec>\<alpha>\<close>). The RHS may mention
   previously defined constants as above, or arbitrary constants \<open>d(\<alpha>\<^sub>i)\<close> for
   some \<open>\<alpha>\<^sub>i\<close> projected from \<open>\<^vec>\<alpha>\<close>. Thus overloaded definitions
   essentially work by primitive recursion over the syntactic structure of a
   single type argument. See also @{cite \<open>\S4.3\<close>
   "Haftmann-Wenzel:2006:classes"}.
 \<close>
 
 text %mlref \<open>
   \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: "string list * string list -> int -> thm -> thm"} \\
   @{define_ML Thm.instantiate: "((indexname * sort) * ctyp) list * ((indexname * typ) * cterm) list
   -> 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}
 
   \<^descr> \<^ML>\<open>Logic.all\<close>~\<open>a B\<close> produces a Pure quantification \<open>\<And>a. B\<close>, where
   occurrences of the atomic term \<open>a\<close> in the body proposition \<open>B\<close> are replaced
   by bound variables. (See also \<^ML>\<open>lambda\<close> on terms.)
 
   \<^descr> \<^ML>\<open>Logic.mk_implies\<close>~\<open>(A, B)\<close> produces a Pure implication \<open>A \<Longrightarrow> B\<close>.
 
   \<^descr> Types \<^ML_type>\<open>ctyp\<close> and \<^ML_type>\<open>cterm\<close> 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 \<^ML_type>\<open>ctyp\<close> and \<^ML_type>\<open>cterm\<close>
   are part of the same inference kernel that is mainly responsible for
   \<^ML_type>\<open>thm\<close>. Thus syntactic operations on \<^ML_type>\<open>ctyp\<close> and \<^ML_type>\<open>cterm\<close> are located in the \<^ML_structure>\<open>Thm\<close> module, even though theorems
   are not yet involved at that stage.
 
   \<^descr> \<^ML>\<open>Thm.ctyp_of\<close>~\<open>ctxt \<tau>\<close> and \<^ML>\<open>Thm.cterm_of\<close>~\<open>ctxt t\<close> 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.
 
   \<^descr> \<^ML>\<open>Thm.apply\<close>, \<^ML>\<open>Thm.lambda\<close>, \<^ML>\<open>Thm.all\<close>, \<^ML>\<open>Drule.mk_implies\<close>
   etc.\ compose certified terms (or propositions) incrementally. This is
-  equivalent to \<^ML>\<open>Thm.cterm_of\<close> after unchecked \<^ML_op>\<open>$\<close>, \<^ML>\<open>lambda\<close>,
+  equivalent to \<^ML>\<open>Thm.cterm_of\<close> after unchecked \<^ML_infix>\<open>$\<close>, \<^ML>\<open>lambda\<close>,
   \<^ML>\<open>Logic.all\<close>, \<^ML>\<open>Logic.mk_implies\<close> 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.
 
   \<^descr> Type \<^ML_type>\<open>thm\<close> represents proven propositions. This is an abstract
   datatype that guarantees that its values have been constructed by basic
   principles of the \<^ML_structure>\<open>Thm\<close> module. Every \<^ML_type>\<open>thm\<close> value
   refers its background theory, cf.\ \secref{sec:context-theory}.
 
   \<^descr> \<^ML>\<open>Thm.transfer\<close>~\<open>thy thm\<close> transfers the given theorem to a \<^emph>\<open>larger\<close>
   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.
 
   \<^descr> \<^ML>\<open>Thm.assume\<close>, \<^ML>\<open>Thm.forall_intr\<close>, \<^ML>\<open>Thm.forall_elim\<close>, \<^ML>\<open>Thm.implies_intr\<close>, and \<^ML>\<open>Thm.implies_elim\<close> correspond to the primitive
   inferences of \figref{fig:prim-rules}.
 
   \<^descr> \<^ML>\<open>Thm.generalize\<close>~\<open>(\<^vec>\<alpha>, \<^vec>x)\<close> corresponds to the
   \<open>generalize\<close> rules of \figref{fig:subst-rules}. Here collections of type and
   term variables are generalized simultaneously, specified by the given basic
   names.
 
   \<^descr> \<^ML>\<open>Thm.instantiate\<close>~\<open>(\<^vec>\<alpha>\<^sub>s, \<^vec>x\<^sub>\<tau>)\<close> corresponds to the
   \<open>instantiate\<close> rules of \figref{fig:subst-rules}. Type variables are
   substituted before term variables. Note that the types in \<open>\<^vec>x\<^sub>\<tau>\<close> refer
   to the instantiated versions.
 
   \<^descr> \<^ML>\<open>Thm.add_axiom\<close>~\<open>ctxt (name, A)\<close> declares an arbitrary proposition as
   axiom, and retrieves it as a theorem from the resulting theory, cf.\ \<open>axiom\<close>
   in \figref{fig:prim-rules}. Note that the low-level representation in the
   axiom table may differ slightly from the returned theorem.
 
   \<^descr> \<^ML>\<open>Thm.add_oracle\<close>~\<open>(binding, oracle)\<close> produces a named oracle rule,
   essentially generating arbitrary axioms on the fly, cf.\ \<open>axiom\<close> in
   \figref{fig:prim-rules}.
 
   \<^descr> \<^ML>\<open>Thm.add_def\<close>~\<open>ctxt unchecked overloaded (name, c \<^vec>x \<equiv> t)\<close>
   states a definitional axiom for an existing constant \<open>c\<close>. Dependencies are
   recorded via \<^ML>\<open>Theory.add_deps\<close>, unless the \<open>unchecked\<close> option is set.
   Note that the low-level representation in the axiom table may differ
   slightly from the returned theorem.
 
   \<^descr> \<^ML>\<open>Theory.add_deps\<close>~\<open>ctxt name c\<^sub>\<tau> \<^vec>d\<^sub>\<sigma>\<close> declares dependencies of
   a named specification for constant \<open>c\<^sub>\<tau>\<close>, relative to existing
   specifications for constants \<open>\<^vec>d\<^sub>\<sigma>\<close>. This also works for type
   constructors.
 
   \<^descr> \<^ML>\<open>Thm_Deps.all_oracles\<close>~\<open>thms\<close> 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"}.
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "ctyp"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "cterm"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "cprop"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "thm"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "thms"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "lemma"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "oracle_name"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
   @@{ML_antiquotation ctyp} typ
   ;
   @@{ML_antiquotation cterm} term
   ;
   @@{ML_antiquotation cprop} prop
   ;
   @@{ML_antiquotation thm} thm
   ;
   @@{ML_antiquotation thms} thms
   ;
   @@{ML_antiquotation lemma} ('(' @'open' ')')? ((prop +) + @'and') \<newline>
     @'by' method method?
   ;
   @@{ML_antiquotation oracle_name} embedded
   \<close>
 
   \<^descr> \<open>@{ctyp \<tau>}\<close> produces a certified type wrt.\ the current background theory
   --- as abstract value of type \<^ML_type>\<open>ctyp\<close>.
 
   \<^descr> \<open>@{cterm t}\<close> and \<open>@{cprop \<phi>}\<close> produce a certified term wrt.\ the current
   background theory --- as abstract value of type \<^ML_type>\<open>cterm\<close>.
 
   \<^descr> \<open>@{thm a}\<close> produces a singleton fact --- as abstract value of type
   \<^ML_type>\<open>thm\<close>.
 
   \<^descr> \<open>@{thms a}\<close> produces a general fact --- as abstract value of type
   \<^ML_type>\<open>thm list\<close>.
 
   \<^descr> \<open>@{lemma \<phi> by meth}\<close> 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 \<^ML_type>\<open>thm\<close> or \<^ML_type>\<open>thm list\<close>, 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>(open)\<close> 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.
 
   \<^descr> \<open>@{oracle_name a}\<close> inlines the internalized oracle name \<open>a\<close> --- as
   \<^ML_type>\<open>string\<close> literal.
 \<close>
 
 
 subsection \<open>Auxiliary connectives \label{sec:logic-aux}\<close>
 
 text \<open>
   Theory \<open>Pure\<close> provides a few auxiliary connectives that are defined on top
   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}
   \<open>conjunction :: prop \<Rightarrow> prop \<Rightarrow> prop\<close> & (infix \<open>&&&\<close>) \\
   \<open>\<turnstile> A &&& B \<equiv> (\<And>C. (A \<Longrightarrow> B \<Longrightarrow> C) \<Longrightarrow> C)\<close> \\[1ex]
   \<open>prop :: prop \<Rightarrow> prop\<close> & (prefix \<open>#\<close>, suppressed) \\
   \<open>#A \<equiv> A\<close> \\[1ex]
   \<open>term :: \<alpha> \<Rightarrow> prop\<close> & (prefix \<open>TERM\<close>) \\
   \<open>term x \<equiv> (\<And>A. A \<Longrightarrow> A)\<close> \\[1ex]
   \<open>type :: \<alpha> itself\<close> & (prefix \<open>TYPE\<close>) \\
   \<open>(unspecified)\<close> \\
   \end{tabular}
   \caption{Definitions of auxiliary connectives}\label{fig:pure-aux}
   \end{center}
   \end{figure}
 
   The introduction \<open>A \<Longrightarrow> B \<Longrightarrow> A &&& B\<close>, and eliminations (projections) \<open>A &&& B
   \<Longrightarrow> A\<close> and \<open>A &&& B \<Longrightarrow> B\<close> are available as derived rules. Conjunction allows to
   treat simultaneous assumptions and conclusions uniformly, e.g.\ consider \<open>A
   \<Longrightarrow> B \<Longrightarrow> C &&& D\<close>. In particular, the goal mechanism represents multiple claims
   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 \<open>prop\<close> marker (\<open>#\<close>) makes arbitrarily complex propositions appear as
   atomic, without changing the meaning: \<open>\<Gamma> \<turnstile> A\<close> and \<open>\<Gamma> \<turnstile> #A\<close> are
   interchangeable. See \secref{sec:tactical-goals} for specific operations.
 
   The \<open>term\<close> marker turns any well-typed term into a derivable proposition: \<open>\<turnstile>
   TERM t\<close> holds unconditionally. Although this is logically vacuous, it allows
   to treat terms and proofs uniformly, similar to a type-theoretic framework.
 
   The \<open>TYPE\<close> constructor is the canonical representative of the unspecified
   type \<open>\<alpha> itself\<close>; it essentially injects the language of types into that of
   terms. There is specific notation \<open>TYPE(\<tau>)\<close> for \<open>TYPE\<^bsub>\<tau> itself\<^esub>\<close>. Although
   being devoid of any particular meaning, the term \<open>TYPE(\<tau>)\<close> accounts for the
   type \<open>\<tau>\<close> within the term language. In particular, \<open>TYPE(\<alpha>)\<close> may be used as
   formal argument in primitive definitions, in order to circumvent hidden
   polymorphism (cf.\ \secref{sec:terms}). For example, \<open>c TYPE(\<alpha>) \<equiv> A[\<alpha>]\<close>
   defines \<open>c :: \<alpha> itself \<Rightarrow> prop\<close> in terms of a proposition \<open>A\<close> that depends on
   an additional type argument, which is essentially a predicate on types.
 \<close>
 
 text %mlref \<open>
   \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}
 
   \<^descr> \<^ML>\<open>Conjunction.intr\<close> derives \<open>A &&& B\<close> from \<open>A\<close> and \<open>B\<close>.
 
   \<^descr> \<^ML>\<open>Conjunction.elim\<close> derives \<open>A\<close> and \<open>B\<close> from \<open>A &&& B\<close>.
 
   \<^descr> \<^ML>\<open>Drule.mk_term\<close> derives \<open>TERM t\<close>.
 
   \<^descr> \<^ML>\<open>Drule.dest_term\<close> recovers term \<open>t\<close> from \<open>TERM t\<close>.
 
   \<^descr> \<^ML>\<open>Logic.mk_type\<close>~\<open>\<tau>\<close> produces the term \<open>TYPE(\<tau>)\<close>.
 
   \<^descr> \<^ML>\<open>Logic.dest_type\<close>~\<open>TYPE(\<tau>)\<close> recovers the type \<open>\<tau>\<close>.
 \<close>
 
 
 subsection \<open>Sort hypotheses\<close>
 
 text \<open>
   Type variables are decorated with sorts, as explained in \secref{sec:types}.
   This constrains type instantiation to certain ranges of types: variable
   \<open>\<alpha>\<^sub>s\<close> may only be assigned to types \<open>\<tau>\<close> that belong to sort \<open>s\<close>. Within the
   logic, sort constraints act like implicit preconditions on the result \<open>\<lparr>\<alpha>\<^sub>1
   : s\<^sub>1\<rparr>, \<dots>, \<lparr>\<alpha>\<^sub>n : s\<^sub>n\<rparr>, \<Gamma> \<turnstile> \<phi>\<close> where the type variables \<open>\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n\<close> cover
   the propositions \<open>\<Gamma>\<close>, \<open>\<phi>\<close>, as well as the proof of \<open>\<Gamma> \<turnstile> \<phi>\<close>.
 
   These \<^emph>\<open>sort hypothesis\<close> 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.\ \<open>\<lparr>\<alpha>\<^sub>s : s\<rparr> \<turnstile> \<phi>\<close>.
   Since such dangling type variables can be renamed arbitrarily without
   changing the proposition \<open>\<phi>\<close>, the inference kernel maintains sort hypotheses
   in anonymous form \<open>s \<turnstile> \<phi>\<close>.
 
   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 \<open>\<tau>\<close> of sort \<open>s\<close> to replace the hypothetical
   type variable \<open>\<alpha>\<^sub>s\<close>.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Thm.extra_shyps: "thm -> sort list"} \\
   @{define_ML Thm.strip_shyps: "thm -> thm"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Thm.extra_shyps\<close>~\<open>thm\<close> determines the extraneous sort hypotheses of
   the given theorem, i.e.\ the sorts that are not present within type
   variables of the statement.
 
   \<^descr> \<^ML>\<open>Thm.strip_shyps\<close>~\<open>thm\<close> removes any extraneous sort hypotheses that
   can be witnessed from the type signature.
 \<close>
 
 text %mlex \<open>
   The following artificial example demonstrates the derivation of \<^prop>\<open>False\<close> with a pending sort hypothesis involving a logically empty sort.
 \<close>
 
 class empty =
   assumes bad: "\<And>(x::'a) y. x \<noteq> y"
 
 theorem (in empty) false: False
   using bad by blast
 
 ML_val \<open>\<^assert> (Thm.extra_shyps @{thm false} = [\<^sort>\<open>empty\<close>])\<close>
 
 text \<open>
   Thanks to the inference kernel managing sort hypothesis according to their
   logical significance, this example is merely an instance of \<^emph>\<open>ex falso
   quodlibet consequitur\<close> --- not a collapse of the logical framework!
 \<close>
 
 
 section \<open>Object-level rules \label{sec:obj-rules}\<close>
 
 text \<open>
   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
   \<^emph>\<open>backchaining\<close>, \<^emph>\<open>higher-order unification\<close> modulo \<open>\<alpha>\<beta>\<eta>\<close>-conversion of
   \<open>\<lambda>\<close>-terms, and so-called \<^emph>\<open>lifting\<close> of rules into a context of \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close>
   connectives. Thus the full power of higher-order Natural Deduction in
   Isabelle/Pure becomes readily available.
 \<close>
 
 
 subsection \<open>Hereditary Harrop Formulae\<close>
 
 text \<open>
   The idea of object-level rules is to model Natural Deduction inferences in
   the style of Gentzen @{cite "Gentzen:1935"}, but we allow arbitrary nesting
   similar to @{cite "Schroeder-Heister:1984"}. The most basic rule format is
   that of a \<^emph>\<open>Horn Clause\<close>:
   \[
   \infer{\<open>A\<close>}{\<open>A\<^sub>1\<close> & \<open>\<dots>\<close> & \<open>A\<^sub>n\<close>}
   \]
   where \<open>A, A\<^sub>1, \<dots>, A\<^sub>n\<close> are atomic propositions of the framework, usually of
   the form \<open>Trueprop B\<close>, where \<open>B\<close> is a (compound) object-level statement.
   This object-level inference corresponds to an iterated implication in Pure
   like this:
   \[
   \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> A\<close>
   \]
   As an example consider conjunction introduction: \<open>A \<Longrightarrow> B \<Longrightarrow> A \<and> B\<close>. Any
   parameters occurring in such rule statements are conceptionally treated as
   arbitrary:
   \[
   \<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>
   \]
 
   Nesting of rules means that the positions of \<open>A\<^sub>i\<close> may again hold compound
   rules, not just atomic propositions. Propositions of this format are called
   \<^emph>\<open>Hereditary Harrop Formulae\<close> in the literature @{cite "Miller:1991"}. Here
   we give an inductive characterization as follows:
 
   \<^medskip>
   \begin{tabular}{ll}
   \<open>\<^bold>x\<close> & set of variables \\
   \<open>\<^bold>A\<close> & set of atomic propositions \\
   \<open>\<^bold>H  =  \<And>\<^bold>x\<^sup>*. \<^bold>H\<^sup>* \<Longrightarrow> \<^bold>A\<close> & set of Hereditary Harrop Formulas \\
   \end{tabular}
   \<^medskip>
 
   Thus we essentially impose nesting levels on propositions formed from \<open>\<And>\<close>
   and \<open>\<Longrightarrow>\<close>. At each level there is a prefix of parameters and compound
   premises, concluding an atomic proposition. Typical examples are
   \<open>\<longrightarrow>\<close>-introduction \<open>(A \<Longrightarrow> B) \<Longrightarrow> A \<longrightarrow> B\<close> or mathematical induction \<open>P 0 \<Longrightarrow> (\<And>n. P n
   \<Longrightarrow> P (Suc n)) \<Longrightarrow> P n\<close>. Even deeper nesting occurs in well-founded induction
   \<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
   rule complexity that is usually seen in practice.
 
   \<^medskip>
   Regular user-level inferences in Isabelle/Pure always maintain the following
   canonical form of results:
 
   \<^item> Normalization by \<open>(A \<Longrightarrow> (\<And>x. B x)) \<equiv> (\<And>x. A \<Longrightarrow> B x)\<close>, 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.
 
   \<^item> The outermost prefix of parameters is represented via schematic variables:
   instead of \<open>\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> A \<^vec>x\<close> we have \<open>\<^vec>H
   ?\<^vec>x \<Longrightarrow> A ?\<^vec>x\<close>. Note that this representation looses information
   about the order of parameters, and vacuous quantifiers vanish automatically.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Simplifier.norm_hhf: "Proof.context -> thm -> thm"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Simplifier.norm_hhf\<close>~\<open>ctxt thm\<close> normalizes the given theorem
   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.
 \<close>
 
 
 subsection \<open>Rule composition\<close>
 
 text \<open>
   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 \<open>\<vartheta>\<close>):
   \[
   \infer[(@{inference_def composition})]{\<open>\<^vec>A\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
   {\<open>\<^vec>A \<Longrightarrow> B\<close> & \<open>B' \<Longrightarrow> C\<close> & \<open>B\<vartheta> = B'\<vartheta>\<close>}
   \]
   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 \<open>C\<close> can again consist of iterated
   implications. We can also permute the premises of the second rule
   back-and-forth in order to compose with \<open>B'\<close> 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 \<open>B\<close>
   and \<open>B'\<close> is not taken into account. For proper @{inference resolution} we
   require \<open>B\<close> to be atomic, and explicitly observe the structure \<open>\<And>\<^vec>x.
   \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x\<close> of the premise of the second rule. The idea
   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})]{\<open>(\<^vec>H \<Longrightarrow> \<^vec>A) \<Longrightarrow> (\<^vec>H \<Longrightarrow> B)\<close>}{\<open>\<^vec>A \<Longrightarrow> B\<close>}
   \]
   \[
   \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>}
   \]
   By combining raw composition with lifting, we get full @{inference
   resolution} as follows:
   \[
   \infer[(@{inference_def resolution})]
   {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>A (?\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
   {\begin{tabular}{l}
     \<open>\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a\<close> \\
     \<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C\<close> \\
     \<open>(\<lambda>\<^vec>x. B (?\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>\<close> \\
    \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})]{\<open>C\<vartheta>\<close>}
   {\<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>)}}
   \]
 
   %FIXME @{inference_def elim_resolution}, @{inference_def dest_resolution}
 \<close>
 
 text %mlref \<open>
   \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}
 
   \<^descr> \<open>rule\<^sub>1 RSN (i, rule\<^sub>2)\<close> resolves the conclusion of \<open>rule\<^sub>1\<close> with the
   \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>, according to the @{inference resolution}
   principle explained above. Unless there is precisely one resolvent it raises
   exception \<^ML>\<open>THM\<close>.
 
   This corresponds to the rule attribute @{attribute THEN} in Isar source
   language.
 
   \<^descr> \<open>rule\<^sub>1 RS rule\<^sub>2\<close> abbreviates \<open>rule\<^sub>1 RSN (1, rule\<^sub>2)\<close>.
 
   \<^descr> \<open>rules\<^sub>1 RLN (i, rules\<^sub>2)\<close> joins lists of rules. For every \<open>rule\<^sub>1\<close> in
   \<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>
   with the \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>, 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 \<^ML>\<open>resolve_tac\<close>.
 
   \<^descr> \<open>rules\<^sub>1 RL rules\<^sub>2\<close> abbreviates \<open>rules\<^sub>1 RLN (1, rules\<^sub>2)\<close>.
 
   \<^descr> \<open>[rule\<^sub>1, \<dots>, rule\<^sub>n] MRS rule\<close> resolves \<open>rule\<^sub>i\<close> against premise \<open>i\<close> of
   \<open>rule\<close>, for \<open>i = n, \<dots>, 1\<close>. By working from right to left, newly emerging
   premises are concatenated in the result, without interfering.
 
   \<^descr> \<open>rule OF rules\<close> is an alternative notation for \<open>rules MRS rule\<close>, which
   makes rule composition look more like function application. Note that the
   argument \<open>rules\<close> need not be atomic.
 
   This corresponds to the rule attribute @{attribute OF} in Isar source
   language.
 \<close>
 
 
 section \<open>Proof terms \label{sec:proof-terms}\<close>
 
 text \<open>
   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 \<^emph>\<open>Curry-Howard isomorphism\<close>, a proof can be
   viewed as a \<open>\<lambda>\<close>-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
   \<open>\<lambda>\<close>-calculus are added, which correspond to \<open>\<And>x :: \<alpha>. B x\<close> and \<open>A \<Longrightarrow> B\<close>
   according to the propositions-as-types principle. The resulting 3-level
   \<open>\<lambda>\<close>-calculus resembles ``\<open>\<lambda>HOL\<close>'' in the more abstract setting of Pure Type
   Systems (PTS) @{cite "Barendregt-Geuvers:2001"}, if some fine points like
   schematic polymorphism and type classes are ignored.
 
   \<^medskip>
   \<^emph>\<open>Proof abstractions\<close> of the form \<open>\<^bold>\<lambda>x :: \<alpha>. prf\<close> or \<open>\<^bold>\<lambda>p : A. prf\<close>
   correspond to introduction of \<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>, and \<^emph>\<open>proof applications\<close> of the form
   \<open>p \<cdot> t\<close> or \<open>p \<bullet> q\<close> correspond to elimination of \<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>. Actual types \<open>\<alpha>\<close>,
   propositions \<open>A\<close>, and terms \<open>t\<close> might be suppressed and reconstructed from
   the overall proof term.
 
   \<^medskip>
   Various atomic proofs indicate special situations within the proof
   construction as follows.
 
   A \<^emph>\<open>bound proof variable\<close> is a natural number \<open>b\<close> that acts as de-Bruijn
   index for proof term abstractions.
 
   A \<^emph>\<open>minimal proof\<close> ``\<open>?\<close>'' is a dummy proof term. This indicates some
   unrecorded part of the proof.
 
   \<open>Hyp A\<close> 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 \<^emph>\<open>axiom\<close> or \<^emph>\<open>oracle\<close> \<open>a : A[\<^vec>\<tau>]\<close> refers some postulated \<open>proof
   constant\<close>, which is subject to schematic polymorphism of theory content, and
   the particular type instantiation may be given explicitly. The vector of
   types \<open>\<^vec>\<tau>\<close> refers to the schematic type variables in the generic
   proposition \<open>A\<close> in canonical order.
 
   A \<^emph>\<open>proof promise\<close> \<open>a : A[\<^vec>\<tau>]\<close> is a placeholder for some proof of
   polymorphic proposition \<open>A\<close>, with explicit type instantiation as given by
   the vector \<open>\<^vec>\<tau>\<close>, as above. Unlike axioms or oracles, proof promises
   may be \<^emph>\<open>fulfilled\<close> eventually, by substituting \<open>a\<close> by some particular proof
   \<open>q\<close> at the corresponding type instance. This acts like Hindley-Milner
   \<open>let\<close>-polymorphism: a generic local proof definition may get used at
   different type instances, and is replaced by the concrete instance
   eventually.
 
   A \<^emph>\<open>named theorem\<close> wraps up some concrete proof as a closed formal entity,
   in the manner of constant definitions for proof terms. The \<^emph>\<open>proof body\<close> 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.
 \<close>
 
 
 subsection \<open>Reconstructing and checking proof terms\<close>
 
 text \<open>
   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 \<^emph>\<open>implicit\<close> proof terms, by
   omitting all typing information in terms, all term and type labels of proof
   abstractions, and some argument terms of applications \<open>p \<cdot> t\<close> (if possible).
 
   There are separate operations to reconstruct the full proof term later on,
   using \<^emph>\<open>higher-order pattern unification\<close> @{cite "nipkow-patterns" and
   "Berghofer-Nipkow:2000:TPHOL"}.
 
   The \<^emph>\<open>proof checker\<close> expects a fully reconstructed proof term, and can turn
   it into a theorem by replaying its primitive inferences within the kernel.
 \<close>
 
 
 subsection \<open>Concrete syntax of proof terms\<close>
 
 text \<open>
   The concrete syntax of proof terms is a slight extension of the regular
   inner syntax of Isabelle/Pure @{cite "isabelle-isar-ref"}. Its main
   syntactic category @{syntax (inner) proof} is defined as follows:
 
   \begin{center}
   \begin{supertabular}{rclr}
 
   @{syntax_def (inner) proof} & = & \<open>\<^bold>\<lambda>\<close> \<open>params\<close> \<^verbatim>\<open>.\<close> \<open>proof\<close> \\
     & \<open>|\<close> & \<open>proof\<close> \<open>\<cdot>\<close> \<open>any\<close> \\
     & \<open>|\<close> & \<open>proof\<close> \<open>\<bullet>\<close> \<open>proof\<close> \\
     & \<open>|\<close> & \<open>id  |  longid\<close> \\
   \\
 
   \<open>param\<close> & = & \<open>idt\<close> \\
     & \<open>|\<close> & \<open>idt\<close> \<^verbatim>\<open>:\<close> \<open>prop\<close> \\
     & \<open>|\<close> & \<^verbatim>\<open>(\<close> \<open>param\<close> \<^verbatim>\<open>)\<close> \\
   \\
 
   \<open>params\<close> & = & \<open>param\<close> \\
     & \<open>|\<close> & \<open>param\<close> \<open>params\<close> \\
 
   \end{supertabular}
   \end{center}
 
   Implicit term arguments in partial proofs are indicated by ``\<open>_\<close>''. Type
   arguments for theorems and axioms may be specified using \<open>p \<cdot> TYPE(type)\<close>
   (they must appear before any other term argument of a theorem or axiom, but
   may be omitted altogether).
 
   \<^medskip>
   There are separate read and print operations for proof terms, in order to
   avoid conflicts with the regular term language.
 \<close>
 
 text %mlref \<open>
   \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 -> string 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}
 
   \<^descr> Type \<^ML_type>\<open>proof\<close> represents proof terms; this is a datatype with
   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 (!?)
 
   \<^descr> Type \<^ML_type>\<open>proof_body\<close> 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 \<^ML>\<open>Proofterm.fold_body_thms\<close>).
 
   \<^descr> \<^ML>\<open>Thm.proof_of\<close>~\<open>thm\<close> and \<^ML>\<open>Thm.proof_body_of\<close>~\<open>thm\<close> 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.
 
   \<^descr> \<^ML>\<open>Proofterm.proofs\<close> specifies the detail of proof recording within
   \<^ML_type>\<open>thm\<close> values produced by the inference kernel: \<^ML>\<open>0\<close> records only
   the names of oracles, \<^ML>\<open>1\<close> records oracle names and propositions, \<^ML>\<open>2\<close>
   additionally records full proof terms. Officially named theorems that
   contribute to a result are recorded in any case.
 
   \<^descr> \<^ML>\<open>Proofterm.reconstruct_proof\<close>~\<open>thy prop prf\<close> turns the implicit
   proof term \<open>prf\<close> into a full proof of the given proposition.
 
   Reconstruction may fail if \<open>prf\<close> is not a proof of \<open>prop\<close>, 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.
 
   \<^descr> \<^ML>\<open>Proofterm.expand_proof\<close>~\<open>thy expand prf\<close> reconstructs and expands
   the proofs of nested theorems according to the given \<open>expand\<close> function: a
   result of @{ML \<open>SOME ""\<close>} means full expansion, @{ML \<open>SOME\<close>}~\<open>name\<close> means to
   keep the theorem node but replace its internal name, @{ML NONE} means no
   change.
 
   \<^descr> \<^ML>\<open>Proof_Checker.thm_of_proof\<close>~\<open>thy prf\<close> turns the given (full) proof
   into a theorem, by replaying it using only primitive rules of the inference
   kernel.
 
   \<^descr> \<^ML>\<open>Proof_Syntax.read_proof\<close>~\<open>thy b\<^sub>1 b\<^sub>2 s\<close> 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!?
 
   \<^descr> \<^ML>\<open>Proof_Syntax.pretty_proof\<close>~\<open>ctxt prf\<close> pretty-prints the given proof
   term.
 \<close>
 
 text %mlex \<open>
   \<^item> \<^file>\<open>~~/src/HOL/Proofs/ex/Proof_Terms.thy\<close> provides basic examples involving
   proof terms.
 
   \<^item> \<^file>\<open>~~/src/HOL/Proofs/ex/XML_Data.thy\<close> demonstrates export and import of
   proof terms via XML/ML data representation.
 \<close>
 
 end
diff --git a/src/Doc/Implementation/ML.thy b/src/Doc/Implementation/ML.thy
--- a/src/Doc/Implementation/ML.thy
+++ b/src/Doc/Implementation/ML.thy
@@ -1,2211 +1,2211 @@
 (*:maxLineLen=78:*)
 
 theory "ML"
 imports Base
 begin
 
 chapter \<open>Isabelle/ML\<close>
 
 text \<open>
   Isabelle/ML is best understood as a certain culture based on Standard ML.
   Thus it is not a new programming language, but a certain way to use SML at
   an advanced level within the Isabelle environment. This covers a variety of
   aspects that are geared towards an efficient and robust platform for
   applications of formal logic with fully foundational proof construction ---
   according to the well-known \<^emph>\<open>LCF principle\<close>. There is specific
   infrastructure with library modules to address the needs of this difficult
   task. For example, the raw parallel programming model of Poly/ML is
   presented as considerably more abstract concept of \<^emph>\<open>futures\<close>, which is then
   used to augment the inference kernel, Isar theory and proof interpreter, and
   PIDE document management.
 
   The main aspects of Isabelle/ML are introduced below. These first-hand
   explanations should help to understand how proper Isabelle/ML is to be read
   and written, and to get access to the wealth of experience that is expressed
   in the source text and its history of changes.\<^footnote>\<open>See
   \<^url>\<open>https://isabelle.in.tum.de/repos/isabelle\<close> for the full Mercurial history.
   There are symbolic tags to refer to official Isabelle releases, as opposed
   to arbitrary \<^emph>\<open>tip\<close> versions that merely reflect snapshots that are never
   really up-to-date.\<close>
 \<close>
 
 
 section \<open>Style and orthography\<close>
 
 text \<open>
   The sources of Isabelle/Isar are optimized for \<^emph>\<open>readability\<close> and
   \<^emph>\<open>maintainability\<close>. The main purpose is to tell an informed reader what is
   really going on and how things really work. This is a non-trivial aim, but
   it is supported by a certain style of writing Isabelle/ML that has emerged
   from long years of system development.\<^footnote>\<open>See also the interesting style guide
   for OCaml \<^url>\<open>https://caml.inria.fr/resources/doc/guides/guidelines.en.html\<close>
   which shares many of our means and ends.\<close>
 
   The main principle behind any coding style is \<^emph>\<open>consistency\<close>. For a single
   author of a small program this merely means ``choose your style and stick to
   it''. A complex project like Isabelle, with long years of development and
   different contributors, requires more standardization. A coding style that
   is changed every few years or with every new contributor is no style at all,
   because consistency is quickly lost. Global consistency is hard to achieve,
   though. Nonetheless, one should always strive at least for local consistency
   of modules and sub-systems, without deviating from some general principles
   how to write Isabelle/ML.
 
   In a sense, good coding style is like an \<^emph>\<open>orthography\<close> for the sources: it
   helps to read quickly over the text and see through the main points, without
   getting distracted by accidental presentation of free-style code.
 \<close>
 
 
 subsection \<open>Header and sectioning\<close>
 
 text \<open>
   Isabelle source files have a certain standardized header format (with
   precise spacing) that follows ancient traditions reaching back to the
   earliest versions of the system by Larry Paulson. See
   \<^file>\<open>~~/src/Pure/thm.ML\<close>, for example.
 
   The header includes at least \<^verbatim>\<open>Title\<close> and \<^verbatim>\<open>Author\<close> entries, followed by a
   prose description of the purpose of the module. The latter can range from a
   single line to several paragraphs of explanations.
 
   The rest of the file is divided into chapters, sections, subsections,
   subsubsections, paragraphs etc.\ using a simple layout via ML comments as
   follows.
 
   @{verbatim [display]
 \<open>  (**** chapter ****)
  
   (*** section ***)
 
   (** subsection **)
 
   (* subsubsection *)
 
   (*short paragraph*)
 
   (*
     long paragraph,
     with more text
   *)\<close>}
 
   As in regular typography, there is some extra space \<^emph>\<open>before\<close> section
   headings that are adjacent to plain text, but not other headings as in the
   example above.
 
   \<^medskip>
   The precise wording of the prose text given in these headings is chosen
   carefully to introduce the main theme of the subsequent formal ML text.
 \<close>
 
 
 subsection \<open>Naming conventions\<close>
 
 text \<open>
   Since ML is the primary medium to express the meaning of the source text,
   naming of ML entities requires special care.
 \<close>
 
 paragraph \<open>Notation.\<close>
 text \<open>
   A name consists of 1--3 \<^emph>\<open>words\<close> (rarely 4, but not more) that are separated
   by underscore. There are three variants concerning upper or lower case
   letters, which are used for certain ML categories as follows:
 
   \<^medskip>
   \begin{tabular}{lll}
   variant & example & ML categories \\\hline
   lower-case & \<^ML_text>\<open>foo_bar\<close> & values, types, record fields \\
   capitalized & \<^ML_text>\<open>Foo_Bar\<close> & datatype constructors, structures, functors \\
   upper-case & \<^ML_text>\<open>FOO_BAR\<close> & special values, exception constructors, signatures \\
   \end{tabular}
   \<^medskip>
 
   For historical reasons, many capitalized names omit underscores, e.g.\
   old-style \<^ML_text>\<open>FooBar\<close> instead of \<^ML_text>\<open>Foo_Bar\<close>. Genuine
   mixed-case names are \<^emph>\<open>not\<close> used, because clear division of words is
   essential for readability.\<^footnote>\<open>Camel-case was invented to workaround the lack
   of underscore in some early non-ASCII character sets. Later it became
   habitual in some language communities that are now strong in numbers.\<close>
 
   A single (capital) character does not count as ``word'' in this respect:
   some Isabelle/ML names are suffixed by extra markers like this: \<^ML_text>\<open>foo_barT\<close>.
 
   Name variants are produced by adding 1--3 primes, e.g.\ \<^ML_text>\<open>foo'\<close>,
   \<^ML_text>\<open>foo''\<close>, or \<^ML_text>\<open>foo'''\<close>, but not \<^ML_text>\<open>foo''''\<close> or more.
   Decimal digits scale better to larger numbers, e.g.\ \<^ML_text>\<open>foo0\<close>,
   \<^ML_text>\<open>foo1\<close>, \<^ML_text>\<open>foo42\<close>.
 \<close>
 
 paragraph \<open>Scopes.\<close>
 text \<open>
   Apart from very basic library modules, ML structures are not ``opened'', but
   names are referenced with explicit qualification, as in \<^ML>\<open>Syntax.string_of_term\<close> for example. When devising names for structures and
   their components it is important to aim at eye-catching compositions of both
   parts, because this is how they are seen in the sources and documentation.
   For the same reasons, aliases of well-known library functions should be
   avoided.
 
   Local names of function abstraction or case/let bindings are typically
   shorter, sometimes using only rudiments of ``words'', while still avoiding
   cryptic shorthands. An auxiliary function called \<^ML_text>\<open>helper\<close>,
   \<^ML_text>\<open>aux\<close>, or \<^ML_text>\<open>f\<close> is considered bad style.
 
   Example:
 
   @{verbatim [display]
 \<open>  (* RIGHT *)
 
   fun print_foo ctxt foo =
     let
       fun print t = ... Syntax.string_of_term ctxt t ...
     in ... end;
 
 
   (* RIGHT *)
 
   fun print_foo ctxt foo =
     let
       val string_of_term = Syntax.string_of_term ctxt;
       fun print t = ... string_of_term t ...
     in ... end;
 
 
   (* WRONG *)
 
   val string_of_term = Syntax.string_of_term;
 
   fun print_foo ctxt foo =
     let
       fun aux t = ... string_of_term ctxt t ...
     in ... end;\<close>}
 \<close>
 
 paragraph \<open>Specific conventions.\<close>
 text \<open>
   Here are some specific name forms that occur frequently in the sources.
 
   \<^item> A function that maps \<^ML_text>\<open>foo\<close> to \<^ML_text>\<open>bar\<close> is called \<^ML_text>\<open>foo_to_bar\<close> or \<^ML_text>\<open>bar_of_foo\<close> (never \<^ML_text>\<open>foo2bar\<close>, nor
   \<^ML_text>\<open>bar_from_foo\<close>, nor \<^ML_text>\<open>bar_for_foo\<close>, nor \<^ML_text>\<open>bar4foo\<close>).
 
   \<^item> The name component \<^ML_text>\<open>legacy\<close> means that the operation is about to
   be discontinued soon.
 
   \<^item> The name component \<^ML_text>\<open>global\<close> means that this works with the
   background theory instead of the regular local context
   (\secref{sec:context}), sometimes for historical reasons, sometimes due a
   genuine lack of locality of the concept involved, sometimes as a fall-back
   for the lack of a proper context in the application code. Whenever there is
   a non-global variant available, the application should be migrated to use it
   with a proper local context.
 
   \<^item> Variables of the main context types of the Isabelle/Isar framework
   (\secref{sec:context} and \chref{ch:local-theory}) have firm naming
   conventions as follows:
 
     \<^item> theories are called \<^ML_text>\<open>thy\<close>, rarely \<^ML_text>\<open>theory\<close>
     (never \<^ML_text>\<open>thry\<close>)
 
     \<^item> proof contexts are called \<^ML_text>\<open>ctxt\<close>, rarely \<^ML_text>\<open>context\<close> (never \<^ML_text>\<open>ctx\<close>)
 
     \<^item> generic contexts are called \<^ML_text>\<open>context\<close>
 
     \<^item> local theories are called \<^ML_text>\<open>lthy\<close>, except for local
     theories that are treated as proof context (which is a semantic
     super-type)
 
   Variations with primed or decimal numbers are always possible, as well as
   semantic prefixes like \<^ML_text>\<open>foo_thy\<close> or \<^ML_text>\<open>bar_ctxt\<close>, but the
   base conventions above need to be preserved. This allows to emphasize their
   data flow via plain regular expressions in the text editor.
 
   \<^item> The main logical entities (\secref{ch:logic}) have established naming
   convention as follows:
 
     \<^item> sorts are called \<^ML_text>\<open>S\<close>
 
     \<^item> types are called \<^ML_text>\<open>T\<close>, \<^ML_text>\<open>U\<close>, or \<^ML_text>\<open>ty\<close> (never
     \<^ML_text>\<open>t\<close>)
 
     \<^item> terms are called \<^ML_text>\<open>t\<close>, \<^ML_text>\<open>u\<close>, or \<^ML_text>\<open>tm\<close> (never
     \<^ML_text>\<open>trm\<close>)
 
     \<^item> certified types are called \<^ML_text>\<open>cT\<close>, rarely \<^ML_text>\<open>T\<close>, with
     variants as for types
 
     \<^item> certified terms are called \<^ML_text>\<open>ct\<close>, rarely \<^ML_text>\<open>t\<close>, with
     variants as for terms (never \<^ML_text>\<open>ctrm\<close>)
 
     \<^item> theorems are called \<^ML_text>\<open>th\<close>, or \<^ML_text>\<open>thm\<close>
 
   Proper semantic names override these conventions completely. For example,
   the left-hand side of an equation (as a term) can be called \<^ML_text>\<open>lhs\<close>
   (not \<^ML_text>\<open>lhs_tm\<close>). Or a term that is known to be a variable can be
   called \<^ML_text>\<open>v\<close> or \<^ML_text>\<open>x\<close>.
 
   \<^item> Tactics (\secref{sec:tactics}) are sufficiently important to have specific
   naming conventions. The name of a basic tactic definition always has a
   \<^ML_text>\<open>_tac\<close> suffix, the subgoal index (if applicable) is always called
   \<^ML_text>\<open>i\<close>, and the goal state (if made explicit) is usually called
   \<^ML_text>\<open>st\<close> instead of the somewhat misleading \<^ML_text>\<open>thm\<close>. Any other
   arguments are given before the latter two, and the general context is given
   first. Example:
 
   @{verbatim [display] \<open>  fun my_tac ctxt arg1 arg2 i st = ...\<close>}
 
   Note that the goal state \<^ML_text>\<open>st\<close> above is rarely made explicit, if
   tactic combinators (tacticals) are used as usual.
 
   A tactic that requires a proof context needs to make that explicit as seen
   in the \<^verbatim>\<open>ctxt\<close> argument above. Do not refer to the background theory of
   \<^verbatim>\<open>st\<close> -- it is not a proper context, but merely a formal certificate.
 \<close>
 
 
 subsection \<open>General source layout\<close>
 
 text \<open>
   The general Isabelle/ML source layout imitates regular type-setting
   conventions, augmented by the requirements for deeply nested expressions
   that are commonplace in functional programming.
 \<close>
 
 paragraph \<open>Line length\<close>
 text \<open>
   is limited to 80 characters according to ancient standards, but we allow as
   much as 100 characters (not more).\<^footnote>\<open>Readability requires to keep the
   beginning of a line in view while watching its end. Modern wide-screen
   displays do not change the way how the human brain works. Sources also need
   to be printable on plain paper with reasonable font-size.\<close> The extra 20
   characters acknowledge the space requirements due to qualified library
   references in Isabelle/ML.
 \<close>
 
 paragraph \<open>White-space\<close>
 text \<open>
   is used to emphasize the structure of expressions, following mostly standard
   conventions for mathematical typesetting, as can be seen in plain {\TeX} or
   {\LaTeX}. This defines positioning of spaces for parentheses, punctuation,
   and infixes as illustrated here:
 
   @{verbatim [display]
 \<open>  val x = y + z * (a + b);
   val pair = (a, b);
   val record = {foo = 1, bar = 2};\<close>}
 
   Lines are normally broken \<^emph>\<open>after\<close> an infix operator or punctuation
   character. For example:
 
   @{verbatim [display]
 \<open>
   val x =
     a +
     b +
     c;
 
   val tuple =
    (a,
     b,
     c);
 \<close>}
 
   Some special infixes (e.g.\ \<^ML_text>\<open>|>\<close>) work better at the start of the
   line, but punctuation is always at the end.
 
   Function application follows the tradition of \<open>\<lambda>\<close>-calculus, not informal
   mathematics. For example: \<^ML_text>\<open>f a b\<close> for a curried function, or
   \<^ML_text>\<open>g (a, b)\<close> for a tupled function. Note that the space between
   \<^ML_text>\<open>g\<close> and the pair \<^ML_text>\<open>(a, b)\<close> follows the important
   principle of \<^emph>\<open>compositionality\<close>: the layout of \<^ML_text>\<open>g p\<close> does not
   change when \<^ML_text>\<open>p\<close> is refined to the concrete pair \<^ML_text>\<open>(a,
   b)\<close>.
 \<close>
 
 paragraph \<open>Indentation\<close>
 text \<open>
   uses plain spaces, never hard tabulators.\<^footnote>\<open>Tabulators were invented to move
   the carriage of a type-writer to certain predefined positions. In software
   they could be used as a primitive run-length compression of consecutive
   spaces, but the precise result would depend on non-standardized text editor
   configuration.\<close>
 
   Each level of nesting is indented by 2 spaces, sometimes 1, very rarely 4,
   never 8 or any other odd number.
 
   Indentation follows a simple logical format that only depends on the nesting
   depth, not the accidental length of the text that initiates a level of
   nesting. Example:
 
   @{verbatim [display]
 \<open>  (* RIGHT *)
 
   if b then
     expr1_part1
     expr1_part2
   else
     expr2_part1
     expr2_part2
 
 
   (* WRONG *)
 
   if b then expr1_part1
             expr1_part2
   else expr2_part1
        expr2_part2\<close>}
 
   The second form has many problems: it assumes a fixed-width font when
   viewing the sources, it uses more space on the line and thus makes it hard
   to observe its strict length limit (working against \<^emph>\<open>readability\<close>), it
   requires extra editing to adapt the layout to changes of the initial text
   (working against \<^emph>\<open>maintainability\<close>) etc.
 
   \<^medskip>
   For similar reasons, any kind of two-dimensional or tabular layouts,
   ASCII-art with lines or boxes of asterisks etc.\ should be avoided.
 \<close>
 
 paragraph \<open>Complex expressions\<close>
 text \<open>
   that consist of multi-clausal function definitions, \<^ML_text>\<open>handle\<close>,
   \<^ML_text>\<open>case\<close>, \<^ML_text>\<open>let\<close> (and combinations) require special
   attention. The syntax of Standard ML is quite ambitious and admits a lot of
   variance that can distort the meaning of the text.
 
   Multiple clauses of \<^ML_text>\<open>fun\<close>, \<^ML_text>\<open>fn\<close>, \<^ML_text>\<open>handle\<close>,
   \<^ML_text>\<open>case\<close> get extra indentation to indicate the nesting clearly.
   Example:
 
   @{verbatim [display]
 \<open>  (* RIGHT *)
 
   fun foo p1 =
         expr1
     | foo p2 =
         expr2
 
 
   (* WRONG *)
 
   fun foo p1 =
     expr1
     | foo p2 =
     expr2\<close>}
 
   Body expressions consisting of \<^ML_text>\<open>case\<close> or \<^ML_text>\<open>let\<close> require
   care to maintain compositionality, to prevent loss of logical indentation
   where it is especially important to see the structure of the text. Example:
 
   @{verbatim [display]
 \<open>  (* RIGHT *)
 
   fun foo p1 =
         (case e of
           q1 => ...
         | q2 => ...)
     | foo p2 =
         let
           ...
         in
           ...
         end
 
 
   (* WRONG *)
 
   fun foo p1 = case e of
       q1 => ...
     | q2 => ...
     | foo p2 =
     let
       ...
     in
       ...
     end\<close>}
 
   Extra parentheses around \<^ML_text>\<open>case\<close> expressions are optional, but help
   to analyse the nesting based on character matching in the text editor.
 
   \<^medskip>
   There are two main exceptions to the overall principle of compositionality
   in the layout of complex expressions.
 
   \<^enum> \<^ML_text>\<open>if\<close> expressions are iterated as if ML had multi-branch
   conditionals, e.g.
 
   @{verbatim [display]
 \<open>  (* RIGHT *)
 
   if b1 then e1
   else if b2 then e2
   else e3\<close>}
 
   \<^enum> \<^ML_text>\<open>fn\<close> abstractions are often layed-out as if they would lack any
   structure by themselves. This traditional form is motivated by the
   possibility to shift function arguments back and forth wrt.\ additional
   combinators. Example:
 
   @{verbatim [display]
 \<open>  (* RIGHT *)
 
   fun foo x y = fold (fn z =>
     expr)\<close>}
 
   Here the visual appearance is that of three arguments \<^ML_text>\<open>x\<close>,
   \<^ML_text>\<open>y\<close>, \<^ML_text>\<open>z\<close> in a row.
 
 
   Such weakly structured layout should be use with great care. Here are some
   counter-examples involving \<^ML_text>\<open>let\<close> expressions:
 
   @{verbatim [display]
 \<open>  (* WRONG *)
 
   fun foo x = let
       val y = ...
     in ... end
 
 
   (* WRONG *)
 
   fun foo x = let
     val y = ...
   in ... end
 
 
   (* WRONG *)
 
   fun foo x =
   let
     val y = ...
   in ... end
 
 
   (* WRONG *)
 
   fun foo x =
     let
       val y = ...
     in
       ... end\<close>}
 
   \<^medskip>
   In general the source layout is meant to emphasize the structure of complex
   language expressions, not to pretend that SML had a completely different
   syntax (say that of Haskell, Scala, Java).
 \<close>
 
 
 section \<open>ML embedded into Isabelle/Isar\<close>
 
 text \<open>
   ML and Isar are intertwined via an open-ended bootstrap process that
   provides more and more programming facilities and logical content in an
   alternating manner. Bootstrapping starts from the raw environment of
   existing implementations of Standard ML (mainly Poly/ML).
 
   Isabelle/Pure marks the point where the raw ML toplevel is superseded by
   Isabelle/ML within the Isar theory and proof language, with a uniform
   context for arbitrary ML values (see also \secref{sec:context}). This formal
   environment holds ML compiler bindings, logical entities, and many other
   things.
 
   Object-logics like Isabelle/HOL are built within the Isabelle/ML/Isar
   environment by introducing suitable theories with associated ML modules,
   either inlined within \<^verbatim>\<open>.thy\<close> files, or as separate \<^verbatim>\<open>.ML\<close> files that are
   loading from some theory. Thus Isabelle/HOL is defined as a regular
   user-space application within the Isabelle framework. Further add-on tools
   can be implemented in ML within the Isar context in the same manner: ML is
   part of the standard repertoire of Isabelle, and there is no distinction
   between ``users'' and ``developers'' in this respect.
 \<close>
 
 
 subsection \<open>Isar ML commands\<close>
 
 text \<open>
   The primary Isar source language provides facilities to ``open a window'' to
   the underlying ML compiler. Especially see the Isar commands @{command_ref
   "ML_file"} and @{command_ref "ML"}: both work the same way, but the source
   text is provided differently, via a file vs.\ inlined, respectively. Apart
   from embedding ML into the main theory definition like that, there are many
   more commands that refer to ML source, such as @{command_ref setup} or
   @{command_ref declaration}. Even more fine-grained embedding of ML into Isar
   is encountered in the proof method @{method_ref tactic}, which refines the
   pending goal state via a given expression of type \<^ML_type>\<open>tactic\<close>.
 \<close>
 
 text %mlex \<open>
   The following artificial example demonstrates some ML toplevel declarations
   within the implicit Isar theory context. This is regular functional
   programming without referring to logical entities yet.
 \<close>
 
 ML \<open>
   fun factorial 0 = 1
     | factorial n = n * factorial (n - 1)
 \<close>
 
 text \<open>
   Here the ML environment is already managed by Isabelle, i.e.\ the \<^ML>\<open>factorial\<close> function is not yet accessible in the preceding paragraph, nor in
   a different theory that is independent from the current one in the import
   hierarchy.
 
   Removing the above ML declaration from the source text will remove any trace
   of this definition, as expected. The Isabelle/ML toplevel environment is
   managed in a \<^emph>\<open>stateless\<close> way: in contrast to the raw ML toplevel, there are
   no global side-effects involved here.\<^footnote>\<open>Such a stateless compilation
   environment is also a prerequisite for robust parallel compilation within
   independent nodes of the implicit theory development graph.\<close>
 
   \<^medskip>
   The next example shows how to embed ML into Isar proofs, using @{command_ref
   "ML_prf"} instead of @{command_ref "ML"}. As illustrated below, the effect
   on the ML environment is local to the whole proof body, but ignoring the
   block structure.
 \<close>
 
 notepad
 begin
   ML_prf %"ML" \<open>val a = 1\<close>
   {
     ML_prf %"ML" \<open>val b = a + 1\<close>
   } \<comment> \<open>Isar block structure ignored by ML environment\<close>
   ML_prf %"ML" \<open>val c = b + 1\<close>
 end
 
 text \<open>
   By side-stepping the normal scoping rules for Isar proof blocks, embedded ML
   code can refer to the different contexts and manipulate corresponding
   entities, e.g.\ export a fact from a block context.
 
   \<^medskip>
   Two further ML commands are useful in certain situations: @{command_ref
   ML_val} and @{command_ref ML_command} are \<^emph>\<open>diagnostic\<close> in the sense that
   there is no effect on the underlying environment, and can thus be used
   anywhere. The examples below produce long strings of digits by invoking \<^ML>\<open>factorial\<close>: @{command ML_val} takes care of printing the ML toplevel result,
   but @{command ML_command} is silent so we produce an explicit output
   message.
 \<close>
 
 ML_val \<open>factorial 100\<close>
 ML_command \<open>writeln (string_of_int (factorial 100))\<close>
 
 notepad
 begin
   ML_val \<open>factorial 100\<close>
   ML_command \<open>writeln (string_of_int (factorial 100))\<close>
 end
 
 
 subsection \<open>Compile-time context\<close>
 
 text \<open>
   Whenever the ML compiler is invoked within Isabelle/Isar, the formal context
   is passed as a thread-local reference variable. Thus ML code may access the
   theory context during compilation, by reading or writing the (local) theory
   under construction. Note that such direct access to the compile-time context
   is rare. In practice it is typically done via some derived ML functions
   instead.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Context.the_generic_context: "unit -> Context.generic"} \\
   @{define_ML "Context.>>": "(Context.generic -> Context.generic) -> unit"} \\
   @{define_ML ML_Thms.bind_thms: "string * thm list -> unit"} \\
   @{define_ML ML_Thms.bind_thm: "string * thm -> unit"} \\
   \end{mldecls}
 
     \<^descr> \<^ML>\<open>Context.the_generic_context ()\<close> refers to the theory context of
     the ML toplevel --- at compile time. ML code needs to take care to refer to
     \<^ML>\<open>Context.the_generic_context ()\<close> correctly. Recall that evaluation
     of a function body is delayed until actual run-time.
 
     \<^descr> \<^ML>\<open>Context.>>\<close>~\<open>f\<close> applies context transformation \<open>f\<close> to the implicit
     context of the ML toplevel.
 
     \<^descr> \<^ML>\<open>ML_Thms.bind_thms\<close>~\<open>(name, thms)\<close> stores a list of theorems produced
     in ML both in the (global) theory context and the ML toplevel, associating
     it with the provided name.
 
     \<^descr> \<^ML>\<open>ML_Thms.bind_thm\<close> is similar to \<^ML>\<open>ML_Thms.bind_thms\<close> but refers to
     a singleton fact.
 
   It is important to note that the above functions are really restricted to
   the compile time, even though the ML compiler is invoked at run-time. The
   majority of ML code either uses static antiquotations
   (\secref{sec:ML-antiq}) or refers to the theory or proof context at
   run-time, by explicit functional abstraction.
 \<close>
 
 
 subsection \<open>Antiquotations \label{sec:ML-antiq}\<close>
 
 text \<open>
   A very important consequence of embedding ML into Isar is the concept of
   \<^emph>\<open>ML antiquotation\<close>. The standard token language of ML is augmented by
   special syntactic entities of the following form:
 
   \<^rail>\<open>
   @{syntax_def antiquote}: '@{' name args '}'
   \<close>
 
   Here @{syntax name} and @{syntax args} are outer syntax categories, as
   defined in @{cite "isabelle-isar-ref"}.
 
   \<^medskip>
   A regular antiquotation \<open>@{name args}\<close> processes its arguments by the usual
   means of the Isar source language, and produces corresponding ML source
   text, either as literal \<^emph>\<open>inline\<close> text (e.g.\ \<open>@{term t}\<close>) or abstract
   \<^emph>\<open>value\<close> (e.g. \<open>@{thm th}\<close>). This pre-compilation scheme allows to refer to
   formal entities in a robust manner, with proper static scoping and with some
   degree of logical checking of small portions of the code.
 \<close>
 
 
 subsection \<open>Printing ML values\<close>
 
 text \<open>
   The ML compiler knows about the structure of values according to their
   static type, and can print them in the manner of its toplevel, although the
   details are non-portable. The antiquotations @{ML_antiquotation_def
   "make_string"} and @{ML_antiquotation_def "print"} provide a quasi-portable
   way to refer to this potential capability of the underlying ML system in
   generic Isabelle/ML sources.
 
   This is occasionally useful for diagnostic or demonstration purposes. Note
   that production-quality tools require proper user-level error messages,
   avoiding raw ML values in the output.
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "make_string"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "print"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
   @@{ML_antiquotation make_string}
   ;
   @@{ML_antiquotation print} embedded?
   \<close>
 
   \<^descr> \<open>@{make_string}\<close> inlines a function to print arbitrary values similar to
   the ML toplevel. The result is compiler dependent and may fall back on "?"
   in certain situations. The value of configuration option @{attribute_ref
   ML_print_depth} determines further details of output.
 
   \<^descr> \<open>@{print f}\<close> uses the ML function \<open>f: string -> unit\<close> to output the result
   of \<open>@{make_string}\<close> above, together with the source position of the
   antiquotation. The default output function is \<^ML>\<open>writeln\<close>.
 \<close>
 
 text %mlex \<open>
   The following artificial examples show how to produce adhoc output of ML
   values for debugging purposes.
 \<close>
 
 ML_val \<open>
   val x = 42;
   val y = true;
 
   writeln (\<^make_string> {x = x, y = y});
 
   \<^print> {x = x, y = y};
   \<^print>\<open>tracing\<close> {x = x, y = y};
 \<close>
 
 
 section \<open>Canonical argument order \label{sec:canonical-argument-order}\<close>
 
 text \<open>
   Standard ML is a language in the tradition of \<open>\<lambda>\<close>-calculus and
   \<^emph>\<open>higher-order functional programming\<close>, similar to OCaml, Haskell, or
   Isabelle/Pure and HOL as logical languages. Getting acquainted with the
   native style of representing functions in that setting can save a lot of
   extra boiler-plate of redundant shuffling of arguments, auxiliary
   abstractions etc.
 
   Functions are usually \<^emph>\<open>curried\<close>: the idea of turning arguments of type
   \<open>\<tau>\<^sub>i\<close> (for \<open>i \<in> {1, \<dots> n}\<close>) into a result of type \<open>\<tau>\<close> is represented by the
   iterated function space \<open>\<tau>\<^sub>1 \<rightarrow> \<dots> \<rightarrow> \<tau>\<^sub>n \<rightarrow> \<tau>\<close>. This is isomorphic to the
   well-known encoding via tuples \<open>\<tau>\<^sub>1 \<times> \<dots> \<times> \<tau>\<^sub>n \<rightarrow> \<tau>\<close>, but the curried version
   fits more smoothly into the basic calculus.\<^footnote>\<open>The difference is even more
   significant in HOL, because the redundant tuple structure needs to be
   accommodated extraneous proof steps.\<close>
 
   Currying gives some flexibility due to \<^emph>\<open>partial application\<close>. A function
   \<open>f: \<tau>\<^sub>1 \<rightarrow> \<tau>\<^sub>2 \<rightarrow> \<tau>\<close> can be applied to \<open>x: \<tau>\<^sub>1\<close> and the remaining \<open>(f x): \<tau>\<^sub>2
   \<rightarrow> \<tau>\<close> passed to another function etc. How well this works in practice depends
   on the order of arguments. In the worst case, arguments are arranged
   erratically, and using a function in a certain situation always requires
   some glue code. Thus we would get exponentially many opportunities to
   decorate the code with meaningless permutations of arguments.
 
   This can be avoided by \<^emph>\<open>canonical argument order\<close>, which observes certain
   standard patterns and minimizes adhoc permutations in their application. In
   Isabelle/ML, large portions of text can be written without auxiliary
   operations like \<open>swap: \<alpha> \<times> \<beta> \<rightarrow> \<beta> \<times> \<alpha>\<close> or \<open>C: (\<alpha> \<rightarrow> \<beta> \<rightarrow> \<gamma>) \<rightarrow> (\<beta> \<rightarrow> \<alpha> \<rightarrow> \<gamma>)\<close> (the
   latter is not present in the Isabelle/ML library).
 
   \<^medskip>
   The main idea is that arguments that vary less are moved further to the left
   than those that vary more. Two particularly important categories of
   functions are \<^emph>\<open>selectors\<close> and \<^emph>\<open>updates\<close>.
 
   The subsequent scheme is based on a hypothetical set-like container of type
   \<open>\<beta>\<close> that manages elements of type \<open>\<alpha>\<close>. Both the names and types of the
   associated operations are canonical for Isabelle/ML.
 
   \begin{center}
   \begin{tabular}{ll}
   kind & canonical name and type \\\hline
   selector & \<open>member: \<beta> \<rightarrow> \<alpha> \<rightarrow> bool\<close> \\
   update & \<open>insert: \<alpha> \<rightarrow> \<beta> \<rightarrow> \<beta>\<close> \\
   \end{tabular}
   \end{center}
 
   Given a container \<open>B: \<beta>\<close>, the partially applied \<open>member B\<close> is a predicate
   over elements \<open>\<alpha> \<rightarrow> bool\<close>, and thus represents the intended denotation
   directly. It is customary to pass the abstract predicate to further
   operations, not the concrete container. The argument order makes it easy to
   use other combinators: \<open>forall (member B) list\<close> will check a list of
   elements for membership in \<open>B\<close> etc. Often the explicit \<open>list\<close> is pointless
   and can be contracted to \<open>forall (member B)\<close> to get directly a predicate
   again.
 
   In contrast, an update operation varies the container, so it moves to the
   right: \<open>insert a\<close> is a function \<open>\<beta> \<rightarrow> \<beta>\<close> to insert a value \<open>a\<close>. These can be
   composed naturally as \<open>insert c \<circ> insert b \<circ> insert a\<close>. The slightly awkward
   inversion of the composition order is due to conventional mathematical
   notation, which can be easily amended as explained below.
 \<close>
 
 
 subsection \<open>Forward application and composition\<close>
 
 text \<open>
   Regular function application and infix notation works best for relatively
   deeply structured expressions, e.g.\ \<open>h (f x y + g z)\<close>. The important
   special case of \<^emph>\<open>linear transformation\<close> applies a cascade of functions \<open>f\<^sub>n
   (\<dots> (f\<^sub>1 x))\<close>. This becomes hard to read and maintain if the functions are
   themselves given as complex expressions. The notation can be significantly
   improved by introducing \<^emph>\<open>forward\<close> versions of application and composition
   as follows:
 
   \<^medskip>
   \begin{tabular}{lll}
   \<open>x |> f\<close> & \<open>\<equiv>\<close> & \<open>f x\<close> \\
   \<open>(f #> g) x\<close> & \<open>\<equiv>\<close> & \<open>x |> f |> g\<close> \\
   \end{tabular}
   \<^medskip>
 
   This enables to write conveniently \<open>x |> f\<^sub>1 |> \<dots> |> f\<^sub>n\<close> or \<open>f\<^sub>1 #> \<dots> #>
   f\<^sub>n\<close> for its functional abstraction over \<open>x\<close>.
 
   \<^medskip>
   There is an additional set of combinators to accommodate multiple results
   (via pairs) that are passed on as multiple arguments (via currying).
 
   \<^medskip>
   \begin{tabular}{lll}
   \<open>(x, y) |-> f\<close> & \<open>\<equiv>\<close> & \<open>f x y\<close> \\
   \<open>(f #-> g) x\<close> & \<open>\<equiv>\<close> & \<open>x |> f |-> g\<close> \\
   \end{tabular}
   \<^medskip>
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_infix "|>" : "'a * ('a -> 'b) -> 'b"} \\
   @{define_ML_infix "|->" : "('c * 'a) * ('c -> 'a -> 'b) -> 'b"} \\
   @{define_ML_infix "#>" : "('a -> 'b) * ('b -> 'c) -> 'a -> 'c"} \\
   @{define_ML_infix "#->" : "('a -> 'c * 'b) * ('c -> 'b -> 'd) -> 'a -> 'd"} \\
   \end{mldecls}
 \<close>
 
 
 subsection \<open>Canonical iteration\<close>
 
 text \<open>
   As explained above, a function \<open>f: \<alpha> \<rightarrow> \<beta> \<rightarrow> \<beta>\<close> can be understood as update on
   a configuration of type \<open>\<beta>\<close>, parameterized by an argument of type \<open>\<alpha>\<close>. Given
   \<open>a: \<alpha>\<close> the partial application \<open>(f a): \<beta> \<rightarrow> \<beta>\<close> operates homogeneously on \<open>\<beta>\<close>.
   This can be iterated naturally over a list of parameters \<open>[a\<^sub>1, \<dots>, a\<^sub>n]\<close> as
   \<open>f a\<^sub>1 #> \<dots> #> f a\<^sub>n\<close>. The latter expression is again a function \<open>\<beta> \<rightarrow> \<beta>\<close>. It
   can be applied to an initial configuration \<open>b: \<beta>\<close> to start the iteration
   over the given list of arguments: each \<open>a\<close> in \<open>a\<^sub>1, \<dots>, a\<^sub>n\<close> is applied
   consecutively by updating a cumulative configuration.
 
   The \<open>fold\<close> combinator in Isabelle/ML lifts a function \<open>f\<close> as above to its
   iterated version over a list of arguments. Lifting can be repeated, e.g.\
   \<open>(fold \<circ> fold) f\<close> iterates over a list of lists as expected.
 
   The variant \<open>fold_rev\<close> works inside-out over the list of arguments, such
   that \<open>fold_rev f \<equiv> fold f \<circ> rev\<close> holds.
 
   The \<open>fold_map\<close> combinator essentially performs \<open>fold\<close> and \<open>map\<close>
   simultaneously: each application of \<open>f\<close> produces an updated configuration
   together with a side-result; the iteration collects all such side-results as
   a separate list.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML fold: "('a -> 'b -> 'b) -> 'a list -> 'b -> 'b"} \\
   @{define_ML fold_rev: "('a -> 'b -> 'b) -> 'a list -> 'b -> 'b"} \\
   @{define_ML fold_map: "('a -> 'b -> 'c * 'b) -> 'a list -> 'b -> 'c list * 'b"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>fold\<close>~\<open>f\<close> lifts the parametrized update function \<open>f\<close> to a list of
   parameters.
 
   \<^descr> \<^ML>\<open>fold_rev\<close>~\<open>f\<close> is similar to \<^ML>\<open>fold\<close>~\<open>f\<close>, but works inside-out, as
   if the list would be reversed.
 
   \<^descr> \<^ML>\<open>fold_map\<close>~\<open>f\<close> lifts the parametrized update function \<open>f\<close> (with
   side-result) to a list of parameters and cumulative side-results.
 
 
   \begin{warn}
   The literature on functional programming provides a confusing multitude of
   combinators called \<open>foldl\<close>, \<open>foldr\<close> etc. SML97 provides its own variations
   as \<^ML>\<open>List.foldl\<close> and \<^ML>\<open>List.foldr\<close>, while the classic Isabelle library
   also has the historic \<^ML>\<open>Library.foldl\<close> and \<^ML>\<open>Library.foldr\<close>. To avoid
   unnecessary complication, all these historical versions should be ignored,
   and the canonical \<^ML>\<open>fold\<close> (or \<^ML>\<open>fold_rev\<close>) used exclusively.
   \end{warn}
 \<close>
 
 text %mlex \<open>
   The following example shows how to fill a text buffer incrementally by
   adding strings, either individually or from a given list.
 \<close>
 
 ML_val \<open>
   val s =
     Buffer.empty
     |> Buffer.add "digits: "
     |> fold (Buffer.add o string_of_int) (0 upto 9)
     |> Buffer.content;
 
   \<^assert> (s = "digits: 0123456789");
 \<close>
 
 text \<open>
   Note how \<^ML>\<open>fold (Buffer.add o string_of_int)\<close> above saves an extra \<^ML>\<open>map\<close> over the given list. This kind of peephole optimization reduces both
   the code size and the tree structures in memory (``deforestation''), but it
   requires some practice to read and write fluently.
 
   \<^medskip>
   The next example elaborates the idea of canonical iteration, demonstrating
   fast accumulation of tree content using a text buffer.
 \<close>
 
 ML \<open>
   datatype tree = Text of string | Elem of string * tree list;
 
   fun slow_content (Text txt) = txt
     | slow_content (Elem (name, ts)) =
         "<" ^ name ^ ">" ^
         implode (map slow_content ts) ^
         "</" ^ name ^ ">"
 
   fun add_content (Text txt) = Buffer.add txt
     | add_content (Elem (name, ts)) =
         Buffer.add ("<" ^ name ^ ">") #>
         fold add_content ts #>
         Buffer.add ("</" ^ name ^ ">");
 
   fun fast_content tree =
     Buffer.empty |> add_content tree |> Buffer.content;
 \<close>
 
 text \<open>
   The slowness of \<^ML>\<open>slow_content\<close> is due to the \<^ML>\<open>implode\<close> of the
   recursive results, because it copies previously produced strings again and
   again.
 
   The incremental \<^ML>\<open>add_content\<close> avoids this by operating on a buffer that
   is passed through in a linear fashion. Using \<^ML_text>\<open>#>\<close> and contraction
   over the actual buffer argument saves some additional boiler-plate. Of
   course, the two \<^ML>\<open>Buffer.add\<close> invocations with concatenated strings
   could have been split into smaller parts, but this would have obfuscated the
   source without making a big difference in performance. Here we have done
   some peephole-optimization for the sake of readability.
 
   Another benefit of \<^ML>\<open>add_content\<close> is its ``open'' form as a function on
   buffers that can be continued in further linear transformations, folding
   etc. Thus it is more compositional than the naive \<^ML>\<open>slow_content\<close>. As
   realistic example, compare the old-style
   \<^ML>\<open>Term.maxidx_of_term: term -> int\<close> with the newer \<^ML>\<open>Term.maxidx_term: term -> int -> int\<close> in Isabelle/Pure.
 
   Note that \<^ML>\<open>fast_content\<close> above is only defined as example. In many
   practical situations, it is customary to provide the incremental \<^ML>\<open>add_content\<close> only and leave the initialization and termination to the
   concrete application to the user.
 \<close>
 
 
 section \<open>Message output channels \label{sec:message-channels}\<close>
 
 text \<open>
   Isabelle provides output channels for different kinds of messages: regular
   output, high-volume tracing information, warnings, and errors.
 
   Depending on the user interface involved, these messages may appear in
   different text styles or colours. The standard output for batch sessions
   prefixes each line of warnings by \<^verbatim>\<open>###\<close> and errors by \<^verbatim>\<open>***\<close>, but leaves
   anything else unchanged. The message body may contain further markup and
   formatting, which is routinely used in the Prover IDE @{cite
   "isabelle-jedit"}.
 
   Messages are associated with the transaction context of the running Isar
   command. This enables the front-end to manage commands and resulting
   messages together. For example, after deleting a command from a given theory
   document version, the corresponding message output can be retracted from the
   display.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML writeln: "string -> unit"} \\
   @{define_ML tracing: "string -> unit"} \\
   @{define_ML warning: "string -> unit"} \\
   @{define_ML error: "string -> 'a"} % FIXME Output.error_message (!?) \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>writeln\<close>~\<open>text\<close> outputs \<open>text\<close> as regular message. This is the
   primary message output operation of Isabelle and should be used by default.
 
   \<^descr> \<^ML>\<open>tracing\<close>~\<open>text\<close> outputs \<open>text\<close> as special tracing message, indicating
   potential high-volume output to the front-end (hundreds or thousands of
   messages issued by a single command). The idea is to allow the
   user-interface to downgrade the quality of message display to achieve higher
   throughput.
 
   Note that the user might have to take special actions to see tracing output,
   e.g.\ switch to a different output window. So this channel should not be
   used for regular output.
 
   \<^descr> \<^ML>\<open>warning\<close>~\<open>text\<close> outputs \<open>text\<close> as warning, which typically means some
   extra emphasis on the front-end side (color highlighting, icons, etc.).
 
   \<^descr> \<^ML>\<open>error\<close>~\<open>text\<close> raises exception \<^ML>\<open>ERROR\<close>~\<open>text\<close> and thus lets the
   Isar toplevel print \<open>text\<close> on the error channel, which typically means some
   extra emphasis on the front-end side (color highlighting, icons, etc.).
 
   This assumes that the exception is not handled before the command
   terminates. Handling exception \<^ML>\<open>ERROR\<close>~\<open>text\<close> is a perfectly legal
   alternative: it means that the error is absorbed without any message output.
 
   \begin{warn}
   The actual error channel is accessed via \<^ML>\<open>Output.error_message\<close>, but
   this is normally not used directly in user code.
   \end{warn}
 
 
   \begin{warn}
   Regular Isabelle/ML code should output messages exclusively by the official
   channels. Using raw I/O on \<^emph>\<open>stdout\<close> or \<^emph>\<open>stderr\<close> instead (e.g.\ via \<^ML>\<open>TextIO.output\<close>) is apt to cause problems in the presence of parallel and
   asynchronous processing of Isabelle theories. Such raw output might be
   displayed by the front-end in some system console log, with a low chance
   that the user will ever see it. Moreover, as a genuine side-effect on global
   process channels, there is no proper way to retract output when Isar command
   transactions are reset by the system.
   \end{warn}
 
   \begin{warn}
   The message channels should be used in a message-oriented manner. This means
   that multi-line output that logically belongs together is issued by a single
   invocation of \<^ML>\<open>writeln\<close> etc.\ with the functional concatenation of all
   message constituents.
   \end{warn}
 \<close>
 
 text %mlex \<open>
   The following example demonstrates a multi-line warning. Note that in some
   situations the user sees only the first line, so the most important point
   should be made first.
 \<close>
 
 ML_command \<open>
   warning (cat_lines
    ["Beware the Jabberwock, my son!",
     "The jaws that bite, the claws that catch!",
     "Beware the Jubjub Bird, and shun",
     "The frumious Bandersnatch!"]);
 \<close>
 
 text \<open>
   \<^medskip>
   An alternative is to make a paragraph of freely-floating words as follows.
 \<close>
 
 ML_command \<open>
   warning (Pretty.string_of (Pretty.para
     "Beware the Jabberwock, my son! \
     \The jaws that bite, the claws that catch! \
     \Beware the Jubjub Bird, and shun \
     \The frumious Bandersnatch!"))
 \<close>
 
 text \<open>
   This has advantages with variable window / popup sizes, but might make it
   harder to search for message content systematically, e.g.\ by other tools or
   by humans expecting the ``verse'' of a formal message in a fixed layout.
 \<close>
 
 
 section \<open>Exceptions \label{sec:exceptions}\<close>
 
 text \<open>
   The Standard ML semantics of strict functional evaluation together with
   exceptions is rather well defined, but some delicate points need to be
   observed to avoid that ML programs go wrong despite static type-checking.
   Exceptions in Isabelle/ML are subsequently categorized as follows.
 \<close>
 
 paragraph \<open>Regular user errors.\<close>
 text \<open>
   These are meant to provide informative feedback about malformed input etc.
 
   The \<^emph>\<open>error\<close> function raises the corresponding \<^ML>\<open>ERROR\<close> exception, with a
   plain text message as argument. \<^ML>\<open>ERROR\<close> exceptions can be handled
   internally, in order to be ignored, turned into other exceptions, or
   cascaded by appending messages. If the corresponding Isabelle/Isar command
   terminates with an \<^ML>\<open>ERROR\<close> exception state, the system will print the
   result on the error channel (see \secref{sec:message-channels}).
 
   It is considered bad style to refer to internal function names or values in
   ML source notation in user error messages. Do not use \<open>@{make_string}\<close> nor
   \<open>@{here}\<close>!
 
   Grammatical correctness of error messages can be improved by \<^emph>\<open>omitting\<close>
   final punctuation: messages are often concatenated or put into a larger
   context (e.g.\ augmented with source position). Note that punctuation after
   formal entities (types, terms, theorems) is particularly prone to user
   confusion.
 \<close>
 
 paragraph \<open>Program failures.\<close>
 text \<open>
   There is a handful of standard exceptions that indicate general failure
   situations, or failures of core operations on logical entities (types,
   terms, theorems, theories, see \chref{ch:logic}).
 
   These exceptions indicate a genuine breakdown of the program, so the main
   purpose is to determine quickly what has happened where. Traditionally, the
   (short) exception message would include the name of an ML function, although
   this is no longer necessary, because the ML runtime system attaches detailed
   source position stemming from the corresponding \<^ML_text>\<open>raise\<close> keyword.
 
   \<^medskip>
   User modules can always introduce their own custom exceptions locally, e.g.\
   to organize internal failures robustly without overlapping with existing
   exceptions. Exceptions that are exposed in module signatures require extra
   care, though, and should \<^emph>\<open>not\<close> be introduced by default. Surprise by users
   of a module can be often minimized by using plain user errors instead.
 \<close>
 
 paragraph \<open>Interrupts.\<close>
 text \<open>
   These indicate arbitrary system events: both the ML runtime system and the
   Isabelle/ML infrastructure signal various exceptional situations by raising
   the special \<^ML>\<open>Exn.Interrupt\<close> exception in user code.
 
   This is the one and only way that physical events can intrude an Isabelle/ML
   program. Such an interrupt can mean out-of-memory, stack overflow, timeout,
   internal signaling of threads, or a POSIX process signal. An Isabelle/ML
   program that intercepts interrupts becomes dependent on physical effects of
   the environment. Even worse, exception handling patterns that are too
   general by accident, e.g.\ by misspelled exception constructors, will cover
   interrupts unintentionally and thus render the program semantics
   ill-defined.
 
   Note that the Interrupt exception dates back to the original SML90 language
   definition. It was excluded from the SML97 version to avoid its malign
   impact on ML program semantics, but without providing a viable alternative.
   Isabelle/ML recovers physical interruptibility (which is an indispensable
   tool to implement managed evaluation of command transactions), but requires
   user code to be strictly transparent wrt.\ interrupts.
 
   \begin{warn}
   Isabelle/ML user code needs to terminate promptly on interruption, without
   guessing at its meaning to the system infrastructure. Temporary handling of
   interrupts for cleanup of global resources etc.\ needs to be followed
   immediately by re-raising of the original exception.
   \end{warn}
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML try: "('a -> 'b) -> 'a -> 'b option"} \\
   @{define_ML can: "('a -> 'b) -> 'a -> bool"} \\
   @{define_ML_exception ERROR of string} \\
   @{define_ML_exception Fail of string} \\
   @{define_ML Exn.is_interrupt: "exn -> bool"} \\
   @{define_ML Exn.reraise: "exn -> 'a"} \\
   @{define_ML Runtime.exn_trace: "(unit -> 'a) -> 'a"} \\
   \end{mldecls}
 
   \<^rail>\<open>
     (@@{ML_antiquotation try} | @@{ML_antiquotation can}) embedded
   \<close>
 
   \<^descr> \<^ML>\<open>try\<close>~\<open>f x\<close> makes the partiality of evaluating \<open>f x\<close> explicit via the
   option datatype. Interrupts are \<^emph>\<open>not\<close> handled here, i.e.\ this form serves
   as safe replacement for the \<^emph>\<open>unsafe\<close> version \<^ML_text>\<open>(SOME\<close>~\<open>f
   x\<close>~\<^ML_text>\<open>handle _ => NONE)\<close> that is occasionally seen in books about
   SML97, but not in Isabelle/ML.
 
   \<^descr> \<^ML>\<open>can\<close> is similar to \<^ML>\<open>try\<close> with more abstract result.
 
   \<^descr> \<^ML>\<open>ERROR\<close>~\<open>msg\<close> represents user errors; this exception is normally
   raised indirectly via the \<^ML>\<open>error\<close> function (see
   \secref{sec:message-channels}).
 
   \<^descr> \<^ML>\<open>Fail\<close>~\<open>msg\<close> represents general program failures.
 
   \<^descr> \<^ML>\<open>Exn.is_interrupt\<close> identifies interrupts robustly, without mentioning
   concrete exception constructors in user code. Handled interrupts need to be
   re-raised promptly!
 
   \<^descr> \<^ML>\<open>Exn.reraise\<close>~\<open>exn\<close> raises exception \<open>exn\<close> while preserving its implicit
   position information (if possible, depending on the ML platform).
 
   \<^descr> \<^ML>\<open>Runtime.exn_trace\<close>~\<^ML_text>\<open>(fn () =>\<close>~\<open>e\<close>\<^ML_text>\<open>)\<close> evaluates
   expression \<open>e\<close> while printing a full trace of its stack of nested exceptions
   (if possible, depending on the ML platform).
 
   Inserting \<^ML>\<open>Runtime.exn_trace\<close> into ML code temporarily is useful for
   debugging, but not suitable for production code.
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "try"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "can"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "assert"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "undefined"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^descr> \<open>@{try}\<close> and \<open>{can}\<close> are similar to the corresponding functions, but the
   argument is taken directly as ML expression: functional abstraction and
   application is done implicitly.
 
   \<^descr> \<open>@{assert}\<close> inlines a function \<^ML_type>\<open>bool -> unit\<close> that raises
   \<^ML>\<open>Fail\<close> if the argument is \<^ML>\<open>false\<close>. Due to inlining the source
   position of failed assertions is included in the error output.
 
   \<^descr> \<open>@{undefined}\<close> inlines \<^verbatim>\<open>raise\<close>~\<^ML>\<open>Match\<close>, i.e.\ the ML program
   behaves as in some function application of an undefined case.
 \<close>
 
 text %mlex \<open>
   We define a total version of division: any failures are swept under the
   carpet and mapped to a default value. Thus division-by-zero becomes 0, but
   there could be other exceptions like overflow that produce the same result
   (for unbounded integers this does not happen).
 \<close>
 
 ML \<open>
   fun div_total x y = \<^try>\<open>x div y\<close> |> the_default 0;
 
   \<^assert> (div_total 1 0 = 0);
 \<close>
 
 text \<open>
   The ML function \<^ML>\<open>undefined\<close> is defined in \<^file>\<open>~~/src/Pure/library.ML\<close>
   as follows:
 \<close>
 
 ML \<open>fun undefined _ = raise Match\<close>
 
 text \<open>
   \<^medskip>
   The following variant uses the antiquotation @{ML_antiquotation undefined}
   instead:
 \<close>
 
 ML \<open>fun undefined _ = \<^undefined>\<close>
 
 text \<open>
   \<^medskip>
   Here is the same, using control-symbol notation for the antiquotation, with
   special rendering of \<^verbatim>\<open>\<^undefined>\<close>:
 \<close>
 
 ML \<open>fun undefined _ = \<^undefined>\<close>
 
 text \<open>
   \<^medskip> Semantically, all forms are equivalent to a function definition
   without any clauses, but that is syntactically not allowed in ML.
 \<close>
 
 
 section \<open>Strings of symbols \label{sec:symbols}\<close>
 
 text \<open>
   A \<^emph>\<open>symbol\<close> constitutes the smallest textual unit in Isabelle/ML --- raw ML
   characters are normally not encountered at all. Isabelle strings consist of
   a sequence of symbols, represented as a packed string or an exploded list of
   strings. Each symbol is in itself a small string, which has either one of
   the following forms:
 
     \<^enum> a single ASCII character ``\<open>c\<close>'', for example ``\<^verbatim>\<open>a\<close>'',
 
     \<^enum> a codepoint according to UTF-8 (non-ASCII byte sequence),
 
     \<^enum> a regular symbol ``\<^verbatim>\<open>\<ident>\<close>'', for example ``\<^verbatim>\<open>\<alpha>\<close>'',
 
     \<^enum> a control symbol ``\<^verbatim>\<open>\<^ident>\<close>'', for example ``\<^verbatim>\<open>\<^bold>\<close>'',
 
   The \<open>ident\<close> syntax for symbol names is \<open>letter (letter | digit)\<^sup>*\<close>, where
   \<open>letter = A..Za..z\<close> and \<open>digit = 0..9\<close>. There are infinitely many regular
   symbols and control symbols, but a fixed collection of standard symbols is
   treated specifically. For example, ``\<^verbatim>\<open>\<alpha>\<close>'' is classified as a letter, which
   means it may occur within regular Isabelle identifiers.
 
   The character set underlying Isabelle symbols is 7-bit ASCII, but 8-bit
   character sequences are passed-through unchanged. Unicode/UCS data in UTF-8
   encoding is processed in a non-strict fashion, such that well-formed code
   sequences are recognized accordingly. Unicode provides its own collection of
   mathematical symbols, but within the core Isabelle/ML world there is no link
   to the standard collection of Isabelle regular symbols.
 
   \<^medskip>
   Output of Isabelle symbols depends on the print mode. For example, the
   standard {\LaTeX} setup of the Isabelle document preparation system would
   present ``\<^verbatim>\<open>\<alpha>\<close>'' as \<open>\<alpha>\<close>, and ``\<^verbatim>\<open>\<^bold>\<alpha>\<close>'' as \<open>\<^bold>\<alpha>\<close>. On-screen rendering usually
   works by mapping a finite subset of Isabelle symbols to suitable Unicode
   characters.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type Symbol.symbol = string} \\
   @{define_ML Symbol.explode: "string -> Symbol.symbol list"} \\
   @{define_ML Symbol.is_letter: "Symbol.symbol -> bool"} \\
   @{define_ML Symbol.is_digit: "Symbol.symbol -> bool"} \\
   @{define_ML Symbol.is_quasi: "Symbol.symbol -> bool"} \\
   @{define_ML Symbol.is_blank: "Symbol.symbol -> bool"} \\
   \end{mldecls}
   \begin{mldecls}
   @{define_ML_type "Symbol.sym"} \\
   @{define_ML Symbol.decode: "Symbol.symbol -> Symbol.sym"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>Symbol.symbol\<close> represents individual Isabelle symbols.
 
   \<^descr> \<^ML>\<open>Symbol.explode\<close>~\<open>str\<close> produces a symbol list from the packed form.
   This function supersedes \<^ML>\<open>String.explode\<close> for virtually all purposes
   of manipulating text in Isabelle!\<^footnote>\<open>The runtime overhead for exploded strings
   is mainly that of the list structure: individual symbols that happen to be a
   singleton string do not require extra memory in Poly/ML.\<close>
 
   \<^descr> \<^ML>\<open>Symbol.is_letter\<close>, \<^ML>\<open>Symbol.is_digit\<close>, \<^ML>\<open>Symbol.is_quasi\<close>, \<^ML>\<open>Symbol.is_blank\<close> classify standard symbols
   according to fixed syntactic conventions of Isabelle, cf.\ @{cite
   "isabelle-isar-ref"}.
 
   \<^descr> Type \<^ML_type>\<open>Symbol.sym\<close> is a concrete datatype that represents the
   different kinds of symbols explicitly, with constructors \<^ML>\<open>Symbol.Char\<close>, \<^ML>\<open>Symbol.UTF8\<close>, \<^ML>\<open>Symbol.Sym\<close>, \<^ML>\<open>Symbol.Control\<close>, \<^ML>\<open>Symbol.Malformed\<close>.
 
   \<^descr> \<^ML>\<open>Symbol.decode\<close> converts the string representation of a symbol into
   the datatype version.
 \<close>
 
 paragraph \<open>Historical note.\<close>
 text \<open>
   In the original SML90 standard the primitive ML type \<^ML_type>\<open>char\<close> did not
   exists, and \<^ML_text>\<open>explode: string -> string list\<close> produced a list of
   singleton strings like \<^ML>\<open>raw_explode: string -> string list\<close> in
   Isabelle/ML today. When SML97 came out, Isabelle did not adopt its somewhat
   anachronistic 8-bit or 16-bit characters, but the idea of exploding a string
   into a list of small strings was extended to ``symbols'' as explained above.
   Thus Isabelle sources can refer to an infinite store of user-defined
   symbols, without having to worry about the multitude of Unicode encodings
   that have emerged over the years.
 \<close>
 
 
 section \<open>Basic data types\<close>
 
 text \<open>
   The basis library proposal of SML97 needs to be treated with caution. Many
   of its operations simply do not fit with important Isabelle/ML conventions
   (like ``canonical argument order'', see
   \secref{sec:canonical-argument-order}), others cause problems with the
   parallel evaluation model of Isabelle/ML (such as \<^ML>\<open>TextIO.print\<close> or \<^ML>\<open>OS.Process.system\<close>).
 
   Subsequently we give a brief overview of important operations on basic ML
   data types.
 \<close>
 
 
 subsection \<open>Characters\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type char} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>char\<close> is \<^emph>\<open>not\<close> used. The smallest textual unit in Isabelle
   is represented as a ``symbol'' (see \secref{sec:symbols}).
 \<close>
 
 
 subsection \<open>Strings\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type string} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>string\<close> represents immutable vectors of 8-bit characters.
   There are operations in SML to convert back and forth to actual byte
   vectors, which are seldom used.
 
   This historically important raw text representation is used for
   Isabelle-specific purposes with the following implicit substructures packed
   into the string content:
 
     \<^enum> sequence of Isabelle symbols (see also \secref{sec:symbols}), with \<^ML>\<open>Symbol.explode\<close> as key operation;
   
     \<^enum> XML tree structure via YXML (see also @{cite "isabelle-system"}), with
     \<^ML>\<open>YXML.parse_body\<close> as key operation.
 
   Note that Isabelle/ML string literals may refer Isabelle symbols like
   ``\<^verbatim>\<open>\<alpha>\<close>'' natively, \<^emph>\<open>without\<close> escaping the backslash. This is a consequence
   of Isabelle treating all source text as strings of symbols, instead of raw
   characters.
 \<close>
 
 text %mlex \<open>
   The subsequent example illustrates the difference of physical addressing of
   bytes versus logical addressing of symbols in Isabelle strings.
 \<close>
 
 ML_val \<open>
   val s = "\<A>";
 
   \<^assert> (length (Symbol.explode s) = 1);
   \<^assert> (size s = 4);
 \<close>
 
 text \<open>
   Note that in Unicode renderings of the symbol \<open>\<A>\<close>, variations of encodings
   like UTF-8 or UTF-16 pose delicate questions about the multi-byte
   representations of its codepoint, which is outside of the 16-bit address
   space of the original Unicode standard from the 1990-ies. In Isabelle/ML it
   is just ``\<^verbatim>\<open>\<A>\<close>'' literally, using plain ASCII characters beyond any
   doubts.
 \<close>
 
 
 subsection \<open>Integers\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type int} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>int\<close> represents regular mathematical integers, which are
   \<^emph>\<open>unbounded\<close>. Overflow is treated properly, but should never happen in
   practice.\<^footnote>\<open>The size limit for integer bit patterns in memory is 64\,MB for
   32-bit Poly/ML, and much higher for 64-bit systems.\<close>
 
   Structure \<^ML_structure>\<open>IntInf\<close> of SML97 is obsolete and superseded by
   \<^ML_structure>\<open>Int\<close>. Structure \<^ML_structure>\<open>Integer\<close> in
   \<^file>\<open>~~/src/Pure/General/integer.ML\<close> provides some additional operations.
 \<close>
 
 
 subsection \<open>Rational numbers\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type Rat.rat} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>Rat.rat\<close> represents rational numbers, based on the
   unbounded integers of Poly/ML.
 
   Literal rationals may be written with special antiquotation syntax
   \<^verbatim>\<open>@\<close>\<open>int\<close>\<^verbatim>\<open>/\<close>\<open>nat\<close> or \<^verbatim>\<open>@\<close>\<open>int\<close> (without any white space). For example
   \<^verbatim>\<open>@~1/4\<close> or \<^verbatim>\<open>@10\<close>. The ML toplevel pretty printer uses the same format.
 
   Standard operations are provided via ad-hoc overloading of \<^verbatim>\<open>+\<close>, \<^verbatim>\<open>-\<close>, \<^verbatim>\<open>*\<close>,
   \<^verbatim>\<open>/\<close>, etc.
 \<close>
 
 
 subsection \<open>Time\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type Time.time} \\
   @{define_ML seconds: "real -> Time.time"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>Time.time\<close> represents time abstractly according to the
   SML97 basis library definition. This is adequate for internal ML operations,
   but awkward in concrete time specifications.
 
   \<^descr> \<^ML>\<open>seconds\<close>~\<open>s\<close> turns the concrete scalar \<open>s\<close> (measured in seconds) into
   an abstract time value. Floating point numbers are easy to use as
   configuration options in the context (see \secref{sec:config-options}) or
   system options that are maintained externally.
 \<close>
 
 
 subsection \<open>Options\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Option.map: "('a -> 'b) -> 'a option -> 'b option"} \\
   @{define_ML is_some: "'a option -> bool"} \\
   @{define_ML is_none: "'a option -> bool"} \\
   @{define_ML the: "'a option -> 'a"} \\
   @{define_ML these: "'a list option -> 'a list"} \\
   @{define_ML the_list: "'a option -> 'a list"} \\
   @{define_ML the_default: "'a -> 'a option -> 'a"} \\
   \end{mldecls}
 \<close>
 
 text \<open>
   Apart from \<^ML>\<open>Option.map\<close> most other operations defined in structure
   \<^ML_structure>\<open>Option\<close> are alien to Isabelle/ML and never used. The
   operations shown above are defined in \<^file>\<open>~~/src/Pure/General/basics.ML\<close>.
 \<close>
 
 
 subsection \<open>Lists\<close>
 
 text \<open>
   Lists are ubiquitous in ML as simple and light-weight ``collections'' for
   many everyday programming tasks. Isabelle/ML provides important additions
   and improvements over operations that are predefined in the SML97 library.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML cons: "'a -> 'a list -> 'a list"} \\
   @{define_ML member: "('b * 'a -> bool) -> 'a list -> 'b -> bool"} \\
   @{define_ML insert: "('a * 'a -> bool) -> 'a -> 'a list -> 'a list"} \\
   @{define_ML remove: "('b * 'a -> bool) -> 'b -> 'a list -> 'a list"} \\
   @{define_ML update: "('a * 'a -> bool) -> 'a -> 'a list -> 'a list"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>cons\<close>~\<open>x xs\<close> evaluates to \<open>x :: xs\<close>.
 
   Tupled infix operators are a historical accident in Standard ML. The curried
   \<^ML>\<open>cons\<close> amends this, but it should be only used when partial application
   is required.
 
   \<^descr> \<^ML>\<open>member\<close>, \<^ML>\<open>insert\<close>, \<^ML>\<open>remove\<close>, \<^ML>\<open>update\<close> treat lists as a
   set-like container that maintains the order of elements. See
   \<^file>\<open>~~/src/Pure/library.ML\<close> for the full specifications (written in ML).
   There are some further derived operations like \<^ML>\<open>union\<close> or \<^ML>\<open>inter\<close>.
 
   Note that \<^ML>\<open>insert\<close> is conservative about elements that are already a
   \<^ML>\<open>member\<close> of the list, while \<^ML>\<open>update\<close> ensures that the latest entry
   is always put in front. The latter discipline is often more appropriate in
   declarations of context data (\secref{sec:context-data}) that are issued by
   the user in Isar source: later declarations take precedence over earlier
   ones. \<close>
 
 text %mlex \<open>
   Using canonical \<^ML>\<open>fold\<close> together with \<^ML>\<open>cons\<close> (or similar standard
   operations) alternates the orientation of data. The is quite natural and
   should not be altered forcible by inserting extra applications of \<^ML>\<open>rev\<close>.
   The alternative \<^ML>\<open>fold_rev\<close> can be used in the few situations, where
   alternation should be prevented.
 \<close>
 
 ML_val \<open>
   val items = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 
   val list1 = fold cons items [];
   \<^assert> (list1 = rev items);
 
   val list2 = fold_rev cons items [];
   \<^assert> (list2 = items);
 \<close>
 
 text \<open>
   The subsequent example demonstrates how to \<^emph>\<open>merge\<close> two lists in a natural
   way.
 \<close>
 
 ML_val \<open>
   fun merge_lists eq (xs, ys) = fold_rev (insert eq) ys xs;
 \<close>
 
 text \<open>
   Here the first list is treated conservatively: only the new elements from
   the second list are inserted. The inside-out order of insertion via \<^ML>\<open>fold_rev\<close> attempts to preserve the order of elements in the result.
 
   This way of merging lists is typical for context data
   (\secref{sec:context-data}). See also \<^ML>\<open>merge\<close> as defined in
   \<^file>\<open>~~/src/Pure/library.ML\<close>.
 \<close>
 
 
 subsection \<open>Association lists\<close>
 
 text \<open>
   The operations for association lists interpret a concrete list of pairs as a
   finite function from keys to values. Redundant representations with multiple
   occurrences of the same key are implicitly normalized: lookup and update
   only take the first occurrence into account.
 \<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML AList.lookup: "('a * 'b -> bool) -> ('b * 'c) list -> 'a -> 'c option"} \\
   @{define_ML AList.defined: "('a * 'b -> bool) -> ('b * 'c) list -> 'a -> bool"} \\
   @{define_ML AList.update: "('a * 'a -> bool) -> 'a * 'b -> ('a * 'b) list -> ('a * 'b) list"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>AList.lookup\<close>, \<^ML>\<open>AList.defined\<close>, \<^ML>\<open>AList.update\<close> implement the
   main ``framework operations'' for mappings in Isabelle/ML, following
   standard conventions for their names and types.
 
   Note that a function called \<^verbatim>\<open>lookup\<close> is obliged to express its partiality
   via an explicit option element. There is no choice to raise an exception,
   without changing the name to something like \<open>the_element\<close> or \<open>get\<close>.
 
   The \<open>defined\<close> operation is essentially a contraction of \<^ML>\<open>is_some\<close> and
   \<^verbatim>\<open>lookup\<close>, but this is sufficiently frequent to justify its independent
   existence. This also gives the implementation some opportunity for peep-hole
   optimization.
 
 
   Association lists are adequate as simple implementation of finite mappings
   in many practical situations. A more advanced table structure is defined in
   \<^file>\<open>~~/src/Pure/General/table.ML\<close>; that version scales easily to thousands or
   millions of elements.
 \<close>
 
 
 subsection \<open>Unsynchronized references\<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type "'a Unsynchronized.ref"} \\
   @{define_ML Unsynchronized.ref: "'a -> 'a Unsynchronized.ref"} \\
   @{define_ML "!": "'a Unsynchronized.ref -> 'a"} \\
   @{define_ML_infix ":=" : "'a Unsynchronized.ref * 'a -> unit"} \\
   \end{mldecls}
 \<close>
 
 text \<open>
   Due to ubiquitous parallelism in Isabelle/ML (see also
   \secref{sec:multi-threading}), the mutable reference cells of Standard ML
   are notorious for causing problems. In a highly parallel system, both
   correctness \<^emph>\<open>and\<close> performance are easily degraded when using mutable data.
 
   The unwieldy name of \<^ML>\<open>Unsynchronized.ref\<close> for the constructor for
   references in Isabelle/ML emphasizes the inconveniences caused by
-  mutability. Existing operations \<^ML>\<open>!\<close> and \<^ML_op>\<open>:=\<close> are unchanged,
+  mutability. Existing operations \<^ML>\<open>!\<close> and \<^ML_infix>\<open>:=\<close> are unchanged,
   but should be used with special precautions, say in a strictly local
   situation that is guaranteed to be restricted to sequential evaluation ---
   now and in the future.
 
   \begin{warn}
   Never \<^ML_text>\<open>open Unsynchronized\<close>, not even in a local scope!
   Pretending that mutable state is no problem is a very bad idea.
   \end{warn}
 \<close>
 
 
 section \<open>Thread-safe programming \label{sec:multi-threading}\<close>
 
 text \<open>
   Multi-threaded execution has become an everyday reality in Isabelle since
   Poly/ML 5.2.1 and Isabelle2008. Isabelle/ML provides implicit and explicit
   parallelism by default, and there is no way for user-space tools to ``opt
   out''. ML programs that are purely functional, output messages only via the
   official channels (\secref{sec:message-channels}), and do not intercept
   interrupts (\secref{sec:exceptions}) can participate in the multi-threaded
   environment immediately without further ado.
 
   More ambitious tools with more fine-grained interaction with the environment
   need to observe the principles explained below.
 \<close>
 
 
 subsection \<open>Multi-threading with shared memory\<close>
 
 text \<open>
   Multiple threads help to organize advanced operations of the system, such as
   real-time conditions on command transactions, sub-components with explicit
   communication, general asynchronous interaction etc. Moreover, parallel
   evaluation is a prerequisite to make adequate use of the CPU resources that
   are available on multi-core systems.\<^footnote>\<open>Multi-core computing does not mean
   that there are ``spare cycles'' to be wasted. It means that the continued
   exponential speedup of CPU performance due to ``Moore's Law'' follows
   different rules: clock frequency has reached its peak around 2005, and
   applications need to be parallelized in order to avoid a perceived loss of
   performance. See also @{cite "Sutter:2005"}.\<close>
 
   Isabelle/Isar exploits the inherent structure of theories and proofs to
   support \<^emph>\<open>implicit parallelism\<close> to a large extent. LCF-style theorem proving
   provides almost ideal conditions for that, see also @{cite "Wenzel:2009"}.
   This means, significant parts of theory and proof checking is parallelized
   by default. In Isabelle2013, a maximum speedup-factor of 3.5 on 4 cores and
   6.5 on 8 cores can be expected @{cite "Wenzel:2013:ITP"}.
 
   \<^medskip>
   ML threads lack the memory protection of separate processes, and operate
   concurrently on shared heap memory. This has the advantage that results of
   independent computations are directly available to other threads: abstract
   values can be passed without copying or awkward serialization that is
   typically required for separate processes.
 
   To make shared-memory multi-threading work robustly and efficiently, some
   programming guidelines need to be observed. While the ML system is
   responsible to maintain basic integrity of the representation of ML values
   in memory, the application programmer needs to ensure that multi-threaded
   execution does not break the intended semantics.
 
   \begin{warn}
   To participate in implicit parallelism, tools need to be thread-safe. A
   single ill-behaved tool can affect the stability and performance of the
   whole system.
   \end{warn}
 
   Apart from observing the principles of thread-safeness passively, advanced
   tools may also exploit parallelism actively, e.g.\ by using library
   functions for parallel list operations (\secref{sec:parlist}).
 
   \begin{warn}
   Parallel computing resources are managed centrally by the Isabelle/ML
   infrastructure. User programs should not fork their own ML threads to
   perform heavy computations.
   \end{warn}
 \<close>
 
 
 subsection \<open>Critical shared resources\<close>
 
 text \<open>
   Thread-safeness is mainly concerned about concurrent read/write access to
   shared resources, which are outside the purely functional world of ML. This
   covers the following in particular.
 
     \<^item> Global references (or arrays), i.e.\ mutable memory cells that persist
     over several invocations of associated operations.\<^footnote>\<open>This is independent of
     the visibility of such mutable values in the toplevel scope.\<close>
 
     \<^item> Global state of the running Isabelle/ML process, i.e.\ raw I/O channels,
     environment variables, current working directory.
 
     \<^item> Writable resources in the file-system that are shared among different
     threads or external processes.
 
   Isabelle/ML provides various mechanisms to avoid critical shared resources
   in most situations. As last resort there are some mechanisms for explicit
   synchronization. The following guidelines help to make Isabelle/ML programs
   work smoothly in a concurrent environment.
 
   \<^item> Avoid global references altogether. Isabelle/Isar maintains a uniform
   context that incorporates arbitrary data declared by user programs
   (\secref{sec:context-data}). This context is passed as plain value and user
   tools can get/map their own data in a purely functional manner.
   Configuration options within the context (\secref{sec:config-options})
   provide simple drop-in replacements for historic reference variables.
 
   \<^item> Keep components with local state information re-entrant. Instead of poking
   initial values into (private) global references, a new state record can be
   created on each invocation, and passed through any auxiliary functions of
   the component. The state record contain mutable references in special
   situations, without requiring any synchronization, as long as each
   invocation gets its own copy and the tool itself is single-threaded.
 
   \<^item> Avoid raw output on \<open>stdout\<close> or \<open>stderr\<close>. The Poly/ML library is
   thread-safe for each individual output operation, but the ordering of
   parallel invocations is arbitrary. This means raw output will appear on some
   system console with unpredictable interleaving of atomic chunks.
 
   Note that this does not affect regular message output channels
   (\secref{sec:message-channels}). An official message id is associated with
   the command transaction from where it originates, independently of other
   transactions. This means each running Isar command has effectively its own
   set of message channels, and interleaving can only happen when commands use
   parallelism internally (and only at message boundaries).
 
   \<^item> Treat environment variables and the current working directory of the
   running process as read-only.
 
   \<^item> Restrict writing to the file-system to unique temporary files. Isabelle
   already provides a temporary directory that is unique for the running
   process, and there is a centralized source of unique serial numbers in
   Isabelle/ML. Thus temporary files that are passed to to some external
   process will be always disjoint, and thus thread-safe.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML File.tmp_path: "Path.T -> Path.T"} \\
   @{define_ML serial_string: "unit -> string"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>File.tmp_path\<close>~\<open>path\<close> relocates the base component of \<open>path\<close> into the
   unique temporary directory of the running Isabelle/ML process.
 
   \<^descr> \<^ML>\<open>serial_string\<close>~\<open>()\<close> creates a new serial number that is unique over
   the runtime of the Isabelle/ML process.
 \<close>
 
 text %mlex \<open>
   The following example shows how to create unique temporary file names.
 \<close>
 
 ML_val \<open>
   val tmp1 = File.tmp_path (Path.basic ("foo" ^ serial_string ()));
   val tmp2 = File.tmp_path (Path.basic ("foo" ^ serial_string ()));
   \<^assert> (tmp1 <> tmp2);
 \<close>
 
 
 subsection \<open>Explicit synchronization\<close>
 
 text \<open>
   Isabelle/ML provides explicit synchronization for mutable variables over
   immutable data, which may be updated atomically and exclusively. This
   addresses the rare situations where mutable shared resources are really
   required. Synchronization in Isabelle/ML is based on primitives of Poly/ML,
   which have been adapted to the specific assumptions of the concurrent
   Isabelle environment. User code should not break this abstraction, but stay
   within the confines of concurrent Isabelle/ML.
 
   A \<^emph>\<open>synchronized variable\<close> is an explicit state component associated with
   mechanisms for locking and signaling. There are operations to await a
   condition, change the state, and signal the change to all other waiting
   threads. Synchronized access to the state variable is \<^emph>\<open>not\<close> re-entrant:
   direct or indirect nesting within the same thread will cause a deadlock!
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type "'a Synchronized.var"} \\
   @{define_ML Synchronized.var: "string -> 'a -> 'a Synchronized.var"} \\
   @{define_ML Synchronized.guarded_access: "'a Synchronized.var ->
   ('a -> ('b * 'a) option) -> 'b"} \\
   \end{mldecls}
 
     \<^descr> Type \<^ML_type>\<open>'a Synchronized.var\<close> represents synchronized variables
     with state of type \<^ML_type>\<open>'a\<close>.
 
     \<^descr> \<^ML>\<open>Synchronized.var\<close>~\<open>name x\<close> creates a synchronized variable that is
     initialized with value \<open>x\<close>. The \<open>name\<close> is used for tracing.
 
     \<^descr> \<^ML>\<open>Synchronized.guarded_access\<close>~\<open>var f\<close> lets the function \<open>f\<close> operate
     within a critical section on the state \<open>x\<close> as follows: if \<open>f x\<close> produces
     \<^ML>\<open>NONE\<close>, it continues to wait on the internal condition variable,
     expecting that some other thread will eventually change the content in a
     suitable manner; if \<open>f x\<close> produces \<^ML>\<open>SOME\<close>~\<open>(y, x')\<close> it is satisfied and
     assigns the new state value \<open>x'\<close>, broadcasts a signal to all waiting threads
     on the associated condition variable, and returns the result \<open>y\<close>.
 
   There are some further variants of the \<^ML>\<open>Synchronized.guarded_access\<close>
   combinator, see \<^file>\<open>~~/src/Pure/Concurrent/synchronized.ML\<close> for details.
 \<close>
 
 text %mlex \<open>
   The following example implements a counter that produces positive integers
   that are unique over the runtime of the Isabelle process:
 \<close>
 
 ML_val \<open>
   local
     val counter = Synchronized.var "counter" 0;
   in
     fun next () =
       Synchronized.guarded_access counter
         (fn i =>
           let val j = i + 1
           in SOME (j, j) end);
   end;
 
   val a = next ();
   val b = next ();
   \<^assert> (a <> b);
 \<close>
 
 text \<open>
   \<^medskip>
   See \<^file>\<open>~~/src/Pure/Concurrent/mailbox.ML\<close> how to implement a mailbox as
   synchronized variable over a purely functional list.
 \<close>
 
 
 section \<open>Managed evaluation\<close>
 
 text \<open>
   Execution of Standard ML follows the model of strict functional evaluation
   with optional exceptions. Evaluation happens whenever some function is
   applied to (sufficiently many) arguments. The result is either an explicit
   value or an implicit exception.
 
   \<^emph>\<open>Managed evaluation\<close> in Isabelle/ML organizes expressions and results to
   control certain physical side-conditions, to say more specifically when and
   how evaluation happens. For example, the Isabelle/ML library supports lazy
   evaluation with memoing, parallel evaluation via futures, asynchronous
   evaluation via promises, evaluation with time limit etc.
 
   \<^medskip>
   An \<^emph>\<open>unevaluated expression\<close> is represented either as unit abstraction
   \<^verbatim>\<open>fn () => a\<close> of type \<^verbatim>\<open>unit -> 'a\<close> or as regular function \<^verbatim>\<open>fn a => b\<close> of
   type \<^verbatim>\<open>'a -> 'b\<close>. Both forms occur routinely, and special care is required
   to tell them apart --- the static type-system of SML is only of limited help
   here.
 
   The first form is more intuitive: some combinator \<^verbatim>\<open>(unit -> 'a) -> 'a\<close>
   applies the given function to \<^verbatim>\<open>()\<close> to initiate the postponed evaluation
   process. The second form is more flexible: some combinator
   \<^verbatim>\<open>('a -> 'b) -> 'a -> 'b\<close> acts like a modified form of function application;
   several such combinators may be cascaded to modify a given function, before
   it is ultimately applied to some argument.
 
   \<^medskip>
   \<^emph>\<open>Reified results\<close> make the disjoint sum of regular values versions
   exceptional situations explicit as ML datatype: \<open>'a result = Res of 'a | Exn
   of exn\<close>. This is typically used for administrative purposes, to store the
   overall outcome of an evaluation process.
 
   \<^emph>\<open>Parallel exceptions\<close> aggregate reified results, such that multiple
   exceptions are digested as a collection in canonical form that identifies
   exceptions according to their original occurrence. This is particular
   important for parallel evaluation via futures \secref{sec:futures}, which
   are organized as acyclic graph of evaluations that depend on other
   evaluations: exceptions stemming from shared sub-graphs are exposed exactly
   once and in the order of their original occurrence (e.g.\ when printed at
   the toplevel). Interrupt counts as neutral element here: it is treated as
   minimal information about some canceled evaluation process, and is absorbed
   by the presence of regular program exceptions.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type "'a Exn.result"} \\
   @{define_ML Exn.capture: "('a -> 'b) -> 'a -> 'b Exn.result"} \\
   @{define_ML Exn.interruptible_capture: "('a -> 'b) -> 'a -> 'b Exn.result"} \\
   @{define_ML Exn.release: "'a Exn.result -> 'a"} \\
   @{define_ML Par_Exn.release_all: "'a Exn.result list -> 'a list"} \\
   @{define_ML Par_Exn.release_first: "'a Exn.result list -> 'a list"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>'a Exn.result\<close> represents the disjoint sum of ML results
   explicitly, with constructor \<^ML>\<open>Exn.Res\<close> for regular values and \<^ML>\<open>Exn.Exn\<close> for exceptions.
 
   \<^descr> \<^ML>\<open>Exn.capture\<close>~\<open>f x\<close> manages the evaluation of \<open>f x\<close> such that
   exceptions are made explicit as \<^ML>\<open>Exn.Exn\<close>. Note that this includes
   physical interrupts (see also \secref{sec:exceptions}), so the same
   precautions apply to user code: interrupts must not be absorbed
   accidentally!
 
   \<^descr> \<^ML>\<open>Exn.interruptible_capture\<close> is similar to \<^ML>\<open>Exn.capture\<close>, but
   interrupts are immediately re-raised as required for user code.
 
   \<^descr> \<^ML>\<open>Exn.release\<close>~\<open>result\<close> releases the original runtime result, exposing
   its regular value or raising the reified exception.
 
   \<^descr> \<^ML>\<open>Par_Exn.release_all\<close>~\<open>results\<close> combines results that were produced
   independently (e.g.\ by parallel evaluation). If all results are regular
   values, that list is returned. Otherwise, the collection of all exceptions
   is raised, wrapped-up as collective parallel exception. Note that the latter
   prevents access to individual exceptions by conventional \<^verbatim>\<open>handle\<close> of ML.
 
   \<^descr> \<^ML>\<open>Par_Exn.release_first\<close> is similar to \<^ML>\<open>Par_Exn.release_all\<close>, but
   only the first (meaningful) exception that has occurred in the original
   evaluation process is raised again, the others are ignored. That single
   exception may get handled by conventional means in ML.
 \<close>
 
 
 subsection \<open>Parallel skeletons \label{sec:parlist}\<close>
 
 text \<open>
   Algorithmic skeletons are combinators that operate on lists in parallel, in
   the manner of well-known \<open>map\<close>, \<open>exists\<close>, \<open>forall\<close> etc. Management of
   futures (\secref{sec:futures}) and their results as reified exceptions is
   wrapped up into simple programming interfaces that resemble the sequential
   versions.
 
   What remains is the application-specific problem to present expressions with
   suitable \<^emph>\<open>granularity\<close>: each list element corresponds to one evaluation
   task. If the granularity is too coarse, the available CPUs are not
   saturated. If it is too fine-grained, CPU cycles are wasted due to the
   overhead of organizing parallel processing. In the worst case, parallel
   performance will be less than the sequential counterpart!
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Par_List.map: "('a -> 'b) -> 'a list -> 'b list"} \\
   @{define_ML Par_List.get_some: "('a -> 'b option) -> 'a list -> 'b option"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Par_List.map\<close>~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> is like \<^ML>\<open>map\<close>~\<open>f [x\<^sub>1, \<dots>,
   x\<^sub>n]\<close>, but the evaluation of \<open>f x\<^sub>i\<close> for \<open>i = 1, \<dots>, n\<close> is performed in
   parallel.
 
   An exception in any \<open>f x\<^sub>i\<close> cancels the overall evaluation process. The
   final result is produced via \<^ML>\<open>Par_Exn.release_first\<close> as explained above,
   which means the first program exception that happened to occur in the
   parallel evaluation is propagated, and all other failures are ignored.
 
   \<^descr> \<^ML>\<open>Par_List.get_some\<close>~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> produces some \<open>f x\<^sub>i\<close> that is of
   the form \<open>SOME y\<^sub>i\<close>, if that exists, otherwise \<open>NONE\<close>. Thus it is similar to
   \<^ML>\<open>Library.get_first\<close>, but subject to a non-deterministic parallel choice
   process. The first successful result cancels the overall evaluation process;
   other exceptions are propagated as for \<^ML>\<open>Par_List.map\<close>.
 
   This generic parallel choice combinator is the basis for derived forms, such
   as \<^ML>\<open>Par_List.find_some\<close>, \<^ML>\<open>Par_List.exists\<close>, \<^ML>\<open>Par_List.forall\<close>.
 \<close>
 
 text %mlex \<open>
   Subsequently, the Ackermann function is evaluated in parallel for some
   ranges of arguments.
 \<close>
 
 ML_val \<open>
   fun ackermann 0 n = n + 1
     | ackermann m 0 = ackermann (m - 1) 1
     | ackermann m n = ackermann (m - 1) (ackermann m (n - 1));
 
   Par_List.map (ackermann 2) (500 upto 1000);
   Par_List.map (ackermann 3) (5 upto 10);
 \<close>
 
 
 subsection \<open>Lazy evaluation\<close>
 
 text \<open>
   Classic lazy evaluation works via the \<open>lazy\<close>~/ \<open>force\<close> pair of operations:
   \<open>lazy\<close> to wrap an unevaluated expression, and \<open>force\<close> to evaluate it once
   and store its result persistently. Later invocations of \<open>force\<close> retrieve the
   stored result without another evaluation. Isabelle/ML refines this idea to
   accommodate the aspects of multi-threading, synchronous program exceptions
   and asynchronous interrupts.
 
   The first thread that invokes \<open>force\<close> on an unfinished lazy value changes
   its state into a \<^emph>\<open>promise\<close> of the eventual result and starts evaluating it.
   Any other threads that \<open>force\<close> the same lazy value in the meantime need to
   wait for it to finish, by producing a regular result or program exception.
   If the evaluation attempt is interrupted, this event is propagated to all
   waiting threads and the lazy value is reset to its original state.
 
   This means a lazy value is completely evaluated at most once, in a
   thread-safe manner. There might be multiple interrupted evaluation attempts,
   and multiple receivers of intermediate interrupt events. Interrupts are
   \<^emph>\<open>not\<close> made persistent: later evaluation attempts start again from the
   original expression.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type "'a lazy"} \\
   @{define_ML Lazy.lazy: "(unit -> 'a) -> 'a lazy"} \\
   @{define_ML Lazy.value: "'a -> 'a lazy"} \\
   @{define_ML Lazy.force: "'a lazy -> 'a"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>'a lazy\<close> represents lazy values over type \<^verbatim>\<open>'a\<close>.
 
   \<^descr> \<^ML>\<open>Lazy.lazy\<close>~\<open>(fn () => e)\<close> wraps the unevaluated expression \<open>e\<close> as
   unfinished lazy value.
 
   \<^descr> \<^ML>\<open>Lazy.value\<close>~\<open>a\<close> wraps the value \<open>a\<close> as finished lazy value. When
   forced, it returns \<open>a\<close> without any further evaluation.
 
   There is very low overhead for this proforma wrapping of strict values as
   lazy values.
 
   \<^descr> \<^ML>\<open>Lazy.force\<close>~\<open>x\<close> produces the result of the lazy value in a
   thread-safe manner as explained above. Thus it may cause the current thread
   to wait on a pending evaluation attempt by another thread.
 \<close>
 
 
 subsection \<open>Futures \label{sec:futures}\<close>
 
 text \<open>
   Futures help to organize parallel execution in a value-oriented manner, with
   \<open>fork\<close>~/ \<open>join\<close> as the main pair of operations, and some further variants;
   see also @{cite "Wenzel:2009" and "Wenzel:2013:ITP"}. Unlike lazy values,
   futures are evaluated strictly and spontaneously on separate worker threads.
   Futures may be canceled, which leads to interrupts on running evaluation
   attempts, and forces structurally related futures to fail for all time;
   already finished futures remain unchanged. Exceptions between related
   futures are propagated as well, and turned into parallel exceptions (see
   above).
 
   Technically, a future is a single-assignment variable together with a
   \<^emph>\<open>task\<close> that serves administrative purposes, notably within the \<^emph>\<open>task
   queue\<close> where new futures are registered for eventual evaluation and the
   worker threads retrieve their work.
 
   The pool of worker threads is limited, in correlation with the number of
   physical cores on the machine. Note that allocation of runtime resources may
   be distorted either if workers yield CPU time (e.g.\ via system sleep or
   wait operations), or if non-worker threads contend for significant runtime
   resources independently. There is a limited number of replacement worker
   threads that get activated in certain explicit wait conditions, after a
   timeout.
 
   \<^medskip>
   Each future task belongs to some \<^emph>\<open>task group\<close>, which represents the
   hierarchic structure of related tasks, together with the exception status a
   that point. By default, the task group of a newly created future is a new
   sub-group of the presently running one, but it is also possible to indicate
   different group layouts under program control.
 
   Cancellation of futures actually refers to the corresponding task group and
   all its sub-groups. Thus interrupts are propagated down the group hierarchy.
   Regular program exceptions are treated likewise: failure of the evaluation
   of some future task affects its own group and all sub-groups. Given a
   particular task group, its \<^emph>\<open>group status\<close> cumulates all relevant exceptions
   according to its position within the group hierarchy. Interrupted tasks that
   lack regular result information, will pick up parallel exceptions from the
   cumulative group status.
 
   \<^medskip>
   A \<^emph>\<open>passive future\<close> or \<^emph>\<open>promise\<close> is a future with slightly different
   evaluation policies: there is only a single-assignment variable and some
   expression to evaluate for the \<^emph>\<open>failed\<close> case (e.g.\ to clean up resources
   when canceled). A regular result is produced by external means, using a
   separate \<^emph>\<open>fulfill\<close> operation.
 
   Promises are managed in the same task queue, so regular futures may depend
   on them. This allows a form of reactive programming, where some promises are
   used as minimal elements (or guards) within the future dependency graph:
   when these promises are fulfilled the evaluation of subsequent futures
   starts spontaneously, according to their own inter-dependencies.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type "'a future"} \\
   @{define_ML Future.fork: "(unit -> 'a) -> 'a future"} \\
   @{define_ML Future.forks: "Future.params -> (unit -> 'a) list -> 'a future list"} \\
   @{define_ML Future.join: "'a future -> 'a"} \\
   @{define_ML Future.joins: "'a future list -> 'a list"} \\
   @{define_ML Future.value: "'a -> 'a future"} \\
   @{define_ML Future.map: "('a -> 'b) -> 'a future -> 'b future"} \\
   @{define_ML Future.cancel: "'a future -> unit"} \\
   @{define_ML Future.cancel_group: "Future.group -> unit"} \\[0.5ex]
   @{define_ML Future.promise: "(unit -> unit) -> 'a future"} \\
   @{define_ML Future.fulfill: "'a future -> 'a -> unit"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>'a future\<close> represents future values over type \<^verbatim>\<open>'a\<close>.
 
   \<^descr> \<^ML>\<open>Future.fork\<close>~\<open>(fn () => e)\<close> registers the unevaluated expression \<open>e\<close>
   as unfinished future value, to be evaluated eventually on the parallel
   worker-thread farm. This is a shorthand for \<^ML>\<open>Future.forks\<close> below, with
   default parameters and a single expression.
 
   \<^descr> \<^ML>\<open>Future.forks\<close>~\<open>params exprs\<close> is the general interface to fork several
   futures simultaneously. The \<open>params\<close> consist of the following fields:
 
     \<^item> \<open>name : string\<close> (default \<^ML>\<open>""\<close>) specifies a common name for the
     tasks of the forked futures, which serves diagnostic purposes.
 
     \<^item> \<open>group : Future.group option\<close> (default \<^ML>\<open>NONE\<close>) specifies an optional
     task group for the forked futures. \<^ML>\<open>NONE\<close> means that a new sub-group
     of the current worker-thread task context is created. If this is not a
     worker thread, the group will be a new root in the group hierarchy.
 
     \<^item> \<open>deps : Future.task list\<close> (default \<^ML>\<open>[]\<close>) specifies dependencies on
     other future tasks, i.e.\ the adjacency relation in the global task queue.
     Dependencies on already finished tasks are ignored.
 
     \<^item> \<open>pri : int\<close> (default \<^ML>\<open>0\<close>) specifies a priority within the task
     queue.
 
     Typically there is only little deviation from the default priority \<^ML>\<open>0\<close>. As a rule of thumb, \<^ML>\<open>~1\<close> means ``low priority" and \<^ML>\<open>1\<close> means
     ``high priority''.
 
     Note that the task priority only affects the position in the queue, not
     the thread priority. When a worker thread picks up a task for processing,
     it runs with the normal thread priority to the end (or until canceled).
     Higher priority tasks that are queued later need to wait until this (or
     another) worker thread becomes free again.
 
     \<^item> \<open>interrupts : bool\<close> (default \<^ML>\<open>true\<close>) tells whether the worker thread
     that processes the corresponding task is initially put into interruptible
     state. This state may change again while running, by modifying the thread
     attributes.
 
     With interrupts disabled, a running future task cannot be canceled. It is
     the responsibility of the programmer that this special state is retained
     only briefly.
 
   \<^descr> \<^ML>\<open>Future.join\<close>~\<open>x\<close> retrieves the value of an already finished future,
   which may lead to an exception, according to the result of its previous
   evaluation.
 
   For an unfinished future there are several cases depending on the role of
   the current thread and the status of the future. A non-worker thread waits
   passively until the future is eventually evaluated. A worker thread
   temporarily changes its task context and takes over the responsibility to
   evaluate the future expression on the spot. The latter is done in a
   thread-safe manner: other threads that intend to join the same future need
   to wait until the ongoing evaluation is finished.
 
   Note that excessive use of dynamic dependencies of futures by adhoc joining
   may lead to bad utilization of CPU cores, due to threads waiting on other
   threads to finish required futures. The future task farm has a limited
   amount of replacement threads that continue working on unrelated tasks after
   some timeout.
 
   Whenever possible, static dependencies of futures should be specified
   explicitly when forked (see \<open>deps\<close> above). Thus the evaluation can work from
   the bottom up, without join conflicts and wait states.
 
   \<^descr> \<^ML>\<open>Future.joins\<close>~\<open>xs\<close> joins the given list of futures simultaneously,
   which is more efficient than \<^ML>\<open>map Future.join\<close>~\<open>xs\<close>.
 
   Based on the dependency graph of tasks, the current thread takes over the
   responsibility to evaluate future expressions that are required for the main
   result, working from the bottom up. Waiting on future results that are
   presently evaluated on other threads only happens as last resort, when no
   other unfinished futures are left over.
 
   \<^descr> \<^ML>\<open>Future.value\<close>~\<open>a\<close> wraps the value \<open>a\<close> as finished future value,
   bypassing the worker-thread farm. When joined, it returns \<open>a\<close> without any
   further evaluation.
 
   There is very low overhead for this proforma wrapping of strict values as
   futures.
 
   \<^descr> \<^ML>\<open>Future.map\<close>~\<open>f x\<close> is a fast-path implementation of \<^ML>\<open>Future.fork\<close>~\<open>(fn () => f (\<close>\<^ML>\<open>Future.join\<close>~\<open>x))\<close>, which avoids the full
   overhead of the task queue and worker-thread farm as far as possible. The
   function \<open>f\<close> is supposed to be some trivial post-processing or projection of
   the future result.
 
   \<^descr> \<^ML>\<open>Future.cancel\<close>~\<open>x\<close> cancels the task group of the given future, using
   \<^ML>\<open>Future.cancel_group\<close> below.
 
   \<^descr> \<^ML>\<open>Future.cancel_group\<close>~\<open>group\<close> cancels all tasks of the given task
   group for all time. Threads that are presently processing a task of the
   given group are interrupted: it may take some time until they are actually
   terminated. Tasks that are queued but not yet processed are dequeued and
   forced into interrupted state. Since the task group is itself invalidated,
   any further attempt to fork a future that belongs to it will yield a
   canceled result as well.
 
   \<^descr> \<^ML>\<open>Future.promise\<close>~\<open>abort\<close> registers a passive future with the given
   \<open>abort\<close> operation: it is invoked when the future task group is canceled.
 
   \<^descr> \<^ML>\<open>Future.fulfill\<close>~\<open>x a\<close> finishes the passive future \<open>x\<close> by the given
   value \<open>a\<close>. If the promise has already been canceled, the attempt to fulfill
   it causes an exception.
 \<close>
 
 end
diff --git a/src/Doc/Implementation/Tactic.thy b/src/Doc/Implementation/Tactic.thy
--- a/src/Doc/Implementation/Tactic.thy
+++ b/src/Doc/Implementation/Tactic.thy
@@ -1,817 +1,817 @@
 (*:maxLineLen=78:*)
 
 theory Tactic
 imports Base
 begin
 
 chapter \<open>Tactical reasoning\<close>
 
 text \<open>
   Tactical reasoning works by refining an initial claim in a backwards
   fashion, until a solved form is reached. A \<open>goal\<close> consists of several
   subgoals that need to be solved in order to achieve the main statement; zero
   subgoals means that the proof may be finished. A \<open>tactic\<close> is a refinement
   operation that maps a goal to a lazy sequence of potential successors. A
   \<open>tactical\<close> is a combinator for composing tactics.
 \<close>
 
 
 section \<open>Goals \label{sec:tactical-goals}\<close>
 
 text \<open>
   Isabelle/Pure represents a goal as a theorem stating that the subgoals imply
   the main goal: \<open>A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> C\<close>. The outermost goal structure is that of
   a Horn Clause: i.e.\ an iterated implication without any quantifiers\<^footnote>\<open>Recall
   that outermost \<open>\<And>x. \<phi>[x]\<close> is always represented via schematic variables in
   the body: \<open>\<phi>[?x]\<close>. These variables may get instantiated during the course of
   reasoning.\<close>. For \<open>n = 0\<close> a goal is called ``solved''.
 
   The structure of each subgoal \<open>A\<^sub>i\<close> is that of a general Hereditary Harrop
   Formula \<open>\<And>x\<^sub>1 \<dots> \<And>x\<^sub>k. H\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> H\<^sub>m \<Longrightarrow> B\<close>. Here \<open>x\<^sub>1, \<dots>, x\<^sub>k\<close> are goal
   parameters, i.e.\ arbitrary-but-fixed entities of certain types, and \<open>H\<^sub>1,
   \<dots>, H\<^sub>m\<close> are goal hypotheses, i.e.\ facts that may be assumed locally.
   Together, this forms the goal context of the conclusion \<open>B\<close> to be
   established. The goal hypotheses may be again arbitrary Hereditary Harrop
   Formulas, although the level of nesting rarely exceeds 1--2 in practice.
 
   The main conclusion \<open>C\<close> is internally marked as a protected proposition,
   which is represented explicitly by the notation \<open>#C\<close> here. This ensures that
   the decomposition into subgoals and main conclusion is well-defined for
   arbitrarily structured claims.
 
   \<^medskip>
   Basic goal management is performed via the following Isabelle/Pure rules:
 
   \[
   \infer[\<open>(init)\<close>]{\<open>C \<Longrightarrow> #C\<close>}{} \qquad
   \infer[\<open>(finish)\<close>]{\<open>C\<close>}{\<open>#C\<close>}
   \]
 
   \<^medskip>
   The following low-level variants admit general reasoning with protected
   propositions:
 
   \[
   \infer[\<open>(protect n)\<close>]{\<open>A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> #C\<close>}{\<open>A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> C\<close>}
   \]
   \[
   \infer[\<open>(conclude)\<close>]{\<open>A \<Longrightarrow> \<dots> \<Longrightarrow> C\<close>}{\<open>A \<Longrightarrow> \<dots> \<Longrightarrow> #C\<close>}
   \]
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Goal.init: "cterm -> thm"} \\
   @{define_ML Goal.finish: "Proof.context -> thm -> thm"} \\
   @{define_ML Goal.protect: "int -> thm -> thm"} \\
   @{define_ML Goal.conclude: "thm -> thm"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Goal.init\<close>~\<open>C\<close> initializes a tactical goal from the well-formed
   proposition \<open>C\<close>.
 
   \<^descr> \<^ML>\<open>Goal.finish\<close>~\<open>ctxt thm\<close> checks whether theorem \<open>thm\<close> is a solved
   goal (no subgoals), and concludes the result by removing the goal
   protection. The context is only required for printing error messages.
 
   \<^descr> \<^ML>\<open>Goal.protect\<close>~\<open>n thm\<close> protects the statement of theorem \<open>thm\<close>. The
   parameter \<open>n\<close> indicates the number of premises to be retained.
 
   \<^descr> \<^ML>\<open>Goal.conclude\<close>~\<open>thm\<close> removes the goal protection, even if there are
   pending subgoals.
 \<close>
 
 
 section \<open>Tactics\label{sec:tactics}\<close>
 
 text \<open>
   A \<open>tactic\<close> is a function \<open>goal \<rightarrow> goal\<^sup>*\<^sup>*\<close> that maps a given goal state
   (represented as a theorem, cf.\ \secref{sec:tactical-goals}) to a lazy
   sequence of potential successor states. The underlying sequence
   implementation is lazy both in head and tail, and is purely functional in
   \<^emph>\<open>not\<close> supporting memoing.\<^footnote>\<open>The lack of memoing and the strict nature of ML
   requires some care when working with low-level sequence operations, to avoid
   duplicate or premature evaluation of results. It also means that modified
   runtime behavior, such as timeout, is very hard to achieve for general
   tactics.\<close>
 
   An \<^emph>\<open>empty result sequence\<close> means that the tactic has failed: in a compound
   tactic expression other tactics might be tried instead, or the whole
   refinement step might fail outright, producing a toplevel error message in
   the end. When implementing tactics from scratch, one should take care to
   observe the basic protocol of mapping regular error conditions to an empty
   result; only serious faults should emerge as exceptions.
 
   By enumerating \<^emph>\<open>multiple results\<close>, a tactic can easily express the
   potential outcome of an internal search process. There are also combinators
   for building proof tools that involve search systematically, see also
   \secref{sec:tacticals}.
 
   \<^medskip>
   As explained before, a goal state essentially consists of a list of subgoals
   that imply the main goal (conclusion). Tactics may operate on all subgoals
   or on a particularly specified subgoal, but must not change the main
   conclusion (apart from instantiating schematic goal variables).
 
   Tactics with explicit \<^emph>\<open>subgoal addressing\<close> are of the form \<open>int \<rightarrow> tactic\<close>
   and may be applied to a particular subgoal (counting from 1). If the subgoal
   number is out of range, the tactic should fail with an empty result
   sequence, but must not raise an exception!
 
   Operating on a particular subgoal means to replace it by an interval of zero
   or more subgoals in the same place; other subgoals must not be affected,
   apart from instantiating schematic variables ranging over the whole goal
   state.
 
   A common pattern of composing tactics with subgoal addressing is to try the
   first one, and then the second one only if the subgoal has not been solved
   yet. Special care is required here to avoid bumping into unrelated subgoals
   that happen to come after the original subgoal. Assuming that there is only
   a single initial subgoal is a very common error when implementing tactics!
 
   Tactics with internal subgoal addressing should expose the subgoal index as
   \<open>int\<close> argument in full generality; a hardwired subgoal 1 is not acceptable.
   
   \<^medskip>
   The main well-formedness conditions for proper tactics are summarized as
   follows.
 
     \<^item> General tactic failure is indicated by an empty result, only serious
     faults may produce an exception.
 
     \<^item> The main conclusion must not be changed, apart from instantiating
     schematic variables.
 
     \<^item> A tactic operates either uniformly on all subgoals, or specifically on a
     selected subgoal (without bumping into unrelated subgoals).
 
     \<^item> Range errors in subgoal addressing produce an empty result.
 
   Some of these conditions are checked by higher-level goal infrastructure
   (\secref{sec:struct-goals}); others are not checked explicitly, and
   violating them merely results in ill-behaved tactics experienced by the user
   (e.g.\ tactics that insist in being applicable only to singleton goals, or
   prevent composition via standard tacticals such as \<^ML>\<open>REPEAT\<close>).
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_type tactic = "thm -> thm Seq.seq"} \\
   @{define_ML no_tac: tactic} \\
   @{define_ML all_tac: tactic} \\
   @{define_ML print_tac: "Proof.context -> string -> tactic"} \\[1ex]
   @{define_ML PRIMITIVE: "(thm -> thm) -> tactic"} \\[1ex]
   @{define_ML SUBGOAL: "(term * int -> tactic) -> int -> tactic"} \\
   @{define_ML CSUBGOAL: "(cterm * int -> tactic) -> int -> tactic"} \\
   @{define_ML SELECT_GOAL: "tactic -> int -> tactic"} \\
   @{define_ML PREFER_GOAL: "tactic -> int -> tactic"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>tactic\<close> represents tactics. The well-formedness conditions
   described above need to be observed. See also \<^file>\<open>~~/src/Pure/General/seq.ML\<close>
   for the underlying implementation of lazy sequences.
 
   \<^descr> Type \<^ML_type>\<open>int -> tactic\<close> represents tactics with explicit subgoal
   addressing, with well-formedness conditions as described above.
 
   \<^descr> \<^ML>\<open>no_tac\<close> is a tactic that always fails, returning the empty sequence.
 
   \<^descr> \<^ML>\<open>all_tac\<close> is a tactic that always succeeds, returning a singleton
   sequence with unchanged goal state.
 
   \<^descr> \<^ML>\<open>print_tac\<close>~\<open>ctxt message\<close> is like \<^ML>\<open>all_tac\<close>, but prints a message
   together with the goal state on the tracing channel.
 
   \<^descr> \<^ML>\<open>PRIMITIVE\<close>~\<open>rule\<close> turns a primitive inference rule into a tactic with
   unique result. Exception \<^ML>\<open>THM\<close> is considered a regular tactic failure
   and produces an empty result; other exceptions are passed through.
 
   \<^descr> \<^ML>\<open>SUBGOAL\<close>~\<open>(fn (subgoal, i) => tactic)\<close> is the most basic form to
   produce a tactic with subgoal addressing. The given abstraction over the
   subgoal term and subgoal number allows to peek at the relevant information
   of the full goal state. The subgoal range is checked as required above.
 
   \<^descr> \<^ML>\<open>CSUBGOAL\<close> is similar to \<^ML>\<open>SUBGOAL\<close>, but passes the subgoal as
   \<^ML_type>\<open>cterm\<close> instead of raw \<^ML_type>\<open>term\<close>. This avoids expensive
   re-certification in situations where the subgoal is used directly for
   primitive inferences.
 
   \<^descr> \<^ML>\<open>SELECT_GOAL\<close>~\<open>tac i\<close> confines a tactic to the specified subgoal \<open>i\<close>.
   This rearranges subgoals and the main goal protection
   (\secref{sec:tactical-goals}), while retaining the syntactic context of the
   overall goal state (concerning schematic variables etc.).
 
   \<^descr> \<^ML>\<open>PREFER_GOAL\<close>~\<open>tac i\<close> rearranges subgoals to put \<open>i\<close> in front. This is
   similar to \<^ML>\<open>SELECT_GOAL\<close>, but without changing the main goal protection.
 \<close>
 
 
 subsection \<open>Resolution and assumption tactics \label{sec:resolve-assume-tac}\<close>
 
 text \<open>
   \<^emph>\<open>Resolution\<close> is the most basic mechanism for refining a subgoal using a
   theorem as object-level rule. \<^emph>\<open>Elim-resolution\<close> is particularly suited for
   elimination rules: it resolves with a rule, proves its first premise by
   assumption, and finally deletes that assumption from any new subgoals.
   \<^emph>\<open>Destruct-resolution\<close> is like elim-resolution, but the given destruction
   rules are first turned into canonical elimination format.
   \<^emph>\<open>Forward-resolution\<close> is like destruct-resolution, but without deleting the
   selected assumption. The \<open>r/e/d/f\<close> naming convention is maintained for
   several different kinds of resolution rules and tactics.
 
   Assumption tactics close a subgoal by unifying some of its premises against
   its conclusion.
 
   \<^medskip>
   All the tactics in this section operate on a subgoal designated by a
   positive integer. Other subgoals might be affected indirectly, due to
   instantiation of schematic variables.
 
   There are various sources of non-determinism, the tactic result sequence
   enumerates all possibilities of the following choices (if applicable):
 
     \<^enum> selecting one of the rules given as argument to the tactic;
 
     \<^enum> selecting a subgoal premise to eliminate, unifying it against the first
     premise of the rule;
 
     \<^enum> unifying the conclusion of the subgoal to the conclusion of the rule.
 
   Recall that higher-order unification may produce multiple results that are
   enumerated here.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML resolve_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML eresolve_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML dresolve_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML forward_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML biresolve_tac: "Proof.context -> (bool * thm) list -> int -> tactic"} \\[1ex]
   @{define_ML assume_tac: "Proof.context -> int -> tactic"} \\
   @{define_ML eq_assume_tac: "int -> tactic"} \\[1ex]
   @{define_ML match_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML ematch_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML dmatch_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{define_ML bimatch_tac: "Proof.context -> (bool * thm) list -> int -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>resolve_tac\<close>~\<open>ctxt thms i\<close> refines the goal state using the given
   theorems, which should normally be introduction rules. The tactic resolves a
   rule's conclusion with subgoal \<open>i\<close>, replacing it by the corresponding
   versions of the rule's premises.
 
   \<^descr> \<^ML>\<open>eresolve_tac\<close>~\<open>ctxt thms i\<close> performs elim-resolution with the given
   theorems, which are normally be elimination rules.
 
   Note that \<^ML_text>\<open>eresolve_tac ctxt [asm_rl]\<close> is equivalent to \<^ML_text>\<open>assume_tac ctxt\<close>, which facilitates mixing of assumption steps with
   genuine eliminations.
 
   \<^descr> \<^ML>\<open>dresolve_tac\<close>~\<open>ctxt thms i\<close> performs destruct-resolution with the
   given theorems, which should normally be destruction rules. This replaces an
   assumption by the result of applying one of the rules.
 
   \<^descr> \<^ML>\<open>forward_tac\<close> is like \<^ML>\<open>dresolve_tac\<close> except that the selected
   assumption is not deleted. It applies a rule to an assumption, adding the
   result as a new assumption.
 
   \<^descr> \<^ML>\<open>biresolve_tac\<close>~\<open>ctxt brls i\<close> refines the proof state by resolution or
   elim-resolution on each rule, as indicated by its flag. It affects subgoal
   \<open>i\<close> of the proof state.
 
   For each pair \<open>(flag, rule)\<close>, it applies resolution if the flag is \<open>false\<close>
   and elim-resolution if the flag is \<open>true\<close>. A single tactic call handles a
   mixture of introduction and elimination rules, which is useful to organize
   the search process systematically in proof tools.
 
   \<^descr> \<^ML>\<open>assume_tac\<close>~\<open>ctxt i\<close> attempts to solve subgoal \<open>i\<close> by assumption
   (modulo higher-order unification).
 
   \<^descr> \<^ML>\<open>eq_assume_tac\<close> is similar to \<^ML>\<open>assume_tac\<close>, but checks only for
   immediate \<open>\<alpha>\<close>-convertibility instead of using unification. It succeeds (with
   a unique next state) if one of the assumptions is equal to the subgoal's
   conclusion. Since it does not instantiate variables, it cannot make other
   subgoals unprovable.
 
   \<^descr> \<^ML>\<open>match_tac\<close>, \<^ML>\<open>ematch_tac\<close>, \<^ML>\<open>dmatch_tac\<close>, and \<^ML>\<open>bimatch_tac\<close>
   are similar to \<^ML>\<open>resolve_tac\<close>, \<^ML>\<open>eresolve_tac\<close>, \<^ML>\<open>dresolve_tac\<close>,
   and \<^ML>\<open>biresolve_tac\<close>, respectively, but do not instantiate schematic
   variables in the goal state.\<^footnote>\<open>Strictly speaking, matching means to treat the
   unknowns in the goal state as constants, but these tactics merely discard
   unifiers that would update the goal state. In rare situations (where the
   conclusion and goal state have flexible terms at the same position), the
   tactic will fail even though an acceptable unifier exists.\<close> These tactics
   were written for a specific application within the classical reasoner.
 
   Flexible subgoals are not updated at will, but are left alone.
 \<close>
 
 
 subsection \<open>Explicit instantiation within a subgoal context\<close>
 
 text \<open>
   The main resolution tactics (\secref{sec:resolve-assume-tac}) use
   higher-order unification, which works well in many practical situations
   despite its daunting theoretical properties. Nonetheless, there are
   important problem classes where unguided higher-order unification is not so
   useful. This typically involves rules like universal elimination,
   existential introduction, or equational substitution. Here the unification
   problem involves fully flexible \<open>?P ?x\<close> schemes, which are hard to manage
   without further hints.
 
   By providing a (small) rigid term for \<open>?x\<close> explicitly, the remaining
   unification problem is to assign a (large) term to \<open>?P\<close>, according to the
   shape of the given subgoal. This is sufficiently well-behaved in most
   practical situations.
 
   \<^medskip>
   Isabelle provides separate versions of the standard \<open>r/e/d/f\<close> resolution
   tactics that allow to provide explicit instantiations of unknowns of the
   given rule, wrt.\ terms that refer to the implicit context of the selected
   subgoal.
 
   An instantiation consists of a list of pairs of the form \<open>(?x, t)\<close>, where
   \<open>?x\<close> is a schematic variable occurring in the given rule, and \<open>t\<close> is a term
   from the current proof context, augmented by the local goal parameters of
   the selected subgoal; cf.\ the \<open>focus\<close> operation described in
   \secref{sec:variables}.
 
   Entering the syntactic context of a subgoal is a brittle operation, because
   its exact form is somewhat accidental, and the choice of bound variable
   names depends on the presence of other local and global names. Explicit
   renaming of subgoal parameters prior to explicit instantiation might help to
   achieve a bit more robustness.
 
   Type instantiations may be given as well, via pairs like \<open>(?'a, \<tau>)\<close>. Type
   instantiations are distinguished from term instantiations by the syntactic
   form of the schematic variable. Types are instantiated before terms are.
   Since term instantiation already performs simple type-inference, so explicit
   type instantiations are seldom necessary.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML Rule_Insts.res_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{define_ML Rule_Insts.eres_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{define_ML Rule_Insts.dres_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{define_ML Rule_Insts.forw_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{define_ML Rule_Insts.subgoal_tac: "Proof.context -> string ->
     (binding * string option * mixfix) list -> int -> tactic"} \\
   @{define_ML Rule_Insts.thin_tac: "Proof.context -> string ->
     (binding * string option * mixfix) list -> int -> tactic"} \\
   @{define_ML rename_tac: "string list -> int -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Rule_Insts.res_inst_tac\<close>~\<open>ctxt insts thm i\<close> instantiates the rule
   \<open>thm\<close> with the instantiations \<open>insts\<close>, as described above, and then performs
   resolution on subgoal \<open>i\<close>.
   
   \<^descr> \<^ML>\<open>Rule_Insts.eres_inst_tac\<close> is like \<^ML>\<open>Rule_Insts.res_inst_tac\<close>, but
   performs elim-resolution.
 
   \<^descr> \<^ML>\<open>Rule_Insts.dres_inst_tac\<close> is like \<^ML>\<open>Rule_Insts.res_inst_tac\<close>, but
   performs destruct-resolution.
 
   \<^descr> \<^ML>\<open>Rule_Insts.forw_inst_tac\<close> is like \<^ML>\<open>Rule_Insts.dres_inst_tac\<close>
   except that the selected assumption is not deleted.
 
   \<^descr> \<^ML>\<open>Rule_Insts.subgoal_tac\<close>~\<open>ctxt \<phi> i\<close> adds the proposition \<open>\<phi>\<close> as local
   premise to subgoal \<open>i\<close>, and poses the same as a new subgoal \<open>i + 1\<close> (in the
   original context).
 
   \<^descr> \<^ML>\<open>Rule_Insts.thin_tac\<close>~\<open>ctxt \<phi> i\<close> deletes the specified premise from
   subgoal \<open>i\<close>. Note that \<open>\<phi>\<close> may contain schematic variables, to abbreviate
   the intended proposition; the first matching subgoal premise will be
   deleted. Removing useless premises from a subgoal increases its readability
   and can make search tactics run faster.
 
   \<^descr> \<^ML>\<open>rename_tac\<close>~\<open>names i\<close> renames the innermost parameters of subgoal \<open>i\<close>
   according to the provided \<open>names\<close> (which need to be distinct identifiers).
 
 
   For historical reasons, the above instantiation tactics take unparsed string
   arguments, which makes them hard to use in general ML code. The slightly
   more advanced \<^ML>\<open>Subgoal.FOCUS\<close> combinator of \secref{sec:struct-goals}
   allows to refer to internal goal structure with explicit context management.
 \<close>
 
 
 subsection \<open>Rearranging goal states\<close>
 
 text \<open>
   In rare situations there is a need to rearrange goal states: either the
   overall collection of subgoals, or the local structure of a subgoal. Various
   administrative tactics allow to operate on the concrete presentation these
   conceptual sets of formulae.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML rotate_tac: "int -> int -> tactic"} \\
   @{define_ML distinct_subgoals_tac: tactic} \\
   @{define_ML flexflex_tac: "Proof.context -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>rotate_tac\<close>~\<open>n i\<close> rotates the premises of subgoal \<open>i\<close> by \<open>n\<close>
   positions: from right to left if \<open>n\<close> is positive, and from left to right if
   \<open>n\<close> is negative.
 
   \<^descr> \<^ML>\<open>distinct_subgoals_tac\<close> removes duplicate subgoals from a proof state.
   This is potentially inefficient.
 
   \<^descr> \<^ML>\<open>flexflex_tac\<close> removes all flex-flex pairs from the proof state by
   applying the trivial unifier. This drastic step loses information. It is
   already part of the Isar infrastructure for facts resulting from goals, and
   rarely needs to be invoked manually.
 
   Flex-flex constraints arise from difficult cases of higher-order
   unification. To prevent this, use \<^ML>\<open>Rule_Insts.res_inst_tac\<close> to
   instantiate some variables in a rule. Normally flex-flex constraints can be
   ignored; they often disappear as unknowns get instantiated.
 \<close>
 
 
 subsection \<open>Raw composition: resolution without lifting\<close>
 
 text \<open>
   Raw composition of two rules means resolving them without prior lifting or
   renaming of unknowns. This low-level operation, which underlies the
   resolution tactics, may occasionally be useful for special effects.
   Schematic variables are not renamed by default, so beware of clashes!
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML compose_tac: "Proof.context -> (bool * thm * int) -> int -> tactic"} \\
   @{define_ML Drule.compose: "thm * int * thm -> thm"} \\
   @{define_ML_infix COMP: "thm * thm -> thm"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>compose_tac\<close>~\<open>ctxt (flag, rule, m) i\<close> refines subgoal \<open>i\<close> using
   \<open>rule\<close>, without lifting. The \<open>rule\<close> is taken to have the form \<open>\<psi>\<^sub>1 \<Longrightarrow> \<dots> \<psi>\<^sub>m \<Longrightarrow>
   \<psi>\<close>, where \<open>\<psi>\<close> need not be atomic; thus \<open>m\<close> determines the number of new
   subgoals. If \<open>flag\<close> is \<open>true\<close> then it performs elim-resolution --- it solves
   the first premise of \<open>rule\<close> by assumption and deletes that assumption.
 
   \<^descr> \<^ML>\<open>Drule.compose\<close>~\<open>(thm\<^sub>1, i, thm\<^sub>2)\<close> uses \<open>thm\<^sub>1\<close>, regarded as an
   atomic formula, to solve premise \<open>i\<close> of \<open>thm\<^sub>2\<close>. Let \<open>thm\<^sub>1\<close> and \<open>thm\<^sub>2\<close> be
   \<open>\<psi>\<close> and \<open>\<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<phi>\<close>. The unique \<open>s\<close> that unifies \<open>\<psi>\<close> and \<open>\<phi>\<^sub>i\<close> yields
   the theorem \<open>(\<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>i\<^sub>-\<^sub>1 \<Longrightarrow> \<phi>\<^sub>i\<^sub>+\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<phi>)s\<close>. Multiple results are
   considered as error (exception \<^ML>\<open>THM\<close>).
 
   \<^descr> \<open>thm\<^sub>1 COMP thm\<^sub>2\<close> is the same as \<open>Drule.compose (thm\<^sub>1, 1, thm\<^sub>2)\<close>.
 
 
   \begin{warn}
   These low-level operations are stepping outside the structure imposed by
   regular rule resolution. Used without understanding of the consequences,
   they may produce results that cause problems with standard rules and tactics
   later on.
   \end{warn}
 \<close>
 
 
 section \<open>Tacticals \label{sec:tacticals}\<close>
 
 text \<open>
   A \<^emph>\<open>tactical\<close> is a functional combinator for building up complex tactics
   from simpler ones. Common tacticals perform sequential composition,
   disjunctive choice, iteration, or goal addressing. Various search strategies
   may be expressed via tacticals.
 \<close>
 
 
 subsection \<open>Combining tactics\<close>
 
 text \<open>
   Sequential composition and alternative choices are the most basic ways to
   combine tactics, similarly to ``\<^verbatim>\<open>,\<close>'' and ``\<^verbatim>\<open>|\<close>'' in Isar method notation.
-  This corresponds to \<^ML_op>\<open>THEN\<close> and \<^ML_op>\<open>ORELSE\<close> in ML, but there
+  This corresponds to \<^ML_infix>\<open>THEN\<close> and \<^ML_infix>\<open>ORELSE\<close> in ML, but there
   are further possibilities for fine-tuning alternation of tactics such as
-  \<^ML_op>\<open>APPEND\<close>. Further details become visible in ML due to explicit
+  \<^ML_infix>\<open>APPEND\<close>. Further details become visible in ML due to explicit
   subgoal addressing.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML_infix "THEN": "tactic * tactic -> tactic"} \\
   @{define_ML_infix "ORELSE": "tactic * tactic -> tactic"} \\
   @{define_ML_infix "APPEND": "tactic * tactic -> tactic"} \\
   @{define_ML "EVERY": "tactic list -> tactic"} \\
   @{define_ML "FIRST": "tactic list -> tactic"} \\[0.5ex]
 
   @{define_ML_infix "THEN'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
   @{define_ML_infix "ORELSE'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
   @{define_ML_infix "APPEND'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
   @{define_ML "EVERY'": "('a -> tactic) list -> 'a -> tactic"} \\
   @{define_ML "FIRST'": "('a -> tactic) list -> 'a -> tactic"} \\
   \end{mldecls}
 
-  \<^descr> \<open>tac\<^sub>1\<close>~\<^ML_op>\<open>THEN\<close>~\<open>tac\<^sub>2\<close> is the sequential composition of \<open>tac\<^sub>1\<close> and
+  \<^descr> \<open>tac\<^sub>1\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>tac\<^sub>2\<close> is the sequential composition of \<open>tac\<^sub>1\<close> and
   \<open>tac\<^sub>2\<close>. Applied to a goal state, it returns all states reachable in two
   steps by applying \<open>tac\<^sub>1\<close> followed by \<open>tac\<^sub>2\<close>. First, it applies \<open>tac\<^sub>1\<close> to
   the goal state, getting a sequence of possible next states; then, it applies
   \<open>tac\<^sub>2\<close> to each of these and concatenates the results to produce again one
   flat sequence of states.
 
-  \<^descr> \<open>tac\<^sub>1\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>tac\<^sub>2\<close> makes a choice between \<open>tac\<^sub>1\<close> and
+  \<^descr> \<open>tac\<^sub>1\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>tac\<^sub>2\<close> makes a choice between \<open>tac\<^sub>1\<close> and
   \<open>tac\<^sub>2\<close>. Applied to a state, it tries \<open>tac\<^sub>1\<close> and returns the result if
   non-empty; if \<open>tac\<^sub>1\<close> fails then it uses \<open>tac\<^sub>2\<close>. This is a deterministic
   choice: if \<open>tac\<^sub>1\<close> succeeds then \<open>tac\<^sub>2\<close> is excluded from the result.
 
-  \<^descr> \<open>tac\<^sub>1\<close>~\<^ML_op>\<open>APPEND\<close>~\<open>tac\<^sub>2\<close> concatenates the possible results of
-  \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close>. Unlike \<^ML_op>\<open>ORELSE\<close> there is \<^emph>\<open>no commitment\<close> to
-  either tactic, so \<^ML_op>\<open>APPEND\<close> helps to avoid incompleteness during
+  \<^descr> \<open>tac\<^sub>1\<close>~\<^ML_infix>\<open>APPEND\<close>~\<open>tac\<^sub>2\<close> concatenates the possible results of
+  \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close>. Unlike \<^ML_infix>\<open>ORELSE\<close> there is \<^emph>\<open>no commitment\<close> to
+  either tactic, so \<^ML_infix>\<open>APPEND\<close> helps to avoid incompleteness during
   search, at the cost of potential inefficiencies.
 
-  \<^descr> \<^ML>\<open>EVERY\<close>~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>n]\<close> abbreviates \<open>tac\<^sub>1\<close>~\<^ML_op>\<open>THEN\<close>~\<open>\<dots>\<close>~\<^ML_op>\<open>THEN\<close>~\<open>tac\<^sub>n\<close>. Note that \<^ML>\<open>EVERY []\<close> is the same as
+  \<^descr> \<^ML>\<open>EVERY\<close>~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>n]\<close> abbreviates \<open>tac\<^sub>1\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>\<dots>\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>tac\<^sub>n\<close>. Note that \<^ML>\<open>EVERY []\<close> is the same as
   \<^ML>\<open>all_tac\<close>: it always succeeds.
 
-  \<^descr> \<^ML>\<open>FIRST\<close>~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>n]\<close> abbreviates \<open>tac\<^sub>1\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>\<dots>\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>tac\<^sub>n\<close>. Note that \<^ML>\<open>FIRST []\<close> is the
+  \<^descr> \<^ML>\<open>FIRST\<close>~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>n]\<close> abbreviates \<open>tac\<^sub>1\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>\<dots>\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>tac\<^sub>n\<close>. Note that \<^ML>\<open>FIRST []\<close> is the
   same as \<^ML>\<open>no_tac\<close>: it always fails.
 
-  \<^descr> \<^ML_op>\<open>THEN'\<close> is the lifted version of \<^ML_op>\<open>THEN\<close>, for tactics
-  with explicit subgoal addressing. So \<open>(tac\<^sub>1\<close>~\<^ML_op>\<open>THEN'\<close>~\<open>tac\<^sub>2) i\<close> is
-  the same as \<open>(tac\<^sub>1 i\<close>~\<^ML_op>\<open>THEN\<close>~\<open>tac\<^sub>2 i)\<close>.
+  \<^descr> \<^ML_infix>\<open>THEN'\<close> is the lifted version of \<^ML_infix>\<open>THEN\<close>, for tactics
+  with explicit subgoal addressing. So \<open>(tac\<^sub>1\<close>~\<^ML_infix>\<open>THEN'\<close>~\<open>tac\<^sub>2) i\<close> is
+  the same as \<open>(tac\<^sub>1 i\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>tac\<^sub>2 i)\<close>.
 
   The other primed tacticals work analogously.
 \<close>
 
 
 subsection \<open>Repetition tacticals\<close>
 
 text \<open>
   These tacticals provide further control over repetition of tactics, beyond
   the stylized forms of ``\<^verbatim>\<open>?\<close>'' and ``\<^verbatim>\<open>+\<close>'' in Isar method expressions.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML "TRY": "tactic -> tactic"} \\
   @{define_ML "REPEAT": "tactic -> tactic"} \\
   @{define_ML "REPEAT1": "tactic -> tactic"} \\
   @{define_ML "REPEAT_DETERM": "tactic -> tactic"} \\
   @{define_ML "REPEAT_DETERM_N": "int -> tactic -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>TRY\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state and returns the resulting
   sequence, if non-empty; otherwise it returns the original state. Thus, it
   applies \<open>tac\<close> at most once.
 
   Note that for tactics with subgoal addressing, the combinator can be applied
-  via functional composition: \<^ML>\<open>TRY\<close>~\<^ML_op>\<open>o\<close>~\<open>tac\<close>. There is no need
+  via functional composition: \<^ML>\<open>TRY\<close>~\<^ML_infix>\<open>o\<close>~\<open>tac\<close>. There is no need
   for \<^verbatim>\<open>TRY'\<close>.
 
   \<^descr> \<^ML>\<open>REPEAT\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state and, recursively, to
   each element of the resulting sequence. The resulting sequence consists of
   those states that make \<open>tac\<close> fail. Thus, it applies \<open>tac\<close> as many times as
   possible (including zero times), and allows backtracking over each
   invocation of \<open>tac\<close>. \<^ML>\<open>REPEAT\<close> is more general than \<^ML>\<open>REPEAT_DETERM\<close>,
   but requires more space.
 
   \<^descr> \<^ML>\<open>REPEAT1\<close>~\<open>tac\<close> is like \<^ML>\<open>REPEAT\<close>~\<open>tac\<close> but it always applies \<open>tac\<close>
   at least once, failing if this is impossible.
 
   \<^descr> \<^ML>\<open>REPEAT_DETERM\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state and,
   recursively, to the head of the resulting sequence. It returns the first
   state to make \<open>tac\<close> fail. It is deterministic, discarding alternative
   outcomes.
 
   \<^descr> \<^ML>\<open>REPEAT_DETERM_N\<close>~\<open>n tac\<close> is like \<^ML>\<open>REPEAT_DETERM\<close>~\<open>tac\<close> but the
   number of repetitions is bound by \<open>n\<close> (where \<^ML>\<open>~1\<close> means \<open>\<infinity>\<close>).
 \<close>
 
 text %mlex \<open>
   The basic tactics and tacticals considered above follow some algebraic laws:
 
-  \<^item> \<^ML>\<open>all_tac\<close> is the identity element of the tactical \<^ML_op>\<open>THEN\<close>.
+  \<^item> \<^ML>\<open>all_tac\<close> is the identity element of the tactical \<^ML_infix>\<open>THEN\<close>.
 
-  \<^item> \<^ML>\<open>no_tac\<close> is the identity element of \<^ML_op>\<open>ORELSE\<close> and \<^ML_op>\<open>APPEND\<close>. Also, it is a zero element for \<^ML_op>\<open>THEN\<close>, which means that
-  \<open>tac\<close>~\<^ML_op>\<open>THEN\<close>~\<^ML>\<open>no_tac\<close> is equivalent to \<^ML>\<open>no_tac\<close>.
+  \<^item> \<^ML>\<open>no_tac\<close> is the identity element of \<^ML_infix>\<open>ORELSE\<close> and \<^ML_infix>\<open>APPEND\<close>. Also, it is a zero element for \<^ML_infix>\<open>THEN\<close>, which means that
+  \<open>tac\<close>~\<^ML_infix>\<open>THEN\<close>~\<^ML>\<open>no_tac\<close> is equivalent to \<^ML>\<open>no_tac\<close>.
 
   \<^item> \<^ML>\<open>TRY\<close> and \<^ML>\<open>REPEAT\<close> can be expressed as (recursive) functions over
   more basic combinators (ignoring some internal implementation tricks):
 \<close>
 
 ML \<open>
   fun TRY tac = tac ORELSE all_tac;
   fun REPEAT tac st = ((tac THEN REPEAT tac) ORELSE all_tac) st;
 \<close>
 
 text \<open>
-  If \<open>tac\<close> can return multiple outcomes then so can \<^ML>\<open>REPEAT\<close>~\<open>tac\<close>. \<^ML>\<open>REPEAT\<close> uses \<^ML_op>\<open>ORELSE\<close> and not \<^ML_op>\<open>APPEND\<close>, it applies \<open>tac\<close>
+  If \<open>tac\<close> can return multiple outcomes then so can \<^ML>\<open>REPEAT\<close>~\<open>tac\<close>. \<^ML>\<open>REPEAT\<close> uses \<^ML_infix>\<open>ORELSE\<close> and not \<^ML_infix>\<open>APPEND\<close>, it applies \<open>tac\<close>
   as many times as possible in each outcome.
 
   \begin{warn}
   Note the explicit abstraction over the goal state in the ML definition of
   \<^ML>\<open>REPEAT\<close>. Recursive tacticals must be coded in this awkward fashion to
   avoid infinite recursion of eager functional evaluation in Standard ML. The
   following attempt would make \<^ML>\<open>REPEAT\<close>~\<open>tac\<close> loop:
   \end{warn}
 \<close>
 
 ML_val \<open>
   (*BAD -- does not terminate!*)
   fun REPEAT tac = (tac THEN REPEAT tac) ORELSE all_tac;
 \<close>
 
 
 subsection \<open>Applying tactics to subgoal ranges\<close>
 
 text \<open>
   Tactics with explicit subgoal addressing \<^ML_type>\<open>int -> tactic\<close> can be
   used together with tacticals that act like ``subgoal quantifiers'': guided
   by success of the body tactic a certain range of subgoals is covered. Thus
   the body tactic is applied to \<^emph>\<open>all\<close> subgoals, \<^emph>\<open>some\<close> subgoal etc.
 
   Suppose that the goal state has \<open>n \<ge> 0\<close> subgoals. Many of these tacticals
   address subgoal ranges counting downwards from \<open>n\<close> towards \<open>1\<close>. This has the
   fortunate effect that newly emerging subgoals are concatenated in the
   result, without interfering each other. Nonetheless, there might be
   situations where a different order is desired.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{define_ML ALLGOALS: "(int -> tactic) -> tactic"} \\
   @{define_ML SOMEGOAL: "(int -> tactic) -> tactic"} \\
   @{define_ML FIRSTGOAL: "(int -> tactic) -> tactic"} \\
   @{define_ML HEADGOAL: "(int -> tactic) -> tactic"} \\
   @{define_ML REPEAT_SOME: "(int -> tactic) -> tactic"} \\
   @{define_ML REPEAT_FIRST: "(int -> tactic) -> tactic"} \\
   @{define_ML RANGE: "(int -> tactic) list -> int -> tactic"} \\
   \end{mldecls}
 
-  \<^descr> \<^ML>\<open>ALLGOALS\<close>~\<open>tac\<close> is equivalent to \<open>tac n\<close>~\<^ML_op>\<open>THEN\<close>~\<open>\<dots>\<close>~\<^ML_op>\<open>THEN\<close>~\<open>tac 1\<close>. It applies the \<open>tac\<close> to all the subgoals, counting downwards.
+  \<^descr> \<^ML>\<open>ALLGOALS\<close>~\<open>tac\<close> is equivalent to \<open>tac n\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>\<dots>\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>tac 1\<close>. It applies the \<open>tac\<close> to all the subgoals, counting downwards.
 
-  \<^descr> \<^ML>\<open>SOMEGOAL\<close>~\<open>tac\<close> is equivalent to \<open>tac n\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>\<dots>\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>tac 1\<close>. It applies \<open>tac\<close> to one subgoal, counting downwards.
+  \<^descr> \<^ML>\<open>SOMEGOAL\<close>~\<open>tac\<close> is equivalent to \<open>tac n\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>\<dots>\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>tac 1\<close>. It applies \<open>tac\<close> to one subgoal, counting downwards.
 
-  \<^descr> \<^ML>\<open>FIRSTGOAL\<close>~\<open>tac\<close> is equivalent to \<open>tac 1\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>\<dots>\<close>~\<^ML_op>\<open>ORELSE\<close>~\<open>tac n\<close>. It applies \<open>tac\<close> to one subgoal, counting upwards.
+  \<^descr> \<^ML>\<open>FIRSTGOAL\<close>~\<open>tac\<close> is equivalent to \<open>tac 1\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>\<dots>\<close>~\<^ML_infix>\<open>ORELSE\<close>~\<open>tac n\<close>. It applies \<open>tac\<close> to one subgoal, counting upwards.
 
   \<^descr> \<^ML>\<open>HEADGOAL\<close>~\<open>tac\<close> is equivalent to \<open>tac 1\<close>. It applies \<open>tac\<close>
   unconditionally to the first subgoal.
 
   \<^descr> \<^ML>\<open>REPEAT_SOME\<close>~\<open>tac\<close> applies \<open>tac\<close> once or more to a subgoal, counting
   downwards.
 
   \<^descr> \<^ML>\<open>REPEAT_FIRST\<close>~\<open>tac\<close> applies \<open>tac\<close> once or more to a subgoal, counting
   upwards.
 
   \<^descr> \<^ML>\<open>RANGE\<close>~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>k] i\<close> is equivalent to \<open>tac\<^sub>k (i + k -
-  1)\<close>~\<^ML_op>\<open>THEN\<close>~\<open>\<dots>\<close>~\<^ML_op>\<open>THEN\<close>~\<open>tac\<^sub>1 i\<close>. It applies the given list of
+  1)\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>\<dots>\<close>~\<^ML_infix>\<open>THEN\<close>~\<open>tac\<^sub>1 i\<close>. It applies the given list of
   tactics to the corresponding range of subgoals, counting downwards.
 \<close>
 
 
 subsection \<open>Control and search tacticals\<close>
 
 text \<open>
   A predicate on theorems \<^ML_type>\<open>thm -> bool\<close> can test whether a goal
   state enjoys some desirable property --- such as having no subgoals. Tactics
   that search for satisfactory goal states are easy to express. The main
   search procedures, depth-first, breadth-first and best-first, are provided
   as tacticals. They generate the search tree by repeatedly applying a given
   tactic.
 \<close>
 
 
 text %mlref ""
 
 subsubsection \<open>Filtering a tactic's results\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML FILTER: "(thm -> bool) -> tactic -> tactic"} \\
   @{define_ML CHANGED: "tactic -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>FILTER\<close>~\<open>sat tac\<close> applies \<open>tac\<close> to the goal state and returns a
   sequence consisting of those result goal states that are satisfactory in the
   sense of \<open>sat\<close>.
 
   \<^descr> \<^ML>\<open>CHANGED\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state and returns precisely
   those states that differ from the original state (according to \<^ML>\<open>Thm.eq_thm\<close>). Thus \<^ML>\<open>CHANGED\<close>~\<open>tac\<close> always has some effect on the state.
 \<close>
 
 
 subsubsection \<open>Depth-first search\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML DEPTH_FIRST: "(thm -> bool) -> tactic -> tactic"} \\
   @{define_ML DEPTH_SOLVE: "tactic -> tactic"} \\
   @{define_ML DEPTH_SOLVE_1: "tactic -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>DEPTH_FIRST\<close>~\<open>sat tac\<close> returns the goal state if \<open>sat\<close> returns true.
   Otherwise it applies \<open>tac\<close>, then recursively searches from each element of
   the resulting sequence. The code uses a stack for efficiency, in effect
-  applying \<open>tac\<close>~\<^ML_op>\<open>THEN\<close>~\<^ML>\<open>DEPTH_FIRST\<close>~\<open>sat tac\<close> to the state.
+  applying \<open>tac\<close>~\<^ML_infix>\<open>THEN\<close>~\<^ML>\<open>DEPTH_FIRST\<close>~\<open>sat tac\<close> to the state.
 
   \<^descr> \<^ML>\<open>DEPTH_SOLVE\<close>\<open>tac\<close> uses \<^ML>\<open>DEPTH_FIRST\<close> to search for states having
   no subgoals.
 
   \<^descr> \<^ML>\<open>DEPTH_SOLVE_1\<close>~\<open>tac\<close> uses \<^ML>\<open>DEPTH_FIRST\<close> to search for states
   having fewer subgoals than the given state. Thus, it insists upon solving at
   least one subgoal.
 \<close>
 
 
 subsubsection \<open>Other search strategies\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML BREADTH_FIRST: "(thm -> bool) -> tactic -> tactic"} \\
   @{define_ML BEST_FIRST: "(thm -> bool) * (thm -> int) -> tactic -> tactic"} \\
   @{define_ML THEN_BEST_FIRST: "tactic -> (thm -> bool) * (thm -> int) -> tactic -> tactic"} \\
   \end{mldecls}
 
   These search strategies will find a solution if one exists. However, they do
   not enumerate all solutions; they terminate after the first satisfactory
   result from \<open>tac\<close>.
 
   \<^descr> \<^ML>\<open>BREADTH_FIRST\<close>~\<open>sat tac\<close> uses breadth-first search to find states for
   which \<open>sat\<close> is true. For most applications, it is too slow.
 
   \<^descr> \<^ML>\<open>BEST_FIRST\<close>~\<open>(sat, dist) tac\<close> does a heuristic search, using \<open>dist\<close>
   to estimate the distance from a satisfactory state (in the sense of \<open>sat\<close>).
   It maintains a list of states ordered by distance. It applies \<open>tac\<close> to the
   head of this list; if the result contains any satisfactory states, then it
   returns them. Otherwise, \<^ML>\<open>BEST_FIRST\<close> adds the new states to the list,
   and continues.
 
   The distance function is typically \<^ML>\<open>size_of_thm\<close>, which computes the
   size of the state. The smaller the state, the fewer and simpler subgoals it
   has.
 
   \<^descr> \<^ML>\<open>THEN_BEST_FIRST\<close>~\<open>tac\<^sub>0 (sat, dist) tac\<close> is like \<^ML>\<open>BEST_FIRST\<close>,
   except that the priority queue initially contains the result of applying
   \<open>tac\<^sub>0\<close> to the goal state. This tactical permits separate tactics for
   starting the search and continuing the search.
 \<close>
 
 
 subsubsection \<open>Auxiliary tacticals for searching\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML COND: "(thm -> bool) -> tactic -> tactic -> tactic"} \\
   @{define_ML IF_UNSOLVED: "tactic -> tactic"} \\
   @{define_ML SOLVE: "tactic -> tactic"} \\
   @{define_ML DETERM: "tactic -> tactic"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>COND\<close>~\<open>sat tac\<^sub>1 tac\<^sub>2\<close> applies \<open>tac\<^sub>1\<close> to the goal state if it
   satisfies predicate \<open>sat\<close>, and applies \<open>tac\<^sub>2\<close>. It is a conditional tactical
   in that only one of \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close> is applied to a goal state. However,
   both \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close> are evaluated because ML uses eager evaluation.
 
   \<^descr> \<^ML>\<open>IF_UNSOLVED\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state if it has any
   subgoals, and simply returns the goal state otherwise. Many common tactics,
   such as \<^ML>\<open>resolve_tac\<close>, fail if applied to a goal state that has no
   subgoals.
 
   \<^descr> \<^ML>\<open>SOLVE\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state and then fails iff there
   are subgoals left.
 
   \<^descr> \<^ML>\<open>DETERM\<close>~\<open>tac\<close> applies \<open>tac\<close> to the goal state and returns the head of
   the resulting sequence. \<^ML>\<open>DETERM\<close> limits the search space by making its
   argument deterministic.
 \<close>
 
 
 subsubsection \<open>Predicates and functions useful for searching\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML has_fewer_prems: "int -> thm -> bool"} \\
   @{define_ML Thm.eq_thm: "thm * thm -> bool"} \\
   @{define_ML Thm.eq_thm_prop: "thm * thm -> bool"} \\
   @{define_ML size_of_thm: "thm -> int"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>has_fewer_prems\<close>~\<open>n thm\<close> reports whether \<open>thm\<close> has fewer than \<open>n\<close>
   premises.
 
   \<^descr> \<^ML>\<open>Thm.eq_thm\<close>~\<open>(thm\<^sub>1, thm\<^sub>2)\<close> reports whether \<open>thm\<^sub>1\<close> and \<open>thm\<^sub>2\<close> are
   equal. Both theorems must have the same conclusions, the same set of
   hypotheses, and the same set of sort hypotheses. Names of bound variables
   are ignored as usual.
 
   \<^descr> \<^ML>\<open>Thm.eq_thm_prop\<close>~\<open>(thm\<^sub>1, thm\<^sub>2)\<close> reports whether the propositions of
   \<open>thm\<^sub>1\<close> and \<open>thm\<^sub>2\<close> are equal. Names of bound variables are ignored.
 
   \<^descr> \<^ML>\<open>size_of_thm\<close>~\<open>thm\<close> computes the size of \<open>thm\<close>, namely the number of
   variables, constants and abstractions in its conclusion. It may serve as a
   distance function for \<^ML>\<open>BEST_FIRST\<close>.
 \<close>
 
 end
diff --git a/src/Doc/Isar_Ref/Document_Preparation.thy b/src/Doc/Isar_Ref/Document_Preparation.thy
--- a/src/Doc/Isar_Ref/Document_Preparation.thy
+++ b/src/Doc/Isar_Ref/Document_Preparation.thy
@@ -1,700 +1,718 @@
 (*:maxLineLen=78:*)
 
 theory Document_Preparation
   imports Main Base
 begin
 
 chapter \<open>Document preparation \label{ch:document-prep}\<close>
 
 text \<open>
   Isabelle/Isar provides a simple document preparation system based on
   {PDF-\LaTeX}, with support for hyperlinks and bookmarks within that format.
   This allows to produce papers, books, theses etc.\ from Isabelle theory
   sources.
 
   {\LaTeX} output is generated while processing a \<^emph>\<open>session\<close> in batch mode, as
   explained in the \<^emph>\<open>The Isabelle System Manual\<close> @{cite "isabelle-system"}.
   The main Isabelle tools to get started with document preparation are
   @{tool_ref mkroot} and @{tool_ref build}.
 
   The classic Isabelle/HOL tutorial @{cite "isabelle-hol-book"} also explains
   some aspects of theory presentation.
 \<close>
 
 
 section \<open>Markup commands \label{sec:markup}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "chapter"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "section"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "subsection"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "subsubsection"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "paragraph"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "subparagraph"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "text"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "txt"} & : & \<open>any \<rightarrow> any\<close> \\
     @{command_def "text_raw"} & : & \<open>any \<rightarrow> any\<close> \\
   \end{matharray}
 
   Markup commands provide a structured way to insert text into the document
   generated from a theory. Each markup command takes a single @{syntax text}
   argument, which is passed as argument to a corresponding {\LaTeX} macro. The
   default macros provided by \<^file>\<open>~~/lib/texinputs/isabelle.sty\<close> can be
   redefined according to the needs of the underlying document and {\LaTeX}
   styles.
 
   Note that formal comments (\secref{sec:comments}) are similar to markup
   commands, but have a different status within Isabelle/Isar syntax.
 
   \<^rail>\<open>
     (@@{command chapter} | @@{command section} | @@{command subsection} |
       @@{command subsubsection} | @@{command paragraph} | @@{command subparagraph})
       @{syntax text} ';'? |
     (@@{command text} | @@{command txt} | @@{command text_raw}) @{syntax text}
   \<close>
 
     \<^descr> @{command chapter}, @{command section}, @{command subsection} etc.\ mark
     section headings within the theory source. This works in any context, even
     before the initial @{command theory} command. The corresponding {\LaTeX}
     macros are \<^verbatim>\<open>\isamarkupchapter\<close>, \<^verbatim>\<open>\isamarkupsection\<close>,
     \<^verbatim>\<open>\isamarkupsubsection\<close> etc.\
 
     \<^descr> @{command text} and @{command txt} specify paragraphs of plain text.
     This corresponds to a {\LaTeX} environment \<^verbatim>\<open>\begin{isamarkuptext}\<close> \<open>\<dots>\<close>
     \<^verbatim>\<open>\end{isamarkuptext}\<close> etc.
 
     \<^descr> @{command text_raw} is similar to @{command text}, but without any
     surrounding markup environment. This allows to inject arbitrary {\LaTeX}
     source into the generated document.
 
   All text passed to any of the above markup commands may refer to formal
   entities via \<^emph>\<open>document antiquotations\<close>, see also \secref{sec:antiq}. These
   are interpreted in the present theory or proof context.
 
   \<^medskip>
   The proof markup commands closely resemble those for theory specifications,
   but have a different formal status and produce different {\LaTeX} macros.
 \<close>
 
 
 section \<open>Document antiquotations \label{sec:antiq}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{antiquotation_def "theory"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "thm"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "lemma"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "prop"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "term"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def term_type} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def typeof} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def const} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def abbrev} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def typ} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def type} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def class} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def locale} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "text"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def goals} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def subgoals} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def prf} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def full_prf} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_text} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def ML} & : & \<open>antiquotation\<close> \\
-    @{antiquotation_def ML_op} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_def} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_ref} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_infix} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_infix_def} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_infix_ref} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def ML_type} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_type_def} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_type_ref} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def ML_structure} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_structure_def} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_structure_ref} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def ML_functor} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_functor_def} & : & \<open>antiquotation\<close> \\
+    @{antiquotation_def ML_functor_ref} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def emph} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def bold} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def verbatim} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def bash_function} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def system_option} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def session} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "file"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "url"} & : & \<open>antiquotation\<close> \\
     @{antiquotation_def "cite"} & : & \<open>antiquotation\<close> \\
     @{command_def "print_antiquotations"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
   \end{matharray}
 
   The overall content of an Isabelle/Isar theory may alternate between formal
   and informal text. The main body consists of formal specification and proof
   commands, interspersed with markup commands (\secref{sec:markup}) or
   document comments (\secref{sec:comments}). The argument of markup commands
   quotes informal text to be printed in the resulting document, but may again
   refer to formal entities via \<^emph>\<open>document antiquotations\<close>.
 
   For example, embedding \<^verbatim>\<open>@{term [show_types] "f x = a + x"}\<close>
   within a text block makes
   \isa{{\isacharparenleft}f{\isasymColon}{\isacharprime}a\ {\isasymRightarrow}\ {\isacharprime}a{\isacharparenright}\ {\isacharparenleft}x{\isasymColon}{\isacharprime}a{\isacharparenright}\ {\isacharequal}\ {\isacharparenleft}a{\isasymColon}{\isacharprime}a{\isacharparenright}\ {\isacharplus}\ x} appear in the final {\LaTeX} document.
 
   Antiquotations usually spare the author tedious typing of logical entities
   in full detail. Even more importantly, some degree of consistency-checking
   between the main body of formal text and its informal explanation is
   achieved, since terms and types appearing in antiquotations are checked
   within the current theory or proof context.
 
   \<^medskip>
   Antiquotations are in general written as
   \<^verbatim>\<open>@{\<close>\<open>name\<close>~\<^verbatim>\<open>[\<close>\<open>options\<close>\<^verbatim>\<open>]\<close>~\<open>arguments\<close>\<^verbatim>\<open>}\<close>. The short form
   \<^verbatim>\<open>\\<close>\<^verbatim>\<open><^\<close>\<open>name\<close>\<^verbatim>\<open>>\<close>\<open>\<open>argument_content\<close>\<close> (without surrounding \<^verbatim>\<open>@{\<close>\<open>\<dots>\<close>\<^verbatim>\<open>}\<close>)
   works for a single argument that is a cartouche. A cartouche without special
   decoration is equivalent to \<^verbatim>\<open>\<^cartouche>\<close>\<open>\<open>argument_content\<close>\<close>, which is
   equivalent to \<^verbatim>\<open>@{cartouche\<close>~\<open>\<open>argument_content\<close>\<close>\<^verbatim>\<open>}\<close>. The special name
   @{antiquotation_def cartouche} is defined in the context: Isabelle/Pure
   introduces that as an alias to @{antiquotation_ref text} (see below).
   Consequently, \<open>\<open>foo_bar + baz \<le> bazar\<close>\<close> prints literal quasi-formal text
   (unchecked). A control symbol \<^verbatim>\<open>\\<close>\<^verbatim>\<open><^\<close>\<open>name\<close>\<^verbatim>\<open>>\<close> within the body text, but
   without a subsequent cartouche, is equivalent to \<^verbatim>\<open>@{\<close>\<open>name\<close>\<^verbatim>\<open>}\<close>.
 
   \begingroup
   \def\isasymcontrolstart{\isatt{\isacharbackslash\isacharless\isacharcircum}}
   \<^rail>\<open>
     @{syntax_def antiquotation}:
       '@{' antiquotation_body '}' |
       '\<controlstart>' @{syntax_ref name} '>' @{syntax_ref cartouche} |
       @{syntax_ref cartouche}
     ;
     options: '[' (option * ',') ']'
     ;
     option: @{syntax name} | @{syntax name} '=' @{syntax name}
     ;
   \<close>
   \endgroup
 
   Note that the syntax of antiquotations may \<^emph>\<open>not\<close> include source comments
   \<^verbatim>\<open>(*\<close>~\<open>\<dots>\<close>~\<^verbatim>\<open>*)\<close> nor verbatim text \<^verbatim>\<open>{*\<close>~\<open>\<dots>\<close>~\<^verbatim>\<open>*}\<close>.
 
   %% FIXME less monolithic presentation, move to individual sections!?
   \<^rail>\<open>
     @{syntax_def antiquotation_body}:
       (@@{antiquotation text} | @@{antiquotation cartouche} | @@{antiquotation theory_text})
         options @{syntax text} |
       @@{antiquotation theory} options @{syntax embedded} |
       @@{antiquotation thm} options styles @{syntax thms} |
       @@{antiquotation lemma} options @{syntax prop} @'by' @{syntax method} @{syntax method}? |
       @@{antiquotation prop} options styles @{syntax prop} |
       @@{antiquotation term} options styles @{syntax term} |
       @@{antiquotation (HOL) value} options styles @{syntax term} |
       @@{antiquotation term_type} options styles @{syntax term} |
       @@{antiquotation typeof} options styles @{syntax term} |
       @@{antiquotation const} options @{syntax term} |
       @@{antiquotation abbrev} options @{syntax term} |
       @@{antiquotation typ} options @{syntax type} |
       @@{antiquotation type} options @{syntax embedded} |
       @@{antiquotation class} options @{syntax embedded} |
       @@{antiquotation locale} options @{syntax embedded} |
       (@@{antiquotation command} | @@{antiquotation method} | @@{antiquotation attribute})
         options @{syntax name}
     ;
     @{syntax antiquotation}:
       @@{antiquotation goals} options |
       @@{antiquotation subgoals} options |
       @@{antiquotation prf} options @{syntax thms} |
       @@{antiquotation full_prf} options @{syntax thms} |
+      @@{antiquotation ML_text} options @{syntax text} |
       @@{antiquotation ML} options @{syntax text} |
-      @@{antiquotation ML_op} options @{syntax text} |
+      @@{antiquotation ML_infix} options @{syntax text} |
       @@{antiquotation ML_type} options @{syntax text} |
       @@{antiquotation ML_structure} options @{syntax text} |
       @@{antiquotation ML_functor} options @{syntax text} |
       @@{antiquotation emph} options @{syntax text} |
       @@{antiquotation bold} options @{syntax text} |
       @@{antiquotation verbatim} options @{syntax text} |
       @@{antiquotation bash_function} options @{syntax embedded} |
       @@{antiquotation system_option} options @{syntax embedded} |
       @@{antiquotation session} options @{syntax embedded} |
       @@{antiquotation path} options @{syntax embedded} |
       @@{antiquotation "file"} options @{syntax name} |
       @@{antiquotation dir} options @{syntax name} |
       @@{antiquotation url} options @{syntax embedded} |
       @@{antiquotation cite} options @{syntax cartouche}? (@{syntax name} + @'and')
     ;
     styles: '(' (style + ',') ')'
     ;
     style: (@{syntax name} +)
     ;
     @@{command print_antiquotations} ('!'?)
   \<close>
 
   \<^descr> \<open>@{text s}\<close> prints uninterpreted source text \<open>s\<close>, i.e.\ inner syntax. This
   is particularly useful to print portions of text according to the Isabelle
   document style, without demanding well-formedness, e.g.\ small pieces of
   terms that should not be parsed or type-checked yet.
 
   It is also possible to write this in the short form \<open>\<open>s\<close>\<close> without any
   further decoration.
 
   \<^descr> \<open>@{theory_text s}\<close> prints uninterpreted theory source text \<open>s\<close>, i.e.\
   outer syntax with command keywords and other tokens.
 
   \<^descr> \<open>@{theory A}\<close> prints the session-qualified theory name \<open>A\<close>, which is
   guaranteed to refer to a valid ancestor theory in the current context.
 
   \<^descr> \<open>@{thm a\<^sub>1 \<dots> a\<^sub>n}\<close> prints theorems \<open>a\<^sub>1 \<dots> a\<^sub>n\<close>. Full fact expressions are
   allowed here, including attributes (\secref{sec:syn-att}).
 
   \<^descr> \<open>@{prop \<phi>}\<close> prints a well-typed proposition \<open>\<phi>\<close>.
 
   \<^descr> \<open>@{lemma \<phi> by m}\<close> proves a well-typed proposition \<open>\<phi>\<close> by method \<open>m\<close> and
   prints the original \<open>\<phi>\<close>.
 
   \<^descr> \<open>@{term t}\<close> prints a well-typed term \<open>t\<close>.
   
   \<^descr> \<open>@{value t}\<close> evaluates a term \<open>t\<close> and prints its result, see also
   @{command_ref (HOL) value}.
 
   \<^descr> \<open>@{term_type t}\<close> prints a well-typed term \<open>t\<close> annotated with its type.
 
   \<^descr> \<open>@{typeof t}\<close> prints the type of a well-typed term \<open>t\<close>.
 
   \<^descr> \<open>@{const c}\<close> prints a logical or syntactic constant \<open>c\<close>.
   
   \<^descr> \<open>@{abbrev c x\<^sub>1 \<dots> x\<^sub>n}\<close> prints a constant abbreviation \<open>c x\<^sub>1 \<dots> x\<^sub>n \<equiv> rhs\<close>
   as defined in the current context.
 
   \<^descr> \<open>@{typ \<tau>}\<close> prints a well-formed type \<open>\<tau>\<close>.
 
   \<^descr> \<open>@{type \<kappa>}\<close> prints a (logical or syntactic) type constructor \<open>\<kappa>\<close>.
 
   \<^descr> \<open>@{class c}\<close> prints a class \<open>c\<close>.
 
   \<^descr> \<open>@{locale c}\<close> prints a locale \<open>c\<close>.
 
   \<^descr> \<open>@{command name}\<close>, \<open>@{method name}\<close>, \<open>@{attribute name}\<close> print checked
   entities of the Isar language.
 
   \<^descr> \<open>@{goals}\<close> prints the current \<^emph>\<open>dynamic\<close> goal state. This is mainly for
   support of tactic-emulation scripts within Isar. Presentation of goal states
   does not conform to the idea of human-readable proof documents!
 
   When explaining proofs in detail it is usually better to spell out the
   reasoning via proper Isar proof commands, instead of peeking at the internal
   machine configuration.
   
   \<^descr> \<open>@{subgoals}\<close> is similar to \<open>@{goals}\<close>, but does not print the main goal.
   
   \<^descr> \<open>@{prf a\<^sub>1 \<dots> a\<^sub>n}\<close> prints the (compact) proof terms corresponding to the
   theorems \<open>a\<^sub>1 \<dots> a\<^sub>n\<close>. Note that this requires proof terms to be switched on
   for the current logic session.
   
   \<^descr> \<open>@{full_prf a\<^sub>1 \<dots> a\<^sub>n}\<close> is like \<open>@{prf a\<^sub>1 \<dots> a\<^sub>n}\<close>, but prints the full
   proof terms, i.e.\ also displays information omitted in the compact proof
   term, which is denoted by ``\<open>_\<close>'' placeholders there.
-  
-  \<^descr> \<open>@{ML s}\<close>, \<open>@{ML_op s}\<close>, \<open>@{ML_type s}\<close>, \<open>@{ML_structure s}\<close>, and
+
+  \<^descr> \<open>@{ML_text s}\<close> prints ML text verbatim: only the token language is
+  checked.
+
+  \<^descr> \<open>@{ML s}\<close>, \<open>@{ML_infix s}\<close>, \<open>@{ML_type s}\<close>, \<open>@{ML_structure s}\<close>, and
   \<open>@{ML_functor s}\<close> check text \<open>s\<close> as ML value, infix operator, type,
-  structure, and functor respectively. The source is printed verbatim.
+  exception, structure, and functor respectively. The source is printed
+  verbatim. The variants \<open>@{ML_def s}\<close> and \<open>@{ML_ref s}\<close> etc. maintain the
+  document index: ``def'' means to make a bold entry, ``ref'' means to make a
+  regular entry.
 
   \<^descr> \<open>@{emph s}\<close> prints document source recursively, with {\LaTeX} markup
   \<^verbatim>\<open>\emph{\<close>\<open>\<dots>\<close>\<^verbatim>\<open>}\<close>.
 
   \<^descr> \<open>@{bold s}\<close> prints document source recursively, with {\LaTeX} markup
   \<^verbatim>\<open>\textbf{\<close>\<open>\<dots>\<close>\<^verbatim>\<open>}\<close>.
 
   \<^descr> \<open>@{verbatim s}\<close> prints uninterpreted source text literally as ASCII
   characters, using some type-writer font style.
 
   \<^descr> \<open>@{bash_function name}\<close> prints the given GNU bash function verbatim. The
   name is checked wrt.\ the Isabelle system environment @{cite
   "isabelle-system"}.
 
   \<^descr> \<open>@{system_option name}\<close> prints the given system option verbatim. The name
   is checked wrt.\ cumulative \<^verbatim>\<open>etc/options\<close> of all Isabelle components,
   notably \<^file>\<open>~~/etc/options\<close>.
 
   \<^descr> \<open>@{session name}\<close> prints given session name verbatim. The name is checked
   wrt.\ the dependencies of the current session.
 
   \<^descr> \<open>@{path name}\<close> prints the file-system path name verbatim.
 
   \<^descr> \<open>@{file name}\<close> is like \<open>@{path name}\<close>, but ensures that \<open>name\<close> refers to a
   plain file.
 
   \<^descr> \<open>@{dir name}\<close> is like \<open>@{path name}\<close>, but ensures that \<open>name\<close> refers to a
   directory.
 
   \<^descr> \<open>@{url name}\<close> produces markup for the given URL, which results in an
   active hyperlink within the text.
 
   \<^descr> \<open>@{cite name}\<close> produces a citation \<^verbatim>\<open>\cite{name}\<close> in {\LaTeX}, where the
   name refers to some Bib{\TeX} database entry. This is only checked in
   batch-mode session builds.
 
   The variant \<open>@{cite \<open>opt\<close> name}\<close> produces \<^verbatim>\<open>\cite[opt]{name}\<close> with some
   free-form optional argument. Multiple names are output with commas, e.g.
   \<open>@{cite foo \<AND> bar}\<close> becomes \<^verbatim>\<open>\cite{foo,bar}\<close>.
 
   The {\LaTeX} macro name is determined by the antiquotation option
   @{antiquotation_option_def cite_macro}, or the configuration option
   @{attribute cite_macro} in the context. For example, \<open>@{cite [cite_macro =
   nocite] foobar}\<close> produces \<^verbatim>\<open>\nocite{foobar}\<close>.
 
   \<^descr> @{command "print_antiquotations"} prints all document antiquotations that
   are defined in the current context; the ``\<open>!\<close>'' option indicates extra
   verbosity.
 \<close>
 
 
 subsection \<open>Styled antiquotations\<close>
 
 text \<open>
   The antiquotations \<open>thm\<close>, \<open>prop\<close> and \<open>term\<close> admit an extra \<^emph>\<open>style\<close>
   specification to modify the printed result. A style is specified by a name
   with a possibly empty number of arguments; multiple styles can be sequenced
   with commas. The following standard styles are available:
 
   \<^descr> \<open>lhs\<close> extracts the first argument of any application form with at least
   two arguments --- typically meta-level or object-level equality, or any
   other binary relation.
   
   \<^descr> \<open>rhs\<close> is like \<open>lhs\<close>, but extracts the second argument.
   
   \<^descr> \<open>concl\<close> extracts the conclusion \<open>C\<close> from a rule in Horn-clause normal form
   \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> C\<close>.
   
   \<^descr> \<open>prem\<close> \<open>n\<close> extract premise number \<open>n\<close> from from a rule in Horn-clause
   normal form \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> C\<close>.
 \<close>
 
 
 subsection \<open>General options\<close>
 
 text \<open>
   The following options are available to tune the printed output of
   antiquotations. Note that many of these coincide with system and
   configuration options of the same names.
 
     \<^descr> @{antiquotation_option_def show_types}~\<open>= bool\<close> and
     @{antiquotation_option_def show_sorts}~\<open>= bool\<close> control printing of
     explicit type and sort constraints.
 
     \<^descr> @{antiquotation_option_def show_structs}~\<open>= bool\<close> controls printing of
     implicit structures.
 
     \<^descr> @{antiquotation_option_def show_abbrevs}~\<open>= bool\<close> controls folding of
     abbreviations.
 
     \<^descr> @{antiquotation_option_def names_long}~\<open>= bool\<close> forces names of types
     and constants etc.\ to be printed in their fully qualified internal form.
 
     \<^descr> @{antiquotation_option_def names_short}~\<open>= bool\<close> forces names of types
     and constants etc.\ to be printed unqualified. Note that internalizing the
     output again in the current context may well yield a different result.
 
     \<^descr> @{antiquotation_option_def names_unique}~\<open>= bool\<close> determines whether the
     printed version of qualified names should be made sufficiently long to
     avoid overlap with names declared further back. Set to \<open>false\<close> for more
     concise output.
 
     \<^descr> @{antiquotation_option_def eta_contract}~\<open>= bool\<close> prints terms in
     \<open>\<eta>\<close>-contracted form.
 
     \<^descr> @{antiquotation_option_def display}~\<open>= bool\<close> indicates if the text is to
     be output as multi-line ``display material'', rather than a small piece of
     text without line breaks (which is the default).
 
     In this mode the embedded entities are printed in the same style as the
     main theory text.
 
     \<^descr> @{antiquotation_option_def break}~\<open>= bool\<close> controls line breaks in
     non-display material.
 
     \<^descr> @{antiquotation_option_def cartouche}~\<open>= bool\<close> indicates if the output
     should be delimited as cartouche.
 
     \<^descr> @{antiquotation_option_def quotes}~\<open>= bool\<close> indicates if the output
     should be delimited via double quotes (option @{antiquotation_option
     cartouche} takes precedence). Note that the Isabelle {\LaTeX} styles may
     suppress quotes on their own account.
 
     \<^descr> @{antiquotation_option_def mode}~\<open>= name\<close> adds \<open>name\<close> to the print mode
     to be used for presentation. Note that the standard setup for {\LaTeX}
     output is already present by default, with mode ``\<open>latex\<close>''.
 
     \<^descr> @{antiquotation_option_def margin}~\<open>= nat\<close> and
     @{antiquotation_option_def indent}~\<open>= nat\<close> change the margin or
     indentation for pretty printing of display material.
 
     \<^descr> @{antiquotation_option_def goals_limit}~\<open>= nat\<close> determines the maximum
     number of subgoals to be printed (for goal-based antiquotation).
 
     \<^descr> @{antiquotation_option_def source}~\<open>= bool\<close> prints the original source
     text of the antiquotation arguments, rather than its internal
     representation. Note that formal checking of @{antiquotation "thm"},
     @{antiquotation "term"}, etc. is still enabled; use the @{antiquotation
     "text"} antiquotation for unchecked output.
 
     Regular \<open>term\<close> and \<open>typ\<close> antiquotations with \<open>source = false\<close> involve a
     full round-trip from the original source to an internalized logical entity
     back to a source form, according to the syntax of the current context.
     Thus the printed output is not under direct control of the author, it may
     even fluctuate a bit as the underlying theory is changed later on.
 
     In contrast, @{antiquotation_option source}~\<open>= true\<close> admits direct
     printing of the given source text, with the desirable well-formedness
     check in the background, but without modification of the printed text.
 
     Cartouche delimiters of the argument are stripped for antiquotations that
     are internally categorized as ``embedded''.
 
     \<^descr> @{antiquotation_option_def source_cartouche} is like
     @{antiquotation_option source}, but cartouche delimiters are always
     preserved in the output.
 
   For Boolean flags, ``\<open>name = true\<close>'' may be abbreviated as ``\<open>name\<close>''. All
   of the above flags are disabled by default, unless changed specifically for
   a logic session in the corresponding \<^verbatim>\<open>ROOT\<close> file.
 \<close>
 
 
 section \<open>Markdown-like text structure\<close>
 
 text \<open>
   The markup commands @{command_ref text}, @{command_ref txt}, @{command_ref
   text_raw} (\secref{sec:markup}) consist of plain text. Its internal
   structure consists of paragraphs and (nested) lists, using special Isabelle
   symbols and some rules for indentation and blank lines. This quasi-visual
   format resembles \<^emph>\<open>Markdown\<close>\<^footnote>\<open>\<^url>\<open>http://commonmark.org\<close>\<close>, but the full
   complexity of that notation is avoided.
 
   This is a summary of the main principles of minimal Markdown in Isabelle:
 
     \<^item> List items start with the following markers
       \<^descr>[itemize:] \<^verbatim>\<open>\<^item>\<close>
       \<^descr>[enumerate:] \<^verbatim>\<open>\<^enum>\<close>
       \<^descr>[description:] \<^verbatim>\<open>\<^descr>\<close>
 
     \<^item> Adjacent list items with same indentation and same marker are grouped
     into a single list.
 
     \<^item> Singleton blank lines separate paragraphs.
 
     \<^item> Multiple blank lines escape from the current list hierarchy.
 
   Notable differences to official Markdown:
 
     \<^item> Indentation of list items needs to match exactly.
 
     \<^item> Indentation is unlimited (official Markdown interprets four spaces as
     block quote).
 
     \<^item> List items always consist of paragraphs --- there is no notion of
     ``tight'' list.
 
     \<^item> Section headings are expressed via Isar document markup commands
     (\secref{sec:markup}).
 
     \<^item> URLs, font styles, other special content is expressed via antiquotations
     (\secref{sec:antiq}), usually with proper nesting of sub-languages via
     text cartouches.
 \<close>
 
 
 section \<open>Document markers and command tags \label{sec:document-markers}\<close>
 
 text \<open>
   \emph{Document markers} are formal comments of the form \<open>\<^marker>\<open>marker_body\<close>\<close>
   (using the control symbol \<^verbatim>\<open>\<^marker>\<close>) and may occur anywhere within the
   outer syntax of a command: the inner syntax of a marker body resembles that
   for attributes (\secref{sec:syn-att}). In contrast, \emph{Command tags} may
   only occur after a command keyword and are treated as special markers as
   explained below.
 
   \<^rail>\<open>
     @{syntax_def marker}: '\<^marker>' @{syntax cartouche}
     ;
     @{syntax_def marker_body}: (@{syntax name} @{syntax args} * ',')
     ;
     @{syntax_def tags}: tag*
     ;
     tag: '%' (@{syntax short_ident} | @{syntax string})
   \<close>
 
   Document markers are stripped from the document output, but surrounding
   white-space is preserved: e.g.\ a marker at the end of a line does not
   affect the subsequent line break. Markers operate within the semantic
   presentation context of a command, and may modify it to change the overall
   appearance of a command span (e.g.\ by adding tags).
 
   Each document marker has its own syntax defined in the theory context; the
   following markers are predefined in Isabelle/Pure:
 
   \<^rail>\<open>
     (@@{document_marker_def title} |
      @@{document_marker_def creator} |
      @@{document_marker_def contributor} |
      @@{document_marker_def date} |
      @@{document_marker_def license} |
      @@{document_marker_def description}) @{syntax embedded}
     ;
     @@{document_marker_def tag} (scope?) @{syntax name}
     ;
     scope: '(' ('proof' | 'command') ')'
   \<close>
 
     \<^descr> \<open>\<^marker>\<open>title arg\<close>\<close>, \<open>\<^marker>\<open>creator arg\<close>\<close>, \<open>\<^marker>\<open>contributor arg\<close>\<close>, \<open>\<^marker>\<open>date arg\<close>\<close>,
     \<open>\<^marker>\<open>license arg\<close>\<close>, and \<open>\<^marker>\<open>description arg\<close>\<close> produce markup in the PIDE
     document, without any immediate effect on typesetting. This vocabulary is
     taken from the Dublin Core Metadata
     Initiative\<^footnote>\<open>\<^url>\<open>https://www.dublincore.org/specifications/dublin-core/dcmi-terms\<close>\<close>.
     The argument is an uninterpreted string, except for @{document_marker
     description}, which consists of words that are subject to spell-checking.
 
     \<^descr> \<open>\<^marker>\<open>tag name\<close>\<close> updates the list of command tags in the presentation
     context: later declarations take precedence, so \<open>\<^marker>\<open>tag a, tag b, tag c\<close>\<close>
     produces a reversed list. The default tags are given by the original
     \<^theory_text>\<open>keywords\<close> declaration of a command, and the system option
     @{system_option_ref document_tags}.
 
     The optional \<open>scope\<close> tells how far the tagging is applied to subsequent
     proof structure: ``\<^theory_text>\<open>("proof")\<close>'' means it applies to the following proof
     text, and ``\<^theory_text>\<open>(command)\<close>'' means it only applies to the current command.
     The default within a proof body is ``\<^theory_text>\<open>("proof")\<close>'', but for toplevel goal
     statements it is ``\<^theory_text>\<open>(command)\<close>''. Thus a \<open>tag\<close> marker for \<^theory_text>\<open>theorem\<close>,
     \<^theory_text>\<open>lemma\<close> etc. does \emph{not} affect its proof by default.
 
     An old-style command tag \<^verbatim>\<open>%\<close>\<open>name\<close> is treated like a document marker
     \<open>\<^marker>\<open>tag (proof) name\<close>\<close>: the list of command tags precedes the list of
     document markers. The head of the resulting tags in the presentation
     context is turned into {\LaTeX} environments to modify the type-setting.
     The following tags are pre-declared for certain classes of commands, and
     serve as default markup for certain kinds of commands:
 
     \<^medskip>
     \begin{tabular}{ll}
       \<open>document\<close> & document markup commands \\
       \<open>theory\<close> & theory begin/end \\
       \<open>proof\<close> & all proof commands \\
       \<open>ML\<close> & all commands involving ML code \\
     \end{tabular}
     \<^medskip>
 
   The Isabelle document preparation system @{cite "isabelle-system"} allows
   tagged command regions to be presented specifically, e.g.\ to fold proof
   texts, or drop parts of the text completely.
 
   For example ``\<^theory_text>\<open>by auto\<close>~\<open>\<^marker>\<open>tag invisible\<close>\<close>'' causes that piece of proof to
   be treated as \<open>invisible\<close> instead of \<open>proof\<close> (the default), which may be
   shown or hidden depending on the document setup. In contrast, ``\<^theory_text>\<open>by
   auto\<close>~\<open>\<^marker>\<open>tag visible\<close>\<close>'' forces this text to be shown invariably.
 
   Explicit tag specifications within a proof apply to all subsequent commands
   of the same level of nesting. For example, ``\<^theory_text>\<open>proof\<close>~\<open>\<^marker>\<open>tag invisible\<close>
   \<dots>\<close>~\<^theory_text>\<open>qed\<close>'' forces the whole sub-proof to be typeset as \<open>visible\<close> (unless
   some of its parts are tagged differently).
 
   \<^medskip>
   Command tags merely produce certain markup environments for type-setting.
   The meaning of these is determined by {\LaTeX} macros, as defined in
   \<^file>\<open>~~/lib/texinputs/isabelle.sty\<close> or by the document author. The Isabelle
   document preparation tools also provide some high-level options to specify
   the meaning of arbitrary tags to ``keep'', ``drop'', or ``fold'' the
   corresponding parts of the text. Logic sessions may also specify ``document
   versions'', where given tags are interpreted in some particular way. Again
   see @{cite "isabelle-system"} for further details.
 \<close>
 
 
 section \<open>Railroad diagrams\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{antiquotation_def "rail"} & : & \<open>antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     'rail' @{syntax text}
   \<close>
 
   The @{antiquotation rail} antiquotation allows to include syntax diagrams
   into Isabelle documents. {\LaTeX} requires the style file
   \<^file>\<open>~~/lib/texinputs/railsetup.sty\<close>, which can be used via
   \<^verbatim>\<open>\usepackage{railsetup}\<close> in \<^verbatim>\<open>root.tex\<close>, for example.
 
   The rail specification language is quoted here as Isabelle @{syntax string}
   or text @{syntax "cartouche"}; it has its own grammar given below.
 
   \begingroup
   \def\isasymnewline{\isatt{\isacharbackslash\isacharless newline\isachargreater}}
   \<^rail>\<open>
   rule? + ';'
   ;
   rule: ((identifier | @{syntax antiquotation}) ':')? body
   ;
   body: concatenation + '|'
   ;
   concatenation: ((atom '?'?) +) (('*' | '+') atom?)?
   ;
   atom: '(' body? ')' | identifier |
     '@'? (string | @{syntax antiquotation}) |
     '\<newline>'
   \<close>
   \endgroup
 
   The lexical syntax of \<open>identifier\<close> coincides with that of @{syntax
   short_ident} in regular Isabelle syntax, but \<open>string\<close> uses single quotes
   instead of double quotes of the standard @{syntax string} category.
 
   Each \<open>rule\<close> defines a formal language (with optional name), using a notation
   that is similar to EBNF or regular expressions with recursion. The meaning
   and visual appearance of these rail language elements is illustrated by the
   following representative examples.
 
   \<^item> Empty \<^verbatim>\<open>()\<close>
 
   \<^rail>\<open>()\<close>
 
   \<^item> Nonterminal \<^verbatim>\<open>A\<close>
 
   \<^rail>\<open>A\<close>
 
   \<^item> Nonterminal via Isabelle antiquotation \<^verbatim>\<open>@{syntax method}\<close>
 
   \<^rail>\<open>@{syntax method}\<close>
 
   \<^item> Terminal \<^verbatim>\<open>'xyz'\<close>
 
   \<^rail>\<open>'xyz'\<close>
 
   \<^item> Terminal in keyword style \<^verbatim>\<open>@'xyz'\<close>
 
   \<^rail>\<open>@'xyz'\<close>
 
   \<^item> Terminal via Isabelle antiquotation \<^verbatim>\<open>@@{method rule}\<close>
 
   \<^rail>\<open>@@{method rule}\<close>
 
   \<^item> Concatenation \<^verbatim>\<open>A B C\<close>
 
   \<^rail>\<open>A B C\<close>
 
   \<^item> Newline inside concatenation \<^verbatim>\<open>A B C \<newline> D E F\<close>
 
   \<^rail>\<open>A B C \<newline> D E F\<close>
 
   \<^item> Variants \<^verbatim>\<open>A | B | C\<close>
 
   \<^rail>\<open>A | B | C\<close>
 
   \<^item> Option \<^verbatim>\<open>A ?\<close>
 
   \<^rail>\<open>A ?\<close>
 
   \<^item> Repetition \<^verbatim>\<open>A *\<close>
 
   \<^rail>\<open>A *\<close>
 
   \<^item> Repetition with separator \<^verbatim>\<open>A * sep\<close>
 
   \<^rail>\<open>A * sep\<close>
 
   \<^item> Strict repetition \<^verbatim>\<open>A +\<close>
 
   \<^rail>\<open>A +\<close>
 
   \<^item> Strict repetition with separator \<^verbatim>\<open>A + sep\<close>
 
   \<^rail>\<open>A + sep\<close>
 \<close>
 
 end
diff --git a/src/Doc/Isar_Ref/Generic.thy b/src/Doc/Isar_Ref/Generic.thy
--- a/src/Doc/Isar_Ref/Generic.thy
+++ b/src/Doc/Isar_Ref/Generic.thy
@@ -1,1827 +1,1827 @@
 (*:maxLineLen=78:*)
 
 theory Generic
 imports Main Base
 begin
 
 chapter \<open>Generic tools and packages \label{ch:gen-tools}\<close>
 
 section \<open>Configuration options \label{sec:config}\<close>
 
 text \<open>
   Isabelle/Pure maintains a record of named configuration options within the
   theory or proof context, with values of type \<^ML_type>\<open>bool\<close>, \<^ML_type>\<open>int\<close>, \<^ML_type>\<open>real\<close>, or \<^ML_type>\<open>string\<close>. Tools may declare options in
   ML, and then refer to these values (relative to the context). Thus global
   reference variables are easily avoided. The user may change the value of a
   configuration option by means of an associated attribute of the same name.
   This form of context declaration works particularly well with commands such
   as @{command "declare"} or @{command "using"} like this:
 \<close>
 
 (*<*)experiment begin(*>*)
 declare [[show_main_goal = false]]
 
 notepad
 begin
   note [[show_main_goal = true]]
 end
 (*<*)end(*>*)
 
 text \<open>
   \begin{matharray}{rcll}
     @{command_def "print_options"} & : & \<open>context \<rightarrow>\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{command print_options} ('!'?)
     ;
     @{syntax name} ('=' ('true' | 'false' | @{syntax int} | @{syntax float} | @{syntax name}))?
   \<close>
 
   \<^descr> @{command "print_options"} prints the available configuration options,
   with names, types, and current values; the ``\<open>!\<close>'' option indicates extra
   verbosity.
   
   \<^descr> \<open>name = value\<close> as an attribute expression modifies the named option, with
   the syntax of the value depending on the option's type. For \<^ML_type>\<open>bool\<close>
   the default value is \<open>true\<close>. Any attempt to change a global option in a
   local context is ignored.
 \<close>
 
 
 section \<open>Basic proof tools\<close>
 
 subsection \<open>Miscellaneous methods and attributes \label{sec:misc-meth-att}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{method_def unfold} & : & \<open>method\<close> \\
     @{method_def fold} & : & \<open>method\<close> \\
     @{method_def insert} & : & \<open>method\<close> \\[0.5ex]
     @{method_def erule}\<open>\<^sup>*\<close> & : & \<open>method\<close> \\
     @{method_def drule}\<open>\<^sup>*\<close> & : & \<open>method\<close> \\
     @{method_def frule}\<open>\<^sup>*\<close> & : & \<open>method\<close> \\
     @{method_def intro} & : & \<open>method\<close> \\
     @{method_def elim} & : & \<open>method\<close> \\
     @{method_def fail} & : & \<open>method\<close> \\
     @{method_def succeed} & : & \<open>method\<close> \\
     @{method_def sleep} & : & \<open>method\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     (@@{method fold} | @@{method unfold} | @@{method insert}) @{syntax thms}
     ;
     (@@{method erule} | @@{method drule} | @@{method frule})
       ('(' @{syntax nat} ')')? @{syntax thms}
     ;
     (@@{method intro} | @@{method elim}) @{syntax thms}?
     ;
     @@{method sleep} @{syntax real}
   \<close>
 
   \<^descr> @{method unfold}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> and @{method fold}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> expand (or
   fold back) the given definitions throughout all goals; any chained facts
   provided are inserted into the goal and subject to rewriting as well.
 
   Unfolding works in two stages: first, the given equations are used directly
   for rewriting; second, the equations are passed through the attribute
   @{attribute_ref abs_def} before rewriting --- to ensure that definitions are
   fully expanded, regardless of the actual parameters that are provided.
 
   \<^descr> @{method insert}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> inserts theorems as facts into all goals of
   the proof state. Note that current facts indicated for forward chaining are
   ignored.
 
   \<^descr> @{method erule}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close>, @{method drule}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close>, and @{method
   frule}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> are similar to the basic @{method rule} method (see
   \secref{sec:pure-meth-att}), but apply rules by elim-resolution,
   destruct-resolution, and forward-resolution, respectively @{cite
   "isabelle-implementation"}. The optional natural number argument (default 0)
   specifies additional assumption steps to be performed here.
 
   Note that these methods are improper ones, mainly serving for
   experimentation and tactic script emulation. Different modes of basic rule
   application are usually expressed in Isar at the proof language level,
   rather than via implicit proof state manipulations. For example, a proper
   single-step elimination would be done using the plain @{method rule} method,
   with forward chaining of current facts.
 
   \<^descr> @{method intro} and @{method elim} repeatedly refine some goal by intro-
   or elim-resolution, after having inserted any chained facts. Exactly the
   rules given as arguments are taken into account; this allows fine-tuned
   decomposition of a proof problem, in contrast to common automated tools.
 
   \<^descr> @{method fail} yields an empty result sequence; it is the identity of the
   ``\<open>|\<close>'' method combinator (cf.\ \secref{sec:proof-meth}).
 
   \<^descr> @{method succeed} yields a single (unchanged) result; it is the identity
   of the ``\<open>,\<close>'' method combinator (cf.\ \secref{sec:proof-meth}).
 
   \<^descr> @{method sleep}~\<open>s\<close> succeeds after a real-time delay of \<open>s\<close> seconds. This
   is occasionally useful for demonstration and testing purposes.
 
 
   \begin{matharray}{rcl}
     @{attribute_def tagged} & : & \<open>attribute\<close> \\
     @{attribute_def untagged} & : & \<open>attribute\<close> \\[0.5ex]
     @{attribute_def THEN} & : & \<open>attribute\<close> \\
     @{attribute_def unfolded} & : & \<open>attribute\<close> \\
     @{attribute_def folded} & : & \<open>attribute\<close> \\
     @{attribute_def abs_def} & : & \<open>attribute\<close> \\[0.5ex]
     @{attribute_def rotated} & : & \<open>attribute\<close> \\
     @{attribute_def (Pure) elim_format} & : & \<open>attribute\<close> \\
     @{attribute_def no_vars}\<open>\<^sup>*\<close> & : & \<open>attribute\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{attribute tagged} @{syntax name} @{syntax name}
     ;
     @@{attribute untagged} @{syntax name}
     ;
     @@{attribute THEN} ('[' @{syntax nat} ']')? @{syntax thm}
     ;
     (@@{attribute unfolded} | @@{attribute folded}) @{syntax thms}
     ;
     @@{attribute rotated} @{syntax int}?
   \<close>
 
   \<^descr> @{attribute tagged}~\<open>name value\<close> and @{attribute untagged}~\<open>name\<close> add and
   remove \<^emph>\<open>tags\<close> of some theorem. Tags may be any list of string pairs that
   serve as formal comment. The first string is considered the tag name, the
   second its value. Note that @{attribute untagged} removes any tags of the
   same name.
 
   \<^descr> @{attribute THEN}~\<open>a\<close> composes rules by resolution; it resolves with the
   first premise of \<open>a\<close> (an alternative position may be also specified). See
-  also \<^ML_op>\<open>RS\<close> in @{cite "isabelle-implementation"}.
+  also \<^ML_infix>\<open>RS\<close> in @{cite "isabelle-implementation"}.
   
   \<^descr> @{attribute unfolded}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> and @{attribute folded}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close>
   expand and fold back again the given definitions throughout a rule.
 
   \<^descr> @{attribute abs_def} turns an equation of the form \<^prop>\<open>f x y \<equiv> t\<close>
   into \<^prop>\<open>f \<equiv> \<lambda>x y. t\<close>, which ensures that @{method simp} steps always
   expand it. This also works for object-logic equality.
 
   \<^descr> @{attribute rotated}~\<open>n\<close> rotate the premises of a theorem by \<open>n\<close> (default
   1).
 
   \<^descr> @{attribute (Pure) elim_format} turns a destruction rule into elimination
   rule format, by resolving with the rule \<^prop>\<open>PROP A \<Longrightarrow> (PROP A \<Longrightarrow> PROP B) \<Longrightarrow>
   PROP B\<close>.
   
   Note that the Classical Reasoner (\secref{sec:classical}) provides its own
   version of this operation.
 
   \<^descr> @{attribute no_vars} replaces schematic variables by free ones; this is
   mainly for tuning output of pretty printed theorems.
 \<close>
 
 
 subsection \<open>Low-level equational reasoning\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{method_def subst} & : & \<open>method\<close> \\
     @{method_def hypsubst} & : & \<open>method\<close> \\
     @{method_def split} & : & \<open>method\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{method subst} ('(' 'asm' ')')? \<newline> ('(' (@{syntax nat}+) ')')? @{syntax thm}
     ;
     @@{method split} @{syntax thms}
   \<close>
 
   These methods provide low-level facilities for equational reasoning that are
   intended for specialized applications only. Normally, single step
   calculations would be performed in a structured text (see also
   \secref{sec:calculation}), while the Simplifier methods provide the
   canonical way for automated normalization (see \secref{sec:simplifier}).
 
   \<^descr> @{method subst}~\<open>eq\<close> performs a single substitution step using rule \<open>eq\<close>,
   which may be either a meta or object equality.
 
   \<^descr> @{method subst}~\<open>(asm) eq\<close> substitutes in an assumption.
 
   \<^descr> @{method subst}~\<open>(i \<dots> j) eq\<close> performs several substitutions in the
   conclusion. The numbers \<open>i\<close> to \<open>j\<close> indicate the positions to substitute at.
   Positions are ordered from the top of the term tree moving down from left to
   right. For example, in \<open>(a + b) + (c + d)\<close> there are three positions where
   commutativity of \<open>+\<close> is applicable: 1 refers to \<open>a + b\<close>, 2 to the whole
   term, and 3 to \<open>c + d\<close>.
 
   If the positions in the list \<open>(i \<dots> j)\<close> are non-overlapping (e.g.\ \<open>(2 3)\<close> in
   \<open>(a + b) + (c + d)\<close>) you may assume all substitutions are performed
   simultaneously. Otherwise the behaviour of \<open>subst\<close> is not specified.
 
   \<^descr> @{method subst}~\<open>(asm) (i \<dots> j) eq\<close> performs the substitutions in the
   assumptions. The positions refer to the assumptions in order from left to
   right. For example, given in a goal of the form \<open>P (a + b) \<Longrightarrow> P (c + d) \<Longrightarrow> \<dots>\<close>,
   position 1 of commutativity of \<open>+\<close> is the subterm \<open>a + b\<close> and position 2 is
   the subterm \<open>c + d\<close>.
 
   \<^descr> @{method hypsubst} performs substitution using some assumption; this only
   works for equations of the form \<open>x = t\<close> where \<open>x\<close> is a free or bound
   variable.
 
   \<^descr> @{method split}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> performs single-step case splitting using the
   given rules. Splitting is performed in the conclusion or some assumption of
   the subgoal, depending of the structure of the rule.
   
   Note that the @{method simp} method already involves repeated application of
   split rules as declared in the current context, using @{attribute split},
   for example.
 \<close>
 
 
 section \<open>The Simplifier \label{sec:simplifier}\<close>
 
 text \<open>
   The Simplifier performs conditional and unconditional rewriting and uses
   contextual information: rule declarations in the background theory or local
   proof context are taken into account, as well as chained facts and subgoal
   premises (``local assumptions''). There are several general hooks that allow
   to modify the simplification strategy, or incorporate other proof tools that
   solve sub-problems, produce rewrite rules on demand etc.
 
   The rewriting strategy is always strictly bottom up, except for congruence
   rules, which are applied while descending into a term. Conditions in
   conditional rewrite rules are solved recursively before the rewrite rule is
   applied.
 
   The default Simplifier setup of major object logics (HOL, HOLCF, FOL, ZF)
   makes the Simplifier ready for immediate use, without engaging into the
   internal structures. Thus it serves as general-purpose proof tool with the
   main focus on equational reasoning, and a bit more than that.
 \<close>
 
 
 subsection \<open>Simplification methods \label{sec:simp-meth}\<close>
 
 text \<open>
   \begin{tabular}{rcll}
     @{method_def simp} & : & \<open>method\<close> \\
     @{method_def simp_all} & : & \<open>method\<close> \\
     \<open>Pure.\<close>@{method_def (Pure) simp} & : & \<open>method\<close> \\
     \<open>Pure.\<close>@{method_def (Pure) simp_all} & : & \<open>method\<close> \\
     @{attribute_def simp_depth_limit} & : & \<open>attribute\<close> & default \<open>100\<close> \\
   \end{tabular}
   \<^medskip>
 
   \<^rail>\<open>
     (@@{method simp} | @@{method simp_all}) opt? (@{syntax simpmod} * )
     ;
 
     opt: '(' ('no_asm' | 'no_asm_simp' | 'no_asm_use' | 'asm_lr' ) ')'
     ;
     @{syntax_def simpmod}: ('add' | 'del' | 'flip' | 'only' |
       'split' (() | '!' | 'del') | 'cong' (() | 'add' | 'del'))
     ':' @{syntax thms}
   \<close>
 
   \<^descr> @{method simp} invokes the Simplifier on the first subgoal, after
   inserting chained facts as additional goal premises; further rule
   declarations may be included via \<open>(simp add: facts)\<close>. The proof method fails
   if the subgoal remains unchanged after simplification.
 
   Note that the original goal premises and chained facts are subject to
   simplification themselves, while declarations via \<open>add\<close>/\<open>del\<close> merely follow
   the policies of the object-logic to extract rewrite rules from theorems,
   without further simplification. This may lead to slightly different behavior
   in either case, which might be required precisely like that in some boundary
   situations to perform the intended simplification step!
 
   \<^medskip>
 Modifier \<open>flip\<close> deletes the following theorems from the simpset and adds
 their symmetric version (i.e.\ lhs and rhs exchanged). No warning is shown
 if the original theorem was not present.
 
   \<^medskip>
   The \<open>only\<close> modifier first removes all other rewrite rules, looper tactics
   (including split rules), congruence rules, and then behaves like \<open>add\<close>.
   Implicit solvers remain, which means that trivial rules like reflexivity or
   introduction of \<open>True\<close> are available to solve the simplified subgoals, but
   also non-trivial tools like linear arithmetic in HOL. The latter may lead to
   some surprise of the meaning of ``only'' in Isabelle/HOL compared to
   English!
 
   \<^medskip>
   The \<open>split\<close> modifiers add or delete rules for the Splitter (see also
   \secref{sec:simp-strategies} on the looper). This works only if the
   Simplifier method has been properly setup to include the Splitter (all major
   object logics such HOL, HOLCF, FOL, ZF do this already).
   The \<open>!\<close> option causes the split rules to be used aggressively:
   after each application of a split rule in the conclusion, the \<open>safe\<close>
   tactic of the classical reasoner (see \secref{sec:classical:partial})
   is applied to the new goal. The net effect is that the goal is split into
   the different cases. This option can speed up simplification of goals
   with many nested conditional or case expressions significantly.
 
   There is also a separate @{method_ref split} method available for
   single-step case splitting. The effect of repeatedly applying \<open>(split thms)\<close>
   can be imitated by ``\<open>(simp only: split: thms)\<close>''.
 
   \<^medskip>
   The \<open>cong\<close> modifiers add or delete Simplifier congruence rules (see also
   \secref{sec:simp-rules}); the default is to add.
 
   \<^descr> @{method simp_all} is similar to @{method simp}, but acts on all goals,
   working backwards from the last to the first one as usual in Isabelle.\<^footnote>\<open>The
   order is irrelevant for goals without schematic variables, so simplification
   might actually be performed in parallel here.\<close>
 
   Chained facts are inserted into all subgoals, before the simplification
   process starts. Further rule declarations are the same as for @{method
   simp}.
 
   The proof method fails if all subgoals remain unchanged after
   simplification.
 
   \<^descr> @{attribute simp_depth_limit} limits the number of recursive invocations
   of the Simplifier during conditional rewriting.
 
 
   By default the Simplifier methods above take local assumptions fully into
   account, using equational assumptions in the subsequent normalization
   process, or simplifying assumptions themselves. Further options allow to
   fine-tune the behavior of the Simplifier in this respect, corresponding to a
   variety of ML tactics as follows.\<^footnote>\<open>Unlike the corresponding Isar proof
   methods, the ML tactics do not insist in changing the goal state.\<close>
 
   \begin{center}
   \small
   \begin{tabular}{|l|l|p{0.3\textwidth}|}
   \hline
   Isar method & ML tactic & behavior \\\hline
 
   \<open>(simp (no_asm))\<close> & \<^ML>\<open>simp_tac\<close> & assumptions are ignored completely
   \\\hline
 
   \<open>(simp (no_asm_simp))\<close> & \<^ML>\<open>asm_simp_tac\<close> & assumptions are used in the
   simplification of the conclusion but are not themselves simplified \\\hline
 
   \<open>(simp (no_asm_use))\<close> & \<^ML>\<open>full_simp_tac\<close> & assumptions are simplified but
   are not used in the simplification of each other or the conclusion \\\hline
 
   \<open>(simp)\<close> & \<^ML>\<open>asm_full_simp_tac\<close> & assumptions are used in the
   simplification of the conclusion and to simplify other assumptions \\\hline
 
   \<open>(simp (asm_lr))\<close> & \<^ML>\<open>asm_lr_simp_tac\<close> & compatibility mode: an
   assumption is only used for simplifying assumptions which are to the right
   of it \\\hline
 
   \end{tabular}
   \end{center}
 
   \<^medskip>
   In Isabelle/Pure, proof methods @{method (Pure) simp} and @{method (Pure)
   simp_all} only know about meta-equality \<open>\<equiv>\<close>. Any new object-logic needs to
   re-define these methods via \<^ML>\<open>Simplifier.method_setup\<close> in ML:
   Isabelle/FOL or Isabelle/HOL may serve as blue-prints.
 \<close>
 
 
 subsubsection \<open>Examples\<close>
 
 text \<open>
   We consider basic algebraic simplifications in Isabelle/HOL. The rather
   trivial goal \<^prop>\<open>0 + (x + 0) = x + 0 + 0\<close> looks like a good candidate
   to be solved by a single call of @{method simp}:
 \<close>
 
 lemma "0 + (x + 0) = x + 0 + 0" apply simp? oops
 
 text \<open>
   The above attempt \<^emph>\<open>fails\<close>, because \<^term>\<open>0\<close> and \<^term>\<open>(+)\<close> in the
   HOL library are declared as generic type class operations, without stating
   any algebraic laws yet. More specific types are required to get access to
   certain standard simplifications of the theory context, e.g.\ like this:\<close>
 
 lemma fixes x :: nat shows "0 + (x + 0) = x + 0 + 0" by simp
 lemma fixes x :: int shows "0 + (x + 0) = x + 0 + 0" by simp
 lemma fixes x :: "'a :: monoid_add" shows "0 + (x + 0) = x + 0 + 0" by simp
 
 text \<open>
   \<^medskip>
   In many cases, assumptions of a subgoal are also needed in the
   simplification process. For example:
 \<close>
 
 lemma fixes x :: nat shows "x = 0 \<Longrightarrow> x + x = 0" by simp
 lemma fixes x :: nat assumes "x = 0" shows "x + x = 0" apply simp oops
 lemma fixes x :: nat assumes "x = 0" shows "x + x = 0" using assms by simp
 
 text \<open>
   As seen above, local assumptions that shall contribute to simplification
   need to be part of the subgoal already, or indicated explicitly for use by
   the subsequent method invocation. Both too little or too much information
   can make simplification fail, for different reasons.
 
   In the next example the malicious assumption \<^prop>\<open>\<And>x::nat. f x = g (f (g
   x))\<close> does not contribute to solve the problem, but makes the default
   @{method simp} method loop: the rewrite rule \<open>f ?x \<equiv> g (f (g ?x))\<close> extracted
   from the assumption does not terminate. The Simplifier notices certain
   simple forms of nontermination, but not this one. The problem can be solved
   nonetheless, by ignoring assumptions via special options as explained
   before:
 \<close>
 
 lemma "(\<And>x::nat. f x = g (f (g x))) \<Longrightarrow> f 0 = f 0 + 0"
   by (simp (no_asm))
 
 text \<open>
   The latter form is typical for long unstructured proof scripts, where the
   control over the goal content is limited. In structured proofs it is usually
   better to avoid pushing too many facts into the goal state in the first
   place. Assumptions in the Isar proof context do not intrude the reasoning if
   not used explicitly. This is illustrated for a toplevel statement and a
   local proof body as follows:
 \<close>
 
 lemma
   assumes "\<And>x::nat. f x = g (f (g x))"
   shows "f 0 = f 0 + 0" by simp
 
 notepad
 begin
   assume "\<And>x::nat. f x = g (f (g x))"
   have "f 0 = f 0 + 0" by simp
 end
 
 text \<open>
   \<^medskip>
   Because assumptions may simplify each other, there can be very subtle cases
   of nontermination. For example, the regular @{method simp} method applied to
   \<^prop>\<open>P (f x) \<Longrightarrow> y = x \<Longrightarrow> f x = f y \<Longrightarrow> Q\<close> gives rise to the infinite
   reduction sequence
   \[
   \<open>P (f x)\<close> \stackrel{\<open>f x \<equiv> f y\<close>}{\longmapsto}
   \<open>P (f y)\<close> \stackrel{\<open>y \<equiv> x\<close>}{\longmapsto}
   \<open>P (f x)\<close> \stackrel{\<open>f x \<equiv> f y\<close>}{\longmapsto} \cdots
   \]
   whereas applying the same to \<^prop>\<open>y = x \<Longrightarrow> f x = f y \<Longrightarrow> P (f x) \<Longrightarrow> Q\<close>
   terminates (without solving the goal):
 \<close>
 
 lemma "y = x \<Longrightarrow> f x = f y \<Longrightarrow> P (f x) \<Longrightarrow> Q"
   apply simp
   oops
 
 text \<open>
   See also \secref{sec:simp-trace} for options to enable Simplifier trace
   mode, which often helps to diagnose problems with rewrite systems.
 \<close>
 
 
 subsection \<open>Declaring rules \label{sec:simp-rules}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{attribute_def simp} & : & \<open>attribute\<close> \\
     @{attribute_def split} & : & \<open>attribute\<close> \\
     @{attribute_def cong} & : & \<open>attribute\<close> \\
     @{command_def "print_simpset"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     (@@{attribute simp} | @@{attribute cong}) (() | 'add' | 'del') |
     @@{attribute split} (() | '!' | 'del')
     ;
     @@{command print_simpset} ('!'?)
   \<close>
 
   \<^descr> @{attribute simp} declares rewrite rules, by adding or deleting them from
   the simpset within the theory or proof context. Rewrite rules are theorems
   expressing some form of equality, for example:
 
   \<open>Suc ?m + ?n = ?m + Suc ?n\<close> \\
   \<open>?P \<and> ?P \<longleftrightarrow> ?P\<close> \\
   \<open>?A \<union> ?B \<equiv> {x. x \<in> ?A \<or> x \<in> ?B}\<close>
 
   \<^medskip>
   Conditional rewrites such as \<open>?m < ?n \<Longrightarrow> ?m div ?n = 0\<close> are also permitted;
   the conditions can be arbitrary formulas.
 
   \<^medskip>
   Internally, all rewrite rules are translated into Pure equalities, theorems
   with conclusion \<open>lhs \<equiv> rhs\<close>. The simpset contains a function for extracting
   equalities from arbitrary theorems, which is usually installed when the
   object-logic is configured initially. For example, \<open>\<not> ?x \<in> {}\<close> could be
   turned into \<open>?x \<in> {} \<equiv> False\<close>. Theorems that are declared as @{attribute
   simp} and local assumptions within a goal are treated uniformly in this
   respect.
 
   The Simplifier accepts the following formats for the \<open>lhs\<close> term:
 
     \<^enum> First-order patterns, considering the sublanguage of application of
     constant operators to variable operands, without \<open>\<lambda>\<close>-abstractions or
     functional variables. For example:
 
     \<open>(?x + ?y) + ?z \<equiv> ?x + (?y + ?z)\<close> \\
     \<open>f (f ?x ?y) ?z \<equiv> f ?x (f ?y ?z)\<close>
 
     \<^enum> Higher-order patterns in the sense of @{cite "nipkow-patterns"}. These
     are terms in \<open>\<beta>\<close>-normal form (this will always be the case unless you have
     done something strange) where each occurrence of an unknown is of the form
     \<open>?F x\<^sub>1 \<dots> x\<^sub>n\<close>, where the \<open>x\<^sub>i\<close> are distinct bound variables.
 
     For example, \<open>(\<forall>x. ?P x \<and> ?Q x) \<equiv> (\<forall>x. ?P x) \<and> (\<forall>x. ?Q x)\<close> or its
     symmetric form, since the \<open>rhs\<close> is also a higher-order pattern.
 
     \<^enum> Physical first-order patterns over raw \<open>\<lambda>\<close>-term structure without
     \<open>\<alpha>\<beta>\<eta>\<close>-equality; abstractions and bound variables are treated like
     quasi-constant term material.
 
     For example, the rule \<open>?f ?x \<in> range ?f = True\<close> rewrites the term \<open>g a \<in>
     range g\<close> to \<open>True\<close>, but will fail to match \<open>g (h b) \<in> range (\<lambda>x. g (h
     x))\<close>. However, offending subterms (in our case \<open>?f ?x\<close>, which is not a
     pattern) can be replaced by adding new variables and conditions like this:
     \<open>?y = ?f ?x \<Longrightarrow> ?y \<in> range ?f = True\<close> is acceptable as a conditional rewrite
     rule of the second category since conditions can be arbitrary terms.
 
   \<^descr> @{attribute split} declares case split rules.
 
   \<^descr> @{attribute cong} declares congruence rules to the Simplifier context.
 
   Congruence rules are equalities of the form @{text [display]
   "\<dots> \<Longrightarrow> f ?x\<^sub>1 \<dots> ?x\<^sub>n = f ?y\<^sub>1 \<dots> ?y\<^sub>n"}
 
   This controls the simplification of the arguments of \<open>f\<close>. For example, some
   arguments can be simplified under additional assumptions:
   @{text [display]
     "?P\<^sub>1 \<longleftrightarrow> ?Q\<^sub>1 \<Longrightarrow>
     (?Q\<^sub>1 \<Longrightarrow> ?P\<^sub>2 \<longleftrightarrow> ?Q\<^sub>2) \<Longrightarrow>
     (?P\<^sub>1 \<longrightarrow> ?P\<^sub>2) \<longleftrightarrow> (?Q\<^sub>1 \<longrightarrow> ?Q\<^sub>2)"}
 
   Given this rule, the Simplifier assumes \<open>?Q\<^sub>1\<close> and extracts rewrite rules
   from it when simplifying \<open>?P\<^sub>2\<close>. Such local assumptions are effective for
   rewriting formulae such as \<open>x = 0 \<longrightarrow> y + x = y\<close>.
 
   %FIXME
   %The local assumptions are also provided as theorems to the solver;
   %see \secref{sec:simp-solver} below.
 
   \<^medskip>
   The following congruence rule for bounded quantifiers also supplies
   contextual information --- about the bound variable: @{text [display]
   "(?A = ?B) \<Longrightarrow>
     (\<And>x. x \<in> ?B \<Longrightarrow> ?P x \<longleftrightarrow> ?Q x) \<Longrightarrow>
     (\<forall>x \<in> ?A. ?P x) \<longleftrightarrow> (\<forall>x \<in> ?B. ?Q x)"}
 
   \<^medskip>
   This congruence rule for conditional expressions can supply contextual
   information for simplifying the arms: @{text [display]
   "?p = ?q \<Longrightarrow>
     (?q \<Longrightarrow> ?a = ?c) \<Longrightarrow>
     (\<not> ?q \<Longrightarrow> ?b = ?d) \<Longrightarrow>
     (if ?p then ?a else ?b) = (if ?q then ?c else ?d)"}
 
   A congruence rule can also \<^emph>\<open>prevent\<close> simplification of some arguments. Here
   is an alternative congruence rule for conditional expressions that conforms
   to non-strict functional evaluation: @{text [display]
   "?p = ?q \<Longrightarrow>
     (if ?p then ?a else ?b) = (if ?q then ?a else ?b)"}
 
   Only the first argument is simplified; the others remain unchanged. This can
   make simplification much faster, but may require an extra case split over
   the condition \<open>?q\<close> to prove the goal.
 
   \<^descr> @{command "print_simpset"} prints the collection of rules declared to the
   Simplifier, which is also known as ``simpset'' internally; the ``\<open>!\<close>''
   option indicates extra verbosity.
 
   The implicit simpset of the theory context is propagated monotonically
   through the theory hierarchy: forming a new theory, the union of the
   simpsets of its imports are taken as starting point. Also note that
   definitional packages like @{command "datatype"}, @{command "primrec"},
   @{command "fun"} routinely declare Simplifier rules to the target context,
   while plain @{command "definition"} is an exception in \<^emph>\<open>not\<close> declaring
   anything.
 
   \<^medskip>
   It is up the user to manipulate the current simpset further by explicitly
   adding or deleting theorems as simplification rules, or installing other
   tools via simplification procedures (\secref{sec:simproc}). Good simpsets
   are hard to design. Rules that obviously simplify, like \<open>?n + 0 \<equiv> ?n\<close> are
   good candidates for the implicit simpset, unless a special non-normalizing
   behavior of certain operations is intended. More specific rules (such as
   distributive laws, which duplicate subterms) should be added only for
   specific proof steps. Conversely, sometimes a rule needs to be deleted just
   for some part of a proof. The need of frequent additions or deletions may
   indicate a poorly designed simpset.
 
   \begin{warn}
   The union of simpsets from theory imports (as described above) is not always
   a good starting point for the new theory. If some ancestors have deleted
   simplification rules because they are no longer wanted, while others have
   left those rules in, then the union will contain the unwanted rules, and
   thus have to be deleted again in the theory body.
   \end{warn}
 \<close>
 
 
 subsection \<open>Ordered rewriting with permutative rules\<close>
 
 text \<open>
   A rewrite rule is \<^emph>\<open>permutative\<close> if the left-hand side and right-hand side
   are the equal up to renaming of variables. The most common permutative rule
   is commutativity: \<open>?x + ?y = ?y + ?x\<close>. Other examples include \<open>(?x - ?y) -
   ?z = (?x - ?z) - ?y\<close> in arithmetic and \<open>insert ?x (insert ?y ?A) = insert ?y
   (insert ?x ?A)\<close> for sets. Such rules are common enough to merit special
   attention.
 
   Because ordinary rewriting loops given such rules, the Simplifier employs a
   special strategy, called \<^emph>\<open>ordered rewriting\<close>. Permutative rules are
   detected and only applied if the rewriting step decreases the redex wrt.\ a
   given term ordering. For example, commutativity rewrites \<open>b + a\<close> to \<open>a + b\<close>,
   but then stops, because the redex cannot be decreased further in the sense
   of the term ordering.
 
   The default is lexicographic ordering of term structure, but this could be
   also changed locally for special applications via @{define_ML
   Simplifier.set_term_ord} in Isabelle/ML.
 
   \<^medskip>
   Permutative rewrite rules are declared to the Simplifier just like other
   rewrite rules. Their special status is recognized automatically, and their
   application is guarded by the term ordering accordingly.
 \<close>
 
 
 subsubsection \<open>Rewriting with AC operators\<close>
 
 text \<open>
   Ordered rewriting is particularly effective in the case of
   associative-commutative operators. (Associativity by itself is not
   permutative.) When dealing with an AC-operator \<open>f\<close>, keep the following
   points in mind:
 
     \<^item> The associative law must always be oriented from left to right, namely
     \<open>f (f x y) z = f x (f y z)\<close>. The opposite orientation, if used with
     commutativity, leads to looping in conjunction with the standard term
     order.
 
     \<^item> To complete your set of rewrite rules, you must add not just
     associativity (A) and commutativity (C) but also a derived rule
     \<^emph>\<open>left-commutativity\<close> (LC): \<open>f x (f y z) = f y (f x z)\<close>.
 
   Ordered rewriting with the combination of A, C, and LC sorts a term
   lexicographically --- the rewriting engine imitates bubble-sort.
 \<close>
 
 experiment
   fixes f :: "'a \<Rightarrow> 'a \<Rightarrow> 'a"  (infix "\<bullet>" 60)
   assumes assoc: "(x \<bullet> y) \<bullet> z = x \<bullet> (y \<bullet> z)"
   assumes commute: "x \<bullet> y = y \<bullet> x"
 begin
 
 lemma left_commute: "x \<bullet> (y \<bullet> z) = y \<bullet> (x \<bullet> z)"
 proof -
   have "(x \<bullet> y) \<bullet> z = (y \<bullet> x) \<bullet> z" by (simp only: commute)
   then show ?thesis by (simp only: assoc)
 qed
 
 lemmas AC_rules = assoc commute left_commute
 
 text \<open>
   Thus the Simplifier is able to establish equalities with arbitrary
   permutations of subterms, by normalizing to a common standard form. For
   example:
 \<close>
 
 lemma "(b \<bullet> c) \<bullet> a = xxx"
   apply (simp only: AC_rules)
   txt \<open>\<^subgoals>\<close>
   oops
 
 lemma "(b \<bullet> c) \<bullet> a = a \<bullet> (b \<bullet> c)" by (simp only: AC_rules)
 lemma "(b \<bullet> c) \<bullet> a = c \<bullet> (b \<bullet> a)" by (simp only: AC_rules)
 lemma "(b \<bullet> c) \<bullet> a = (c \<bullet> b) \<bullet> a" by (simp only: AC_rules)
 
 end
 
 text \<open>
   Martin and Nipkow @{cite "martin-nipkow"} discuss the theory and give many
   examples; other algebraic structures are amenable to ordered rewriting, such
   as Boolean rings. The Boyer-Moore theorem prover @{cite bm88book} also
   employs ordered rewriting.
 \<close>
 
 
 subsubsection \<open>Re-orienting equalities\<close>
 
 text \<open>Another application of ordered rewriting uses the derived rule
   @{thm [source] eq_commute}: @{thm [source = false] eq_commute} to
   reverse equations.
 
   This is occasionally useful to re-orient local assumptions according
   to the term ordering, when other built-in mechanisms of
   reorientation and mutual simplification fail to apply.\<close>
 
 
 subsection \<open>Simplifier tracing and debugging \label{sec:simp-trace}\<close>
 
 text \<open>
   \begin{tabular}{rcll}
     @{attribute_def simp_trace} & : & \<open>attribute\<close> & default \<open>false\<close> \\
     @{attribute_def simp_trace_depth_limit} & : & \<open>attribute\<close> & default \<open>1\<close> \\
     @{attribute_def simp_debug} & : & \<open>attribute\<close> & default \<open>false\<close> \\
     @{attribute_def simp_trace_new} & : & \<open>attribute\<close> \\
     @{attribute_def simp_break} & : & \<open>attribute\<close> \\
   \end{tabular}
   \<^medskip>
 
   \<^rail>\<open>
     @@{attribute simp_trace_new} ('interactive')? \<newline>
       ('mode' '=' ('full' | 'normal'))? \<newline>
       ('depth' '=' @{syntax nat})?
     ;
 
     @@{attribute simp_break} (@{syntax term}*)
   \<close>
 
   These attributes and configurations options control various aspects of
   Simplifier tracing and debugging.
 
   \<^descr> @{attribute simp_trace} makes the Simplifier output internal operations.
   This includes rewrite steps, but also bookkeeping like modifications of the
   simpset.
 
   \<^descr> @{attribute simp_trace_depth_limit} limits the effect of @{attribute
   simp_trace} to the given depth of recursive Simplifier invocations (when
   solving conditions of rewrite rules).
 
   \<^descr> @{attribute simp_debug} makes the Simplifier output some extra information
   about internal operations. This includes any attempted invocation of
   simplification procedures.
 
   \<^descr> @{attribute simp_trace_new} controls Simplifier tracing within
   Isabelle/PIDE applications, notably Isabelle/jEdit @{cite "isabelle-jedit"}.
   This provides a hierarchical representation of the rewriting steps performed
   by the Simplifier.
 
   Users can configure the behaviour by specifying breakpoints, verbosity and
   enabling or disabling the interactive mode. In normal verbosity (the
   default), only rule applications matching a breakpoint will be shown to the
   user. In full verbosity, all rule applications will be logged. Interactive
   mode interrupts the normal flow of the Simplifier and defers the decision
   how to continue to the user via some GUI dialog.
 
   \<^descr> @{attribute simp_break} declares term or theorem breakpoints for
   @{attribute simp_trace_new} as described above. Term breakpoints are
   patterns which are checked for matches on the redex of a rule application.
   Theorem breakpoints trigger when the corresponding theorem is applied in a
   rewrite step. For example:
 \<close>
 
 (*<*)experiment begin(*>*)
 declare conjI [simp_break]
 declare [[simp_break "?x \<and> ?y"]]
 (*<*)end(*>*)
 
 
 subsection \<open>Simplification procedures \label{sec:simproc}\<close>
 
 text \<open>
   Simplification procedures are ML functions that produce proven rewrite rules
   on demand. They are associated with higher-order patterns that approximate
   the left-hand sides of equations. The Simplifier first matches the current
   redex against one of the LHS patterns; if this succeeds, the corresponding
   ML function is invoked, passing the Simplifier context and redex term. Thus
   rules may be specifically fashioned for particular situations, resulting in
   a more powerful mechanism than term rewriting by a fixed set of rules.
 
   Any successful result needs to be a (possibly conditional) rewrite rule \<open>t \<equiv>
   u\<close> that is applicable to the current redex. The rule will be applied just as
   any ordinary rewrite rule. It is expected to be already in \<^emph>\<open>internal form\<close>,
   bypassing the automatic preprocessing of object-level equivalences.
 
   \begin{matharray}{rcl}
     @{command_def "simproc_setup"} & : & \<open>local_theory \<rightarrow> local_theory\<close> \\
     simproc & : & \<open>attribute\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{command simproc_setup} @{syntax name} '(' (@{syntax term} + '|') ')' '='
       @{syntax text};
 
     @@{attribute simproc} (('add' ':')? | 'del' ':') (@{syntax name}+)
   \<close>
 
   \<^descr> @{command "simproc_setup"} defines a named simplification procedure that
   is invoked by the Simplifier whenever any of the given term patterns match
   the current redex. The implementation, which is provided as ML source text,
   needs to be of type
   \<^ML_type>\<open>morphism -> Proof.context -> cterm -> thm option\<close>, where the
   \<^ML_type>\<open>cterm\<close> represents the current redex \<open>r\<close> and the result is supposed
   to be some proven rewrite rule \<open>r \<equiv> r'\<close> (or a generalized version), or \<^ML>\<open>NONE\<close> to indicate failure. The \<^ML_type>\<open>Proof.context\<close> argument holds the
   full context of the current Simplifier invocation. The \<^ML_type>\<open>morphism\<close>
   informs about the difference of the original compilation context wrt.\ the
   one of the actual application later on.
 
   Morphisms are only relevant for simprocs that are defined within a local
   target context, e.g.\ in a locale.
 
   \<^descr> \<open>simproc add: name\<close> and \<open>simproc del: name\<close> add or delete named simprocs
   to the current Simplifier context. The default is to add a simproc. Note
   that @{command "simproc_setup"} already adds the new simproc to the
   subsequent context.
 \<close>
 
 
 subsubsection \<open>Example\<close>
 
 text \<open>
   The following simplification procedure for @{thm [source = false,
   show_types] unit_eq} in HOL performs fine-grained control over rule
   application, beyond higher-order pattern matching. Declaring @{thm unit_eq}
   as @{attribute simp} directly would make the Simplifier loop! Note that a
   version of this simplification procedure is already active in Isabelle/HOL.
 \<close>
 
 (*<*)experiment begin(*>*)
 simproc_setup unit ("x::unit") =
   \<open>fn _ => fn _ => fn ct =>
     if HOLogic.is_unit (Thm.term_of ct) then NONE
     else SOME (mk_meta_eq @{thm unit_eq})\<close>
 (*<*)end(*>*)
 
 text \<open>
   Since the Simplifier applies simplification procedures frequently, it is
   important to make the failure check in ML reasonably fast.\<close>
 
 
 subsection \<open>Configurable Simplifier strategies \label{sec:simp-strategies}\<close>
 
 text \<open>
   The core term-rewriting engine of the Simplifier is normally used in
   combination with some add-on components that modify the strategy and allow
   to integrate other non-Simplifier proof tools. These may be reconfigured in
   ML as explained below. Even if the default strategies of object-logics like
   Isabelle/HOL are used unchanged, it helps to understand how the standard
   Simplifier strategies work.\<close>
 
 
 subsubsection \<open>The subgoaler\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML Simplifier.set_subgoaler: "(Proof.context -> int -> tactic) ->
   Proof.context -> Proof.context"} \\
   @{define_ML Simplifier.prems_of: "Proof.context -> thm list"} \\
   \end{mldecls}
 
   The subgoaler is the tactic used to solve subgoals arising out of
   conditional rewrite rules or congruence rules. The default should be
   simplification itself. In rare situations, this strategy may need to be
   changed. For example, if the premise of a conditional rule is an instance of
   its conclusion, as in \<open>Suc ?m < ?n \<Longrightarrow> ?m < ?n\<close>, the default strategy could
   loop. % FIXME !??
 
     \<^descr> \<^ML>\<open>Simplifier.set_subgoaler\<close>~\<open>tac ctxt\<close> sets the subgoaler of the
     context to \<open>tac\<close>. The tactic will be applied to the context of the running
     Simplifier instance.
 
     \<^descr> \<^ML>\<open>Simplifier.prems_of\<close>~\<open>ctxt\<close> retrieves the current set of premises
     from the context. This may be non-empty only if the Simplifier has been
     told to utilize local assumptions in the first place (cf.\ the options in
     \secref{sec:simp-meth}).
 
   As an example, consider the following alternative subgoaler:
 \<close>
 
 ML_val \<open>
   fun subgoaler_tac ctxt =
     assume_tac ctxt ORELSE'
     resolve_tac ctxt (Simplifier.prems_of ctxt) ORELSE'
     asm_simp_tac ctxt
 \<close>
 
 text \<open>
   This tactic first tries to solve the subgoal by assumption or by resolving
   with with one of the premises, calling simplification only if that fails.\<close>
 
 
 subsubsection \<open>The solver\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML_type solver} \\
   @{define_ML Simplifier.mk_solver: "string ->
   (Proof.context -> int -> tactic) -> solver"} \\
   @{define_ML_infix setSolver: "Proof.context * solver -> Proof.context"} \\
   @{define_ML_infix addSolver: "Proof.context * solver -> Proof.context"} \\
   @{define_ML_infix setSSolver: "Proof.context * solver -> Proof.context"} \\
   @{define_ML_infix addSSolver: "Proof.context * solver -> Proof.context"} \\
   \end{mldecls}
 
   A solver is a tactic that attempts to solve a subgoal after simplification.
   Its core functionality is to prove trivial subgoals such as \<^prop>\<open>True\<close>
   and \<open>t = t\<close>, but object-logics might be more ambitious. For example,
   Isabelle/HOL performs a restricted version of linear arithmetic here.
 
   Solvers are packaged up in abstract type \<^ML_type>\<open>solver\<close>, with \<^ML>\<open>Simplifier.mk_solver\<close> as the only operation to create a solver.
 
   \<^medskip>
   Rewriting does not instantiate unknowns. For example, rewriting alone cannot
   prove \<open>a \<in> ?A\<close> since this requires instantiating \<open>?A\<close>. The solver, however,
   is an arbitrary tactic and may instantiate unknowns as it pleases. This is
   the only way the Simplifier can handle a conditional rewrite rule whose
   condition contains extra variables. When a simplification tactic is to be
   combined with other provers, especially with the Classical Reasoner, it is
   important whether it can be considered safe or not. For this reason a
   simpset contains two solvers: safe and unsafe.
 
   The standard simplification strategy solely uses the unsafe solver, which is
   appropriate in most cases. For special applications where the simplification
   process is not allowed to instantiate unknowns within the goal,
   simplification starts with the safe solver, but may still apply the ordinary
   unsafe one in nested simplifications for conditional rules or congruences.
   Note that in this way the overall tactic is not totally safe: it may
   instantiate unknowns that appear also in other subgoals.
 
   \<^descr> \<^ML>\<open>Simplifier.mk_solver\<close>~\<open>name tac\<close> turns \<open>tac\<close> into a solver; the
   \<open>name\<close> is only attached as a comment and has no further significance.
 
   \<^descr> \<open>ctxt setSSolver solver\<close> installs \<open>solver\<close> as the safe solver of \<open>ctxt\<close>.
 
   \<^descr> \<open>ctxt addSSolver solver\<close> adds \<open>solver\<close> as an additional safe solver; it
   will be tried after the solvers which had already been present in \<open>ctxt\<close>.
 
   \<^descr> \<open>ctxt setSolver solver\<close> installs \<open>solver\<close> as the unsafe solver of \<open>ctxt\<close>.
 
   \<^descr> \<open>ctxt addSolver solver\<close> adds \<open>solver\<close> as an additional unsafe solver; it
   will be tried after the solvers which had already been present in \<open>ctxt\<close>.
 
 
   \<^medskip>
   The solver tactic is invoked with the context of the running Simplifier.
   Further operations may be used to retrieve relevant information, such as the
   list of local Simplifier premises via \<^ML>\<open>Simplifier.prems_of\<close> --- this
   list may be non-empty only if the Simplifier runs in a mode that utilizes
   local assumptions (see also \secref{sec:simp-meth}). The solver is also
   presented the full goal including its assumptions in any case. Thus it can
   use these (e.g.\ by calling \<^ML>\<open>assume_tac\<close>), even if the Simplifier proper
   happens to ignore local premises at the moment.
 
   \<^medskip>
   As explained before, the subgoaler is also used to solve the premises of
   congruence rules. These are usually of the form \<open>s = ?x\<close>, where \<open>s\<close> needs to
   be simplified and \<open>?x\<close> needs to be instantiated with the result. Typically,
   the subgoaler will invoke the Simplifier at some point, which will
   eventually call the solver. For this reason, solver tactics must be prepared
   to solve goals of the form \<open>t = ?x\<close>, usually by reflexivity. In particular,
   reflexivity should be tried before any of the fancy automated proof tools.
 
   It may even happen that due to simplification the subgoal is no longer an
   equality. For example, \<open>False \<longleftrightarrow> ?Q\<close> could be rewritten to \<open>\<not> ?Q\<close>. To cover
   this case, the solver could try resolving with the theorem \<open>\<not> False\<close> of the
   object-logic.
 
   \<^medskip>
   \begin{warn}
   If a premise of a congruence rule cannot be proved, then the congruence is
   ignored. This should only happen if the rule is \<^emph>\<open>conditional\<close> --- that is,
   contains premises not of the form \<open>t = ?x\<close>. Otherwise it indicates that some
   congruence rule, or possibly the subgoaler or solver, is faulty.
   \end{warn}
 \<close>
 
 
 subsubsection \<open>The looper\<close>
 
 text \<open>
   \begin{mldecls}
   @{define_ML_infix setloop: "Proof.context *
   (Proof.context -> int -> tactic) -> Proof.context"} \\
   @{define_ML_infix addloop: "Proof.context *
   (string * (Proof.context -> int -> tactic))
   -> Proof.context"} \\
   @{define_ML_infix delloop: "Proof.context * string -> Proof.context"} \\
   @{define_ML Splitter.add_split: "thm -> Proof.context -> Proof.context"} \\
   @{define_ML Splitter.add_split: "thm -> Proof.context -> Proof.context"} \\
   @{define_ML Splitter.add_split_bang: "
   thm -> Proof.context -> Proof.context"} \\
   @{define_ML Splitter.del_split: "thm -> Proof.context -> Proof.context"} \\
   \end{mldecls}
 
   The looper is a list of tactics that are applied after simplification, in
   case the solver failed to solve the simplified goal. If the looper succeeds,
   the simplification process is started all over again. Each of the subgoals
   generated by the looper is attacked in turn, in reverse order.
 
   A typical looper is \<^emph>\<open>case splitting\<close>: the expansion of a conditional.
   Another possibility is to apply an elimination rule on the assumptions. More
   adventurous loopers could start an induction.
 
     \<^descr> \<open>ctxt setloop tac\<close> installs \<open>tac\<close> as the only looper tactic of \<open>ctxt\<close>.
 
     \<^descr> \<open>ctxt addloop (name, tac)\<close> adds \<open>tac\<close> as an additional looper tactic
     with name \<open>name\<close>, which is significant for managing the collection of
     loopers. The tactic will be tried after the looper tactics that had
     already been present in \<open>ctxt\<close>.
 
     \<^descr> \<open>ctxt delloop name\<close> deletes the looper tactic that was associated with
     \<open>name\<close> from \<open>ctxt\<close>.
 
     \<^descr> \<^ML>\<open>Splitter.add_split\<close>~\<open>thm ctxt\<close> adds split tactic
     for \<open>thm\<close> as additional looper tactic of \<open>ctxt\<close>
     (overwriting previous split tactic for the same constant).
 
     \<^descr> \<^ML>\<open>Splitter.add_split_bang\<close>~\<open>thm ctxt\<close> adds aggressive
     (see \S\ref{sec:simp-meth})
     split tactic for \<open>thm\<close> as additional looper tactic of \<open>ctxt\<close>
     (overwriting previous split tactic for the same constant).
 
     \<^descr> \<^ML>\<open>Splitter.del_split\<close>~\<open>thm ctxt\<close> deletes the split tactic
     corresponding to \<open>thm\<close> from the looper tactics of \<open>ctxt\<close>.
 
   The splitter replaces applications of a given function; the right-hand side
   of the replacement can be anything. For example, here is a splitting rule
   for conditional expressions:
 
   @{text [display] "?P (if ?Q ?x ?y) \<longleftrightarrow> (?Q \<longrightarrow> ?P ?x) \<and> (\<not> ?Q \<longrightarrow> ?P ?y)"}
 
   Another example is the elimination operator for Cartesian products (which
   happens to be called \<^const>\<open>case_prod\<close> in Isabelle/HOL:
 
   @{text [display] "?P (case_prod ?f ?p) \<longleftrightarrow> (\<forall>a b. ?p = (a, b) \<longrightarrow> ?P (f a b))"}
 
   For technical reasons, there is a distinction between case splitting in the
   conclusion and in the premises of a subgoal. The former is done by \<^ML>\<open>Splitter.split_tac\<close> with rules like @{thm [source] if_split} or @{thm
   [source] option.split}, which do not split the subgoal, while the latter is
   done by \<^ML>\<open>Splitter.split_asm_tac\<close> with rules like @{thm [source]
   if_split_asm} or @{thm [source] option.split_asm}, which split the subgoal.
   The function \<^ML>\<open>Splitter.add_split\<close> automatically takes care of which
   tactic to call, analyzing the form of the rules given as argument; it is the
   same operation behind \<open>split\<close> attribute or method modifier syntax in the
   Isar source language.
 
   Case splits should be allowed only when necessary; they are expensive and
   hard to control. Case-splitting on if-expressions in the conclusion is
   usually beneficial, so it is enabled by default in Isabelle/HOL and
   Isabelle/FOL/ZF.
 
   \begin{warn}
   With \<^ML>\<open>Splitter.split_asm_tac\<close> as looper component, the Simplifier may
   split subgoals! This might cause unexpected problems in tactic expressions
   that silently assume 0 or 1 subgoals after simplification.
   \end{warn}
 \<close>
 
 
 subsection \<open>Forward simplification \label{sec:simp-forward}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{attribute_def simplified} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{attribute simplified} opt? @{syntax thms}?
     ;
 
     opt: '(' ('no_asm' | 'no_asm_simp' | 'no_asm_use') ')'
   \<close>
 
   \<^descr> @{attribute simplified}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> causes a theorem to be simplified,
   either by exactly the specified rules \<open>a\<^sub>1, \<dots>, a\<^sub>n\<close>, or the implicit
   Simplifier context if no arguments are given. The result is fully simplified
   by default, including assumptions and conclusion; the options \<open>no_asm\<close> etc.\
   tune the Simplifier in the same way as the for the \<open>simp\<close> method.
 
   Note that forward simplification restricts the Simplifier to its most basic
   operation of term rewriting; solver and looper tactics
   (\secref{sec:simp-strategies}) are \<^emph>\<open>not\<close> involved here. The @{attribute
   simplified} attribute should be only rarely required under normal
   circumstances.
 \<close>
 
 
 section \<open>The Classical Reasoner \label{sec:classical}\<close>
 
 subsection \<open>Basic concepts\<close>
 
 text \<open>Although Isabelle is generic, many users will be working in
   some extension of classical first-order logic.  Isabelle/ZF is built
   upon theory FOL, while Isabelle/HOL conceptually contains
   first-order logic as a fragment.  Theorem-proving in predicate logic
   is undecidable, but many automated strategies have been developed to
   assist in this task.
 
   Isabelle's classical reasoner is a generic package that accepts
   certain information about a logic and delivers a suite of automatic
   proof tools, based on rules that are classified and declared in the
   context.  These proof procedures are slow and simplistic compared
   with high-end automated theorem provers, but they can save
   considerable time and effort in practice.  They can prove theorems
   such as Pelletier's @{cite pelletier86} problems 40 and 41 in a few
   milliseconds (including full proof reconstruction):\<close>
 
 lemma "(\<exists>y. \<forall>x. F x y \<longleftrightarrow> F x x) \<longrightarrow> \<not> (\<forall>x. \<exists>y. \<forall>z. F z y \<longleftrightarrow> \<not> F z x)"
   by blast
 
 lemma "(\<forall>z. \<exists>y. \<forall>x. f x y \<longleftrightarrow> f x z \<and> \<not> f x x) \<longrightarrow> \<not> (\<exists>z. \<forall>x. f x z)"
   by blast
 
 text \<open>The proof tools are generic.  They are not restricted to
   first-order logic, and have been heavily used in the development of
   the Isabelle/HOL library and applications.  The tactics can be
   traced, and their components can be called directly; in this manner,
   any proof can be viewed interactively.\<close>
 
 
 subsubsection \<open>The sequent calculus\<close>
 
 text \<open>Isabelle supports natural deduction, which is easy to use for
   interactive proof.  But natural deduction does not easily lend
   itself to automation, and has a bias towards intuitionism.  For
   certain proofs in classical logic, it can not be called natural.
   The \<^emph>\<open>sequent calculus\<close>, a generalization of natural deduction,
   is easier to automate.
 
   A \<^bold>\<open>sequent\<close> has the form \<open>\<Gamma> \<turnstile> \<Delta>\<close>, where \<open>\<Gamma>\<close>
   and \<open>\<Delta>\<close> are sets of formulae.\<^footnote>\<open>For first-order
   logic, sequents can equivalently be made from lists or multisets of
   formulae.\<close> The sequent \<open>P\<^sub>1, \<dots>, P\<^sub>m \<turnstile> Q\<^sub>1, \<dots>, Q\<^sub>n\<close> is
   \<^bold>\<open>valid\<close> if \<open>P\<^sub>1 \<and> \<dots> \<and> P\<^sub>m\<close> implies \<open>Q\<^sub>1 \<or> \<dots> \<or>
   Q\<^sub>n\<close>.  Thus \<open>P\<^sub>1, \<dots>, P\<^sub>m\<close> represent assumptions, each of which
   is true, while \<open>Q\<^sub>1, \<dots>, Q\<^sub>n\<close> represent alternative goals.  A
   sequent is \<^bold>\<open>basic\<close> if its left and right sides have a common
   formula, as in \<open>P, Q \<turnstile> Q, R\<close>; basic sequents are trivially
   valid.
 
   Sequent rules are classified as \<^bold>\<open>right\<close> or \<^bold>\<open>left\<close>,
   indicating which side of the \<open>\<turnstile>\<close> symbol they operate on.
   Rules that operate on the right side are analogous to natural
   deduction's introduction rules, and left rules are analogous to
   elimination rules.  The sequent calculus analogue of \<open>(\<longrightarrow>I)\<close>
   is the rule
   \[
   \infer[\<open>(\<longrightarrow>R)\<close>]{\<open>\<Gamma> \<turnstile> \<Delta>, P \<longrightarrow> Q\<close>}{\<open>P, \<Gamma> \<turnstile> \<Delta>, Q\<close>}
   \]
   Applying the rule backwards, this breaks down some implication on
   the right side of a sequent; \<open>\<Gamma>\<close> and \<open>\<Delta>\<close> stand for
   the sets of formulae that are unaffected by the inference.  The
   analogue of the pair \<open>(\<or>I1)\<close> and \<open>(\<or>I2)\<close> is the
   single rule
   \[
   \infer[\<open>(\<or>R)\<close>]{\<open>\<Gamma> \<turnstile> \<Delta>, P \<or> Q\<close>}{\<open>\<Gamma> \<turnstile> \<Delta>, P, Q\<close>}
   \]
   This breaks down some disjunction on the right side, replacing it by
   both disjuncts.  Thus, the sequent calculus is a kind of
   multiple-conclusion logic.
 
   To illustrate the use of multiple formulae on the right, let us
   prove the classical theorem \<open>(P \<longrightarrow> Q) \<or> (Q \<longrightarrow> P)\<close>.  Working
   backwards, we reduce this formula to a basic sequent:
   \[
   \infer[\<open>(\<or>R)\<close>]{\<open>\<turnstile> (P \<longrightarrow> Q) \<or> (Q \<longrightarrow> P)\<close>}
     {\infer[\<open>(\<longrightarrow>R)\<close>]{\<open>\<turnstile> (P \<longrightarrow> Q), (Q \<longrightarrow> P)\<close>}
       {\infer[\<open>(\<longrightarrow>R)\<close>]{\<open>P \<turnstile> Q, (Q \<longrightarrow> P)\<close>}
         {\<open>P, Q \<turnstile> Q, P\<close>}}}
   \]
 
   This example is typical of the sequent calculus: start with the
   desired theorem and apply rules backwards in a fairly arbitrary
   manner.  This yields a surprisingly effective proof procedure.
   Quantifiers add only few complications, since Isabelle handles
   parameters and schematic variables.  See @{cite \<open>Chapter 10\<close>
   "paulson-ml2"} for further discussion.\<close>
 
 
 subsubsection \<open>Simulating sequents by natural deduction\<close>
 
 text \<open>Isabelle can represent sequents directly, as in the
   object-logic LK.  But natural deduction is easier to work with, and
   most object-logics employ it.  Fortunately, we can simulate the
   sequent \<open>P\<^sub>1, \<dots>, P\<^sub>m \<turnstile> Q\<^sub>1, \<dots>, Q\<^sub>n\<close> by the Isabelle formula
   \<open>P\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> P\<^sub>m \<Longrightarrow> \<not> Q\<^sub>2 \<Longrightarrow> ... \<Longrightarrow> \<not> Q\<^sub>n \<Longrightarrow> Q\<^sub>1\<close> where the order of
   the assumptions and the choice of \<open>Q\<^sub>1\<close> are arbitrary.
   Elim-resolution plays a key role in simulating sequent proofs.
 
   We can easily handle reasoning on the left.  Elim-resolution with
   the rules \<open>(\<or>E)\<close>, \<open>(\<bottom>E)\<close> and \<open>(\<exists>E)\<close> achieves
   a similar effect as the corresponding sequent rules.  For the other
   connectives, we use sequent-style elimination rules instead of
   destruction rules such as \<open>(\<and>E1, 2)\<close> and \<open>(\<forall>E)\<close>.
   But note that the rule \<open>(\<not>L)\<close> has no effect under our
   representation of sequents!
   \[
   \infer[\<open>(\<not>L)\<close>]{\<open>\<not> P, \<Gamma> \<turnstile> \<Delta>\<close>}{\<open>\<Gamma> \<turnstile> \<Delta>, P\<close>}
   \]
 
   What about reasoning on the right?  Introduction rules can only
   affect the formula in the conclusion, namely \<open>Q\<^sub>1\<close>.  The
   other right-side formulae are represented as negated assumptions,
   \<open>\<not> Q\<^sub>2, \<dots>, \<not> Q\<^sub>n\<close>.  In order to operate on one of these, it
   must first be exchanged with \<open>Q\<^sub>1\<close>.  Elim-resolution with the
   \<open>swap\<close> rule has this effect: \<open>\<not> P \<Longrightarrow> (\<not> R \<Longrightarrow> P) \<Longrightarrow> R\<close>
 
   To ensure that swaps occur only when necessary, each introduction
   rule is converted into a swapped form: it is resolved with the
   second premise of \<open>(swap)\<close>.  The swapped form of \<open>(\<and>I)\<close>, which might be called \<open>(\<not>\<and>E)\<close>, is
   @{text [display] "\<not> (P \<and> Q) \<Longrightarrow> (\<not> R \<Longrightarrow> P) \<Longrightarrow> (\<not> R \<Longrightarrow> Q) \<Longrightarrow> R"}
 
   Similarly, the swapped form of \<open>(\<longrightarrow>I)\<close> is
   @{text [display] "\<not> (P \<longrightarrow> Q) \<Longrightarrow> (\<not> R \<Longrightarrow> P \<Longrightarrow> Q) \<Longrightarrow> R"}
 
   Swapped introduction rules are applied using elim-resolution, which
   deletes the negated formula.  Our representation of sequents also
   requires the use of ordinary introduction rules.  If we had no
   regard for readability of intermediate goal states, we could treat
   the right side more uniformly by representing sequents as @{text
   [display] "P\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> P\<^sub>m \<Longrightarrow> \<not> Q\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> \<not> Q\<^sub>n \<Longrightarrow> \<bottom>"}
 \<close>
 
 
 subsubsection \<open>Extra rules for the sequent calculus\<close>
 
 text \<open>As mentioned, destruction rules such as \<open>(\<and>E1, 2)\<close> and
   \<open>(\<forall>E)\<close> must be replaced by sequent-style elimination rules.
   In addition, we need rules to embody the classical equivalence
   between \<open>P \<longrightarrow> Q\<close> and \<open>\<not> P \<or> Q\<close>.  The introduction
   rules \<open>(\<or>I1, 2)\<close> are replaced by a rule that simulates
   \<open>(\<or>R)\<close>: @{text [display] "(\<not> Q \<Longrightarrow> P) \<Longrightarrow> P \<or> Q"}
 
   The destruction rule \<open>(\<longrightarrow>E)\<close> is replaced by @{text [display]
   "(P \<longrightarrow> Q) \<Longrightarrow> (\<not> P \<Longrightarrow> R) \<Longrightarrow> (Q \<Longrightarrow> R) \<Longrightarrow> R"}
 
   Quantifier replication also requires special rules.  In classical
   logic, \<open>\<exists>x. P x\<close> is equivalent to \<open>\<not> (\<forall>x. \<not> P x)\<close>;
   the rules \<open>(\<exists>R)\<close> and \<open>(\<forall>L)\<close> are dual:
   \[
   \infer[\<open>(\<exists>R)\<close>]{\<open>\<Gamma> \<turnstile> \<Delta>, \<exists>x. P x\<close>}{\<open>\<Gamma> \<turnstile> \<Delta>, \<exists>x. P x, P t\<close>}
   \qquad
   \infer[\<open>(\<forall>L)\<close>]{\<open>\<forall>x. P x, \<Gamma> \<turnstile> \<Delta>\<close>}{\<open>P t, \<forall>x. P x, \<Gamma> \<turnstile> \<Delta>\<close>}
   \]
   Thus both kinds of quantifier may be replicated.  Theorems requiring
   multiple uses of a universal formula are easy to invent; consider
   @{text [display] "(\<forall>x. P x \<longrightarrow> P (f x)) \<and> P a \<longrightarrow> P (f\<^sup>n a)"} for any
   \<open>n > 1\<close>.  Natural examples of the multiple use of an
   existential formula are rare; a standard one is \<open>\<exists>x. \<forall>y. P x
   \<longrightarrow> P y\<close>.
 
   Forgoing quantifier replication loses completeness, but gains
   decidability, since the search space becomes finite.  Many useful
   theorems can be proved without replication, and the search generally
   delivers its verdict in a reasonable time.  To adopt this approach,
   represent the sequent rules \<open>(\<exists>R)\<close>, \<open>(\<exists>L)\<close> and
   \<open>(\<forall>R)\<close> by \<open>(\<exists>I)\<close>, \<open>(\<exists>E)\<close> and \<open>(\<forall>I)\<close>,
   respectively, and put \<open>(\<forall>E)\<close> into elimination form: @{text
   [display] "\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> Q) \<Longrightarrow> Q"}
 
   Elim-resolution with this rule will delete the universal formula
   after a single use.  To replicate universal quantifiers, replace the
   rule by @{text [display] "\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> \<forall>x. P x \<Longrightarrow> Q) \<Longrightarrow> Q"}
 
   To replicate existential quantifiers, replace \<open>(\<exists>I)\<close> by
   @{text [display] "(\<not> (\<exists>x. P x) \<Longrightarrow> P t) \<Longrightarrow> \<exists>x. P x"}
 
   All introduction rules mentioned above are also useful in swapped
   form.
 
   Replication makes the search space infinite; we must apply the rules
   with care.  The classical reasoner distinguishes between safe and
   unsafe rules, applying the latter only when there is no alternative.
   Depth-first search may well go down a blind alley; best-first search
   is better behaved in an infinite search space.  However, quantifier
   replication is too expensive to prove any but the simplest theorems.
 \<close>
 
 
 subsection \<open>Rule declarations\<close>
 
 text \<open>The proof tools of the Classical Reasoner depend on
   collections of rules declared in the context, which are classified
   as introduction, elimination or destruction and as \<^emph>\<open>safe\<close> or
   \<^emph>\<open>unsafe\<close>.  In general, safe rules can be attempted blindly,
   while unsafe rules must be used with care.  A safe rule must never
   reduce a provable goal to an unprovable set of subgoals.
 
   The rule \<open>P \<Longrightarrow> P \<or> Q\<close> is unsafe because it reduces \<open>P
   \<or> Q\<close> to \<open>P\<close>, which might turn out as premature choice of an
   unprovable subgoal.  Any rule whose premises contain new unknowns is
   unsafe. The elimination rule \<open>\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> Q) \<Longrightarrow> Q\<close> is
   unsafe, since it is applied via elim-resolution, which discards the
   assumption \<open>\<forall>x. P x\<close> and replaces it by the weaker
   assumption \<open>P t\<close>.  The rule \<open>P t \<Longrightarrow> \<exists>x. P x\<close> is
   unsafe for similar reasons.  The quantifier duplication rule \<open>\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> \<forall>x. P x \<Longrightarrow> Q) \<Longrightarrow> Q\<close> is unsafe in a different sense:
   since it keeps the assumption \<open>\<forall>x. P x\<close>, it is prone to
   looping.  In classical first-order logic, all rules are safe except
   those mentioned above.
 
   The safe~/ unsafe distinction is vague, and may be regarded merely
   as a way of giving some rules priority over others.  One could argue
   that \<open>(\<or>E)\<close> is unsafe, because repeated application of it
   could generate exponentially many subgoals.  Induction rules are
   unsafe because inductive proofs are difficult to set up
   automatically.  Any inference that instantiates an unknown
   in the proof state is unsafe --- thus matching must be used, rather than
   unification.  Even proof by assumption is unsafe if it instantiates
   unknowns shared with other subgoals.
 
   \begin{matharray}{rcl}
     @{command_def "print_claset"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
     @{attribute_def intro} & : & \<open>attribute\<close> \\
     @{attribute_def elim} & : & \<open>attribute\<close> \\
     @{attribute_def dest} & : & \<open>attribute\<close> \\
     @{attribute_def rule} & : & \<open>attribute\<close> \\
     @{attribute_def iff} & : & \<open>attribute\<close> \\
     @{attribute_def swapped} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     (@@{attribute intro} | @@{attribute elim} | @@{attribute dest}) ('!' | () | '?') @{syntax nat}?
     ;
     @@{attribute rule} 'del'
     ;
     @@{attribute iff} (((() | 'add') '?'?) | 'del')
   \<close>
 
   \<^descr> @{command "print_claset"} prints the collection of rules
   declared to the Classical Reasoner, i.e.\ the \<^ML_type>\<open>claset\<close>
   within the context.
 
   \<^descr> @{attribute intro}, @{attribute elim}, and @{attribute dest}
   declare introduction, elimination, and destruction rules,
   respectively.  By default, rules are considered as \<^emph>\<open>unsafe\<close>
   (i.e.\ not applied blindly without backtracking), while ``\<open>!\<close>'' classifies as \<^emph>\<open>safe\<close>.  Rule declarations marked by
   ``\<open>?\<close>'' coincide with those of Isabelle/Pure, cf.\
   \secref{sec:pure-meth-att} (i.e.\ are only applied in single steps
   of the @{method rule} method).  The optional natural number
   specifies an explicit weight argument, which is ignored by the
   automated reasoning tools, but determines the search order of single
   rule steps.
 
   Introduction rules are those that can be applied using ordinary
   resolution.  Their swapped forms are generated internally, which
   will be applied using elim-resolution.  Elimination rules are
   applied using elim-resolution.  Rules are sorted by the number of
   new subgoals they will yield; rules that generate the fewest
   subgoals will be tried first.  Otherwise, later declarations take
   precedence over earlier ones.
 
   Rules already present in the context with the same classification
   are ignored.  A warning is printed if the rule has already been
   added with some other classification, but the rule is added anyway
   as requested.
 
   \<^descr> @{attribute rule}~\<open>del\<close> deletes all occurrences of a
   rule from the classical context, regardless of its classification as
   introduction~/ elimination~/ destruction and safe~/ unsafe.
 
   \<^descr> @{attribute iff} declares logical equivalences to the
   Simplifier and the Classical reasoner at the same time.
   Non-conditional rules result in a safe introduction and elimination
   pair; conditional ones are considered unsafe.  Rules with negative
   conclusion are automatically inverted (using \<open>\<not>\<close>-elimination
   internally).
 
   The ``\<open>?\<close>'' version of @{attribute iff} declares rules to
   the Isabelle/Pure context only, and omits the Simplifier
   declaration.
 
   \<^descr> @{attribute swapped} turns an introduction rule into an
   elimination, by resolving with the classical swap principle \<open>\<not> P \<Longrightarrow> (\<not> R \<Longrightarrow> P) \<Longrightarrow> R\<close> in the second position.  This is mainly for
   illustrative purposes: the Classical Reasoner already swaps rules
   internally as explained above.
 \<close>
 
 
 subsection \<open>Structured methods\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{method_def rule} & : & \<open>method\<close> \\
     @{method_def contradiction} & : & \<open>method\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{method rule} @{syntax thms}?
   \<close>
 
   \<^descr> @{method rule} as offered by the Classical Reasoner is a
   refinement over the Pure one (see \secref{sec:pure-meth-att}).  Both
   versions work the same, but the classical version observes the
   classical rule context in addition to that of Isabelle/Pure.
 
   Common object logics (HOL, ZF, etc.) declare a rich collection of
   classical rules (even if these would qualify as intuitionistic
   ones), but only few declarations to the rule context of
   Isabelle/Pure (\secref{sec:pure-meth-att}).
 
   \<^descr> @{method contradiction} solves some goal by contradiction,
   deriving any result from both \<open>\<not> A\<close> and \<open>A\<close>.  Chained
   facts, which are guaranteed to participate, may appear in either
   order.
 \<close>
 
 
 subsection \<open>Fully automated methods\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{method_def blast} & : & \<open>method\<close> \\
     @{method_def auto} & : & \<open>method\<close> \\
     @{method_def force} & : & \<open>method\<close> \\
     @{method_def fast} & : & \<open>method\<close> \\
     @{method_def slow} & : & \<open>method\<close> \\
     @{method_def best} & : & \<open>method\<close> \\
     @{method_def fastforce} & : & \<open>method\<close> \\
     @{method_def slowsimp} & : & \<open>method\<close> \\
     @{method_def bestsimp} & : & \<open>method\<close> \\
     @{method_def deepen} & : & \<open>method\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{method blast} @{syntax nat}? (@{syntax clamod} * )
     ;
     @@{method auto} (@{syntax nat} @{syntax nat})? (@{syntax clasimpmod} * )
     ;
     @@{method force} (@{syntax clasimpmod} * )
     ;
     (@@{method fast} | @@{method slow} | @@{method best}) (@{syntax clamod} * )
     ;
     (@@{method fastforce} | @@{method slowsimp} | @@{method bestsimp})
       (@{syntax clasimpmod} * )
     ;
     @@{method deepen} (@{syntax nat} ?) (@{syntax clamod} * )
     ;
     @{syntax_def clamod}:
       (('intro' | 'elim' | 'dest') ('!' | () | '?') | 'del') ':' @{syntax thms}
     ;
     @{syntax_def clasimpmod}: ('simp' (() | 'add' | 'del' | 'only') |
       'cong' (() | 'add' | 'del') |
       'split' (() | '!' | 'del') |
       'iff' (((() | 'add') '?'?) | 'del') |
       (('intro' | 'elim' | 'dest') ('!' | () | '?') | 'del')) ':' @{syntax thms}
   \<close>
 
   \<^descr> @{method blast} is a separate classical tableau prover that
   uses the same classical rule declarations as explained before.
 
   Proof search is coded directly in ML using special data structures.
   A successful proof is then reconstructed using regular Isabelle
   inferences.  It is faster and more powerful than the other classical
   reasoning tools, but has major limitations too.
 
     \<^item> It does not use the classical wrapper tacticals, such as the
     integration with the Simplifier of @{method fastforce}.
 
     \<^item> It does not perform higher-order unification, as needed by the
     rule @{thm [source=false] rangeI} in HOL.  There are often
     alternatives to such rules, for example @{thm [source=false]
     range_eqI}.
 
     \<^item> Function variables may only be applied to parameters of the
     subgoal.  (This restriction arises because the prover does not use
     higher-order unification.)  If other function variables are present
     then the prover will fail with the message
     @{verbatim [display] \<open>Function unknown's argument not a bound variable\<close>}
 
     \<^item> Its proof strategy is more general than @{method fast} but can
     be slower.  If @{method blast} fails or seems to be running forever,
     try @{method fast} and the other proof tools described below.
 
   The optional integer argument specifies a bound for the number of
   unsafe steps used in a proof.  By default, @{method blast} starts
   with a bound of 0 and increases it successively to 20.  In contrast,
   \<open>(blast lim)\<close> tries to prove the goal using a search bound
   of \<open>lim\<close>.  Sometimes a slow proof using @{method blast} can
   be made much faster by supplying the successful search bound to this
   proof method instead.
 
   \<^descr> @{method auto} combines classical reasoning with
   simplification.  It is intended for situations where there are a lot
   of mostly trivial subgoals; it proves all the easy ones, leaving the
   ones it cannot prove.  Occasionally, attempting to prove the hard
   ones may take a long time.
 
   The optional depth arguments in \<open>(auto m n)\<close> refer to its
   builtin classical reasoning procedures: \<open>m\<close> (default 4) is for
   @{method blast}, which is tried first, and \<open>n\<close> (default 2) is
   for a slower but more general alternative that also takes wrappers
   into account.
 
   \<^descr> @{method force} is intended to prove the first subgoal
   completely, using many fancy proof tools and performing a rather
   exhaustive search.  As a result, proof attempts may take rather long
   or diverge easily.
 
   \<^descr> @{method fast}, @{method best}, @{method slow} attempt to
   prove the first subgoal using sequent-style reasoning as explained
   before.  Unlike @{method blast}, they construct proofs directly in
   Isabelle.
 
   There is a difference in search strategy and back-tracking: @{method
   fast} uses depth-first search and @{method best} uses best-first
   search (guided by a heuristic function: normally the total size of
   the proof state).
 
   Method @{method slow} is like @{method fast}, but conducts a broader
   search: it may, when backtracking from a failed proof attempt, undo
   even the step of proving a subgoal by assumption.
 
   \<^descr> @{method fastforce}, @{method slowsimp}, @{method bestsimp}
   are like @{method fast}, @{method slow}, @{method best},
   respectively, but use the Simplifier as additional wrapper. The name
   @{method fastforce}, reflects the behaviour of this popular method
   better without requiring an understanding of its implementation.
 
   \<^descr> @{method deepen} works by exhaustive search up to a certain
   depth.  The start depth is 4 (unless specified explicitly), and the
   depth is increased iteratively up to 10.  Unsafe rules are modified
   to preserve the formula they act on, so that it be used repeatedly.
   This method can prove more goals than @{method fast}, but is much
   slower, for example if the assumptions have many universal
   quantifiers.
 
 
   Any of the above methods support additional modifiers of the context
   of classical (and simplifier) rules, but the ones related to the
   Simplifier are explicitly prefixed by \<open>simp\<close> here.  The
   semantics of these ad-hoc rule declarations is analogous to the
   attributes given before.  Facts provided by forward chaining are
   inserted into the goal before commencing proof search.
 \<close>
 
 
 subsection \<open>Partially automated methods\label{sec:classical:partial}\<close>
 
 text \<open>These proof methods may help in situations when the
   fully-automated tools fail.  The result is a simpler subgoal that
   can be tackled by other means, such as by manual instantiation of
   quantifiers.
 
   \begin{matharray}{rcl}
     @{method_def safe} & : & \<open>method\<close> \\
     @{method_def clarify} & : & \<open>method\<close> \\
     @{method_def clarsimp} & : & \<open>method\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     (@@{method safe} | @@{method clarify}) (@{syntax clamod} * )
     ;
     @@{method clarsimp} (@{syntax clasimpmod} * )
   \<close>
 
   \<^descr> @{method safe} repeatedly performs safe steps on all subgoals.
   It is deterministic, with at most one outcome.
 
   \<^descr> @{method clarify} performs a series of safe steps without
   splitting subgoals; see also @{method clarify_step}.
 
   \<^descr> @{method clarsimp} acts like @{method clarify}, but also does
   simplification.  Note that if the Simplifier context includes a
   splitter for the premises, the subgoal may still be split.
 \<close>
 
 
 subsection \<open>Single-step tactics\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{method_def safe_step} & : & \<open>method\<close> \\
     @{method_def inst_step} & : & \<open>method\<close> \\
     @{method_def step} & : & \<open>method\<close> \\
     @{method_def slow_step} & : & \<open>method\<close> \\
     @{method_def clarify_step} & : &  \<open>method\<close> \\
   \end{matharray}
 
   These are the primitive tactics behind the automated proof methods
   of the Classical Reasoner.  By calling them yourself, you can
   execute these procedures one step at a time.
 
   \<^descr> @{method safe_step} performs a safe step on the first subgoal.
   The safe wrapper tacticals are applied to a tactic that may include
   proof by assumption or Modus Ponens (taking care not to instantiate
   unknowns), or substitution.
 
   \<^descr> @{method inst_step} is like @{method safe_step}, but allows
   unknowns to be instantiated.
 
   \<^descr> @{method step} is the basic step of the proof procedure, it
   operates on the first subgoal.  The unsafe wrapper tacticals are
   applied to a tactic that tries @{method safe}, @{method inst_step},
   or applies an unsafe rule from the context.
 
   \<^descr> @{method slow_step} resembles @{method step}, but allows
   backtracking between using safe rules with instantiation (@{method
   inst_step}) and using unsafe rules.  The resulting search space is
   larger.
 
   \<^descr> @{method clarify_step} performs a safe step on the first
   subgoal; no splitting step is applied.  For example, the subgoal
   \<open>A \<and> B\<close> is left as a conjunction.  Proof by assumption,
   Modus Ponens, etc., may be performed provided they do not
   instantiate unknowns.  Assumptions of the form \<open>x = t\<close> may
   be eliminated.  The safe wrapper tactical is applied.
 \<close>
 
 
 subsection \<open>Modifying the search step\<close>
 
 text \<open>
   \begin{mldecls}
     @{define_ML_type wrapper = "(int -> tactic) -> (int -> tactic)"} \\[0.5ex]
     @{define_ML_infix addSWrapper: "Proof.context *
   (string * (Proof.context -> wrapper)) -> Proof.context"} \\
     @{define_ML_infix addSbefore: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
     @{define_ML_infix addSafter: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
     @{define_ML_infix delSWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
     @{define_ML_infix addWrapper: "Proof.context *
   (string * (Proof.context -> wrapper)) -> Proof.context"} \\
     @{define_ML_infix addbefore: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
     @{define_ML_infix addafter: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
     @{define_ML_infix delWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
     @{define_ML addSss: "Proof.context -> Proof.context"} \\
     @{define_ML addss: "Proof.context -> Proof.context"} \\
   \end{mldecls}
 
   The proof strategy of the Classical Reasoner is simple.  Perform as
   many safe inferences as possible; or else, apply certain safe rules,
   allowing instantiation of unknowns; or else, apply an unsafe rule.
   The tactics also eliminate assumptions of the form \<open>x = t\<close>
   by substitution if they have been set up to do so.  They may perform
   a form of Modus Ponens: if there are assumptions \<open>P \<longrightarrow> Q\<close> and
   \<open>P\<close>, then replace \<open>P \<longrightarrow> Q\<close> by \<open>Q\<close>.
 
   The classical reasoning tools --- except @{method blast} --- allow
   to modify this basic proof strategy by applying two lists of
   arbitrary \<^emph>\<open>wrapper tacticals\<close> to it.  The first wrapper list,
   which is considered to contain safe wrappers only, affects @{method
   safe_step} and all the tactics that call it.  The second one, which
   may contain unsafe wrappers, affects the unsafe parts of @{method
   step}, @{method slow_step}, and the tactics that call them.  A
   wrapper transforms each step of the search, for example by
   attempting other tactics before or after the original step tactic.
   All members of a wrapper list are applied in turn to the respective
   step tactic.
 
   Initially the two wrapper lists are empty, which means no
   modification of the step tactics. Safe and unsafe wrappers are added
   to the context with the functions given below, supplying them with
   wrapper names.  These names may be used to selectively delete
   wrappers.
 
   \<^descr> \<open>ctxt addSWrapper (name, wrapper)\<close> adds a new wrapper,
   which should yield a safe tactic, to modify the existing safe step
   tactic.
 
   \<^descr> \<open>ctxt addSbefore (name, tac)\<close> adds the given tactic as a
   safe wrapper, such that it is tried \<^emph>\<open>before\<close> each safe step of
   the search.
 
   \<^descr> \<open>ctxt addSafter (name, tac)\<close> adds the given tactic as a
   safe wrapper, such that it is tried when a safe step of the search
   would fail.
 
   \<^descr> \<open>ctxt delSWrapper name\<close> deletes the safe wrapper with
   the given name.
 
   \<^descr> \<open>ctxt addWrapper (name, wrapper)\<close> adds a new wrapper to
   modify the existing (unsafe) step tactic.
 
   \<^descr> \<open>ctxt addbefore (name, tac)\<close> adds the given tactic as an
   unsafe wrapper, such that it its result is concatenated
   \<^emph>\<open>before\<close> the result of each unsafe step.
 
   \<^descr> \<open>ctxt addafter (name, tac)\<close> adds the given tactic as an
   unsafe wrapper, such that it its result is concatenated \<^emph>\<open>after\<close>
   the result of each unsafe step.
 
   \<^descr> \<open>ctxt delWrapper name\<close> deletes the unsafe wrapper with
   the given name.
 
   \<^descr> \<open>addSss\<close> adds the simpset of the context to its
   classical set. The assumptions and goal will be simplified, in a
   rather safe way, after each safe step of the search.
 
   \<^descr> \<open>addss\<close> adds the simpset of the context to its
   classical set. The assumptions and goal will be simplified, before
   the each unsafe step of the search.
 \<close>
 
 
 section \<open>Object-logic setup \label{sec:object-logic}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "judgment"} & : & \<open>theory \<rightarrow> theory\<close> \\
     @{method_def atomize} & : & \<open>method\<close> \\
     @{attribute_def atomize} & : & \<open>attribute\<close> \\
     @{attribute_def rule_format} & : & \<open>attribute\<close> \\
     @{attribute_def rulify} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   The very starting point for any Isabelle object-logic is a ``truth
   judgment'' that links object-level statements to the meta-logic
   (with its minimal language of \<open>prop\<close> that covers universal
   quantification \<open>\<And>\<close> and implication \<open>\<Longrightarrow>\<close>).
 
   Common object-logics are sufficiently expressive to internalize rule
   statements over \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> within their own
   language.  This is useful in certain situations where a rule needs
   to be viewed as an atomic statement from the meta-level perspective,
   e.g.\ \<open>\<And>x. x \<in> A \<Longrightarrow> P x\<close> versus \<open>\<forall>x \<in> A. P x\<close>.
 
   From the following language elements, only the @{method atomize}
   method and @{attribute rule_format} attribute are occasionally
   required by end-users, the rest is for those who need to setup their
   own object-logic.  In the latter case existing formulations of
   Isabelle/FOL or Isabelle/HOL may be taken as realistic examples.
 
   Generic tools may refer to the information provided by object-logic
   declarations internally.
 
   \<^rail>\<open>
     @@{command judgment} @{syntax name} '::' @{syntax type} @{syntax mixfix}?
     ;
     @@{attribute atomize} ('(' 'full' ')')?
     ;
     @@{attribute rule_format} ('(' 'noasm' ')')?
   \<close>
 
   \<^descr> @{command "judgment"}~\<open>c :: \<sigma> (mx)\<close> declares constant
   \<open>c\<close> as the truth judgment of the current object-logic.  Its
   type \<open>\<sigma>\<close> should specify a coercion of the category of
   object-level propositions to \<open>prop\<close> of the Pure meta-logic;
   the mixfix annotation \<open>(mx)\<close> would typically just link the
   object language (internally of syntactic category \<open>logic\<close>)
   with that of \<open>prop\<close>.  Only one @{command "judgment"}
   declaration may be given in any theory development.
   
   \<^descr> @{method atomize} (as a method) rewrites any non-atomic
   premises of a sub-goal, using the meta-level equations declared via
   @{attribute atomize} (as an attribute) beforehand.  As a result,
   heavily nested goals become amenable to fundamental operations such
   as resolution (cf.\ the @{method (Pure) rule} method).  Giving the ``\<open>(full)\<close>'' option here means to turn the whole subgoal into an
   object-statement (if possible), including the outermost parameters
   and assumptions as well.
 
   A typical collection of @{attribute atomize} rules for a particular
   object-logic would provide an internalization for each of the
   connectives of \<open>\<And>\<close>, \<open>\<Longrightarrow>\<close>, and \<open>\<equiv>\<close>.
   Meta-level conjunction should be covered as well (this is
   particularly important for locales, see \secref{sec:locale}).
 
   \<^descr> @{attribute rule_format} rewrites a theorem by the equalities
   declared as @{attribute rulify} rules in the current object-logic.
   By default, the result is fully normalized, including assumptions
   and conclusions at any depth.  The \<open>(no_asm)\<close> option
   restricts the transformation to the conclusion of a rule.
 
   In common object-logics (HOL, FOL, ZF), the effect of @{attribute
   rule_format} is to replace (bounded) universal quantification
   (\<open>\<forall>\<close>) and implication (\<open>\<longrightarrow>\<close>) by the corresponding
   rule statements over \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close>.
 \<close>
 
 
 section \<open>Tracing higher-order unification\<close>
 
 text \<open>
   \begin{tabular}{rcll}
     @{attribute_def unify_trace_simp} & : & \<open>attribute\<close> & default \<open>false\<close> \\
     @{attribute_def unify_trace_types} & : & \<open>attribute\<close> & default \<open>false\<close> \\
     @{attribute_def unify_trace_bound} & : & \<open>attribute\<close> & default \<open>50\<close> \\
     @{attribute_def unify_search_bound} & : & \<open>attribute\<close> & default \<open>60\<close> \\
   \end{tabular}
   \<^medskip>
 
   Higher-order unification works well in most practical situations,
   but sometimes needs extra care to identify problems.  These tracing
   options may help.
 
   \<^descr> @{attribute unify_trace_simp} controls tracing of the
   simplification phase of higher-order unification.
 
   \<^descr> @{attribute unify_trace_types} controls warnings of
   incompleteness, when unification is not considering all possible
   instantiations of schematic type variables.
 
   \<^descr> @{attribute unify_trace_bound} determines the depth where
   unification starts to print tracing information once it reaches
   depth; 0 for full tracing.  At the default value, tracing
   information is almost never printed in practice.
 
   \<^descr> @{attribute unify_search_bound} prevents unification from
   searching past the given depth.  Because of this bound, higher-order
   unification cannot return an infinite sequence, though it can return
   an exponentially long one.  The search rarely approaches the default
   value in practice.  If the search is cut off, unification prints a
   warning ``Unification bound exceeded''.
 
 
   \begin{warn}
   Options for unification cannot be modified in a local context.  Only
   the global theory content is taken into account.
   \end{warn}
 \<close>
 
 end
diff --git a/src/Doc/Isar_Ref/Proof.thy b/src/Doc/Isar_Ref/Proof.thy
--- a/src/Doc/Isar_Ref/Proof.thy
+++ b/src/Doc/Isar_Ref/Proof.thy
@@ -1,1440 +1,1440 @@
 (*:maxLineLen=78:*)
 
 theory Proof
   imports Main Base
 begin
 
 chapter \<open>Proofs \label{ch:proofs}\<close>
 
 text \<open>
   Proof commands perform transitions of Isar/VM machine configurations, which
   are block-structured, consisting of a stack of nodes with three main
   components: logical proof context, current facts, and open goals. Isar/VM
   transitions are typed according to the following three different modes of
   operation:
 
     \<^descr> \<open>proof(prove)\<close> means that a new goal has just been stated that is now to
     be \<^emph>\<open>proven\<close>; the next command may refine it by some proof method, and
     enter a sub-proof to establish the actual result.
 
     \<^descr> \<open>proof(state)\<close> is like a nested theory mode: the context may be
     augmented by \<^emph>\<open>stating\<close> additional assumptions, intermediate results etc.
 
     \<^descr> \<open>proof(chain)\<close> is intermediate between \<open>proof(state)\<close> and
     \<open>proof(prove)\<close>: existing facts (i.e.\ the contents of the special
     @{fact_ref this} register) have been just picked up in order to be used
     when refining the goal claimed next.
 
   The proof mode indicator may be understood as an instruction to the writer,
   telling what kind of operation may be performed next. The corresponding
   typings of proof commands restricts the shape of well-formed proof texts to
   particular command sequences. So dynamic arrangements of commands eventually
   turn out as static texts of a certain structure.
 
   \Appref{ap:refcard} gives a simplified grammar of the (extensible) language
   emerging that way from the different types of proof commands. The main ideas
   of the overall Isar framework are explained in \chref{ch:isar-framework}.
 \<close>
 
 
 section \<open>Proof structure\<close>
 
 subsection \<open>Formal notepad\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "notepad"} & : & \<open>local_theory \<rightarrow> proof(state)\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{command notepad} @'begin'
     ;
     @@{command end}
   \<close>
 
   \<^descr> @{command "notepad"}~@{keyword "begin"} opens a proof state without any
   goal statement. This allows to experiment with Isar, without producing any
   persistent result. The notepad is closed by @{command "end"}.
 \<close>
 
 
 subsection \<open>Blocks\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "next"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "{"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "}"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
   \end{matharray}
 
   While Isar is inherently block-structured, opening and closing blocks is
   mostly handled rather casually, with little explicit user-intervention. Any
   local goal statement automatically opens \<^emph>\<open>two\<close> internal blocks, which are
   closed again when concluding the sub-proof (by @{command "qed"} etc.).
   Sections of different context within a sub-proof may be switched via
   @{command "next"}, which is just a single block-close followed by block-open
   again. The effect of @{command "next"} is to reset the local proof context;
   there is no goal focus involved here!
 
   For slightly more advanced applications, there are explicit block
   parentheses as well. These typically achieve a stronger forward style of
   reasoning.
 
   \<^descr> @{command "next"} switches to a fresh block within a sub-proof, resetting
   the local context to the initial one.
 
   \<^descr> @{command "{"} and @{command "}"} explicitly open and close blocks. Any
   current facts pass through ``@{command "{"}'' unchanged, while ``@{command
   "}"}'' causes any result to be \<^emph>\<open>exported\<close> into the enclosing context. Thus
   fixed variables are generalized, assumptions discharged, and local
   definitions unfolded (cf.\ \secref{sec:proof-context}). There is no
   difference of @{command "assume"} and @{command "presume"} in this mode of
   forward reasoning --- in contrast to plain backward reasoning with the
   result exported at @{command "show"} time.
 \<close>
 
 
 subsection \<open>Omitting proofs\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "oops"} & : & \<open>proof \<rightarrow> local_theory | theory\<close> \\
   \end{matharray}
 
   The @{command "oops"} command discontinues the current proof attempt, while
   considering the partial proof text as properly processed. This is
   conceptually quite different from ``faking'' actual proofs via @{command_ref
   "sorry"} (see \secref{sec:proof-steps}): @{command "oops"} does not observe
   the proof structure at all, but goes back right to the theory level.
   Furthermore, @{command "oops"} does not produce any result theorem --- there
   is no intended claim to be able to complete the proof in any way.
 
   A typical application of @{command "oops"} is to explain Isar proofs
   \<^emph>\<open>within\<close> the system itself, in conjunction with the document preparation
   tools of Isabelle described in \chref{ch:document-prep}. Thus partial or
   even wrong proof attempts can be discussed in a logically sound manner. Note
   that the Isabelle {\LaTeX} macros can be easily adapted to print something
   like ``\<open>\<dots>\<close>'' instead of the keyword ``@{command "oops"}''.
 \<close>
 
 
 section \<open>Statements\<close>
 
 subsection \<open>Context elements \label{sec:proof-context}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "fix"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "assume"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "presume"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "define"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
   \end{matharray}
 
   The logical proof context consists of fixed variables and assumptions. The
   former closely correspond to Skolem constants, or meta-level universal
   quantification as provided by the Isabelle/Pure logical framework.
   Introducing some \<^emph>\<open>arbitrary, but fixed\<close> variable via ``@{command
   "fix"}~\<open>x\<close>'' results in a local value that may be used in the subsequent
   proof as any other variable or constant. Furthermore, any result \<open>\<turnstile> \<phi>[x]\<close>
   exported from the context will be universally closed wrt.\ \<open>x\<close> at the
   outermost level: \<open>\<turnstile> \<And>x. \<phi>[x]\<close> (this is expressed in normal form using
   Isabelle's meta-variables).
 
   Similarly, introducing some assumption \<open>\<chi>\<close> has two effects. On the one hand,
   a local theorem is created that may be used as a fact in subsequent proof
   steps. On the other hand, any result \<open>\<chi> \<turnstile> \<phi>\<close> exported from the context
   becomes conditional wrt.\ the assumption: \<open>\<turnstile> \<chi> \<Longrightarrow> \<phi>\<close>. Thus, solving an
   enclosing goal using such a result would basically introduce a new subgoal
   stemming from the assumption. How this situation is handled depends on the
   version of assumption command used: while @{command "assume"} insists on
   solving the subgoal by unification with some premise of the goal, @{command
   "presume"} leaves the subgoal unchanged in order to be proved later by the
   user.
 
   Local definitions, introduced by ``\<^theory_text>\<open>define x where x = t\<close>'', are achieved
   by combining ``@{command "fix"}~\<open>x\<close>'' with another version of assumption
   that causes any hypothetical equation \<open>x \<equiv> t\<close> to be eliminated by the
   reflexivity rule. Thus, exporting some result \<open>x \<equiv> t \<turnstile> \<phi>[x]\<close> yields \<open>\<turnstile>
   \<phi>[t]\<close>.
 
   \<^rail>\<open>
     @@{command fix} @{syntax vars}
     ;
     (@@{command assume} | @@{command presume}) concl prems @{syntax for_fixes}
     ;
     concl: (@{syntax props} + @'and')
     ;
     prems: (@'if' (@{syntax props'} + @'and'))?
     ;
     @@{command define} @{syntax vars} @'where'
       (@{syntax props} + @'and') @{syntax for_fixes}
   \<close>
 
   \<^descr> @{command "fix"}~\<open>x\<close> introduces a local variable \<open>x\<close> that is \<^emph>\<open>arbitrary,
   but fixed\<close>.
 
   \<^descr> @{command "assume"}~\<open>a: \<phi>\<close> and @{command "presume"}~\<open>a: \<phi>\<close> introduce a
   local fact \<open>\<phi> \<turnstile> \<phi>\<close> by assumption. Subsequent results applied to an enclosing
   goal (e.g.\ by @{command_ref "show"}) are handled as follows: @{command
   "assume"} expects to be able to unify with existing premises in the goal,
   while @{command "presume"} leaves \<open>\<phi>\<close> as new subgoals.
 
   Several lists of assumptions may be given (separated by @{keyword_ref
   "and"}; the resulting list of current facts consists of all of these
   concatenated.
 
   A structured assumption like \<^theory_text>\<open>assume "B x" if "A x" for x\<close> is equivalent to
   \<^theory_text>\<open>assume "\<And>x. A x \<Longrightarrow> B x"\<close>, but vacuous quantification is avoided: a
   for-context only effects propositions according to actual use of variables.
 
   \<^descr> \<^theory_text>\<open>define x where "x = t"\<close> introduces a local (non-polymorphic) definition.
   In results that are exported from the context, \<open>x\<close> is replaced by \<open>t\<close>.
 
   Internally, equational assumptions are added to the context in Pure form,
   using \<open>x \<equiv> t\<close> instead of \<open>x = t\<close> or \<open>x \<longleftrightarrow> t\<close> from the object-logic. When
   exporting results from the context, \<open>x\<close> is generalized and the assumption
   discharged by reflexivity, causing the replacement by \<open>t\<close>.
 
   The default name for the definitional fact is \<open>x_def\<close>. Several simultaneous
   definitions may be given as well, with a collective default name.
 
   \<^medskip>
   It is also possible to abstract over local parameters as follows: \<^theory_text>\<open>define f
   :: "'a \<Rightarrow> 'b" where "f x = t" for x :: 'a\<close>.
 \<close>
 
 
 subsection \<open>Term abbreviations \label{sec:term-abbrev}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "let"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{keyword_def "is"} & : & syntax \\
   \end{matharray}
 
   Abbreviations may be either bound by explicit @{command "let"}~\<open>p \<equiv> t\<close>
   statements, or by annotating assumptions or goal statements with a list of
   patterns ``\<^theory_text>\<open>(is p\<^sub>1 \<dots> p\<^sub>n)\<close>''. In both cases, higher-order matching is
   invoked to bind extra-logical term variables, which may be either named
   schematic variables of the form \<open>?x\<close>, or nameless dummies ``@{variable _}''
   (underscore). Note that in the @{command "let"} form the patterns occur on
   the left-hand side, while the @{keyword "is"} patterns are in postfix
   position.
 
   Polymorphism of term bindings is handled in Hindley-Milner style, similar to
   ML. Type variables referring to local assumptions or open goal statements
   are \<^emph>\<open>fixed\<close>, while those of finished results or bound by @{command "let"}
   may occur in \<^emph>\<open>arbitrary\<close> instances later. Even though actual polymorphism
   should be rarely used in practice, this mechanism is essential to achieve
   proper incremental type-inference, as the user proceeds to build up the Isar
   proof text from left to right.
 
   \<^medskip>
   Term abbreviations are quite different from local definitions as introduced
   via @{command "define"} (see \secref{sec:proof-context}). The latter are
   visible within the logic as actual equations, while abbreviations disappear
   during the input process just after type checking. Also note that @{command
   "define"} does not support polymorphism.
 
   \<^rail>\<open>
     @@{command let} ((@{syntax term} + @'and') '=' @{syntax term} + @'and')
   \<close>
 
   The syntax of @{keyword "is"} patterns follows @{syntax term_pat} or
   @{syntax prop_pat} (see \secref{sec:term-decls}).
 
     \<^descr> \<^theory_text>\<open>let p\<^sub>1 = t\<^sub>1 and \<dots> p\<^sub>n = t\<^sub>n\<close> binds any text variables in patterns
     \<open>p\<^sub>1, \<dots>, p\<^sub>n\<close> by simultaneous higher-order matching against terms \<open>t\<^sub>1, \<dots>,
     t\<^sub>n\<close>.
 
     \<^descr> \<^theory_text>\<open>(is p\<^sub>1 \<dots> p\<^sub>n)\<close> resembles @{command "let"}, but matches \<open>p\<^sub>1, \<dots>, p\<^sub>n\<close>
     against the preceding statement. Also note that @{keyword "is"} is not a
     separate command, but part of others (such as @{command "assume"},
     @{command "have"} etc.).
 
   Some \<^emph>\<open>implicit\<close> term abbreviations\index{term abbreviations} for goals and
   facts are available as well. For any open goal, @{variable_ref thesis}
   refers to its object-level statement, abstracted over any meta-level
   parameters (if present). Likewise, @{variable_ref this} is bound for fact
   statements resulting from assumptions or finished goals. In case @{variable
   this} refers to an object-logic statement that is an application \<open>f t\<close>, then
   \<open>t\<close> is bound to the special text variable ``@{variable "\<dots>"}'' (three dots).
   The canonical application of this convenience are calculational proofs (see
   \secref{sec:calculation}).
 \<close>
 
 
 subsection \<open>Facts and forward chaining \label{sec:proof-facts}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "note"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "then"} & : & \<open>proof(state) \<rightarrow> proof(chain)\<close> \\
     @{command_def "from"} & : & \<open>proof(state) \<rightarrow> proof(chain)\<close> \\
     @{command_def "with"} & : & \<open>proof(state) \<rightarrow> proof(chain)\<close> \\
     @{command_def "using"} & : & \<open>proof(prove) \<rightarrow> proof(prove)\<close> \\
     @{command_def "unfolding"} & : & \<open>proof(prove) \<rightarrow> proof(prove)\<close> \\
     @{method_def "use"} & : & \<open>method\<close> \\
     @{fact_def "method_facts"} & : & \<open>fact\<close> \\
   \end{matharray}
 
   New facts are established either by assumption or proof of local statements.
   Any fact will usually be involved in further proofs, either as explicit
   arguments of proof methods, or when forward chaining towards the next goal
   via @{command "then"} (and variants); @{command "from"} and @{command
   "with"} are composite forms involving @{command "note"}. The @{command
   "using"} elements augments the collection of used facts \<^emph>\<open>after\<close> a goal has
   been stated. Note that the special theorem name @{fact_ref this} refers to
   the most recently established facts, but only \<^emph>\<open>before\<close> issuing a follow-up
   claim.
 
   \<^rail>\<open>
     @@{command note} (@{syntax thmdef}? @{syntax thms} + @'and')
     ;
     (@@{command from} | @@{command with} | @@{command using} | @@{command unfolding})
       (@{syntax thms} + @'and')
     ;
     @{method use} @{syntax thms} @'in' @{syntax method}
   \<close>
 
   \<^descr> @{command "note"}~\<open>a = b\<^sub>1 \<dots> b\<^sub>n\<close> recalls existing facts \<open>b\<^sub>1, \<dots>, b\<^sub>n\<close>,
   binding the result as \<open>a\<close>. Note that attributes may be involved as well,
   both on the left and right hand sides.
 
   \<^descr> @{command "then"} indicates forward chaining by the current facts in order
   to establish the goal to be claimed next. The initial proof method invoked
   to refine that will be offered the facts to do ``anything appropriate'' (see
   also \secref{sec:proof-steps}). For example, method @{method (Pure) rule}
   (see \secref{sec:pure-meth-att}) would typically do an elimination rather
   than an introduction. Automatic methods usually insert the facts into the
   goal state before operation. This provides a simple scheme to control
   relevance of facts in automated proof search.
 
   \<^descr> @{command "from"}~\<open>b\<close> abbreviates ``@{command "note"}~\<open>b\<close>~@{command
   "then"}''; thus @{command "then"} is equivalent to ``@{command
   "from"}~\<open>this\<close>''.
 
   \<^descr> @{command "with"}~\<open>b\<^sub>1 \<dots> b\<^sub>n\<close> abbreviates ``@{command "from"}~\<open>b\<^sub>1 \<dots> b\<^sub>n
   \<AND> this\<close>''; thus the forward chaining is from earlier facts together
   with the current ones.
 
   \<^descr> @{command "using"}~\<open>b\<^sub>1 \<dots> b\<^sub>n\<close> augments the facts to be used by a
   subsequent refinement step (such as @{command_ref "apply"} or @{command_ref
   "proof"}).
 
   \<^descr> @{command "unfolding"}~\<open>b\<^sub>1 \<dots> b\<^sub>n\<close> is structurally similar to @{command
   "using"}, but unfolds definitional equations \<open>b\<^sub>1 \<dots> b\<^sub>n\<close> throughout the goal
   state and facts. See also the proof method @{method_ref unfold}.
 
   \<^descr> \<^theory_text>\<open>(use b\<^sub>1 \<dots> b\<^sub>n in method)\<close> uses the facts in the given method
   expression. The facts provided by the proof state (via @{command "using"}
   etc.) are ignored, but it is possible to refer to @{fact method_facts}
   explicitly.
 
   \<^descr> @{fact method_facts} is a dynamic fact that refers to the currently used
   facts of the goal state.
 
 
   Forward chaining with an empty list of theorems is the same as not chaining
   at all. Thus ``@{command "from"}~\<open>nothing\<close>'' has no effect apart from
   entering \<open>prove(chain)\<close> mode, since @{fact_ref nothing} is bound to the
   empty list of theorems.
 
   Basic proof methods (such as @{method_ref (Pure) rule}) expect multiple
   facts to be given in their proper order, corresponding to a prefix of the
   premises of the rule involved. Note that positions may be easily skipped
   using something like @{command "from"}~\<open>_ \<AND> a \<AND> b\<close>, for example.
   This involves the trivial rule \<open>PROP \<psi> \<Longrightarrow> PROP \<psi>\<close>, which is bound in
   Isabelle/Pure as ``@{fact_ref "_"}'' (underscore).
 
   Automated methods (such as @{method simp} or @{method auto}) just insert any
   given facts before their usual operation. Depending on the kind of procedure
   involved, the order of facts is less significant here.
 \<close>
 
 
 subsection \<open>Goals \label{sec:goals}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "lemma"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close> \\
     @{command_def "theorem"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close> \\
     @{command_def "corollary"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close> \\
     @{command_def "proposition"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close> \\
     @{command_def "schematic_goal"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close> \\
     @{command_def "have"} & : & \<open>proof(state) | proof(chain) \<rightarrow> proof(prove)\<close> \\
     @{command_def "show"} & : & \<open>proof(state) | proof(chain) \<rightarrow> proof(prove)\<close> \\
     @{command_def "hence"} & : & \<open>proof(state) \<rightarrow> proof(prove)\<close> \\
     @{command_def "thus"} & : & \<open>proof(state) \<rightarrow> proof(prove)\<close> \\
     @{command_def "print_statement"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
   \end{matharray}
 
   From a theory context, proof mode is entered by an initial goal command such
   as @{command "lemma"}. Within a proof context, new claims may be introduced
   locally; there are variants to interact with the overall proof structure
   specifically, such as @{command have} or @{command show}.
 
   Goals may consist of multiple statements, resulting in a list of facts
   eventually. A pending multi-goal is internally represented as a meta-level
   conjunction (\<open>&&&\<close>), which is usually split into the corresponding number of
   sub-goals prior to an initial method application, via @{command_ref "proof"}
   (\secref{sec:proof-steps}) or @{command_ref "apply"}
   (\secref{sec:tactic-commands}). The @{method_ref induct} method covered in
   \secref{sec:cases-induct} acts on multiple claims simultaneously.
 
   Claims at the theory level may be either in short or long form. A short goal
   merely consists of several simultaneous propositions (often just one). A
   long goal includes an explicit context specification for the subsequent
   conclusion, involving local parameters and assumptions. Here the role of
   each part of the statement is explicitly marked by separate keywords (see
   also \secref{sec:locale}); the local assumptions being introduced here are
   available as @{fact_ref assms} in the proof. Moreover, there are two kinds
   of conclusions: @{element_def "shows"} states several simultaneous
   propositions (essentially a big conjunction), while @{element_def "obtains"}
   claims several simultaneous simultaneous contexts of (essentially a big
   disjunction of eliminated parameters and assumptions, cf.\
   \secref{sec:obtain}).
 
   \<^rail>\<open>
     (@@{command lemma} | @@{command theorem} | @@{command corollary} |
      @@{command proposition} | @@{command schematic_goal})
       (long_statement | short_statement)
     ;
     (@@{command have} | @@{command show} | @@{command hence} | @@{command thus})
       stmt cond_stmt @{syntax for_fixes}
     ;
     @@{command print_statement} @{syntax modes}? @{syntax thms}
     ;
 
     stmt: (@{syntax props} + @'and')
     ;
     cond_stmt: ((@'if' | @'when') stmt)?
     ;
     short_statement: stmt (@'if' stmt)? @{syntax for_fixes}
     ;
     long_statement: @{syntax thmdecl}? context conclusion
     ;
     context: (@{syntax_ref "includes"}?) (@{syntax context_elem} *)
     ;
     conclusion: @'shows' stmt | @'obtains' @{syntax obtain_clauses}
     ;
     @{syntax_def obtain_clauses}: (@{syntax par_name}? obtain_case + '|')
     ;
     @{syntax_def obtain_case}: @{syntax vars} @'where'
       (@{syntax thmdecl}? (@{syntax prop}+) + @'and')
   \<close>
 
   \<^descr> @{command "lemma"}~\<open>a: \<phi>\<close> enters proof mode with \<open>\<phi>\<close> as main goal,
   eventually resulting in some fact \<open>\<turnstile> \<phi>\<close> to be put back into the target
   context.
 
   A @{syntax long_statement} may build up an initial proof context for the
   subsequent claim, potentially including local definitions and syntax; see
   also @{syntax "includes"} in \secref{sec:bundle} and @{syntax context_elem}
   in \secref{sec:locale}.
 
   A @{syntax short_statement} consists of propositions as conclusion, with an
   option context of premises and parameters, via \<^verbatim>\<open>if\<close>/\<^verbatim>\<open>for\<close> in postfix
   notation, corresponding to \<^verbatim>\<open>assumes\<close>/\<^verbatim>\<open>fixes\<close> in the long prefix notation.
 
   Local premises (if present) are called ``\<open>assms\<close>'' for @{syntax
   long_statement}, and ``\<open>that\<close>'' for @{syntax short_statement}.
 
   \<^descr> @{command "theorem"}, @{command "corollary"}, and @{command "proposition"}
   are the same as @{command "lemma"}. The different command names merely serve
   as a formal comment in the theory source.
 
   \<^descr> @{command "schematic_goal"} is similar to @{command "theorem"}, but allows
   the statement to contain unbound schematic variables.
 
   Under normal circumstances, an Isar proof text needs to specify claims
   explicitly. Schematic goals are more like goals in Prolog, where certain
   results are synthesized in the course of reasoning. With schematic
   statements, the inherent compositionality of Isar proofs is lost, which also
   impacts performance, because proof checking is forced into sequential mode.
 
   \<^descr> @{command "have"}~\<open>a: \<phi>\<close> claims a local goal, eventually resulting in a
   fact within the current logical context. This operation is completely
   independent of any pending sub-goals of an enclosing goal statements, so
   @{command "have"} may be freely used for experimental exploration of
   potential results within a proof body.
 
   \<^descr> @{command "show"}~\<open>a: \<phi>\<close> is like @{command "have"}~\<open>a: \<phi>\<close> plus a second
   stage to refine some pending sub-goal for each one of the finished result,
   after having been exported into the corresponding context (at the head of
   the sub-proof of this @{command "show"} command).
 
   To accommodate interactive debugging, resulting rules are printed before
   being applied internally. Even more, interactive execution of @{command
   "show"} predicts potential failure and displays the resulting error as a
   warning beforehand. Watch out for the following message:
   @{verbatim [display] \<open>Local statement fails to refine any pending goal\<close>}
 
   \<^descr> @{command "hence"} expands to ``@{command "then"}~@{command "have"}'' and
   @{command "thus"} expands to ``@{command "then"}~@{command "show"}''. These
   conflations are left-over from early history of Isar. The expanded syntax is
   more orthogonal and improves readability and maintainability of proofs.
 
   \<^descr> @{command "print_statement"}~\<open>a\<close> prints facts from the current theory or
   proof context in long statement form, according to the syntax for @{command
   "lemma"} given above.
 
 
   Any goal statement causes some term abbreviations (such as @{variable_ref
   "?thesis"}) to be bound automatically, see also \secref{sec:term-abbrev}.
 
   Structured goal statements involving @{keyword_ref "if"} or @{keyword_ref
   "when"} define the special fact @{fact_ref that} to refer to these
   assumptions in the proof body. The user may provide separate names according
   to the syntax of the statement.
 \<close>
 
 
 section \<open>Calculational reasoning \label{sec:calculation}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "also"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "finally"} & : & \<open>proof(state) \<rightarrow> proof(chain)\<close> \\
     @{command_def "moreover"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "ultimately"} & : & \<open>proof(state) \<rightarrow> proof(chain)\<close> \\
     @{command_def "print_trans_rules"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
     @{attribute trans} & : & \<open>attribute\<close> \\
     @{attribute sym} & : & \<open>attribute\<close> \\
     @{attribute symmetric} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   Calculational proof is forward reasoning with implicit application of
   transitivity rules (such those of \<open>=\<close>, \<open>\<le>\<close>, \<open><\<close>). Isabelle/Isar maintains an
   auxiliary fact register @{fact_ref calculation} for accumulating results
   obtained by transitivity composed with the current result. Command @{command
   "also"} updates @{fact calculation} involving @{fact this}, while @{command
   "finally"} exhibits the final @{fact calculation} by forward chaining
   towards the next goal statement. Both commands require valid current facts,
   i.e.\ may occur only after commands that produce theorems such as @{command
   "assume"}, @{command "note"}, or some finished proof of @{command "have"},
   @{command "show"} etc. The @{command "moreover"} and @{command "ultimately"}
   commands are similar to @{command "also"} and @{command "finally"}, but only
   collect further results in @{fact calculation} without applying any rules
   yet.
 
   Also note that the implicit term abbreviation ``\<open>\<dots>\<close>'' has its canonical
   application with calculational proofs. It refers to the argument of the
   preceding statement. (The argument of a curried infix expression happens to
   be its right-hand side.)
 
   Isabelle/Isar calculations are implicitly subject to block structure in the
   sense that new threads of calculational reasoning are commenced for any new
   block (as opened by a local goal, for example). This means that, apart from
   being able to nest calculations, there is no separate \<^emph>\<open>begin-calculation\<close>
   command required.
 
   \<^medskip>
   The Isar calculation proof commands may be defined as follows:\<^footnote>\<open>We suppress
   internal bookkeeping such as proper handling of block-structure.\<close>
 
   \begin{matharray}{rcl}
     @{command "also"}\<open>\<^sub>0\<close> & \equiv & @{command "note"}~\<open>calculation = this\<close> \\
     @{command "also"}\<open>\<^sub>n\<^sub>+\<^sub>1\<close> & \equiv & @{command "note"}~\<open>calculation = trans [OF calculation this]\<close> \\[0.5ex]
     @{command "finally"} & \equiv & @{command "also"}~@{command "from"}~\<open>calculation\<close> \\[0.5ex]
     @{command "moreover"} & \equiv & @{command "note"}~\<open>calculation = calculation this\<close> \\
     @{command "ultimately"} & \equiv & @{command "moreover"}~@{command "from"}~\<open>calculation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     (@@{command also} | @@{command finally}) ('(' @{syntax thms} ')')?
     ;
     @@{attribute trans} (() | 'add' | 'del')
   \<close>
 
   \<^descr> @{command "also"}~\<open>(a\<^sub>1 \<dots> a\<^sub>n)\<close> maintains the auxiliary @{fact
   calculation} register as follows. The first occurrence of @{command "also"}
   in some calculational thread initializes @{fact calculation} by @{fact
   this}. Any subsequent @{command "also"} on the same level of block-structure
   updates @{fact calculation} by some transitivity rule applied to @{fact
   calculation} and @{fact this} (in that order). Transitivity rules are picked
   from the current context, unless alternative rules are given as explicit
   arguments.
 
   \<^descr> @{command "finally"}~\<open>(a\<^sub>1 \<dots> a\<^sub>n)\<close> maintains @{fact calculation} in the
   same way as @{command "also"} and then concludes the current calculational
   thread. The final result is exhibited as fact for forward chaining towards
   the next goal. Basically, @{command "finally"} abbreviates @{command
   "also"}~@{command "from"}~@{fact calculation}. Typical idioms for concluding
   calculational proofs are ``@{command "finally"}~@{command
   "show"}~\<open>?thesis\<close>~@{command "."}'' and ``@{command "finally"}~@{command
   "have"}~\<open>\<phi>\<close>~@{command "."}''.
 
   \<^descr> @{command "moreover"} and @{command "ultimately"} are analogous to
   @{command "also"} and @{command "finally"}, but collect results only,
   without applying rules.
 
   \<^descr> @{command "print_trans_rules"} prints the list of transitivity rules (for
   calculational commands @{command "also"} and @{command "finally"}) and
   symmetry rules (for the @{attribute symmetric} operation and single step
   elimination patters) of the current context.
 
   \<^descr> @{attribute trans} declares theorems as transitivity rules.
 
   \<^descr> @{attribute sym} declares symmetry rules, as well as @{attribute
   "Pure.elim"}\<open>?\<close> rules.
 
   \<^descr> @{attribute symmetric} resolves a theorem with some rule declared as
   @{attribute sym} in the current context. For example, ``@{command
   "assume"}~\<open>[symmetric]: x = y\<close>'' produces a swapped fact derived from that
   assumption.
 
   In structured proof texts it is often more appropriate to use an explicit
   single-step elimination proof, such as ``@{command "assume"}~\<open>x =
   y\<close>~@{command "then"}~@{command "have"}~\<open>y = x\<close>~@{command ".."}''.
 \<close>
 
 
 section \<open>Refinement steps\<close>
 
 subsection \<open>Proof method expressions \label{sec:proof-meth}\<close>
 
 text \<open>
   Proof methods are either basic ones, or expressions composed of methods via
   ``\<^verbatim>\<open>,\<close>'' (sequential composition), ``\<^verbatim>\<open>;\<close>'' (structural composition),
   ``\<^verbatim>\<open>|\<close>'' (alternative choices), ``\<^verbatim>\<open>?\<close>'' (try), ``\<^verbatim>\<open>+\<close>'' (repeat at least
   once), ``\<^verbatim>\<open>[\<close>\<open>n\<close>\<^verbatim>\<open>]\<close>'' (restriction to first \<open>n\<close> subgoals). In practice,
   proof methods are usually just a comma separated list of @{syntax
   name}~@{syntax args} specifications. Note that parentheses may be dropped
   for single method specifications (with no arguments). The syntactic
   precedence of method combinators is \<^verbatim>\<open>|\<close> \<^verbatim>\<open>;\<close> \<^verbatim>\<open>,\<close> \<^verbatim>\<open>[]\<close> \<^verbatim>\<open>+\<close> \<^verbatim>\<open>?\<close> (from low
   to high).
 
   \<^rail>\<open>
     @{syntax_def method}:
       (@{syntax name} | '(' methods ')') (() | '?' | '+' | '[' @{syntax nat}? ']')
     ;
     methods: (@{syntax name} @{syntax args} | @{syntax method}) + (',' | ';' | '|')
   \<close>
 
   Regular Isar proof methods do \<^emph>\<open>not\<close> admit direct goal addressing, but refer
   to the first subgoal or to all subgoals uniformly. Nonetheless, the
   subsequent mechanisms allow to imitate the effect of subgoal addressing that
   is known from ML tactics.
 
   \<^medskip>
   Goal \<^emph>\<open>restriction\<close> means the proof state is wrapped-up in a way that
   certain subgoals are exposed, and other subgoals are ``parked'' elsewhere.
   Thus a proof method has no other chance than to operate on the subgoals that
   are presently exposed.
 
   Structural composition ``\<open>m\<^sub>1\<close>\<^verbatim>\<open>;\<close>~\<open>m\<^sub>2\<close>'' means that method \<open>m\<^sub>1\<close> is
   applied with restriction to the first subgoal, then \<open>m\<^sub>2\<close> is applied
   consecutively with restriction to each subgoal that has newly emerged due to
-  \<open>m\<^sub>1\<close>. This is analogous to the tactic combinator \<^ML_op>\<open>THEN_ALL_NEW\<close> in
+  \<open>m\<^sub>1\<close>. This is analogous to the tactic combinator \<^ML_infix>\<open>THEN_ALL_NEW\<close> in
   Isabelle/ML, see also @{cite "isabelle-implementation"}. For example, \<open>(rule
   r; blast)\<close> applies rule \<open>r\<close> and then solves all new subgoals by \<open>blast\<close>.
 
   Moreover, the explicit goal restriction operator ``\<open>[n]\<close>'' exposes only the
   first \<open>n\<close> subgoals (which need to exist), with default \<open>n = 1\<close>. For example,
   the method expression ``\<open>simp_all[3]\<close>'' simplifies the first three subgoals,
   while ``\<open>(rule r, simp_all)[]\<close>'' simplifies all new goals that emerge from
   applying rule \<open>r\<close> to the originally first one.
 
   \<^medskip>
   Improper methods, notably tactic emulations, offer low-level goal addressing
   as explicit argument to the individual tactic being involved. Here ``\<open>[!]\<close>''
   refers to all goals, and ``\<open>[n-]\<close>'' to all goals starting from \<open>n\<close>.
 
   \<^rail>\<open>
     @{syntax_def goal_spec}:
       '[' (@{syntax nat} '-' @{syntax nat} | @{syntax nat} '-' | @{syntax nat} | '!' ) ']'
   \<close>
 \<close>
 
 
 subsection \<open>Initial and terminal proof steps \label{sec:proof-steps}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "proof"} & : & \<open>proof(prove) \<rightarrow> proof(state)\<close> \\
     @{command_def "qed"} & : & \<open>proof(state) \<rightarrow> proof(state) | local_theory | theory\<close> \\
     @{command_def "by"} & : & \<open>proof(prove) \<rightarrow> proof(state) | local_theory | theory\<close> \\
     @{command_def ".."} & : & \<open>proof(prove) \<rightarrow> proof(state) | local_theory | theory\<close> \\
     @{command_def "."} & : & \<open>proof(prove) \<rightarrow> proof(state) | local_theory | theory\<close> \\
     @{command_def "sorry"} & : & \<open>proof(prove) \<rightarrow> proof(state) | local_theory | theory\<close> \\
     @{method_def standard} & : & \<open>method\<close> \\
   \end{matharray}
 
   Arbitrary goal refinement via tactics is considered harmful. Structured
   proof composition in Isar admits proof methods to be invoked in two places
   only.
 
     \<^enum> An \<^emph>\<open>initial\<close> refinement step @{command_ref "proof"}~\<open>m\<^sub>1\<close> reduces a
     newly stated goal to a number of sub-goals that are to be solved later.
     Facts are passed to \<open>m\<^sub>1\<close> for forward chaining, if so indicated by
     \<open>proof(chain)\<close> mode.
 
     \<^enum> A \<^emph>\<open>terminal\<close> conclusion step @{command_ref "qed"}~\<open>m\<^sub>2\<close> is intended to
     solve remaining goals. No facts are passed to \<open>m\<^sub>2\<close>.
 
   The only other (proper) way to affect pending goals in a proof body is by
   @{command_ref "show"}, which involves an explicit statement of what is to be
   solved eventually. Thus we avoid the fundamental problem of unstructured
   tactic scripts that consist of numerous consecutive goal transformations,
   with invisible effects.
 
   \<^medskip>
   As a general rule of thumb for good proof style, initial proof methods
   should either solve the goal completely, or constitute some well-understood
   reduction to new sub-goals. Arbitrary automatic proof tools that are prone
   leave a large number of badly structured sub-goals are no help in continuing
   the proof document in an intelligible manner.
 
   Unless given explicitly by the user, the default initial method is @{method
   standard}, which subsumes at least @{method_ref (Pure) rule} or its
   classical variant @{method_ref (HOL) rule}. These methods apply a single
   standard elimination or introduction rule according to the topmost logical
   connective involved. There is no separate default terminal method. Any
   remaining goals are always solved by assumption in the very last step.
 
   \<^rail>\<open>
     @@{command proof} method?
     ;
     @@{command qed} method?
     ;
     @@{command "by"} method method?
     ;
     (@@{command "."} | @@{command ".."} | @@{command sorry})
   \<close>
 
   \<^descr> @{command "proof"}~\<open>m\<^sub>1\<close> refines the goal by proof method \<open>m\<^sub>1\<close>; facts for
   forward chaining are passed if so indicated by \<open>proof(chain)\<close> mode.
 
   \<^descr> @{command "qed"}~\<open>m\<^sub>2\<close> refines any remaining goals by proof method \<open>m\<^sub>2\<close>
   and concludes the sub-proof by assumption. If the goal had been \<open>show\<close>, some
   pending sub-goal is solved as well by the rule resulting from the result
   \<^emph>\<open>exported\<close> into the enclosing goal context. Thus \<open>qed\<close> may fail for two
   reasons: either \<open>m\<^sub>2\<close> fails, or the resulting rule does not fit to any
   pending goal\<^footnote>\<open>This includes any additional ``strong'' assumptions as
   introduced by @{command "assume"}.\<close> of the enclosing context. Debugging such
   a situation might involve temporarily changing @{command "show"} into
   @{command "have"}, or weakening the local context by replacing occurrences
   of @{command "assume"} by @{command "presume"}.
 
   \<^descr> @{command "by"}~\<open>m\<^sub>1 m\<^sub>2\<close> is a \<^emph>\<open>terminal proof\<close>\index{proof!terminal}; it
   abbreviates @{command "proof"}~\<open>m\<^sub>1\<close>~@{command "qed"}~\<open>m\<^sub>2\<close>, but with
   backtracking across both methods. Debugging an unsuccessful @{command
   "by"}~\<open>m\<^sub>1 m\<^sub>2\<close> command can be done by expanding its definition; in many
   cases @{command "proof"}~\<open>m\<^sub>1\<close> (or even \<open>apply\<close>~\<open>m\<^sub>1\<close>) is already sufficient
   to see the problem.
 
   \<^descr> ``@{command ".."}'' is a \<^emph>\<open>standard proof\<close>\index{proof!standard}; it
   abbreviates @{command "by"}~\<open>standard\<close>.
 
   \<^descr> ``@{command "."}'' is a \<^emph>\<open>trivial proof\<close>\index{proof!trivial}; it
   abbreviates @{command "by"}~\<open>this\<close>.
 
   \<^descr> @{command "sorry"} is a \<^emph>\<open>fake proof\<close>\index{proof!fake} pretending to
   solve the pending claim without further ado. This only works in interactive
   development, or if the @{attribute quick_and_dirty} is enabled. Facts
   emerging from fake proofs are not the real thing. Internally, the derivation
   object is tainted by an oracle invocation, which may be inspected via the
   command @{command "thm_oracles"} (\secref{sec:oracles}).
 
   The most important application of @{command "sorry"} is to support
   experimentation and top-down proof development.
 
   \<^descr> @{method standard} refers to the default refinement step of some Isar
   language elements (notably @{command proof} and ``@{command ".."}''). It is
   \<^emph>\<open>dynamically scoped\<close>, so the behaviour depends on the application
   environment.
 
   In Isabelle/Pure, @{method standard} performs elementary introduction~/
   elimination steps (@{method_ref (Pure) rule}), introduction of type classes
   (@{method_ref intro_classes}) and locales (@{method_ref intro_locales}).
 
   In Isabelle/HOL, @{method standard} also takes classical rules into account
   (cf.\ \secref{sec:classical}).
 \<close>
 
 
 subsection \<open>Fundamental methods and attributes \label{sec:pure-meth-att}\<close>
 
 text \<open>
   The following proof methods and attributes refer to basic logical operations
   of Isar. Further methods and attributes are provided by several generic and
   object-logic specific tools and packages (see \chref{ch:gen-tools} and
   \partref{part:hol}).
 
   \begin{matharray}{rcl}
     @{command_def "print_rules"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\[0.5ex]
     @{method_def "-"} & : & \<open>method\<close> \\
     @{method_def "goal_cases"} & : & \<open>method\<close> \\
     @{method_def "subproofs"} & : & \<open>method\<close> \\
     @{method_def "fact"} & : & \<open>method\<close> \\
     @{method_def "assumption"} & : & \<open>method\<close> \\
     @{method_def "this"} & : & \<open>method\<close> \\
     @{method_def (Pure) "rule"} & : & \<open>method\<close> \\
     @{attribute_def (Pure) "intro"} & : & \<open>attribute\<close> \\
     @{attribute_def (Pure) "elim"} & : & \<open>attribute\<close> \\
     @{attribute_def (Pure) "dest"} & : & \<open>attribute\<close> \\
     @{attribute_def (Pure) "rule"} & : & \<open>attribute\<close> \\[0.5ex]
     @{attribute_def "OF"} & : & \<open>attribute\<close> \\
     @{attribute_def "of"} & : & \<open>attribute\<close> \\
     @{attribute_def "where"} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{method goal_cases} (@{syntax name}*)
     ;
     @@{method subproofs} @{syntax method}
     ;
     @@{method fact} @{syntax thms}?
     ;
     @@{method (Pure) rule} @{syntax thms}?
     ;
     rulemod: ('intro' | 'elim' | 'dest')
       ((('!' | () | '?') @{syntax nat}?) | 'del') ':' @{syntax thms}
     ;
     (@@{attribute intro} | @@{attribute elim} | @@{attribute dest})
       ('!' | () | '?') @{syntax nat}?
     ;
     @@{attribute (Pure) rule} 'del'
     ;
     @@{attribute OF} @{syntax thms}
     ;
     @@{attribute of} @{syntax insts} ('concl' ':' @{syntax insts})? @{syntax for_fixes}
     ;
     @@{attribute "where"} @{syntax named_insts} @{syntax for_fixes}
   \<close>
 
   \<^descr> @{command "print_rules"} prints rules declared via attributes @{attribute
   (Pure) intro}, @{attribute (Pure) elim}, @{attribute (Pure) dest} of
   Isabelle/Pure.
 
   See also the analogous @{command "print_claset"} command for similar rule
   declarations of the classical reasoner (\secref{sec:classical}).
 
   \<^descr> ``@{method "-"}'' (minus) inserts the forward chaining facts as premises
   into the goal, and nothing else.
 
   Note that command @{command_ref "proof"} without any method actually
   performs a single reduction step using the @{method_ref (Pure) rule} method;
   thus a plain \<^emph>\<open>do-nothing\<close> proof step would be ``@{command "proof"}~\<open>-\<close>''
   rather than @{command "proof"} alone.
 
   \<^descr> @{method "goal_cases"}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> turns the current subgoals into cases
   within the context (see also \secref{sec:cases-induct}). The specified case
   names are used if present; otherwise cases are numbered starting from 1.
 
   Invoking cases in the subsequent proof body via the @{command_ref case}
   command will @{command fix} goal parameters, @{command assume} goal
   premises, and @{command let} variable @{variable_ref ?case} refer to the
   conclusion.
 
   \<^descr> @{method "subproofs"}~\<open>m\<close> applies the method expression \<open>m\<close> consecutively
   to each subgoal, constructing individual subproofs internally (analogous to
   ``\<^theory_text>\<open>show goal by m\<close>'' for each subgoal of the proof state). Search
   alternatives of \<open>m\<close> are truncated: the method is forced to be deterministic.
   This method combinator impacts the internal construction of proof terms: it
   makes a cascade of let-expressions within the derivation tree and may thus
   improve scalability.
 
   \<^descr> @{method "fact"}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> composes some fact from \<open>a\<^sub>1, \<dots>, a\<^sub>n\<close> (or
   implicitly from the current proof context) modulo unification of schematic
   type and term variables. The rule structure is not taken into account, i.e.\
   meta-level implication is considered atomic. This is the same principle
   underlying literal facts (cf.\ \secref{sec:syn-att}): ``@{command
   "have"}~\<open>\<phi>\<close>~@{command "by"}~\<open>fact\<close>'' is equivalent to ``@{command
   "note"}~\<^verbatim>\<open>`\<close>\<open>\<phi>\<close>\<^verbatim>\<open>`\<close>'' provided that \<open>\<turnstile> \<phi>\<close> is an instance of some known \<open>\<turnstile> \<phi>\<close>
   in the proof context.
 
   \<^descr> @{method assumption} solves some goal by a single assumption step. All
   given facts are guaranteed to participate in the refinement; this means
   there may be only 0 or 1 in the first place. Recall that @{command "qed"}
   (\secref{sec:proof-steps}) already concludes any remaining sub-goals by
   assumption, so structured proofs usually need not quote the @{method
   assumption} method at all.
 
   \<^descr> @{method this} applies all of the current facts directly as rules. Recall
   that ``@{command "."}'' (dot) abbreviates ``@{command "by"}~\<open>this\<close>''.
 
   \<^descr> @{method (Pure) rule}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> applies some rule given as argument in
   backward manner; facts are used to reduce the rule before applying it to the
   goal. Thus @{method (Pure) rule} without facts is plain introduction, while
   with facts it becomes elimination.
 
   When no arguments are given, the @{method (Pure) rule} method tries to pick
   appropriate rules automatically, as declared in the current context using
   the @{attribute (Pure) intro}, @{attribute (Pure) elim}, @{attribute (Pure)
   dest} attributes (see below). This is included in the standard behaviour of
   @{command "proof"} and ``@{command ".."}'' (double-dot) steps (see
   \secref{sec:proof-steps}).
 
   \<^descr> @{attribute (Pure) intro}, @{attribute (Pure) elim}, and @{attribute
   (Pure) dest} declare introduction, elimination, and destruct rules, to be
   used with method @{method (Pure) rule}, and similar tools. Note that the
   latter will ignore rules declared with ``\<open>?\<close>'', while ``\<open>!\<close>'' are used most
   aggressively.
 
   The classical reasoner (see \secref{sec:classical}) introduces its own
   variants of these attributes; use qualified names to access the present
   versions of Isabelle/Pure, i.e.\ @{attribute (Pure) "Pure.intro"}.
 
   \<^descr> @{attribute (Pure) rule}~\<open>del\<close> undeclares introduction, elimination, or
   destruct rules.
 
   \<^descr> @{attribute OF}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> applies some theorem to all of the given rules
   \<open>a\<^sub>1, \<dots>, a\<^sub>n\<close> in canonical right-to-left order, which means that premises
   stemming from the \<open>a\<^sub>i\<close> emerge in parallel in the result, without
   interfering with each other. In many practical situations, the \<open>a\<^sub>i\<close> do not
   have premises themselves, so \<open>rule [OF a\<^sub>1 \<dots> a\<^sub>n]\<close> can be actually read as
   functional application (modulo unification).
 
   Argument positions may be effectively skipped by using ``\<open>_\<close>'' (underscore),
   which refers to the propositional identity rule in the Pure theory.
 
   \<^descr> @{attribute of}~\<open>t\<^sub>1 \<dots> t\<^sub>n\<close> performs positional instantiation of term
   variables. The terms \<open>t\<^sub>1, \<dots>, t\<^sub>n\<close> are substituted for any schematic
   variables occurring in a theorem from left to right; ``\<open>_\<close>'' (underscore)
   indicates to skip a position. Arguments following a ``\<open>concl:\<close>''
   specification refer to positions of the conclusion of a rule.
 
   An optional context of local variables \<open>\<FOR> x\<^sub>1 \<dots> x\<^sub>m\<close> may be specified:
   the instantiated theorem is exported, and these variables become schematic
   (usually with some shifting of indices).
 
   \<^descr> @{attribute "where"}~\<open>x\<^sub>1 = t\<^sub>1 \<AND> \<dots> x\<^sub>n = t\<^sub>n\<close> performs named
   instantiation of schematic type and term variables occurring in a theorem.
   Schematic variables have to be specified on the left-hand side (e.g.\
   \<open>?x1.3\<close>). The question mark may be omitted if the variable name is a plain
   identifier without index. As type instantiations are inferred from term
   instantiations, explicit type instantiations are seldom necessary.
 
   An optional context of local variables \<open>\<FOR> x\<^sub>1 \<dots> x\<^sub>m\<close> may be specified
   as for @{attribute "of"} above.
 \<close>
 
 
 subsection \<open>Defining proof methods\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "method_setup"} & : & \<open>local_theory \<rightarrow> local_theory\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{command method_setup} @{syntax name} '=' @{syntax text} @{syntax text}?
   \<close>
 
   \<^descr> @{command "method_setup"}~\<open>name = text description\<close> defines a proof method
   in the current context. The given \<open>text\<close> has to be an ML expression of type
   \<^ML_type>\<open>(Proof.context -> Proof.method) context_parser\<close>, cf.\ basic
   parsers defined in structure \<^ML_structure>\<open>Args\<close> and \<^ML_structure>\<open>Attrib\<close>. There are also combinators like \<^ML>\<open>METHOD\<close> and \<^ML>\<open>SIMPLE_METHOD\<close> to turn certain tactic forms into official proof methods; the
   primed versions refer to tactics with explicit goal addressing.
 
   Here are some example method definitions:
 \<close>
 
 (*<*)experiment begin(*>*)
   method_setup my_method1 =
     \<open>Scan.succeed (K (SIMPLE_METHOD' (fn i: int => no_tac)))\<close>
     "my first method (without any arguments)"
 
   method_setup my_method2 =
     \<open>Scan.succeed (fn ctxt: Proof.context =>
       SIMPLE_METHOD' (fn i: int => no_tac))\<close>
     "my second method (with context)"
 
   method_setup my_method3 =
     \<open>Attrib.thms >> (fn thms: thm list => fn ctxt: Proof.context =>
       SIMPLE_METHOD' (fn i: int => no_tac))\<close>
     "my third method (with theorem arguments and context)"
 (*<*)end(*>*)
 
 
 section \<open>Proof by cases and induction \label{sec:cases-induct}\<close>
 
 subsection \<open>Rule contexts\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "case"} & : & \<open>proof(state) \<rightarrow> proof(state)\<close> \\
     @{command_def "print_cases"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
     @{attribute_def case_names} & : & \<open>attribute\<close> \\
     @{attribute_def case_conclusion} & : & \<open>attribute\<close> \\
     @{attribute_def params} & : & \<open>attribute\<close> \\
     @{attribute_def consumes} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   The puristic way to build up Isar proof contexts is by explicit language
   elements like @{command "fix"}, @{command "assume"}, @{command "let"} (see
   \secref{sec:proof-context}). This is adequate for plain natural deduction,
   but easily becomes unwieldy in concrete verification tasks, which typically
   involve big induction rules with several cases.
 
   The @{command "case"} command provides a shorthand to refer to a local
   context symbolically: certain proof methods provide an environment of named
   ``cases'' of the form \<open>c: x\<^sub>1, \<dots>, x\<^sub>m, \<phi>\<^sub>1, \<dots>, \<phi>\<^sub>n\<close>; the effect of
   ``@{command "case"}~\<open>c\<close>'' is then equivalent to ``@{command "fix"}~\<open>x\<^sub>1 \<dots>
   x\<^sub>m\<close>~@{command "assume"}~\<open>c: \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n\<close>''. Term bindings may be covered as
   well, notably @{variable ?case} for the main conclusion.
 
   By default, the ``terminology'' \<open>x\<^sub>1, \<dots>, x\<^sub>m\<close> of a case value is marked as
   hidden, i.e.\ there is no way to refer to such parameters in the subsequent
   proof text. After all, original rule parameters stem from somewhere outside
   of the current proof text. By using the explicit form ``@{command
   "case"}~\<open>(c y\<^sub>1 \<dots> y\<^sub>m)\<close>'' instead, the proof author is able to chose local
   names that fit nicely into the current context.
 
   \<^medskip>
   It is important to note that proper use of @{command "case"} does not
   provide means to peek at the current goal state, which is not directly
   observable in Isar! Nonetheless, goal refinement commands do provide named
   cases \<open>goal\<^sub>i\<close> for each subgoal \<open>i = 1, \<dots>, n\<close> of the resulting goal state.
   Using this extra feature requires great care, because some bits of the
   internal tactical machinery intrude the proof text. In particular, parameter
   names stemming from the left-over of automated reasoning tools are usually
   quite unpredictable.
 
   Under normal circumstances, the text of cases emerge from standard
   elimination or induction rules, which in turn are derived from previous
   theory specifications in a canonical way (say from @{command "inductive"}
   definitions).
 
   \<^medskip>
   Proper cases are only available if both the proof method and the rules
   involved support this. By using appropriate attributes, case names,
   conclusions, and parameters may be also declared by hand. Thus variant
   versions of rules that have been derived manually become ready to use in
   advanced case analysis later.
 
   \<^rail>\<open>
     @@{command case} @{syntax thmdecl}? (name | '(' name (('_' | @{syntax name}) *) ')')
     ;
     @@{attribute case_names} ((@{syntax name} ( '[' (('_' | @{syntax name}) *) ']' ) ? ) +)
     ;
     @@{attribute case_conclusion} @{syntax name} (@{syntax name} * )
     ;
     @@{attribute params} ((@{syntax name} * ) + @'and')
     ;
     @@{attribute consumes} @{syntax int}?
   \<close>
 
   \<^descr> @{command "case"}~\<open>a: (c x\<^sub>1 \<dots> x\<^sub>m)\<close> invokes a named local context \<open>c:
   x\<^sub>1, \<dots>, x\<^sub>m, \<phi>\<^sub>1, \<dots>, \<phi>\<^sub>m\<close>, as provided by an appropriate proof method (such
   as @{method_ref cases} and @{method_ref induct}). The command ``@{command
   "case"}~\<open>a: (c x\<^sub>1 \<dots> x\<^sub>m)\<close>'' abbreviates ``@{command "fix"}~\<open>x\<^sub>1 \<dots>
   x\<^sub>m\<close>~@{command "assume"}~\<open>a.c: \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n\<close>''. Each local fact is qualified by
   the prefix \<open>a\<close>, and all such facts are collectively bound to the name \<open>a\<close>.
 
   The fact name is specification \<open>a\<close> is optional, the default is to re-use
   \<open>c\<close>. So @{command "case"}~\<open>(c x\<^sub>1 \<dots> x\<^sub>m)\<close> is the same as @{command
   "case"}~\<open>c: (c x\<^sub>1 \<dots> x\<^sub>m)\<close>.
 
   \<^descr> @{command "print_cases"} prints all local contexts of the current state,
   using Isar proof language notation.
 
   \<^descr> @{attribute case_names}~\<open>c\<^sub>1 \<dots> c\<^sub>k\<close> declares names for the local contexts
   of premises of a theorem; \<open>c\<^sub>1, \<dots>, c\<^sub>k\<close> refers to the \<^emph>\<open>prefix\<close> of the list
   of premises. Each of the cases \<open>c\<^sub>i\<close> can be of the form \<open>c[h\<^sub>1 \<dots> h\<^sub>n]\<close> where
   the \<open>h\<^sub>1 \<dots> h\<^sub>n\<close> are the names of the hypotheses in case \<open>c\<^sub>i\<close> from left to
   right.
 
   \<^descr> @{attribute case_conclusion}~\<open>c d\<^sub>1 \<dots> d\<^sub>k\<close> declares names for the
   conclusions of a named premise \<open>c\<close>; here \<open>d\<^sub>1, \<dots>, d\<^sub>k\<close> refers to the prefix
   of arguments of a logical formula built by nesting a binary connective
   (e.g.\ \<open>\<or>\<close>).
 
   Note that proof methods such as @{method induct} and @{method coinduct}
   already provide a default name for the conclusion as a whole. The need to
   name subformulas only arises with cases that split into several sub-cases,
   as in common co-induction rules.
 
   \<^descr> @{attribute params}~\<open>p\<^sub>1 \<dots> p\<^sub>m \<AND> \<dots> q\<^sub>1 \<dots> q\<^sub>n\<close> renames the innermost
   parameters of premises \<open>1, \<dots>, n\<close> of some theorem. An empty list of names may
   be given to skip positions, leaving the present parameters unchanged.
 
   Note that the default usage of case rules does \<^emph>\<open>not\<close> directly expose
   parameters to the proof context.
 
   \<^descr> @{attribute consumes}~\<open>n\<close> declares the number of ``major premises'' of a
   rule, i.e.\ the number of facts to be consumed when it is applied by an
   appropriate proof method. The default value of @{attribute consumes} is \<open>n =
   1\<close>, which is appropriate for the usual kind of cases and induction rules for
   inductive sets (cf.\ \secref{sec:hol-inductive}). Rules without any
   @{attribute consumes} declaration given are treated as if @{attribute
   consumes}~\<open>0\<close> had been specified.
 
   A negative \<open>n\<close> is interpreted relatively to the total number of premises of
   the rule in the target context. Thus its absolute value specifies the
   remaining number of premises, after subtracting the prefix of major premises
   as indicated above. This form of declaration has the technical advantage of
   being stable under more morphisms, notably those that export the result from
   a nested @{command_ref context} with additional assumptions.
 
   Note that explicit @{attribute consumes} declarations are only rarely
   needed; this is already taken care of automatically by the higher-level
   @{attribute cases}, @{attribute induct}, and @{attribute coinduct}
   declarations.
 \<close>
 
 
 subsection \<open>Proof methods\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{method_def cases} & : & \<open>method\<close> \\
     @{method_def induct} & : & \<open>method\<close> \\
     @{method_def induction} & : & \<open>method\<close> \\
     @{method_def coinduct} & : & \<open>method\<close> \\
   \end{matharray}
 
   The @{method cases}, @{method induct}, @{method induction}, and @{method
   coinduct} methods provide a uniform interface to common proof techniques
   over datatypes, inductive predicates (or sets), recursive functions etc. The
   corresponding rules may be specified and instantiated in a casual manner.
   Furthermore, these methods provide named local contexts that may be invoked
   via the @{command "case"} proof command within the subsequent proof text.
   This accommodates compact proof texts even when reasoning about large
   specifications.
 
   The @{method induct} method also provides some infrastructure to work with
   structured statements (either using explicit meta-level connectives, or
   including facts and parameters separately). This avoids cumbersome encoding
   of ``strengthened'' inductive statements within the object-logic.
 
   Method @{method induction} differs from @{method induct} only in the names
   of the facts in the local context invoked by the @{command "case"} command.
 
   \<^rail>\<open>
     @@{method cases} ('(' 'no_simp' ')')? \<newline>
       (@{syntax insts} * @'and') rule?
     ;
     (@@{method induct} | @@{method induction})
       ('(' 'no_simp' ')')? (definsts * @'and') \<newline> arbitrary? taking? rule?
     ;
     @@{method coinduct} @{syntax insts} taking rule?
     ;
 
     rule: ('type' | 'pred' | 'set') ':' (@{syntax name} +) | 'rule' ':' (@{syntax thm} +)
     ;
     definst: @{syntax name} ('==' | '\<equiv>') @{syntax term} | '(' @{syntax term} ')' | @{syntax inst}
     ;
     definsts: ( definst * )
     ;
     arbitrary: 'arbitrary' ':' ((@{syntax term} * ) @'and' +)
     ;
     taking: 'taking' ':' @{syntax insts}
   \<close>
 
   \<^descr> @{method cases}~\<open>insts R\<close> applies method @{method rule} with an
   appropriate case distinction theorem, instantiated to the subjects \<open>insts\<close>.
   Symbolic case names are bound according to the rule's local contexts.
 
   The rule is determined as follows, according to the facts and arguments
   passed to the @{method cases} method:
 
   \<^medskip>
   \begin{tabular}{llll}
     facts           &                 & arguments   & rule \\\hline
     \<open>\<turnstile> R\<close>   & @{method cases} &             & implicit rule \<open>R\<close> \\
                     & @{method cases} &             & classical case split \\
                     & @{method cases} & \<open>t\<close>   & datatype exhaustion (type of \<open>t\<close>) \\
     \<open>\<turnstile> A t\<close> & @{method cases} & \<open>\<dots>\<close> & inductive predicate/set elimination (of \<open>A\<close>) \\
     \<open>\<dots>\<close>     & @{method cases} & \<open>\<dots> rule: R\<close> & explicit rule \<open>R\<close> \\
   \end{tabular}
   \<^medskip>
 
   Several instantiations may be given, referring to the \<^emph>\<open>suffix\<close> of premises
   of the case rule; within each premise, the \<^emph>\<open>prefix\<close> of variables is
   instantiated. In most situations, only a single term needs to be specified;
   this refers to the first variable of the last premise (it is usually the
   same for all cases). The \<open>(no_simp)\<close> option can be used to disable
   pre-simplification of cases (see the description of @{method induct} below
   for details).
 
   \<^descr> @{method induct}~\<open>insts R\<close> and @{method induction}~\<open>insts R\<close> are analogous
   to the @{method cases} method, but refer to induction rules, which are
   determined as follows:
 
   \<^medskip>
   \begin{tabular}{llll}
     facts   &                  & arguments     & rule \\\hline
             & @{method induct} & \<open>P x\<close>         & datatype induction (type of \<open>x\<close>) \\
     \<open>\<turnstile> A x\<close> & @{method induct} & \<open>\<dots>\<close>          & predicate/set induction (of \<open>A\<close>) \\
     \<open>\<dots>\<close>    & @{method induct} & \<open>\<dots> rule: R\<close>  & explicit rule \<open>R\<close> \\
   \end{tabular}
   \<^medskip>
 
   Several instantiations may be given, each referring to some part of a mutual
   inductive definition or datatype --- only related partial induction rules
   may be used together, though. Any of the lists of terms \<open>P, x, \<dots>\<close> refers to
   the \<^emph>\<open>suffix\<close> of variables present in the induction rule. This enables the
   writer to specify only induction variables, or both predicates and
   variables, for example.
 
   Instantiations may be definitional: equations \<open>x \<equiv> t\<close> introduce local
   definitions, which are inserted into the claim and discharged after applying
   the induction rule. Equalities reappear in the inductive cases, but have
   been transformed according to the induction principle being involved here.
   In order to achieve practically useful induction hypotheses, some variables
   occurring in \<open>t\<close> need to generalized (see below). Instantiations of
   the form \<open>t\<close>, where \<open>t\<close> is not a variable, are taken as a shorthand for \<open>x \<equiv>
   t\<close>, where \<open>x\<close> is a fresh variable. If this is not intended, \<open>t\<close> has to be
   enclosed in parentheses. By default, the equalities generated by
   definitional instantiations are pre-simplified using a specific set of
   rules, usually consisting of distinctness and injectivity theorems for
   datatypes. This pre-simplification may cause some of the parameters of an
   inductive case to disappear, or may even completely delete some of the
   inductive cases, if one of the equalities occurring in their premises can be
   simplified to \<open>False\<close>. The \<open>(no_simp)\<close> option can be used to disable
   pre-simplification. Additional rules to be used in pre-simplification can be
   declared using the @{attribute_def induct_simp} attribute.
 
   The optional ``\<open>arbitrary: x\<^sub>1 \<dots> x\<^sub>m\<close>'' specification generalizes variables
   \<open>x\<^sub>1, \<dots>, x\<^sub>m\<close> of the original goal before applying induction. It is possible
   to separate variables by ``\<open>and\<close>'' to generalize in goals other than
   the first. Thus induction hypotheses may become sufficiently general to get
   the proof through. Together with definitional instantiations, one may
   effectively perform induction over expressions of a certain structure.
 
   The optional ``\<open>taking: t\<^sub>1 \<dots> t\<^sub>n\<close>'' specification provides additional
   instantiations of a prefix of pending variables in the rule. Such schematic
   induction rules rarely occur in practice, though.
 
   \<^descr> @{method coinduct}~\<open>inst R\<close> is analogous to the @{method induct} method,
   but refers to coinduction rules, which are determined as follows:
 
   \<^medskip>
   \begin{tabular}{llll}
     goal  &                    & arguments & rule \\\hline
           & @{method coinduct} & \<open>x\<close> & type coinduction (type of \<open>x\<close>) \\
     \<open>A x\<close> & @{method coinduct} & \<open>\<dots>\<close> & predicate/set coinduction (of \<open>A\<close>) \\
     \<open>\<dots>\<close>   & @{method coinduct} & \<open>\<dots> rule: R\<close> & explicit rule \<open>R\<close> \\
   \end{tabular}
   \<^medskip>
 
   Coinduction is the dual of induction. Induction essentially eliminates \<open>A x\<close>
   towards a generic result \<open>P x\<close>, while coinduction introduces \<open>A x\<close> starting
   with \<open>B x\<close>, for a suitable ``bisimulation'' \<open>B\<close>. The cases of a coinduct
   rule are typically named after the predicates or sets being covered, while
   the conclusions consist of several alternatives being named after the
   individual destructor patterns.
 
   The given instantiation refers to the \<^emph>\<open>suffix\<close> of variables occurring in
   the rule's major premise, or conclusion if unavailable. An additional
   ``\<open>taking: t\<^sub>1 \<dots> t\<^sub>n\<close>'' specification may be required in order to specify
   the bisimulation to be used in the coinduction step.
 
 
   Above methods produce named local contexts, as determined by the
   instantiated rule as given in the text. Beyond that, the @{method induct}
   and @{method coinduct} methods guess further instantiations from the goal
   specification itself. Any persisting unresolved schematic variables of the
   resulting rule will render the the corresponding case invalid. The term
   binding @{variable ?case} for the conclusion will be provided with each
   case, provided that term is fully specified.
 
   The @{command "print_cases"} command prints all named cases present in the
   current proof state.
 
   \<^medskip>
   Despite the additional infrastructure, both @{method cases} and @{method
   coinduct} merely apply a certain rule, after instantiation, while conforming
   due to the usual way of monotonic natural deduction: the context of a
   structured statement \<open>\<And>x\<^sub>1 \<dots> x\<^sub>m. \<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<dots>\<close> reappears unchanged after
   the case split.
 
   The @{method induct} method is fundamentally different in this respect: the
   meta-level structure is passed through the ``recursive'' course involved in
   the induction. Thus the original statement is basically replaced by separate
   copies, corresponding to the induction hypotheses and conclusion; the
   original goal context is no longer available. Thus local assumptions, fixed
   parameters and definitions effectively participate in the inductive
   rephrasing of the original statement.
 
   In @{method induct} proofs, local assumptions introduced by cases are split
   into two different kinds: \<open>hyps\<close> stemming from the rule and \<open>prems\<close> from the
   goal statement. This is reflected in the extracted cases accordingly, so
   invoking ``@{command "case"}~\<open>c\<close>'' will provide separate facts \<open>c.hyps\<close> and
   \<open>c.prems\<close>, as well as fact \<open>c\<close> to hold the all-inclusive list.
 
   In @{method induction} proofs, local assumptions introduced by cases are
   split into three different kinds: \<open>IH\<close>, the induction hypotheses, \<open>hyps\<close>,
   the remaining hypotheses stemming from the rule, and \<open>prems\<close>, the
   assumptions from the goal statement. The names are \<open>c.IH\<close>, \<open>c.hyps\<close> and
   \<open>c.prems\<close>, as above.
 
   \<^medskip>
   Facts presented to either method are consumed according to the number of
   ``major premises'' of the rule involved, which is usually 0 for plain cases
   and induction rules of datatypes etc.\ and 1 for rules of inductive
   predicates or sets and the like. The remaining facts are inserted into the
   goal verbatim before the actual \<open>cases\<close>, \<open>induct\<close>, or \<open>coinduct\<close> rule is
   applied.
 \<close>
 
 
 subsection \<open>Declaring rules\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "print_induct_rules"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
     @{attribute_def cases} & : & \<open>attribute\<close> \\
     @{attribute_def induct} & : & \<open>attribute\<close> \\
     @{attribute_def coinduct} & : & \<open>attribute\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
     @@{attribute cases} spec
     ;
     @@{attribute induct} spec
     ;
     @@{attribute coinduct} spec
     ;
 
     spec: (('type' | 'pred' | 'set') ':' @{syntax name}) | 'del'
   \<close>
 
   \<^descr> @{command "print_induct_rules"} prints cases and induct rules for
   predicates (or sets) and types of the current context.
 
   \<^descr> @{attribute cases}, @{attribute induct}, and @{attribute coinduct} (as
   attributes) declare rules for reasoning about (co)inductive predicates (or
   sets) and types, using the corresponding methods of the same name. Certain
   definitional packages of object-logics usually declare emerging cases and
   induction rules as expected, so users rarely need to intervene.
 
   Rules may be deleted via the \<open>del\<close> specification, which covers all of the
   \<open>type\<close>/\<open>pred\<close>/\<open>set\<close> sub-categories simultaneously. For example, @{attribute
   cases}~\<open>del\<close> removes any @{attribute cases} rules declared for some type,
   predicate, or set.
 
   Manual rule declarations usually refer to the @{attribute case_names} and
   @{attribute params} attributes to adjust names of cases and parameters of a
   rule; the @{attribute consumes} declaration is taken care of automatically:
   @{attribute consumes}~\<open>0\<close> is specified for ``type'' rules and @{attribute
   consumes}~\<open>1\<close> for ``predicate'' / ``set'' rules.
 \<close>
 
 
 section \<open>Generalized elimination and case splitting \label{sec:obtain}\<close>
 
 text \<open>
   \begin{matharray}{rcl}
     @{command_def "consider"} & : & \<open>proof(state) | proof(chain) \<rightarrow> proof(prove)\<close> \\
     @{command_def "obtain"} & : & \<open>proof(state) | proof(chain) \<rightarrow> proof(prove)\<close> \\
     @{command_def "guess"}\<open>\<^sup>*\<close> & : & \<open>proof(state) | proof(chain) \<rightarrow> proof(prove)\<close> \\
   \end{matharray}
 
   Generalized elimination means that hypothetical parameters and premises may
   be introduced in the current context, potentially with a split into cases.
   This works by virtue of a locally proven rule that establishes the soundness
   of this temporary context extension. As representative examples, one may
   think of standard rules from Isabelle/HOL like this:
 
   \<^medskip>
   \begin{tabular}{ll}
   \<open>\<exists>x. B x \<Longrightarrow> (\<And>x. B x \<Longrightarrow> thesis) \<Longrightarrow> thesis\<close> \\
   \<open>A \<and> B \<Longrightarrow> (A \<Longrightarrow> B \<Longrightarrow> thesis) \<Longrightarrow> thesis\<close> \\
   \<open>A \<or> B \<Longrightarrow> (A \<Longrightarrow> thesis) \<Longrightarrow> (B \<Longrightarrow> thesis) \<Longrightarrow> thesis\<close> \\
   \end{tabular}
   \<^medskip>
 
   In general, these particular rules and connectives need to get involved at
   all: this concept works directly in Isabelle/Pure via Isar commands defined
   below. In particular, the logic of elimination and case splitting is
   delegated to an Isar proof, which often involves automated tools.
 
   \<^rail>\<open>
     @@{command consider} @{syntax obtain_clauses}
     ;
     @@{command obtain} @{syntax par_name}? @{syntax vars} \<newline>
       @'where' concl prems @{syntax for_fixes}
     ;
     concl: (@{syntax props} + @'and')
     ;
     prems: (@'if' (@{syntax props'} + @'and'))?
     ;
     @@{command guess} @{syntax vars}
   \<close>
 
   \<^descr> @{command consider}~\<open>(a) \<^vec>x \<WHERE> \<^vec>A \<^vec>x | (b)
   \<^vec>y \<WHERE> \<^vec>B \<^vec>y | \<dots>\<close> states a rule for case splitting
   into separate subgoals, such that each case involves new parameters and
   premises. After the proof is finished, the resulting rule may be used
   directly with the @{method cases} proof method (\secref{sec:cases-induct}),
   in order to perform actual case-splitting of the proof text via @{command
   case} and @{command next} as usual.
 
   Optional names in round parentheses refer to case names: in the proof of the
   rule this is a fact name, in the resulting rule it is used as annotation
   with the @{attribute_ref case_names} attribute.
 
   \<^medskip>
   Formally, the command @{command consider} is defined as derived Isar
   language element as follows:
 
   \begin{matharray}{l}
     @{command "consider"}~\<open>(a) \<^vec>x \<WHERE> \<^vec>A \<^vec>x | (b) \<^vec>y \<WHERE> \<^vec>B \<^vec>y | \<dots> \<equiv>\<close> \\[1ex]
     \quad @{command "have"}~\<open>[case_names a b \<dots>]: thesis\<close> \\
     \qquad \<open>\<IF> a [Pure.intro?]: \<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis\<close> \\
     \qquad \<open>\<AND> b [Pure.intro?]: \<And>\<^vec>y. \<^vec>B \<^vec>y \<Longrightarrow> thesis\<close> \\
     \qquad \<open>\<AND> \<dots>\<close> \\
     \qquad \<open>\<FOR> thesis\<close> \\
     \qquad @{command "apply"}~\<open>(insert a b \<dots>)\<close> \\
   \end{matharray}
 
   See also \secref{sec:goals} for @{keyword "obtains"} in toplevel goal
   statements, as well as @{command print_statement} to print existing rules in
   a similar format.
 
   \<^descr> @{command obtain}~\<open>\<^vec>x \<WHERE> \<^vec>A \<^vec>x\<close> states a
   generalized elimination rule with exactly one case. After the proof is
   finished, it is activated for the subsequent proof text: the context is
   augmented via @{command fix}~\<open>\<^vec>x\<close> @{command assume}~\<open>\<^vec>A
   \<^vec>x\<close>, with special provisions to export later results by discharging
   these assumptions again.
 
   Note that according to the parameter scopes within the elimination rule,
   results \<^emph>\<open>must not\<close> refer to hypothetical parameters; otherwise the export
   will fail! This restriction conforms to the usual manner of existential
   reasoning in Natural Deduction.
 
   \<^medskip>
   Formally, the command @{command obtain} is defined as derived Isar language
   element as follows, using an instrumented variant of @{command assume}:
 
   \begin{matharray}{l}
     @{command "obtain"}~\<open>\<^vec>x \<WHERE> a: \<^vec>A \<^vec>x  \<langle>proof\<rangle> \<equiv>\<close> \\[1ex]
     \quad @{command "have"}~\<open>thesis\<close> \\
     \qquad \<open>\<IF> that [Pure.intro?]: \<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis\<close> \\
     \qquad \<open>\<FOR> thesis\<close> \\
     \qquad @{command "apply"}~\<open>(insert that)\<close> \\
     \qquad \<open>\<langle>proof\<rangle>\<close> \\
     \quad @{command "fix"}~\<open>\<^vec>x\<close>~@{command "assume"}\<open>\<^sup>* a: \<^vec>A \<^vec>x\<close> \\
   \end{matharray}
 
   \<^descr> @{command guess} is similar to @{command obtain}, but it derives the
   obtained context elements from the course of tactical reasoning in the
   proof. Thus it can considerably obscure the proof: it is classified as
   \<^emph>\<open>improper\<close>.
 
   A proof with @{command guess} starts with a fixed goal \<open>thesis\<close>. The
   subsequent refinement steps may turn this to anything of the form
   \<open>\<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis\<close>, but without splitting into new
   subgoals. The final goal state is then used as reduction rule for the obtain
   pattern described above. Obtained parameters \<open>\<^vec>x\<close> are marked as
   internal by default, and thus inaccessible in the proof text. The variable
   names and type constraints given as arguments for @{command "guess"} specify
   a prefix of accessible parameters.
 
 
   In the proof of @{command consider} and @{command obtain} the local premises
   are always bound to the fact name @{fact_ref that}, according to structured
   Isar statements involving @{keyword_ref "if"} (\secref{sec:goals}).
 
   Facts that are established by @{command "obtain"} and @{command "guess"} may
   not be polymorphic: any type-variables occurring here are fixed in the
   present context. This is a natural consequence of the role of @{command fix}
   and @{command assume} in these constructs.
 \<close>
 
 end
diff --git a/src/Doc/antiquote_setup.ML b/src/Doc/antiquote_setup.ML
--- a/src/Doc/antiquote_setup.ML
+++ b/src/Doc/antiquote_setup.ML
@@ -1,246 +1,158 @@
 (*  Title:      Doc/antiquote_setup.ML
     Author:     Makarius
 
 Auxiliary antiquotations for the Isabelle manuals.
 *)
 
 structure Antiquote_Setup: sig end =
 struct
 
 (* misc utils *)
 
 fun translate f = Symbol.explode #> map f #> implode;
 
 val clean_string = translate
   (fn "_" => "\\_"
     | "#" => "\\#"
     | "$" => "\\$"
     | "%" => "\\%"
     | "<" => "$<$"
     | ">" => "$>$"
     | "{" => "\\{"
     | "|" => "$\\mid$"
     | "}" => "\\}"
     | "\<hyphen>" => "-"
     | c => c);
 
 fun clean_name "\<dots>" = "dots"
   | clean_name ".." = "ddot"
   | clean_name "." = "dot"
   | clean_name "_" = "underscore"
   | clean_name "{" = "braceleft"
   | clean_name "}" = "braceright"
   | clean_name s = s |> translate (fn "_" => "-" | "\<hyphen>" => "-" | c => c);
 
 
-(* ML text *)
-
-local
-
-fun test_val (ml1, []) = ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read ");"
-  | test_val (ml1, ml2) = ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read " : " @ ml2 @ ML_Lex.read ");";
-
-fun test_op (ml1, ml2) = test_val (ML_Lex.read "op " @ ml1, ml2);
-
-fun test_type (ml1, []) = ML_Lex.read "val _ = NONE : (" @ ml1 @ ML_Lex.read ") option;"
-  | test_type (ml1, ml2) =
-      ML_Lex.read "val _ = [NONE : (" @ ml1 @ ML_Lex.read ") option, NONE : (" @
-      ml2 @ ML_Lex.read ") option];";
-
-fun text_exn (ml1, []) = ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read " : exn);"
-  | text_exn (ml1, ml2) =
-      ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read " : " @ ml2 @ ML_Lex.read " -> exn);";
-
-fun test_struct (ml, _) =
-  ML_Lex.read "functor XXX() = struct structure XX = " @ ml @ ML_Lex.read " end;";
-
-fun test_functor (Antiquote.Text tok :: _, _) =
-      ML_Lex.read "ML_Env.check_functor " @
-      ML_Lex.read (ML_Syntax.print_string (ML_Lex.content_of tok))
-  | test_functor _ = raise Fail "Bad ML functor specification";
-
-val is_name =
-  ML_Lex.kind_of #> (fn kind => kind = ML_Lex.Ident orelse kind = ML_Lex.Long_Ident);
-
-fun is_ml_identifier ants =
-  forall Antiquote.is_text ants andalso
-    (case filter is_name (map (Antiquote.the_text "") ants) of
-      toks as [_] => Symbol_Pos.is_identifier (Long_Name.base_name (ML_Lex.flatten toks))
-    | _ => false);
-
-val parse_ml = Args.text_input -- Scan.optional (Args.colon |-- Args.text_input) Input.empty;
-val parse_type = Args.text_input -- Scan.optional (Args.$$$ "=" |-- Args.text_input) Input.empty;
-val parse_exn = Args.text_input -- Scan.optional (Args.$$$ "of" |-- Args.text_input) Input.empty;
-val parse_struct = Args.text_input >> rpair Input.empty;
-
-fun antiquotation_ml parse test kind show_kind binding index =
-  Document_Output.antiquotation_raw binding (Scan.lift parse)
-    (fn ctxt => fn (source1, source2) =>
-      let
-        val (ml1, ml2) = apply2 ML_Lex.read_source (source1, source2);
-        val pos = Input.pos_of source1;
-        val _ =
-          ML_Context.eval_in (SOME ctxt) ML_Compiler.flags pos (test (ml1, ml2))
-            handle ERROR msg => error (msg ^ Position.here pos);
-
-        val (txt1, txt2) = apply2 (#1 o Input.source_content) (source1, source2);
-        val sep = if kind = "type" then "=" else if kind = "exception" then "of" else ":";
-        val txt =
-          if txt2 = "" then txt1
-          else if sep = ":" andalso is_ml_identifier ml1 then txt1 ^ ": " ^ txt2
-          else txt1 ^ " " ^ sep ^ " " ^ txt2;
-
-        val main_text =
-          Document_Output.verbatim ctxt
-            (if kind = "" orelse not show_kind then txt else kind ^ " " ^ txt);
-
-        val index_text =
-          index |> Option.map (fn def =>
-            let
-              val ctxt' = Config.put Document_Antiquotation.thy_output_display false ctxt;
-              val kind' = if kind = "" then " (ML)" else " (ML " ^ kind ^ ")";
-              val txt' = Latex.block [Document_Output.verbatim ctxt' txt1, Latex.string kind'];
-              val like = Document_Antiquotation.approx_content ctxt source1;
-            in Latex.index_entry {items = [{text = txt', like = like}], def = def} end);
-      in Latex.block (the_list index_text @ [main_text]) end);
-
-fun antiquotation_ml' parse test kind binding =
-  antiquotation_ml parse test kind true binding (SOME true);
-
-in
-
-val _ =
-  Theory.setup
-   (antiquotation_ml' parse_ml test_val "" \<^binding>\<open>define_ML\<close> #>
-    antiquotation_ml' parse_ml test_op "infix" \<^binding>\<open>define_ML_infix\<close> #>
-    antiquotation_ml' parse_type test_type "type" \<^binding>\<open>define_ML_type\<close> #>
-    antiquotation_ml' parse_exn text_exn "exception" \<^binding>\<open>define_ML_exception\<close> #>
-    antiquotation_ml' parse_struct test_struct "structure" \<^binding>\<open>define_ML_structure\<close> #>
-    antiquotation_ml' parse_struct test_functor "functor" \<^binding>\<open>define_ML_functor\<close>);
-
-end;
-
-
 (* named theorems *)
 
 val _ =
   Theory.setup (Document_Output.antiquotation_raw \<^binding>\<open>named_thms\<close>
     (Scan.repeat (Attrib.thm -- Scan.lift (Args.parens Args.name)))
     (fn ctxt =>
       map (fn (thm, name) =>
         Output.output
           (Document_Antiquotation.format ctxt
             (Document_Antiquotation.delimit ctxt (Document_Output.pretty_thm ctxt thm))) ^
         enclose "\\rulename{" "}" (Output.output name))
       #> space_implode "\\par\\smallskip%\n"
       #> Latex.string #> single
       #> Document_Output.isabelle ctxt));
 
 
 (* Isabelle/Isar entities (with index) *)
 
 local
 
 fun no_check (_: Proof.context) (name, _: Position.T) = name;
 
 fun check_keyword ctxt (name, pos) =
   if Keyword.is_keyword (Thy_Header.get_keywords' ctxt) name then name
   else error ("Bad outer syntax keyword " ^ quote name ^ Position.here pos);
 
 fun check_system_option ctxt arg =
   (Completion.check_option (Options.default ()) ctxt arg; true)
     handle ERROR _ => false;
 
 val arg = enclose "{" "}" o clean_string;
 
 fun entity check markup binding index =
   Document_Output.antiquotation_raw
     (binding |> Binding.map_name (fn name => name ^
       (case index of NONE => "" | SOME true => "_def" | SOME false => "_ref")))
     (Scan.lift (Scan.optional (Args.parens Args.name) "" -- Args.name_position))
     (fn ctxt => fn (logic, (name, pos)) =>
       let
         val kind = translate (fn "_" => " " | c => c) (Binding.name_of binding);
         val hyper_name =
           "{" ^ Long_Name.append kind (Long_Name.append logic (clean_name name)) ^ "}";
         val hyper =
           enclose ("\\hyperlink" ^ hyper_name ^ "{") "}" #>
           index = SOME true ? enclose ("\\hypertarget" ^ hyper_name ^ "{") "}";
         val idx =
           (case index of
             NONE => ""
           | SOME is_def =>
               "\\index" ^ (if is_def then "def" else "ref") ^ arg logic ^ arg kind ^ arg name);
         val _ =
           if Context_Position.is_reported ctxt pos then ignore (check ctxt (name, pos)) else ();
         val latex =
           idx ^
           (Output.output name
             |> (if markup = "" then I else enclose ("\\" ^ markup ^ "{") "}")
             |> hyper o enclose "\\mbox{\\isa{" "}}");
       in Latex.string latex end);
 
 fun entity_antiqs check markup kind =
   entity check markup kind NONE #>
   entity check markup kind (SOME true) #>
   entity check markup kind (SOME false);
 
 in
 
 val _ =
   Theory.setup
    (entity_antiqs no_check "" \<^binding>\<open>syntax\<close> #>
     entity_antiqs Outer_Syntax.check_command "isacommand" \<^binding>\<open>command\<close> #>
     entity_antiqs check_keyword "isakeyword" \<^binding>\<open>keyword\<close> #>
     entity_antiqs check_keyword "isakeyword" \<^binding>\<open>element\<close> #>
     entity_antiqs Method.check_name "" \<^binding>\<open>method\<close> #>
     entity_antiqs Attrib.check_name "" \<^binding>\<open>attribute\<close> #>
     entity_antiqs no_check "" \<^binding>\<open>fact\<close> #>
     entity_antiqs no_check "" \<^binding>\<open>variable\<close> #>
     entity_antiqs no_check "" \<^binding>\<open>case\<close> #>
     entity_antiqs Document_Antiquotation.check "" \<^binding>\<open>antiquotation\<close> #>
     entity_antiqs Document_Antiquotation.check_option "" \<^binding>\<open>antiquotation_option\<close> #>
     entity_antiqs Document_Marker.check "" \<^binding>\<open>document_marker\<close> #>
     entity_antiqs no_check "isasystem" \<^binding>\<open>setting\<close> #>
     entity_antiqs check_system_option "isasystem" \<^binding>\<open>system_option\<close> #>
     entity_antiqs no_check "" \<^binding>\<open>inference\<close> #>
     entity_antiqs no_check "isasystem" \<^binding>\<open>executable\<close> #>
     entity_antiqs Isabelle_Tool.check "isatool" \<^binding>\<open>tool\<close> #>
     entity_antiqs ML_Context.check_antiquotation "" \<^binding>\<open>ML_antiquotation\<close> #>
     entity_antiqs (K JEdit.check_action) "isasystem" \<^binding>\<open>action\<close>);
 
 end;
 
 
 (* show symbols *)
 
 val _ =
   Theory.setup (Document_Output.antiquotation_raw \<^binding>\<open>show_symbols\<close> (Scan.succeed ())
     (fn _ => fn _ =>
       let
         val symbol_name =
           unprefix "\\newcommand{\\isasym"
           #> raw_explode
           #> take_prefix Symbol.is_ascii_letter
           #> implode;
 
         val symbols =
           File.read \<^file>\<open>~~/lib/texinputs/isabellesym.sty\<close>
           |> split_lines
           |> map_filter (fn line =>
             (case try symbol_name line of
               NONE => NONE
             | SOME "" => NONE
             | SOME name => SOME ("\\verb,\\" ^ "<" ^ name ^ ">, & {\\isasym" ^ name ^ "}")));
 
         val eol = "\\\\\n";
         fun table (a :: b :: rest) = a ^ " & " ^ b ^ eol :: table rest
           | table [a] = [a ^ eol]
           | table [] = [];
       in
         Latex.string
           ("\\begin{supertabular}{ll@{\\qquad}ll}\n" ^ implode (table symbols) ^
            "\\end{supertabular}\n")
       end))
 
 end;
diff --git a/src/Pure/Thy/document_antiquotations.ML b/src/Pure/Thy/document_antiquotations.ML
--- a/src/Pure/Thy/document_antiquotations.ML
+++ b/src/Pure/Thy/document_antiquotations.ML
@@ -1,370 +1,437 @@
 (*  Title:      Pure/Thy/document_antiquotations.ML
     Author:     Makarius
 
 Miscellaneous document antiquotations.
 *)
 
 structure Document_Antiquotations: sig end =
 struct
 
 (* basic entities *)
 
 local
 
 type style = term -> term;
 
 fun pretty_term_style ctxt (style: style, t) =
   Document_Output.pretty_term ctxt (style t);
 
 fun pretty_thms_style ctxt (style: style, ths) =
   map (fn th => Document_Output.pretty_term ctxt (style (Thm.full_prop_of th))) ths;
 
 fun pretty_term_typ ctxt (style: style, t) =
   let val t' = style t
   in Document_Output.pretty_term ctxt (Type.constraint (Term.fastype_of t') t') end;
 
 fun pretty_term_typeof ctxt (style: style, t) =
   Syntax.pretty_typ ctxt (Term.fastype_of (style t));
 
 fun pretty_const ctxt c =
   let
     val t = Const (c, Consts.type_scheme (Proof_Context.consts_of ctxt) c)
       handle TYPE (msg, _, _) => error msg;
     val (t', _) = yield_singleton (Variable.import_terms true) t ctxt;
   in Document_Output.pretty_term ctxt t' end;
 
 fun pretty_abbrev ctxt s =
   let
     val t = Syntax.read_term (Proof_Context.set_mode Proof_Context.mode_abbrev ctxt) s;
     fun err () = error ("Abbreviated constant expected: " ^ Syntax.string_of_term ctxt t);
     val (head, args) = Term.strip_comb t;
     val (c, T) = Term.dest_Const head handle TERM _ => err ();
     val (U, u) = Consts.the_abbreviation (Proof_Context.consts_of ctxt) c
       handle TYPE _ => err ();
     val t' = Term.betapplys (Envir.expand_atom T (U, u), args);
     val eq = Logic.mk_equals (t, t');
     val ctxt' = Proof_Context.augment eq ctxt;
   in Proof_Context.pretty_term_abbrev ctxt' eq end;
 
 fun pretty_locale ctxt (name, pos) =
   let val thy = Proof_Context.theory_of ctxt
   in Pretty.str (Locale.extern thy (Locale.check thy (name, pos))) end;
 
 fun pretty_class ctxt s =
   Pretty.str (Proof_Context.extern_class ctxt (Proof_Context.read_class ctxt s));
 
 fun pretty_type ctxt s =
   let val Type (name, _) = Proof_Context.read_type_name {proper = true, strict = false} ctxt s
   in Pretty.str (Proof_Context.extern_type ctxt name) end;
 
 fun pretty_prf full ctxt = Proof_Syntax.pretty_standard_proof_of ctxt full;
 
 fun pretty_theory ctxt (name, pos) =
   (Theory.check {long = true} ctxt (name, pos); Pretty.str name);
 
 val basic_entity = Document_Output.antiquotation_pretty_source_embedded;
 
 fun basic_entities name scan pretty =
   Document_Antiquotation.setup name scan
     (fn {context = ctxt, source = src, argument = xs} =>
       Document_Output.pretty_items_source ctxt {embedded = false} src (map (pretty ctxt) xs));
 
 val _ = Theory.setup
  (basic_entity \<^binding>\<open>prop\<close> (Term_Style.parse -- Args.prop) pretty_term_style #>
   basic_entity \<^binding>\<open>term\<close> (Term_Style.parse -- Args.term) pretty_term_style #>
   basic_entity \<^binding>\<open>term_type\<close> (Term_Style.parse -- Args.term) pretty_term_typ #>
   basic_entity \<^binding>\<open>typeof\<close> (Term_Style.parse -- Args.term) pretty_term_typeof #>
   basic_entity \<^binding>\<open>const\<close> (Args.const {proper = true, strict = false}) pretty_const #>
   basic_entity \<^binding>\<open>abbrev\<close> (Scan.lift Args.embedded_inner_syntax) pretty_abbrev #>
   basic_entity \<^binding>\<open>typ\<close> Args.typ_abbrev Syntax.pretty_typ #>
   basic_entity \<^binding>\<open>locale\<close> (Scan.lift Args.embedded_position) pretty_locale #>
   basic_entity \<^binding>\<open>class\<close> (Scan.lift Args.embedded_inner_syntax) pretty_class #>
   basic_entity \<^binding>\<open>type\<close> (Scan.lift Args.embedded_inner_syntax) pretty_type #>
   basic_entity \<^binding>\<open>theory\<close> (Scan.lift Args.embedded_position) pretty_theory #>
   basic_entities \<^binding>\<open>prf\<close> Attrib.thms (pretty_prf false) #>
   basic_entities \<^binding>\<open>full_prf\<close> Attrib.thms (pretty_prf true) #>
   Document_Antiquotation.setup \<^binding>\<open>thm\<close> (Term_Style.parse -- Attrib.thms)
     (fn {context = ctxt, source = src, argument = arg} =>
       Document_Output.pretty_items_source ctxt {embedded = false} src (pretty_thms_style ctxt arg)));
 
 in end;
 
 
 (* Markdown errors *)
 
 local
 
 fun markdown_error binding =
   Document_Antiquotation.setup binding (Scan.succeed ())
     (fn {source = src, ...} =>
       error ("Bad Markdown structure: illegal " ^ quote (Binding.name_of binding) ^
         Position.here (Position.no_range_position (#1 (Token.range_of src)))))
 
 val _ =
   Theory.setup
    (markdown_error \<^binding>\<open>item\<close> #>
     markdown_error \<^binding>\<open>enum\<close> #>
     markdown_error \<^binding>\<open>descr\<close>);
 
 in end;
 
 
 (* control spacing *)
 
 val _ =
   Theory.setup
    (Document_Output.antiquotation_raw \<^binding>\<open>noindent\<close> (Scan.succeed ())
       (fn _ => fn () => Latex.string "\\noindent") #>
     Document_Output.antiquotation_raw \<^binding>\<open>smallskip\<close> (Scan.succeed ())
       (fn _ => fn () => Latex.string "\\smallskip") #>
     Document_Output.antiquotation_raw \<^binding>\<open>medskip\<close> (Scan.succeed ())
       (fn _ => fn () => Latex.string "\\medskip") #>
     Document_Output.antiquotation_raw \<^binding>\<open>bigskip\<close> (Scan.succeed ())
       (fn _ => fn () => Latex.string "\\bigskip"));
 
 
 (* nested document text *)
 
 local
 
 fun nested_antiquotation name s1 s2 =
   Document_Output.antiquotation_raw_embedded name (Scan.lift Args.cartouche_input)
     (fn ctxt => fn txt =>
       (Context_Position.reports ctxt (Document_Output.document_reports txt);
         Latex.enclose_block s1 s2 (Document_Output.output_document ctxt {markdown = false} txt)));
 
 val _ =
   Theory.setup
    (nested_antiquotation \<^binding>\<open>footnote\<close> "\\footnote{" "}" #>
     nested_antiquotation \<^binding>\<open>emph\<close> "\\emph{" "}" #>
     nested_antiquotation \<^binding>\<open>bold\<close> "\\textbf{" "}");
 
 in end;
 
 
 (* index entries *)
 
 local
 
 val index_like = Parse.$$$ "(" |-- Parse.!!! (Parse.$$$ "is" |-- Args.name --| Parse.$$$ ")");
 val index_args = Parse.enum1 "!" (Args.embedded_input -- Scan.option index_like);
 
 fun output_text ctxt = Latex.block o Document_Output.output_document ctxt {markdown = false};
 
 fun index binding def =
   Document_Output.antiquotation_raw binding (Scan.lift index_args)
     (fn ctxt => fn args =>
       let
         val _ = Context_Position.reports ctxt (maps (Document_Output.document_reports o #1) args);
         fun make_item (txt, opt_like) =
           let
             val text = output_text ctxt txt;
             val like =
               (case opt_like of
                 SOME s => s
               | NONE => Document_Antiquotation.approx_content ctxt txt);
             val _ =
               if is_none opt_like andalso Context_Position.is_visible ctxt then
                 writeln ("(" ^ Markup.markup Markup.keyword2 "is" ^ " " ^ quote like ^ ")" ^
                   Position.here (Input.pos_of txt))
               else ();
           in {text = text, like = like} end;
       in Latex.index_entry {items = map make_item args, def = def} end);
 
 val _ = Theory.setup (index \<^binding>\<open>index_ref\<close> false #> index \<^binding>\<open>index_def\<close> true);
 
 in end;
 
 
 (* quasi-formal text (unchecked) *)
 
 local
 
 fun report_text ctxt text =
   let val pos = Input.pos_of text in
     Context_Position.reports ctxt
       [(pos, Markup.language_text (Input.is_delimited text)),
        (pos, Markup.raw_text)]
   end;
 
 fun prepare_text ctxt =
   Input.source_content #> #1 #> Document_Antiquotation.prepare_lines ctxt;
 
 fun text_antiquotation name =
   Document_Output.antiquotation_raw_embedded name (Scan.lift Args.text_input)
     (fn ctxt => fn text =>
       let
         val _ = report_text ctxt text;
       in
         prepare_text ctxt text
         |> Document_Output.output_source ctxt
         |> Document_Output.isabelle ctxt
       end);
 
 val theory_text_antiquotation =
   Document_Output.antiquotation_raw_embedded \<^binding>\<open>theory_text\<close> (Scan.lift Args.text_input)
     (fn ctxt => fn text =>
       let
         val keywords = Thy_Header.get_keywords' ctxt;
 
         val _ = report_text ctxt text;
         val _ =
           Input.source_explode text
           |> Token.tokenize keywords {strict = true}
           |> maps (Token.reports keywords)
           |> Context_Position.reports_text ctxt;
       in
         prepare_text ctxt text
         |> Token.explode0 keywords
         |> maps (Document_Output.output_token ctxt)
         |> Document_Output.isabelle ctxt
       end);
 
 val _ =
   Theory.setup
    (text_antiquotation \<^binding>\<open>text\<close> #>
     text_antiquotation \<^binding>\<open>cartouche\<close> #>
     theory_text_antiquotation);
 
 in end;
 
 
 (* goal state *)
 
 local
 
 fun goal_state name main =
   Document_Output.antiquotation_pretty name (Scan.succeed ())
     (fn ctxt => fn () =>
       Goal_Display.pretty_goal
         (Config.put Goal_Display.show_main_goal main ctxt)
         (#goal (Proof.goal (Toplevel.proof_of (Toplevel.presentation_state ctxt)))));
 
 val _ = Theory.setup
  (goal_state \<^binding>\<open>goals\<close> true #>
   goal_state \<^binding>\<open>subgoals\<close> false);
 
 in end;
 
 
 (* embedded lemma *)
 
 val _ = Theory.setup
   (Document_Antiquotation.setup \<^binding>\<open>lemma\<close>
     (Scan.lift (Scan.ahead Parse.not_eof) -- Args.prop --
       Scan.lift (Parse.position (Parse.reserved "by") -- Method.parse -- Scan.option Method.parse))
     (fn {context = ctxt, source = src, argument = ((prop_tok, prop), (((_, by_pos), m1), m2))} =>
       let
         val reports =
           (by_pos, Markup.keyword1 |> Markup.keyword_properties) ::
             maps Method.reports_of (m1 :: the_list m2);
         val _ = Context_Position.reports ctxt reports;
 
         (* FIXME check proof!? *)
         val _ = ctxt
           |> Proof.theorem NONE (K I) [[(prop, [])]]
           |> Proof.global_terminal_proof (m1, m2);
       in
         Document_Output.pretty_source ctxt {embedded = false}
           [hd src, prop_tok] (Document_Output.pretty_term ctxt prop)
       end));
 
 
 (* verbatim text *)
 
 val _ = Theory.setup
   (Document_Output.antiquotation_verbatim_embedded \<^binding>\<open>verbatim\<close> (Scan.lift Args.text_input)
     (fn ctxt => fn text =>
       let
         val pos = Input.pos_of text;
         val _ =
           Context_Position.reports ctxt
             [(pos, Markup.language_verbatim (Input.is_delimited text)),
              (pos, Markup.raw_text)];
       in #1 (Input.source_content text) end));
 
 
 (* bash functions *)
 
 val _ = Theory.setup
   (Document_Output.antiquotation_verbatim_embedded \<^binding>\<open>bash_function\<close>
     (Scan.lift Args.embedded_position) Isabelle_System.check_bash_function);
 
 
 (* system options *)
 
 val _ = Theory.setup
   (Document_Output.antiquotation_verbatim_embedded \<^binding>\<open>system_option\<close>
     (Scan.lift Args.embedded_position)
     (fn ctxt => fn (name, pos) =>
       let val _ = Completion.check_option (Options.default ()) ctxt (name, pos);
       in name end));
 
 
 (* ML text *)
 
 local
 
-fun ml_text name ml =
-  Document_Output.antiquotation_verbatim_embedded name (Scan.lift Args.text_input)
-    (fn ctxt => fn text =>
-      let val _ = ML_Context.eval_in (SOME ctxt) ML_Compiler.flags (Input.pos_of text) (ml text)
-      in #1 (Input.source_content text) end);
-
-fun ml_enclose bg en source =
-  ML_Lex.read bg @ ML_Lex.read_source source @ ML_Lex.read en;
+fun test_val (ml1, []) = ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read ");"
+  | test_val (ml1, ml2) = ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read " : " @ ml2 @ ML_Lex.read ");";
 
-val _ = Theory.setup
- (ml_text \<^binding>\<open>ML\<close> (ml_enclose "fn _ => (" ");") #>
-  ml_text \<^binding>\<open>ML_op\<close> (ml_enclose "fn _ => (op " ");") #>
-  ml_text \<^binding>\<open>ML_type\<close> (ml_enclose "val _ = NONE : (" ") option;") #>
-  ml_text \<^binding>\<open>ML_structure\<close>
-    (ml_enclose "functor XXX() = struct structure XX = " " end;") #>
+fun test_op (ml1, ml2) = test_val (ML_Lex.read "op " @ ml1, ml2);
 
-  ml_text \<^binding>\<open>ML_functor\<close>   (* FIXME formal treatment of functor name (!?) *)
-    (fn source =>
-      ML_Lex.read ("ML_Env.check_functor " ^
-        ML_Syntax.print_string (#1 (Input.source_content source)))) #>
+fun test_type (ml1, []) = ML_Lex.read "val _ = NONE : (" @ ml1 @ ML_Lex.read ") option;"
+  | test_type (ml1, ml2) =
+      ML_Lex.read "val _ = [NONE : (" @ ml1 @ ML_Lex.read ") option, NONE : (" @
+      ml2 @ ML_Lex.read ") option];";
 
-  ml_text \<^binding>\<open>ML_text\<close> (K []));
+fun test_exn (ml1, []) = ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read " : exn);"
+  | test_exn (ml1, ml2) =
+      ML_Lex.read "fn _ => (" @ ml1 @ ML_Lex.read " : " @ ml2 @ ML_Lex.read " -> exn);";
 
-in end;
+fun test_struct (ml, _) =
+  ML_Lex.read "functor XXX() = struct structure XX = " @ ml @ ML_Lex.read " end;";
+
+fun test_functor (Antiquote.Text tok :: _, _) =
+      ML_Lex.read "ML_Env.check_functor " @
+      ML_Lex.read (ML_Syntax.print_string (ML_Lex.content_of tok))
+  | test_functor _ = raise Fail "Bad ML functor specification";
+
+val is_name =
+  ML_Lex.kind_of #> (fn kind => kind = ML_Lex.Ident orelse kind = ML_Lex.Long_Ident);
+
+fun is_ml_identifier ants =
+  forall Antiquote.is_text ants andalso
+    (case filter is_name (map (Antiquote.the_text "") ants) of
+      toks as [_] => Symbol_Pos.is_identifier (Long_Name.base_name (ML_Lex.flatten toks))
+    | _ => false);
+
+val parse_ml0 = Args.text_input >> rpair Input.empty;
+val parse_ml = Args.text_input -- Scan.optional (Args.colon |-- Args.text_input) Input.empty;
+val parse_type = Args.text_input -- Scan.optional (Args.$$$ "=" |-- Args.text_input) Input.empty;
+val parse_exn = Args.text_input -- Scan.optional (Args.$$$ "of" |-- Args.text_input) Input.empty;
+
+fun antiquotation_ml parse test kind show_kind binding index =
+  Document_Output.antiquotation_raw binding (Scan.lift parse)
+    (fn ctxt => fn (source1, source2) =>
+      let
+        val (ml1, ml2) = apply2 ML_Lex.read_source (source1, source2);
+        val pos = Input.pos_of source1;
+        val _ =
+          ML_Context.eval_in (SOME ctxt) ML_Compiler.flags pos (test (ml1, ml2))
+            handle ERROR msg => error (msg ^ Position.here pos);
+
+        val (txt1, txt2) = apply2 (#1 o Input.source_content) (source1, source2);
+        val sep = if kind = "type" then "=" else if kind = "exception" then "of" else ":";
+        val txt =
+          if txt2 = "" then txt1
+          else if sep = ":" andalso is_ml_identifier ml1 then txt1 ^ ": " ^ txt2
+          else txt1 ^ " " ^ sep ^ " " ^ txt2;
+
+        val main_text =
+          Document_Output.verbatim ctxt
+            (if kind = "" orelse not show_kind then txt else kind ^ " " ^ txt);
+
+        val index_text =
+          index |> Option.map (fn def =>
+            let
+              val ctxt' = Config.put Document_Antiquotation.thy_output_display false ctxt;
+              val kind' = if kind = "" then " (ML)" else " (ML " ^ kind ^ ")";
+              val txt' = Latex.block [Document_Output.verbatim ctxt' txt1, Latex.string kind'];
+              val like = Document_Antiquotation.approx_content ctxt source1;
+            in Latex.index_entry {items = [{text = txt', like = like}], def = def} end);
+      in Latex.block (the_list index_text @ [main_text]) end);
+
+fun antiquotation_ml0 test kind =
+  antiquotation_ml parse_ml0 test kind false;
+
+fun antiquotation_ml1 parse test kind binding =
+  antiquotation_ml parse test kind true binding (SOME true);
+
+in
+
+val _ =
+  Theory.setup
+   (Latex.index_variants (antiquotation_ml0 test_val "") \<^binding>\<open>ML\<close> #>
+    Latex.index_variants (antiquotation_ml0 test_op "infix") \<^binding>\<open>ML_infix\<close> #>
+    Latex.index_variants (antiquotation_ml0 test_type "type") \<^binding>\<open>ML_type\<close> #>
+    Latex.index_variants (antiquotation_ml0 test_struct "structure") \<^binding>\<open>ML_structure\<close> #>
+    Latex.index_variants (antiquotation_ml0 test_functor "functor") \<^binding>\<open>ML_functor\<close> #>
+    antiquotation_ml0 (K []) "text" \<^binding>\<open>ML_text\<close> NONE #>
+    antiquotation_ml1 parse_ml test_val "" \<^binding>\<open>define_ML\<close> #>
+    antiquotation_ml1 parse_ml test_op "infix" \<^binding>\<open>define_ML_infix\<close> #>
+    antiquotation_ml1 parse_type test_type "type" \<^binding>\<open>define_ML_type\<close> #>
+    antiquotation_ml1 parse_exn test_exn "exception" \<^binding>\<open>define_ML_exception\<close> #>
+    antiquotation_ml1 parse_ml0 test_struct "structure" \<^binding>\<open>define_ML_structure\<close> #>
+    antiquotation_ml1 parse_ml0 test_functor "functor" \<^binding>\<open>define_ML_functor\<close>);
+
+end;
 
 
 (* URLs *)
 
 val escape_url =
   translate_string (fn c => if c = "%" orelse c = "#" orelse c = "^" then "\\" ^ c else c);
 
 val _ = Theory.setup
   (Document_Output.antiquotation_raw_embedded \<^binding>\<open>url\<close> (Scan.lift Args.embedded_input)
     (fn ctxt => fn source =>
       let
         val url = Input.string_of source;
         val pos = Input.pos_of source;
         val delimited = Input.is_delimited source;
         val _ =
           Context_Position.reports ctxt
             [(pos, Markup.language_url delimited), (pos, Markup.url url)];
       in Latex.enclose_block "\\url{" "}" [Latex.string (escape_url url)] end));
 
 
 (* formal entities *)
 
 local
 
 fun entity_antiquotation name check bg en =
   Document_Output.antiquotation_raw name (Scan.lift Args.name_position)
     (fn ctxt => fn (name, pos) =>
       let val _ = check ctxt (name, pos)
       in Latex.enclose_block bg en [Latex.string (Output.output name)] end);
 
 val _ =
   Theory.setup
    (entity_antiquotation \<^binding>\<open>command\<close> Outer_Syntax.check_command "\\isacommand{" "}" #>
     entity_antiquotation \<^binding>\<open>method\<close> Method.check_name "\\isa{" "}" #>
     entity_antiquotation \<^binding>\<open>attribute\<close> Attrib.check_name "\\isa{" "}");
 
 in end;
 
 end;