src/Doc/Isar_Ref/Generic.thy
author wenzelm
Mon Oct 09 21:12:22 2017 +0200 (23 months ago)
changeset 66822 4642cf4a7ebb
parent 63821 52235c27538c
child 67399 eab6ce8368fa
permissions -rw-r--r--
tuned signature;
     1 (*:maxLineLen=78:*)
     2 
     3 theory Generic
     4 imports Main Base
     5 begin
     6 
     7 chapter \<open>Generic tools and packages \label{ch:gen-tools}\<close>
     8 
     9 section \<open>Configuration options \label{sec:config}\<close>
    10 
    11 text \<open>
    12   Isabelle/Pure maintains a record of named configuration options within the
    13   theory or proof context, with values of type @{ML_type bool}, @{ML_type
    14   int}, @{ML_type real}, or @{ML_type string}. Tools may declare options in
    15   ML, and then refer to these values (relative to the context). Thus global
    16   reference variables are easily avoided. The user may change the value of a
    17   configuration option by means of an associated attribute of the same name.
    18   This form of context declaration works particularly well with commands such
    19   as @{command "declare"} or @{command "using"} like this:
    20 \<close>
    21 
    22 (*<*)experiment begin(*>*)
    23 declare [[show_main_goal = false]]
    24 
    25 notepad
    26 begin
    27   note [[show_main_goal = true]]
    28 end
    29 (*<*)end(*>*)
    30 
    31 text \<open>
    32   \begin{matharray}{rcll}
    33     @{command_def "print_options"} & : & \<open>context \<rightarrow>\<close> \\
    34   \end{matharray}
    35 
    36   @{rail \<open>
    37     @@{command print_options} ('!'?)
    38     ;
    39     @{syntax name} ('=' ('true' | 'false' | @{syntax int} | @{syntax float} | @{syntax name}))?
    40   \<close>}
    41 
    42   \<^descr> @{command "print_options"} prints the available configuration options,
    43   with names, types, and current values; the ``\<open>!\<close>'' option indicates extra
    44   verbosity.
    45   
    46   \<^descr> \<open>name = value\<close> as an attribute expression modifies the named option, with
    47   the syntax of the value depending on the option's type. For @{ML_type bool}
    48   the default value is \<open>true\<close>. Any attempt to change a global option in a
    49   local context is ignored.
    50 \<close>
    51 
    52 
    53 section \<open>Basic proof tools\<close>
    54 
    55 subsection \<open>Miscellaneous methods and attributes \label{sec:misc-meth-att}\<close>
    56 
    57 text \<open>
    58   \begin{matharray}{rcl}
    59     @{method_def unfold} & : & \<open>method\<close> \\
    60     @{method_def fold} & : & \<open>method\<close> \\
    61     @{method_def insert} & : & \<open>method\<close> \\[0.5ex]
    62     @{method_def erule}\<open>\<^sup>*\<close> & : & \<open>method\<close> \\
    63     @{method_def drule}\<open>\<^sup>*\<close> & : & \<open>method\<close> \\
    64     @{method_def frule}\<open>\<^sup>*\<close> & : & \<open>method\<close> \\
    65     @{method_def intro} & : & \<open>method\<close> \\
    66     @{method_def elim} & : & \<open>method\<close> \\
    67     @{method_def fail} & : & \<open>method\<close> \\
    68     @{method_def succeed} & : & \<open>method\<close> \\
    69     @{method_def sleep} & : & \<open>method\<close> \\
    70   \end{matharray}
    71 
    72   @{rail \<open>
    73     (@@{method fold} | @@{method unfold} | @@{method insert}) @{syntax thms}
    74     ;
    75     (@@{method erule} | @@{method drule} | @@{method frule})
    76       ('(' @{syntax nat} ')')? @{syntax thms}
    77     ;
    78     (@@{method intro} | @@{method elim}) @{syntax thms}?
    79     ;
    80     @@{method sleep} @{syntax real}
    81   \<close>}
    82 
    83   \<^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
    84   fold back) the given definitions throughout all goals; any chained facts
    85   provided are inserted into the goal and subject to rewriting as well.
    86 
    87   Unfolding works in two stages: first, the given equations are used directly
    88   for rewriting; second, the equations are passed through the attribute
    89   @{attribute_ref abs_def} before rewriting --- to ensure that definitions are
    90   fully expanded, regardless of the actual parameters that are provided.
    91 
    92   \<^descr> @{method insert}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> inserts theorems as facts into all goals of
    93   the proof state. Note that current facts indicated for forward chaining are
    94   ignored.
    95 
    96   \<^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
    97   frule}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> are similar to the basic @{method rule} method (see
    98   \secref{sec:pure-meth-att}), but apply rules by elim-resolution,
    99   destruct-resolution, and forward-resolution, respectively @{cite
   100   "isabelle-implementation"}. The optional natural number argument (default 0)
   101   specifies additional assumption steps to be performed here.
   102 
   103   Note that these methods are improper ones, mainly serving for
   104   experimentation and tactic script emulation. Different modes of basic rule
   105   application are usually expressed in Isar at the proof language level,
   106   rather than via implicit proof state manipulations. For example, a proper
   107   single-step elimination would be done using the plain @{method rule} method,
   108   with forward chaining of current facts.
   109 
   110   \<^descr> @{method intro} and @{method elim} repeatedly refine some goal by intro-
   111   or elim-resolution, after having inserted any chained facts. Exactly the
   112   rules given as arguments are taken into account; this allows fine-tuned
   113   decomposition of a proof problem, in contrast to common automated tools.
   114 
   115   \<^descr> @{method fail} yields an empty result sequence; it is the identity of the
   116   ``\<open>|\<close>'' method combinator (cf.\ \secref{sec:proof-meth}).
   117 
   118   \<^descr> @{method succeed} yields a single (unchanged) result; it is the identity
   119   of the ``\<open>,\<close>'' method combinator (cf.\ \secref{sec:proof-meth}).
   120 
   121   \<^descr> @{method sleep}~\<open>s\<close> succeeds after a real-time delay of \<open>s\<close> seconds. This
   122   is occasionally useful for demonstration and testing purposes.
   123 
   124 
   125   \begin{matharray}{rcl}
   126     @{attribute_def tagged} & : & \<open>attribute\<close> \\
   127     @{attribute_def untagged} & : & \<open>attribute\<close> \\[0.5ex]
   128     @{attribute_def THEN} & : & \<open>attribute\<close> \\
   129     @{attribute_def unfolded} & : & \<open>attribute\<close> \\
   130     @{attribute_def folded} & : & \<open>attribute\<close> \\
   131     @{attribute_def abs_def} & : & \<open>attribute\<close> \\[0.5ex]
   132     @{attribute_def rotated} & : & \<open>attribute\<close> \\
   133     @{attribute_def (Pure) elim_format} & : & \<open>attribute\<close> \\
   134     @{attribute_def no_vars}\<open>\<^sup>*\<close> & : & \<open>attribute\<close> \\
   135   \end{matharray}
   136 
   137   @{rail \<open>
   138     @@{attribute tagged} @{syntax name} @{syntax name}
   139     ;
   140     @@{attribute untagged} @{syntax name}
   141     ;
   142     @@{attribute THEN} ('[' @{syntax nat} ']')? @{syntax thm}
   143     ;
   144     (@@{attribute unfolded} | @@{attribute folded}) @{syntax thms}
   145     ;
   146     @@{attribute rotated} @{syntax int}?
   147   \<close>}
   148 
   149   \<^descr> @{attribute tagged}~\<open>name value\<close> and @{attribute untagged}~\<open>name\<close> add and
   150   remove \<^emph>\<open>tags\<close> of some theorem. Tags may be any list of string pairs that
   151   serve as formal comment. The first string is considered the tag name, the
   152   second its value. Note that @{attribute untagged} removes any tags of the
   153   same name.
   154 
   155   \<^descr> @{attribute THEN}~\<open>a\<close> composes rules by resolution; it resolves with the
   156   first premise of \<open>a\<close> (an alternative position may be also specified). See
   157   also @{ML_op "RS"} in @{cite "isabelle-implementation"}.
   158   
   159   \<^descr> @{attribute unfolded}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> and @{attribute folded}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close>
   160   expand and fold back again the given definitions throughout a rule.
   161 
   162   \<^descr> @{attribute abs_def} turns an equation of the form @{prop "f x y \<equiv> t"}
   163   into @{prop "f \<equiv> \<lambda>x y. t"}, which ensures that @{method simp} steps always
   164   expand it. This also works for object-logic equality.
   165 
   166   \<^descr> @{attribute rotated}~\<open>n\<close> rotate the premises of a theorem by \<open>n\<close> (default
   167   1).
   168 
   169   \<^descr> @{attribute (Pure) elim_format} turns a destruction rule into elimination
   170   rule format, by resolving with the rule @{prop "PROP A \<Longrightarrow> (PROP A \<Longrightarrow> PROP B) \<Longrightarrow>
   171   PROP B"}.
   172   
   173   Note that the Classical Reasoner (\secref{sec:classical}) provides its own
   174   version of this operation.
   175 
   176   \<^descr> @{attribute no_vars} replaces schematic variables by free ones; this is
   177   mainly for tuning output of pretty printed theorems.
   178 \<close>
   179 
   180 
   181 subsection \<open>Low-level equational reasoning\<close>
   182 
   183 text \<open>
   184   \begin{matharray}{rcl}
   185     @{method_def subst} & : & \<open>method\<close> \\
   186     @{method_def hypsubst} & : & \<open>method\<close> \\
   187     @{method_def split} & : & \<open>method\<close> \\
   188   \end{matharray}
   189 
   190   @{rail \<open>
   191     @@{method subst} ('(' 'asm' ')')? \<newline> ('(' (@{syntax nat}+) ')')? @{syntax thm}
   192     ;
   193     @@{method split} @{syntax thms}
   194   \<close>}
   195 
   196   These methods provide low-level facilities for equational reasoning that are
   197   intended for specialized applications only. Normally, single step
   198   calculations would be performed in a structured text (see also
   199   \secref{sec:calculation}), while the Simplifier methods provide the
   200   canonical way for automated normalization (see \secref{sec:simplifier}).
   201 
   202   \<^descr> @{method subst}~\<open>eq\<close> performs a single substitution step using rule \<open>eq\<close>,
   203   which may be either a meta or object equality.
   204 
   205   \<^descr> @{method subst}~\<open>(asm) eq\<close> substitutes in an assumption.
   206 
   207   \<^descr> @{method subst}~\<open>(i \<dots> j) eq\<close> performs several substitutions in the
   208   conclusion. The numbers \<open>i\<close> to \<open>j\<close> indicate the positions to substitute at.
   209   Positions are ordered from the top of the term tree moving down from left to
   210   right. For example, in \<open>(a + b) + (c + d)\<close> there are three positions where
   211   commutativity of \<open>+\<close> is applicable: 1 refers to \<open>a + b\<close>, 2 to the whole
   212   term, and 3 to \<open>c + d\<close>.
   213 
   214   If the positions in the list \<open>(i \<dots> j)\<close> are non-overlapping (e.g.\ \<open>(2 3)\<close> in
   215   \<open>(a + b) + (c + d)\<close>) you may assume all substitutions are performed
   216   simultaneously. Otherwise the behaviour of \<open>subst\<close> is not specified.
   217 
   218   \<^descr> @{method subst}~\<open>(asm) (i \<dots> j) eq\<close> performs the substitutions in the
   219   assumptions. The positions refer to the assumptions in order from left to
   220   right. For example, given in a goal of the form \<open>P (a + b) \<Longrightarrow> P (c + d) \<Longrightarrow> \<dots>\<close>,
   221   position 1 of commutativity of \<open>+\<close> is the subterm \<open>a + b\<close> and position 2 is
   222   the subterm \<open>c + d\<close>.
   223 
   224   \<^descr> @{method hypsubst} performs substitution using some assumption; this only
   225   works for equations of the form \<open>x = t\<close> where \<open>x\<close> is a free or bound
   226   variable.
   227 
   228   \<^descr> @{method split}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> performs single-step case splitting using the
   229   given rules. Splitting is performed in the conclusion or some assumption of
   230   the subgoal, depending of the structure of the rule.
   231   
   232   Note that the @{method simp} method already involves repeated application of
   233   split rules as declared in the current context, using @{attribute split},
   234   for example.
   235 \<close>
   236 
   237 
   238 section \<open>The Simplifier \label{sec:simplifier}\<close>
   239 
   240 text \<open>
   241   The Simplifier performs conditional and unconditional rewriting and uses
   242   contextual information: rule declarations in the background theory or local
   243   proof context are taken into account, as well as chained facts and subgoal
   244   premises (``local assumptions''). There are several general hooks that allow
   245   to modify the simplification strategy, or incorporate other proof tools that
   246   solve sub-problems, produce rewrite rules on demand etc.
   247 
   248   The rewriting strategy is always strictly bottom up, except for congruence
   249   rules, which are applied while descending into a term. Conditions in
   250   conditional rewrite rules are solved recursively before the rewrite rule is
   251   applied.
   252 
   253   The default Simplifier setup of major object logics (HOL, HOLCF, FOL, ZF)
   254   makes the Simplifier ready for immediate use, without engaging into the
   255   internal structures. Thus it serves as general-purpose proof tool with the
   256   main focus on equational reasoning, and a bit more than that.
   257 \<close>
   258 
   259 
   260 subsection \<open>Simplification methods \label{sec:simp-meth}\<close>
   261 
   262 text \<open>
   263   \begin{tabular}{rcll}
   264     @{method_def simp} & : & \<open>method\<close> \\
   265     @{method_def simp_all} & : & \<open>method\<close> \\
   266     \<open>Pure.\<close>@{method_def (Pure) simp} & : & \<open>method\<close> \\
   267     \<open>Pure.\<close>@{method_def (Pure) simp_all} & : & \<open>method\<close> \\
   268     @{attribute_def simp_depth_limit} & : & \<open>attribute\<close> & default \<open>100\<close> \\
   269   \end{tabular}
   270   \<^medskip>
   271 
   272   @{rail \<open>
   273     (@@{method simp} | @@{method simp_all}) opt? (@{syntax simpmod} * )
   274     ;
   275 
   276     opt: '(' ('no_asm' | 'no_asm_simp' | 'no_asm_use' | 'asm_lr' ) ')'
   277     ;
   278     @{syntax_def simpmod}: ('add' | 'del' | 'only' | 'split' (() | '!' | 'del') |
   279       'cong' (() | 'add' | 'del')) ':' @{syntax thms}
   280   \<close>}
   281 
   282   \<^descr> @{method simp} invokes the Simplifier on the first subgoal, after
   283   inserting chained facts as additional goal premises; further rule
   284   declarations may be included via \<open>(simp add: facts)\<close>. The proof method fails
   285   if the subgoal remains unchanged after simplification.
   286 
   287   Note that the original goal premises and chained facts are subject to
   288   simplification themselves, while declarations via \<open>add\<close>/\<open>del\<close> merely follow
   289   the policies of the object-logic to extract rewrite rules from theorems,
   290   without further simplification. This may lead to slightly different behavior
   291   in either case, which might be required precisely like that in some boundary
   292   situations to perform the intended simplification step!
   293 
   294   \<^medskip>
   295   The \<open>only\<close> modifier first removes all other rewrite rules, looper tactics
   296   (including split rules), congruence rules, and then behaves like \<open>add\<close>.
   297   Implicit solvers remain, which means that trivial rules like reflexivity or
   298   introduction of \<open>True\<close> are available to solve the simplified subgoals, but
   299   also non-trivial tools like linear arithmetic in HOL. The latter may lead to
   300   some surprise of the meaning of ``only'' in Isabelle/HOL compared to
   301   English!
   302 
   303   \<^medskip>
   304   The \<open>split\<close> modifiers add or delete rules for the Splitter (see also
   305   \secref{sec:simp-strategies} on the looper). This works only if the
   306   Simplifier method has been properly setup to include the Splitter (all major
   307   object logics such HOL, HOLCF, FOL, ZF do this already).
   308   The \<open>!\<close> option causes the split rules to be used aggressively:
   309   after each application of a split rule in the conclusion, the \<open>safe\<close>
   310   tactic of the classical reasoner (see \secref{sec:classical:partial})
   311   is applied to the new goal. The net effect is that the goal is split into
   312   the different cases. This option can speed up simplification of goals
   313   with many nested conditional or case expressions significantly.
   314 
   315   There is also a separate @{method_ref split} method available for
   316   single-step case splitting. The effect of repeatedly applying \<open>(split thms)\<close>
   317   can be imitated by ``\<open>(simp only: split: thms)\<close>''.
   318 
   319   \<^medskip>
   320   The \<open>cong\<close> modifiers add or delete Simplifier congruence rules (see also
   321   \secref{sec:simp-rules}); the default is to add.
   322 
   323   \<^descr> @{method simp_all} is similar to @{method simp}, but acts on all goals,
   324   working backwards from the last to the first one as usual in Isabelle.\<^footnote>\<open>The
   325   order is irrelevant for goals without schematic variables, so simplification
   326   might actually be performed in parallel here.\<close>
   327 
   328   Chained facts are inserted into all subgoals, before the simplification
   329   process starts. Further rule declarations are the same as for @{method
   330   simp}.
   331 
   332   The proof method fails if all subgoals remain unchanged after
   333   simplification.
   334 
   335   \<^descr> @{attribute simp_depth_limit} limits the number of recursive invocations
   336   of the Simplifier during conditional rewriting.
   337 
   338 
   339   By default the Simplifier methods above take local assumptions fully into
   340   account, using equational assumptions in the subsequent normalization
   341   process, or simplifying assumptions themselves. Further options allow to
   342   fine-tune the behavior of the Simplifier in this respect, corresponding to a
   343   variety of ML tactics as follows.\<^footnote>\<open>Unlike the corresponding Isar proof
   344   methods, the ML tactics do not insist in changing the goal state.\<close>
   345 
   346   \begin{center}
   347   \small
   348   \begin{tabular}{|l|l|p{0.3\textwidth}|}
   349   \hline
   350   Isar method & ML tactic & behavior \\\hline
   351 
   352   \<open>(simp (no_asm))\<close> & @{ML simp_tac} & assumptions are ignored completely
   353   \\\hline
   354 
   355   \<open>(simp (no_asm_simp))\<close> & @{ML asm_simp_tac} & assumptions are used in the
   356   simplification of the conclusion but are not themselves simplified \\\hline
   357 
   358   \<open>(simp (no_asm_use))\<close> & @{ML full_simp_tac} & assumptions are simplified but
   359   are not used in the simplification of each other or the conclusion \\\hline
   360 
   361   \<open>(simp)\<close> & @{ML asm_full_simp_tac} & assumptions are used in the
   362   simplification of the conclusion and to simplify other assumptions \\\hline
   363 
   364   \<open>(simp (asm_lr))\<close> & @{ML asm_lr_simp_tac} & compatibility mode: an
   365   assumption is only used for simplifying assumptions which are to the right
   366   of it \\\hline
   367 
   368   \end{tabular}
   369   \end{center}
   370 
   371   \<^medskip>
   372   In Isabelle/Pure, proof methods @{method (Pure) simp} and @{method (Pure)
   373   simp_all} only know about meta-equality \<open>\<equiv>\<close>. Any new object-logic needs to
   374   re-define these methods via @{ML Simplifier.method_setup} in ML:
   375   Isabelle/FOL or Isabelle/HOL may serve as blue-prints.
   376 \<close>
   377 
   378 
   379 subsubsection \<open>Examples\<close>
   380 
   381 text \<open>
   382   We consider basic algebraic simplifications in Isabelle/HOL. The rather
   383   trivial goal @{prop "0 + (x + 0) = x + 0 + 0"} looks like a good candidate
   384   to be solved by a single call of @{method simp}:
   385 \<close>
   386 
   387 lemma "0 + (x + 0) = x + 0 + 0" apply simp? oops
   388 
   389 text \<open>
   390   The above attempt \<^emph>\<open>fails\<close>, because @{term "0"} and @{term "op +"} in the
   391   HOL library are declared as generic type class operations, without stating
   392   any algebraic laws yet. More specific types are required to get access to
   393   certain standard simplifications of the theory context, e.g.\ like this:\<close>
   394 
   395 lemma fixes x :: nat shows "0 + (x + 0) = x + 0 + 0" by simp
   396 lemma fixes x :: int shows "0 + (x + 0) = x + 0 + 0" by simp
   397 lemma fixes x :: "'a :: monoid_add" shows "0 + (x + 0) = x + 0 + 0" by simp
   398 
   399 text \<open>
   400   \<^medskip>
   401   In many cases, assumptions of a subgoal are also needed in the
   402   simplification process. For example:
   403 \<close>
   404 
   405 lemma fixes x :: nat shows "x = 0 \<Longrightarrow> x + x = 0" by simp
   406 lemma fixes x :: nat assumes "x = 0" shows "x + x = 0" apply simp oops
   407 lemma fixes x :: nat assumes "x = 0" shows "x + x = 0" using assms by simp
   408 
   409 text \<open>
   410   As seen above, local assumptions that shall contribute to simplification
   411   need to be part of the subgoal already, or indicated explicitly for use by
   412   the subsequent method invocation. Both too little or too much information
   413   can make simplification fail, for different reasons.
   414 
   415   In the next example the malicious assumption @{prop "\<And>x::nat. f x = g (f (g
   416   x))"} does not contribute to solve the problem, but makes the default
   417   @{method simp} method loop: the rewrite rule \<open>f ?x \<equiv> g (f (g ?x))\<close> extracted
   418   from the assumption does not terminate. The Simplifier notices certain
   419   simple forms of nontermination, but not this one. The problem can be solved
   420   nonetheless, by ignoring assumptions via special options as explained
   421   before:
   422 \<close>
   423 
   424 lemma "(\<And>x::nat. f x = g (f (g x))) \<Longrightarrow> f 0 = f 0 + 0"
   425   by (simp (no_asm))
   426 
   427 text \<open>
   428   The latter form is typical for long unstructured proof scripts, where the
   429   control over the goal content is limited. In structured proofs it is usually
   430   better to avoid pushing too many facts into the goal state in the first
   431   place. Assumptions in the Isar proof context do not intrude the reasoning if
   432   not used explicitly. This is illustrated for a toplevel statement and a
   433   local proof body as follows:
   434 \<close>
   435 
   436 lemma
   437   assumes "\<And>x::nat. f x = g (f (g x))"
   438   shows "f 0 = f 0 + 0" by simp
   439 
   440 notepad
   441 begin
   442   assume "\<And>x::nat. f x = g (f (g x))"
   443   have "f 0 = f 0 + 0" by simp
   444 end
   445 
   446 text \<open>
   447   \<^medskip>
   448   Because assumptions may simplify each other, there can be very subtle cases
   449   of nontermination. For example, the regular @{method simp} method applied to
   450   @{prop "P (f x) \<Longrightarrow> y = x \<Longrightarrow> f x = f y \<Longrightarrow> Q"} gives rise to the infinite
   451   reduction sequence
   452   \[
   453   \<open>P (f x)\<close> \stackrel{\<open>f x \<equiv> f y\<close>}{\longmapsto}
   454   \<open>P (f y)\<close> \stackrel{\<open>y \<equiv> x\<close>}{\longmapsto}
   455   \<open>P (f x)\<close> \stackrel{\<open>f x \<equiv> f y\<close>}{\longmapsto} \cdots
   456   \]
   457   whereas applying the same to @{prop "y = x \<Longrightarrow> f x = f y \<Longrightarrow> P (f x) \<Longrightarrow> Q"}
   458   terminates (without solving the goal):
   459 \<close>
   460 
   461 lemma "y = x \<Longrightarrow> f x = f y \<Longrightarrow> P (f x) \<Longrightarrow> Q"
   462   apply simp
   463   oops
   464 
   465 text \<open>
   466   See also \secref{sec:simp-trace} for options to enable Simplifier trace
   467   mode, which often helps to diagnose problems with rewrite systems.
   468 \<close>
   469 
   470 
   471 subsection \<open>Declaring rules \label{sec:simp-rules}\<close>
   472 
   473 text \<open>
   474   \begin{matharray}{rcl}
   475     @{attribute_def simp} & : & \<open>attribute\<close> \\
   476     @{attribute_def split} & : & \<open>attribute\<close> \\
   477     @{attribute_def cong} & : & \<open>attribute\<close> \\
   478     @{command_def "print_simpset"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
   479   \end{matharray}
   480 
   481   @{rail \<open>
   482     (@@{attribute simp} | @@{attribute cong}) (() | 'add' | 'del') |
   483     @@{attribute split} (() | '!' | 'del')
   484     ;
   485     @@{command print_simpset} ('!'?)
   486   \<close>}
   487 
   488   \<^descr> @{attribute simp} declares rewrite rules, by adding or deleting them from
   489   the simpset within the theory or proof context. Rewrite rules are theorems
   490   expressing some form of equality, for example:
   491 
   492   \<open>Suc ?m + ?n = ?m + Suc ?n\<close> \\
   493   \<open>?P \<and> ?P \<longleftrightarrow> ?P\<close> \\
   494   \<open>?A \<union> ?B \<equiv> {x. x \<in> ?A \<or> x \<in> ?B}\<close>
   495 
   496   \<^medskip>
   497   Conditional rewrites such as \<open>?m < ?n \<Longrightarrow> ?m div ?n = 0\<close> are also permitted;
   498   the conditions can be arbitrary formulas.
   499 
   500   \<^medskip>
   501   Internally, all rewrite rules are translated into Pure equalities, theorems
   502   with conclusion \<open>lhs \<equiv> rhs\<close>. The simpset contains a function for extracting
   503   equalities from arbitrary theorems, which is usually installed when the
   504   object-logic is configured initially. For example, \<open>\<not> ?x \<in> {}\<close> could be
   505   turned into \<open>?x \<in> {} \<equiv> False\<close>. Theorems that are declared as @{attribute
   506   simp} and local assumptions within a goal are treated uniformly in this
   507   respect.
   508 
   509   The Simplifier accepts the following formats for the \<open>lhs\<close> term:
   510 
   511     \<^enum> First-order patterns, considering the sublanguage of application of
   512     constant operators to variable operands, without \<open>\<lambda>\<close>-abstractions or
   513     functional variables. For example:
   514 
   515     \<open>(?x + ?y) + ?z \<equiv> ?x + (?y + ?z)\<close> \\
   516     \<open>f (f ?x ?y) ?z \<equiv> f ?x (f ?y ?z)\<close>
   517 
   518     \<^enum> Higher-order patterns in the sense of @{cite "nipkow-patterns"}. These
   519     are terms in \<open>\<beta>\<close>-normal form (this will always be the case unless you have
   520     done something strange) where each occurrence of an unknown is of the form
   521     \<open>?F x\<^sub>1 \<dots> x\<^sub>n\<close>, where the \<open>x\<^sub>i\<close> are distinct bound variables.
   522 
   523     For example, \<open>(\<forall>x. ?P x \<and> ?Q x) \<equiv> (\<forall>x. ?P x) \<and> (\<forall>x. ?Q x)\<close> or its
   524     symmetric form, since the \<open>rhs\<close> is also a higher-order pattern.
   525 
   526     \<^enum> Physical first-order patterns over raw \<open>\<lambda>\<close>-term structure without
   527     \<open>\<alpha>\<beta>\<eta>\<close>-equality; abstractions and bound variables are treated like
   528     quasi-constant term material.
   529 
   530     For example, the rule \<open>?f ?x \<in> range ?f = True\<close> rewrites the term \<open>g a \<in>
   531     range g\<close> to \<open>True\<close>, but will fail to match \<open>g (h b) \<in> range (\<lambda>x. g (h
   532     x))\<close>. However, offending subterms (in our case \<open>?f ?x\<close>, which is not a
   533     pattern) can be replaced by adding new variables and conditions like this:
   534     \<open>?y = ?f ?x \<Longrightarrow> ?y \<in> range ?f = True\<close> is acceptable as a conditional rewrite
   535     rule of the second category since conditions can be arbitrary terms.
   536 
   537   \<^descr> @{attribute split} declares case split rules.
   538 
   539   \<^descr> @{attribute cong} declares congruence rules to the Simplifier context.
   540 
   541   Congruence rules are equalities of the form @{text [display]
   542   "\<dots> \<Longrightarrow> f ?x\<^sub>1 \<dots> ?x\<^sub>n = f ?y\<^sub>1 \<dots> ?y\<^sub>n"}
   543 
   544   This controls the simplification of the arguments of \<open>f\<close>. For example, some
   545   arguments can be simplified under additional assumptions:
   546   @{text [display]
   547     "?P\<^sub>1 \<longleftrightarrow> ?Q\<^sub>1 \<Longrightarrow>
   548     (?Q\<^sub>1 \<Longrightarrow> ?P\<^sub>2 \<longleftrightarrow> ?Q\<^sub>2) \<Longrightarrow>
   549     (?P\<^sub>1 \<longrightarrow> ?P\<^sub>2) \<longleftrightarrow> (?Q\<^sub>1 \<longrightarrow> ?Q\<^sub>2)"}
   550 
   551   Given this rule, the Simplifier assumes \<open>?Q\<^sub>1\<close> and extracts rewrite rules
   552   from it when simplifying \<open>?P\<^sub>2\<close>. Such local assumptions are effective for
   553   rewriting formulae such as \<open>x = 0 \<longrightarrow> y + x = y\<close>.
   554 
   555   %FIXME
   556   %The local assumptions are also provided as theorems to the solver;
   557   %see \secref{sec:simp-solver} below.
   558 
   559   \<^medskip>
   560   The following congruence rule for bounded quantifiers also supplies
   561   contextual information --- about the bound variable: @{text [display]
   562   "(?A = ?B) \<Longrightarrow>
   563     (\<And>x. x \<in> ?B \<Longrightarrow> ?P x \<longleftrightarrow> ?Q x) \<Longrightarrow>
   564     (\<forall>x \<in> ?A. ?P x) \<longleftrightarrow> (\<forall>x \<in> ?B. ?Q x)"}
   565 
   566   \<^medskip>
   567   This congruence rule for conditional expressions can supply contextual
   568   information for simplifying the arms: @{text [display]
   569   "?p = ?q \<Longrightarrow>
   570     (?q \<Longrightarrow> ?a = ?c) \<Longrightarrow>
   571     (\<not> ?q \<Longrightarrow> ?b = ?d) \<Longrightarrow>
   572     (if ?p then ?a else ?b) = (if ?q then ?c else ?d)"}
   573 
   574   A congruence rule can also \<^emph>\<open>prevent\<close> simplification of some arguments. Here
   575   is an alternative congruence rule for conditional expressions that conforms
   576   to non-strict functional evaluation: @{text [display]
   577   "?p = ?q \<Longrightarrow>
   578     (if ?p then ?a else ?b) = (if ?q then ?a else ?b)"}
   579 
   580   Only the first argument is simplified; the others remain unchanged. This can
   581   make simplification much faster, but may require an extra case split over
   582   the condition \<open>?q\<close> to prove the goal.
   583 
   584   \<^descr> @{command "print_simpset"} prints the collection of rules declared to the
   585   Simplifier, which is also known as ``simpset'' internally; the ``\<open>!\<close>''
   586   option indicates extra verbosity.
   587 
   588   The implicit simpset of the theory context is propagated monotonically
   589   through the theory hierarchy: forming a new theory, the union of the
   590   simpsets of its imports are taken as starting point. Also note that
   591   definitional packages like @{command "datatype"}, @{command "primrec"},
   592   @{command "fun"} routinely declare Simplifier rules to the target context,
   593   while plain @{command "definition"} is an exception in \<^emph>\<open>not\<close> declaring
   594   anything.
   595 
   596   \<^medskip>
   597   It is up the user to manipulate the current simpset further by explicitly
   598   adding or deleting theorems as simplification rules, or installing other
   599   tools via simplification procedures (\secref{sec:simproc}). Good simpsets
   600   are hard to design. Rules that obviously simplify, like \<open>?n + 0 \<equiv> ?n\<close> are
   601   good candidates for the implicit simpset, unless a special non-normalizing
   602   behavior of certain operations is intended. More specific rules (such as
   603   distributive laws, which duplicate subterms) should be added only for
   604   specific proof steps. Conversely, sometimes a rule needs to be deleted just
   605   for some part of a proof. The need of frequent additions or deletions may
   606   indicate a poorly designed simpset.
   607 
   608   \begin{warn}
   609   The union of simpsets from theory imports (as described above) is not always
   610   a good starting point for the new theory. If some ancestors have deleted
   611   simplification rules because they are no longer wanted, while others have
   612   left those rules in, then the union will contain the unwanted rules, and
   613   thus have to be deleted again in the theory body.
   614   \end{warn}
   615 \<close>
   616 
   617 
   618 subsection \<open>Ordered rewriting with permutative rules\<close>
   619 
   620 text \<open>
   621   A rewrite rule is \<^emph>\<open>permutative\<close> if the left-hand side and right-hand side
   622   are the equal up to renaming of variables. The most common permutative rule
   623   is commutativity: \<open>?x + ?y = ?y + ?x\<close>. Other examples include \<open>(?x - ?y) -
   624   ?z = (?x - ?z) - ?y\<close> in arithmetic and \<open>insert ?x (insert ?y ?A) = insert ?y
   625   (insert ?x ?A)\<close> for sets. Such rules are common enough to merit special
   626   attention.
   627 
   628   Because ordinary rewriting loops given such rules, the Simplifier employs a
   629   special strategy, called \<^emph>\<open>ordered rewriting\<close>. Permutative rules are
   630   detected and only applied if the rewriting step decreases the redex wrt.\ a
   631   given term ordering. For example, commutativity rewrites \<open>b + a\<close> to \<open>a + b\<close>,
   632   but then stops, because the redex cannot be decreased further in the sense
   633   of the term ordering.
   634 
   635   The default is lexicographic ordering of term structure, but this could be
   636   also changed locally for special applications via @{index_ML
   637   Simplifier.set_termless} in Isabelle/ML.
   638 
   639   \<^medskip>
   640   Permutative rewrite rules are declared to the Simplifier just like other
   641   rewrite rules. Their special status is recognized automatically, and their
   642   application is guarded by the term ordering accordingly.
   643 \<close>
   644 
   645 
   646 subsubsection \<open>Rewriting with AC operators\<close>
   647 
   648 text \<open>
   649   Ordered rewriting is particularly effective in the case of
   650   associative-commutative operators. (Associativity by itself is not
   651   permutative.) When dealing with an AC-operator \<open>f\<close>, keep the following
   652   points in mind:
   653 
   654     \<^item> The associative law must always be oriented from left to right, namely
   655     \<open>f (f x y) z = f x (f y z)\<close>. The opposite orientation, if used with
   656     commutativity, leads to looping in conjunction with the standard term
   657     order.
   658 
   659     \<^item> To complete your set of rewrite rules, you must add not just
   660     associativity (A) and commutativity (C) but also a derived rule
   661     \<^emph>\<open>left-commutativity\<close> (LC): \<open>f x (f y z) = f y (f x z)\<close>.
   662 
   663   Ordered rewriting with the combination of A, C, and LC sorts a term
   664   lexicographically --- the rewriting engine imitates bubble-sort.
   665 \<close>
   666 
   667 experiment
   668   fixes f :: "'a \<Rightarrow> 'a \<Rightarrow> 'a"  (infix "\<bullet>" 60)
   669   assumes assoc: "(x \<bullet> y) \<bullet> z = x \<bullet> (y \<bullet> z)"
   670   assumes commute: "x \<bullet> y = y \<bullet> x"
   671 begin
   672 
   673 lemma left_commute: "x \<bullet> (y \<bullet> z) = y \<bullet> (x \<bullet> z)"
   674 proof -
   675   have "(x \<bullet> y) \<bullet> z = (y \<bullet> x) \<bullet> z" by (simp only: commute)
   676   then show ?thesis by (simp only: assoc)
   677 qed
   678 
   679 lemmas AC_rules = assoc commute left_commute
   680 
   681 text \<open>
   682   Thus the Simplifier is able to establish equalities with arbitrary
   683   permutations of subterms, by normalizing to a common standard form. For
   684   example:
   685 \<close>
   686 
   687 lemma "(b \<bullet> c) \<bullet> a = xxx"
   688   apply (simp only: AC_rules)
   689   txt \<open>@{subgoals}\<close>
   690   oops
   691 
   692 lemma "(b \<bullet> c) \<bullet> a = a \<bullet> (b \<bullet> c)" by (simp only: AC_rules)
   693 lemma "(b \<bullet> c) \<bullet> a = c \<bullet> (b \<bullet> a)" by (simp only: AC_rules)
   694 lemma "(b \<bullet> c) \<bullet> a = (c \<bullet> b) \<bullet> a" by (simp only: AC_rules)
   695 
   696 end
   697 
   698 text \<open>
   699   Martin and Nipkow @{cite "martin-nipkow"} discuss the theory and give many
   700   examples; other algebraic structures are amenable to ordered rewriting, such
   701   as Boolean rings. The Boyer-Moore theorem prover @{cite bm88book} also
   702   employs ordered rewriting.
   703 \<close>
   704 
   705 
   706 subsubsection \<open>Re-orienting equalities\<close>
   707 
   708 text \<open>Another application of ordered rewriting uses the derived rule
   709   @{thm [source] eq_commute}: @{thm [source = false] eq_commute} to
   710   reverse equations.
   711 
   712   This is occasionally useful to re-orient local assumptions according
   713   to the term ordering, when other built-in mechanisms of
   714   reorientation and mutual simplification fail to apply.\<close>
   715 
   716 
   717 subsection \<open>Simplifier tracing and debugging \label{sec:simp-trace}\<close>
   718 
   719 text \<open>
   720   \begin{tabular}{rcll}
   721     @{attribute_def simp_trace} & : & \<open>attribute\<close> & default \<open>false\<close> \\
   722     @{attribute_def simp_trace_depth_limit} & : & \<open>attribute\<close> & default \<open>1\<close> \\
   723     @{attribute_def simp_debug} & : & \<open>attribute\<close> & default \<open>false\<close> \\
   724     @{attribute_def simp_trace_new} & : & \<open>attribute\<close> \\
   725     @{attribute_def simp_break} & : & \<open>attribute\<close> \\
   726   \end{tabular}
   727   \<^medskip>
   728 
   729   @{rail \<open>
   730     @@{attribute simp_trace_new} ('interactive')? \<newline>
   731       ('mode' '=' ('full' | 'normal'))? \<newline>
   732       ('depth' '=' @{syntax nat})?
   733     ;
   734 
   735     @@{attribute simp_break} (@{syntax term}*)
   736   \<close>}
   737 
   738   These attributes and configurations options control various aspects of
   739   Simplifier tracing and debugging.
   740 
   741   \<^descr> @{attribute simp_trace} makes the Simplifier output internal operations.
   742   This includes rewrite steps, but also bookkeeping like modifications of the
   743   simpset.
   744 
   745   \<^descr> @{attribute simp_trace_depth_limit} limits the effect of @{attribute
   746   simp_trace} to the given depth of recursive Simplifier invocations (when
   747   solving conditions of rewrite rules).
   748 
   749   \<^descr> @{attribute simp_debug} makes the Simplifier output some extra information
   750   about internal operations. This includes any attempted invocation of
   751   simplification procedures.
   752 
   753   \<^descr> @{attribute simp_trace_new} controls Simplifier tracing within
   754   Isabelle/PIDE applications, notably Isabelle/jEdit @{cite "isabelle-jedit"}.
   755   This provides a hierarchical representation of the rewriting steps performed
   756   by the Simplifier.
   757 
   758   Users can configure the behaviour by specifying breakpoints, verbosity and
   759   enabling or disabling the interactive mode. In normal verbosity (the
   760   default), only rule applications matching a breakpoint will be shown to the
   761   user. In full verbosity, all rule applications will be logged. Interactive
   762   mode interrupts the normal flow of the Simplifier and defers the decision
   763   how to continue to the user via some GUI dialog.
   764 
   765   \<^descr> @{attribute simp_break} declares term or theorem breakpoints for
   766   @{attribute simp_trace_new} as described above. Term breakpoints are
   767   patterns which are checked for matches on the redex of a rule application.
   768   Theorem breakpoints trigger when the corresponding theorem is applied in a
   769   rewrite step. For example:
   770 \<close>
   771 
   772 (*<*)experiment begin(*>*)
   773 declare conjI [simp_break]
   774 declare [[simp_break "?x \<and> ?y"]]
   775 (*<*)end(*>*)
   776 
   777 
   778 subsection \<open>Simplification procedures \label{sec:simproc}\<close>
   779 
   780 text \<open>
   781   Simplification procedures are ML functions that produce proven rewrite rules
   782   on demand. They are associated with higher-order patterns that approximate
   783   the left-hand sides of equations. The Simplifier first matches the current
   784   redex against one of the LHS patterns; if this succeeds, the corresponding
   785   ML function is invoked, passing the Simplifier context and redex term. Thus
   786   rules may be specifically fashioned for particular situations, resulting in
   787   a more powerful mechanism than term rewriting by a fixed set of rules.
   788 
   789   Any successful result needs to be a (possibly conditional) rewrite rule \<open>t \<equiv>
   790   u\<close> that is applicable to the current redex. The rule will be applied just as
   791   any ordinary rewrite rule. It is expected to be already in \<^emph>\<open>internal form\<close>,
   792   bypassing the automatic preprocessing of object-level equivalences.
   793 
   794   \begin{matharray}{rcl}
   795     @{command_def "simproc_setup"} & : & \<open>local_theory \<rightarrow> local_theory\<close> \\
   796     simproc & : & \<open>attribute\<close> \\
   797   \end{matharray}
   798 
   799   @{rail \<open>
   800     @@{command simproc_setup} @{syntax name} '(' (@{syntax term} + '|') ')' '='
   801       @{syntax text};
   802 
   803     @@{attribute simproc} (('add' ':')? | 'del' ':') (@{syntax name}+)
   804   \<close>}
   805 
   806   \<^descr> @{command "simproc_setup"} defines a named simplification procedure that
   807   is invoked by the Simplifier whenever any of the given term patterns match
   808   the current redex. The implementation, which is provided as ML source text,
   809   needs to be of type
   810   @{ML_type "morphism -> Proof.context -> cterm -> thm option"}, where the
   811   @{ML_type cterm} represents the current redex \<open>r\<close> and the result is supposed
   812   to be some proven rewrite rule \<open>r \<equiv> r'\<close> (or a generalized version), or @{ML
   813   NONE} to indicate failure. The @{ML_type Proof.context} argument holds the
   814   full context of the current Simplifier invocation. The @{ML_type morphism}
   815   informs about the difference of the original compilation context wrt.\ the
   816   one of the actual application later on.
   817 
   818   Morphisms are only relevant for simprocs that are defined within a local
   819   target context, e.g.\ in a locale.
   820 
   821   \<^descr> \<open>simproc add: name\<close> and \<open>simproc del: name\<close> add or delete named simprocs
   822   to the current Simplifier context. The default is to add a simproc. Note
   823   that @{command "simproc_setup"} already adds the new simproc to the
   824   subsequent context.
   825 \<close>
   826 
   827 
   828 subsubsection \<open>Example\<close>
   829 
   830 text \<open>
   831   The following simplification procedure for @{thm [source = false,
   832   show_types] unit_eq} in HOL performs fine-grained control over rule
   833   application, beyond higher-order pattern matching. Declaring @{thm unit_eq}
   834   as @{attribute simp} directly would make the Simplifier loop! Note that a
   835   version of this simplification procedure is already active in Isabelle/HOL.
   836 \<close>
   837 
   838 (*<*)experiment begin(*>*)
   839 simproc_setup unit ("x::unit") =
   840   \<open>fn _ => fn _ => fn ct =>
   841     if HOLogic.is_unit (Thm.term_of ct) then NONE
   842     else SOME (mk_meta_eq @{thm unit_eq})\<close>
   843 (*<*)end(*>*)
   844 
   845 text \<open>
   846   Since the Simplifier applies simplification procedures frequently, it is
   847   important to make the failure check in ML reasonably fast.\<close>
   848 
   849 
   850 subsection \<open>Configurable Simplifier strategies \label{sec:simp-strategies}\<close>
   851 
   852 text \<open>
   853   The core term-rewriting engine of the Simplifier is normally used in
   854   combination with some add-on components that modify the strategy and allow
   855   to integrate other non-Simplifier proof tools. These may be reconfigured in
   856   ML as explained below. Even if the default strategies of object-logics like
   857   Isabelle/HOL are used unchanged, it helps to understand how the standard
   858   Simplifier strategies work.\<close>
   859 
   860 
   861 subsubsection \<open>The subgoaler\<close>
   862 
   863 text \<open>
   864   \begin{mldecls}
   865   @{index_ML Simplifier.set_subgoaler: "(Proof.context -> int -> tactic) ->
   866   Proof.context -> Proof.context"} \\
   867   @{index_ML Simplifier.prems_of: "Proof.context -> thm list"} \\
   868   \end{mldecls}
   869 
   870   The subgoaler is the tactic used to solve subgoals arising out of
   871   conditional rewrite rules or congruence rules. The default should be
   872   simplification itself. In rare situations, this strategy may need to be
   873   changed. For example, if the premise of a conditional rule is an instance of
   874   its conclusion, as in \<open>Suc ?m < ?n \<Longrightarrow> ?m < ?n\<close>, the default strategy could
   875   loop. % FIXME !??
   876 
   877     \<^descr> @{ML Simplifier.set_subgoaler}~\<open>tac ctxt\<close> sets the subgoaler of the
   878     context to \<open>tac\<close>. The tactic will be applied to the context of the running
   879     Simplifier instance.
   880 
   881     \<^descr> @{ML Simplifier.prems_of}~\<open>ctxt\<close> retrieves the current set of premises
   882     from the context. This may be non-empty only if the Simplifier has been
   883     told to utilize local assumptions in the first place (cf.\ the options in
   884     \secref{sec:simp-meth}).
   885 
   886   As an example, consider the following alternative subgoaler:
   887 \<close>
   888 
   889 ML_val \<open>
   890   fun subgoaler_tac ctxt =
   891     assume_tac ctxt ORELSE'
   892     resolve_tac ctxt (Simplifier.prems_of ctxt) ORELSE'
   893     asm_simp_tac ctxt
   894 \<close>
   895 
   896 text \<open>
   897   This tactic first tries to solve the subgoal by assumption or by resolving
   898   with with one of the premises, calling simplification only if that fails.\<close>
   899 
   900 
   901 subsubsection \<open>The solver\<close>
   902 
   903 text \<open>
   904   \begin{mldecls}
   905   @{index_ML_type solver} \\
   906   @{index_ML Simplifier.mk_solver: "string ->
   907   (Proof.context -> int -> tactic) -> solver"} \\
   908   @{index_ML_op setSolver: "Proof.context * solver -> Proof.context"} \\
   909   @{index_ML_op addSolver: "Proof.context * solver -> Proof.context"} \\
   910   @{index_ML_op setSSolver: "Proof.context * solver -> Proof.context"} \\
   911   @{index_ML_op addSSolver: "Proof.context * solver -> Proof.context"} \\
   912   \end{mldecls}
   913 
   914   A solver is a tactic that attempts to solve a subgoal after simplification.
   915   Its core functionality is to prove trivial subgoals such as @{prop "True"}
   916   and \<open>t = t\<close>, but object-logics might be more ambitious. For example,
   917   Isabelle/HOL performs a restricted version of linear arithmetic here.
   918 
   919   Solvers are packaged up in abstract type @{ML_type solver}, with @{ML
   920   Simplifier.mk_solver} as the only operation to create a solver.
   921 
   922   \<^medskip>
   923   Rewriting does not instantiate unknowns. For example, rewriting alone cannot
   924   prove \<open>a \<in> ?A\<close> since this requires instantiating \<open>?A\<close>. The solver, however,
   925   is an arbitrary tactic and may instantiate unknowns as it pleases. This is
   926   the only way the Simplifier can handle a conditional rewrite rule whose
   927   condition contains extra variables. When a simplification tactic is to be
   928   combined with other provers, especially with the Classical Reasoner, it is
   929   important whether it can be considered safe or not. For this reason a
   930   simpset contains two solvers: safe and unsafe.
   931 
   932   The standard simplification strategy solely uses the unsafe solver, which is
   933   appropriate in most cases. For special applications where the simplification
   934   process is not allowed to instantiate unknowns within the goal,
   935   simplification starts with the safe solver, but may still apply the ordinary
   936   unsafe one in nested simplifications for conditional rules or congruences.
   937   Note that in this way the overall tactic is not totally safe: it may
   938   instantiate unknowns that appear also in other subgoals.
   939 
   940   \<^descr> @{ML Simplifier.mk_solver}~\<open>name tac\<close> turns \<open>tac\<close> into a solver; the
   941   \<open>name\<close> is only attached as a comment and has no further significance.
   942 
   943   \<^descr> \<open>ctxt setSSolver solver\<close> installs \<open>solver\<close> as the safe solver of \<open>ctxt\<close>.
   944 
   945   \<^descr> \<open>ctxt addSSolver solver\<close> adds \<open>solver\<close> as an additional safe solver; it
   946   will be tried after the solvers which had already been present in \<open>ctxt\<close>.
   947 
   948   \<^descr> \<open>ctxt setSolver solver\<close> installs \<open>solver\<close> as the unsafe solver of \<open>ctxt\<close>.
   949 
   950   \<^descr> \<open>ctxt addSolver solver\<close> adds \<open>solver\<close> as an additional unsafe solver; it
   951   will be tried after the solvers which had already been present in \<open>ctxt\<close>.
   952 
   953 
   954   \<^medskip>
   955   The solver tactic is invoked with the context of the running Simplifier.
   956   Further operations may be used to retrieve relevant information, such as the
   957   list of local Simplifier premises via @{ML Simplifier.prems_of} --- this
   958   list may be non-empty only if the Simplifier runs in a mode that utilizes
   959   local assumptions (see also \secref{sec:simp-meth}). The solver is also
   960   presented the full goal including its assumptions in any case. Thus it can
   961   use these (e.g.\ by calling @{ML assume_tac}), even if the Simplifier proper
   962   happens to ignore local premises at the moment.
   963 
   964   \<^medskip>
   965   As explained before, the subgoaler is also used to solve the premises of
   966   congruence rules. These are usually of the form \<open>s = ?x\<close>, where \<open>s\<close> needs to
   967   be simplified and \<open>?x\<close> needs to be instantiated with the result. Typically,
   968   the subgoaler will invoke the Simplifier at some point, which will
   969   eventually call the solver. For this reason, solver tactics must be prepared
   970   to solve goals of the form \<open>t = ?x\<close>, usually by reflexivity. In particular,
   971   reflexivity should be tried before any of the fancy automated proof tools.
   972 
   973   It may even happen that due to simplification the subgoal is no longer an
   974   equality. For example, \<open>False \<longleftrightarrow> ?Q\<close> could be rewritten to \<open>\<not> ?Q\<close>. To cover
   975   this case, the solver could try resolving with the theorem \<open>\<not> False\<close> of the
   976   object-logic.
   977 
   978   \<^medskip>
   979   \begin{warn}
   980   If a premise of a congruence rule cannot be proved, then the congruence is
   981   ignored. This should only happen if the rule is \<^emph>\<open>conditional\<close> --- that is,
   982   contains premises not of the form \<open>t = ?x\<close>. Otherwise it indicates that some
   983   congruence rule, or possibly the subgoaler or solver, is faulty.
   984   \end{warn}
   985 \<close>
   986 
   987 
   988 subsubsection \<open>The looper\<close>
   989 
   990 text \<open>
   991   \begin{mldecls}
   992   @{index_ML_op setloop: "Proof.context *
   993   (Proof.context -> int -> tactic) -> Proof.context"} \\
   994   @{index_ML_op addloop: "Proof.context *
   995   (string * (Proof.context -> int -> tactic))
   996   -> Proof.context"} \\
   997   @{index_ML_op delloop: "Proof.context * string -> Proof.context"} \\
   998   @{index_ML Splitter.add_split: "thm -> Proof.context -> Proof.context"} \\
   999   @{index_ML Splitter.add_split: "thm -> Proof.context -> Proof.context"} \\
  1000   @{index_ML Splitter.add_split_bang: "
  1001   thm -> Proof.context -> Proof.context"} \\
  1002   @{index_ML Splitter.del_split: "thm -> Proof.context -> Proof.context"} \\
  1003   \end{mldecls}
  1004 
  1005   The looper is a list of tactics that are applied after simplification, in
  1006   case the solver failed to solve the simplified goal. If the looper succeeds,
  1007   the simplification process is started all over again. Each of the subgoals
  1008   generated by the looper is attacked in turn, in reverse order.
  1009 
  1010   A typical looper is \<^emph>\<open>case splitting\<close>: the expansion of a conditional.
  1011   Another possibility is to apply an elimination rule on the assumptions. More
  1012   adventurous loopers could start an induction.
  1013 
  1014     \<^descr> \<open>ctxt setloop tac\<close> installs \<open>tac\<close> as the only looper tactic of \<open>ctxt\<close>.
  1015 
  1016     \<^descr> \<open>ctxt addloop (name, tac)\<close> adds \<open>tac\<close> as an additional looper tactic
  1017     with name \<open>name\<close>, which is significant for managing the collection of
  1018     loopers. The tactic will be tried after the looper tactics that had
  1019     already been present in \<open>ctxt\<close>.
  1020 
  1021     \<^descr> \<open>ctxt delloop name\<close> deletes the looper tactic that was associated with
  1022     \<open>name\<close> from \<open>ctxt\<close>.
  1023 
  1024     \<^descr> @{ML Splitter.add_split}~\<open>thm ctxt\<close> adds split tactic
  1025     for \<open>thm\<close> as additional looper tactic of \<open>ctxt\<close>
  1026     (overwriting previous split tactic for the same constant).
  1027 
  1028     \<^descr> @{ML Splitter.add_split_bang}~\<open>thm ctxt\<close> adds aggressive
  1029     (see \S\ref{sec:simp-meth})
  1030     split tactic for \<open>thm\<close> as additional looper tactic of \<open>ctxt\<close>
  1031     (overwriting previous split tactic for the same constant).
  1032 
  1033     \<^descr> @{ML Splitter.del_split}~\<open>thm ctxt\<close> deletes the split tactic
  1034     corresponding to \<open>thm\<close> from the looper tactics of \<open>ctxt\<close>.
  1035 
  1036   The splitter replaces applications of a given function; the right-hand side
  1037   of the replacement can be anything. For example, here is a splitting rule
  1038   for conditional expressions:
  1039 
  1040   @{text [display] "?P (if ?Q ?x ?y) \<longleftrightarrow> (?Q \<longrightarrow> ?P ?x) \<and> (\<not> ?Q \<longrightarrow> ?P ?y)"}
  1041 
  1042   Another example is the elimination operator for Cartesian products (which
  1043   happens to be called @{const case_prod} in Isabelle/HOL:
  1044 
  1045   @{text [display] "?P (case_prod ?f ?p) \<longleftrightarrow> (\<forall>a b. ?p = (a, b) \<longrightarrow> ?P (f a b))"}
  1046 
  1047   For technical reasons, there is a distinction between case splitting in the
  1048   conclusion and in the premises of a subgoal. The former is done by @{ML
  1049   Splitter.split_tac} with rules like @{thm [source] if_split} or @{thm
  1050   [source] option.split}, which do not split the subgoal, while the latter is
  1051   done by @{ML Splitter.split_asm_tac} with rules like @{thm [source]
  1052   if_split_asm} or @{thm [source] option.split_asm}, which split the subgoal.
  1053   The function @{ML Splitter.add_split} automatically takes care of which
  1054   tactic to call, analyzing the form of the rules given as argument; it is the
  1055   same operation behind \<open>split\<close> attribute or method modifier syntax in the
  1056   Isar source language.
  1057 
  1058   Case splits should be allowed only when necessary; they are expensive and
  1059   hard to control. Case-splitting on if-expressions in the conclusion is
  1060   usually beneficial, so it is enabled by default in Isabelle/HOL and
  1061   Isabelle/FOL/ZF.
  1062 
  1063   \begin{warn}
  1064   With @{ML Splitter.split_asm_tac} as looper component, the Simplifier may
  1065   split subgoals! This might cause unexpected problems in tactic expressions
  1066   that silently assume 0 or 1 subgoals after simplification.
  1067   \end{warn}
  1068 \<close>
  1069 
  1070 
  1071 subsection \<open>Forward simplification \label{sec:simp-forward}\<close>
  1072 
  1073 text \<open>
  1074   \begin{matharray}{rcl}
  1075     @{attribute_def simplified} & : & \<open>attribute\<close> \\
  1076   \end{matharray}
  1077 
  1078   @{rail \<open>
  1079     @@{attribute simplified} opt? @{syntax thms}?
  1080     ;
  1081 
  1082     opt: '(' ('no_asm' | 'no_asm_simp' | 'no_asm_use') ')'
  1083   \<close>}
  1084 
  1085   \<^descr> @{attribute simplified}~\<open>a\<^sub>1 \<dots> a\<^sub>n\<close> causes a theorem to be simplified,
  1086   either by exactly the specified rules \<open>a\<^sub>1, \<dots>, a\<^sub>n\<close>, or the implicit
  1087   Simplifier context if no arguments are given. The result is fully simplified
  1088   by default, including assumptions and conclusion; the options \<open>no_asm\<close> etc.\
  1089   tune the Simplifier in the same way as the for the \<open>simp\<close> method.
  1090 
  1091   Note that forward simplification restricts the Simplifier to its most basic
  1092   operation of term rewriting; solver and looper tactics
  1093   (\secref{sec:simp-strategies}) are \<^emph>\<open>not\<close> involved here. The @{attribute
  1094   simplified} attribute should be only rarely required under normal
  1095   circumstances.
  1096 \<close>
  1097 
  1098 
  1099 section \<open>The Classical Reasoner \label{sec:classical}\<close>
  1100 
  1101 subsection \<open>Basic concepts\<close>
  1102 
  1103 text \<open>Although Isabelle is generic, many users will be working in
  1104   some extension of classical first-order logic.  Isabelle/ZF is built
  1105   upon theory FOL, while Isabelle/HOL conceptually contains
  1106   first-order logic as a fragment.  Theorem-proving in predicate logic
  1107   is undecidable, but many automated strategies have been developed to
  1108   assist in this task.
  1109 
  1110   Isabelle's classical reasoner is a generic package that accepts
  1111   certain information about a logic and delivers a suite of automatic
  1112   proof tools, based on rules that are classified and declared in the
  1113   context.  These proof procedures are slow and simplistic compared
  1114   with high-end automated theorem provers, but they can save
  1115   considerable time and effort in practice.  They can prove theorems
  1116   such as Pelletier's @{cite pelletier86} problems 40 and 41 in a few
  1117   milliseconds (including full proof reconstruction):\<close>
  1118 
  1119 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)"
  1120   by blast
  1121 
  1122 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)"
  1123   by blast
  1124 
  1125 text \<open>The proof tools are generic.  They are not restricted to
  1126   first-order logic, and have been heavily used in the development of
  1127   the Isabelle/HOL library and applications.  The tactics can be
  1128   traced, and their components can be called directly; in this manner,
  1129   any proof can be viewed interactively.\<close>
  1130 
  1131 
  1132 subsubsection \<open>The sequent calculus\<close>
  1133 
  1134 text \<open>Isabelle supports natural deduction, which is easy to use for
  1135   interactive proof.  But natural deduction does not easily lend
  1136   itself to automation, and has a bias towards intuitionism.  For
  1137   certain proofs in classical logic, it can not be called natural.
  1138   The \<^emph>\<open>sequent calculus\<close>, a generalization of natural deduction,
  1139   is easier to automate.
  1140 
  1141   A \<^bold>\<open>sequent\<close> has the form \<open>\<Gamma> \<turnstile> \<Delta>\<close>, where \<open>\<Gamma>\<close>
  1142   and \<open>\<Delta>\<close> are sets of formulae.\<^footnote>\<open>For first-order
  1143   logic, sequents can equivalently be made from lists or multisets of
  1144   formulae.\<close> The sequent \<open>P\<^sub>1, \<dots>, P\<^sub>m \<turnstile> Q\<^sub>1, \<dots>, Q\<^sub>n\<close> is
  1145   \<^bold>\<open>valid\<close> if \<open>P\<^sub>1 \<and> \<dots> \<and> P\<^sub>m\<close> implies \<open>Q\<^sub>1 \<or> \<dots> \<or>
  1146   Q\<^sub>n\<close>.  Thus \<open>P\<^sub>1, \<dots>, P\<^sub>m\<close> represent assumptions, each of which
  1147   is true, while \<open>Q\<^sub>1, \<dots>, Q\<^sub>n\<close> represent alternative goals.  A
  1148   sequent is \<^bold>\<open>basic\<close> if its left and right sides have a common
  1149   formula, as in \<open>P, Q \<turnstile> Q, R\<close>; basic sequents are trivially
  1150   valid.
  1151 
  1152   Sequent rules are classified as \<^bold>\<open>right\<close> or \<^bold>\<open>left\<close>,
  1153   indicating which side of the \<open>\<turnstile>\<close> symbol they operate on.
  1154   Rules that operate on the right side are analogous to natural
  1155   deduction's introduction rules, and left rules are analogous to
  1156   elimination rules.  The sequent calculus analogue of \<open>(\<longrightarrow>I)\<close>
  1157   is the rule
  1158   \[
  1159   \infer[\<open>(\<longrightarrow>R)\<close>]{\<open>\<Gamma> \<turnstile> \<Delta>, P \<longrightarrow> Q\<close>}{\<open>P, \<Gamma> \<turnstile> \<Delta>, Q\<close>}
  1160   \]
  1161   Applying the rule backwards, this breaks down some implication on
  1162   the right side of a sequent; \<open>\<Gamma>\<close> and \<open>\<Delta>\<close> stand for
  1163   the sets of formulae that are unaffected by the inference.  The
  1164   analogue of the pair \<open>(\<or>I1)\<close> and \<open>(\<or>I2)\<close> is the
  1165   single rule
  1166   \[
  1167   \infer[\<open>(\<or>R)\<close>]{\<open>\<Gamma> \<turnstile> \<Delta>, P \<or> Q\<close>}{\<open>\<Gamma> \<turnstile> \<Delta>, P, Q\<close>}
  1168   \]
  1169   This breaks down some disjunction on the right side, replacing it by
  1170   both disjuncts.  Thus, the sequent calculus is a kind of
  1171   multiple-conclusion logic.
  1172 
  1173   To illustrate the use of multiple formulae on the right, let us
  1174   prove the classical theorem \<open>(P \<longrightarrow> Q) \<or> (Q \<longrightarrow> P)\<close>.  Working
  1175   backwards, we reduce this formula to a basic sequent:
  1176   \[
  1177   \infer[\<open>(\<or>R)\<close>]{\<open>\<turnstile> (P \<longrightarrow> Q) \<or> (Q \<longrightarrow> P)\<close>}
  1178     {\infer[\<open>(\<longrightarrow>R)\<close>]{\<open>\<turnstile> (P \<longrightarrow> Q), (Q \<longrightarrow> P)\<close>}
  1179       {\infer[\<open>(\<longrightarrow>R)\<close>]{\<open>P \<turnstile> Q, (Q \<longrightarrow> P)\<close>}
  1180         {\<open>P, Q \<turnstile> Q, P\<close>}}}
  1181   \]
  1182 
  1183   This example is typical of the sequent calculus: start with the
  1184   desired theorem and apply rules backwards in a fairly arbitrary
  1185   manner.  This yields a surprisingly effective proof procedure.
  1186   Quantifiers add only few complications, since Isabelle handles
  1187   parameters and schematic variables.  See @{cite \<open>Chapter 10\<close>
  1188   "paulson-ml2"} for further discussion.\<close>
  1189 
  1190 
  1191 subsubsection \<open>Simulating sequents by natural deduction\<close>
  1192 
  1193 text \<open>Isabelle can represent sequents directly, as in the
  1194   object-logic LK.  But natural deduction is easier to work with, and
  1195   most object-logics employ it.  Fortunately, we can simulate the
  1196   sequent \<open>P\<^sub>1, \<dots>, P\<^sub>m \<turnstile> Q\<^sub>1, \<dots>, Q\<^sub>n\<close> by the Isabelle formula
  1197   \<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
  1198   the assumptions and the choice of \<open>Q\<^sub>1\<close> are arbitrary.
  1199   Elim-resolution plays a key role in simulating sequent proofs.
  1200 
  1201   We can easily handle reasoning on the left.  Elim-resolution with
  1202   the rules \<open>(\<or>E)\<close>, \<open>(\<bottom>E)\<close> and \<open>(\<exists>E)\<close> achieves
  1203   a similar effect as the corresponding sequent rules.  For the other
  1204   connectives, we use sequent-style elimination rules instead of
  1205   destruction rules such as \<open>(\<and>E1, 2)\<close> and \<open>(\<forall>E)\<close>.
  1206   But note that the rule \<open>(\<not>L)\<close> has no effect under our
  1207   representation of sequents!
  1208   \[
  1209   \infer[\<open>(\<not>L)\<close>]{\<open>\<not> P, \<Gamma> \<turnstile> \<Delta>\<close>}{\<open>\<Gamma> \<turnstile> \<Delta>, P\<close>}
  1210   \]
  1211 
  1212   What about reasoning on the right?  Introduction rules can only
  1213   affect the formula in the conclusion, namely \<open>Q\<^sub>1\<close>.  The
  1214   other right-side formulae are represented as negated assumptions,
  1215   \<open>\<not> Q\<^sub>2, \<dots>, \<not> Q\<^sub>n\<close>.  In order to operate on one of these, it
  1216   must first be exchanged with \<open>Q\<^sub>1\<close>.  Elim-resolution with the
  1217   \<open>swap\<close> rule has this effect: \<open>\<not> P \<Longrightarrow> (\<not> R \<Longrightarrow> P) \<Longrightarrow> R\<close>
  1218 
  1219   To ensure that swaps occur only when necessary, each introduction
  1220   rule is converted into a swapped form: it is resolved with the
  1221   second premise of \<open>(swap)\<close>.  The swapped form of \<open>(\<and>I)\<close>, which might be called \<open>(\<not>\<and>E)\<close>, is
  1222   @{text [display] "\<not> (P \<and> Q) \<Longrightarrow> (\<not> R \<Longrightarrow> P) \<Longrightarrow> (\<not> R \<Longrightarrow> Q) \<Longrightarrow> R"}
  1223 
  1224   Similarly, the swapped form of \<open>(\<longrightarrow>I)\<close> is
  1225   @{text [display] "\<not> (P \<longrightarrow> Q) \<Longrightarrow> (\<not> R \<Longrightarrow> P \<Longrightarrow> Q) \<Longrightarrow> R"}
  1226 
  1227   Swapped introduction rules are applied using elim-resolution, which
  1228   deletes the negated formula.  Our representation of sequents also
  1229   requires the use of ordinary introduction rules.  If we had no
  1230   regard for readability of intermediate goal states, we could treat
  1231   the right side more uniformly by representing sequents as @{text
  1232   [display] "P\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> P\<^sub>m \<Longrightarrow> \<not> Q\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> \<not> Q\<^sub>n \<Longrightarrow> \<bottom>"}
  1233 \<close>
  1234 
  1235 
  1236 subsubsection \<open>Extra rules for the sequent calculus\<close>
  1237 
  1238 text \<open>As mentioned, destruction rules such as \<open>(\<and>E1, 2)\<close> and
  1239   \<open>(\<forall>E)\<close> must be replaced by sequent-style elimination rules.
  1240   In addition, we need rules to embody the classical equivalence
  1241   between \<open>P \<longrightarrow> Q\<close> and \<open>\<not> P \<or> Q\<close>.  The introduction
  1242   rules \<open>(\<or>I1, 2)\<close> are replaced by a rule that simulates
  1243   \<open>(\<or>R)\<close>: @{text [display] "(\<not> Q \<Longrightarrow> P) \<Longrightarrow> P \<or> Q"}
  1244 
  1245   The destruction rule \<open>(\<longrightarrow>E)\<close> is replaced by @{text [display]
  1246   "(P \<longrightarrow> Q) \<Longrightarrow> (\<not> P \<Longrightarrow> R) \<Longrightarrow> (Q \<Longrightarrow> R) \<Longrightarrow> R"}
  1247 
  1248   Quantifier replication also requires special rules.  In classical
  1249   logic, \<open>\<exists>x. P x\<close> is equivalent to \<open>\<not> (\<forall>x. \<not> P x)\<close>;
  1250   the rules \<open>(\<exists>R)\<close> and \<open>(\<forall>L)\<close> are dual:
  1251   \[
  1252   \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>}
  1253   \qquad
  1254   \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>}
  1255   \]
  1256   Thus both kinds of quantifier may be replicated.  Theorems requiring
  1257   multiple uses of a universal formula are easy to invent; consider
  1258   @{text [display] "(\<forall>x. P x \<longrightarrow> P (f x)) \<and> P a \<longrightarrow> P (f\<^sup>n a)"} for any
  1259   \<open>n > 1\<close>.  Natural examples of the multiple use of an
  1260   existential formula are rare; a standard one is \<open>\<exists>x. \<forall>y. P x
  1261   \<longrightarrow> P y\<close>.
  1262 
  1263   Forgoing quantifier replication loses completeness, but gains
  1264   decidability, since the search space becomes finite.  Many useful
  1265   theorems can be proved without replication, and the search generally
  1266   delivers its verdict in a reasonable time.  To adopt this approach,
  1267   represent the sequent rules \<open>(\<exists>R)\<close>, \<open>(\<exists>L)\<close> and
  1268   \<open>(\<forall>R)\<close> by \<open>(\<exists>I)\<close>, \<open>(\<exists>E)\<close> and \<open>(\<forall>I)\<close>,
  1269   respectively, and put \<open>(\<forall>E)\<close> into elimination form: @{text
  1270   [display] "\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> Q) \<Longrightarrow> Q"}
  1271 
  1272   Elim-resolution with this rule will delete the universal formula
  1273   after a single use.  To replicate universal quantifiers, replace the
  1274   rule by @{text [display] "\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> \<forall>x. P x \<Longrightarrow> Q) \<Longrightarrow> Q"}
  1275 
  1276   To replicate existential quantifiers, replace \<open>(\<exists>I)\<close> by
  1277   @{text [display] "(\<not> (\<exists>x. P x) \<Longrightarrow> P t) \<Longrightarrow> \<exists>x. P x"}
  1278 
  1279   All introduction rules mentioned above are also useful in swapped
  1280   form.
  1281 
  1282   Replication makes the search space infinite; we must apply the rules
  1283   with care.  The classical reasoner distinguishes between safe and
  1284   unsafe rules, applying the latter only when there is no alternative.
  1285   Depth-first search may well go down a blind alley; best-first search
  1286   is better behaved in an infinite search space.  However, quantifier
  1287   replication is too expensive to prove any but the simplest theorems.
  1288 \<close>
  1289 
  1290 
  1291 subsection \<open>Rule declarations\<close>
  1292 
  1293 text \<open>The proof tools of the Classical Reasoner depend on
  1294   collections of rules declared in the context, which are classified
  1295   as introduction, elimination or destruction and as \<^emph>\<open>safe\<close> or
  1296   \<^emph>\<open>unsafe\<close>.  In general, safe rules can be attempted blindly,
  1297   while unsafe rules must be used with care.  A safe rule must never
  1298   reduce a provable goal to an unprovable set of subgoals.
  1299 
  1300   The rule \<open>P \<Longrightarrow> P \<or> Q\<close> is unsafe because it reduces \<open>P
  1301   \<or> Q\<close> to \<open>P\<close>, which might turn out as premature choice of an
  1302   unprovable subgoal.  Any rule is unsafe whose premises contain new
  1303   unknowns.  The elimination rule \<open>\<forall>x. P x \<Longrightarrow> (P t \<Longrightarrow> Q) \<Longrightarrow> Q\<close> is
  1304   unsafe, since it is applied via elim-resolution, which discards the
  1305   assumption \<open>\<forall>x. P x\<close> and replaces it by the weaker
  1306   assumption \<open>P t\<close>.  The rule \<open>P t \<Longrightarrow> \<exists>x. P x\<close> is
  1307   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:
  1308   since it keeps the assumption \<open>\<forall>x. P x\<close>, it is prone to
  1309   looping.  In classical first-order logic, all rules are safe except
  1310   those mentioned above.
  1311 
  1312   The safe~/ unsafe distinction is vague, and may be regarded merely
  1313   as a way of giving some rules priority over others.  One could argue
  1314   that \<open>(\<or>E)\<close> is unsafe, because repeated application of it
  1315   could generate exponentially many subgoals.  Induction rules are
  1316   unsafe because inductive proofs are difficult to set up
  1317   automatically.  Any inference is unsafe that instantiates an unknown
  1318   in the proof state --- thus matching must be used, rather than
  1319   unification.  Even proof by assumption is unsafe if it instantiates
  1320   unknowns shared with other subgoals.
  1321 
  1322   \begin{matharray}{rcl}
  1323     @{command_def "print_claset"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow>\<close> \\
  1324     @{attribute_def intro} & : & \<open>attribute\<close> \\
  1325     @{attribute_def elim} & : & \<open>attribute\<close> \\
  1326     @{attribute_def dest} & : & \<open>attribute\<close> \\
  1327     @{attribute_def rule} & : & \<open>attribute\<close> \\
  1328     @{attribute_def iff} & : & \<open>attribute\<close> \\
  1329     @{attribute_def swapped} & : & \<open>attribute\<close> \\
  1330   \end{matharray}
  1331 
  1332   @{rail \<open>
  1333     (@@{attribute intro} | @@{attribute elim} | @@{attribute dest}) ('!' | () | '?') @{syntax nat}?
  1334     ;
  1335     @@{attribute rule} 'del'
  1336     ;
  1337     @@{attribute iff} (((() | 'add') '?'?) | 'del')
  1338   \<close>}
  1339 
  1340   \<^descr> @{command "print_claset"} prints the collection of rules
  1341   declared to the Classical Reasoner, i.e.\ the @{ML_type claset}
  1342   within the context.
  1343 
  1344   \<^descr> @{attribute intro}, @{attribute elim}, and @{attribute dest}
  1345   declare introduction, elimination, and destruction rules,
  1346   respectively.  By default, rules are considered as \<^emph>\<open>unsafe\<close>
  1347   (i.e.\ not applied blindly without backtracking), while ``\<open>!\<close>'' classifies as \<^emph>\<open>safe\<close>.  Rule declarations marked by
  1348   ``\<open>?\<close>'' coincide with those of Isabelle/Pure, cf.\
  1349   \secref{sec:pure-meth-att} (i.e.\ are only applied in single steps
  1350   of the @{method rule} method).  The optional natural number
  1351   specifies an explicit weight argument, which is ignored by the
  1352   automated reasoning tools, but determines the search order of single
  1353   rule steps.
  1354 
  1355   Introduction rules are those that can be applied using ordinary
  1356   resolution.  Their swapped forms are generated internally, which
  1357   will be applied using elim-resolution.  Elimination rules are
  1358   applied using elim-resolution.  Rules are sorted by the number of
  1359   new subgoals they will yield; rules that generate the fewest
  1360   subgoals will be tried first.  Otherwise, later declarations take
  1361   precedence over earlier ones.
  1362 
  1363   Rules already present in the context with the same classification
  1364   are ignored.  A warning is printed if the rule has already been
  1365   added with some other classification, but the rule is added anyway
  1366   as requested.
  1367 
  1368   \<^descr> @{attribute rule}~\<open>del\<close> deletes all occurrences of a
  1369   rule from the classical context, regardless of its classification as
  1370   introduction~/ elimination~/ destruction and safe~/ unsafe.
  1371 
  1372   \<^descr> @{attribute iff} declares logical equivalences to the
  1373   Simplifier and the Classical reasoner at the same time.
  1374   Non-conditional rules result in a safe introduction and elimination
  1375   pair; conditional ones are considered unsafe.  Rules with negative
  1376   conclusion are automatically inverted (using \<open>\<not>\<close>-elimination
  1377   internally).
  1378 
  1379   The ``\<open>?\<close>'' version of @{attribute iff} declares rules to
  1380   the Isabelle/Pure context only, and omits the Simplifier
  1381   declaration.
  1382 
  1383   \<^descr> @{attribute swapped} turns an introduction rule into an
  1384   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
  1385   illustrative purposes: the Classical Reasoner already swaps rules
  1386   internally as explained above.
  1387 \<close>
  1388 
  1389 
  1390 subsection \<open>Structured methods\<close>
  1391 
  1392 text \<open>
  1393   \begin{matharray}{rcl}
  1394     @{method_def rule} & : & \<open>method\<close> \\
  1395     @{method_def contradiction} & : & \<open>method\<close> \\
  1396   \end{matharray}
  1397 
  1398   @{rail \<open>
  1399     @@{method rule} @{syntax thms}?
  1400   \<close>}
  1401 
  1402   \<^descr> @{method rule} as offered by the Classical Reasoner is a
  1403   refinement over the Pure one (see \secref{sec:pure-meth-att}).  Both
  1404   versions work the same, but the classical version observes the
  1405   classical rule context in addition to that of Isabelle/Pure.
  1406 
  1407   Common object logics (HOL, ZF, etc.) declare a rich collection of
  1408   classical rules (even if these would qualify as intuitionistic
  1409   ones), but only few declarations to the rule context of
  1410   Isabelle/Pure (\secref{sec:pure-meth-att}).
  1411 
  1412   \<^descr> @{method contradiction} solves some goal by contradiction,
  1413   deriving any result from both \<open>\<not> A\<close> and \<open>A\<close>.  Chained
  1414   facts, which are guaranteed to participate, may appear in either
  1415   order.
  1416 \<close>
  1417 
  1418 
  1419 subsection \<open>Fully automated methods\<close>
  1420 
  1421 text \<open>
  1422   \begin{matharray}{rcl}
  1423     @{method_def blast} & : & \<open>method\<close> \\
  1424     @{method_def auto} & : & \<open>method\<close> \\
  1425     @{method_def force} & : & \<open>method\<close> \\
  1426     @{method_def fast} & : & \<open>method\<close> \\
  1427     @{method_def slow} & : & \<open>method\<close> \\
  1428     @{method_def best} & : & \<open>method\<close> \\
  1429     @{method_def fastforce} & : & \<open>method\<close> \\
  1430     @{method_def slowsimp} & : & \<open>method\<close> \\
  1431     @{method_def bestsimp} & : & \<open>method\<close> \\
  1432     @{method_def deepen} & : & \<open>method\<close> \\
  1433   \end{matharray}
  1434 
  1435   @{rail \<open>
  1436     @@{method blast} @{syntax nat}? (@{syntax clamod} * )
  1437     ;
  1438     @@{method auto} (@{syntax nat} @{syntax nat})? (@{syntax clasimpmod} * )
  1439     ;
  1440     @@{method force} (@{syntax clasimpmod} * )
  1441     ;
  1442     (@@{method fast} | @@{method slow} | @@{method best}) (@{syntax clamod} * )
  1443     ;
  1444     (@@{method fastforce} | @@{method slowsimp} | @@{method bestsimp})
  1445       (@{syntax clasimpmod} * )
  1446     ;
  1447     @@{method deepen} (@{syntax nat} ?) (@{syntax clamod} * )
  1448     ;
  1449     @{syntax_def clamod}:
  1450       (('intro' | 'elim' | 'dest') ('!' | () | '?') | 'del') ':' @{syntax thms}
  1451     ;
  1452     @{syntax_def clasimpmod}: ('simp' (() | 'add' | 'del' | 'only') |
  1453       'cong' (() | 'add' | 'del') |
  1454       'split' (() | '!' | 'del') |
  1455       'iff' (((() | 'add') '?'?) | 'del') |
  1456       (('intro' | 'elim' | 'dest') ('!' | () | '?') | 'del')) ':' @{syntax thms}
  1457   \<close>}
  1458 
  1459   \<^descr> @{method blast} is a separate classical tableau prover that
  1460   uses the same classical rule declarations as explained before.
  1461 
  1462   Proof search is coded directly in ML using special data structures.
  1463   A successful proof is then reconstructed using regular Isabelle
  1464   inferences.  It is faster and more powerful than the other classical
  1465   reasoning tools, but has major limitations too.
  1466 
  1467     \<^item> It does not use the classical wrapper tacticals, such as the
  1468     integration with the Simplifier of @{method fastforce}.
  1469 
  1470     \<^item> It does not perform higher-order unification, as needed by the
  1471     rule @{thm [source=false] rangeI} in HOL.  There are often
  1472     alternatives to such rules, for example @{thm [source=false]
  1473     range_eqI}.
  1474 
  1475     \<^item> Function variables may only be applied to parameters of the
  1476     subgoal.  (This restriction arises because the prover does not use
  1477     higher-order unification.)  If other function variables are present
  1478     then the prover will fail with the message
  1479     @{verbatim [display] \<open>Function unknown's argument not a bound variable\<close>}
  1480 
  1481     \<^item> Its proof strategy is more general than @{method fast} but can
  1482     be slower.  If @{method blast} fails or seems to be running forever,
  1483     try @{method fast} and the other proof tools described below.
  1484 
  1485   The optional integer argument specifies a bound for the number of
  1486   unsafe steps used in a proof.  By default, @{method blast} starts
  1487   with a bound of 0 and increases it successively to 20.  In contrast,
  1488   \<open>(blast lim)\<close> tries to prove the goal using a search bound
  1489   of \<open>lim\<close>.  Sometimes a slow proof using @{method blast} can
  1490   be made much faster by supplying the successful search bound to this
  1491   proof method instead.
  1492 
  1493   \<^descr> @{method auto} combines classical reasoning with
  1494   simplification.  It is intended for situations where there are a lot
  1495   of mostly trivial subgoals; it proves all the easy ones, leaving the
  1496   ones it cannot prove.  Occasionally, attempting to prove the hard
  1497   ones may take a long time.
  1498 
  1499   The optional depth arguments in \<open>(auto m n)\<close> refer to its
  1500   builtin classical reasoning procedures: \<open>m\<close> (default 4) is for
  1501   @{method blast}, which is tried first, and \<open>n\<close> (default 2) is
  1502   for a slower but more general alternative that also takes wrappers
  1503   into account.
  1504 
  1505   \<^descr> @{method force} is intended to prove the first subgoal
  1506   completely, using many fancy proof tools and performing a rather
  1507   exhaustive search.  As a result, proof attempts may take rather long
  1508   or diverge easily.
  1509 
  1510   \<^descr> @{method fast}, @{method best}, @{method slow} attempt to
  1511   prove the first subgoal using sequent-style reasoning as explained
  1512   before.  Unlike @{method blast}, they construct proofs directly in
  1513   Isabelle.
  1514 
  1515   There is a difference in search strategy and back-tracking: @{method
  1516   fast} uses depth-first search and @{method best} uses best-first
  1517   search (guided by a heuristic function: normally the total size of
  1518   the proof state).
  1519 
  1520   Method @{method slow} is like @{method fast}, but conducts a broader
  1521   search: it may, when backtracking from a failed proof attempt, undo
  1522   even the step of proving a subgoal by assumption.
  1523 
  1524   \<^descr> @{method fastforce}, @{method slowsimp}, @{method bestsimp}
  1525   are like @{method fast}, @{method slow}, @{method best},
  1526   respectively, but use the Simplifier as additional wrapper. The name
  1527   @{method fastforce}, reflects the behaviour of this popular method
  1528   better without requiring an understanding of its implementation.
  1529 
  1530   \<^descr> @{method deepen} works by exhaustive search up to a certain
  1531   depth.  The start depth is 4 (unless specified explicitly), and the
  1532   depth is increased iteratively up to 10.  Unsafe rules are modified
  1533   to preserve the formula they act on, so that it be used repeatedly.
  1534   This method can prove more goals than @{method fast}, but is much
  1535   slower, for example if the assumptions have many universal
  1536   quantifiers.
  1537 
  1538 
  1539   Any of the above methods support additional modifiers of the context
  1540   of classical (and simplifier) rules, but the ones related to the
  1541   Simplifier are explicitly prefixed by \<open>simp\<close> here.  The
  1542   semantics of these ad-hoc rule declarations is analogous to the
  1543   attributes given before.  Facts provided by forward chaining are
  1544   inserted into the goal before commencing proof search.
  1545 \<close>
  1546 
  1547 
  1548 subsection \<open>Partially automated methods\label{sec:classical:partial}\<close>
  1549 
  1550 text \<open>These proof methods may help in situations when the
  1551   fully-automated tools fail.  The result is a simpler subgoal that
  1552   can be tackled by other means, such as by manual instantiation of
  1553   quantifiers.
  1554 
  1555   \begin{matharray}{rcl}
  1556     @{method_def safe} & : & \<open>method\<close> \\
  1557     @{method_def clarify} & : & \<open>method\<close> \\
  1558     @{method_def clarsimp} & : & \<open>method\<close> \\
  1559   \end{matharray}
  1560 
  1561   @{rail \<open>
  1562     (@@{method safe} | @@{method clarify}) (@{syntax clamod} * )
  1563     ;
  1564     @@{method clarsimp} (@{syntax clasimpmod} * )
  1565   \<close>}
  1566 
  1567   \<^descr> @{method safe} repeatedly performs safe steps on all subgoals.
  1568   It is deterministic, with at most one outcome.
  1569 
  1570   \<^descr> @{method clarify} performs a series of safe steps without
  1571   splitting subgoals; see also @{method clarify_step}.
  1572 
  1573   \<^descr> @{method clarsimp} acts like @{method clarify}, but also does
  1574   simplification.  Note that if the Simplifier context includes a
  1575   splitter for the premises, the subgoal may still be split.
  1576 \<close>
  1577 
  1578 
  1579 subsection \<open>Single-step tactics\<close>
  1580 
  1581 text \<open>
  1582   \begin{matharray}{rcl}
  1583     @{method_def safe_step} & : & \<open>method\<close> \\
  1584     @{method_def inst_step} & : & \<open>method\<close> \\
  1585     @{method_def step} & : & \<open>method\<close> \\
  1586     @{method_def slow_step} & : & \<open>method\<close> \\
  1587     @{method_def clarify_step} & : &  \<open>method\<close> \\
  1588   \end{matharray}
  1589 
  1590   These are the primitive tactics behind the automated proof methods
  1591   of the Classical Reasoner.  By calling them yourself, you can
  1592   execute these procedures one step at a time.
  1593 
  1594   \<^descr> @{method safe_step} performs a safe step on the first subgoal.
  1595   The safe wrapper tacticals are applied to a tactic that may include
  1596   proof by assumption or Modus Ponens (taking care not to instantiate
  1597   unknowns), or substitution.
  1598 
  1599   \<^descr> @{method inst_step} is like @{method safe_step}, but allows
  1600   unknowns to be instantiated.
  1601 
  1602   \<^descr> @{method step} is the basic step of the proof procedure, it
  1603   operates on the first subgoal.  The unsafe wrapper tacticals are
  1604   applied to a tactic that tries @{method safe}, @{method inst_step},
  1605   or applies an unsafe rule from the context.
  1606 
  1607   \<^descr> @{method slow_step} resembles @{method step}, but allows
  1608   backtracking between using safe rules with instantiation (@{method
  1609   inst_step}) and using unsafe rules.  The resulting search space is
  1610   larger.
  1611 
  1612   \<^descr> @{method clarify_step} performs a safe step on the first
  1613   subgoal; no splitting step is applied.  For example, the subgoal
  1614   \<open>A \<and> B\<close> is left as a conjunction.  Proof by assumption,
  1615   Modus Ponens, etc., may be performed provided they do not
  1616   instantiate unknowns.  Assumptions of the form \<open>x = t\<close> may
  1617   be eliminated.  The safe wrapper tactical is applied.
  1618 \<close>
  1619 
  1620 
  1621 subsection \<open>Modifying the search step\<close>
  1622 
  1623 text \<open>
  1624   \begin{mldecls}
  1625     @{index_ML_type wrapper: "(int -> tactic) -> (int -> tactic)"} \\[0.5ex]
  1626     @{index_ML_op addSWrapper: "Proof.context *
  1627   (string * (Proof.context -> wrapper)) -> Proof.context"} \\
  1628     @{index_ML_op addSbefore: "Proof.context *
  1629   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
  1630     @{index_ML_op addSafter: "Proof.context *
  1631   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
  1632     @{index_ML_op delSWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
  1633     @{index_ML_op addWrapper: "Proof.context *
  1634   (string * (Proof.context -> wrapper)) -> Proof.context"} \\
  1635     @{index_ML_op addbefore: "Proof.context *
  1636   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
  1637     @{index_ML_op addafter: "Proof.context *
  1638   (string * (Proof.context -> int -> tactic)) -> Proof.context"} \\
  1639     @{index_ML_op delWrapper: "Proof.context * string -> Proof.context"} \\[0.5ex]
  1640     @{index_ML addSss: "Proof.context -> Proof.context"} \\
  1641     @{index_ML addss: "Proof.context -> Proof.context"} \\
  1642   \end{mldecls}
  1643 
  1644   The proof strategy of the Classical Reasoner is simple.  Perform as
  1645   many safe inferences as possible; or else, apply certain safe rules,
  1646   allowing instantiation of unknowns; or else, apply an unsafe rule.
  1647   The tactics also eliminate assumptions of the form \<open>x = t\<close>
  1648   by substitution if they have been set up to do so.  They may perform
  1649   a form of Modus Ponens: if there are assumptions \<open>P \<longrightarrow> Q\<close> and
  1650   \<open>P\<close>, then replace \<open>P \<longrightarrow> Q\<close> by \<open>Q\<close>.
  1651 
  1652   The classical reasoning tools --- except @{method blast} --- allow
  1653   to modify this basic proof strategy by applying two lists of
  1654   arbitrary \<^emph>\<open>wrapper tacticals\<close> to it.  The first wrapper list,
  1655   which is considered to contain safe wrappers only, affects @{method
  1656   safe_step} and all the tactics that call it.  The second one, which
  1657   may contain unsafe wrappers, affects the unsafe parts of @{method
  1658   step}, @{method slow_step}, and the tactics that call them.  A
  1659   wrapper transforms each step of the search, for example by
  1660   attempting other tactics before or after the original step tactic.
  1661   All members of a wrapper list are applied in turn to the respective
  1662   step tactic.
  1663 
  1664   Initially the two wrapper lists are empty, which means no
  1665   modification of the step tactics. Safe and unsafe wrappers are added
  1666   to the context with the functions given below, supplying them with
  1667   wrapper names.  These names may be used to selectively delete
  1668   wrappers.
  1669 
  1670   \<^descr> \<open>ctxt addSWrapper (name, wrapper)\<close> adds a new wrapper,
  1671   which should yield a safe tactic, to modify the existing safe step
  1672   tactic.
  1673 
  1674   \<^descr> \<open>ctxt addSbefore (name, tac)\<close> adds the given tactic as a
  1675   safe wrapper, such that it is tried \<^emph>\<open>before\<close> each safe step of
  1676   the search.
  1677 
  1678   \<^descr> \<open>ctxt addSafter (name, tac)\<close> adds the given tactic as a
  1679   safe wrapper, such that it is tried when a safe step of the search
  1680   would fail.
  1681 
  1682   \<^descr> \<open>ctxt delSWrapper name\<close> deletes the safe wrapper with
  1683   the given name.
  1684 
  1685   \<^descr> \<open>ctxt addWrapper (name, wrapper)\<close> adds a new wrapper to
  1686   modify the existing (unsafe) step tactic.
  1687 
  1688   \<^descr> \<open>ctxt addbefore (name, tac)\<close> adds the given tactic as an
  1689   unsafe wrapper, such that it its result is concatenated
  1690   \<^emph>\<open>before\<close> the result of each unsafe step.
  1691 
  1692   \<^descr> \<open>ctxt addafter (name, tac)\<close> adds the given tactic as an
  1693   unsafe wrapper, such that it its result is concatenated \<^emph>\<open>after\<close>
  1694   the result of each unsafe step.
  1695 
  1696   \<^descr> \<open>ctxt delWrapper name\<close> deletes the unsafe wrapper with
  1697   the given name.
  1698 
  1699   \<^descr> \<open>addSss\<close> adds the simpset of the context to its
  1700   classical set. The assumptions and goal will be simplified, in a
  1701   rather safe way, after each safe step of the search.
  1702 
  1703   \<^descr> \<open>addss\<close> adds the simpset of the context to its
  1704   classical set. The assumptions and goal will be simplified, before
  1705   the each unsafe step of the search.
  1706 \<close>
  1707 
  1708 
  1709 section \<open>Object-logic setup \label{sec:object-logic}\<close>
  1710 
  1711 text \<open>
  1712   \begin{matharray}{rcl}
  1713     @{command_def "judgment"} & : & \<open>theory \<rightarrow> theory\<close> \\
  1714     @{method_def atomize} & : & \<open>method\<close> \\
  1715     @{attribute_def atomize} & : & \<open>attribute\<close> \\
  1716     @{attribute_def rule_format} & : & \<open>attribute\<close> \\
  1717     @{attribute_def rulify} & : & \<open>attribute\<close> \\
  1718   \end{matharray}
  1719 
  1720   The very starting point for any Isabelle object-logic is a ``truth
  1721   judgment'' that links object-level statements to the meta-logic
  1722   (with its minimal language of \<open>prop\<close> that covers universal
  1723   quantification \<open>\<And>\<close> and implication \<open>\<Longrightarrow>\<close>).
  1724 
  1725   Common object-logics are sufficiently expressive to internalize rule
  1726   statements over \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> within their own
  1727   language.  This is useful in certain situations where a rule needs
  1728   to be viewed as an atomic statement from the meta-level perspective,
  1729   e.g.\ \<open>\<And>x. x \<in> A \<Longrightarrow> P x\<close> versus \<open>\<forall>x \<in> A. P x\<close>.
  1730 
  1731   From the following language elements, only the @{method atomize}
  1732   method and @{attribute rule_format} attribute are occasionally
  1733   required by end-users, the rest is for those who need to setup their
  1734   own object-logic.  In the latter case existing formulations of
  1735   Isabelle/FOL or Isabelle/HOL may be taken as realistic examples.
  1736 
  1737   Generic tools may refer to the information provided by object-logic
  1738   declarations internally.
  1739 
  1740   @{rail \<open>
  1741     @@{command judgment} @{syntax name} '::' @{syntax type} @{syntax mixfix}?
  1742     ;
  1743     @@{attribute atomize} ('(' 'full' ')')?
  1744     ;
  1745     @@{attribute rule_format} ('(' 'noasm' ')')?
  1746   \<close>}
  1747 
  1748   \<^descr> @{command "judgment"}~\<open>c :: \<sigma> (mx)\<close> declares constant
  1749   \<open>c\<close> as the truth judgment of the current object-logic.  Its
  1750   type \<open>\<sigma>\<close> should specify a coercion of the category of
  1751   object-level propositions to \<open>prop\<close> of the Pure meta-logic;
  1752   the mixfix annotation \<open>(mx)\<close> would typically just link the
  1753   object language (internally of syntactic category \<open>logic\<close>)
  1754   with that of \<open>prop\<close>.  Only one @{command "judgment"}
  1755   declaration may be given in any theory development.
  1756   
  1757   \<^descr> @{method atomize} (as a method) rewrites any non-atomic
  1758   premises of a sub-goal, using the meta-level equations declared via
  1759   @{attribute atomize} (as an attribute) beforehand.  As a result,
  1760   heavily nested goals become amenable to fundamental operations such
  1761   as resolution (cf.\ the @{method (Pure) rule} method).  Giving the ``\<open>(full)\<close>'' option here means to turn the whole subgoal into an
  1762   object-statement (if possible), including the outermost parameters
  1763   and assumptions as well.
  1764 
  1765   A typical collection of @{attribute atomize} rules for a particular
  1766   object-logic would provide an internalization for each of the
  1767   connectives of \<open>\<And>\<close>, \<open>\<Longrightarrow>\<close>, and \<open>\<equiv>\<close>.
  1768   Meta-level conjunction should be covered as well (this is
  1769   particularly important for locales, see \secref{sec:locale}).
  1770 
  1771   \<^descr> @{attribute rule_format} rewrites a theorem by the equalities
  1772   declared as @{attribute rulify} rules in the current object-logic.
  1773   By default, the result is fully normalized, including assumptions
  1774   and conclusions at any depth.  The \<open>(no_asm)\<close> option
  1775   restricts the transformation to the conclusion of a rule.
  1776 
  1777   In common object-logics (HOL, FOL, ZF), the effect of @{attribute
  1778   rule_format} is to replace (bounded) universal quantification
  1779   (\<open>\<forall>\<close>) and implication (\<open>\<longrightarrow>\<close>) by the corresponding
  1780   rule statements over \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close>.
  1781 \<close>
  1782 
  1783 
  1784 section \<open>Tracing higher-order unification\<close>
  1785 
  1786 text \<open>
  1787   \begin{tabular}{rcll}
  1788     @{attribute_def unify_trace_simp} & : & \<open>attribute\<close> & default \<open>false\<close> \\
  1789     @{attribute_def unify_trace_types} & : & \<open>attribute\<close> & default \<open>false\<close> \\
  1790     @{attribute_def unify_trace_bound} & : & \<open>attribute\<close> & default \<open>50\<close> \\
  1791     @{attribute_def unify_search_bound} & : & \<open>attribute\<close> & default \<open>60\<close> \\
  1792   \end{tabular}
  1793   \<^medskip>
  1794 
  1795   Higher-order unification works well in most practical situations,
  1796   but sometimes needs extra care to identify problems.  These tracing
  1797   options may help.
  1798 
  1799   \<^descr> @{attribute unify_trace_simp} controls tracing of the
  1800   simplification phase of higher-order unification.
  1801 
  1802   \<^descr> @{attribute unify_trace_types} controls warnings of
  1803   incompleteness, when unification is not considering all possible
  1804   instantiations of schematic type variables.
  1805 
  1806   \<^descr> @{attribute unify_trace_bound} determines the depth where
  1807   unification starts to print tracing information once it reaches
  1808   depth; 0 for full tracing.  At the default value, tracing
  1809   information is almost never printed in practice.
  1810 
  1811   \<^descr> @{attribute unify_search_bound} prevents unification from
  1812   searching past the given depth.  Because of this bound, higher-order
  1813   unification cannot return an infinite sequence, though it can return
  1814   an exponentially long one.  The search rarely approaches the default
  1815   value in practice.  If the search is cut off, unification prints a
  1816   warning ``Unification bound exceeded''.
  1817 
  1818 
  1819   \begin{warn}
  1820   Options for unification cannot be modified in a local context.  Only
  1821   the global theory content is taken into account.
  1822   \end{warn}
  1823 \<close>
  1824 
  1825 end