diff --git a/src/Doc/Implementation/Local_Theory.thy b/src/Doc/Implementation/Local_Theory.thy
--- a/src/Doc/Implementation/Local_Theory.thy
+++ b/src/Doc/Implementation/Local_Theory.thy
@@ -1,149 +1,149 @@
 (*:maxLineLen=78:*)
 
 theory Local_Theory
 imports Base
 begin
 
 chapter \<open>Local theory specifications \label{ch:local-theory}\<close>
 
 text \<open>
   A \<^emph>\<open>local theory\<close> combines aspects of both theory and proof context (cf.\
   \secref{sec:context}), such that definitional specifications may be given
   relatively to parameters and assumptions. A local theory is represented as a
   regular proof context, augmented by administrative data about the \<^emph>\<open>target
   context\<close>.
 
   The target is usually derived from the background theory by adding local
   \<open>\<FIX>\<close> and \<open>\<ASSUME>\<close> elements, plus suitable modifications of
   non-logical context data (e.g.\ a special type-checking discipline). Once
   initialized, the target is ready to absorb definitional primitives:
   \<open>\<DEFINE>\<close> for terms and \<open>\<NOTE>\<close> for theorems. Such definitions may get
   transformed in a target-specific way, but the programming interface hides
   such details.
 
   Isabelle/Pure provides target mechanisms for locales, type-classes,
   type-class instantiations, and general overloading. In principle, users can
   implement new targets as well, but this rather arcane discipline is beyond
   the scope of this manual. In contrast, implementing derived definitional
   packages to be used within a local theory context is quite easy: the
   interfaces are even simpler and more abstract than the underlying primitives
   for raw theories.
 
   Many definitional packages for local theories are available in Isabelle.
   Although a few old packages only work for global theories, the standard way
   of implementing definitional packages in Isabelle is via the local theory
   interface.
 \<close>
 
 
 section \<open>Definitional elements\<close>
 
 text \<open>
   There are separate elements \<open>\<DEFINE> c \<equiv> t\<close> for terms, and \<open>\<NOTE> b =
   thm\<close> for theorems. Types are treated implicitly, according to Hindley-Milner
   discipline (cf.\ \secref{sec:variables}). These definitional primitives
   essentially act like \<open>let\<close>-bindings within a local context that may already
   contain earlier \<open>let\<close>-bindings and some initial \<open>\<lambda>\<close>-bindings. Thus we gain
   \<^emph>\<open>dependent definitions\<close> that are relative to an initial axiomatic context.
   The following diagram illustrates this idea of axiomatic elements versus
   definitional elements:
 
   \begin{center}
   \begin{tabular}{|l|l|l|}
   \hline
   & \<open>\<lambda>\<close>-binding & \<open>let\<close>-binding \\
   \hline
   types & fixed \<open>\<alpha>\<close> & arbitrary \<open>\<beta>\<close> \\
   terms & \<open>\<FIX> x :: \<tau>\<close> & \<open>\<DEFINE> c \<equiv> t\<close> \\
   theorems & \<open>\<ASSUME> a: A\<close> & \<open>\<NOTE> b = \<^BG>B\<^EN>\<close> \\
   \hline
   \end{tabular}
   \end{center}
 
   A user package merely needs to produce suitable \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close>
   elements according to the application. For example, a package for inductive
   definitions might first \<open>\<DEFINE>\<close> a certain predicate as some fixed-point
   construction, then \<open>\<NOTE>\<close> a proven result about monotonicity of the
   functor involved here, and then produce further derived concepts via
   additional \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close> elements.
 
   The cumulative sequence of \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close> produced at package
   runtime is managed by the local theory infrastructure by means of an
   \<^emph>\<open>auxiliary context\<close>. Thus the system holds up the impression of working
   within a fully abstract situation with hypothetical entities: \<open>\<DEFINE> c \<equiv>
   t\<close> always results in a literal fact \<open>\<^BG>c \<equiv> t\<^EN>\<close>, where \<open>c\<close> is a
   fixed variable \<open>c\<close>. The details about global constants, name spaces etc. are
   handled internally.
 
   So the general structure of a local theory is a sandwich of three layers:
 
   \begin{center}
   \framebox{\quad auxiliary context \quad\framebox{\quad target context \quad\framebox{\quad background theory\quad}}}
   \end{center}
 
   When a definitional package is finished, the auxiliary context is reset to
   the target context. The target now holds definitions for terms and theorems
   that stem from the hypothetical \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close> elements,
   transformed by the particular target policy (see @{cite \<open>\S4--5\<close>
   "Haftmann-Wenzel:2009"} for details).
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
-  @{index_ML_type local_theory: Proof.context} \\
+  @{index_ML_type local_theory = Proof.context} \\
   @{index_ML Named_Target.init: "string list -> string -> theory -> local_theory"} \\[1ex]
   @{index_ML Local_Theory.define: "(binding * mixfix) * (Attrib.binding * term) ->
     local_theory -> (term * (string * thm)) * local_theory"} \\
   @{index_ML Local_Theory.note: "Attrib.binding * thm list ->
     local_theory -> (string * thm list) * local_theory"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>local_theory\<close> represents local theories. Although this is
   merely an alias for \<^ML_type>\<open>Proof.context\<close>, it is semantically a subtype
   of the same: a \<^ML_type>\<open>local_theory\<close> holds target information as special
   context data. Subtyping means that any value \<open>lthy:\<close>~\<^ML_type>\<open>local_theory\<close>
   can be also used with operations on expecting a regular \<open>ctxt:\<close>~\<^ML_type>\<open>Proof.context\<close>.
 
   \<^descr> \<^ML>\<open>Named_Target.init\<close>~\<open>includes name thy\<close> initializes a local theory
   derived from the given background theory. An empty name refers to a \<^emph>\<open>global
   theory\<close> context, and a non-empty name refers to a @{command locale} or
   @{command class} context (a fully-qualified internal name is expected here).
   This is useful for experimentation --- normally the Isar toplevel already
   takes care to initialize the local theory context.
 
   \<^descr> \<^ML>\<open>Local_Theory.define\<close>~\<open>((b, mx), (a, rhs)) lthy\<close> defines a local
   entity according to the specification that is given relatively to the
   current \<open>lthy\<close> context. In particular the term of the RHS may refer to
   earlier local entities from the auxiliary context, or hypothetical
   parameters from the target context. The result is the newly defined term
   (which is always a fixed variable with exactly the same name as specified
   for the LHS), together with an equational theorem that states the definition
   as a hypothetical fact.
 
   Unless an explicit name binding is given for the RHS, the resulting fact
   will be called \<open>b_def\<close>. Any given attributes are applied to that same fact
   --- immediately in the auxiliary context \<^emph>\<open>and\<close> in any transformed versions
   stemming from target-specific policies or any later interpretations of
   results from the target context (think of @{command locale} and @{command
   interpretation}, for example). This means that attributes should be usually
   plain declarations such as @{attribute simp}, while non-trivial rules like
   @{attribute simplified} are better avoided.
 
   \<^descr> \<^ML>\<open>Local_Theory.note\<close>~\<open>(a, ths) lthy\<close> is analogous to \<^ML>\<open>Local_Theory.define\<close>, but defines facts instead of terms. There is also a
   slightly more general variant \<^ML>\<open>Local_Theory.notes\<close> that defines several
   facts (with attribute expressions) simultaneously.
 
   This is essentially the internal version of the @{command lemmas} command,
   or @{command declare} if an empty name binding is given.
 \<close>
 
 
 section \<open>Morphisms and declarations \label{sec:morphisms}\<close>
 
 text \<open>
   %FIXME
 
   See also @{cite "Chaieb-Wenzel:2007"}.
 \<close>
 
 end
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}
-  @{index_ML_type class: string} \\
-  @{index_ML_type sort: "class list"} \\
-  @{index_ML_type arity: "string * sort list * sort"} \\
+  @{index_ML_type class = string} \\
+  @{index_ML_type sort = "class list"} \\
+  @{index_ML_type arity = "string * sort list * sort"} \\
   @{index_ML_type typ} \\
   @{index_ML Term.map_atyps: "(typ -> typ) -> typ -> typ"} \\
   @{index_ML Term.fold_atyps: "(typ -> 'a -> 'a) -> typ -> 'a -> 'a"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML Sign.subsort: "theory -> sort * sort -> bool"} \\
   @{index_ML Sign.of_sort: "theory -> typ * sort -> bool"} \\
   @{index_ML Sign.add_type: "Proof.context -> binding * int * mixfix -> theory -> theory"} \\
   @{index_ML Sign.add_type_abbrev: "Proof.context ->
   binding * string list * typ -> theory -> theory"} \\
   @{index_ML Sign.primitive_class: "binding * class list -> theory -> theory"} \\
   @{index_ML Sign.primitive_classrel: "class * class -> theory -> theory"} \\
   @{index_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}
   @{index_ML_type term} \\
-  @{index_ML_op "aconv": "term * term -> bool"} \\
+  @{index_ML_infix "aconv": "term * term -> bool"} \\
   @{index_ML Term.map_types: "(typ -> typ) -> term -> term"} \\
   @{index_ML Term.fold_types: "(typ -> 'a -> 'a) -> term -> 'a -> 'a"} \\
   @{index_ML Term.map_aterms: "(term -> term) -> term -> term"} \\
   @{index_ML Term.fold_aterms: "(term -> 'a -> 'a) -> term -> 'a -> 'a"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML fastype_of: "term -> typ"} \\
   @{index_ML lambda: "term -> term -> term"} \\
   @{index_ML betapply: "term * term -> term"} \\
   @{index_ML incr_boundvars: "int -> term -> term"} \\
   @{index_ML Sign.declare_const: "Proof.context ->
   (binding * typ) * mixfix -> theory -> term * theory"} \\
   @{index_ML Sign.add_abbrev: "string -> binding * term ->
   theory -> (term * term) * theory"} \\
   @{index_ML Sign.const_typargs: "theory -> string * typ -> typ list"} \\
   @{index_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 @{index_ML Bound}, @{index_ML Free}, @{index_ML
-  Var}, @{index_ML Const}, @{index_ML Abs}, @{index_ML_op "$"}.
+  Var}, @{index_ML Const}, @{index_ML Abs}, @{index_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}
   @{index_ML Logic.all: "term -> term -> term"} \\
   @{index_ML Logic.mk_implies: "term * term -> term"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML_type ctyp} \\
   @{index_ML_type cterm} \\
   @{index_ML Thm.ctyp_of: "Proof.context -> typ -> ctyp"} \\
   @{index_ML Thm.cterm_of: "Proof.context -> term -> cterm"} \\
   @{index_ML Thm.apply: "cterm -> cterm -> cterm"} \\
   @{index_ML Thm.lambda: "cterm -> cterm -> cterm"} \\
   @{index_ML Thm.all: "Proof.context -> cterm -> cterm -> cterm"} \\
   @{index_ML Drule.mk_implies: "cterm * cterm -> cterm"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML_type thm} \\
   @{index_ML Thm.transfer: "theory -> thm -> thm"} \\
   @{index_ML Thm.assume: "cterm -> thm"} \\
   @{index_ML Thm.forall_intr: "cterm -> thm -> thm"} \\
   @{index_ML Thm.forall_elim: "cterm -> thm -> thm"} \\
   @{index_ML Thm.implies_intr: "cterm -> thm -> thm"} \\
   @{index_ML Thm.implies_elim: "thm -> thm -> thm"} \\
   @{index_ML Thm.generalize: "string list * string list -> int -> thm -> thm"} \\
   @{index_ML Thm.instantiate: "((indexname * sort) * ctyp) list * ((indexname * typ) * cterm) list
   -> thm -> thm"} \\
   @{index_ML Thm.add_axiom: "Proof.context ->
   binding * term -> theory -> (string * thm) * theory"} \\
   @{index_ML Thm.add_oracle: "binding * ('a -> cterm) -> theory ->
   (string * ('a -> thm)) * theory"} \\
   @{index_ML Thm.add_def: "Defs.context -> bool -> bool ->
   binding * term -> theory -> (string * thm) * theory"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML Theory.add_deps: "Defs.context -> string ->
   Defs.entry -> Defs.entry list -> theory -> theory"} \\
   @{index_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>,
   \<^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}
   @{index_ML Conjunction.intr: "thm -> thm -> thm"} \\
   @{index_ML Conjunction.elim: "thm -> thm * thm"} \\
   @{index_ML Drule.mk_term: "cterm -> thm"} \\
   @{index_ML Drule.dest_term: "thm -> cterm"} \\
   @{index_ML Logic.mk_type: "typ -> term"} \\
   @{index_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}
   @{index_ML Thm.extra_shyps: "thm -> sort list"} \\
   @{index_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}
   @{index_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}
-  @{index_ML_op "RSN": "thm * (int * thm) -> thm"} \\
-  @{index_ML_op "RS": "thm * thm -> thm"} \\
+  @{index_ML_infix "RSN": "thm * (int * thm) -> thm"} \\
+  @{index_ML_infix "RS": "thm * thm -> thm"} \\
 
-  @{index_ML_op "RLN": "thm list * (int * thm list) -> thm list"} \\
-  @{index_ML_op "RL": "thm list * thm list -> thm list"} \\
+  @{index_ML_infix "RLN": "thm list * (int * thm list) -> thm list"} \\
+  @{index_ML_infix "RL": "thm list * thm list -> thm list"} \\
 
-  @{index_ML_op "MRS": "thm list * thm -> thm"} \\
-  @{index_ML_op "OF": "thm * thm list -> thm"} \\
+  @{index_ML_infix "MRS": "thm list * thm -> thm"} \\
+  @{index_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}
   @{index_ML_type proof} \\
   @{index_ML_type proof_body} \\
   @{index_ML Proofterm.proofs: "int Unsynchronized.ref"} \\
   @{index_ML Proofterm.reconstruct_proof:
   "theory -> term -> proof -> proof"} \\
   @{index_ML Proofterm.expand_proof: "theory ->
   (Proofterm.thm_header -> string option) -> proof -> proof"} \\
   @{index_ML Proof_Checker.thm_of_proof: "theory -> proof -> thm"} \\
   @{index_ML Proof_Syntax.read_proof: "theory -> bool -> bool -> string -> proof"} \\
   @{index_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 @{index_ML Abst}, @{index_ML AbsP}, @{index_ML_op "%"},
-  @{index_ML_op "%%"}, @{index_ML PBound}, @{index_ML MinProof}, @{index_ML
+  constructors @{index_ML Abst}, @{index_ML AbsP}, @{index_ML_infix "%"},
+  @{index_ML_infix "%%"}, @{index_ML PBound}, @{index_ML MinProof}, @{index_ML
   Hyp}, @{index_ML PAxm}, @{index_ML Oracle}, @{index_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}
   @{index_ML Context.the_generic_context: "unit -> Context.generic"} \\
   @{index_ML "Context.>>": "(Context.generic -> Context.generic) -> unit"} \\
   @{index_ML ML_Thms.bind_thms: "string * thm list -> unit"} \\
   @{index_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}
-  @{index_ML_op "|> ": "'a * ('a -> 'b) -> 'b"} \\
-  @{index_ML_op "|-> ": "('c * 'a) * ('c -> 'a -> 'b) -> 'b"} \\
-  @{index_ML_op "#> ": "('a -> 'b) * ('b -> 'c) -> 'a -> 'c"} \\
-  @{index_ML_op "#-> ": "('a -> 'c * 'b) * ('c -> 'b -> 'd) -> 'a -> 'd"} \\
+  @{index_ML_infix "|>" : "'a * ('a -> 'b) -> 'b"} \\
+  @{index_ML_infix "|->" : "('c * 'a) * ('c -> 'a -> 'b) -> 'b"} \\
+  @{index_ML_infix "#>" : "('a -> 'b) * ('b -> 'c) -> 'a -> 'c"} \\
+  @{index_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}
   @{index_ML fold: "('a -> 'b -> 'b) -> 'a list -> 'b -> 'b"} \\
   @{index_ML fold_rev: "('a -> 'b -> 'b) -> 'a list -> 'b -> 'b"} \\
   @{index_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}
   @{index_ML writeln: "string -> unit"} \\
   @{index_ML tracing: "string -> unit"} \\
   @{index_ML warning: "string -> unit"} \\
   @{index_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}
   @{index_ML try: "('a -> 'b) -> 'a -> 'b option"} \\
   @{index_ML can: "('a -> 'b) -> 'a -> bool"} \\
-  @{index_ML_exception ERROR: string} \\
-  @{index_ML_exception Fail: string} \\
+  @{index_ML_exception ERROR of string} \\
+  @{index_ML_exception Fail of string} \\
   @{index_ML Exn.is_interrupt: "exn -> bool"} \\
   @{index_ML Exn.reraise: "exn -> 'a"} \\
   @{index_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}
-  @{index_ML_type "Symbol.symbol": string} \\
+  @{index_ML_type Symbol.symbol = string} \\
   @{index_ML Symbol.explode: "string -> Symbol.symbol list"} \\
   @{index_ML Symbol.is_letter: "Symbol.symbol -> bool"} \\
   @{index_ML Symbol.is_digit: "Symbol.symbol -> bool"} \\
   @{index_ML Symbol.is_quasi: "Symbol.symbol -> bool"} \\
   @{index_ML Symbol.is_blank: "Symbol.symbol -> bool"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML_type "Symbol.sym"} \\
   @{index_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}
   @{index_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}
   @{index_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}
   @{index_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}
   @{index_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}
   @{index_ML_type Time.time} \\
   @{index_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}
   @{index_ML Option.map: "('a -> 'b) -> 'a option -> 'b option"} \\
   @{index_ML is_some: "'a option -> bool"} \\
   @{index_ML is_none: "'a option -> bool"} \\
   @{index_ML the: "'a option -> 'a"} \\
   @{index_ML these: "'a list option -> 'a list"} \\
   @{index_ML the_list: "'a option -> 'a list"} \\
   @{index_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}
   @{index_ML cons: "'a -> 'a list -> 'a list"} \\
   @{index_ML member: "('b * 'a -> bool) -> 'a list -> 'b -> bool"} \\
   @{index_ML insert: "('a * 'a -> bool) -> 'a -> 'a list -> 'a list"} \\
   @{index_ML remove: "('b * 'a -> bool) -> 'b -> 'a list -> 'a list"} \\
   @{index_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}
   @{index_ML AList.lookup: "('a * 'b -> bool) -> ('b * 'c) list -> 'a -> 'c option"} \\
   @{index_ML AList.defined: "('a * 'b -> bool) -> ('b * 'c) list -> 'a -> bool"} \\
   @{index_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}
   @{index_ML_type "'a Unsynchronized.ref"} \\
   @{index_ML Unsynchronized.ref: "'a -> 'a Unsynchronized.ref"} \\
   @{index_ML "!": "'a Unsynchronized.ref -> 'a"} \\
-  @{index_ML_op ":=": "'a Unsynchronized.ref * 'a -> unit"} \\
+  @{index_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,
   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}
   @{index_ML File.tmp_path: "Path.T -> Path.T"} \\
   @{index_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}
   @{index_ML_type "'a Synchronized.var"} \\
   @{index_ML Synchronized.var: "string -> 'a -> 'a Synchronized.var"} \\
   @{index_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}
   @{index_ML_type "'a Exn.result"} \\
   @{index_ML Exn.capture: "('a -> 'b) -> 'a -> 'b Exn.result"} \\
   @{index_ML Exn.interruptible_capture: "('a -> 'b) -> 'a -> 'b Exn.result"} \\
   @{index_ML Exn.release: "'a Exn.result -> 'a"} \\
   @{index_ML Par_Exn.release_all: "'a Exn.result list -> 'a list"} \\
   @{index_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}
   @{index_ML Par_List.map: "('a -> 'b) -> 'a list -> 'b list"} \\
   @{index_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}
   @{index_ML_type "'a lazy"} \\
   @{index_ML Lazy.lazy: "(unit -> 'a) -> 'a lazy"} \\
   @{index_ML Lazy.value: "'a -> 'a lazy"} \\
   @{index_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}
   @{index_ML_type "'a future"} \\
   @{index_ML Future.fork: "(unit -> 'a) -> 'a future"} \\
   @{index_ML Future.forks: "Future.params -> (unit -> 'a) list -> 'a future list"} \\
   @{index_ML Future.join: "'a future -> 'a"} \\
   @{index_ML Future.joins: "'a future list -> 'a list"} \\
   @{index_ML Future.value: "'a -> 'a future"} \\
   @{index_ML Future.map: "('a -> 'b) -> 'a future -> 'b future"} \\
   @{index_ML Future.cancel: "'a future -> unit"} \\
   @{index_ML Future.cancel_group: "Future.group -> unit"} \\[0.5ex]
   @{index_ML Future.promise: "(unit -> unit) -> 'a future"} \\
   @{index_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/Prelim.thy b/src/Doc/Implementation/Prelim.thy
--- a/src/Doc/Implementation/Prelim.thy
+++ b/src/Doc/Implementation/Prelim.thy
@@ -1,974 +1,974 @@
 (*:maxLineLen=78:*)
 
 theory Prelim
 imports Base
 begin
 
 chapter \<open>Preliminaries\<close>
 
 section \<open>Contexts \label{sec:context}\<close>
 
 text \<open>
   A logical context represents the background that is required for formulating
   statements and composing proofs. It acts as a medium to produce formal
   content, depending on earlier material (declarations, results etc.).
 
   For example, derivations within the Isabelle/Pure logic can be described as
   a judgment \<open>\<Gamma> \<turnstile>\<^sub>\<Theta> \<phi>\<close>, which means that a proposition \<open>\<phi>\<close> is derivable from
   hypotheses \<open>\<Gamma>\<close> within the theory \<open>\<Theta>\<close>. There are logical reasons for keeping
   \<open>\<Theta>\<close> and \<open>\<Gamma>\<close> separate: theories can be liberal about supporting type
   constructors and schematic polymorphism of constants and axioms, while the
   inner calculus of \<open>\<Gamma> \<turnstile> \<phi>\<close> is strictly limited to Simple Type Theory (with
   fixed type variables in the assumptions).
 
   \<^medskip>
   Contexts and derivations are linked by the following key principles:
 
   \<^item> Transfer: monotonicity of derivations admits results to be transferred
   into a \<^emph>\<open>larger\<close> context, i.e.\ \<open>\<Gamma> \<turnstile>\<^sub>\<Theta> \<phi>\<close> implies \<open>\<Gamma>' \<turnstile>\<^sub>\<Theta>\<^sub>' \<phi>\<close> for contexts
   \<open>\<Theta>' \<supseteq> \<Theta>\<close> and \<open>\<Gamma>' \<supseteq> \<Gamma>\<close>.
 
   \<^item> Export: discharge of hypotheses admits results to be exported into a
   \<^emph>\<open>smaller\<close> context, i.e.\ \<open>\<Gamma>' \<turnstile>\<^sub>\<Theta> \<phi>\<close> implies \<open>\<Gamma> \<turnstile>\<^sub>\<Theta> \<Delta> \<Longrightarrow> \<phi>\<close> where \<open>\<Gamma>' \<supseteq> \<Gamma>\<close>
   and \<open>\<Delta> = \<Gamma>' - \<Gamma>\<close>. Note that \<open>\<Theta>\<close> remains unchanged here, only the \<open>\<Gamma>\<close> part is
   affected.
 
 
   \<^medskip>
   By modeling the main characteristics of the primitive \<open>\<Theta>\<close> and \<open>\<Gamma>\<close> above, and
   abstracting over any particular logical content, we arrive at the
   fundamental notions of \<^emph>\<open>theory context\<close> and \<^emph>\<open>proof context\<close> in
   Isabelle/Isar. These implement a certain policy to manage arbitrary
   \<^emph>\<open>context data\<close>. There is a strongly-typed mechanism to declare new kinds of
   data at compile time.
 
   The internal bootstrap process of Isabelle/Pure eventually reaches a stage
   where certain data slots provide the logical content of \<open>\<Theta>\<close> and \<open>\<Gamma>\<close> sketched
   above, but this does not stop there! Various additional data slots support
   all kinds of mechanisms that are not necessarily part of the core logic.
 
   For example, there would be data for canonical introduction and elimination
   rules for arbitrary operators (depending on the object-logic and
   application), which enables users to perform standard proof steps implicitly
   (cf.\ the \<open>rule\<close> method @{cite "isabelle-isar-ref"}).
 
   \<^medskip>
   Thus Isabelle/Isar is able to bring forth more and more concepts
   successively. In particular, an object-logic like Isabelle/HOL continues the
   Isabelle/Pure setup by adding specific components for automated reasoning
   (classical reasoner, tableau prover, structured induction etc.) and derived
   specification mechanisms (inductive predicates, recursive functions etc.).
   All of this is ultimately based on the generic data management by theory and
   proof contexts introduced here.
 \<close>
 
 
 subsection \<open>Theory context \label{sec:context-theory}\<close>
 
 text \<open>
   A \<^emph>\<open>theory\<close> is a data container with explicit name and unique identifier.
   Theories are related by a (nominal) sub-theory relation, which corresponds
   to the dependency graph of the original construction; each theory is derived
   from a certain sub-graph of ancestor theories. To this end, the system
   maintains a set of symbolic ``identification stamps'' within each theory.
 
   The \<open>begin\<close> operation starts a new theory by importing several parent
   theories (with merged contents) and entering a special mode of nameless
   incremental updates, until the final \<open>end\<close> operation is performed.
 
   \<^medskip>
   The example in \figref{fig:ex-theory} below shows a theory graph derived
   from \<open>Pure\<close>, with theory \<open>Length\<close> importing \<open>Nat\<close> and \<open>List\<close>. The body of
   \<open>Length\<close> consists of a sequence of updates, resulting in locally a linear
   sub-theory relation for each intermediate step.
 
   \begin{figure}[htb]
   \begin{center}
   \begin{tabular}{rcccl}
         &            & \<open>Pure\<close> \\
         &            & \<open>\<down>\<close> \\
         &            & \<open>FOL\<close> \\
         & $\swarrow$ &              & $\searrow$ & \\
   \<open>Nat\<close> &    &              &            & \<open>List\<close> \\
         & $\searrow$ &              & $\swarrow$ \\
         &            & \<open>Length\<close> \\
         &            & \multicolumn{3}{l}{~~@{keyword "begin"}} \\
         &            & $\vdots$~~ \\
         &            & \multicolumn{3}{l}{~~@{command "end"}} \\
   \end{tabular}
   \caption{A theory definition depending on ancestors}\label{fig:ex-theory}
   \end{center}
   \end{figure}
 
   \<^medskip>
   Derived formal entities may retain a reference to the background theory in
   order to indicate the formal context from which they were produced. This
   provides an immutable certificate of the background theory.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML_type theory} \\
   @{index_ML Context.eq_thy: "theory * theory -> bool"} \\
   @{index_ML Context.subthy: "theory * theory -> bool"} \\
   @{index_ML Theory.begin_theory: "string * Position.T -> theory list -> theory"} \\
   @{index_ML Theory.parents_of: "theory -> theory list"} \\
   @{index_ML Theory.ancestors_of: "theory -> theory list"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>theory\<close> represents theory contexts.
 
   \<^descr> \<^ML>\<open>Context.eq_thy\<close>~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> check strict identity of two
   theories.
 
   \<^descr> \<^ML>\<open>Context.subthy\<close>~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> compares theories according to the
   intrinsic graph structure of the construction. This sub-theory relation is a
   nominal approximation of inclusion (\<open>\<subseteq>\<close>) of the corresponding content
   (according to the semantics of the ML modules that implement the data).
 
   \<^descr> \<^ML>\<open>Theory.begin_theory\<close>~\<open>name parents\<close> constructs a new theory based
   on the given parents. This ML function is normally not invoked directly.
 
   \<^descr> \<^ML>\<open>Theory.parents_of\<close>~\<open>thy\<close> returns the direct ancestors of \<open>thy\<close>.
 
   \<^descr> \<^ML>\<open>Theory.ancestors_of\<close>~\<open>thy\<close> returns all ancestors of \<open>thy\<close> (not
   including \<open>thy\<close> itself).
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "theory"} & : & \<open>ML_antiquotation\<close> \\
   @{ML_antiquotation_def "theory_context"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
   @@{ML_antiquotation theory} embedded?
   ;
   @@{ML_antiquotation theory_context} embedded
   \<close>
 
   \<^descr> \<open>@{theory}\<close> refers to the background theory of the current context --- as
   abstract value.
 
   \<^descr> \<open>@{theory A}\<close> refers to an explicitly named ancestor theory \<open>A\<close> of the
   background theory of the current context --- as abstract value.
 
   \<^descr> \<open>@{theory_context A}\<close> is similar to \<open>@{theory A}\<close>, but presents the result
   as initial \<^ML_type>\<open>Proof.context\<close> (see also \<^ML>\<open>Proof_Context.init_global\<close>).
 \<close>
 
 
 subsection \<open>Proof context \label{sec:context-proof}\<close>
 
 text \<open>
   A proof context is a container for pure data that refers to the theory from
   which it is derived. The \<open>init\<close> operation creates a proof context from a
   given theory. There is an explicit \<open>transfer\<close> operation to force
   resynchronization with updates to the background theory -- this is rarely
   required in practice.
 
   Entities derived in a proof context need to record logical requirements
   explicitly, since there is no separate context identification or symbolic
   inclusion as for theories. For example, hypotheses used in primitive
   derivations (cf.\ \secref{sec:thms}) are recorded separately within the
   sequent \<open>\<Gamma> \<turnstile> \<phi>\<close>, just to make double sure. Results could still leak into an
   alien proof context due to programming errors, but Isabelle/Isar includes
   some extra validity checks in critical positions, notably at the end of a
   sub-proof.
 
   Proof contexts may be manipulated arbitrarily, although the common
   discipline is to follow block structure as a mental model: a given context
   is extended consecutively, and results are exported back into the original
   context. Note that an Isar proof state models block-structured reasoning
   explicitly, using a stack of proof contexts internally. For various
   technical reasons, the background theory of an Isar proof state must not be
   changed while the proof is still under construction!
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML_type Proof.context} \\
   @{index_ML Proof_Context.init_global: "theory -> Proof.context"} \\
   @{index_ML Proof_Context.theory_of: "Proof.context -> theory"} \\
   @{index_ML Proof_Context.transfer: "theory -> Proof.context -> Proof.context"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>Proof.context\<close> represents proof contexts.
 
   \<^descr> \<^ML>\<open>Proof_Context.init_global\<close>~\<open>thy\<close> produces a proof context derived
   from \<open>thy\<close>, initializing all data.
 
   \<^descr> \<^ML>\<open>Proof_Context.theory_of\<close>~\<open>ctxt\<close> selects the background theory from
   \<open>ctxt\<close>.
 
   \<^descr> \<^ML>\<open>Proof_Context.transfer\<close>~\<open>thy ctxt\<close> promotes the background theory of
   \<open>ctxt\<close> to the super theory \<open>thy\<close>.
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "context"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^descr> \<open>@{context}\<close> refers to \<^emph>\<open>the\<close> context at compile-time --- as abstract
   value. Independently of (local) theory or proof mode, this always produces a
   meaningful result.
 
   This is probably the most common antiquotation in interactive
   experimentation with ML inside Isar.
 \<close>
 
 
 subsection \<open>Generic contexts \label{sec:generic-context}\<close>
 
 text \<open>
   A generic context is the disjoint sum of either a theory or proof context.
   Occasionally, this enables uniform treatment of generic context data,
   typically extra-logical information. Operations on generic contexts include
   the usual injections, partial selections, and combinators for lifting
   operations on either component of the disjoint sum.
 
   Moreover, there are total operations \<open>theory_of\<close> and \<open>proof_of\<close> to convert a
   generic context into either kind: a theory can always be selected from the
   sum, while a proof context might have to be constructed by an ad-hoc \<open>init\<close>
   operation, which incurs a small runtime overhead.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML_type Context.generic} \\
   @{index_ML Context.theory_of: "Context.generic -> theory"} \\
   @{index_ML Context.proof_of: "Context.generic -> Proof.context"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>Context.generic\<close> is the direct sum of \<^ML_type>\<open>theory\<close>
   and \<^ML_type>\<open>Proof.context\<close>, with the datatype constructors \<^ML>\<open>Context.Theory\<close> and \<^ML>\<open>Context.Proof\<close>.
 
   \<^descr> \<^ML>\<open>Context.theory_of\<close>~\<open>context\<close> always produces a theory from the
   generic \<open>context\<close>, using \<^ML>\<open>Proof_Context.theory_of\<close> as required.
 
   \<^descr> \<^ML>\<open>Context.proof_of\<close>~\<open>context\<close> always produces a proof context from the
   generic \<open>context\<close>, using \<^ML>\<open>Proof_Context.init_global\<close> as required (note
   that this re-initializes the context data with each invocation).
 \<close>
 
 
 subsection \<open>Context data \label{sec:context-data}\<close>
 
 text \<open>
   The main purpose of theory and proof contexts is to manage arbitrary (pure)
   data. New data types can be declared incrementally at compile time. There
   are separate declaration mechanisms for any of the three kinds of contexts:
   theory, proof, generic.
 \<close>
 
 paragraph \<open>Theory data\<close>
 text \<open>declarations need to implement the following ML signature:
 
   \<^medskip>
   \begin{tabular}{ll}
   \<open>\<type> T\<close> & representing type \\
   \<open>\<val> empty: T\<close> & empty default value \\
   \<open>\<val> extend: T \<rightarrow> T\<close> & obsolete (identity function) \\
   \<open>\<val> merge: T \<times> T \<rightarrow> T\<close> & merge data \\
   \end{tabular}
   \<^medskip>
 
   The \<open>empty\<close> value acts as initial default for \<^emph>\<open>any\<close> theory that does not
   declare actual data content; \<open>extend\<close> is obsolete: it needs to be the
   identity function.
 
   The \<open>merge\<close> operation needs to join the data from two theories in a
   conservative manner. The standard scheme for \<open>merge (data\<^sub>1, data\<^sub>2)\<close>
   inserts those parts of \<open>data\<^sub>2\<close> into \<open>data\<^sub>1\<close> that are not yet present,
   while keeping the general order of things. The \<^ML>\<open>Library.merge\<close>
   function on plain lists may serve as canonical template. Particularly note
   that shared parts of the data must not be duplicated by naive concatenation,
   or a theory graph that resembles a chain of diamonds would cause an
   exponential blowup!
 
   Sometimes, the data consists of a single item that cannot be ``merged'' in a
   sensible manner. Then the standard scheme degenerates to the projection to
   \<open>data\<^sub>1\<close>, ignoring \<open>data\<^sub>2\<close> outright.
 \<close>
 
 paragraph \<open>Proof context data\<close>
 text \<open>declarations need to implement the following ML signature:
 
   \<^medskip>
   \begin{tabular}{ll}
   \<open>\<type> T\<close> & representing type \\
   \<open>\<val> init: theory \<rightarrow> T\<close> & produce initial value \\
   \end{tabular}
   \<^medskip>
 
   The \<open>init\<close> operation is supposed to produce a pure value from the given
   background theory and should be somehow ``immediate''. Whenever a proof
   context is initialized, which happens frequently, the the system invokes the
   \<open>init\<close> operation of \<^emph>\<open>all\<close> theory data slots ever declared. This also means
   that one needs to be economic about the total number of proof data
   declarations in the system, i.e.\ each ML module should declare at most one,
   sometimes two data slots for its internal use. Repeated data declarations to
   simulate a record type should be avoided!
 \<close>
 
 paragraph \<open>Generic data\<close>
 text \<open>
   provides a hybrid interface for both theory and proof data. The \<open>init\<close>
   operation for proof contexts is predefined to select the current data value
   from the background theory.
 
   \<^bigskip>
   Any of the above data declarations over type \<open>T\<close> result in an ML structure
   with the following signature:
 
   \<^medskip>
   \begin{tabular}{ll}
   \<open>get: context \<rightarrow> T\<close> \\
   \<open>put: T \<rightarrow> context \<rightarrow> context\<close> \\
   \<open>map: (T \<rightarrow> T) \<rightarrow> context \<rightarrow> context\<close> \\
   \end{tabular}
   \<^medskip>
 
   These other operations provide exclusive access for the particular kind of
   context (theory, proof, or generic context). This interface observes the ML
   discipline for types and scopes: there is no other way to access the
   corresponding data slot of a context. By keeping these operations private,
   an Isabelle/ML module may maintain abstract values authentically.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML_functor Theory_Data} \\
   @{index_ML_functor Proof_Data} \\
   @{index_ML_functor Generic_Data} \\
   \end{mldecls}
 
   \<^descr> \<^ML_functor>\<open>Theory_Data\<close>\<open>(spec)\<close> declares data for type \<^ML_type>\<open>theory\<close>
   according to the specification provided as argument structure. The resulting
   structure provides data init and access operations as described above.
 
   \<^descr> \<^ML_functor>\<open>Proof_Data\<close>\<open>(spec)\<close> is analogous to \<^ML_functor>\<open>Theory_Data\<close>
   for type \<^ML_type>\<open>Proof.context\<close>.
 
   \<^descr> \<^ML_functor>\<open>Generic_Data\<close>\<open>(spec)\<close> is analogous to \<^ML_functor>\<open>Theory_Data\<close> for type \<^ML_type>\<open>Context.generic\<close>. \<close>
 
 text %mlex \<open>
   The following artificial example demonstrates theory data: we maintain a set
   of terms that are supposed to be wellformed wrt.\ the enclosing theory. The
   public interface is as follows:
 \<close>
 
 ML \<open>
   signature WELLFORMED_TERMS =
   sig
     val get: theory -> term list
     val add: term -> theory -> theory
   end;
 \<close>
 
 text \<open>
   The implementation uses private theory data internally, and only exposes an
   operation that involves explicit argument checking wrt.\ the given theory.
 \<close>
 
 ML \<open>
   structure Wellformed_Terms: WELLFORMED_TERMS =
   struct
 
   structure Terms = Theory_Data
   (
     type T = term Ord_List.T;
     val empty = [];
     val extend = I;
     fun merge (ts1, ts2) =
       Ord_List.union Term_Ord.fast_term_ord ts1 ts2;
   );
 
   val get = Terms.get;
 
   fun add raw_t thy =
     let
       val t = Sign.cert_term thy raw_t;
     in
       Terms.map (Ord_List.insert Term_Ord.fast_term_ord t) thy
     end;
 
   end;
 \<close>
 
 text \<open>
   Type \<^ML_type>\<open>term Ord_List.T\<close> is used for reasonably efficient
   representation of a set of terms: all operations are linear in the number of
   stored elements. Here we assume that users of this module do not care about
   the declaration order, since that data structure forces its own arrangement
   of elements.
 
   Observe how the \<^ML_text>\<open>merge\<close> operation joins the data slots of the two
   constituents: \<^ML>\<open>Ord_List.union\<close> prevents duplication of common data from
   different branches, thus avoiding the danger of exponential blowup. Plain
   list append etc.\ must never be used for theory data merges!
 
   \<^medskip>
   Our intended invariant is achieved as follows:
 
     \<^enum> \<^ML>\<open>Wellformed_Terms.add\<close> only admits terms that have passed the \<^ML>\<open>Sign.cert_term\<close> check of the given theory at that point.
   
     \<^enum> Wellformedness in the sense of \<^ML>\<open>Sign.cert_term\<close> is monotonic wrt.\
     the sub-theory relation. So our data can move upwards in the hierarchy
     (via extension or merges), and maintain wellformedness without further
     checks.
 
   Note that all basic operations of the inference kernel (which includes \<^ML>\<open>Sign.cert_term\<close>) observe this monotonicity principle, but other user-space
   tools don't. For example, fully-featured type-inference via \<^ML>\<open>Syntax.check_term\<close> (cf.\ \secref{sec:term-check}) is not necessarily
   monotonic wrt.\ the background theory, since constraints of term constants
   can be modified by later declarations, for example.
 
   In most cases, user-space context data does not have to take such invariants
   too seriously. The situation is different in the implementation of the
   inference kernel itself, which uses the very same data mechanisms for types,
   constants, axioms etc.
 \<close>
 
 
 subsection \<open>Configuration options \label{sec:config-options}\<close>
 
 text \<open>
   A \<^emph>\<open>configuration option\<close> is a named optional value of some basic type
   (Boolean, integer, string) that is stored in the context. It is a simple
   application of general context data (\secref{sec:context-data}) that is
   sufficiently common to justify customized setup, which includes some
   concrete declarations for end-users using existing notation for attributes
   (cf.\ \secref{sec:attributes}).
 
   For example, the predefined configuration option @{attribute show_types}
   controls output of explicit type constraints for variables in printed terms
   (cf.\ \secref{sec:read-print}). Its value can be modified within Isar text
   like this:
 \<close>
 
 experiment
 begin
 
 declare [[show_types = false]]
   \<comment> \<open>declaration within (local) theory context\<close>
 
 notepad
 begin
   note [[show_types = true]]
     \<comment> \<open>declaration within proof (forward mode)\<close>
   term x
 
   have "x = x"
     using [[show_types = false]]
       \<comment> \<open>declaration within proof (backward mode)\<close>
     ..
 end
 
 end
 
 text \<open>
   Configuration options that are not set explicitly hold a default value that
   can depend on the application context. This allows to retrieve the value
   from another slot within the context, or fall back on a global preference
   mechanism, for example.
 
   The operations to declare configuration options and get/map their values are
   modeled as direct replacements for historic global references, only that the
   context is made explicit. This allows easy configuration of tools, without
   relying on the execution order as required for old-style mutable
   references.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML Config.get: "Proof.context -> 'a Config.T -> 'a"} \\
   @{index_ML Config.map: "'a Config.T -> ('a -> 'a) -> Proof.context -> Proof.context"} \\
   @{index_ML Attrib.setup_config_bool: "binding -> (Context.generic -> bool) ->
   bool Config.T"} \\
   @{index_ML Attrib.setup_config_int: "binding -> (Context.generic -> int) ->
   int Config.T"} \\
   @{index_ML Attrib.setup_config_real: "binding -> (Context.generic -> real) ->
   real Config.T"} \\
   @{index_ML Attrib.setup_config_string: "binding -> (Context.generic -> string) ->
   string Config.T"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Config.get\<close>~\<open>ctxt config\<close> gets the value of \<open>config\<close> in the given
   context.
 
   \<^descr> \<^ML>\<open>Config.map\<close>~\<open>config f ctxt\<close> updates the context by updating the value
   of \<open>config\<close>.
 
   \<^descr> \<open>config =\<close>~\<^ML>\<open>Attrib.setup_config_bool\<close>~\<open>name default\<close> creates a named
   configuration option of type \<^ML_type>\<open>bool\<close>, with the given \<open>default\<close>
   depending on the application context. The resulting \<open>config\<close> can be used to
   get/map its value in a given context. There is an implicit update of the
   background theory that registers the option as attribute with some concrete
   syntax.
 
   \<^descr> \<^ML>\<open>Attrib.config_int\<close>, \<^ML>\<open>Attrib.config_real\<close>, and \<^ML>\<open>Attrib.config_string\<close> work like \<^ML>\<open>Attrib.config_bool\<close>, but for types
   \<^ML_type>\<open>int\<close> and \<^ML_type>\<open>string\<close>, respectively.
 \<close>
 
 text %mlex \<open>
   The following example shows how to declare and use a Boolean configuration
   option called \<open>my_flag\<close> with constant default value \<^ML>\<open>false\<close>.
 \<close>
 
 ML \<open>
   val my_flag =
     Attrib.setup_config_bool \<^binding>\<open>my_flag\<close> (K false)
 \<close>
 
 text \<open>
   Now the user can refer to @{attribute my_flag} in declarations, while ML
   tools can retrieve the current value from the context via \<^ML>\<open>Config.get\<close>.
 \<close>
 
 ML_val \<open>\<^assert> (Config.get \<^context> my_flag = false)\<close>
 
 declare [[my_flag = true]]
 
 ML_val \<open>\<^assert> (Config.get \<^context> my_flag = true)\<close>
 
 notepad
 begin
   {
     note [[my_flag = false]]
     ML_val \<open>\<^assert> (Config.get \<^context> my_flag = false)\<close>
   }
   ML_val \<open>\<^assert> (Config.get \<^context> my_flag = true)\<close>
 end
 
 text \<open>
   Here is another example involving ML type \<^ML_type>\<open>real\<close> (floating-point
   numbers).
 \<close>
 
 ML \<open>
   val airspeed_velocity =
     Attrib.setup_config_real \<^binding>\<open>airspeed_velocity\<close> (K 0.0)
 \<close>
 
 declare [[airspeed_velocity = 10]]
 declare [[airspeed_velocity = 9.9]]
 
 
 section \<open>Names \label{sec:names}\<close>
 
 text \<open>
   In principle, a name is just a string, but there are various conventions for
   representing additional structure. For example, ``\<open>Foo.bar.baz\<close>'' is
   considered as a long name consisting of qualifier \<open>Foo.bar\<close> and base name
   \<open>baz\<close>. The individual constituents of a name may have further substructure,
   e.g.\ the string ``\<^verbatim>\<open>\<alpha>\<close>'' encodes as a single symbol (\secref{sec:symbols}).
 
   \<^medskip>
   Subsequently, we shall introduce specific categories of names. Roughly
   speaking these correspond to logical entities as follows:
 
   \<^item> Basic names (\secref{sec:basic-name}): free and bound variables.
 
   \<^item> Indexed names (\secref{sec:indexname}): schematic variables.
 
   \<^item> Long names (\secref{sec:long-name}): constants of any kind (type
   constructors, term constants, other concepts defined in user space). Such
   entities are typically managed via name spaces (\secref{sec:name-space}).
 \<close>
 
 
 subsection \<open>Basic names \label{sec:basic-name}\<close>
 
 text \<open>
   A \<^emph>\<open>basic name\<close> essentially consists of a single Isabelle identifier. There
   are conventions to mark separate classes of basic names, by attaching a
   suffix of underscores: one underscore means \<^emph>\<open>internal name\<close>, two
   underscores means \<^emph>\<open>Skolem name\<close>, three underscores means \<^emph>\<open>internal Skolem
   name\<close>.
 
   For example, the basic name \<open>foo\<close> has the internal version \<open>foo_\<close>, with
   Skolem versions \<open>foo__\<close> and \<open>foo___\<close>, respectively.
 
   These special versions provide copies of the basic name space, apart from
   anything that normally appears in the user text. For example, system
   generated variables in Isar proof contexts are usually marked as internal,
   which prevents mysterious names like \<open>xaa\<close> to appear in human-readable text.
 
   \<^medskip>
   Manipulating binding scopes often requires on-the-fly renamings. A \<^emph>\<open>name
   context\<close> contains a collection of already used names. The \<open>declare\<close>
   operation adds names to the context.
 
   The \<open>invents\<close> operation derives a number of fresh names from a given
   starting point. For example, the first three names derived from \<open>a\<close> are \<open>a\<close>,
   \<open>b\<close>, \<open>c\<close>.
 
   The \<open>variants\<close> operation produces fresh names by incrementing tentative
   names as base-26 numbers (with digits \<open>a..z\<close>) until all clashes are
   resolved. For example, name \<open>foo\<close> results in variants \<open>fooa\<close>, \<open>foob\<close>,
   \<open>fooc\<close>, \dots, \<open>fooaa\<close>, \<open>fooab\<close> etc.; each renaming step picks the next
   unused variant from this sequence.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML Name.internal: "string -> string"} \\
   @{index_ML Name.skolem: "string -> string"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML_type Name.context} \\
   @{index_ML Name.context: Name.context} \\
   @{index_ML Name.declare: "string -> Name.context -> Name.context"} \\
   @{index_ML Name.invent: "Name.context -> string -> int -> string list"} \\
   @{index_ML Name.variant: "string -> Name.context -> string * Name.context"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML Variable.names_of: "Proof.context -> Name.context"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Name.internal\<close>~\<open>name\<close> produces an internal name by adding one
   underscore.
 
   \<^descr> \<^ML>\<open>Name.skolem\<close>~\<open>name\<close> produces a Skolem name by adding two underscores.
 
   \<^descr> Type \<^ML_type>\<open>Name.context\<close> represents the context of already used names;
   the initial value is \<^ML>\<open>Name.context\<close>.
 
   \<^descr> \<^ML>\<open>Name.declare\<close>~\<open>name\<close> enters a used name into the context.
 
   \<^descr> \<^ML>\<open>Name.invent\<close>~\<open>context name n\<close> produces \<open>n\<close> fresh names derived from
   \<open>name\<close>.
 
   \<^descr> \<^ML>\<open>Name.variant\<close>~\<open>name context\<close> produces a fresh variant of \<open>name\<close>; the
   result is declared to the context.
 
   \<^descr> \<^ML>\<open>Variable.names_of\<close>~\<open>ctxt\<close> retrieves the context of declared type and
   term variable names. Projecting a proof context down to a primitive name
   context is occasionally useful when invoking lower-level operations. Regular
   management of ``fresh variables'' is done by suitable operations of
   structure \<^ML_structure>\<open>Variable\<close>, which is also able to provide an
   official status of ``locally fixed variable'' within the logical environment
   (cf.\ \secref{sec:variables}).
 \<close>
 
 text %mlex \<open>
   The following simple examples demonstrate how to produce fresh names from
   the initial \<^ML>\<open>Name.context\<close>.
 \<close>
 
 ML_val \<open>
   val list1 = Name.invent Name.context "a" 5;
   \<^assert> (list1 = ["a", "b", "c", "d", "e"]);
 
   val list2 =
     #1 (fold_map Name.variant ["x", "x", "a", "a", "'a", "'a"] Name.context);
   \<^assert> (list2 = ["x", "xa", "a", "aa", "'a", "'aa"]);
 \<close>
 
 text \<open>
   \<^medskip>
   The same works relatively to the formal context as follows.\<close>
 
 experiment fixes a b c :: 'a
 begin
 
 ML_val \<open>
   val names = Variable.names_of \<^context>;
 
   val list1 = Name.invent names "a" 5;
   \<^assert> (list1 = ["d", "e", "f", "g", "h"]);
 
   val list2 =
     #1 (fold_map Name.variant ["x", "x", "a", "a", "'a", "'a"] names);
   \<^assert> (list2 = ["x", "xa", "aa", "ab", "'aa", "'ab"]);
 \<close>
 
 end
 
 
 subsection \<open>Indexed names \label{sec:indexname}\<close>
 
 text \<open>
   An \<^emph>\<open>indexed name\<close> (or \<open>indexname\<close>) is a pair of a basic name and a natural
   number. This representation allows efficient renaming by incrementing the
   second component only. The canonical way to rename two collections of
   indexnames apart from each other is this: determine the maximum index
   \<open>maxidx\<close> of the first collection, then increment all indexes of the second
   collection by \<open>maxidx + 1\<close>; the maximum index of an empty collection is
   \<open>-1\<close>.
 
   Occasionally, basic names are injected into the same pair type of indexed
   names: then \<open>(x, -1)\<close> is used to encode the basic name \<open>x\<close>.
 
   \<^medskip>
   Isabelle syntax observes the following rules for representing an indexname
   \<open>(x, i)\<close> as a packed string:
 
     \<^item> \<open>?x\<close> if \<open>x\<close> does not end with a digit and \<open>i = 0\<close>,
 
     \<^item> \<open>?xi\<close> if \<open>x\<close> does not end with a digit,
 
     \<^item> \<open>?x.i\<close> otherwise.
 
   Indexnames may acquire large index numbers after several maxidx shifts have
   been applied. Results are usually normalized towards \<open>0\<close> at certain
   checkpoints, notably at the end of a proof. This works by producing variants
   of the corresponding basic name components. For example, the collection
   \<open>?x1, ?x7, ?x42\<close> becomes \<open>?x, ?xa, ?xb\<close>.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
-  @{index_ML_type indexname: "string * int"} \\
+  @{index_ML_type indexname = "string * int"} \\
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>indexname\<close> represents indexed names. This is an
   abbreviation for \<^ML_type>\<open>string * int\<close>. The second component is usually
   non-negative, except for situations where \<open>(x, -1)\<close> is used to inject basic
   names into this type. Other negative indexes should not be used.
 \<close>
 
 
 subsection \<open>Long names \label{sec:long-name}\<close>
 
 text \<open>
   A \<^emph>\<open>long name\<close> consists of a sequence of non-empty name components. The
   packed representation uses a dot as separator, as in ``\<open>A.b.c\<close>''. The last
   component is called \<^emph>\<open>base name\<close>, the remaining prefix is called
   \<^emph>\<open>qualifier\<close> (which may be empty). The qualifier can be understood as the
   access path to the named entity while passing through some nested
   block-structure, although our free-form long names do not really enforce any
   strict discipline.
 
   For example, an item named ``\<open>A.b.c\<close>'' may be understood as a local entity
   \<open>c\<close>, within a local structure \<open>b\<close>, within a global structure \<open>A\<close>. In
   practice, long names usually represent 1--3 levels of qualification. User ML
   code should not make any assumptions about the particular structure of long
   names!
 
   The empty name is commonly used as an indication of unnamed entities, or
   entities that are not entered into the corresponding name space, whenever
   this makes any sense. The basic operations on long names map empty names
   again to empty names.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML Long_Name.base_name: "string -> string"} \\
   @{index_ML Long_Name.qualifier: "string -> string"} \\
   @{index_ML Long_Name.append: "string -> string -> string"} \\
   @{index_ML Long_Name.implode: "string list -> string"} \\
   @{index_ML Long_Name.explode: "string -> string list"} \\
   \end{mldecls}
 
   \<^descr> \<^ML>\<open>Long_Name.base_name\<close>~\<open>name\<close> returns the base name of a long name.
 
   \<^descr> \<^ML>\<open>Long_Name.qualifier\<close>~\<open>name\<close> returns the qualifier of a long name.
 
   \<^descr> \<^ML>\<open>Long_Name.append\<close>~\<open>name\<^sub>1 name\<^sub>2\<close> appends two long names.
 
   \<^descr> \<^ML>\<open>Long_Name.implode\<close>~\<open>names\<close> and \<^ML>\<open>Long_Name.explode\<close>~\<open>name\<close> convert
   between the packed string representation and the explicit list form of long
   names.
 \<close>
 
 
 subsection \<open>Name spaces \label{sec:name-space}\<close>
 
 text \<open>
   A \<open>name space\<close> manages a collection of long names, together with a mapping
   between partially qualified external names and fully qualified internal
   names (in both directions). Note that the corresponding \<open>intern\<close> and
   \<open>extern\<close> operations are mostly used for parsing and printing only! The
   \<open>declare\<close> operation augments a name space according to the accesses
   determined by a given binding, and a naming policy from the context.
 
   \<^medskip>
   A \<open>binding\<close> specifies details about the prospective long name of a newly
   introduced formal entity. It consists of a base name, prefixes for
   qualification (separate ones for system infrastructure and user-space
   mechanisms), a slot for the original source position, and some additional
   flags.
 
   \<^medskip>
   A \<open>naming\<close> provides some additional details for producing a long name from a
   binding. Normally, the naming is implicit in the theory or proof context.
   The \<open>full\<close> operation (and its variants for different context types) produces
   a fully qualified internal name to be entered into a name space. The main
   equation of this ``chemical reaction'' when binding new entities in a
   context is as follows:
 
   \<^medskip>
   \begin{tabular}{l}
   \<open>binding + naming \<longrightarrow> long name + name space accesses\<close>
   \end{tabular}
 
   \<^bigskip>
   As a general principle, there is a separate name space for each kind of
   formal entity, e.g.\ fact, logical constant, type constructor, type class.
   It is usually clear from the occurrence in concrete syntax (or from the
   scope) which kind of entity a name refers to. For example, the very same
   name \<open>c\<close> may be used uniformly for a constant, type constructor, and type
   class.
 
   There are common schemes to name derived entities systematically according
   to the name of the main logical entity involved, e.g.\ fact \<open>c.intro\<close> for a
   canonical introduction rule related to constant \<open>c\<close>. This technique of
   mapping names from one space into another requires some care in order to
   avoid conflicts. In particular, theorem names derived from a type
   constructor or type class should get an additional suffix in addition to the
   usual qualification. This leads to the following conventions for derived
   names:
 
   \<^medskip>
   \begin{tabular}{ll}
   logical entity & fact name \\\hline
   constant \<open>c\<close> & \<open>c.intro\<close> \\
   type \<open>c\<close> & \<open>c_type.intro\<close> \\
   class \<open>c\<close> & \<open>c_class.intro\<close> \\
   \end{tabular}
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
   @{index_ML_type binding} \\
   @{index_ML Binding.empty: binding} \\
   @{index_ML Binding.name: "string -> binding"} \\
   @{index_ML Binding.qualify: "bool -> string -> binding -> binding"} \\
   @{index_ML Binding.prefix: "bool -> string -> binding -> binding"} \\
   @{index_ML Binding.concealed: "binding -> binding"} \\
   @{index_ML Binding.print: "binding -> string"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML_type Name_Space.naming} \\
   @{index_ML Name_Space.global_naming: Name_Space.naming} \\
   @{index_ML Name_Space.add_path: "string -> Name_Space.naming -> Name_Space.naming"} \\
   @{index_ML Name_Space.full_name: "Name_Space.naming -> binding -> string"} \\
   \end{mldecls}
   \begin{mldecls}
   @{index_ML_type Name_Space.T} \\
   @{index_ML Name_Space.empty: "string -> Name_Space.T"} \\
   @{index_ML Name_Space.merge: "Name_Space.T * Name_Space.T -> Name_Space.T"} \\
   @{index_ML Name_Space.declare: "Context.generic -> bool ->
   binding -> Name_Space.T -> string * Name_Space.T"} \\
   @{index_ML Name_Space.intern: "Name_Space.T -> string -> string"} \\
   @{index_ML Name_Space.extern: "Proof.context -> Name_Space.T -> string -> string"} \\
   @{index_ML Name_Space.is_concealed: "Name_Space.T -> string -> bool"}
   \end{mldecls}
 
   \<^descr> Type \<^ML_type>\<open>binding\<close> represents the abstract concept of name bindings.
 
   \<^descr> \<^ML>\<open>Binding.empty\<close> is the empty binding.
 
   \<^descr> \<^ML>\<open>Binding.name\<close>~\<open>name\<close> produces a binding with base name \<open>name\<close>. Note
   that this lacks proper source position information; see also the ML
   antiquotation @{ML_antiquotation binding}.
 
   \<^descr> \<^ML>\<open>Binding.qualify\<close>~\<open>mandatory name binding\<close> prefixes qualifier \<open>name\<close>
   to \<open>binding\<close>. The \<open>mandatory\<close> flag tells if this name component always needs
   to be given in name space accesses --- this is mostly \<open>false\<close> in practice.
   Note that this part of qualification is typically used in derived
   specification mechanisms.
 
   \<^descr> \<^ML>\<open>Binding.prefix\<close> is similar to \<^ML>\<open>Binding.qualify\<close>, but affects the
   system prefix. This part of extra qualification is typically used in the
   infrastructure for modular specifications, notably ``local theory targets''
   (see also \chref{ch:local-theory}).
 
   \<^descr> \<^ML>\<open>Binding.concealed\<close>~\<open>binding\<close> indicates that the binding shall refer
   to an entity that serves foundational purposes only. This flag helps to mark
   implementation details of specification mechanism etc. Other tools should
   not depend on the particulars of concealed entities (cf.\ \<^ML>\<open>Name_Space.is_concealed\<close>).
 
   \<^descr> \<^ML>\<open>Binding.print\<close>~\<open>binding\<close> produces a string representation for
   human-readable output, together with some formal markup that might get used
   in GUI front-ends, for example.
 
   \<^descr> Type \<^ML_type>\<open>Name_Space.naming\<close> represents the abstract concept of a
   naming policy.
 
   \<^descr> \<^ML>\<open>Name_Space.global_naming\<close> is the default naming policy: it is global
   and lacks any path prefix. In a regular theory context this is augmented by
   a path prefix consisting of the theory name.
 
   \<^descr> \<^ML>\<open>Name_Space.add_path\<close>~\<open>path naming\<close> augments the naming policy by
   extending its path component.
 
   \<^descr> \<^ML>\<open>Name_Space.full_name\<close>~\<open>naming binding\<close> turns a name binding (usually
   a basic name) into the fully qualified internal name, according to the given
   naming policy.
 
   \<^descr> Type \<^ML_type>\<open>Name_Space.T\<close> represents name spaces.
 
   \<^descr> \<^ML>\<open>Name_Space.empty\<close>~\<open>kind\<close> and \<^ML>\<open>Name_Space.merge\<close>~\<open>(space\<^sub>1,
   space\<^sub>2)\<close> are the canonical operations for maintaining name spaces according
   to theory data management (\secref{sec:context-data}); \<open>kind\<close> is a formal
   comment to characterize the purpose of a name space.
 
   \<^descr> \<^ML>\<open>Name_Space.declare\<close>~\<open>context strict binding space\<close> enters a name
   binding as fully qualified internal name into the name space, using the
   naming of the context.
 
   \<^descr> \<^ML>\<open>Name_Space.intern\<close>~\<open>space name\<close> internalizes a (partially qualified)
   external name.
 
   This operation is mostly for parsing! Note that fully qualified names
   stemming from declarations are produced via \<^ML>\<open>Name_Space.full_name\<close> and
   \<^ML>\<open>Name_Space.declare\<close> (or their derivatives for \<^ML_type>\<open>theory\<close> and
   \<^ML_type>\<open>Proof.context\<close>).
 
   \<^descr> \<^ML>\<open>Name_Space.extern\<close>~\<open>ctxt space name\<close> externalizes a (fully qualified)
   internal name.
 
   This operation is mostly for printing! User code should not rely on the
   precise result too much.
 
   \<^descr> \<^ML>\<open>Name_Space.is_concealed\<close>~\<open>space name\<close> indicates whether \<open>name\<close> refers
   to a strictly private entity that other tools are supposed to ignore!
 \<close>
 
 text %mlantiq \<open>
   \begin{matharray}{rcl}
   @{ML_antiquotation_def "binding"} & : & \<open>ML_antiquotation\<close> \\
   \end{matharray}
 
   \<^rail>\<open>
   @@{ML_antiquotation binding} embedded
   \<close>
 
   \<^descr> \<open>@{binding name}\<close> produces a binding with base name \<open>name\<close> and the source
   position taken from the concrete syntax of this antiquotation. In many
   situations this is more appropriate than the more basic \<^ML>\<open>Binding.name\<close>
   function.
 \<close>
 
 text %mlex \<open>
   The following example yields the source position of some concrete binding
   inlined into the text:
 \<close>
 
 ML_val \<open>Binding.pos_of \<^binding>\<open>here\<close>\<close>
 
 text \<open>
   \<^medskip>
   That position can be also printed in a message as follows:
 \<close>
 
 ML_command
   \<open>writeln
     ("Look here" ^ Position.here (Binding.pos_of \<^binding>\<open>here\<close>))\<close>
 
 text \<open>
   This illustrates a key virtue of formalized bindings as opposed to raw
   specifications of base names: the system can use this additional information
   for feedback given to the user (error messages etc.).
 
   \<^medskip>
   The following example refers to its source position directly, which is
   occasionally useful for experimentation and diagnostic purposes:
 \<close>
 
 ML_command \<open>warning ("Look here" ^ Position.here \<^here>)\<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}
   @{index_ML Goal.init: "cterm -> thm"} \\
   @{index_ML Goal.finish: "Proof.context -> thm -> thm"} \\
   @{index_ML Goal.protect: "int -> thm -> thm"} \\
   @{index_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}
-  @{index_ML_type tactic: "thm -> thm Seq.seq"} \\
+  @{index_ML_type tactic = "thm -> thm Seq.seq"} \\
   @{index_ML no_tac: tactic} \\
   @{index_ML all_tac: tactic} \\
   @{index_ML print_tac: "Proof.context -> string -> tactic"} \\[1ex]
   @{index_ML PRIMITIVE: "(thm -> thm) -> tactic"} \\[1ex]
   @{index_ML SUBGOAL: "(term * int -> tactic) -> int -> tactic"} \\
   @{index_ML CSUBGOAL: "(cterm * int -> tactic) -> int -> tactic"} \\
   @{index_ML SELECT_GOAL: "tactic -> int -> tactic"} \\
   @{index_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}
   @{index_ML resolve_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_ML eresolve_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_ML dresolve_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_ML forward_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_ML biresolve_tac: "Proof.context -> (bool * thm) list -> int -> tactic"} \\[1ex]
   @{index_ML assume_tac: "Proof.context -> int -> tactic"} \\
   @{index_ML eq_assume_tac: "int -> tactic"} \\[1ex]
   @{index_ML match_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_ML ematch_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_ML dmatch_tac: "Proof.context -> thm list -> int -> tactic"} \\
   @{index_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}
   @{index_ML Rule_Insts.res_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{index_ML Rule_Insts.eres_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{index_ML Rule_Insts.dres_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{index_ML Rule_Insts.forw_inst_tac: "Proof.context ->
     ((indexname * Position.T) * string) list -> (binding * string option * mixfix) list ->
     thm -> int -> tactic"} \\
   @{index_ML Rule_Insts.subgoal_tac: "Proof.context -> string ->
     (binding * string option * mixfix) list -> int -> tactic"} \\
   @{index_ML Rule_Insts.thin_tac: "Proof.context -> string ->
     (binding * string option * mixfix) list -> int -> tactic"} \\
   @{index_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}
   @{index_ML rotate_tac: "int -> int -> tactic"} \\
   @{index_ML distinct_subgoals_tac: tactic} \\
   @{index_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}
   @{index_ML compose_tac: "Proof.context -> (bool * thm * int) -> int -> tactic"} \\
   @{index_ML Drule.compose: "thm * int * thm -> thm"} \\
-  @{index_ML_op COMP: "thm * thm -> thm"} \\
+  @{index_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
   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
   subgoal addressing.
 \<close>
 
 text %mlref \<open>
   \begin{mldecls}
-  @{index_ML_op "THEN": "tactic * tactic -> tactic"} \\
-  @{index_ML_op "ORELSE": "tactic * tactic -> tactic"} \\
-  @{index_ML_op "APPEND": "tactic * tactic -> tactic"} \\
+  @{index_ML_infix "THEN": "tactic * tactic -> tactic"} \\
+  @{index_ML_infix "ORELSE": "tactic * tactic -> tactic"} \\
+  @{index_ML_infix "APPEND": "tactic * tactic -> tactic"} \\
   @{index_ML "EVERY": "tactic list -> tactic"} \\
   @{index_ML "FIRST": "tactic list -> tactic"} \\[0.5ex]
 
-  @{index_ML_op "THEN'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
-  @{index_ML_op "ORELSE'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
-  @{index_ML_op "APPEND'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
+  @{index_ML_infix "THEN'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
+  @{index_ML_infix "ORELSE'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
+  @{index_ML_infix "APPEND'": "('a -> tactic) * ('a -> tactic) -> 'a -> tactic"} \\
   @{index_ML "EVERY'": "('a -> tactic) list -> 'a -> tactic"} \\
   @{index_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
   \<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
   \<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
   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
   \<^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
   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>.
 
   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}
   @{index_ML "TRY": "tactic -> tactic"} \\
   @{index_ML "REPEAT": "tactic -> tactic"} \\
   @{index_ML "REPEAT1": "tactic -> tactic"} \\
   @{index_ML "REPEAT_DETERM": "tactic -> tactic"} \\
   @{index_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
   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>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>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>
   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}
   @{index_ML ALLGOALS: "(int -> tactic) -> tactic"} \\
   @{index_ML SOMEGOAL: "(int -> tactic) -> tactic"} \\
   @{index_ML FIRSTGOAL: "(int -> tactic) -> tactic"} \\
   @{index_ML HEADGOAL: "(int -> tactic) -> tactic"} \\
   @{index_ML REPEAT_SOME: "(int -> tactic) -> tactic"} \\
   @{index_ML REPEAT_FIRST: "(int -> tactic) -> tactic"} \\
   @{index_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>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>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>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
   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}
   @{index_ML FILTER: "(thm -> bool) -> tactic -> tactic"} \\
   @{index_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}
   @{index_ML DEPTH_FIRST: "(thm -> bool) -> tactic -> tactic"} \\
   @{index_ML DEPTH_SOLVE: "tactic -> tactic"} \\
   @{index_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.
 
   \<^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}
   @{index_ML BREADTH_FIRST: "(thm -> bool) -> tactic -> tactic"} \\
   @{index_ML BEST_FIRST: "(thm -> bool) * (thm -> int) -> tactic -> tactic"} \\
   @{index_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}
   @{index_ML COND: "(thm -> bool) -> tactic -> tactic -> tactic"} \\
   @{index_ML IF_UNSOLVED: "tactic -> tactic"} \\
   @{index_ML SOLVE: "tactic -> tactic"} \\
   @{index_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}
   @{index_ML has_fewer_prems: "int -> thm -> bool"} \\
   @{index_ML Thm.eq_thm: "thm * thm -> bool"} \\
   @{index_ML Thm.eq_thm_prop: "thm * thm -> bool"} \\
   @{index_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/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"}.
   
   \<^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 @{index_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}
   @{index_ML Simplifier.set_subgoaler: "(Proof.context -> int -> tactic) ->
   Proof.context -> Proof.context"} \\
   @{index_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}
   @{index_ML_type solver} \\
   @{index_ML Simplifier.mk_solver: "string ->
   (Proof.context -> int -> tactic) -> solver"} \\
-  @{index_ML_op setSolver: "Proof.context * solver -> Proof.context"} \\
-  @{index_ML_op addSolver: "Proof.context * solver -> Proof.context"} \\
-  @{index_ML_op setSSolver: "Proof.context * solver -> Proof.context"} \\
-  @{index_ML_op addSSolver: "Proof.context * solver -> Proof.context"} \\
+  @{index_ML_infix setSolver: "Proof.context * solver -> Proof.context"} \\
+  @{index_ML_infix addSolver: "Proof.context * solver -> Proof.context"} \\
+  @{index_ML_infix setSSolver: "Proof.context * solver -> Proof.context"} \\
+  @{index_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}
-  @{index_ML_op setloop: "Proof.context *
+  @{index_ML_infix setloop: "Proof.context *
   (Proof.context -> int -> tactic) -> Proof.context"} \\
-  @{index_ML_op addloop: "Proof.context *
+  @{index_ML_infix addloop: "Proof.context *
   (string * (Proof.context -> int -> tactic))
   -> Proof.context"} \\
-  @{index_ML_op delloop: "Proof.context * string -> Proof.context"} \\
+  @{index_ML_infix delloop: "Proof.context * string -> Proof.context"} \\
   @{index_ML Splitter.add_split: "thm -> Proof.context -> Proof.context"} \\
   @{index_ML Splitter.add_split: "thm -> Proof.context -> Proof.context"} \\
   @{index_ML Splitter.add_split_bang: "
   thm -> Proof.context -> Proof.context"} \\
   @{index_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}
-    @{index_ML_type wrapper: "(int -> tactic) -> (int -> tactic)"} \\[0.5ex]
-    @{index_ML_op addSWrapper: "Proof.context *
+    @{index_ML_type wrapper = "(int -> tactic) -> (int -> tactic)"} \\[0.5ex]
+    @{index_ML_infix addSWrapper: "Proof.context *
   (string * (Proof.context -> wrapper)) -> Proof.context"} \\
-    @{index_ML_op addSbefore: "Proof.context *
-  (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
-    @{index_ML_op addSafter: "Proof.context *
+    @{index_ML_infix addSbefore: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
-    @{index_ML_op delSWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
-    @{index_ML_op addWrapper: "Proof.context *
+    @{index_ML_infix addSafter: "Proof.context *
+  (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
+    @{index_ML_infix delSWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
+    @{index_ML_infix addWrapper: "Proof.context *
   (string * (Proof.context -> wrapper)) -> Proof.context"} \\
-    @{index_ML_op addbefore: "Proof.context *
+    @{index_ML_infix addbefore: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
-    @{index_ML_op addafter: "Proof.context *
+    @{index_ML_infix addafter: "Proof.context *
   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
-    @{index_ML_op delWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
+    @{index_ML_infix delWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
     @{index_ML addSss: "Proof.context -> Proof.context"} \\
     @{index_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/antiquote_setup.ML b/src/Doc/antiquote_setup.ML
--- a/src/Doc/antiquote_setup.ML
+++ b/src/Doc/antiquote_setup.ML
@@ -1,242 +1,246 @@
 (*  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 ml_val (toks1, []) = ML_Lex.read "fn _ => (" @ toks1 @ ML_Lex.read ");"
-  | ml_val (toks1, toks2) =
-      ML_Lex.read "fn _ => (" @ toks1 @ ML_Lex.read " : " @ toks2 @ ML_Lex.read ");";
-
-fun ml_op (toks1, []) = ML_Lex.read "fn _ => (op " @ toks1 @ ML_Lex.read ");"
-  | ml_op (toks1, toks2) =
-      ML_Lex.read "fn _ => (op " @ toks1 @ ML_Lex.read " : " @ toks2 @ ML_Lex.read ");";
+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 ml_type (toks1, []) = ML_Lex.read "val _ = NONE : (" @ toks1 @ ML_Lex.read ") option;"
-  | ml_type (toks1, toks2) =
-      ML_Lex.read "val _ = [NONE : (" @ toks1 @ ML_Lex.read ") option, NONE : (" @
-        toks2 @ ML_Lex.read ") option];";
+fun test_op (ml1, ml2) = test_val (ML_Lex.read "op " @ ml1, ml2);
 
-fun ml_exception (toks1, []) = ML_Lex.read "fn _ => (" @ toks1 @ ML_Lex.read " : exn);"
-  | ml_exception (toks1, toks2) =
-      ML_Lex.read "fn _ => (" @ toks1 @ ML_Lex.read " : " @ toks2 @ ML_Lex.read " -> exn);";
+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 ml_structure (toks, _) =
-  ML_Lex.read "functor XXX() = struct structure XX = " @ toks @ ML_Lex.read " end;";
+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 ml_functor (Antiquote.Text tok :: _, _) =
+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))
-  | ml_functor _ = raise Fail "Bad ML functor specification";
+  | 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 ml_name txt =
-  (case filter is_name (ML_Lex.tokenize txt) of
-    toks as [_] => ML_Lex.flatten toks
-  | _ => error ("Single ML name expected in input: " ^ quote txt));
-
-fun prep_ml source =
-  (#1 (Input.source_content source), ML_Lex.read_source source);
-
-fun index_ml name kind ml = Document_Output.antiquotation_raw name
-  (Scan.lift (Args.text_input -- Scan.option (Args.colon |-- Args.text_input)))
-  (fn ctxt => fn (source1, opt_source2) =>
-    let
-      val (txt1, ants1) = prep_ml source1;
-      val (txt2, ants2) =
-        (case opt_source2 of
-          SOME source => prep_ml source
-        | NONE => ("", []));
+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 txt =
-        if txt2 = "" then txt1
-        else if kind = "type" then txt1 ^ " = " ^ txt2
-        else if kind = "exception" then txt1 ^ " of " ^ txt2
-        else if Symbol_Pos.is_identifier (Long_Name.base_name (ml_name txt1))
-        then txt1 ^ ": " ^ txt2
-        else txt1 ^ " : " ^ txt2;
-      val txt' = if kind = "" then txt else kind ^ " " ^ txt;
+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;
 
-      val pos = Input.pos_of source1;
-      val _ =
-        ML_Context.eval_in (SOME ctxt) ML_Compiler.flags pos (ml (ants1, ants2))
-          handle ERROR msg => error (msg ^ Position.here pos);
-      val kind' = if kind = "" then "ML" else "ML " ^ kind;
-    in
-      Latex.block
-       [Latex.string ("\\indexdef{}{" ^ kind' ^ "}{" ^ clean_string (ml_name txt1) ^ "}"),
-        Document_Output.verbatim ctxt txt']
-    end);
+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
-   (index_ml \<^binding>\<open>index_ML\<close> "" ml_val #>
-    index_ml \<^binding>\<open>index_ML_op\<close> "infix" ml_op #>
-    index_ml \<^binding>\<open>index_ML_type\<close> "type" ml_type #>
-    index_ml \<^binding>\<open>index_ML_exception\<close> "exception" ml_exception #>
-    index_ml \<^binding>\<open>index_ML_structure\<close> "structure" ml_structure #>
-    index_ml \<^binding>\<open>index_ML_functor\<close> "functor" ml_functor);
+   (antiquotation_ml' parse_ml test_val "" \<^binding>\<open>index_ML\<close> #>
+    antiquotation_ml' parse_ml test_op "infix" \<^binding>\<open>index_ML_infix\<close> #>
+    antiquotation_ml' parse_type test_type "type" \<^binding>\<open>index_ML_type\<close> #>
+    antiquotation_ml' parse_exn text_exn "exception" \<^binding>\<open>index_ML_exception\<close> #>
+    antiquotation_ml' parse_struct test_struct "structure" \<^binding>\<open>index_ML_structure\<close> #>
+    antiquotation_ml' parse_struct test_functor "functor" \<^binding>\<open>index_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/latex.ML b/src/Pure/Thy/latex.ML
--- a/src/Pure/Thy/latex.ML
+++ b/src/Pure/Thy/latex.ML
@@ -1,298 +1,307 @@
 (*  Title:      Pure/Thy/latex.ML
     Author:     Makarius
 
 LaTeX output of theory sources.
 *)
 
 signature LATEX =
 sig
   type text
   val string: string -> text
   val text: string * Position.T -> text
   val block: text list -> text
   val enclose_body: string -> string -> text list -> text list
   val enclose_block: string -> string -> text list -> text
   val output_text: text list -> string
   val output_positions: Position.T -> text list -> string
   val output_name: string -> string
   val output_ascii: string -> string
   val output_ascii_breakable: string -> string -> string
   val output_symbols: Symbol.symbol list -> string
   val output_syms: string -> string
   val symbols: Symbol_Pos.T list -> text
   val symbols_output: Symbol_Pos.T list -> text
   val begin_delim: string -> string
   val end_delim: string -> string
   val begin_tag: string -> string
   val end_tag: string -> string
   val environment_block: string -> text list -> text
   val environment: string -> string -> string
   val isabelle_body: string -> text list -> text list
   val theory_entry: string -> string
   val index_escape: string -> string
   type index_item = {text: text, like: string}
   val index_item: index_item -> text
   type index_entry = {items: index_item list, def: bool}
   val index_entry: index_entry -> text
+  val index_variants: (binding -> bool option -> 'a -> 'a) -> binding -> 'a -> 'a
   val latexN: string
   val latex_output: string -> string * int
   val latex_markup: string * Properties.T -> Markup.output
   val latex_indent: string -> int -> string
 end;
 
 structure Latex: LATEX =
 struct
 
 (* text with positions *)
 
 abstype text = Text of string * Position.T | Block of text list
 with
 
 fun string s = Text (s, Position.none);
 val text = Text;
 val block = Block;
 
 fun map_text f (Text (s, pos)) = Text (f s, pos)
   | map_text f (Block texts) = Block ((map o map_text) f texts);
 
 fun output_text texts =
   let
     fun output (Text (s, _)) = Buffer.add s
       | output (Block body) = fold output body;
   in Buffer.empty |> fold output texts |> Buffer.content end;
 
 fun output_positions file_pos texts =
   let
     fun position (a, b) = enclose "%:%" "%:%" (a ^ "=" ^ b);
     fun add_position p positions =
       let val s = position (apply2 Value.print_int p)
       in positions |> s <> hd positions ? cons s end;
 
     fun output (Text (s, pos)) (positions, line) =
           let
             val positions' =
               (case Position.line_of pos of
                 NONE => positions
               | SOME l => add_position (line, l) positions);
             val line' = fold_string (fn c => fn n => if c = "\n" then n + 1 else n) s line;
           in (positions', line') end
       | output (Block body) res = fold output body res;
   in
     (case Position.file_of file_pos of
       NONE => ""
     | SOME file =>
         ([position (Markup.fileN, file), "\\endinput"], 1)
         |> fold output texts |> #1 |> rev |> cat_lines)
   end;
 
 end;
 
 fun enclose_body bg en body =
   (if bg = "" then [] else [string bg]) @ body @
   (if en = "" then [] else [string en]);
 
 fun enclose_block bg en = block o enclose_body bg en;
 
 
 (* output name for LaTeX macros *)
 
 val output_name =
   translate_string
     (fn "_" => "UNDERSCORE"
       | "'" => "PRIME"
       | "0" => "ZERO"
       | "1" => "ONE"
       | "2" => "TWO"
       | "3" => "THREE"
       | "4" => "FOUR"
       | "5" => "FIVE"
       | "6" => "SIX"
       | "7" => "SEVEN"
       | "8" => "EIGHT"
       | "9" => "NINE"
       | s => s);
 
 fun enclose_name bg en = enclose bg en o output_name;
 
 
 (* output verbatim ASCII *)
 
 val output_ascii =
   translate_string
     (fn " " => "\\ "
       | "\t" => "\\ "
       | "\n" => "\\isanewline\n"
       | s =>
           s
           |> exists_string (fn s' => s = s') "\"#$%&',-<>\\^_`{}~" ? enclose "{\\char`\\" "}"
           |> suffix "{\\kern0pt}");
 
 fun output_ascii_breakable sep =
   space_explode sep
   #> map output_ascii
   #> space_implode (output_ascii sep ^ "\\discretionary{}{}{}");
 
 
 (* output symbols *)
 
 local
 
 val char_table =
   Symtab.make
    [("\007", "{\\isacharbell}"),
     ("!", "{\\isacharbang}"),
     ("\"", "{\\isachardoublequote}"),
     ("#", "{\\isacharhash}"),
     ("$", "{\\isachardollar}"),
     ("%", "{\\isacharpercent}"),
     ("&", "{\\isacharampersand}"),
     ("'", "{\\isacharprime}"),
     ("(", "{\\isacharparenleft}"),
     (")", "{\\isacharparenright}"),
     ("*", "{\\isacharasterisk}"),
     ("+", "{\\isacharplus}"),
     (",", "{\\isacharcomma}"),
     ("-", "{\\isacharminus}"),
     (".", "{\\isachardot}"),
     ("/", "{\\isacharslash}"),
     (":", "{\\isacharcolon}"),
     (";", "{\\isacharsemicolon}"),
     ("<", "{\\isacharless}"),
     ("=", "{\\isacharequal}"),
     (">", "{\\isachargreater}"),
     ("?", "{\\isacharquery}"),
     ("@", "{\\isacharat}"),
     ("[", "{\\isacharbrackleft}"),
     ("\\", "{\\isacharbackslash}"),
     ("]", "{\\isacharbrackright}"),
     ("^", "{\\isacharcircum}"),
     ("_", "{\\isacharunderscore}"),
     ("`", "{\\isacharbackquote}"),
     ("{", "{\\isacharbraceleft}"),
     ("|", "{\\isacharbar}"),
     ("}", "{\\isacharbraceright}"),
     ("~", "{\\isachartilde}")];
 
 fun output_chr " " = "\\ "
   | output_chr "\t" = "\\ "
   | output_chr "\n" = "\\isanewline\n"
   | output_chr c =
       (case Symtab.lookup char_table c of
         SOME s => s ^ "{\\kern0pt}"
       | NONE => if Symbol.is_ascii_digit c then enclose "{\\isadigit{" "}}" c else c);
 
 fun output_sym sym =
   (case Symbol.decode sym of
     Symbol.Char s => output_chr s
   | Symbol.UTF8 s => s
   | Symbol.Sym s => enclose_name "{\\isasym" "}" s
   | Symbol.Control s => enclose_name "\\isactrl" " " s
   | Symbol.Malformed s => error (Symbol.malformed_msg s)
   | Symbol.EOF => error "Bad EOF symbol");
 
 open Basic_Symbol_Pos;
 
 val scan_latex_length =
   Scan.many1 (fn (s, _) => s <> Symbol.latex andalso Symbol.not_eof s)
     >> (Symbol.length o map Symbol_Pos.symbol) ||
   $$ Symbol.latex -- Scan.option (Scan.permissive Symbol_Pos.scan_cartouche "") >> K 0;
 
 val scan_latex =
   $$ Symbol.latex |-- Symbol_Pos.scan_cartouche_content "Embedded LaTeX: "
     >> (implode o map Symbol_Pos.symbol) ||
   Scan.one (Symbol.not_eof o Symbol_Pos.symbol) >> (output_sym o Symbol_Pos.symbol);
 
 fun read scan syms =
   Scan.read Symbol_Pos.stopper (Scan.repeat scan) (map (rpair Position.none) syms);
 
 in
 
 fun length_symbols syms =
   fold Integer.add (these (read scan_latex_length syms)) 0;
 
 fun output_symbols syms =
   if member (op =) syms Symbol.latex then
     (case read scan_latex syms of
       SOME ss => implode ss
     | NONE => error ("Malformed embedded LaTeX: " ^ quote (Symbol.beginning 10 syms)))
   else implode (map output_sym syms);
 
 val output_syms = output_symbols o Symbol.explode;
 
 end;
 
 fun symbols syms = text (Symbol_Pos.content syms, #1 (Symbol_Pos.range syms));
 fun symbols_output syms =
   text (output_symbols (map Symbol_Pos.symbol syms), #1 (Symbol_Pos.range syms));
 
 
 (* tags *)
 
 val begin_delim = enclose_name "%\n\\isadelim" "\n";
 val end_delim = enclose_name "%\n\\endisadelim" "\n";
 val begin_tag = enclose_name "%\n\\isatag" "\n";
 fun end_tag tg = enclose_name "%\n\\endisatag" "\n" tg ^ enclose "{\\isafold" "}%\n" tg;
 
 
 (* theory presentation *)
 
 fun environment_delim name =
  ("%\n\\begin{" ^ output_name name ^ "}%\n",
   "%\n\\end{" ^ output_name name ^ "}");
 
 fun environment_block name = environment_delim name |-> enclose_body #> block;
 fun environment name = environment_delim name |-> enclose;
 
 fun isabelle_body name =
   enclose_body
    ("%\n\\begin{isabellebody}%\n\\setisabellecontext{" ^ output_syms name ^ "}%\n")
    "%\n\\end{isabellebody}%\n";
 
 fun theory_entry name = "\\input{" ^ name ^ ".tex}\n\n";
 
 
 (* index entries *)
 
 type index_item = {text: text, like: string};
 type index_entry = {items: index_item list, def: bool};
 
 val index_escape =
   translate_string (fn s =>
-    s |> exists_string (fn s' => s = s') "\"\\{}!@|" ? prefix "\"");
+    if member_string "!\"@|" s then "\\char" ^ string_of_int (ord s)
+    else if member_string "\\{}#" s then "\"" ^ s else s);
 
 fun index_item (item: index_item) =
   let
     val like_text =
       if #like item = "" then []
       else [string (index_escape (#like item) ^ "@")];
   in block (like_text @ [map_text index_escape (#text item)]) end;
 
 fun index_entry (entry: index_entry) =
   (separate (string "!") (map index_item (#items entry)) @
     [string ("|" ^ index_escape (if #def entry then "isaindexdef" else "isaindexref"))])
   |> enclose_block "\\index{" "}";
 
 
+fun index_binding NONE = I
+  | index_binding (SOME def) = Binding.map_name (suffix (if def then "_def" else "_ref"));
+
+fun index_variants setup binding =
+  fold (fn index => setup (index_binding index binding) index) [NONE, SOME true, SOME false];
+
+
 (* print mode *)
 
 val latexN = "latex";
 
 fun latex_output str =
   let val syms = Symbol.explode str
   in (output_symbols syms, length_symbols syms) end;
 
 fun latex_markup (s, _: Properties.T) =
   if s = Markup.commandN orelse s = Markup.keyword1N orelse s = Markup.keyword3N
   then ("\\isacommand{", "}")
   else if s = Markup.keyword2N
   then ("\\isakeyword{", "}")
   else Markup.no_output;
 
 fun latex_indent "" _ = ""
   | latex_indent s _ = enclose "\\isaindent{" "}" s;
 
 val _ = Output.add_mode latexN latex_output (prefix Symbol.latex o cartouche);
 val _ = Markup.add_mode latexN latex_markup;
 val _ = Pretty.add_mode latexN latex_indent;
 
 end;
diff --git a/src/Pure/library.ML b/src/Pure/library.ML
--- a/src/Pure/library.ML
+++ b/src/Pure/library.ML
@@ -1,1093 +1,1096 @@
 (*  Title:      Pure/library.ML
     Author:     Lawrence C Paulson, Cambridge University Computer Laboratory
     Author:     Markus Wenzel, TU Muenchen
 
 Basic library: functions, pairs, booleans, lists, integers,
 strings, lists as sets, orders, current directory, misc.
 
 See also General/basics.ML for the most fundamental concepts.
 *)
 
 infixr 0 <<<
 infix 2 ?
 infix 3 o oo ooo oooo
 infix 4 ~~ upto downto
 infix orf andf
 
 signature BASIC_LIBRARY =
 sig
   (*functions*)
   val undefined: 'a -> 'b
   val I: 'a -> 'a
   val K: 'a -> 'b -> 'a
   val curry: ('a * 'b -> 'c) -> 'a -> 'b -> 'c
   val uncurry: ('a -> 'b -> 'c) -> 'a * 'b -> 'c
   val ? : bool * ('a -> 'a) -> 'a -> 'a
   val oo: ('a -> 'b) * ('c -> 'd -> 'a) -> 'c -> 'd -> 'b
   val ooo: ('a -> 'b) * ('c -> 'd -> 'e -> 'a) -> 'c -> 'd -> 'e -> 'b
   val oooo: ('a -> 'b) * ('c -> 'd -> 'e -> 'f -> 'a) -> 'c -> 'd -> 'e -> 'f -> 'b
   val funpow: int -> ('a -> 'a) -> 'a -> 'a
   val funpow_yield: int -> ('a -> 'b * 'a) -> 'a -> 'b list * 'a
 
   (*pairs*)
   val pair: 'a -> 'b -> 'a * 'b
   val rpair: 'a -> 'b -> 'b * 'a
   val fst: 'a * 'b -> 'a
   val snd: 'a * 'b -> 'b
   val eq_fst: ('a * 'c -> bool) -> ('a * 'b) * ('c * 'd) -> bool
   val eq_snd: ('b * 'd -> bool) -> ('a * 'b) * ('c * 'd) -> bool
   val eq_pair: ('a * 'c -> bool) -> ('b * 'd -> bool) -> ('a * 'b) * ('c * 'd) -> bool
   val swap: 'a * 'b -> 'b * 'a
   val apfst: ('a -> 'b) -> 'a * 'c -> 'b * 'c
   val apsnd: ('a -> 'b) -> 'c * 'a -> 'c * 'b
   val apply2: ('a -> 'b) -> 'a * 'a -> 'b * 'b
 
   (*booleans*)
   val equal: ''a -> ''a -> bool
   val not_equal: ''a -> ''a -> bool
   val orf: ('a -> bool) * ('a -> bool) -> 'a -> bool
   val andf: ('a -> bool) * ('a -> bool) -> 'a -> bool
   val exists: ('a -> bool) -> 'a list -> bool
   val forall: ('a -> bool) -> 'a list -> bool
 
   (*lists*)
   val single: 'a -> 'a list
   val the_single: 'a list -> 'a
   val singleton: ('a list -> 'b list) -> 'a -> 'b
   val yield_singleton: ('a list -> 'c -> 'b list * 'c) -> 'a -> 'c -> 'b * 'c
   val perhaps_apply: ('a -> 'a option) list -> 'a -> 'a option
   val perhaps_loop: ('a -> 'a option) -> 'a -> 'a option
   val foldl1: ('a * 'a -> 'a) -> 'a list -> 'a
   val foldr1: ('a * 'a -> 'a) -> 'a list -> 'a
   val eq_list: ('a * 'a -> bool) -> 'a list * 'a list -> bool
   val maps: ('a -> 'b list) -> 'a list -> 'b list
   val filter: ('a -> bool) -> 'a list -> 'a list
   val filter_out: ('a -> bool) -> 'a list -> 'a list
   val map_filter: ('a -> 'b option) -> 'a list -> 'b list
   val take: int -> 'a list -> 'a list
   val drop: int -> 'a list -> 'a list
   val chop: int -> 'a list -> 'a list * 'a list
   val chop_groups: int -> 'a list -> 'a list list
   val nth: 'a list -> int -> 'a
   val nth_list: 'a list list -> int -> 'a list
   val nth_map: int -> ('a -> 'a) -> 'a list -> 'a list
   val nth_drop: int -> 'a list -> 'a list
   val map_index: (int * 'a -> 'b) -> 'a list -> 'b list
   val fold_index: (int * 'a -> 'b -> 'b) -> 'a list -> 'b -> 'b
   val map_range: (int -> 'a) -> int -> 'a list
   val fold_range: (int -> 'a -> 'a) -> int -> 'a -> 'a
   val split_last: 'a list -> 'a list * 'a
   val find_first: ('a -> bool) -> 'a list -> 'a option
   val find_index: ('a -> bool) -> 'a list -> int
   val get_first: ('a -> 'b option) -> 'a list -> 'b option
   val get_index: ('a -> 'b option) -> 'a list -> (int * 'b) option
   val flat: 'a list list -> 'a list
   val unflat: 'a list list -> 'b list -> 'b list list
   val grouped: int -> (('a list -> 'b list) -> 'c list list -> 'd list list) ->
     ('a -> 'b) -> 'c list -> 'd list
   val burrow: ('a list -> 'b list) -> 'a list list -> 'b list list
   val burrow_options: ('a list -> 'b list) -> 'a option list -> 'b option list
   val fold_burrow: ('a list -> 'c -> 'b list * 'd) -> 'a list list -> 'c -> 'b list list * 'd
   val separate: 'a -> 'a list -> 'a list
   val surround: 'a -> 'a list -> 'a list
   val replicate: int -> 'a -> 'a list
   val map_product: ('a -> 'b -> 'c) -> 'a list -> 'b list -> 'c list
   val fold_product: ('a -> 'b -> 'c -> 'c) -> 'a list -> 'b list -> 'c -> 'c
   val map2: ('a -> 'b -> 'c) -> 'a list -> 'b list -> 'c list
   val fold2: ('a -> 'b -> 'c -> 'c) -> 'a list -> 'b list -> 'c -> 'c
   val map_split: ('a -> 'b * 'c) -> 'a list -> 'b list * 'c list
   val zip_options: 'a list -> 'b option list -> ('a * 'b) list
   val ~~ : 'a list * 'b list -> ('a * 'b) list
   val split_list: ('a * 'b) list -> 'a list * 'b list
   val burrow_fst: ('a list -> 'b list) -> ('a * 'c) list -> ('b * 'c) list
   val take_prefix: ('a -> bool) -> 'a list -> 'a list
   val drop_prefix: ('a -> bool) -> 'a list -> 'a list
   val chop_prefix: ('a -> bool) -> 'a list -> 'a list * 'a list
   val take_suffix: ('a -> bool) -> 'a list -> 'a list
   val drop_suffix: ('a -> bool) -> 'a list -> 'a list
   val chop_suffix: ('a -> bool) -> 'a list -> 'a list * 'a list
   val is_prefix: ('a * 'a -> bool) -> 'a list -> 'a list -> bool
   val chop_common_prefix: ('a * 'b -> bool) -> 'a list * 'b list -> 'a list * ('a list * 'b list)
   val prefixes1: 'a list -> 'a list list
   val prefixes: 'a list -> 'a list list
   val suffixes1: 'a list -> 'a list list
   val suffixes: 'a list -> 'a list list
   val trim: ('a -> bool) -> 'a list -> 'a list
 
   (*integers*)
   val upto: int * int -> int list
   val downto: int * int -> int list
   val hex_digit: int -> string
   val radixpand: int * int -> int list
   val radixstring: int * string * int -> string
   val string_of_int: int -> string
   val signed_string_of_int: int -> string
   val string_of_indexname: string * int -> string
   val read_radix_int: int -> string list -> int * string list
   val read_int: string list -> int * string list
   val oct_char: string -> string
 
   (*strings*)
   val nth_string: string -> int -> string
   val fold_string: (string -> 'a -> 'a) -> string -> 'a -> 'a
   val exists_string: (string -> bool) -> string -> bool
   val forall_string: (string -> bool) -> string -> bool
+  val member_string: string -> string -> bool
   val first_field: string -> string -> (string * string) option
   val enclose: string -> string -> string -> string
   val unenclose: string -> string
   val quote: string -> string
   val cartouche: string -> string
   val space_implode: string -> string list -> string
   val commas: string list -> string
   val commas_quote: string list -> string
   val cat_lines: string list -> string
   val space_explode: string -> string -> string list
   val split_lines: string -> string list
   val plain_words: string -> string
   val prefix_lines: string -> string -> string
   val prefix: string -> string -> string
   val suffix: string -> string -> string
   val unprefix: string -> string -> string
   val unsuffix: string -> string -> string
   val trim_line: string -> string
   val trim_split_lines: string -> string list
   val normalize_lines: string -> string
   val replicate_string: int -> string -> string
   val translate_string: (string -> string) -> string -> string
   val encode_lines: string -> string
   val decode_lines: string -> string
   val align_right: string -> int -> string -> string
   val match_string: string -> string -> bool
 
   (*reals*)
   val string_of_real: real -> string
   val signed_string_of_real: real -> string
 
   (*lists as sets -- see also Pure/General/ord_list.ML*)
   val member: ('b * 'a -> bool) -> 'a list -> 'b -> bool
   val insert: ('a * 'a -> bool) -> 'a -> 'a list -> 'a list
   val remove: ('b * 'a -> bool) -> 'b -> 'a list -> 'a list
   val update: ('a * 'a -> bool) -> 'a -> 'a list -> 'a list
   val union: ('a * 'a -> bool) -> 'a list -> 'a list -> 'a list
   val subtract: ('b * 'a -> bool) -> 'b list -> 'a list -> 'a list
   val inter: ('a * 'b -> bool) -> 'b list -> 'a list -> 'a list
   val merge: ('a * 'a -> bool) -> 'a list * 'a list -> 'a list
   val subset: ('a * 'b -> bool) -> 'a list * 'b list -> bool
   val eq_set: ('a * 'a -> bool) -> 'a list * 'a list -> bool
   val distinct: ('a * 'a -> bool) -> 'a list -> 'a list
   val duplicates: ('a * 'a -> bool) -> 'a list -> 'a list
   val has_duplicates: ('a * 'a -> bool) -> 'a list -> bool
   val map_transpose: ('a list -> 'b) -> 'a list list -> 'b list
 
   (*lists as multisets*)
   val remove1: ('b * 'a -> bool) -> 'b -> 'a list -> 'a list
   val combine: ('a * 'a -> bool) -> 'a list -> 'a list -> 'a list
   val submultiset: ('a * 'b -> bool) -> 'a list * 'b list -> bool
 
   (*orders*)
   type 'a ord = 'a * 'a -> order
   val is_equal: order -> bool
   val is_less: order -> bool
   val is_less_equal: order -> bool
   val is_greater: order -> bool
   val is_greater_equal: order -> bool
   val rev_order: order -> order
   val make_ord: ('a * 'a -> bool) -> 'a ord
   val bool_ord: bool ord
   val int_ord: int ord
   val string_ord: string ord
   val fast_string_ord: string ord
   val option_ord: ('a * 'b -> order) -> 'a option * 'b option -> order
   val <<< : ('a -> order) * ('a -> order) -> 'a -> order
   val prod_ord: ('a * 'b -> order) -> ('c * 'd -> order) -> ('a * 'c) * ('b * 'd) -> order
   val dict_ord: ('a * 'b -> order) -> 'a list * 'b list -> order
   val list_ord: ('a * 'b -> order) -> 'a list * 'b list -> order
   val sort: 'a ord -> 'a list -> 'a list
   val sort_distinct: 'a ord -> 'a list -> 'a list
   val sort_strings: string list -> string list
   val sort_by: ('a -> string) -> 'a list -> 'a list
   val tag_list: int -> 'a list -> (int * 'a) list
   val untag_list: (int * 'a) list -> 'a list
   val order_list: (int * 'a) list -> 'a list
 
   (*misc*)
   val divide_and_conquer: ('a -> 'a list * ('b list -> 'b)) -> 'a -> 'b
   val divide_and_conquer': ('a -> 'b -> ('a list * ('c list * 'b -> 'c * 'b)) * 'b) ->
     'a -> 'b -> 'c * 'b
   val partition_eq: ('a * 'a -> bool) -> 'a list -> 'a list list
   val partition_list: (int -> 'a -> bool) -> int -> int -> 'a list -> 'a list list
   type serial = int
   val serial: unit -> serial
   val serial_string: unit -> string
   eqtype stamp
   val stamp: unit -> stamp
   structure Any: sig type T = exn end
   val getenv: string -> string
   val getenv_strict: string -> string
 end;
 
 signature LIBRARY =
 sig
   include BASIC_LIBRARY
   val foldl: ('a * 'b -> 'a) -> 'a * 'b list -> 'a
   val foldr: ('a * 'b -> 'b) -> 'a list * 'b -> 'b
 end;
 
 structure Library: LIBRARY =
 struct
 
 (* functions *)
 
 fun undefined _ = raise Match;
 
 fun I x = x;
 fun K x = fn _ => x;
 fun curry f x y = f (x, y);
 fun uncurry f (x, y) = f x y;
 
 (*conditional application*)
 fun b ? f = fn x => if b then f x else x;
 
 (*composition with multiple args*)
 fun (f oo g) x y = f (g x y);
 fun (f ooo g) x y z = f (g x y z);
 fun (f oooo g) x y z w = f (g x y z w);
 
 (*function exponentiation: f (... (f x) ...) with n applications of f*)
 fun funpow (0: int) _ x = x
   | funpow n f x = funpow (n - 1) f (f x);
 
 fun funpow_yield (0 : int) _ x = ([], x)
   | funpow_yield n f x = x |> f ||>> funpow_yield (n - 1) f |>> op ::;
 
 
 (* pairs *)
 
 fun pair x y = (x, y);
 fun rpair x y = (y, x);
 
 fun fst (x, y) = x;
 fun snd (x, y) = y;
 
 fun eq_fst eq ((x1, _), (x2, _)) = eq (x1, x2);
 fun eq_snd eq ((_, y1), (_, y2)) = eq (y1, y2);
 fun eq_pair eqx eqy ((x1, y1), (x2, y2)) = eqx (x1, x2) andalso eqy (y1, y2);
 
 fun swap (x, y) = (y, x);
 
 fun apfst f (x, y) = (f x, y);
 fun apsnd f (x, y) = (x, f y);
 fun apply2 f (x, y) = (f x, f y);
 
 
 (* booleans *)
 
 (*polymorphic equality*)
 fun equal x y = x = y;
 fun not_equal x y = x <> y;
 
 (*combining predicates*)
 fun p orf q = fn x => p x orelse q x;
 fun p andf q = fn x => p x andalso q x;
 
 val exists = List.exists;
 val forall = List.all;
 
 
 
 (** lists **)
 
 fun single x = [x];
 
 fun the_single [x] = x
   | the_single _ = raise List.Empty;
 
 fun singleton f x = the_single (f [x]);
 
 fun yield_singleton f x = f [x] #>> the_single;
 
 fun perhaps_apply funs arg =
   let
     fun app [] res = res
       | app (f :: fs) (changed, x) =
           (case f x of
             NONE => app fs (changed, x)
           | SOME x' => app fs (true, x'));
   in (case app funs (false, arg) of (false, _) => NONE | (true, arg') => SOME arg') end;
 
 fun perhaps_loop f arg =
   let
     fun loop (changed, x) =
       (case f x of
         NONE => (changed, x)
       | SOME x' => loop (true, x'));
   in (case loop (false, arg) of (false, _) => NONE | (true, arg') => SOME arg') end;
 
 
 (* fold -- old versions *)
 
 (*the following versions of fold are designed to fit nicely with infixes*)
 
 (*  (op @) (e, [x1, ..., xn])  ===>  ((e @ x1) @ x2) ... @ xn
     for operators that associate to the left (TAIL RECURSIVE)*)
 fun foldl (f: 'a * 'b -> 'a) : 'a * 'b list -> 'a =
   let fun itl (e, [])  = e
         | itl (e, a::l) = itl (f(e, a), l)
   in  itl end;
 
 (*  (op @) ([x1, ..., xn], e)  ===>   x1 @ (x2 ... @ (xn @ e))
     for operators that associate to the right (not tail recursive)*)
 fun foldr f (l, e) =
   let fun itr [] = e
         | itr (a::l) = f(a, itr l)
   in  itr l  end;
 
 (*  (op @) [x1, ..., xn]  ===>  ((x1 @ x2) @ x3) ... @ xn
     for operators that associate to the left (TAIL RECURSIVE)*)
 fun foldl1 f [] = raise List.Empty
   | foldl1 f (x :: xs) = foldl f (x, xs);
 
 (*  (op @) [x1, ..., xn]  ===>   x1 @ (x2 ... @ (x[n-1] @ xn))
     for n > 0, operators that associate to the right (not tail recursive)*)
 fun foldr1 f [] = raise List.Empty
   | foldr1 f l =
       let fun itr [x] = x
             | itr (x::l) = f(x, itr l)
       in  itr l  end;
 
 
 (* basic list functions *)
 
 fun eq_list eq (list1, list2) =
   pointer_eq (list1, list2) orelse
     let
       fun eq_lst (x :: xs, y :: ys) = eq (x, y) andalso eq_lst (xs, ys)
         | eq_lst _ = true;
     in length list1 = length list2 andalso eq_lst (list1, list2) end;
 
 fun maps f [] = []
   | maps f (x :: xs) = f x @ maps f xs;
 
 val filter = List.filter;
 fun filter_out f = filter (not o f);
 val map_filter = List.mapPartial;
 
 fun take (0: int) xs = []
   | take _ [] = []
   | take n (x :: xs) = x :: take (n - 1) xs;
 
 fun drop (0: int) xs = xs
   | drop _ [] = []
   | drop n (x :: xs) = drop (n - 1) xs;
 
 fun chop (0: int) xs = ([], xs)
   | chop _ [] = ([], [])
   | chop n (x :: xs) = chop (n - 1) xs |>> cons x;
 
 fun chop_groups n list =
   (case chop (Int.max (n, 1)) list of
     ([], _) => []
   | (g, rest) => g :: chop_groups n rest);
 
 
 (*return nth element of a list, where 0 designates the first element;
   raise Subscript if list too short*)
 fun nth xs i = List.nth (xs, i);
 
 fun nth_list xss i = nth xss i handle General.Subscript => [];
 
 fun nth_map 0 f (x :: xs) = f x :: xs
   | nth_map n f (x :: xs) = x :: nth_map (n - 1) f xs
   | nth_map (_: int) _ [] = raise Subscript;
 
 fun nth_drop n xs =
   List.take (xs, n) @ List.drop (xs, n + 1);
 
 fun map_index f =
   let
     fun map_aux (_: int) [] = []
       | map_aux i (x :: xs) = f (i, x) :: map_aux (i + 1) xs
   in map_aux 0 end;
 
 fun fold_index f =
   let
     fun fold_aux (_: int) [] y = y
       | fold_aux i (x :: xs) y = fold_aux (i + 1) xs (f (i, x) y)
   in fold_aux 0 end;
 
 fun map_range f i =
   let
     fun map_aux (k: int) =
       if k < i then f k :: map_aux (k + 1) else []
   in map_aux 0 end;
 
 fun fold_range f i =
   let
     fun fold_aux (k: int) y =
       if k < i then fold_aux (k + 1) (f k y) else y
   in fold_aux 0 end;
 
 
 (*rear decomposition*)
 fun split_last [] = raise List.Empty
   | split_last [x] = ([], x)
   | split_last (x :: xs) = apfst (cons x) (split_last xs);
 
 (*find first element satisfying predicate*)
 val find_first = List.find;
 
 (*find position of first element satisfying a predicate*)
 fun find_index pred =
   let fun find (_: int) [] = ~1
         | find n (x :: xs) = if pred x then n else find (n + 1) xs;
   in find 0 end;
 
 (*get first element by lookup function*)
 fun get_first _ [] = NONE
   | get_first f (x :: xs) =
       (case f x of
         NONE => get_first f xs
       | some => some);
 
 fun get_index f =
   let
     fun get_aux (_: int) [] = NONE
       | get_aux i (x :: xs) =
           (case f x of
             NONE => get_aux (i + 1) xs
           | SOME y => SOME (i, y))
   in get_aux 0 end;
 
 val flat = List.concat;
 
 fun unflat (xs :: xss) ys =
       let val (ps, qs) = chop (length xs) ys
       in ps :: unflat xss qs end
   | unflat [] [] = []
   | unflat _ _ = raise ListPair.UnequalLengths;
 
 fun grouped n comb f = chop_groups n #> comb (map f) #> flat;
 
 fun burrow f xss = unflat xss (f (flat xss));
 
 fun burrow_options f os = map (try hd) (burrow f (map the_list os));
 
 fun fold_burrow f xss s =
   apfst (unflat xss) (f (flat xss) s);
 
 (*separate s [x1, x2, ..., xn]  ===>  [x1, s, x2, s, ..., s, xn]*)
 fun separate s (x :: (xs as _ :: _)) = x :: s :: separate s xs
   | separate _ xs = xs;
 
 fun surround s (x :: xs) = s :: x :: surround s xs
   | surround s [] = [s];
 
 (*make the list [x, x, ..., x] of length n*)
 fun replicate (n: int) x =
   let fun rep (0, xs) = xs
         | rep (n, xs) = rep (n - 1, x :: xs)
   in
     if n < 0 then raise Subscript
     else rep (n, [])
   end;
 
 
 (* direct product *)
 
 fun map_product f _ [] = []
   | map_product f [] _ = []
   | map_product f (x :: xs) ys = map (f x) ys @ map_product f xs ys;
 
 fun fold_product f _ [] z = z
   | fold_product f [] _ z = z
   | fold_product f (x :: xs) ys z = z |> fold (f x) ys |> fold_product f xs ys;
 
 
 (* lists of pairs *)
 
 fun map2 _ [] [] = []
   | map2 f (x :: xs) (y :: ys) = f x y :: map2 f xs ys
   | map2 _ _ _ = raise ListPair.UnequalLengths;
 
 fun fold2 _ [] [] z = z
   | fold2 f (x :: xs) (y :: ys) z = fold2 f xs ys (f x y z)
   | fold2 _ _ _ _ = raise ListPair.UnequalLengths;
 
 fun map_split _ [] = ([], [])
   | map_split f (x :: xs) =
       let
         val (y, w) = f x;
         val (ys, ws) = map_split f xs;
       in (y :: ys, w :: ws) end;
 
 fun zip_options (x :: xs) (SOME y :: ys) = (x, y) :: zip_options xs ys
   | zip_options (_ :: xs) (NONE :: ys) = zip_options xs ys
   | zip_options _ [] = []
   | zip_options [] _ = raise ListPair.UnequalLengths;
 
 (*combine two lists forming a list of pairs:
   [x1, ..., xn] ~~ [y1, ..., yn]  ===>  [(x1, y1), ..., (xn, yn)]*)
 fun [] ~~ [] = []
   | (x :: xs) ~~ (y :: ys) = (x, y) :: (xs ~~ ys)
   | _ ~~ _ = raise ListPair.UnequalLengths;
 
 (*inverse of ~~; the old 'split':
   [(x1, y1), ..., (xn, yn)]  ===>  ([x1, ..., xn], [y1, ..., yn])*)
 val split_list = ListPair.unzip;
 
 fun burrow_fst f xs = split_list xs |>> f |> op ~~;
 
 
 (* take, drop, chop, trim according to predicate *)
 
 fun take_prefix pred list =
   let
     fun take res (x :: xs) = if pred x then take (x :: res) xs else rev res
       | take res [] = rev res;
   in take [] list end;
 
 fun drop_prefix pred list =
   let
     fun drop (x :: xs) = if pred x then drop xs else x :: xs
       | drop [] = [];
   in drop list end;
 
 fun chop_prefix pred list =
   let
     val prfx = take_prefix pred list;
     val sffx = drop (length prfx) list;
   in (prfx, sffx) end;
 
 fun take_suffix pred list =
   let
     fun take res (x :: xs) = if pred x then take (x :: res) xs else res
       | take res [] = res;
   in take [] (rev list) end;
 
 fun drop_suffix pred list =
   let
     fun drop (x :: xs) = if pred x then drop xs else rev (x :: xs)
       | drop [] = [];
   in drop (rev list) end;
 
 fun chop_suffix pred list =
   let
     val prfx = drop_suffix pred list;
     val sffx = drop (length prfx) list;
   in (prfx, sffx) end;
 
 fun trim pred = drop_prefix pred #> drop_suffix pred;
 
 
 (* prefixes, suffixes *)
 
 fun is_prefix _ [] _ = true
   | is_prefix eq (x :: xs) (y :: ys) = eq (x, y) andalso is_prefix eq xs ys
   | is_prefix eq _ _ = false;
 
 fun chop_common_prefix eq ([], ys) = ([], ([], ys))
   | chop_common_prefix eq (xs, []) = ([], (xs, []))
   | chop_common_prefix eq (xs as x :: xs', ys as y :: ys') =
       if eq (x, y) then
         let val (ps', xys'') = chop_common_prefix eq (xs', ys')
         in (x :: ps', xys'') end
       else ([], (xs, ys));
 
 fun prefixes1 [] = []
   | prefixes1 (x :: xs) = map (cons x) ([] :: prefixes1 xs);
 
 fun prefixes xs = [] :: prefixes1 xs;
 
 fun suffixes1 xs = map rev (prefixes1 (rev xs));
 fun suffixes xs = [] :: suffixes1 xs;
 
 
 
 (** integers **)
 
 (* lists of integers *)
 
 (*make the list [from, from + 1, ..., to]*)
 fun ((i: int) upto j) =
   if i > j then [] else i :: (i + 1 upto j);
 
 (*make the list [from, from - 1, ..., to]*)
 fun ((i: int) downto j) =
   if i < j then [] else i :: (i - 1 downto j);
 
 
 (* convert integers to strings *)
 
 (*hexadecimal*)
 fun hex_digit i =
   if i < 10 then chr (Char.ord #"0" + i) else chr (Char.ord #"a" + i - 10);
 
 (*expand the number in the given base;
   example: radixpand (2, 8) gives [1, 0, 0, 0]*)
 fun radixpand (base, num) : int list =
   let
     fun radix (n, tail) =
       if n < base then n :: tail
       else radix (n div base, (n mod base) :: tail)
   in radix (num, []) end;
 
 (*expands a number into a string of characters starting from "zerochar";
   example: radixstring (2, "0", 8) gives "1000"*)
 fun radixstring (base, zerochar, num) =
   let val offset = ord zerochar;
       fun chrof n = chr (offset + n)
   in implode (map chrof (radixpand (base, num))) end;
 
 
 local
   val zero = Char.ord #"0";
   val small_int = 10000: int;
   val small_int_table = Vector.tabulate (small_int, Int.toString);
 in
 
 fun string_of_int i =
   if i < 0 then Int.toString i
   else if i < 10 then chr (zero + i)
   else if i < small_int then Vector.sub (small_int_table, i)
   else Int.toString i;
 
 end;
 
 fun signed_string_of_int i =
   if i < 0 then "-" ^ string_of_int (~ i) else string_of_int i;
 
 fun string_of_indexname (a, 0) = a
   | string_of_indexname (a, i) = a ^ "_" ^ string_of_int i;
 
 
 (* read integers *)
 
 fun read_radix_int radix cs =
   let
     val zero = Char.ord #"0";
     val limit = zero + radix;
     fun scan (num, []) = (num, [])
       | scan (num, c :: cs) =
           if zero <= ord c andalso ord c < limit then
             scan (radix * num + (ord c - zero), cs)
           else (num, c :: cs);
   in scan (0, cs) end;
 
 val read_int = read_radix_int 10;
 
 fun oct_char s = chr (#1 (read_radix_int 8 (raw_explode s)));
 
 
 
 (** strings **)
 
 (* functions tuned for strings, avoiding explode *)
 
 fun nth_string str i =
   (case try String.substring (str, i, 1) of
     SOME s => s
   | NONE => raise Subscript);
 
 fun fold_string f str x0 =
   let
     val n = size str;
     fun iter (x, i) =
       if i < n then iter (f (String.substring (str, i, 1)) x, i + 1) else x;
   in iter (x0, 0) end;
 
 fun exists_string pred str =
   let
     val n = size str;
     fun ex i = i < n andalso (pred (String.substring (str, i, 1)) orelse ex (i + 1));
   in ex 0 end;
 
 fun forall_string pred = not o exists_string (not o pred);
 
+fun member_string str s = exists_string (fn s' => s = s') str;
+
 fun first_field sep str =
   let
     val n = size sep;
     val len = size str;
     fun find i =
       if i + n > len then NONE
       else if String.substring (str, i, n) = sep then SOME i
       else find (i + 1);
   in
     (case find 0 of
       NONE => NONE
     | SOME i => SOME (String.substring (str, 0, i), String.extract (str, i + n, NONE)))
   end;
 
 (*enclose in brackets*)
 fun enclose lpar rpar str = lpar ^ str ^ rpar;
 fun unenclose str = String.substring (str, 1, size str - 2);
 
 (*simple quoting (does not escape special chars)*)
 val quote = enclose "\"" "\"";
 
 val cartouche = enclose "\<open>" "\<close>";
 
 val space_implode = String.concatWith;
 
 val commas = space_implode ", ";
 val commas_quote = commas o map quote;
 
 val cat_lines = space_implode "\n";
 
 (*space_explode "." "h.e..l.lo" = ["h", "e", "", "l", "lo"]*)
 fun space_explode _ "" = []
   | space_explode sep s = String.fields (fn c => str c = sep) s;
 
 val split_lines = space_explode "\n";
 
 fun plain_words s = space_explode "_" s |> space_implode " ";
 
 fun prefix_lines "" txt = txt
   | prefix_lines prfx txt = txt |> split_lines |> map (fn s => prfx ^ s) |> cat_lines;
 
 fun prefix prfx s = prfx ^ s;
 fun suffix sffx s = s ^ sffx;
 
 fun unprefix prfx s =
   if String.isPrefix prfx s then String.substring (s, size prfx, size s - size prfx)
   else raise Fail "unprefix";
 
 fun unsuffix sffx s =
   if String.isSuffix sffx s then String.substring (s, 0, size s - size sffx)
   else raise Fail "unsuffix";
 
 fun trim_line s =
   if String.isSuffix "\r\n" s
   then String.substring (s, 0, size s - 2)
   else if String.isSuffix "\r" s orelse String.isSuffix "\n" s
   then String.substring (s, 0, size s - 1)
   else s;
 
 val trim_split_lines = trim_line #> split_lines #> map trim_line;
 
 fun normalize_lines str =
   if exists_string (fn s => s = "\r") str then
     split_lines str |> map trim_line |> cat_lines
   else str;
 
 fun replicate_string (0: int) _ = ""
   | replicate_string 1 a = a
   | replicate_string k a =
       if k mod 2 = 0 then replicate_string (k div 2) (a ^ a)
       else replicate_string (k div 2) (a ^ a) ^ a;
 
 fun translate_string f = String.translate (f o String.str);
 
 val encode_lines = translate_string (fn "\n" => "\v" | c => c);
 val decode_lines = translate_string (fn "\v" => "\n" | c => c);
 
 fun align_right c k s =
   let
     val _ = if size c <> 1 orelse size s > k
       then raise Fail "align_right" else ()
   in replicate_string (k - size s) c ^ s end;
 
 (*crude matching of str against simple glob pat*)
 fun match_string pat str =
   let
     fun match [] _ = true
       | match (p :: ps) s =
           size p <= size s andalso
             (case try (unprefix p) s of
               SOME s' => match ps s'
             | NONE => match (p :: ps) (String.substring (s, 1, size s - 1)));
   in match (space_explode "*" pat) str end;
 
 
 
 (** reals **)
 
 val string_of_real = Real.fmt (StringCvt.GEN NONE);
 
 fun signed_string_of_real x =
   if x < 0.0 then "-" ^ string_of_real (~ x) else string_of_real x;
 
 
 
 (** lists as sets -- see also Pure/General/ord_list.ML **)
 
 (* canonical operations *)
 
 fun member eq list x =
   let
     fun memb [] = false
       | memb (y :: ys) = eq (x, y) orelse memb ys;
   in memb list end;
 
 fun insert eq x xs = if member eq xs x then xs else x :: xs;
 fun remove eq x xs = if member eq xs x then filter_out (fn y => eq (x, y)) xs else xs;
 fun update eq x xs = cons x (remove eq x xs);
 
 fun inter eq xs = filter (member eq xs);
 
 fun union eq = fold (insert eq);
 fun subtract eq = fold (remove eq);
 
 fun merge eq (xs, ys) =
   if pointer_eq (xs, ys) then xs
   else if null xs then ys
   else fold_rev (insert eq) ys xs;
 
 
 (* subset and set equality *)
 
 fun subset eq (xs, ys) = forall (member eq ys) xs;
 
 fun eq_set eq (xs, ys) =
   eq_list eq (xs, ys) orelse
     (subset eq (xs, ys) andalso subset (eq o swap) (ys, xs));
 
 
 (*makes a list of the distinct members of the input; preserves order, takes
   first of equal elements*)
 fun distinct eq lst =
   let
     fun dist (rev_seen, []) = rev rev_seen
       | dist (rev_seen, x :: xs) =
           if member eq rev_seen x then dist (rev_seen, xs)
           else dist (x :: rev_seen, xs);
   in dist ([], lst) end;
 
 (*returns a list containing all repeated elements exactly once; preserves
   order, takes first of equal elements*)
 fun duplicates eq lst =
   let
     fun dups (rev_dups, []) = rev rev_dups
       | dups (rev_dups, x :: xs) =
           if member eq rev_dups x orelse not (member eq xs x) then
             dups (rev_dups, xs)
           else dups (x :: rev_dups, xs);
   in dups ([], lst) end;
 
 fun has_duplicates eq =
   let
     fun dups [] = false
       | dups (x :: xs) = member eq xs x orelse dups xs;
   in dups end;
 
 
 (* matrices *)
 
 fun map_transpose f xss =
   let
     val n =
       (case distinct (op =) (map length xss) of
         [] => 0
       | [n] => n
       | _ => raise ListPair.UnequalLengths);
   in map_range (fn m => f (map (fn xs => nth xs m) xss)) n end;
 
 
 
 (** lists as multisets **)
 
 fun remove1 eq x [] = []
   | remove1 eq x (y :: ys) = if eq (x, y) then ys else y :: remove1 eq x ys;
 
 fun combine eq xs ys = fold (remove1 eq) ys xs @ ys;
 
 fun submultiset _ ([], _)  = true
   | submultiset eq (x :: xs, ys) = member eq ys x andalso submultiset eq (xs, remove1 eq x ys);
 
 
 
 (** orders **)
 
 type 'a ord = 'a * 'a -> order;
 
 fun is_equal ord = ord = EQUAL;
 fun is_less ord = ord = LESS;
 fun is_less_equal ord = ord = LESS orelse ord = EQUAL;
 fun is_greater ord = ord = GREATER;
 fun is_greater_equal ord = ord = GREATER orelse ord = EQUAL;
 
 fun rev_order LESS = GREATER
   | rev_order EQUAL = EQUAL
   | rev_order GREATER = LESS;
 
 (*compose orders*)
 fun (a_ord <<< b_ord) p = (case a_ord p of EQUAL => b_ord p | ord => ord);
 
 (*assume rel is a linear strict order*)
 fun make_ord rel (x, y) =
   if rel (x, y) then LESS
   else if rel (y, x) then GREATER
   else EQUAL;
 
 fun bool_ord (false, true) = LESS
   | bool_ord (true, false) = GREATER
   | bool_ord _ = EQUAL;
 
 val int_ord = Int.compare;
 val string_ord = String.compare;
 
 fun fast_string_ord (s1, s2) =
   if pointer_eq (s1, s2) then EQUAL
   else (case int_ord (size s1, size s2) of EQUAL => string_ord (s1, s2) | ord => ord);
 
 fun option_ord ord (SOME x, SOME y) = ord (x, y)
   | option_ord _ (NONE, NONE) = EQUAL
   | option_ord _ (NONE, SOME _) = LESS
   | option_ord _ (SOME _, NONE) = GREATER;
 
 (*lexicographic product*)
 fun prod_ord a_ord b_ord ((x, y), (x', y')) =
   (case a_ord (x, x') of EQUAL => b_ord (y, y') | ord => ord);
 
 (*dictionary order -- in general NOT well-founded!*)
 fun dict_ord elem_ord (x :: xs, y :: ys) =
       (case elem_ord (x, y) of EQUAL => dict_ord elem_ord (xs, ys) | ord => ord)
   | dict_ord _ ([], []) = EQUAL
   | dict_ord _ ([], _ :: _) = LESS
   | dict_ord _ (_ :: _, []) = GREATER;
 
 (*lexicographic product of lists*)
 fun list_ord elem_ord (xs, ys) =
   (case int_ord (length xs, length ys) of EQUAL => dict_ord elem_ord (xs, ys) | ord => ord);
 
 
 (* sorting *)
 
 (*stable mergesort -- preserves order of equal elements*)
 fun mergesort unique ord =
   let
     fun merge (xs as x :: xs') (ys as y :: ys') =
           (case ord (x, y) of
             LESS => x :: merge xs' ys
           | EQUAL =>
               if unique then merge xs ys'
               else x :: merge xs' ys
           | GREATER => y :: merge xs ys')
       | merge [] ys = ys
       | merge xs [] = xs;
 
     fun merge_all [xs] = xs
       | merge_all xss = merge_all (merge_pairs xss)
     and merge_pairs (xs :: ys :: xss) = merge xs ys :: merge_pairs xss
       | merge_pairs xss = xss;
 
     fun runs (x :: y :: xs) =
           (case ord (x, y) of
              LESS => ascending y [x] xs
            | EQUAL =>
                if unique then runs (x :: xs)
                else ascending y [x] xs
            | GREATER => descending y [x] xs)
       | runs xs = [xs]
 
     and ascending x xs (zs as y :: ys) =
           (case ord (x, y) of
              LESS => ascending y (x :: xs) ys
            | EQUAL =>
                if unique then ascending x xs ys
                else ascending y (x :: xs) ys
            | GREATER => rev (x :: xs) :: runs zs)
       | ascending x xs [] = [rev (x :: xs)]
 
     and descending x xs (zs as y :: ys) =
           (case ord (x, y) of
              GREATER => descending y (x :: xs) ys
            | EQUAL =>
                if unique then descending x xs ys
                else (x :: xs) :: runs zs
            | LESS => (x :: xs) :: runs zs)
       | descending x xs [] = [x :: xs];
 
   in merge_all o runs end;
 
 fun sort ord = mergesort false ord;
 fun sort_distinct ord = mergesort true ord;
 
 val sort_strings = sort string_ord;
 fun sort_by key xs = sort (string_ord o apply2 key) xs;
 
 
 (* items tagged by integer index *)
 
 (*insert tags*)
 fun tag_list k [] = []
   | tag_list k (x :: xs) = (k:int, x) :: tag_list (k + 1) xs;
 
 (*remove tags and suppress duplicates -- list is assumed sorted!*)
 fun untag_list [] = []
   | untag_list [(k: int, x)] = [x]
   | untag_list ((k, x) :: (rest as (k', x') :: _)) =
       if k = k' then untag_list rest
       else x :: untag_list rest;
 
 (*return list elements in original order*)
 fun order_list list = untag_list (sort (int_ord o apply2 fst) list);
 
 
 
 (** misc **)
 
 fun divide_and_conquer decomp x =
   let val (ys, recomb) = decomp x
   in recomb (map (divide_and_conquer decomp) ys) end;
 
 fun divide_and_conquer' decomp x s =
   let val ((ys, recomb), s') = decomp x s
   in recomb (fold_map (divide_and_conquer' decomp) ys s') end;
 
 
 (*Partition a list into buckets  [ bi, b(i+1), ..., bj ]
    putting x in bk if p(k)(x) holds.  Preserve order of elements if possible.*)
 fun partition_list p i j =
   let
     fun part (k: int) xs =
       if k > j then
         (case xs of
           [] => []
         | _ => raise Fail "partition_list")
       else
         let val (ns, rest) = List.partition (p k) xs
         in ns :: part (k + 1) rest end;
   in part (i: int) end;
 
 fun partition_eq (eq: 'a * 'a -> bool) =
   let
     fun part [] = []
       | part (x :: ys) =
           let val (xs, xs') = List.partition (fn y => eq (x, y)) ys
           in (x :: xs) :: part xs' end;
   in part end;
 
 
 (* serial numbers and abstract stamps *)
 
 type serial = int;
 val serial = Counter.make ();
 val serial_string = string_of_int o serial;
 
 datatype stamp = Stamp of serial;
 fun stamp () = Stamp (serial ());
 
 
 (* values of any type *)
 
 (*note that the builtin exception datatype may be extended by new
   constructors at any time*)
 structure Any = struct type T = exn end;
 
 
 (* getenv *)
 
 fun getenv x =
   (case OS.Process.getEnv x of
     NONE => ""
   | SOME y => y);
 
 fun getenv_strict x =
   (case getenv x of
     "" => error ("Undefined Isabelle environment variable: " ^ quote x)
   | y => y);
 
 end;
 
 structure Basic_Library: BASIC_LIBRARY = Library;
 open Basic_Library;