isabelle update_cartouches -t;
authorwenzelm
Tue Oct 20 23:53:40 2015 +0200 (2015-10-20)
changeset 614930debd22f0c0e
parent 61492 3480725c71d2
child 61494 63b18f758874
isabelle update_cartouches -t;
src/Doc/Eisbach/Manual.thy
src/Doc/Implementation/Eq.thy
src/Doc/Implementation/Integration.thy
src/Doc/Implementation/Isar.thy
src/Doc/Implementation/Local_Theory.thy
src/Doc/Implementation/Logic.thy
src/Doc/Implementation/ML.thy
src/Doc/Implementation/Prelim.thy
src/Doc/Implementation/Proof.thy
src/Doc/Implementation/Syntax.thy
src/Doc/Implementation/Tactic.thy
src/Doc/Isar_Ref/Document_Preparation.thy
src/Doc/Isar_Ref/First_Order_Logic.thy
src/Doc/Isar_Ref/Framework.thy
src/Doc/Isar_Ref/Generic.thy
src/Doc/Isar_Ref/HOL_Specific.thy
src/Doc/Isar_Ref/Inner_Syntax.thy
src/Doc/Isar_Ref/Outer_Syntax.thy
src/Doc/Isar_Ref/Preface.thy
src/Doc/Isar_Ref/Proof.thy
src/Doc/Isar_Ref/Proof_Script.thy
src/Doc/Isar_Ref/Quick_Reference.thy
src/Doc/Isar_Ref/Spec.thy
src/Doc/Isar_Ref/Symbols.thy
src/Doc/Isar_Ref/Synopsis.thy
src/Doc/JEdit/JEdit.thy
src/Doc/System/Basics.thy
src/Doc/System/Misc.thy
src/Doc/System/Presentation.thy
src/Doc/System/Sessions.thy
     1.1 --- a/src/Doc/Eisbach/Manual.thy	Tue Oct 20 23:03:46 2015 +0200
     1.2 +++ b/src/Doc/Eisbach/Manual.thy	Tue Oct 20 23:53:40 2015 +0200
     1.3 @@ -56,11 +56,11 @@
     1.4        by prop_solver\<^sub>1
     1.5  
     1.6  text \<open>
     1.7 -  In this example, the facts @{text impI} and @{text conjE} are static. They
     1.8 +  In this example, the facts \<open>impI\<close> and \<open>conjE\<close> are static. They
     1.9    are evaluated once when the method is defined and cannot be changed later.
    1.10    This makes the method stable in the sense of \<^emph>\<open>static scoping\<close>: naming
    1.11 -  another fact @{text impI} in a later context won't affect the behaviour of
    1.12 -  @{text "prop_solver\<^sub>1"}.
    1.13 +  another fact \<open>impI\<close> in a later context won't affect the behaviour of
    1.14 +  \<open>prop_solver\<^sub>1\<close>.
    1.15  \<close>
    1.16  
    1.17  
    1.18 @@ -69,8 +69,8 @@
    1.19  text \<open>
    1.20    Methods can also abstract over terms using the @{keyword_def "for"} keyword,
    1.21    optionally providing type constraints. For instance, the following proof
    1.22 -  method @{text intro_ex} takes a term @{term y} of any type, which it uses to
    1.23 -  instantiate the @{term x}-variable of @{text exI} (existential introduction)
    1.24 +  method \<open>intro_ex\<close> takes a term @{term y} of any type, which it uses to
    1.25 +  instantiate the @{term x}-variable of \<open>exI\<close> (existential introduction)
    1.26    before applying the result as a rule. The instantiation is performed here by
    1.27    Isar's @{attribute_ref "where"} attribute. If the current subgoal is to find
    1.28    a witness for the given predicate @{term Q}, then this has the effect of
    1.29 @@ -100,7 +100,7 @@
    1.30  subsection \<open>Named theorems\<close>
    1.31  
    1.32  text \<open>
    1.33 -  A @{text "named theorem"} is a fact whose contents are produced dynamically
    1.34 +  A \<open>named theorem\<close> is a fact whose contents are produced dynamically
    1.35    within the current proof context. The Isar command @{command_ref
    1.36    "named_theorems"} provides simple access to this concept: it declares a
    1.37    dynamic fact with corresponding \<^emph>\<open>attribute\<close> for managing
    1.38 @@ -110,10 +110,9 @@
    1.39      named_theorems intros
    1.40  
    1.41  text \<open>
    1.42 -  So far @{text "intros"} refers to the empty fact. Using the Isar command
    1.43 +  So far \<open>intros\<close> refers to the empty fact. Using the Isar command
    1.44    @{command_ref "declare"} we may apply declaration attributes to the context.
    1.45 -  Below we declare both @{text "conjI"} and @{text "impI"} as @{text
    1.46 -  "intros"}, adding them to the named theorem slot.
    1.47 +  Below we declare both \<open>conjI\<close> and \<open>impI\<close> as \<open>intros\<close>, adding them to the named theorem slot.
    1.48  \<close>
    1.49  
    1.50      declare conjI [intros] and impI [intros]
    1.51 @@ -121,7 +120,7 @@
    1.52  text \<open>
    1.53    We can refer to named theorems as dynamic facts within a particular proof
    1.54    context, which are evaluated whenever the method is invoked. Instead of
    1.55 -  having facts hard-coded into the method, as in @{text prop_solver\<^sub>1}, we can
    1.56 +  having facts hard-coded into the method, as in \<open>prop_solver\<^sub>1\<close>, we can
    1.57    instead refer to these named theorems.
    1.58  \<close>
    1.59  
    1.60 @@ -137,8 +136,8 @@
    1.61  text \<open>
    1.62    Often these named theorems need to be augmented on the spot, when a method
    1.63    is invoked. The @{keyword_def "declares"} keyword in the signature of
    1.64 -  @{command method} adds the common method syntax @{text "method decl: facts"}
    1.65 -  for each named theorem @{text decl}.
    1.66 +  @{command method} adds the common method syntax \<open>method decl: facts\<close>
    1.67 +  for each named theorem \<open>decl\<close>.
    1.68  \<close>
    1.69  
    1.70      method prop_solver\<^sub>4 declares intros elims =
    1.71 @@ -171,11 +170,10 @@
    1.72  section \<open>Higher-order methods\<close>
    1.73  
    1.74  text \<open>
    1.75 -  The \<^emph>\<open>structured concatenation\<close> combinator ``@{text "method\<^sub>1 ;
    1.76 -  method\<^sub>2"}'' was introduced in Isabelle2015, motivated by development of
    1.77 -  Eisbach. It is similar to ``@{text "method\<^sub>1, method\<^sub>2"}'', but @{text
    1.78 -  method\<^sub>2} is invoked on on \<^emph>\<open>all\<close> subgoals that have newly emerged from
    1.79 -  @{text method\<^sub>1}. This is useful to handle cases where the number of
    1.80 +  The \<^emph>\<open>structured concatenation\<close> combinator ``\<open>method\<^sub>1 ;
    1.81 +  method\<^sub>2\<close>'' was introduced in Isabelle2015, motivated by development of
    1.82 +  Eisbach. It is similar to ``\<open>method\<^sub>1, method\<^sub>2\<close>'', but \<open>method\<^sub>2\<close> is invoked on on \<^emph>\<open>all\<close> subgoals that have newly emerged from
    1.83 +  \<open>method\<^sub>1\<close>. This is useful to handle cases where the number of
    1.84    subgoals produced by a method is determined dynamically at run-time.
    1.85  \<close>
    1.86  
    1.87 @@ -192,7 +190,7 @@
    1.88    method combinators with prefix syntax. For example, to more usefully exploit
    1.89    Isabelle's backtracking, the explicit requirement that a method solve all
    1.90    produced subgoals is frequently useful. This can easily be written as a
    1.91 -  \<^emph>\<open>higher-order method\<close> using ``@{text ";"}''. The @{keyword "methods"}
    1.92 +  \<^emph>\<open>higher-order method\<close> using ``\<open>;\<close>''. The @{keyword "methods"}
    1.93    keyword denotes method parameters that are other proof methods to be invoked
    1.94    by the method being defined.
    1.95  \<close>
    1.96 @@ -200,9 +198,9 @@
    1.97      method solve methods m = (m ; fail)
    1.98  
    1.99  text \<open>
   1.100 -  Given some method-argument @{text m}, @{text "solve \<open>m\<close>"} applies the
   1.101 -  method @{text m} and then fails whenever @{text m} produces any new unsolved
   1.102 -  subgoals --- i.e. when @{text m} fails to completely discharge the goal it
   1.103 +  Given some method-argument \<open>m\<close>, \<open>solve \<open>m\<close>\<close> applies the
   1.104 +  method \<open>m\<close> and then fails whenever \<open>m\<close> produces any new unsolved
   1.105 +  subgoals --- i.e. when \<open>m\<close> fails to completely discharge the goal it
   1.106    was applied to.
   1.107  \<close>
   1.108  
   1.109 @@ -224,10 +222,10 @@
   1.110          (erule notE ; solve \<open>prop_solver\<close>))+
   1.111  
   1.112  text \<open>
   1.113 -  The only non-trivial part above is the final alternative @{text "(erule notE
   1.114 -  ; solve \<open>prop_solver\<close>)"}. Here, in the case that all other alternatives
   1.115 +  The only non-trivial part above is the final alternative \<open>(erule notE
   1.116 +  ; solve \<open>prop_solver\<close>)\<close>. Here, in the case that all other alternatives
   1.117    fail, the method takes one of the assumptions @{term "\<not> P"} of the current
   1.118 -  goal and eliminates it with the rule @{text notE}, causing the goal to be
   1.119 +  goal and eliminates it with the rule \<open>notE\<close>, causing the goal to be
   1.120    proved to become @{term P}. The method then recursively invokes itself on
   1.121    the remaining goals. The job of the recursive call is to demonstrate that
   1.122    there is a contradiction in the original assumptions (i.e.\ that @{term P}
   1.123 @@ -238,8 +236,7 @@
   1.124    chosen for elimination.
   1.125  
   1.126    Note that the recursive call to @{method prop_solver} does not have any
   1.127 -  parameters passed to it. Recall that fact parameters, e.g.\ @{text
   1.128 -  "intros"}, @{text "elims"}, and @{text "subst"}, are managed by declarations
   1.129 +  parameters passed to it. Recall that fact parameters, e.g.\ \<open>intros\<close>, \<open>elims\<close>, and \<open>subst\<close>, are managed by declarations
   1.130    in the current proof context. They will therefore be passed to any recursive
   1.131    call to @{method prop_solver} and, more generally, any invocation of a
   1.132    method which declares these named theorems.
   1.133 @@ -299,11 +296,10 @@
   1.134    \<close>}
   1.135  
   1.136    Matching allows methods to introspect the goal state, and to implement more
   1.137 -  explicit control flow. In the basic case, a term or fact @{text ts} is given
   1.138 +  explicit control flow. In the basic case, a term or fact \<open>ts\<close> is given
   1.139    to match against as a \<^emph>\<open>match target\<close>, along with a collection of
   1.140 -  pattern-method pairs @{text "(p, m)"}: roughly speaking, when the pattern
   1.141 -  @{text p} matches any member of @{text ts}, the \<^emph>\<open>inner\<close> method @{text
   1.142 -  m} will be executed.
   1.143 +  pattern-method pairs \<open>(p, m)\<close>: roughly speaking, when the pattern
   1.144 +  \<open>p\<close> matches any member of \<open>ts\<close>, the \<^emph>\<open>inner\<close> method \<open>m\<close> will be executed.
   1.145  \<close>
   1.146  
   1.147      lemma
   1.148 @@ -315,9 +311,9 @@
   1.149  
   1.150  text \<open>
   1.151    In this example we have a structured Isar proof, with the named
   1.152 -  assumption @{text "X"} and a conclusion @{term "P"}. With the match method
   1.153 +  assumption \<open>X\<close> and a conclusion @{term "P"}. With the match method
   1.154    we can find the local facts @{term "Q \<longrightarrow> P"} and @{term "Q"}, binding them to
   1.155 -  separately as @{text "I"} and @{text "I'"}. We then specialize the
   1.156 +  separately as \<open>I\<close> and \<open>I'\<close>. We then specialize the
   1.157    modus-ponens rule @{thm mp [of Q P]} to these facts to solve the goal.
   1.158  \<close>
   1.159  
   1.160 @@ -362,7 +358,7 @@
   1.161    now-bound @{term A} (bound to @{term P}) against the conclusion (also @{term
   1.162    P}), finally applying the specialized rule to solve the goal.
   1.163  
   1.164 -  Schematic terms like @{text "?P"} may also be used to specify match
   1.165 +  Schematic terms like \<open>?P\<close> may also be used to specify match
   1.166    variables, but the result of the match is not bound, and thus cannot be used
   1.167    in the inner method body.
   1.168  
   1.169 @@ -382,11 +378,11 @@
   1.170  text \<open>
   1.171    The first @{method match} matches the pattern @{term "\<exists>x. Q x"} against the
   1.172    current conclusion, binding the term @{term "Q"} in the inner match. Next
   1.173 -  the pattern @{text "Q y"} is matched against all premises of the current
   1.174 +  the pattern \<open>Q y\<close> is matched against all premises of the current
   1.175    subgoal. In this case @{term "Q"} is fixed and @{term "y"} may be
   1.176 -  instantiated. Once a match is found, the local fact @{text U} is bound to
   1.177 +  instantiated. Once a match is found, the local fact \<open>U\<close> is bound to
   1.178    the matching premise and the variable @{term "y"} is bound to the matching
   1.179 -  witness. The existential introduction rule @{text "exI:"}~@{thm exI} is then
   1.180 +  witness. The existential introduction rule \<open>exI:\<close>~@{thm exI} is then
   1.181    instantiated with @{term "y"} as the witness and @{term "Q"} as the
   1.182    predicate, with its proof obligation solved by the local fact U (using the
   1.183    Isar attribute @{attribute OF}). The following example is a trivial use of
   1.184 @@ -426,8 +422,8 @@
   1.185    fail. If focusing instead left the premises in place, using methods
   1.186    like @{method erule} would lead to unintended behaviour, specifically during
   1.187    backtracking. In our example, @{method erule} could choose an alternate
   1.188 -  premise while backtracking, while leaving @{text I} bound to the original
   1.189 -  match. In the case of more complex inner methods, where either @{text I} or
   1.190 +  premise while backtracking, while leaving \<open>I\<close> bound to the original
   1.191 +  match. In the case of more complex inner methods, where either \<open>I\<close> or
   1.192    bound terms are used, this would almost certainly not be the intended
   1.193    behaviour.
   1.194  
   1.195 @@ -451,7 +447,7 @@
   1.196    matched premises may be declared with the @{attribute "thin"} attribute.
   1.197    This will hide the premise from subsequent inner matches, and remove it from
   1.198    the list of premises when the inner method has finished and the subgoal is
   1.199 -  unfocused. It can be considered analogous to the existing @{text thin_tac}.
   1.200 +  unfocused. It can be considered analogous to the existing \<open>thin_tac\<close>.
   1.201  
   1.202    To complete our example, the correct implementation of the method
   1.203    will @{attribute "thin"} the premise from the match and then apply it to the
   1.204 @@ -491,10 +487,10 @@
   1.205  
   1.206  text \<open>
   1.207    In this example, the only premise that exists in the first focus is
   1.208 -  @{term "A"}. Prior to the inner match, the rule @{text impI} changes
   1.209 +  @{term "A"}. Prior to the inner match, the rule \<open>impI\<close> changes
   1.210    the goal @{term "B \<longrightarrow> B"} into @{term "B \<Longrightarrow> B"}. A standard premise
   1.211    match would also include @{term A} as an original premise of the outer
   1.212 -  match. The @{text local} argument limits the match to
   1.213 +  match. The \<open>local\<close> argument limits the match to
   1.214    newly focused premises.
   1.215  
   1.216  \<close>
   1.217 @@ -563,8 +559,7 @@
   1.218              \<open>rule I [of x y]\<close>)
   1.219  
   1.220  text \<open>
   1.221 -  In this example, the order of schematics in @{text asm} is actually @{text
   1.222 -  "?y ?x"}, but we instantiate our matched rule in the opposite order. This is
   1.223 +  In this example, the order of schematics in \<open>asm\<close> is actually \<open>?y ?x\<close>, but we instantiate our matched rule in the opposite order. This is
   1.224    because the effective rule @{term I} was bound from the match, which
   1.225    declared the @{typ 'a} slot first and the @{typ 'b} slot second.
   1.226  
   1.227 @@ -592,7 +587,7 @@
   1.228              \<open>prop_solver\<close>)
   1.229  
   1.230  text \<open>
   1.231 -  In this example, the pattern @{text "\<And>x :: 'a. ?P x \<Longrightarrow> ?Q x"} matches against
   1.232 +  In this example, the pattern \<open>\<And>x :: 'a. ?P x \<Longrightarrow> ?Q x\<close> matches against
   1.233    the only premise, giving an appropriately typed slot for @{term y}. After
   1.234    the match, the resulting rule is instantiated to @{term y} and then declared
   1.235    as an @{attribute intros} rule. This is then picked up by @{method
   1.236 @@ -606,8 +601,7 @@
   1.237    In all previous examples, @{method match} was only ever searching for a
   1.238    single rule or premise. Each local fact would therefore always have a length
   1.239    of exactly one. We may, however, wish to find \<^emph>\<open>all\<close> matching results.
   1.240 -  To achieve this, we can simply mark a given pattern with the @{text
   1.241 -  "(multi)"} argument.
   1.242 +  To achieve this, we can simply mark a given pattern with the \<open>(multi)\<close> argument.
   1.243  \<close>
   1.244  
   1.245      lemma
   1.246 @@ -618,18 +612,18 @@
   1.247        done
   1.248  
   1.249  text \<open>
   1.250 -  In the first @{method match}, without the @{text "(multi)"} argument, @{term
   1.251 -  I} is only ever be bound to one of the members of @{text asms}. This
   1.252 +  In the first @{method match}, without the \<open>(multi)\<close> argument, @{term
   1.253 +  I} is only ever be bound to one of the members of \<open>asms\<close>. This
   1.254    backtracks over both possibilities (see next section), however neither
   1.255    assumption in isolation is sufficient to solve to goal. The use of the
   1.256    @{method solves} combinator ensures that @{method prop_solver} has no effect
   1.257    on the goal when it doesn't solve it, and so the first match leaves the goal
   1.258 -  unchanged. In the second @{method match}, @{text I} is bound to all of
   1.259 -  @{text asms}, declaring both results as @{text intros}. With these rules
   1.260 +  unchanged. In the second @{method match}, \<open>I\<close> is bound to all of
   1.261 +  \<open>asms\<close>, declaring both results as \<open>intros\<close>. With these rules
   1.262    @{method prop_solver} is capable of solving the goal.
   1.263  
   1.264    Using for-fixed variables in patterns imposes additional constraints on the
   1.265 -  results. In all previous examples, the choice of using @{text ?P} or a
   1.266 +  results. In all previous examples, the choice of using \<open>?P\<close> or a
   1.267    for-fixed @{term P} only depended on whether or not @{term P} was mentioned
   1.268    in another pattern or the inner method. When using a multi-match, however,
   1.269    all for-fixed terms must agree in the results.
   1.270 @@ -647,9 +641,9 @@
   1.271  text \<open>
   1.272    Here we have two seemingly-equivalent applications of @{method match},
   1.273    however only the second one is capable of solving the goal. The first
   1.274 -  @{method match} selects the first and third members of @{text asms} (those
   1.275 +  @{method match} selects the first and third members of \<open>asms\<close> (those
   1.276    that agree on their conclusion), which is not sufficient. The second
   1.277 -  @{method match} selects the first and second members of @{text asms} (those
   1.278 +  @{method match} selects the first and second members of \<open>asms\<close> (those
   1.279    that agree on their assumption), which is enough for @{method prop_solver}
   1.280    to solve the goal.
   1.281  \<close>
   1.282 @@ -661,10 +655,10 @@
   1.283    Dummy patterns may be given as placeholders for unique schematics in
   1.284    patterns. They implicitly receive all currently bound variables as
   1.285    arguments, and are coerced into the @{typ prop} type whenever possible. For
   1.286 -  example, the trivial dummy pattern @{text "_"} will match any proposition.
   1.287 -  In contrast, by default the pattern @{text "?P"} is considered to have type
   1.288 +  example, the trivial dummy pattern \<open>_\<close> will match any proposition.
   1.289 +  In contrast, by default the pattern \<open>?P\<close> is considered to have type
   1.290    @{typ bool}. It will not bind anything with meta-logical connectives (e.g.
   1.291 -  @{text "_ \<Longrightarrow> _"} or @{text "_ &&& _"}).
   1.292 +  \<open>_ \<Longrightarrow> _\<close> or \<open>_ &&& _\<close>).
   1.293  \<close>
   1.294  
   1.295      lemma
   1.296 @@ -676,17 +670,17 @@
   1.297  section \<open>Backtracking\<close>
   1.298  
   1.299  text \<open>
   1.300 -  Patterns are considered top-down, executing the inner method @{text m} of
   1.301 +  Patterns are considered top-down, executing the inner method \<open>m\<close> of
   1.302    the first pattern which is satisfied by the current match target. By
   1.303    default, matching performs extensive backtracking by attempting all valid
   1.304    variable and fact bindings according to the given pattern. In particular,
   1.305    all unifiers for a given pattern will be explored, as well as each matching
   1.306 -  fact. The inner method @{text m} will be re-executed for each different
   1.307 +  fact. The inner method \<open>m\<close> will be re-executed for each different
   1.308    variable/fact binding during backtracking. A successful match is considered
   1.309    a cut-point for backtracking. Specifically, once a match is made no other
   1.310    pattern-method pairs will be considered.
   1.311  
   1.312 -  The method @{text foo} below fails for all goals that are conjunctions. Any
   1.313 +  The method \<open>foo\<close> below fails for all goals that are conjunctions. Any
   1.314    such goal will match the first pattern, causing the second pattern (that
   1.315    would otherwise match all goals) to never be considered.
   1.316  \<close>
   1.317 @@ -701,8 +695,7 @@
   1.318    combinator chain, its failure
   1.319    becomes significant because it signals previously applied methods to move to
   1.320    the next result. Therefore, it is necessary for @{method match} to not mask
   1.321 -  such failure. One can always rewrite a match using the combinators ``@{text
   1.322 -  "?"}'' and ``@{text "|"}'' to try subsequent patterns in the case of an
   1.323 +  such failure. One can always rewrite a match using the combinators ``\<open>?\<close>'' and ``\<open>|\<close>'' to try subsequent patterns in the case of an
   1.324    inner-method failure. The following proof method, for example, always
   1.325    invokes @{method prop_solver} for all goals because its first alternative
   1.326    either never matches or (if it does match) always fails.
   1.327 @@ -717,7 +710,7 @@
   1.328  
   1.329  text \<open>
   1.330    Backtracking may be controlled more precisely by marking individual patterns
   1.331 -  as @{text cut}. This causes backtracking to not progress beyond this pattern:
   1.332 +  as \<open>cut\<close>. This causes backtracking to not progress beyond this pattern:
   1.333    once a match is found no others will be considered.
   1.334  \<close>
   1.335  
   1.336 @@ -730,7 +723,7 @@
   1.337    implications of @{term "P"} in the premises are considered, evaluating the
   1.338    inner @{method rule} with each consequent. No other conjunctions will be
   1.339    considered, with method failure occurring once all implications of the
   1.340 -  form @{text "P \<longrightarrow> ?U"} have been explored. Here the left-right processing of
   1.341 +  form \<open>P \<longrightarrow> ?U\<close> have been explored. Here the left-right processing of
   1.342    individual patterns is important, as all patterns after of the cut will
   1.343    maintain their usual backtracking behaviour.
   1.344  \<close>
   1.345 @@ -742,16 +735,16 @@
   1.346        by (foo\<^sub>2 | prop_solver)
   1.347  
   1.348  text \<open>
   1.349 -  In this example, the first lemma is solved by @{text foo\<^sub>2}, by first
   1.350 -  picking @{term "A \<longrightarrow> D"} for @{text I'}, then backtracking and ultimately
   1.351 +  In this example, the first lemma is solved by \<open>foo\<^sub>2\<close>, by first
   1.352 +  picking @{term "A \<longrightarrow> D"} for \<open>I'\<close>, then backtracking and ultimately
   1.353    succeeding after picking @{term "A \<longrightarrow> C"}. In the second lemma, however,
   1.354    @{term "C \<and> D"} is matched first, the second pattern in the match cannot be
   1.355    found and so the method fails, falling through to @{method prop_solver}.
   1.356  
   1.357    More precise control is also possible by giving a positive
   1.358 -  number @{text n} as an argument to @{text cut}. This will limit the number
   1.359 -  of backtracking results of that match to be at most @{text n}.
   1.360 -  The match argument @{text "(cut 1)"} is the same as simply @{text "(cut)"}.
   1.361 +  number \<open>n\<close> as an argument to \<open>cut\<close>. This will limit the number
   1.362 +  of backtracking results of that match to be at most \<open>n\<close>.
   1.363 +  The match argument \<open>(cut 1)\<close> is the same as simply \<open>(cut)\<close>.
   1.364  \<close>
   1.365  
   1.366  
   1.367 @@ -776,16 +769,14 @@
   1.368  
   1.369  text \<open>
   1.370    Intuitively it seems like this proof should fail to check. The first match
   1.371 -  result, which binds @{term I} to the first two members of @{text asms},
   1.372 +  result, which binds @{term I} to the first two members of \<open>asms\<close>,
   1.373    fails the second inner match due to binding @{term P} to @{term A}.
   1.374 -  Backtracking then attempts to bind @{term I} to the third member of @{text
   1.375 -  asms}. This passes all inner matches, but fails when @{method rule} cannot
   1.376 +  Backtracking then attempts to bind @{term I} to the third member of \<open>asms\<close>. This passes all inner matches, but fails when @{method rule} cannot
   1.377    successfully apply this to the current goal. After this, a valid match that
   1.378 -  is produced by the unifier is one which binds @{term P} to simply @{text
   1.379 -  "\<lambda>a. A ?x"}. The first inner match succeeds because @{text "\<lambda>a. A ?x"} does
   1.380 +  is produced by the unifier is one which binds @{term P} to simply \<open>\<lambda>a. A ?x\<close>. The first inner match succeeds because \<open>\<lambda>a. A ?x\<close> does
   1.381    not match @{term A}. The next inner match succeeds because @{term I} has
   1.382 -  only been bound to the first member of @{text asms}. This is due to @{method
   1.383 -  match} considering @{text "\<lambda>a. A ?x"} and @{text "\<lambda>a. A ?y"} as distinct
   1.384 +  only been bound to the first member of \<open>asms\<close>. This is due to @{method
   1.385 +  match} considering \<open>\<lambda>a. A ?x\<close> and \<open>\<lambda>a. A ?y\<close> as distinct
   1.386    terms.
   1.387  
   1.388    The simplest way to address this is to explicitly disallow term bindings
   1.389 @@ -807,7 +798,7 @@
   1.390    The @{method match} method is not aware of the logical content of match
   1.391    targets. Each pattern is simply matched against the shallow structure of a
   1.392    fact or term. Most facts are in \<^emph>\<open>normal form\<close>, which curries premises
   1.393 -  via meta-implication @{text "_ \<Longrightarrow> _"}.
   1.394 +  via meta-implication \<open>_ \<Longrightarrow> _\<close>.
   1.395  \<close>
   1.396  
   1.397      lemma
   1.398 @@ -816,7 +807,7 @@
   1.399        by (match asms in H: "D \<Longrightarrow> _" (multi) \<Rightarrow> \<open>prop_solver elims: H\<close>)
   1.400  
   1.401  text \<open>
   1.402 -  For the first member of @{text asms} the dummy pattern successfully matches
   1.403 +  For the first member of \<open>asms\<close> the dummy pattern successfully matches
   1.404    against @{term "B \<Longrightarrow> C"} and so the proof is successful.
   1.405  \<close>
   1.406  
   1.407 @@ -830,7 +821,7 @@
   1.408  text \<open>
   1.409    This proof will fail to solve the goal. Our match pattern will only match
   1.410    rules which have a single premise, and conclusion @{term C}, so the first
   1.411 -  member of @{text asms} is not bound and thus the proof fails. Matching a
   1.412 +  member of \<open>asms\<close> is not bound and thus the proof fails. Matching a
   1.413    pattern of the form @{term "P \<Longrightarrow> Q"} against this fact will bind @{term "P"}
   1.414    to @{term "A"} and @{term Q} to @{term "B \<Longrightarrow> C"}. Our pattern, with a
   1.415    concrete @{term "C"} in the conclusion, will fail to match this fact.
   1.416 @@ -839,7 +830,7 @@
   1.417    matching against them. This forms a meta-conjunction of all premises in a
   1.418    fact, so that only one implication remains. For example the uncurried
   1.419    version of @{term "A \<Longrightarrow> B \<Longrightarrow> C"} is @{term "A &&& B \<Longrightarrow> C"}. This will now match
   1.420 -  our desired pattern @{text "_ \<Longrightarrow> C"}, and can be \<^emph>\<open>curried\<close> after the
   1.421 +  our desired pattern \<open>_ \<Longrightarrow> C\<close>, and can be \<^emph>\<open>curried\<close> after the
   1.422    match to put it back into normal form.
   1.423  \<close>
   1.424  
   1.425 @@ -867,11 +858,11 @@
   1.426        done
   1.427  
   1.428  text \<open>
   1.429 -  In the first @{method match} we attempt to find a member of @{text asms}
   1.430 +  In the first @{method match} we attempt to find a member of \<open>asms\<close>
   1.431    which matches our goal precisely. This fails due to no such member existing.
   1.432    The second match reverses the role of the fact in the match, by first giving
   1.433    a general pattern @{term P}. This bound pattern is then matched against
   1.434 -  @{term "A y"}. In this case, @{term P} is bound to @{text "A ?x"} and so it
   1.435 +  @{term "A y"}. In this case, @{term P} is bound to \<open>A ?x\<close> and so it
   1.436    successfully matches.
   1.437  \<close>
   1.438  
   1.439 @@ -892,10 +883,9 @@
   1.440            \<open>match (y) in "y :: 'b" for y \<Rightarrow> \<open>rule H [where z = y]\<close>\<close>)
   1.441  
   1.442  text \<open>
   1.443 -  In this example the type @{text 'b} is matched to @{text 'a}, however
   1.444 -  statically they are formally distinct types. The first match binds @{text
   1.445 -  'b} while the inner match serves to coerce @{term y} into having the type
   1.446 -  @{text 'b}. This allows the rule instantiation to successfully apply.
   1.447 +  In this example the type \<open>'b\<close> is matched to \<open>'a\<close>, however
   1.448 +  statically they are formally distinct types. The first match binds \<open>'b\<close> while the inner match serves to coerce @{term y} into having the type
   1.449 +  \<open>'b\<close>. This allows the rule instantiation to successfully apply.
   1.450  \<close>
   1.451  
   1.452  
   1.453 @@ -932,7 +922,7 @@
   1.454  
   1.455  text \<open>
   1.456    A custom rule attribute is a simple way to extend the functionality of
   1.457 -  Eisbach methods. The dummy rule attribute notation (@{text "[[ _ ]]"})
   1.458 +  Eisbach methods. The dummy rule attribute notation (\<open>[[ _ ]]\<close>)
   1.459    invokes the given attribute against a dummy fact and evaluates to the result
   1.460    of that attribute. When used as a match target, this can serve as an
   1.461    effective auxiliary function.
   1.462 @@ -968,7 +958,7 @@
   1.463    Here the new @{method splits} method transforms the goal to use only logical
   1.464    connectives: @{term "L = [] \<longrightarrow> False \<and> (\<forall>x y. L = x # y \<longrightarrow> True)"}. This goal
   1.465    is then in a form solvable by @{method prop_solver} when given the universal
   1.466 -  quantifier introduction rule @{text allI}.
   1.467 +  quantifier introduction rule \<open>allI\<close>.
   1.468  \<close>
   1.469  
   1.470  end
     2.1 --- a/src/Doc/Implementation/Eq.thy	Tue Oct 20 23:03:46 2015 +0200
     2.2 +++ b/src/Doc/Implementation/Eq.thy	Tue Oct 20 23:53:40 2015 +0200
     2.3 @@ -6,7 +6,7 @@
     2.4  
     2.5  text \<open>Equality is one of the most fundamental concepts of
     2.6    mathematics.  The Isabelle/Pure logic (\chref{ch:logic}) provides a
     2.7 -  builtin relation @{text "\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop"} that expresses equality
     2.8 +  builtin relation \<open>\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop\<close> that expresses equality
     2.9    of arbitrary terms (or propositions) at the framework level, as
    2.10    expressed by certain basic inference rules (\secref{sec:eq-rules}).
    2.11  
    2.12 @@ -18,7 +18,7 @@
    2.13  
    2.14    Higher-order matching is able to provide suitable instantiations for
    2.15    giving equality rules, which leads to the versatile concept of
    2.16 -  @{text "\<lambda>"}-term rewriting (\secref{sec:rewriting}).  Internally
    2.17 +  \<open>\<lambda>\<close>-term rewriting (\secref{sec:rewriting}).  Internally
    2.18    this is based on the general-purpose Simplifier engine of Isabelle,
    2.19    which is more specific and more efficient than plain conversions.
    2.20  
    2.21 @@ -31,10 +31,10 @@
    2.22  
    2.23  section \<open>Basic equality rules \label{sec:eq-rules}\<close>
    2.24  
    2.25 -text \<open>Isabelle/Pure uses @{text "\<equiv>"} for equality of arbitrary
    2.26 +text \<open>Isabelle/Pure uses \<open>\<equiv>\<close> for equality of arbitrary
    2.27    terms, which includes equivalence of propositions of the logical
    2.28 -  framework.  The conceptual axiomatization of the constant @{text "\<equiv>
    2.29 -  :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop"} is given in \figref{fig:pure-equality}.  The
    2.30 +  framework.  The conceptual axiomatization of the constant \<open>\<equiv>
    2.31 +  :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop\<close> is given in \figref{fig:pure-equality}.  The
    2.32    inference kernel presents slightly different equality rules, which
    2.33    may be understood as derived rules from this minimal axiomatization.
    2.34    The Pure theory also provides some theorems that express the same
    2.35 @@ -42,15 +42,14 @@
    2.36    rules as explained in \secref{sec:obj-rules}.
    2.37  
    2.38    For example, @{ML Thm.symmetric} as Pure inference is an ML function
    2.39 -  that maps a theorem @{text "th"} stating @{text "t \<equiv> u"} to one
    2.40 -  stating @{text "u \<equiv> t"}.  In contrast, @{thm [source]
    2.41 +  that maps a theorem \<open>th\<close> stating \<open>t \<equiv> u\<close> to one
    2.42 +  stating \<open>u \<equiv> t\<close>.  In contrast, @{thm [source]
    2.43    Pure.symmetric} as Pure theorem expresses the same reasoning in
    2.44 -  declarative form.  If used like @{text "th [THEN Pure.symmetric]"}
    2.45 +  declarative form.  If used like \<open>th [THEN Pure.symmetric]\<close>
    2.46    in Isar source notation, it achieves a similar effect as the ML
    2.47    inference function, although the rule attribute @{attribute THEN} or
    2.48    ML operator @{ML "op RS"} involve the full machinery of higher-order
    2.49 -  unification (modulo @{text "\<beta>\<eta>"}-conversion) and lifting of @{text
    2.50 -  "\<And>/\<Longrightarrow>"} contexts.\<close>
    2.51 +  unification (modulo \<open>\<beta>\<eta>\<close>-conversion) and lifting of \<open>\<And>/\<Longrightarrow>\<close> contexts.\<close>
    2.52  
    2.53  text %mlref \<open>
    2.54    \begin{mldecls}
    2.55 @@ -64,8 +63,8 @@
    2.56    \end{mldecls}
    2.57  
    2.58    See also @{file "~~/src/Pure/thm.ML" } for further description of
    2.59 -  these inference rules, and a few more for primitive @{text "\<beta>"} and
    2.60 -  @{text "\<eta>"} conversions.  Note that @{text "\<alpha>"} conversion is
    2.61 +  these inference rules, and a few more for primitive \<open>\<beta>\<close> and
    2.62 +  \<open>\<eta>\<close> conversions.  Note that \<open>\<alpha>\<close> conversion is
    2.63    implicit due to the representation of terms with de-Bruijn indices
    2.64    (\secref{sec:terms}).\<close>
    2.65  
    2.66 @@ -83,10 +82,10 @@
    2.67  section \<open>Rewriting \label{sec:rewriting}\<close>
    2.68  
    2.69  text \<open>Rewriting normalizes a given term (theorem or goal) by
    2.70 -  replacing instances of given equalities @{text "t \<equiv> u"} in subterms.
    2.71 +  replacing instances of given equalities \<open>t \<equiv> u\<close> in subterms.
    2.72    Rewriting continues until no rewrites are applicable to any subterm.
    2.73 -  This may be used to unfold simple definitions of the form @{text "f
    2.74 -  x\<^sub>1 \<dots> x\<^sub>n \<equiv> u"}, but is slightly more general than that.
    2.75 +  This may be used to unfold simple definitions of the form \<open>f
    2.76 +  x\<^sub>1 \<dots> x\<^sub>n \<equiv> u\<close>, but is slightly more general than that.
    2.77  \<close>
    2.78  
    2.79  text %mlref \<open>
    2.80 @@ -98,23 +97,22 @@
    2.81    @{index_ML fold_goals_tac: "Proof.context -> thm list -> tactic"} \\
    2.82    \end{mldecls}
    2.83  
    2.84 -  \<^descr> @{ML rewrite_rule}~@{text "ctxt rules thm"} rewrites the whole
    2.85 +  \<^descr> @{ML rewrite_rule}~\<open>ctxt rules thm\<close> rewrites the whole
    2.86    theorem by the given rules.
    2.87  
    2.88 -  \<^descr> @{ML rewrite_goals_rule}~@{text "ctxt rules thm"} rewrites the
    2.89 +  \<^descr> @{ML rewrite_goals_rule}~\<open>ctxt rules thm\<close> rewrites the
    2.90    outer premises of the given theorem.  Interpreting the same as a
    2.91    goal state (\secref{sec:tactical-goals}) it means to rewrite all
    2.92    subgoals (in the same manner as @{ML rewrite_goals_tac}).
    2.93  
    2.94 -  \<^descr> @{ML rewrite_goal_tac}~@{text "ctxt rules i"} rewrites subgoal
    2.95 -  @{text "i"} by the given rewrite rules.
    2.96 +  \<^descr> @{ML rewrite_goal_tac}~\<open>ctxt rules i\<close> rewrites subgoal
    2.97 +  \<open>i\<close> by the given rewrite rules.
    2.98  
    2.99 -  \<^descr> @{ML rewrite_goals_tac}~@{text "ctxt rules"} rewrites all subgoals
   2.100 +  \<^descr> @{ML rewrite_goals_tac}~\<open>ctxt rules\<close> rewrites all subgoals
   2.101    by the given rewrite rules.
   2.102  
   2.103 -  \<^descr> @{ML fold_goals_tac}~@{text "ctxt rules"} essentially uses @{ML
   2.104 -  rewrite_goals_tac} with the symmetric form of each member of @{text
   2.105 -  "rules"}, re-ordered to fold longer expression first.  This supports
   2.106 +  \<^descr> @{ML fold_goals_tac}~\<open>ctxt rules\<close> essentially uses @{ML
   2.107 +  rewrite_goals_tac} with the symmetric form of each member of \<open>rules\<close>, re-ordered to fold longer expression first.  This supports
   2.108    to idea to fold primitive definitions that appear in expended form
   2.109    in the proof state.
   2.110  \<close>
     3.1 --- a/src/Doc/Implementation/Integration.thy	Tue Oct 20 23:03:46 2015 +0200
     3.2 +++ b/src/Doc/Implementation/Integration.thy	Tue Oct 20 23:53:40 2015 +0200
     3.3 @@ -23,8 +23,7 @@
     3.4  subsection \<open>Toplevel state\<close>
     3.5  
     3.6  text \<open>
     3.7 -  The toplevel state is a disjoint sum of empty @{text toplevel}, or @{text
     3.8 -  theory}, or @{text proof}. The initial toplevel is empty; a theory is
     3.9 +  The toplevel state is a disjoint sum of empty \<open>toplevel\<close>, or \<open>theory\<close>, or \<open>proof\<close>. The initial toplevel is empty; a theory is
    3.10    commenced by a @{command theory} header; within a theory we may use theory
    3.11    commands such as @{command definition}, or state a @{command theorem} to be
    3.12    proven. A proof state accepts a rich collection of Isar proof commands for
    3.13 @@ -52,23 +51,23 @@
    3.14    operations.  Many operations work only partially for certain cases,
    3.15    since @{ML_type Toplevel.state} is a sum type.
    3.16  
    3.17 -  \<^descr> @{ML Toplevel.is_toplevel}~@{text "state"} checks for an empty
    3.18 +  \<^descr> @{ML Toplevel.is_toplevel}~\<open>state\<close> checks for an empty
    3.19    toplevel state.
    3.20  
    3.21 -  \<^descr> @{ML Toplevel.theory_of}~@{text "state"} selects the
    3.22 -  background theory of @{text "state"}, it raises @{ML Toplevel.UNDEF}
    3.23 +  \<^descr> @{ML Toplevel.theory_of}~\<open>state\<close> selects the
    3.24 +  background theory of \<open>state\<close>, it raises @{ML Toplevel.UNDEF}
    3.25    for an empty toplevel state.
    3.26  
    3.27 -  \<^descr> @{ML Toplevel.proof_of}~@{text "state"} selects the Isar proof
    3.28 +  \<^descr> @{ML Toplevel.proof_of}~\<open>state\<close> selects the Isar proof
    3.29    state if available, otherwise it raises an error.
    3.30  \<close>
    3.31  
    3.32  text %mlantiq \<open>
    3.33    \begin{matharray}{rcl}
    3.34 -  @{ML_antiquotation_def "Isar.state"} & : & @{text ML_antiquotation} \\
    3.35 +  @{ML_antiquotation_def "Isar.state"} & : & \<open>ML_antiquotation\<close> \\
    3.36    \end{matharray}
    3.37  
    3.38 -  \<^descr> @{text "@{Isar.state}"} refers to Isar toplevel state at that
    3.39 +  \<^descr> \<open>@{Isar.state}\<close> refers to Isar toplevel state at that
    3.40    point --- as abstract value.
    3.41  
    3.42    This only works for diagnostic ML commands, such as @{command
    3.43 @@ -113,27 +112,27 @@
    3.44    Toplevel.transition -> Toplevel.transition"} \\
    3.45    \end{mldecls}
    3.46  
    3.47 -  \<^descr> @{ML Toplevel.keep}~@{text "tr"} adjoins a diagnostic
    3.48 +  \<^descr> @{ML Toplevel.keep}~\<open>tr\<close> adjoins a diagnostic
    3.49    function.
    3.50  
    3.51 -  \<^descr> @{ML Toplevel.theory}~@{text "tr"} adjoins a theory
    3.52 +  \<^descr> @{ML Toplevel.theory}~\<open>tr\<close> adjoins a theory
    3.53    transformer.
    3.54  
    3.55 -  \<^descr> @{ML Toplevel.theory_to_proof}~@{text "tr"} adjoins a global
    3.56 +  \<^descr> @{ML Toplevel.theory_to_proof}~\<open>tr\<close> adjoins a global
    3.57    goal function, which turns a theory into a proof state.  The theory
    3.58    may be changed before entering the proof; the generic Isar goal
    3.59    setup includes an @{verbatim after_qed} argument that specifies how to
    3.60    apply the proven result to the enclosing context, when the proof
    3.61    is finished.
    3.62  
    3.63 -  \<^descr> @{ML Toplevel.proof}~@{text "tr"} adjoins a deterministic
    3.64 +  \<^descr> @{ML Toplevel.proof}~\<open>tr\<close> adjoins a deterministic
    3.65    proof command, with a singleton result.
    3.66  
    3.67 -  \<^descr> @{ML Toplevel.proofs}~@{text "tr"} adjoins a general proof
    3.68 +  \<^descr> @{ML Toplevel.proofs}~\<open>tr\<close> adjoins a general proof
    3.69    command, with zero or more result states (represented as a lazy
    3.70    list).
    3.71  
    3.72 -  \<^descr> @{ML Toplevel.end_proof}~@{text "tr"} adjoins a concluding
    3.73 +  \<^descr> @{ML Toplevel.end_proof}~\<open>tr\<close> adjoins a concluding
    3.74    proof command, that returns the resulting theory, after applying the
    3.75    resulting facts to the target context.
    3.76  \<close>
    3.77 @@ -163,7 +162,7 @@
    3.78    @{index_ML Thy_Info.register_thy: "theory -> unit"} \\
    3.79    \end{mldecls}
    3.80  
    3.81 -  \<^descr> @{ML use_thy}~@{text A} ensures that theory @{text A} is fully
    3.82 +  \<^descr> @{ML use_thy}~\<open>A\<close> ensures that theory \<open>A\<close> is fully
    3.83    up-to-date wrt.\ the external file store; outdated ancestors are reloaded on
    3.84    demand.
    3.85  
    3.86 @@ -175,14 +174,14 @@
    3.87  
    3.88    This variant is used by default in @{tool build} @{cite "isabelle-system"}.
    3.89  
    3.90 -  \<^descr> @{ML Thy_Info.get_theory}~@{text A} retrieves the theory value
    3.91 -  presently associated with name @{text A}. Note that the result might be
    3.92 +  \<^descr> @{ML Thy_Info.get_theory}~\<open>A\<close> retrieves the theory value
    3.93 +  presently associated with name \<open>A\<close>. Note that the result might be
    3.94    outdated wrt.\ the file-system content.
    3.95  
    3.96 -  \<^descr> @{ML Thy_Info.remove_thy}~@{text A} deletes theory @{text A} and all
    3.97 +  \<^descr> @{ML Thy_Info.remove_thy}~\<open>A\<close> deletes theory \<open>A\<close> and all
    3.98    descendants from the theory database.
    3.99  
   3.100 -  \<^descr> @{ML Thy_Info.register_thy}~@{text "text thy"} registers an existing
   3.101 +  \<^descr> @{ML Thy_Info.register_thy}~\<open>text thy\<close> registers an existing
   3.102    theory value with the theory loader database and updates source version
   3.103    information according to the file store.
   3.104  \<close>
     4.1 --- a/src/Doc/Implementation/Isar.thy	Tue Oct 20 23:03:46 2015 +0200
     4.2 +++ b/src/Doc/Implementation/Isar.thy	Tue Oct 20 23:53:40 2015 +0200
     4.3 @@ -78,7 +78,7 @@
     4.4    \<^descr> Type @{ML_type Proof.state} represents Isar proof states.
     4.5    This is a block-structured configuration with proof context,
     4.6    linguistic mode, and optional goal.  The latter consists of goal
     4.7 -  context, goal facts (``@{text "using"}''), and tactical goal state
     4.8 +  context, goal facts (``\<open>using\<close>''), and tactical goal state
     4.9    (see \secref{sec:tactical-goals}).
    4.10  
    4.11    The general idea is that the facts shall contribute to the
    4.12 @@ -87,39 +87,37 @@
    4.13  
    4.14    \<^descr> @{ML Proof.assert_forward}, @{ML Proof.assert_chain}, @{ML
    4.15    Proof.assert_backward} are partial identity functions that fail
    4.16 -  unless a certain linguistic mode is active, namely ``@{text
    4.17 -  "proof(state)"}'', ``@{text "proof(chain)"}'', ``@{text
    4.18 -  "proof(prove)"}'', respectively (using the terminology of
    4.19 +  unless a certain linguistic mode is active, namely ``\<open>proof(state)\<close>'', ``\<open>proof(chain)\<close>'', ``\<open>proof(prove)\<close>'', respectively (using the terminology of
    4.20    @{cite "isabelle-isar-ref"}).
    4.21  
    4.22    It is advisable study the implementations of existing proof commands
    4.23    for suitable modes to be asserted.
    4.24  
    4.25 -  \<^descr> @{ML Proof.simple_goal}~@{text "state"} returns the structured
    4.26 +  \<^descr> @{ML Proof.simple_goal}~\<open>state\<close> returns the structured
    4.27    Isar goal (if available) in the form seen by ``simple'' methods
    4.28    (like @{method simp} or @{method blast}).  The Isar goal facts are
    4.29    already inserted as premises into the subgoals, which are presented
    4.30    individually as in @{ML Proof.goal}.
    4.31  
    4.32 -  \<^descr> @{ML Proof.goal}~@{text "state"} returns the structured Isar
    4.33 +  \<^descr> @{ML Proof.goal}~\<open>state\<close> returns the structured Isar
    4.34    goal (if available) in the form seen by regular methods (like
    4.35    @{method rule}).  The auxiliary internal encoding of Pure
    4.36    conjunctions is split into individual subgoals as usual.
    4.37  
    4.38 -  \<^descr> @{ML Proof.raw_goal}~@{text "state"} returns the structured
    4.39 +  \<^descr> @{ML Proof.raw_goal}~\<open>state\<close> returns the structured
    4.40    Isar goal (if available) in the raw internal form seen by ``raw''
    4.41    methods (like @{method induct}).  This form is rarely appropriate
    4.42    for diagnostic tools; @{ML Proof.simple_goal} or @{ML Proof.goal}
    4.43    should be used in most situations.
    4.44  
    4.45 -  \<^descr> @{ML Proof.theorem}~@{text "before_qed after_qed statement ctxt"}
    4.46 +  \<^descr> @{ML Proof.theorem}~\<open>before_qed after_qed statement ctxt\<close>
    4.47    initializes a toplevel Isar proof state within a given context.
    4.48  
    4.49 -  The optional @{text "before_qed"} method is applied at the end of
    4.50 +  The optional \<open>before_qed\<close> method is applied at the end of
    4.51    the proof, just before extracting the result (this feature is rarely
    4.52    used).
    4.53  
    4.54 -  The @{text "after_qed"} continuation receives the extracted result
    4.55 +  The \<open>after_qed\<close> continuation receives the extracted result
    4.56    in order to apply it to the final context in a suitable way (e.g.\
    4.57    storing named facts).  Note that at this generic level the target
    4.58    context is specified as @{ML_type Proof.context}, but the usual
    4.59 @@ -127,20 +125,20 @@
    4.60    @{ML_type local_theory} here (\chref{ch:local-theory}).  This
    4.61    affects the way how results are stored.
    4.62  
    4.63 -  The @{text "statement"} is given as a nested list of terms, each
    4.64 +  The \<open>statement\<close> is given as a nested list of terms, each
    4.65    associated with optional @{keyword "is"} patterns as usual in the
    4.66    Isar source language.  The original nested list structure over terms
    4.67 -  is turned into one over theorems when @{text "after_qed"} is
    4.68 +  is turned into one over theorems when \<open>after_qed\<close> is
    4.69    invoked.
    4.70  \<close>
    4.71  
    4.72  
    4.73  text %mlantiq \<open>
    4.74    \begin{matharray}{rcl}
    4.75 -  @{ML_antiquotation_def "Isar.goal"} & : & @{text ML_antiquotation} \\
    4.76 +  @{ML_antiquotation_def "Isar.goal"} & : & \<open>ML_antiquotation\<close> \\
    4.77    \end{matharray}
    4.78  
    4.79 -  \<^descr> @{text "@{Isar.goal}"} refers to the regular goal state (if
    4.80 +  \<^descr> \<open>@{Isar.goal}\<close> refers to the regular goal state (if
    4.81    available) of the current proof state managed by the Isar toplevel
    4.82    --- as abstract value.
    4.83  
    4.84 @@ -165,8 +163,8 @@
    4.85  
    4.86  section \<open>Proof methods\<close>
    4.87  
    4.88 -text \<open>A @{text "method"} is a function @{text "context \<rightarrow> thm\<^sup>* \<rightarrow> goal
    4.89 -  \<rightarrow> (cases \<times> goal)\<^sup>*\<^sup>*"} that operates on the full Isar goal
    4.90 +text \<open>A \<open>method\<close> is a function \<open>context \<rightarrow> thm\<^sup>* \<rightarrow> goal
    4.91 +  \<rightarrow> (cases \<times> goal)\<^sup>*\<^sup>*\<close> that operates on the full Isar goal
    4.92    configuration with context, goal facts, and tactical goal state and
    4.93    enumerates possible follow-up goal states, with the potential
    4.94    addition of named extensions of the proof context (\<^emph>\<open>cases\<close>).
    4.95 @@ -186,9 +184,9 @@
    4.96  
    4.97    \<^item> A non-trivial method always needs to make progress: an
    4.98    identical follow-up goal state has to be avoided.\footnote{This
    4.99 -  enables the user to write method expressions like @{text "meth\<^sup>+"}
   4.100 +  enables the user to write method expressions like \<open>meth\<^sup>+\<close>
   4.101    without looping, while the trivial do-nothing case can be recovered
   4.102 -  via @{text "meth\<^sup>?"}.}
   4.103 +  via \<open>meth\<^sup>?\<close>.}
   4.104  
   4.105    Exception: trivial stuttering steps, such as ``@{method -}'' or
   4.106    @{method succeed}.
   4.107 @@ -211,19 +209,17 @@
   4.108  
   4.109    \<^medskip>
   4.110    \begin{tabular}{l}
   4.111 -  @{command from}~@{text "facts\<^sub>1"}~@{command have}~@{text "props"}~@{command using}~@{text "facts\<^sub>2"} \\
   4.112 -  @{command proof}~@{text "(initial_method)"} \\
   4.113 -  \quad@{text "body"} \\
   4.114 -  @{command qed}~@{text "(terminal_method)"} \\
   4.115 +  @{command from}~\<open>facts\<^sub>1\<close>~@{command have}~\<open>props\<close>~@{command using}~\<open>facts\<^sub>2\<close> \\
   4.116 +  @{command proof}~\<open>(initial_method)\<close> \\
   4.117 +  \quad\<open>body\<close> \\
   4.118 +  @{command qed}~\<open>(terminal_method)\<close> \\
   4.119    \end{tabular}
   4.120    \<^medskip>
   4.121  
   4.122 -  The goal configuration consists of @{text "facts\<^sub>1"} and
   4.123 -  @{text "facts\<^sub>2"} appended in that order, and various @{text
   4.124 -  "props"} being claimed.  The @{text "initial_method"} is invoked
   4.125 +  The goal configuration consists of \<open>facts\<^sub>1\<close> and
   4.126 +  \<open>facts\<^sub>2\<close> appended in that order, and various \<open>props\<close> being claimed.  The \<open>initial_method\<close> is invoked
   4.127    with facts and goals together and refines the problem to something
   4.128 -  that is handled recursively in the proof @{text "body"}.  The @{text
   4.129 -  "terminal_method"} has another chance to finish any remaining
   4.130 +  that is handled recursively in the proof \<open>body\<close>.  The \<open>terminal_method\<close> has another chance to finish any remaining
   4.131    subgoals, but it does not see the facts of the initial step.
   4.132  
   4.133    \<^medskip>
   4.134 @@ -231,20 +227,18 @@
   4.135  
   4.136    \<^medskip>
   4.137    \begin{tabular}{l}
   4.138 -  @{command have}~@{text "props"} \\
   4.139 -  \quad@{command using}~@{text "facts\<^sub>1"}~@{command apply}~@{text "method\<^sub>1"} \\
   4.140 -  \quad@{command apply}~@{text "method\<^sub>2"} \\
   4.141 -  \quad@{command using}~@{text "facts\<^sub>3"}~@{command apply}~@{text "method\<^sub>3"} \\
   4.142 +  @{command have}~\<open>props\<close> \\
   4.143 +  \quad@{command using}~\<open>facts\<^sub>1\<close>~@{command apply}~\<open>method\<^sub>1\<close> \\
   4.144 +  \quad@{command apply}~\<open>method\<^sub>2\<close> \\
   4.145 +  \quad@{command using}~\<open>facts\<^sub>3\<close>~@{command apply}~\<open>method\<^sub>3\<close> \\
   4.146    \quad@{command done} \\
   4.147    \end{tabular}
   4.148    \<^medskip>
   4.149  
   4.150 -  The @{text "method\<^sub>1"} operates on the original claim while
   4.151 -  using @{text "facts\<^sub>1"}.  Since the @{command apply} command
   4.152 -  structurally resets the facts, the @{text "method\<^sub>2"} will
   4.153 -  operate on the remaining goal state without facts.  The @{text
   4.154 -  "method\<^sub>3"} will see again a collection of @{text
   4.155 -  "facts\<^sub>3"} that has been inserted into the script explicitly.
   4.156 +  The \<open>method\<^sub>1\<close> operates on the original claim while
   4.157 +  using \<open>facts\<^sub>1\<close>.  Since the @{command apply} command
   4.158 +  structurally resets the facts, the \<open>method\<^sub>2\<close> will
   4.159 +  operate on the remaining goal state without facts.  The \<open>method\<^sub>3\<close> will see again a collection of \<open>facts\<^sub>3\<close> that has been inserted into the script explicitly.
   4.160  
   4.161    \<^medskip>
   4.162    Empirically, any Isar proof method can be categorized as
   4.163 @@ -272,7 +266,7 @@
   4.164    \<^enum> \<^emph>\<open>Old-style tactic emulation\<close> with detailed numeric goal
   4.165    addressing and explicit references to entities of the internal goal
   4.166    state (which are otherwise invisible from proper Isar proof text).
   4.167 -  The naming convention @{text "foo_tac"} makes this special
   4.168 +  The naming convention \<open>foo_tac\<close> makes this special
   4.169    non-standard status clear.
   4.170  
   4.171    Example: @{method "rule_tac"}.
   4.172 @@ -303,30 +297,27 @@
   4.173    \<^descr> Type @{ML_type Proof.method} represents proof methods as
   4.174    abstract type.
   4.175  
   4.176 -  \<^descr> @{ML METHOD_CASES}~@{text "(fn facts => cases_tactic)"} wraps
   4.177 -  @{text cases_tactic} depending on goal facts as proof method with
   4.178 +  \<^descr> @{ML METHOD_CASES}~\<open>(fn facts => cases_tactic)\<close> wraps
   4.179 +  \<open>cases_tactic\<close> depending on goal facts as proof method with
   4.180    cases; the goal context is passed via method syntax.
   4.181  
   4.182 -  \<^descr> @{ML METHOD}~@{text "(fn facts => tactic)"} wraps @{text
   4.183 -  tactic} depending on goal facts as regular proof method; the goal
   4.184 +  \<^descr> @{ML METHOD}~\<open>(fn facts => tactic)\<close> wraps \<open>tactic\<close> depending on goal facts as regular proof method; the goal
   4.185    context is passed via method syntax.
   4.186  
   4.187 -  \<^descr> @{ML SIMPLE_METHOD}~@{text "tactic"} wraps a tactic that
   4.188 +  \<^descr> @{ML SIMPLE_METHOD}~\<open>tactic\<close> wraps a tactic that
   4.189    addresses all subgoals uniformly as simple proof method.  Goal facts
   4.190 -  are already inserted into all subgoals before @{text "tactic"} is
   4.191 +  are already inserted into all subgoals before \<open>tactic\<close> is
   4.192    applied.
   4.193  
   4.194 -  \<^descr> @{ML SIMPLE_METHOD'}~@{text "tactic"} wraps a tactic that
   4.195 +  \<^descr> @{ML SIMPLE_METHOD'}~\<open>tactic\<close> wraps a tactic that
   4.196    addresses a specific subgoal as simple proof method that operates on
   4.197 -  subgoal 1.  Goal facts are inserted into the subgoal then the @{text
   4.198 -  "tactic"} is applied.
   4.199 +  subgoal 1.  Goal facts are inserted into the subgoal then the \<open>tactic\<close> is applied.
   4.200  
   4.201 -  \<^descr> @{ML Method.insert_tac}~@{text "facts i"} inserts @{text
   4.202 -  "facts"} into subgoal @{text "i"}.  This is convenient to reproduce
   4.203 +  \<^descr> @{ML Method.insert_tac}~\<open>facts i\<close> inserts \<open>facts\<close> into subgoal \<open>i\<close>.  This is convenient to reproduce
   4.204    part of the @{ML SIMPLE_METHOD} or @{ML SIMPLE_METHOD'} wrapping
   4.205    within regular @{ML METHOD}, for example.
   4.206  
   4.207 -  \<^descr> @{ML Method.setup}~@{text "name parser description"} provides
   4.208 +  \<^descr> @{ML Method.setup}~\<open>name parser description\<close> provides
   4.209    the functionality of the Isar command @{command method_setup} as ML
   4.210    function.
   4.211  \<close>
   4.212 @@ -470,8 +461,8 @@
   4.213    method arguments obtained via concrete syntax or the context does
   4.214    not meet the requirement of ``strong emphasis on facts'' of regular
   4.215    proof methods, because rewrite rules as used above can be easily
   4.216 -  ignored.  A proof text ``@{command using}~@{text "foo"}~@{command
   4.217 -  "by"}~@{text "my_simp"}'' where @{text "foo"} is not used would
   4.218 +  ignored.  A proof text ``@{command using}~\<open>foo\<close>~@{command
   4.219 +  "by"}~\<open>my_simp\<close>'' where \<open>foo\<close> is not used would
   4.220    deceive the reader.
   4.221  
   4.222    \<^medskip>
   4.223 @@ -495,12 +486,12 @@
   4.224  
   4.225  section \<open>Attributes \label{sec:attributes}\<close>
   4.226  
   4.227 -text \<open>An \<^emph>\<open>attribute\<close> is a function @{text "context \<times> thm \<rightarrow>
   4.228 -  context \<times> thm"}, which means both a (generic) context and a theorem
   4.229 +text \<open>An \<^emph>\<open>attribute\<close> is a function \<open>context \<times> thm \<rightarrow>
   4.230 +  context \<times> thm\<close>, which means both a (generic) context and a theorem
   4.231    can be modified simultaneously.  In practice this mixed form is very
   4.232    rare, instead attributes are presented either as \<^emph>\<open>declaration
   4.233 -  attribute:\<close> @{text "thm \<rightarrow> context \<rightarrow> context"} or \<^emph>\<open>rule
   4.234 -  attribute:\<close> @{text "context \<rightarrow> thm \<rightarrow> thm"}.
   4.235 +  attribute:\<close> \<open>thm \<rightarrow> context \<rightarrow> context\<close> or \<^emph>\<open>rule
   4.236 +  attribute:\<close> \<open>context \<rightarrow> thm \<rightarrow> thm\<close>.
   4.237  
   4.238    Attributes can have additional arguments via concrete syntax.  There
   4.239    is a collection of context-sensitive parsers for various logical
   4.240 @@ -527,28 +518,28 @@
   4.241    \<^descr> Type @{ML_type attribute} represents attributes as concrete
   4.242    type alias.
   4.243  
   4.244 -  \<^descr> @{ML Thm.rule_attribute}~@{text "(fn context => rule)"} wraps
   4.245 +  \<^descr> @{ML Thm.rule_attribute}~\<open>(fn context => rule)\<close> wraps
   4.246    a context-dependent rule (mapping on @{ML_type thm}) as attribute.
   4.247  
   4.248 -  \<^descr> @{ML Thm.declaration_attribute}~@{text "(fn thm => decl)"}
   4.249 +  \<^descr> @{ML Thm.declaration_attribute}~\<open>(fn thm => decl)\<close>
   4.250    wraps a theorem-dependent declaration (mapping on @{ML_type
   4.251    Context.generic}) as attribute.
   4.252  
   4.253 -  \<^descr> @{ML Attrib.setup}~@{text "name parser description"} provides
   4.254 +  \<^descr> @{ML Attrib.setup}~\<open>name parser description\<close> provides
   4.255    the functionality of the Isar command @{command attribute_setup} as
   4.256    ML function.
   4.257  \<close>
   4.258  
   4.259  text %mlantiq \<open>
   4.260    \begin{matharray}{rcl}
   4.261 -  @{ML_antiquotation_def attributes} & : & @{text ML_antiquotation} \\
   4.262 +  @{ML_antiquotation_def attributes} & : & \<open>ML_antiquotation\<close> \\
   4.263    \end{matharray}
   4.264  
   4.265    @{rail \<open>
   4.266    @@{ML_antiquotation attributes} attributes
   4.267    \<close>}
   4.268  
   4.269 -  \<^descr> @{text "@{attributes [\<dots>]}"} embeds attribute source
   4.270 +  \<^descr> \<open>@{attributes [\<dots>]}\<close> embeds attribute source
   4.271    representation into the ML text, which is particularly useful with
   4.272    declarations like @{ML Local_Theory.note}.  Attribute names are
   4.273    internalized at compile time, but the source is unevaluated.  This
     5.1 --- a/src/Doc/Implementation/Local_Theory.thy	Tue Oct 20 23:03:46 2015 +0200
     5.2 +++ b/src/Doc/Implementation/Local_Theory.thy	Tue Oct 20 23:53:40 2015 +0200
     5.3 @@ -13,11 +13,11 @@
     5.4    context\<close>.
     5.5  
     5.6    The target is usually derived from the background theory by adding
     5.7 -  local @{text "\<FIX>"} and @{text "\<ASSUME>"} elements, plus
     5.8 +  local \<open>\<FIX>\<close> and \<open>\<ASSUME>\<close> elements, plus
     5.9    suitable modifications of non-logical context data (e.g.\ a special
    5.10    type-checking discipline).  Once initialized, the target is ready to
    5.11 -  absorb definitional primitives: @{text "\<DEFINE>"} for terms and
    5.12 -  @{text "\<NOTE>"} for theorems.  Such definitions may get
    5.13 +  absorb definitional primitives: \<open>\<DEFINE>\<close> for terms and
    5.14 +  \<open>\<NOTE>\<close> for theorems.  Such definitions may get
    5.15    transformed in a target-specific way, but the programming interface
    5.16    hides such details.
    5.17  
    5.18 @@ -39,13 +39,13 @@
    5.19  section \<open>Definitional elements\<close>
    5.20  
    5.21  text \<open>
    5.22 -  There are separate elements @{text "\<DEFINE> c \<equiv> t"} for terms, and
    5.23 -  @{text "\<NOTE> b = thm"} for theorems.  Types are treated
    5.24 +  There are separate elements \<open>\<DEFINE> c \<equiv> t\<close> for terms, and
    5.25 +  \<open>\<NOTE> b = thm\<close> for theorems.  Types are treated
    5.26    implicitly, according to Hindley-Milner discipline (cf.\
    5.27    \secref{sec:variables}).  These definitional primitives essentially
    5.28 -  act like @{text "let"}-bindings within a local context that may
    5.29 -  already contain earlier @{text "let"}-bindings and some initial
    5.30 -  @{text "\<lambda>"}-bindings.  Thus we gain \<^emph>\<open>dependent definitions\<close>
    5.31 +  act like \<open>let\<close>-bindings within a local context that may
    5.32 +  already contain earlier \<open>let\<close>-bindings and some initial
    5.33 +  \<open>\<lambda>\<close>-bindings.  Thus we gain \<^emph>\<open>dependent definitions\<close>
    5.34    that are relative to an initial axiomatic context.  The following
    5.35    diagram illustrates this idea of axiomatic elements versus
    5.36    definitional elements:
    5.37 @@ -53,30 +53,29 @@
    5.38    \begin{center}
    5.39    \begin{tabular}{|l|l|l|}
    5.40    \hline
    5.41 -  & @{text "\<lambda>"}-binding & @{text "let"}-binding \\
    5.42 +  & \<open>\<lambda>\<close>-binding & \<open>let\<close>-binding \\
    5.43    \hline
    5.44 -  types & fixed @{text "\<alpha>"} & arbitrary @{text "\<beta>"} \\
    5.45 -  terms & @{text "\<FIX> x :: \<tau>"} & @{text "\<DEFINE> c \<equiv> t"} \\
    5.46 -  theorems & @{text "\<ASSUME> a: A"} & @{text "\<NOTE> b = \<^BG>B\<^EN>"} \\
    5.47 +  types & fixed \<open>\<alpha>\<close> & arbitrary \<open>\<beta>\<close> \\
    5.48 +  terms & \<open>\<FIX> x :: \<tau>\<close> & \<open>\<DEFINE> c \<equiv> t\<close> \\
    5.49 +  theorems & \<open>\<ASSUME> a: A\<close> & \<open>\<NOTE> b = \<^BG>B\<^EN>\<close> \\
    5.50    \hline
    5.51    \end{tabular}
    5.52    \end{center}
    5.53  
    5.54 -  A user package merely needs to produce suitable @{text "\<DEFINE>"}
    5.55 -  and @{text "\<NOTE>"} elements according to the application.  For
    5.56 -  example, a package for inductive definitions might first @{text
    5.57 -  "\<DEFINE>"} a certain predicate as some fixed-point construction,
    5.58 -  then @{text "\<NOTE>"} a proven result about monotonicity of the
    5.59 +  A user package merely needs to produce suitable \<open>\<DEFINE>\<close>
    5.60 +  and \<open>\<NOTE>\<close> elements according to the application.  For
    5.61 +  example, a package for inductive definitions might first \<open>\<DEFINE>\<close> a certain predicate as some fixed-point construction,
    5.62 +  then \<open>\<NOTE>\<close> a proven result about monotonicity of the
    5.63    functor involved here, and then produce further derived concepts via
    5.64 -  additional @{text "\<DEFINE>"} and @{text "\<NOTE>"} elements.
    5.65 +  additional \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close> elements.
    5.66  
    5.67 -  The cumulative sequence of @{text "\<DEFINE>"} and @{text "\<NOTE>"}
    5.68 +  The cumulative sequence of \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close>
    5.69    produced at package runtime is managed by the local theory
    5.70    infrastructure by means of an \<^emph>\<open>auxiliary context\<close>.  Thus the
    5.71    system holds up the impression of working within a fully abstract
    5.72 -  situation with hypothetical entities: @{text "\<DEFINE> c \<equiv> t"}
    5.73 -  always results in a literal fact @{text "\<^BG>c \<equiv> t\<^EN>"}, where
    5.74 -  @{text "c"} is a fixed variable @{text "c"}.  The details about
    5.75 +  situation with hypothetical entities: \<open>\<DEFINE> c \<equiv> t\<close>
    5.76 +  always results in a literal fact \<open>\<^BG>c \<equiv> t\<^EN>\<close>, where
    5.77 +  \<open>c\<close> is a fixed variable \<open>c\<close>.  The details about
    5.78    global constants, name spaces etc. are handled internally.
    5.79  
    5.80    So the general structure of a local theory is a sandwich of three
    5.81 @@ -88,8 +87,7 @@
    5.82  
    5.83    When a definitional package is finished, the auxiliary context is
    5.84    reset to the target context.  The target now holds definitions for
    5.85 -  terms and theorems that stem from the hypothetical @{text
    5.86 -  "\<DEFINE>"} and @{text "\<NOTE>"} elements, transformed by the
    5.87 +  terms and theorems that stem from the hypothetical \<open>\<DEFINE>\<close> and \<open>\<NOTE>\<close> elements, transformed by the
    5.88    particular target policy (see @{cite \<open>\S4--5\<close> "Haftmann-Wenzel:2009"}
    5.89    for details).\<close>
    5.90  
    5.91 @@ -107,11 +105,11 @@
    5.92    Although this is merely an alias for @{ML_type Proof.context}, it is
    5.93    semantically a subtype of the same: a @{ML_type local_theory} holds
    5.94    target information as special context data.  Subtyping means that
    5.95 -  any value @{text "lthy:"}~@{ML_type local_theory} can be also used
    5.96 -  with operations on expecting a regular @{text "ctxt:"}~@{ML_type
    5.97 +  any value \<open>lthy:\<close>~@{ML_type local_theory} can be also used
    5.98 +  with operations on expecting a regular \<open>ctxt:\<close>~@{ML_type
    5.99    Proof.context}.
   5.100  
   5.101 -  \<^descr> @{ML Named_Target.init}~@{text "before_exit name thy"}
   5.102 +  \<^descr> @{ML Named_Target.init}~\<open>before_exit name thy\<close>
   5.103    initializes a local theory derived from the given background theory.
   5.104    An empty name refers to a \<^emph>\<open>global theory\<close> context, and a
   5.105    non-empty name refers to a @{command locale} or @{command class}
   5.106 @@ -119,9 +117,9 @@
   5.107    useful for experimentation --- normally the Isar toplevel already
   5.108    takes care to initialize the local theory context.
   5.109  
   5.110 -  \<^descr> @{ML Local_Theory.define}~@{text "((b, mx), (a, rhs))
   5.111 -  lthy"} defines a local entity according to the specification that is
   5.112 -  given relatively to the current @{text "lthy"} context.  In
   5.113 +  \<^descr> @{ML Local_Theory.define}~\<open>((b, mx), (a, rhs))
   5.114 +  lthy\<close> defines a local entity according to the specification that is
   5.115 +  given relatively to the current \<open>lthy\<close> context.  In
   5.116    particular the term of the RHS may refer to earlier local entities
   5.117    from the auxiliary context, or hypothetical parameters from the
   5.118    target context.  The result is the newly defined term (which is
   5.119 @@ -130,7 +128,7 @@
   5.120    definition as a hypothetical fact.
   5.121  
   5.122    Unless an explicit name binding is given for the RHS, the resulting
   5.123 -  fact will be called @{text "b_def"}.  Any given attributes are
   5.124 +  fact will be called \<open>b_def\<close>.  Any given attributes are
   5.125    applied to that same fact --- immediately in the auxiliary context
   5.126    \<^emph>\<open>and\<close> in any transformed versions stemming from target-specific
   5.127    policies or any later interpretations of results from the target
   5.128 @@ -139,7 +137,7 @@
   5.129    declarations such as @{attribute simp}, while non-trivial rules like
   5.130    @{attribute simplified} are better avoided.
   5.131  
   5.132 -  \<^descr> @{ML Local_Theory.note}~@{text "(a, ths) lthy"} is
   5.133 +  \<^descr> @{ML Local_Theory.note}~\<open>(a, ths) lthy\<close> is
   5.134    analogous to @{ML Local_Theory.define}, but defines facts instead of
   5.135    terms.  There is also a slightly more general variant @{ML
   5.136    Local_Theory.notes} that defines several facts (with attribute
     6.1 --- a/src/Doc/Implementation/Logic.thy	Tue Oct 20 23:03:46 2015 +0200
     6.2 +++ b/src/Doc/Implementation/Logic.thy	Tue Oct 20 23:53:40 2015 +0200
     6.3 @@ -7,23 +7,20 @@
     6.4  text \<open>
     6.5    The logical foundations of Isabelle/Isar are that of the Pure logic,
     6.6    which has been introduced as a Natural Deduction framework in
     6.7 -  @{cite paulson700}.  This is essentially the same logic as ``@{text
     6.8 -  "\<lambda>HOL"}'' in the more abstract setting of Pure Type Systems (PTS)
     6.9 +  @{cite paulson700}.  This is essentially the same logic as ``\<open>\<lambda>HOL\<close>'' in the more abstract setting of Pure Type Systems (PTS)
    6.10    @{cite "Barendregt-Geuvers:2001"}, although there are some key
    6.11    differences in the specific treatment of simple types in
    6.12    Isabelle/Pure.
    6.13  
    6.14    Following type-theoretic parlance, the Pure logic consists of three
    6.15 -  levels of @{text "\<lambda>"}-calculus with corresponding arrows, @{text
    6.16 -  "\<Rightarrow>"} for syntactic function space (terms depending on terms), @{text
    6.17 -  "\<And>"} for universal quantification (proofs depending on terms), and
    6.18 -  @{text "\<Longrightarrow>"} for implication (proofs depending on proofs).
    6.19 +  levels of \<open>\<lambda>\<close>-calculus with corresponding arrows, \<open>\<Rightarrow>\<close> for syntactic function space (terms depending on terms), \<open>\<And>\<close> for universal quantification (proofs depending on terms), and
    6.20 +  \<open>\<Longrightarrow>\<close> for implication (proofs depending on proofs).
    6.21  
    6.22    Derivations are relative to a logical theory, which declares type
    6.23    constructors, constants, and axioms.  Theory declarations support
    6.24    schematic polymorphism, which is strictly speaking outside the
    6.25    logic.\footnote{This is the deeper logical reason, why the theory
    6.26 -  context @{text "\<Theta>"} is separate from the proof context @{text "\<Gamma>"}
    6.27 +  context \<open>\<Theta>\<close> is separate from the proof context \<open>\<Gamma>\<close>
    6.28    of the core calculus: type constructors, term constants, and facts
    6.29    (proof constants) may involve arbitrary type schemes, but the type
    6.30    of a locally fixed term parameter is also fixed!}
    6.31 @@ -38,31 +35,29 @@
    6.32  
    6.33    \<^medskip>
    6.34    A \<^emph>\<open>type class\<close> is an abstract syntactic entity
    6.35 -  declared in the theory context.  The \<^emph>\<open>subclass relation\<close> @{text
    6.36 -  "c\<^sub>1 \<subseteq> c\<^sub>2"} is specified by stating an acyclic
    6.37 +  declared in the theory context.  The \<^emph>\<open>subclass relation\<close> \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close> is specified by stating an acyclic
    6.38    generating relation; the transitive closure is maintained
    6.39    internally.  The resulting relation is an ordering: reflexive,
    6.40    transitive, and antisymmetric.
    6.41  
    6.42 -  A \<^emph>\<open>sort\<close> is a list of type classes written as @{text "s = {c\<^sub>1,
    6.43 -  \<dots>, c\<^sub>m}"}, it represents symbolic intersection.  Notationally, the
    6.44 +  A \<^emph>\<open>sort\<close> is a list of type classes written as \<open>s = {c\<^sub>1,
    6.45 +  \<dots>, c\<^sub>m}\<close>, it represents symbolic intersection.  Notationally, the
    6.46    curly braces are omitted for singleton intersections, i.e.\ any
    6.47 -  class @{text "c"} may be read as a sort @{text "{c}"}.  The ordering
    6.48 +  class \<open>c\<close> may be read as a sort \<open>{c}\<close>.  The ordering
    6.49    on type classes is extended to sorts according to the meaning of
    6.50 -  intersections: @{text "{c\<^sub>1, \<dots> c\<^sub>m} \<subseteq> {d\<^sub>1, \<dots>, d\<^sub>n}"} iff @{text
    6.51 -  "\<forall>j. \<exists>i. c\<^sub>i \<subseteq> d\<^sub>j"}.  The empty intersection @{text "{}"} refers to
    6.52 +  intersections: \<open>{c\<^sub>1, \<dots> c\<^sub>m} \<subseteq> {d\<^sub>1, \<dots>, d\<^sub>n}\<close> iff \<open>\<forall>j. \<exists>i. c\<^sub>i \<subseteq> d\<^sub>j\<close>.  The empty intersection \<open>{}\<close> refers to
    6.53    the universal sort, which is the largest element wrt.\ the sort
    6.54 -  order.  Thus @{text "{}"} represents the ``full sort'', not the
    6.55 +  order.  Thus \<open>{}\<close> represents the ``full sort'', not the
    6.56    empty one!  The intersection of all (finitely many) classes declared
    6.57    in the current theory is the least element wrt.\ the sort ordering.
    6.58  
    6.59    \<^medskip>
    6.60    A \<^emph>\<open>fixed type variable\<close> is a pair of a basic name
    6.61 -  (starting with a @{text "'"} character) and a sort constraint, e.g.\
    6.62 -  @{text "('a, s)"} which is usually printed as @{text "\<alpha>\<^sub>s"}.
    6.63 +  (starting with a \<open>'\<close> character) and a sort constraint, e.g.\
    6.64 +  \<open>('a, s)\<close> which is usually printed as \<open>\<alpha>\<^sub>s\<close>.
    6.65    A \<^emph>\<open>schematic type variable\<close> is a pair of an indexname and a
    6.66 -  sort constraint, e.g.\ @{text "(('a, 0), s)"} which is usually
    6.67 -  printed as @{text "?\<alpha>\<^sub>s"}.
    6.68 +  sort constraint, e.g.\ \<open>(('a, 0), s)\<close> which is usually
    6.69 +  printed as \<open>?\<alpha>\<^sub>s\<close>.
    6.70  
    6.71    Note that \<^emph>\<open>all\<close> syntactic components contribute to the identity
    6.72    of type variables: basic name, index, and sort constraint.  The core
    6.73 @@ -70,49 +65,47 @@
    6.74    as different, although the type-inference layer (which is outside
    6.75    the core) rejects anything like that.
    6.76  
    6.77 -  A \<^emph>\<open>type constructor\<close> @{text "\<kappa>"} is a @{text "k"}-ary operator
    6.78 +  A \<^emph>\<open>type constructor\<close> \<open>\<kappa>\<close> is a \<open>k\<close>-ary operator
    6.79    on types declared in the theory.  Type constructor application is
    6.80 -  written postfix as @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>k)\<kappa>"}.  For
    6.81 -  @{text "k = 0"} the argument tuple is omitted, e.g.\ @{text "prop"}
    6.82 -  instead of @{text "()prop"}.  For @{text "k = 1"} the parentheses
    6.83 -  are omitted, e.g.\ @{text "\<alpha> list"} instead of @{text "(\<alpha>)list"}.
    6.84 +  written postfix as \<open>(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>k)\<kappa>\<close>.  For
    6.85 +  \<open>k = 0\<close> the argument tuple is omitted, e.g.\ \<open>prop\<close>
    6.86 +  instead of \<open>()prop\<close>.  For \<open>k = 1\<close> the parentheses
    6.87 +  are omitted, e.g.\ \<open>\<alpha> list\<close> instead of \<open>(\<alpha>)list\<close>.
    6.88    Further notation is provided for specific constructors, notably the
    6.89 -  right-associative infix @{text "\<alpha> \<Rightarrow> \<beta>"} instead of @{text "(\<alpha>,
    6.90 -  \<beta>)fun"}.
    6.91 +  right-associative infix \<open>\<alpha> \<Rightarrow> \<beta>\<close> instead of \<open>(\<alpha>,
    6.92 +  \<beta>)fun\<close>.
    6.93    
    6.94    The logical category \<^emph>\<open>type\<close> is defined inductively over type
    6.95 -  variables and type constructors as follows: @{text "\<tau> = \<alpha>\<^sub>s | ?\<alpha>\<^sub>s |
    6.96 -  (\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>"}.
    6.97 +  variables and type constructors as follows: \<open>\<tau> = \<alpha>\<^sub>s | ?\<alpha>\<^sub>s |
    6.98 +  (\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>\<close>.
    6.99  
   6.100 -  A \<^emph>\<open>type abbreviation\<close> is a syntactic definition @{text
   6.101 -  "(\<^vec>\<alpha>)\<kappa> = \<tau>"} of an arbitrary type expression @{text "\<tau>"} over
   6.102 -  variables @{text "\<^vec>\<alpha>"}.  Type abbreviations appear as type
   6.103 +  A \<^emph>\<open>type abbreviation\<close> is a syntactic definition \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close> of an arbitrary type expression \<open>\<tau>\<close> over
   6.104 +  variables \<open>\<^vec>\<alpha>\<close>.  Type abbreviations appear as type
   6.105    constructors in the syntax, but are expanded before entering the
   6.106    logical core.
   6.107  
   6.108    A \<^emph>\<open>type arity\<close> declares the image behavior of a type
   6.109 -  constructor wrt.\ the algebra of sorts: @{text "\<kappa> :: (s\<^sub>1, \<dots>,
   6.110 -  s\<^sub>k)s"} means that @{text "(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>"} is
   6.111 -  of sort @{text "s"} if every argument type @{text "\<tau>\<^sub>i"} is
   6.112 -  of sort @{text "s\<^sub>i"}.  Arity declarations are implicitly
   6.113 -  completed, i.e.\ @{text "\<kappa> :: (\<^vec>s)c"} entails @{text "\<kappa> ::
   6.114 -  (\<^vec>s)c'"} for any @{text "c' \<supseteq> c"}.
   6.115 +  constructor wrt.\ the algebra of sorts: \<open>\<kappa> :: (s\<^sub>1, \<dots>,
   6.116 +  s\<^sub>k)s\<close> means that \<open>(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>k)\<kappa>\<close> is
   6.117 +  of sort \<open>s\<close> if every argument type \<open>\<tau>\<^sub>i\<close> is
   6.118 +  of sort \<open>s\<^sub>i\<close>.  Arity declarations are implicitly
   6.119 +  completed, i.e.\ \<open>\<kappa> :: (\<^vec>s)c\<close> entails \<open>\<kappa> ::
   6.120 +  (\<^vec>s)c'\<close> for any \<open>c' \<supseteq> c\<close>.
   6.121  
   6.122    \<^medskip>
   6.123    The sort algebra is always maintained as \<^emph>\<open>coregular\<close>,
   6.124    which means that type arities are consistent with the subclass
   6.125 -  relation: for any type constructor @{text "\<kappa>"}, and classes @{text
   6.126 -  "c\<^sub>1 \<subseteq> c\<^sub>2"}, and arities @{text "\<kappa> ::
   6.127 -  (\<^vec>s\<^sub>1)c\<^sub>1"} and @{text "\<kappa> ::
   6.128 -  (\<^vec>s\<^sub>2)c\<^sub>2"} holds @{text "\<^vec>s\<^sub>1 \<subseteq>
   6.129 -  \<^vec>s\<^sub>2"} component-wise.
   6.130 +  relation: for any type constructor \<open>\<kappa>\<close>, and classes \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close>, and arities \<open>\<kappa> ::
   6.131 +  (\<^vec>s\<^sub>1)c\<^sub>1\<close> and \<open>\<kappa> ::
   6.132 +  (\<^vec>s\<^sub>2)c\<^sub>2\<close> holds \<open>\<^vec>s\<^sub>1 \<subseteq>
   6.133 +  \<^vec>s\<^sub>2\<close> component-wise.
   6.134  
   6.135    The key property of a coregular order-sorted algebra is that sort
   6.136    constraints can be solved in a most general fashion: for each type
   6.137 -  constructor @{text "\<kappa>"} and sort @{text "s"} there is a most general
   6.138 -  vector of argument sorts @{text "(s\<^sub>1, \<dots>, s\<^sub>k)"} such
   6.139 -  that a type scheme @{text "(\<alpha>\<^bsub>s\<^sub>1\<^esub>, \<dots>,
   6.140 -  \<alpha>\<^bsub>s\<^sub>k\<^esub>)\<kappa>"} is of sort @{text "s"}.
   6.141 +  constructor \<open>\<kappa>\<close> and sort \<open>s\<close> there is a most general
   6.142 +  vector of argument sorts \<open>(s\<^sub>1, \<dots>, s\<^sub>k)\<close> such
   6.143 +  that a type scheme \<open>(\<alpha>\<^bsub>s\<^sub>1\<^esub>, \<dots>,
   6.144 +  \<alpha>\<^bsub>s\<^sub>k\<^esub>)\<kappa>\<close> is of sort \<open>s\<close>.
   6.145    Consequently, type unification has most general solutions (modulo
   6.146    equivalence of sorts), so type-inference produces primary types as
   6.147    expected @{cite "nipkow-prehofer"}.
   6.148 @@ -145,54 +138,53 @@
   6.149    the empty class intersection, i.e.\ the ``full sort''.
   6.150  
   6.151    \<^descr> Type @{ML_type arity} represents type arities.  A triple
   6.152 -  @{text "(\<kappa>, \<^vec>s, s) : arity"} represents @{text "\<kappa> ::
   6.153 -  (\<^vec>s)s"} as described above.
   6.154 +  \<open>(\<kappa>, \<^vec>s, s) : arity\<close> represents \<open>\<kappa> ::
   6.155 +  (\<^vec>s)s\<close> as described above.
   6.156  
   6.157    \<^descr> Type @{ML_type typ} represents types; this is a datatype with
   6.158    constructors @{ML TFree}, @{ML TVar}, @{ML Type}.
   6.159  
   6.160 -  \<^descr> @{ML Term.map_atyps}~@{text "f \<tau>"} applies the mapping @{text
   6.161 -  "f"} to all atomic types (@{ML TFree}, @{ML TVar}) occurring in
   6.162 -  @{text "\<tau>"}.
   6.163 +  \<^descr> @{ML Term.map_atyps}~\<open>f \<tau>\<close> applies the mapping \<open>f\<close> to all atomic types (@{ML TFree}, @{ML TVar}) occurring in
   6.164 +  \<open>\<tau>\<close>.
   6.165  
   6.166 -  \<^descr> @{ML Term.fold_atyps}~@{text "f \<tau>"} iterates the operation
   6.167 -  @{text "f"} over all occurrences of atomic types (@{ML TFree}, @{ML
   6.168 -  TVar}) in @{text "\<tau>"}; the type structure is traversed from left to
   6.169 +  \<^descr> @{ML Term.fold_atyps}~\<open>f \<tau>\<close> iterates the operation
   6.170 +  \<open>f\<close> over all occurrences of atomic types (@{ML TFree}, @{ML
   6.171 +  TVar}) in \<open>\<tau>\<close>; the type structure is traversed from left to
   6.172    right.
   6.173  
   6.174 -  \<^descr> @{ML Sign.subsort}~@{text "thy (s\<^sub>1, s\<^sub>2)"}
   6.175 -  tests the subsort relation @{text "s\<^sub>1 \<subseteq> s\<^sub>2"}.
   6.176 +  \<^descr> @{ML Sign.subsort}~\<open>thy (s\<^sub>1, s\<^sub>2)\<close>
   6.177 +  tests the subsort relation \<open>s\<^sub>1 \<subseteq> s\<^sub>2\<close>.
   6.178  
   6.179 -  \<^descr> @{ML Sign.of_sort}~@{text "thy (\<tau>, s)"} tests whether type
   6.180 -  @{text "\<tau>"} is of sort @{text "s"}.
   6.181 +  \<^descr> @{ML Sign.of_sort}~\<open>thy (\<tau>, s)\<close> tests whether type
   6.182 +  \<open>\<tau>\<close> is of sort \<open>s\<close>.
   6.183  
   6.184 -  \<^descr> @{ML Sign.add_type}~@{text "ctxt (\<kappa>, k, mx)"} declares a
   6.185 -  new type constructors @{text "\<kappa>"} with @{text "k"} arguments and
   6.186 +  \<^descr> @{ML Sign.add_type}~\<open>ctxt (\<kappa>, k, mx)\<close> declares a
   6.187 +  new type constructors \<open>\<kappa>\<close> with \<open>k\<close> arguments and
   6.188    optional mixfix syntax.
   6.189  
   6.190 -  \<^descr> @{ML Sign.add_type_abbrev}~@{text "ctxt (\<kappa>, \<^vec>\<alpha>, \<tau>)"}
   6.191 -  defines a new type abbreviation @{text "(\<^vec>\<alpha>)\<kappa> = \<tau>"}.
   6.192 +  \<^descr> @{ML Sign.add_type_abbrev}~\<open>ctxt (\<kappa>, \<^vec>\<alpha>, \<tau>)\<close>
   6.193 +  defines a new type abbreviation \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close>.
   6.194  
   6.195 -  \<^descr> @{ML Sign.primitive_class}~@{text "(c, [c\<^sub>1, \<dots>,
   6.196 -  c\<^sub>n])"} declares a new class @{text "c"}, together with class
   6.197 -  relations @{text "c \<subseteq> c\<^sub>i"}, for @{text "i = 1, \<dots>, n"}.
   6.198 +  \<^descr> @{ML Sign.primitive_class}~\<open>(c, [c\<^sub>1, \<dots>,
   6.199 +  c\<^sub>n])\<close> declares a new class \<open>c\<close>, together with class
   6.200 +  relations \<open>c \<subseteq> c\<^sub>i\<close>, for \<open>i = 1, \<dots>, n\<close>.
   6.201  
   6.202 -  \<^descr> @{ML Sign.primitive_classrel}~@{text "(c\<^sub>1,
   6.203 -  c\<^sub>2)"} declares the class relation @{text "c\<^sub>1 \<subseteq>
   6.204 -  c\<^sub>2"}.
   6.205 +  \<^descr> @{ML Sign.primitive_classrel}~\<open>(c\<^sub>1,
   6.206 +  c\<^sub>2)\<close> declares the class relation \<open>c\<^sub>1 \<subseteq>
   6.207 +  c\<^sub>2\<close>.
   6.208  
   6.209 -  \<^descr> @{ML Sign.primitive_arity}~@{text "(\<kappa>, \<^vec>s, s)"} declares
   6.210 -  the arity @{text "\<kappa> :: (\<^vec>s)s"}.
   6.211 +  \<^descr> @{ML Sign.primitive_arity}~\<open>(\<kappa>, \<^vec>s, s)\<close> declares
   6.212 +  the arity \<open>\<kappa> :: (\<^vec>s)s\<close>.
   6.213  \<close>
   6.214  
   6.215  text %mlantiq \<open>
   6.216    \begin{matharray}{rcl}
   6.217 -  @{ML_antiquotation_def "class"} & : & @{text ML_antiquotation} \\
   6.218 -  @{ML_antiquotation_def "sort"} & : & @{text ML_antiquotation} \\
   6.219 -  @{ML_antiquotation_def "type_name"} & : & @{text ML_antiquotation} \\
   6.220 -  @{ML_antiquotation_def "type_abbrev"} & : & @{text ML_antiquotation} \\
   6.221 -  @{ML_antiquotation_def "nonterminal"} & : & @{text ML_antiquotation} \\
   6.222 -  @{ML_antiquotation_def "typ"} & : & @{text ML_antiquotation} \\
   6.223 +  @{ML_antiquotation_def "class"} & : & \<open>ML_antiquotation\<close> \\
   6.224 +  @{ML_antiquotation_def "sort"} & : & \<open>ML_antiquotation\<close> \\
   6.225 +  @{ML_antiquotation_def "type_name"} & : & \<open>ML_antiquotation\<close> \\
   6.226 +  @{ML_antiquotation_def "type_abbrev"} & : & \<open>ML_antiquotation\<close> \\
   6.227 +  @{ML_antiquotation_def "nonterminal"} & : & \<open>ML_antiquotation\<close> \\
   6.228 +  @{ML_antiquotation_def "typ"} & : & \<open>ML_antiquotation\<close> \\
   6.229    \end{matharray}
   6.230  
   6.231    @{rail \<open>
   6.232 @@ -207,23 +199,22 @@
   6.233    @@{ML_antiquotation typ} type
   6.234    \<close>}
   6.235  
   6.236 -  \<^descr> @{text "@{class c}"} inlines the internalized class @{text
   6.237 -  "c"} --- as @{ML_type string} literal.
   6.238 +  \<^descr> \<open>@{class c}\<close> inlines the internalized class \<open>c\<close> --- as @{ML_type string} literal.
   6.239  
   6.240 -  \<^descr> @{text "@{sort s}"} inlines the internalized sort @{text "s"}
   6.241 +  \<^descr> \<open>@{sort s}\<close> inlines the internalized sort \<open>s\<close>
   6.242    --- as @{ML_type "string list"} literal.
   6.243  
   6.244 -  \<^descr> @{text "@{type_name c}"} inlines the internalized type
   6.245 -  constructor @{text "c"} --- as @{ML_type string} literal.
   6.246 +  \<^descr> \<open>@{type_name c}\<close> inlines the internalized type
   6.247 +  constructor \<open>c\<close> --- as @{ML_type string} literal.
   6.248  
   6.249 -  \<^descr> @{text "@{type_abbrev c}"} inlines the internalized type
   6.250 -  abbreviation @{text "c"} --- as @{ML_type string} literal.
   6.251 +  \<^descr> \<open>@{type_abbrev c}\<close> inlines the internalized type
   6.252 +  abbreviation \<open>c\<close> --- as @{ML_type string} literal.
   6.253  
   6.254 -  \<^descr> @{text "@{nonterminal c}"} inlines the internalized syntactic
   6.255 -  type~/ grammar nonterminal @{text "c"} --- as @{ML_type string}
   6.256 +  \<^descr> \<open>@{nonterminal c}\<close> inlines the internalized syntactic
   6.257 +  type~/ grammar nonterminal \<open>c\<close> --- as @{ML_type string}
   6.258    literal.
   6.259  
   6.260 -  \<^descr> @{text "@{typ \<tau>}"} inlines the internalized type @{text "\<tau>"}
   6.261 +  \<^descr> \<open>@{typ \<tau>}\<close> inlines the internalized type \<open>\<tau>\<close>
   6.262    --- as constructor term for datatype @{ML_type typ}.
   6.263  \<close>
   6.264  
   6.265 @@ -231,18 +222,18 @@
   6.266  section \<open>Terms \label{sec:terms}\<close>
   6.267  
   6.268  text \<open>
   6.269 -  The language of terms is that of simply-typed @{text "\<lambda>"}-calculus
   6.270 +  The language of terms is that of simply-typed \<open>\<lambda>\<close>-calculus
   6.271    with de-Bruijn indices for bound variables (cf.\ @{cite debruijn72}
   6.272    or @{cite "paulson-ml2"}), with the types being determined by the
   6.273    corresponding binders.  In contrast, free variables and constants
   6.274    have an explicit name and type in each occurrence.
   6.275  
   6.276    \<^medskip>
   6.277 -  A \<^emph>\<open>bound variable\<close> is a natural number @{text "b"},
   6.278 +  A \<^emph>\<open>bound variable\<close> is a natural number \<open>b\<close>,
   6.279    which accounts for the number of intermediate binders between the
   6.280    variable occurrence in the body and its binding position.  For
   6.281 -  example, the de-Bruijn term @{text "\<lambda>\<^bsub>bool\<^esub>. \<lambda>\<^bsub>bool\<^esub>. 1 \<and> 0"} would
   6.282 -  correspond to @{text "\<lambda>x\<^bsub>bool\<^esub>. \<lambda>y\<^bsub>bool\<^esub>. x \<and> y"} in a named
   6.283 +  example, the de-Bruijn term \<open>\<lambda>\<^bsub>bool\<^esub>. \<lambda>\<^bsub>bool\<^esub>. 1 \<and> 0\<close> would
   6.284 +  correspond to \<open>\<lambda>x\<^bsub>bool\<^esub>. \<lambda>y\<^bsub>bool\<^esub>. x \<and> y\<close> in a named
   6.285    representation.  Note that a bound variable may be represented by
   6.286    different de-Bruijn indices at different occurrences, depending on
   6.287    the nesting of abstractions.
   6.288 @@ -254,31 +245,29 @@
   6.289    without any loose variables.
   6.290  
   6.291    A \<^emph>\<open>fixed variable\<close> is a pair of a basic name and a type, e.g.\
   6.292 -  @{text "(x, \<tau>)"} which is usually printed @{text "x\<^sub>\<tau>"} here.  A
   6.293 +  \<open>(x, \<tau>)\<close> which is usually printed \<open>x\<^sub>\<tau>\<close> here.  A
   6.294    \<^emph>\<open>schematic variable\<close> is a pair of an indexname and a type,
   6.295 -  e.g.\ @{text "((x, 0), \<tau>)"} which is likewise printed as @{text
   6.296 -  "?x\<^sub>\<tau>"}.
   6.297 +  e.g.\ \<open>((x, 0), \<tau>)\<close> which is likewise printed as \<open>?x\<^sub>\<tau>\<close>.
   6.298  
   6.299    \<^medskip>
   6.300    A \<^emph>\<open>constant\<close> is a pair of a basic name and a type,
   6.301 -  e.g.\ @{text "(c, \<tau>)"} which is usually printed as @{text "c\<^sub>\<tau>"}
   6.302 +  e.g.\ \<open>(c, \<tau>)\<close> which is usually printed as \<open>c\<^sub>\<tau>\<close>
   6.303    here.  Constants are declared in the context as polymorphic families
   6.304 -  @{text "c :: \<sigma>"}, meaning that all substitution instances @{text
   6.305 -  "c\<^sub>\<tau>"} for @{text "\<tau> = \<sigma>\<vartheta>"} are valid.
   6.306 +  \<open>c :: \<sigma>\<close>, meaning that all substitution instances \<open>c\<^sub>\<tau>\<close> for \<open>\<tau> = \<sigma>\<vartheta>\<close> are valid.
   6.307  
   6.308 -  The vector of \<^emph>\<open>type arguments\<close> of constant @{text "c\<^sub>\<tau>"} wrt.\
   6.309 -  the declaration @{text "c :: \<sigma>"} is defined as the codomain of the
   6.310 -  matcher @{text "\<vartheta> = {?\<alpha>\<^sub>1 \<mapsto> \<tau>\<^sub>1, \<dots>, ?\<alpha>\<^sub>n \<mapsto> \<tau>\<^sub>n}"} presented in
   6.311 -  canonical order @{text "(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n)"}, corresponding to the
   6.312 -  left-to-right occurrences of the @{text "\<alpha>\<^sub>i"} in @{text "\<sigma>"}.
   6.313 +  The vector of \<^emph>\<open>type arguments\<close> of constant \<open>c\<^sub>\<tau>\<close> wrt.\
   6.314 +  the declaration \<open>c :: \<sigma>\<close> is defined as the codomain of the
   6.315 +  matcher \<open>\<vartheta> = {?\<alpha>\<^sub>1 \<mapsto> \<tau>\<^sub>1, \<dots>, ?\<alpha>\<^sub>n \<mapsto> \<tau>\<^sub>n}\<close> presented in
   6.316 +  canonical order \<open>(\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n)\<close>, corresponding to the
   6.317 +  left-to-right occurrences of the \<open>\<alpha>\<^sub>i\<close> in \<open>\<sigma>\<close>.
   6.318    Within a given theory context, there is a one-to-one correspondence
   6.319 -  between any constant @{text "c\<^sub>\<tau>"} and the application @{text "c(\<tau>\<^sub>1,
   6.320 -  \<dots>, \<tau>\<^sub>n)"} of its type arguments.  For example, with @{text "plus :: \<alpha>
   6.321 -  \<Rightarrow> \<alpha> \<Rightarrow> \<alpha>"}, the instance @{text "plus\<^bsub>nat \<Rightarrow> nat \<Rightarrow> nat\<^esub>"} corresponds to
   6.322 -  @{text "plus(nat)"}.
   6.323 +  between any constant \<open>c\<^sub>\<tau>\<close> and the application \<open>c(\<tau>\<^sub>1,
   6.324 +  \<dots>, \<tau>\<^sub>n)\<close> of its type arguments.  For example, with \<open>plus :: \<alpha>
   6.325 +  \<Rightarrow> \<alpha> \<Rightarrow> \<alpha>\<close>, the instance \<open>plus\<^bsub>nat \<Rightarrow> nat \<Rightarrow> nat\<^esub>\<close> corresponds to
   6.326 +  \<open>plus(nat)\<close>.
   6.327  
   6.328 -  Constant declarations @{text "c :: \<sigma>"} may contain sort constraints
   6.329 -  for type variables in @{text "\<sigma>"}.  These are observed by
   6.330 +  Constant declarations \<open>c :: \<sigma>\<close> may contain sort constraints
   6.331 +  for type variables in \<open>\<sigma>\<close>.  These are observed by
   6.332    type-inference as expected, but \<^emph>\<open>ignored\<close> by the core logic.
   6.333    This means the primitive logic is able to reason with instances of
   6.334    polymorphic constants that the user-level type-checker would reject
   6.335 @@ -287,21 +276,21 @@
   6.336    \<^medskip>
   6.337    An \<^emph>\<open>atomic term\<close> is either a variable or constant.
   6.338    The logical category \<^emph>\<open>term\<close> is defined inductively over atomic
   6.339 -  terms, with abstraction and application as follows: @{text "t = b |
   6.340 -  x\<^sub>\<tau> | ?x\<^sub>\<tau> | c\<^sub>\<tau> | \<lambda>\<^sub>\<tau>. t | t\<^sub>1 t\<^sub>2"}.  Parsing and printing takes care of
   6.341 +  terms, with abstraction and application as follows: \<open>t = b |
   6.342 +  x\<^sub>\<tau> | ?x\<^sub>\<tau> | c\<^sub>\<tau> | \<lambda>\<^sub>\<tau>. t | t\<^sub>1 t\<^sub>2\<close>.  Parsing and printing takes care of
   6.343    converting between an external representation with named bound
   6.344    variables.  Subsequently, we shall use the latter notation instead
   6.345    of internal de-Bruijn representation.
   6.346  
   6.347 -  The inductive relation @{text "t :: \<tau>"} assigns a (unique) type to a
   6.348 +  The inductive relation \<open>t :: \<tau>\<close> assigns a (unique) type to a
   6.349    term according to the structure of atomic terms, abstractions, and
   6.350    applications:
   6.351    \[
   6.352 -  \infer{@{text "a\<^sub>\<tau> :: \<tau>"}}{}
   6.353 +  \infer{\<open>a\<^sub>\<tau> :: \<tau>\<close>}{}
   6.354    \qquad
   6.355 -  \infer{@{text "(\<lambda>x\<^sub>\<tau>. t) :: \<tau> \<Rightarrow> \<sigma>"}}{@{text "t :: \<sigma>"}}
   6.356 +  \infer{\<open>(\<lambda>x\<^sub>\<tau>. t) :: \<tau> \<Rightarrow> \<sigma>\<close>}{\<open>t :: \<sigma>\<close>}
   6.357    \qquad
   6.358 -  \infer{@{text "t u :: \<sigma>"}}{@{text "t :: \<tau> \<Rightarrow> \<sigma>"} & @{text "u :: \<tau>"}}
   6.359 +  \infer{\<open>t u :: \<sigma>\<close>}{\<open>t :: \<tau> \<Rightarrow> \<sigma>\<close> & \<open>u :: \<tau>\<close>}
   6.360    \]
   6.361    A \<^emph>\<open>well-typed term\<close> is a term that can be typed according to these rules.
   6.362  
   6.363 @@ -312,43 +301,38 @@
   6.364    variables, and declarations for polymorphic constants.
   6.365  
   6.366    The identity of atomic terms consists both of the name and the type
   6.367 -  component.  This means that different variables @{text
   6.368 -  "x\<^bsub>\<tau>\<^sub>1\<^esub>"} and @{text "x\<^bsub>\<tau>\<^sub>2\<^esub>"} may become the same after
   6.369 +  component.  This means that different variables \<open>x\<^bsub>\<tau>\<^sub>1\<^esub>\<close> and \<open>x\<^bsub>\<tau>\<^sub>2\<^esub>\<close> may become the same after
   6.370    type instantiation.  Type-inference rejects variables of the same
   6.371    name, but different types.  In contrast, mixed instances of
   6.372    polymorphic constants occur routinely.
   6.373  
   6.374    \<^medskip>
   6.375 -  The \<^emph>\<open>hidden polymorphism\<close> of a term @{text "t :: \<sigma>"}
   6.376 -  is the set of type variables occurring in @{text "t"}, but not in
   6.377 -  its type @{text "\<sigma>"}.  This means that the term implicitly depends
   6.378 +  The \<^emph>\<open>hidden polymorphism\<close> of a term \<open>t :: \<sigma>\<close>
   6.379 +  is the set of type variables occurring in \<open>t\<close>, but not in
   6.380 +  its type \<open>\<sigma>\<close>.  This means that the term implicitly depends
   6.381    on type arguments that are not accounted in the result type, i.e.\
   6.382 -  there are different type instances @{text "t\<vartheta> :: \<sigma>"} and
   6.383 -  @{text "t\<vartheta>' :: \<sigma>"} with the same type.  This slightly
   6.384 +  there are different type instances \<open>t\<vartheta> :: \<sigma>\<close> and
   6.385 +  \<open>t\<vartheta>' :: \<sigma>\<close> with the same type.  This slightly
   6.386    pathological situation notoriously demands additional care.
   6.387  
   6.388    \<^medskip>
   6.389 -  A \<^emph>\<open>term abbreviation\<close> is a syntactic definition @{text
   6.390 -  "c\<^sub>\<sigma> \<equiv> t"} of a closed term @{text "t"} of type @{text "\<sigma>"},
   6.391 +  A \<^emph>\<open>term abbreviation\<close> is a syntactic definition \<open>c\<^sub>\<sigma> \<equiv> t\<close> of a closed term \<open>t\<close> of type \<open>\<sigma>\<close>,
   6.392    without any hidden polymorphism.  A term abbreviation looks like a
   6.393    constant in the syntax, but is expanded before entering the logical
   6.394    core.  Abbreviations are usually reverted when printing terms, using
   6.395 -  @{text "t \<rightarrow> c\<^sub>\<sigma>"} as rules for higher-order rewriting.
   6.396 +  \<open>t \<rightarrow> c\<^sub>\<sigma>\<close> as rules for higher-order rewriting.
   6.397  
   6.398    \<^medskip>
   6.399 -  Canonical operations on @{text "\<lambda>"}-terms include @{text
   6.400 -  "\<alpha>\<beta>\<eta>"}-conversion: @{text "\<alpha>"}-conversion refers to capture-free
   6.401 -  renaming of bound variables; @{text "\<beta>"}-conversion contracts an
   6.402 +  Canonical operations on \<open>\<lambda>\<close>-terms include \<open>\<alpha>\<beta>\<eta>\<close>-conversion: \<open>\<alpha>\<close>-conversion refers to capture-free
   6.403 +  renaming of bound variables; \<open>\<beta>\<close>-conversion contracts an
   6.404    abstraction applied to an argument term, substituting the argument
   6.405 -  in the body: @{text "(\<lambda>x. b)a"} becomes @{text "b[a/x]"}; @{text
   6.406 -  "\<eta>"}-conversion contracts vacuous application-abstraction: @{text
   6.407 -  "\<lambda>x. f x"} becomes @{text "f"}, provided that the bound variable
   6.408 -  does not occur in @{text "f"}.
   6.409 +  in the body: \<open>(\<lambda>x. b)a\<close> becomes \<open>b[a/x]\<close>; \<open>\<eta>\<close>-conversion contracts vacuous application-abstraction: \<open>\<lambda>x. f x\<close> becomes \<open>f\<close>, provided that the bound variable
   6.410 +  does not occur in \<open>f\<close>.
   6.411  
   6.412 -  Terms are normally treated modulo @{text "\<alpha>"}-conversion, which is
   6.413 +  Terms are normally treated modulo \<open>\<alpha>\<close>-conversion, which is
   6.414    implicit in the de-Bruijn representation.  Names for bound variables
   6.415    in abstractions are maintained separately as (meaningless) comments,
   6.416 -  mostly for parsing and printing.  Full @{text "\<alpha>\<beta>\<eta>"}-conversion is
   6.417 +  mostly for parsing and printing.  Full \<open>\<alpha>\<beta>\<eta>\<close>-conversion is
   6.418    commonplace in various standard operations (\secref{sec:obj-rules})
   6.419    that are based on higher-order unification and matching.
   6.420  \<close>
   6.421 @@ -381,64 +365,59 @@
   6.422    Free}, @{index_ML Var}, @{index_ML Const}, @{index_ML Abs},
   6.423    @{index_ML_op "$"}.
   6.424  
   6.425 -  \<^descr> @{text "t"}~@{ML_text aconv}~@{text "u"} checks @{text
   6.426 -  "\<alpha>"}-equivalence of two terms.  This is the basic equality relation
   6.427 +  \<^descr> \<open>t\<close>~@{ML_text aconv}~\<open>u\<close> checks \<open>\<alpha>\<close>-equivalence of two terms.  This is the basic equality relation
   6.428    on type @{ML_type term}; raw datatype equality should only be used
   6.429    for operations related to parsing or printing!
   6.430  
   6.431 -  \<^descr> @{ML Term.map_types}~@{text "f t"} applies the mapping @{text
   6.432 -  "f"} to all types occurring in @{text "t"}.
   6.433 +  \<^descr> @{ML Term.map_types}~\<open>f t\<close> applies the mapping \<open>f\<close> to all types occurring in \<open>t\<close>.
   6.434  
   6.435 -  \<^descr> @{ML Term.fold_types}~@{text "f t"} iterates the operation
   6.436 -  @{text "f"} over all occurrences of types in @{text "t"}; the term
   6.437 +  \<^descr> @{ML Term.fold_types}~\<open>f t\<close> iterates the operation
   6.438 +  \<open>f\<close> over all occurrences of types in \<open>t\<close>; the term
   6.439    structure is traversed from left to right.
   6.440  
   6.441 -  \<^descr> @{ML Term.map_aterms}~@{text "f t"} applies the mapping @{text
   6.442 -  "f"} to all atomic terms (@{ML Bound}, @{ML Free}, @{ML Var}, @{ML
   6.443 -  Const}) occurring in @{text "t"}.
   6.444 +  \<^descr> @{ML Term.map_aterms}~\<open>f t\<close> applies the mapping \<open>f\<close> to all atomic terms (@{ML Bound}, @{ML Free}, @{ML Var}, @{ML
   6.445 +  Const}) occurring in \<open>t\<close>.
   6.446  
   6.447 -  \<^descr> @{ML Term.fold_aterms}~@{text "f t"} iterates the operation
   6.448 -  @{text "f"} over all occurrences of atomic terms (@{ML Bound}, @{ML
   6.449 -  Free}, @{ML Var}, @{ML Const}) in @{text "t"}; the term structure is
   6.450 +  \<^descr> @{ML Term.fold_aterms}~\<open>f t\<close> iterates the operation
   6.451 +  \<open>f\<close> over all occurrences of atomic terms (@{ML Bound}, @{ML
   6.452 +  Free}, @{ML Var}, @{ML Const}) in \<open>t\<close>; the term structure is
   6.453    traversed from left to right.
   6.454  
   6.455 -  \<^descr> @{ML fastype_of}~@{text "t"} determines the type of a
   6.456 +  \<^descr> @{ML fastype_of}~\<open>t\<close> determines the type of a
   6.457    well-typed term.  This operation is relatively slow, despite the
   6.458    omission of any sanity checks.
   6.459  
   6.460 -  \<^descr> @{ML lambda}~@{text "a b"} produces an abstraction @{text
   6.461 -  "\<lambda>a. b"}, where occurrences of the atomic term @{text "a"} in the
   6.462 -  body @{text "b"} are replaced by bound variables.
   6.463 +  \<^descr> @{ML lambda}~\<open>a b\<close> produces an abstraction \<open>\<lambda>a. b\<close>, where occurrences of the atomic term \<open>a\<close> in the
   6.464 +  body \<open>b\<close> are replaced by bound variables.
   6.465  
   6.466 -  \<^descr> @{ML betapply}~@{text "(t, u)"} produces an application @{text
   6.467 -  "t u"}, with topmost @{text "\<beta>"}-conversion if @{text "t"} is an
   6.468 +  \<^descr> @{ML betapply}~\<open>(t, u)\<close> produces an application \<open>t u\<close>, with topmost \<open>\<beta>\<close>-conversion if \<open>t\<close> is an
   6.469    abstraction.
   6.470  
   6.471 -  \<^descr> @{ML incr_boundvars}~@{text "j"} increments a term's dangling
   6.472 -  bound variables by the offset @{text "j"}.  This is required when
   6.473 +  \<^descr> @{ML incr_boundvars}~\<open>j\<close> increments a term's dangling
   6.474 +  bound variables by the offset \<open>j\<close>.  This is required when
   6.475    moving a subterm into a context where it is enclosed by a different
   6.476    number of abstractions.  Bound variables with a matching abstraction
   6.477    are unaffected.
   6.478  
   6.479 -  \<^descr> @{ML Sign.declare_const}~@{text "ctxt ((c, \<sigma>), mx)"} declares
   6.480 -  a new constant @{text "c :: \<sigma>"} with optional mixfix syntax.
   6.481 +  \<^descr> @{ML Sign.declare_const}~\<open>ctxt ((c, \<sigma>), mx)\<close> declares
   6.482 +  a new constant \<open>c :: \<sigma>\<close> with optional mixfix syntax.
   6.483  
   6.484 -  \<^descr> @{ML Sign.add_abbrev}~@{text "print_mode (c, t)"}
   6.485 -  introduces a new term abbreviation @{text "c \<equiv> t"}.
   6.486 +  \<^descr> @{ML Sign.add_abbrev}~\<open>print_mode (c, t)\<close>
   6.487 +  introduces a new term abbreviation \<open>c \<equiv> t\<close>.
   6.488  
   6.489 -  \<^descr> @{ML Sign.const_typargs}~@{text "thy (c, \<tau>)"} and @{ML
   6.490 -  Sign.const_instance}~@{text "thy (c, [\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n])"}
   6.491 +  \<^descr> @{ML Sign.const_typargs}~\<open>thy (c, \<tau>)\<close> and @{ML
   6.492 +  Sign.const_instance}~\<open>thy (c, [\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n])\<close>
   6.493    convert between two representations of polymorphic constants: full
   6.494    type instance vs.\ compact type arguments form.
   6.495  \<close>
   6.496  
   6.497  text %mlantiq \<open>
   6.498    \begin{matharray}{rcl}
   6.499 -  @{ML_antiquotation_def "const_name"} & : & @{text ML_antiquotation} \\
   6.500 -  @{ML_antiquotation_def "const_abbrev"} & : & @{text ML_antiquotation} \\
   6.501 -  @{ML_antiquotation_def "const"} & : & @{text ML_antiquotation} \\
   6.502 -  @{ML_antiquotation_def "term"} & : & @{text ML_antiquotation} \\
   6.503 -  @{ML_antiquotation_def "prop"} & : & @{text ML_antiquotation} \\
   6.504 +  @{ML_antiquotation_def "const_name"} & : & \<open>ML_antiquotation\<close> \\
   6.505 +  @{ML_antiquotation_def "const_abbrev"} & : & \<open>ML_antiquotation\<close> \\
   6.506 +  @{ML_antiquotation_def "const"} & : & \<open>ML_antiquotation\<close> \\
   6.507 +  @{ML_antiquotation_def "term"} & : & \<open>ML_antiquotation\<close> \\
   6.508 +  @{ML_antiquotation_def "prop"} & : & \<open>ML_antiquotation\<close> \\
   6.509    \end{matharray}
   6.510  
   6.511    @{rail \<open>
   6.512 @@ -452,45 +431,44 @@
   6.513    @@{ML_antiquotation prop} prop
   6.514    \<close>}
   6.515  
   6.516 -  \<^descr> @{text "@{const_name c}"} inlines the internalized logical
   6.517 -  constant name @{text "c"} --- as @{ML_type string} literal.
   6.518 +  \<^descr> \<open>@{const_name c}\<close> inlines the internalized logical
   6.519 +  constant name \<open>c\<close> --- as @{ML_type string} literal.
   6.520  
   6.521 -  \<^descr> @{text "@{const_abbrev c}"} inlines the internalized
   6.522 -  abbreviated constant name @{text "c"} --- as @{ML_type string}
   6.523 +  \<^descr> \<open>@{const_abbrev c}\<close> inlines the internalized
   6.524 +  abbreviated constant name \<open>c\<close> --- as @{ML_type string}
   6.525    literal.
   6.526  
   6.527 -  \<^descr> @{text "@{const c(\<^vec>\<tau>)}"} inlines the internalized
   6.528 -  constant @{text "c"} with precise type instantiation in the sense of
   6.529 +  \<^descr> \<open>@{const c(\<^vec>\<tau>)}\<close> inlines the internalized
   6.530 +  constant \<open>c\<close> with precise type instantiation in the sense of
   6.531    @{ML Sign.const_instance} --- as @{ML Const} constructor term for
   6.532    datatype @{ML_type term}.
   6.533  
   6.534 -  \<^descr> @{text "@{term t}"} inlines the internalized term @{text "t"}
   6.535 +  \<^descr> \<open>@{term t}\<close> inlines the internalized term \<open>t\<close>
   6.536    --- as constructor term for datatype @{ML_type term}.
   6.537  
   6.538 -  \<^descr> @{text "@{prop \<phi>}"} inlines the internalized proposition
   6.539 -  @{text "\<phi>"} --- as constructor term for datatype @{ML_type term}.
   6.540 +  \<^descr> \<open>@{prop \<phi>}\<close> inlines the internalized proposition
   6.541 +  \<open>\<phi>\<close> --- as constructor term for datatype @{ML_type term}.
   6.542  \<close>
   6.543  
   6.544  
   6.545  section \<open>Theorems \label{sec:thms}\<close>
   6.546  
   6.547  text \<open>
   6.548 -  A \<^emph>\<open>proposition\<close> is a well-typed term of type @{text "prop"}, a
   6.549 +  A \<^emph>\<open>proposition\<close> is a well-typed term of type \<open>prop\<close>, a
   6.550    \<^emph>\<open>theorem\<close> is a proven proposition (depending on a context of
   6.551    hypotheses and the background theory).  Primitive inferences include
   6.552 -  plain Natural Deduction rules for the primary connectives @{text
   6.553 -  "\<And>"} and @{text "\<Longrightarrow>"} of the framework.  There is also a builtin
   6.554 -  notion of equality/equivalence @{text "\<equiv>"}.
   6.555 +  plain Natural Deduction rules for the primary connectives \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> of the framework.  There is also a builtin
   6.556 +  notion of equality/equivalence \<open>\<equiv>\<close>.
   6.557  \<close>
   6.558  
   6.559  
   6.560  subsection \<open>Primitive connectives and rules \label{sec:prim-rules}\<close>
   6.561  
   6.562  text \<open>
   6.563 -  The theory @{text "Pure"} contains constant declarations for the
   6.564 -  primitive connectives @{text "\<And>"}, @{text "\<Longrightarrow>"}, and @{text "\<equiv>"} of
   6.565 +  The theory \<open>Pure\<close> contains constant declarations for the
   6.566 +  primitive connectives \<open>\<And>\<close>, \<open>\<Longrightarrow>\<close>, and \<open>\<equiv>\<close> of
   6.567    the logical framework, see \figref{fig:pure-connectives}.  The
   6.568 -  derivability judgment @{text "A\<^sub>1, \<dots>, A\<^sub>n \<turnstile> B"} is
   6.569 +  derivability judgment \<open>A\<^sub>1, \<dots>, A\<^sub>n \<turnstile> B\<close> is
   6.570    defined inductively by the primitive inferences given in
   6.571    \figref{fig:prim-rules}, with the global restriction that the
   6.572    hypotheses must \<^emph>\<open>not\<close> contain any schematic variables.  The
   6.573 @@ -501,9 +479,9 @@
   6.574    \begin{figure}[htb]
   6.575    \begin{center}
   6.576    \begin{tabular}{ll}
   6.577 -  @{text "all :: (\<alpha> \<Rightarrow> prop) \<Rightarrow> prop"} & universal quantification (binder @{text "\<And>"}) \\
   6.578 -  @{text "\<Longrightarrow> :: prop \<Rightarrow> prop \<Rightarrow> prop"} & implication (right associative infix) \\
   6.579 -  @{text "\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop"} & equality relation (infix) \\
   6.580 +  \<open>all :: (\<alpha> \<Rightarrow> prop) \<Rightarrow> prop\<close> & universal quantification (binder \<open>\<And>\<close>) \\
   6.581 +  \<open>\<Longrightarrow> :: prop \<Rightarrow> prop \<Rightarrow> prop\<close> & implication (right associative infix) \\
   6.582 +  \<open>\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow> prop\<close> & equality relation (infix) \\
   6.583    \end{tabular}
   6.584    \caption{Primitive connectives of Pure}\label{fig:pure-connectives}
   6.585    \end{center}
   6.586 @@ -512,19 +490,19 @@
   6.587    \begin{figure}[htb]
   6.588    \begin{center}
   6.589    \[
   6.590 -  \infer[@{text "(axiom)"}]{@{text "\<turnstile> A"}}{@{text "A \<in> \<Theta>"}}
   6.591 +  \infer[\<open>(axiom)\<close>]{\<open>\<turnstile> A\<close>}{\<open>A \<in> \<Theta>\<close>}
   6.592    \qquad
   6.593 -  \infer[@{text "(assume)"}]{@{text "A \<turnstile> A"}}{}
   6.594 +  \infer[\<open>(assume)\<close>]{\<open>A \<turnstile> A\<close>}{}
   6.595    \]
   6.596    \[
   6.597 -  \infer[@{text "(\<And>\<hyphen>intro)"}]{@{text "\<Gamma> \<turnstile> \<And>x. B[x]"}}{@{text "\<Gamma> \<turnstile> B[x]"} & @{text "x \<notin> \<Gamma>"}}
   6.598 +  \infer[\<open>(\<And>\<hyphen>intro)\<close>]{\<open>\<Gamma> \<turnstile> \<And>x. B[x]\<close>}{\<open>\<Gamma> \<turnstile> B[x]\<close> & \<open>x \<notin> \<Gamma>\<close>}
   6.599    \qquad
   6.600 -  \infer[@{text "(\<And>\<hyphen>elim)"}]{@{text "\<Gamma> \<turnstile> B[a]"}}{@{text "\<Gamma> \<turnstile> \<And>x. B[x]"}}
   6.601 +  \infer[\<open>(\<And>\<hyphen>elim)\<close>]{\<open>\<Gamma> \<turnstile> B[a]\<close>}{\<open>\<Gamma> \<turnstile> \<And>x. B[x]\<close>}
   6.602    \]
   6.603    \[
   6.604 -  \infer[@{text "(\<Longrightarrow>\<hyphen>intro)"}]{@{text "\<Gamma> - A \<turnstile> A \<Longrightarrow> B"}}{@{text "\<Gamma> \<turnstile> B"}}
   6.605 +  \infer[\<open>(\<Longrightarrow>\<hyphen>intro)\<close>]{\<open>\<Gamma> - A \<turnstile> A \<Longrightarrow> B\<close>}{\<open>\<Gamma> \<turnstile> B\<close>}
   6.606    \qquad
   6.607 -  \infer[@{text "(\<Longrightarrow>\<hyphen>elim)"}]{@{text "\<Gamma>\<^sub>1 \<union> \<Gamma>\<^sub>2 \<turnstile> B"}}{@{text "\<Gamma>\<^sub>1 \<turnstile> A \<Longrightarrow> B"} & @{text "\<Gamma>\<^sub>2 \<turnstile> A"}}
   6.608 +  \infer[\<open>(\<Longrightarrow>\<hyphen>elim)\<close>]{\<open>\<Gamma>\<^sub>1 \<union> \<Gamma>\<^sub>2 \<turnstile> B\<close>}{\<open>\<Gamma>\<^sub>1 \<turnstile> A \<Longrightarrow> B\<close> & \<open>\<Gamma>\<^sub>2 \<turnstile> A\<close>}
   6.609    \]
   6.610    \caption{Primitive inferences of Pure}\label{fig:prim-rules}
   6.611    \end{center}
   6.612 @@ -533,72 +511,66 @@
   6.613    \begin{figure}[htb]
   6.614    \begin{center}
   6.615    \begin{tabular}{ll}
   6.616 -  @{text "\<turnstile> (\<lambda>x. b[x]) a \<equiv> b[a]"} & @{text "\<beta>"}-conversion \\
   6.617 -  @{text "\<turnstile> x \<equiv> x"} & reflexivity \\
   6.618 -  @{text "\<turnstile> x \<equiv> y \<Longrightarrow> P x \<Longrightarrow> P y"} & substitution \\
   6.619 -  @{text "\<turnstile> (\<And>x. f x \<equiv> g x) \<Longrightarrow> f \<equiv> g"} & extensionality \\
   6.620 -  @{text "\<turnstile> (A \<Longrightarrow> B) \<Longrightarrow> (B \<Longrightarrow> A) \<Longrightarrow> A \<equiv> B"} & logical equivalence \\
   6.621 +  \<open>\<turnstile> (\<lambda>x. b[x]) a \<equiv> b[a]\<close> & \<open>\<beta>\<close>-conversion \\
   6.622 +  \<open>\<turnstile> x \<equiv> x\<close> & reflexivity \\
   6.623 +  \<open>\<turnstile> x \<equiv> y \<Longrightarrow> P x \<Longrightarrow> P y\<close> & substitution \\
   6.624 +  \<open>\<turnstile> (\<And>x. f x \<equiv> g x) \<Longrightarrow> f \<equiv> g\<close> & extensionality \\
   6.625 +  \<open>\<turnstile> (A \<Longrightarrow> B) \<Longrightarrow> (B \<Longrightarrow> A) \<Longrightarrow> A \<equiv> B\<close> & logical equivalence \\
   6.626    \end{tabular}
   6.627    \caption{Conceptual axiomatization of Pure equality}\label{fig:pure-equality}
   6.628    \end{center}
   6.629    \end{figure}
   6.630  
   6.631 -  The introduction and elimination rules for @{text "\<And>"} and @{text
   6.632 -  "\<Longrightarrow>"} are analogous to formation of dependently typed @{text
   6.633 -  "\<lambda>"}-terms representing the underlying proof objects.  Proof terms
   6.634 +  The introduction and elimination rules for \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> are analogous to formation of dependently typed \<open>\<lambda>\<close>-terms representing the underlying proof objects.  Proof terms
   6.635    are irrelevant in the Pure logic, though; they cannot occur within
   6.636    propositions.  The system provides a runtime option to record
   6.637    explicit proof terms for primitive inferences, see also
   6.638 -  \secref{sec:proof-terms}.  Thus all three levels of @{text
   6.639 -  "\<lambda>"}-calculus become explicit: @{text "\<Rightarrow>"} for terms, and @{text
   6.640 -  "\<And>/\<Longrightarrow>"} for proofs (cf.\ @{cite "Berghofer-Nipkow:2000:TPHOL"}).
   6.641 +  \secref{sec:proof-terms}.  Thus all three levels of \<open>\<lambda>\<close>-calculus become explicit: \<open>\<Rightarrow>\<close> for terms, and \<open>\<And>/\<Longrightarrow>\<close> for proofs (cf.\ @{cite "Berghofer-Nipkow:2000:TPHOL"}).
   6.642  
   6.643 -  Observe that locally fixed parameters (as in @{text
   6.644 -  "\<And>\<hyphen>intro"}) need not be recorded in the hypotheses, because
   6.645 +  Observe that locally fixed parameters (as in \<open>\<And>\<hyphen>intro\<close>) need not be recorded in the hypotheses, because
   6.646    the simple syntactic types of Pure are always inhabitable.
   6.647 -  ``Assumptions'' @{text "x :: \<tau>"} for type-membership are only
   6.648 -  present as long as some @{text "x\<^sub>\<tau>"} occurs in the statement
   6.649 -  body.\footnote{This is the key difference to ``@{text "\<lambda>HOL"}'' in
   6.650 +  ``Assumptions'' \<open>x :: \<tau>\<close> for type-membership are only
   6.651 +  present as long as some \<open>x\<^sub>\<tau>\<close> occurs in the statement
   6.652 +  body.\footnote{This is the key difference to ``\<open>\<lambda>HOL\<close>'' in
   6.653    the PTS framework @{cite "Barendregt-Geuvers:2001"}, where hypotheses
   6.654 -  @{text "x : A"} are treated uniformly for propositions and types.}
   6.655 +  \<open>x : A\<close> are treated uniformly for propositions and types.}
   6.656  
   6.657    \<^medskip>
   6.658    The axiomatization of a theory is implicitly closed by
   6.659 -  forming all instances of type and term variables: @{text "\<turnstile>
   6.660 -  A\<vartheta>"} holds for any substitution instance of an axiom
   6.661 -  @{text "\<turnstile> A"}.  By pushing substitutions through derivations
   6.662 -  inductively, we also get admissible @{text "generalize"} and @{text
   6.663 -  "instantiate"} rules as shown in \figref{fig:subst-rules}.
   6.664 +  forming all instances of type and term variables: \<open>\<turnstile>
   6.665 +  A\<vartheta>\<close> holds for any substitution instance of an axiom
   6.666 +  \<open>\<turnstile> A\<close>.  By pushing substitutions through derivations
   6.667 +  inductively, we also get admissible \<open>generalize\<close> and \<open>instantiate\<close> rules as shown in \figref{fig:subst-rules}.
   6.668  
   6.669    \begin{figure}[htb]
   6.670    \begin{center}
   6.671    \[
   6.672 -  \infer{@{text "\<Gamma> \<turnstile> B[?\<alpha>]"}}{@{text "\<Gamma> \<turnstile> B[\<alpha>]"} & @{text "\<alpha> \<notin> \<Gamma>"}}
   6.673 +  \infer{\<open>\<Gamma> \<turnstile> B[?\<alpha>]\<close>}{\<open>\<Gamma> \<turnstile> B[\<alpha>]\<close> & \<open>\<alpha> \<notin> \<Gamma>\<close>}
   6.674    \quad
   6.675 -  \infer[\quad@{text "(generalize)"}]{@{text "\<Gamma> \<turnstile> B[?x]"}}{@{text "\<Gamma> \<turnstile> B[x]"} & @{text "x \<notin> \<Gamma>"}}
   6.676 +  \infer[\quad\<open>(generalize)\<close>]{\<open>\<Gamma> \<turnstile> B[?x]\<close>}{\<open>\<Gamma> \<turnstile> B[x]\<close> & \<open>x \<notin> \<Gamma>\<close>}
   6.677    \]
   6.678    \[
   6.679 -  \infer{@{text "\<Gamma> \<turnstile> B[\<tau>]"}}{@{text "\<Gamma> \<turnstile> B[?\<alpha>]"}}
   6.680 +  \infer{\<open>\<Gamma> \<turnstile> B[\<tau>]\<close>}{\<open>\<Gamma> \<turnstile> B[?\<alpha>]\<close>}
   6.681    \quad
   6.682 -  \infer[\quad@{text "(instantiate)"}]{@{text "\<Gamma> \<turnstile> B[t]"}}{@{text "\<Gamma> \<turnstile> B[?x]"}}
   6.683 +  \infer[\quad\<open>(instantiate)\<close>]{\<open>\<Gamma> \<turnstile> B[t]\<close>}{\<open>\<Gamma> \<turnstile> B[?x]\<close>}
   6.684    \]
   6.685    \caption{Admissible substitution rules}\label{fig:subst-rules}
   6.686    \end{center}
   6.687    \end{figure}
   6.688  
   6.689 -  Note that @{text "instantiate"} does not require an explicit
   6.690 -  side-condition, because @{text "\<Gamma>"} may never contain schematic
   6.691 +  Note that \<open>instantiate\<close> does not require an explicit
   6.692 +  side-condition, because \<open>\<Gamma>\<close> may never contain schematic
   6.693    variables.
   6.694  
   6.695    In principle, variables could be substituted in hypotheses as well,
   6.696    but this would disrupt the monotonicity of reasoning: deriving
   6.697 -  @{text "\<Gamma>\<vartheta> \<turnstile> B\<vartheta>"} from @{text "\<Gamma> \<turnstile> B"} is
   6.698 -  correct, but @{text "\<Gamma>\<vartheta> \<supseteq> \<Gamma>"} does not necessarily hold:
   6.699 +  \<open>\<Gamma>\<vartheta> \<turnstile> B\<vartheta>\<close> from \<open>\<Gamma> \<turnstile> B\<close> is
   6.700 +  correct, but \<open>\<Gamma>\<vartheta> \<supseteq> \<Gamma>\<close> does not necessarily hold:
   6.701    the result belongs to a different proof context.
   6.702  
   6.703    \<^medskip>
   6.704    An \<^emph>\<open>oracle\<close> is a function that produces axioms on the
   6.705 -  fly.  Logically, this is an instance of the @{text "axiom"} rule
   6.706 +  fly.  Logically, this is an instance of the \<open>axiom\<close> rule
   6.707    (\figref{fig:prim-rules}), but there is an operational difference.
   6.708    The system always records oracle invocations within derivations of
   6.709    theorems by a unique tag.
   6.710 @@ -608,20 +580,16 @@
   6.711    Later on, theories are usually developed in a strictly definitional
   6.712    fashion, by stating only certain equalities over new constants.
   6.713  
   6.714 -  A \<^emph>\<open>simple definition\<close> consists of a constant declaration @{text
   6.715 -  "c :: \<sigma>"} together with an axiom @{text "\<turnstile> c \<equiv> t"}, where @{text "t
   6.716 -  :: \<sigma>"} is a closed term without any hidden polymorphism.  The RHS
   6.717 -  may depend on further defined constants, but not @{text "c"} itself.
   6.718 -  Definitions of functions may be presented as @{text "c \<^vec>x \<equiv>
   6.719 -  t"} instead of the puristic @{text "c \<equiv> \<lambda>\<^vec>x. t"}.
   6.720 +  A \<^emph>\<open>simple definition\<close> consists of a constant declaration \<open>c :: \<sigma>\<close> together with an axiom \<open>\<turnstile> c \<equiv> t\<close>, where \<open>t
   6.721 +  :: \<sigma>\<close> is a closed term without any hidden polymorphism.  The RHS
   6.722 +  may depend on further defined constants, but not \<open>c\<close> itself.
   6.723 +  Definitions of functions may be presented as \<open>c \<^vec>x \<equiv>
   6.724 +  t\<close> instead of the puristic \<open>c \<equiv> \<lambda>\<^vec>x. t\<close>.
   6.725  
   6.726    An \<^emph>\<open>overloaded definition\<close> consists of a collection of axioms
   6.727 -  for the same constant, with zero or one equations @{text
   6.728 -  "c((\<^vec>\<alpha>)\<kappa>) \<equiv> t"} for each type constructor @{text "\<kappa>"} (for
   6.729 -  distinct variables @{text "\<^vec>\<alpha>"}).  The RHS may mention
   6.730 -  previously defined constants as above, or arbitrary constants @{text
   6.731 -  "d(\<alpha>\<^sub>i)"} for some @{text "\<alpha>\<^sub>i"} projected from @{text
   6.732 -  "\<^vec>\<alpha>"}.  Thus overloaded definitions essentially work by
   6.733 +  for the same constant, with zero or one equations \<open>c((\<^vec>\<alpha>)\<kappa>) \<equiv> t\<close> for each type constructor \<open>\<kappa>\<close> (for
   6.734 +  distinct variables \<open>\<^vec>\<alpha>\<close>).  The RHS may mention
   6.735 +  previously defined constants as above, or arbitrary constants \<open>d(\<alpha>\<^sub>i)\<close> for some \<open>\<alpha>\<^sub>i\<close> projected from \<open>\<^vec>\<alpha>\<close>.  Thus overloaded definitions essentially work by
   6.736    primitive recursion over the syntactic structure of a single type
   6.737    argument.  See also @{cite \<open>\S4.3\<close> "Haftmann-Wenzel:2006:classes"}.
   6.738  \<close>
   6.739 @@ -665,7 +633,7 @@
   6.740    Defs.entry -> Defs.entry list -> theory -> theory"} \\
   6.741    \end{mldecls}
   6.742  
   6.743 -  \<^descr> @{ML Thm.peek_status}~@{text "thm"} informs about the current
   6.744 +  \<^descr> @{ML Thm.peek_status}~\<open>thm\<close> informs about the current
   6.745    status of the derivation object behind the given theorem.  This is a
   6.746    snapshot of a potentially ongoing (parallel) evaluation of proofs.
   6.747    The three Boolean values indicate the following: @{verbatim oracle}
   6.748 @@ -674,13 +642,13 @@
   6.749    failed} if some future proof has failed, rendering the theorem
   6.750    invalid!
   6.751  
   6.752 -  \<^descr> @{ML Logic.all}~@{text "a B"} produces a Pure quantification
   6.753 -  @{text "\<And>a. B"}, where occurrences of the atomic term @{text "a"} in
   6.754 -  the body proposition @{text "B"} are replaced by bound variables.
   6.755 +  \<^descr> @{ML Logic.all}~\<open>a B\<close> produces a Pure quantification
   6.756 +  \<open>\<And>a. B\<close>, where occurrences of the atomic term \<open>a\<close> in
   6.757 +  the body proposition \<open>B\<close> are replaced by bound variables.
   6.758    (See also @{ML lambda} on terms.)
   6.759  
   6.760 -  \<^descr> @{ML Logic.mk_implies}~@{text "(A, B)"} produces a Pure
   6.761 -  implication @{text "A \<Longrightarrow> B"}.
   6.762 +  \<^descr> @{ML Logic.mk_implies}~\<open>(A, B)\<close> produces a Pure
   6.763 +  implication \<open>A \<Longrightarrow> B\<close>.
   6.764  
   6.765    \<^descr> Types @{ML_type ctyp} and @{ML_type cterm} represent certified
   6.766    types and terms, respectively.  These are abstract datatypes that
   6.767 @@ -693,8 +661,8 @@
   6.768    are located in the @{ML_structure Thm} module, even though theorems are
   6.769    not yet involved at that stage.
   6.770  
   6.771 -  \<^descr> @{ML Thm.ctyp_of}~@{text "ctxt \<tau>"} and @{ML
   6.772 -  Thm.cterm_of}~@{text "ctxt t"} explicitly check types and terms,
   6.773 +  \<^descr> @{ML Thm.ctyp_of}~\<open>ctxt \<tau>\<close> and @{ML
   6.774 +  Thm.cterm_of}~\<open>ctxt t\<close> explicitly check types and terms,
   6.775    respectively.  This also involves some basic normalizations, such
   6.776    expansion of type and term abbreviations from the underlying
   6.777    theory context.
   6.778 @@ -716,7 +684,7 @@
   6.779    Every @{ML_type thm} value refers its background theory,
   6.780    cf.\ \secref{sec:context-theory}.
   6.781  
   6.782 -  \<^descr> @{ML Thm.transfer}~@{text "thy thm"} transfers the given
   6.783 +  \<^descr> @{ML Thm.transfer}~\<open>thy thm\<close> transfers the given
   6.784    theorem to a \<^emph>\<open>larger\<close> theory, see also \secref{sec:context}.
   6.785    This formal adjustment of the background context has no logical
   6.786    significance, but is occasionally required for formal reasons, e.g.\
   6.787 @@ -727,50 +695,48 @@
   6.788    Thm.forall_elim}, @{ML Thm.implies_intr}, and @{ML Thm.implies_elim}
   6.789    correspond to the primitive inferences of \figref{fig:prim-rules}.
   6.790  
   6.791 -  \<^descr> @{ML Thm.generalize}~@{text "(\<^vec>\<alpha>, \<^vec>x)"}
   6.792 -  corresponds to the @{text "generalize"} rules of
   6.793 +  \<^descr> @{ML Thm.generalize}~\<open>(\<^vec>\<alpha>, \<^vec>x)\<close>
   6.794 +  corresponds to the \<open>generalize\<close> rules of
   6.795    \figref{fig:subst-rules}.  Here collections of type and term
   6.796    variables are generalized simultaneously, specified by the given
   6.797    basic names.
   6.798  
   6.799 -  \<^descr> @{ML Thm.instantiate}~@{text "(\<^vec>\<alpha>\<^sub>s,
   6.800 -  \<^vec>x\<^sub>\<tau>)"} corresponds to the @{text "instantiate"} rules
   6.801 +  \<^descr> @{ML Thm.instantiate}~\<open>(\<^vec>\<alpha>\<^sub>s,
   6.802 +  \<^vec>x\<^sub>\<tau>)\<close> corresponds to the \<open>instantiate\<close> rules
   6.803    of \figref{fig:subst-rules}.  Type variables are substituted before
   6.804 -  term variables.  Note that the types in @{text "\<^vec>x\<^sub>\<tau>"}
   6.805 +  term variables.  Note that the types in \<open>\<^vec>x\<^sub>\<tau>\<close>
   6.806    refer to the instantiated versions.
   6.807  
   6.808 -  \<^descr> @{ML Thm.add_axiom}~@{text "ctxt (name, A)"} declares an
   6.809 +  \<^descr> @{ML Thm.add_axiom}~\<open>ctxt (name, A)\<close> declares an
   6.810    arbitrary proposition as axiom, and retrieves it as a theorem from
   6.811 -  the resulting theory, cf.\ @{text "axiom"} in
   6.812 +  the resulting theory, cf.\ \<open>axiom\<close> in
   6.813    \figref{fig:prim-rules}.  Note that the low-level representation in
   6.814    the axiom table may differ slightly from the returned theorem.
   6.815  
   6.816 -  \<^descr> @{ML Thm.add_oracle}~@{text "(binding, oracle)"} produces a named
   6.817 +  \<^descr> @{ML Thm.add_oracle}~\<open>(binding, oracle)\<close> produces a named
   6.818    oracle rule, essentially generating arbitrary axioms on the fly,
   6.819 -  cf.\ @{text "axiom"} in \figref{fig:prim-rules}.
   6.820 +  cf.\ \<open>axiom\<close> in \figref{fig:prim-rules}.
   6.821  
   6.822 -  \<^descr> @{ML Thm.add_def}~@{text "ctxt unchecked overloaded (name, c
   6.823 -  \<^vec>x \<equiv> t)"} states a definitional axiom for an existing constant
   6.824 -  @{text "c"}.  Dependencies are recorded via @{ML Theory.add_deps},
   6.825 -  unless the @{text "unchecked"} option is set.  Note that the
   6.826 +  \<^descr> @{ML Thm.add_def}~\<open>ctxt unchecked overloaded (name, c
   6.827 +  \<^vec>x \<equiv> t)\<close> states a definitional axiom for an existing constant
   6.828 +  \<open>c\<close>.  Dependencies are recorded via @{ML Theory.add_deps},
   6.829 +  unless the \<open>unchecked\<close> option is set.  Note that the
   6.830    low-level representation in the axiom table may differ slightly from
   6.831    the returned theorem.
   6.832  
   6.833 -  \<^descr> @{ML Theory.add_deps}~@{text "ctxt name c\<^sub>\<tau> \<^vec>d\<^sub>\<sigma>"}
   6.834 -  declares dependencies of a named specification for constant @{text
   6.835 -  "c\<^sub>\<tau>"}, relative to existing specifications for constants @{text
   6.836 -  "\<^vec>d\<^sub>\<sigma>"}.  This also works for type constructors.
   6.837 +  \<^descr> @{ML Theory.add_deps}~\<open>ctxt name c\<^sub>\<tau> \<^vec>d\<^sub>\<sigma>\<close>
   6.838 +  declares dependencies of a named specification for constant \<open>c\<^sub>\<tau>\<close>, relative to existing specifications for constants \<open>\<^vec>d\<^sub>\<sigma>\<close>.  This also works for type constructors.
   6.839  \<close>
   6.840  
   6.841  
   6.842  text %mlantiq \<open>
   6.843    \begin{matharray}{rcl}
   6.844 -  @{ML_antiquotation_def "ctyp"} & : & @{text ML_antiquotation} \\
   6.845 -  @{ML_antiquotation_def "cterm"} & : & @{text ML_antiquotation} \\
   6.846 -  @{ML_antiquotation_def "cprop"} & : & @{text ML_antiquotation} \\
   6.847 -  @{ML_antiquotation_def "thm"} & : & @{text ML_antiquotation} \\
   6.848 -  @{ML_antiquotation_def "thms"} & : & @{text ML_antiquotation} \\
   6.849 -  @{ML_antiquotation_def "lemma"} & : & @{text ML_antiquotation} \\
   6.850 +  @{ML_antiquotation_def "ctyp"} & : & \<open>ML_antiquotation\<close> \\
   6.851 +  @{ML_antiquotation_def "cterm"} & : & \<open>ML_antiquotation\<close> \\
   6.852 +  @{ML_antiquotation_def "cprop"} & : & \<open>ML_antiquotation\<close> \\
   6.853 +  @{ML_antiquotation_def "thm"} & : & \<open>ML_antiquotation\<close> \\
   6.854 +  @{ML_antiquotation_def "thms"} & : & \<open>ML_antiquotation\<close> \\
   6.855 +  @{ML_antiquotation_def "lemma"} & : & \<open>ML_antiquotation\<close> \\
   6.856    \end{matharray}
   6.857  
   6.858    @{rail \<open>
   6.859 @@ -788,28 +754,28 @@
   6.860      @'by' method method?
   6.861    \<close>}
   6.862  
   6.863 -  \<^descr> @{text "@{ctyp \<tau>}"} produces a certified type wrt.\ the
   6.864 +  \<^descr> \<open>@{ctyp \<tau>}\<close> produces a certified type wrt.\ the
   6.865    current background theory --- as abstract value of type @{ML_type
   6.866    ctyp}.
   6.867  
   6.868 -  \<^descr> @{text "@{cterm t}"} and @{text "@{cprop \<phi>}"} produce a
   6.869 +  \<^descr> \<open>@{cterm t}\<close> and \<open>@{cprop \<phi>}\<close> produce a
   6.870    certified term wrt.\ the current background theory --- as abstract
   6.871    value of type @{ML_type cterm}.
   6.872  
   6.873 -  \<^descr> @{text "@{thm a}"} produces a singleton fact --- as abstract
   6.874 +  \<^descr> \<open>@{thm a}\<close> produces a singleton fact --- as abstract
   6.875    value of type @{ML_type thm}.
   6.876  
   6.877 -  \<^descr> @{text "@{thms a}"} produces a general fact --- as abstract
   6.878 +  \<^descr> \<open>@{thms a}\<close> produces a general fact --- as abstract
   6.879    value of type @{ML_type "thm list"}.
   6.880  
   6.881 -  \<^descr> @{text "@{lemma \<phi> by meth}"} produces a fact that is proven on
   6.882 +  \<^descr> \<open>@{lemma \<phi> by meth}\<close> produces a fact that is proven on
   6.883    the spot according to the minimal proof, which imitates a terminal
   6.884    Isar proof.  The result is an abstract value of type @{ML_type thm}
   6.885    or @{ML_type "thm list"}, depending on the number of propositions
   6.886    given here.
   6.887  
   6.888    The internal derivation object lacks a proper theorem name, but it
   6.889 -  is formally closed, unless the @{text "(open)"} option is specified
   6.890 +  is formally closed, unless the \<open>(open)\<close> option is specified
   6.891    (this may impact performance of applications with proof terms).
   6.892  
   6.893    Since ML antiquotations are always evaluated at compile-time, there
   6.894 @@ -823,7 +789,7 @@
   6.895  
   6.896  subsection \<open>Auxiliary connectives \label{sec:logic-aux}\<close>
   6.897  
   6.898 -text \<open>Theory @{text "Pure"} provides a few auxiliary connectives
   6.899 +text \<open>Theory \<open>Pure\<close> provides a few auxiliary connectives
   6.900    that are defined on top of the primitive ones, see
   6.901    \figref{fig:pure-aux}.  These special constants are useful in
   6.902    certain internal encodings, and are normally not directly exposed to
   6.903 @@ -832,51 +798,49 @@
   6.904    \begin{figure}[htb]
   6.905    \begin{center}
   6.906    \begin{tabular}{ll}
   6.907 -  @{text "conjunction :: prop \<Rightarrow> prop \<Rightarrow> prop"} & (infix @{text "&&&"}) \\
   6.908 -  @{text "\<turnstile> A &&& B \<equiv> (\<And>C. (A \<Longrightarrow> B \<Longrightarrow> C) \<Longrightarrow> C)"} \\[1ex]
   6.909 -  @{text "prop :: prop \<Rightarrow> prop"} & (prefix @{text "#"}, suppressed) \\
   6.910 -  @{text "#A \<equiv> A"} \\[1ex]
   6.911 -  @{text "term :: \<alpha> \<Rightarrow> prop"} & (prefix @{text "TERM"}) \\
   6.912 -  @{text "term x \<equiv> (\<And>A. A \<Longrightarrow> A)"} \\[1ex]
   6.913 -  @{text "type :: \<alpha> itself"} & (prefix @{text "TYPE"}) \\
   6.914 -  @{text "(unspecified)"} \\
   6.915 +  \<open>conjunction :: prop \<Rightarrow> prop \<Rightarrow> prop\<close> & (infix \<open>&&&\<close>) \\
   6.916 +  \<open>\<turnstile> A &&& B \<equiv> (\<And>C. (A \<Longrightarrow> B \<Longrightarrow> C) \<Longrightarrow> C)\<close> \\[1ex]
   6.917 +  \<open>prop :: prop \<Rightarrow> prop\<close> & (prefix \<open>#\<close>, suppressed) \\
   6.918 +  \<open>#A \<equiv> A\<close> \\[1ex]
   6.919 +  \<open>term :: \<alpha> \<Rightarrow> prop\<close> & (prefix \<open>TERM\<close>) \\
   6.920 +  \<open>term x \<equiv> (\<And>A. A \<Longrightarrow> A)\<close> \\[1ex]
   6.921 +  \<open>type :: \<alpha> itself\<close> & (prefix \<open>TYPE\<close>) \\
   6.922 +  \<open>(unspecified)\<close> \\
   6.923    \end{tabular}
   6.924    \caption{Definitions of auxiliary connectives}\label{fig:pure-aux}
   6.925    \end{center}
   6.926    \end{figure}
   6.927  
   6.928 -  The introduction @{text "A \<Longrightarrow> B \<Longrightarrow> A &&& B"}, and eliminations
   6.929 -  (projections) @{text "A &&& B \<Longrightarrow> A"} and @{text "A &&& B \<Longrightarrow> B"} are
   6.930 +  The introduction \<open>A \<Longrightarrow> B \<Longrightarrow> A &&& B\<close>, and eliminations
   6.931 +  (projections) \<open>A &&& B \<Longrightarrow> A\<close> and \<open>A &&& B \<Longrightarrow> B\<close> are
   6.932    available as derived rules.  Conjunction allows to treat
   6.933    simultaneous assumptions and conclusions uniformly, e.g.\ consider
   6.934 -  @{text "A \<Longrightarrow> B \<Longrightarrow> C &&& D"}.  In particular, the goal mechanism
   6.935 +  \<open>A \<Longrightarrow> B \<Longrightarrow> C &&& D\<close>.  In particular, the goal mechanism
   6.936    represents multiple claims as explicit conjunction internally, but
   6.937    this is refined (via backwards introduction) into separate sub-goals
   6.938    before the user commences the proof; the final result is projected
   6.939    into a list of theorems using eliminations (cf.\
   6.940    \secref{sec:tactical-goals}).
   6.941  
   6.942 -  The @{text "prop"} marker (@{text "#"}) makes arbitrarily complex
   6.943 -  propositions appear as atomic, without changing the meaning: @{text
   6.944 -  "\<Gamma> \<turnstile> A"} and @{text "\<Gamma> \<turnstile> #A"} are interchangeable.  See
   6.945 +  The \<open>prop\<close> marker (\<open>#\<close>) makes arbitrarily complex
   6.946 +  propositions appear as atomic, without changing the meaning: \<open>\<Gamma> \<turnstile> A\<close> and \<open>\<Gamma> \<turnstile> #A\<close> are interchangeable.  See
   6.947    \secref{sec:tactical-goals} for specific operations.
   6.948  
   6.949 -  The @{text "term"} marker turns any well-typed term into a derivable
   6.950 -  proposition: @{text "\<turnstile> TERM t"} holds unconditionally.  Although
   6.951 +  The \<open>term\<close> marker turns any well-typed term into a derivable
   6.952 +  proposition: \<open>\<turnstile> TERM t\<close> holds unconditionally.  Although
   6.953    this is logically vacuous, it allows to treat terms and proofs
   6.954    uniformly, similar to a type-theoretic framework.
   6.955  
   6.956 -  The @{text "TYPE"} constructor is the canonical representative of
   6.957 -  the unspecified type @{text "\<alpha> itself"}; it essentially injects the
   6.958 +  The \<open>TYPE\<close> constructor is the canonical representative of
   6.959 +  the unspecified type \<open>\<alpha> itself\<close>; it essentially injects the
   6.960    language of types into that of terms.  There is specific notation
   6.961 -  @{text "TYPE(\<tau>)"} for @{text "TYPE\<^bsub>\<tau> itself\<^esub>"}.
   6.962 -  Although being devoid of any particular meaning, the term @{text
   6.963 -  "TYPE(\<tau>)"} accounts for the type @{text "\<tau>"} within the term
   6.964 -  language.  In particular, @{text "TYPE(\<alpha>)"} may be used as formal
   6.965 +  \<open>TYPE(\<tau>)\<close> for \<open>TYPE\<^bsub>\<tau> itself\<^esub>\<close>.
   6.966 +  Although being devoid of any particular meaning, the term \<open>TYPE(\<tau>)\<close> accounts for the type \<open>\<tau>\<close> within the term
   6.967 +  language.  In particular, \<open>TYPE(\<alpha>)\<close> may be used as formal
   6.968    argument in primitive definitions, in order to circumvent hidden
   6.969 -  polymorphism (cf.\ \secref{sec:terms}).  For example, @{text "c
   6.970 -  TYPE(\<alpha>) \<equiv> A[\<alpha>]"} defines @{text "c :: \<alpha> itself \<Rightarrow> prop"} in terms of
   6.971 -  a proposition @{text "A"} that depends on an additional type
   6.972 +  polymorphism (cf.\ \secref{sec:terms}).  For example, \<open>c
   6.973 +  TYPE(\<alpha>) \<equiv> A[\<alpha>]\<close> defines \<open>c :: \<alpha> itself \<Rightarrow> prop\<close> in terms of
   6.974 +  a proposition \<open>A\<close> that depends on an additional type
   6.975    argument, which is essentially a predicate on types.
   6.976  \<close>
   6.977  
   6.978 @@ -890,22 +854,19 @@
   6.979    @{index_ML Logic.dest_type: "term -> typ"} \\
   6.980    \end{mldecls}
   6.981  
   6.982 -  \<^descr> @{ML Conjunction.intr} derives @{text "A &&& B"} from @{text
   6.983 -  "A"} and @{text "B"}.
   6.984 +  \<^descr> @{ML Conjunction.intr} derives \<open>A &&& B\<close> from \<open>A\<close> and \<open>B\<close>.
   6.985  
   6.986 -  \<^descr> @{ML Conjunction.elim} derives @{text "A"} and @{text "B"}
   6.987 -  from @{text "A &&& B"}.
   6.988 +  \<^descr> @{ML Conjunction.elim} derives \<open>A\<close> and \<open>B\<close>
   6.989 +  from \<open>A &&& B\<close>.
   6.990  
   6.991 -  \<^descr> @{ML Drule.mk_term} derives @{text "TERM t"}.
   6.992 +  \<^descr> @{ML Drule.mk_term} derives \<open>TERM t\<close>.
   6.993  
   6.994 -  \<^descr> @{ML Drule.dest_term} recovers term @{text "t"} from @{text
   6.995 -  "TERM t"}.
   6.996 +  \<^descr> @{ML Drule.dest_term} recovers term \<open>t\<close> from \<open>TERM t\<close>.
   6.997  
   6.998 -  \<^descr> @{ML Logic.mk_type}~@{text "\<tau>"} produces the term @{text
   6.999 -  "TYPE(\<tau>)"}.
  6.1000 +  \<^descr> @{ML Logic.mk_type}~\<open>\<tau>\<close> produces the term \<open>TYPE(\<tau>)\<close>.
  6.1001  
  6.1002 -  \<^descr> @{ML Logic.dest_type}~@{text "TYPE(\<tau>)"} recovers the type
  6.1003 -  @{text "\<tau>"}.
  6.1004 +  \<^descr> @{ML Logic.dest_type}~\<open>TYPE(\<tau>)\<close> recovers the type
  6.1005 +  \<open>\<tau>\<close>.
  6.1006  \<close>
  6.1007  
  6.1008  
  6.1009 @@ -913,29 +874,26 @@
  6.1010  
  6.1011  text \<open>Type variables are decorated with sorts, as explained in
  6.1012    \secref{sec:types}.  This constrains type instantiation to certain
  6.1013 -  ranges of types: variable @{text "\<alpha>\<^sub>s"} may only be assigned to types
  6.1014 -  @{text "\<tau>"} that belong to sort @{text "s"}.  Within the logic, sort
  6.1015 -  constraints act like implicit preconditions on the result @{text
  6.1016 -  "\<lparr>\<alpha>\<^sub>1 : s\<^sub>1\<rparr>, \<dots>, \<lparr>\<alpha>\<^sub>n : s\<^sub>n\<rparr>, \<Gamma> \<turnstile> \<phi>"} where the type variables @{text
  6.1017 -  "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} cover the propositions @{text "\<Gamma>"}, @{text "\<phi>"}, as
  6.1018 -  well as the proof of @{text "\<Gamma> \<turnstile> \<phi>"}.
  6.1019 +  ranges of types: variable \<open>\<alpha>\<^sub>s\<close> may only be assigned to types
  6.1020 +  \<open>\<tau>\<close> that belong to sort \<open>s\<close>.  Within the logic, sort
  6.1021 +  constraints act like implicit preconditions on the result \<open>\<lparr>\<alpha>\<^sub>1 : s\<^sub>1\<rparr>, \<dots>, \<lparr>\<alpha>\<^sub>n : s\<^sub>n\<rparr>, \<Gamma> \<turnstile> \<phi>\<close> where the type variables \<open>\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n\<close> cover the propositions \<open>\<Gamma>\<close>, \<open>\<phi>\<close>, as
  6.1022 +  well as the proof of \<open>\<Gamma> \<turnstile> \<phi>\<close>.
  6.1023  
  6.1024    These \<^emph>\<open>sort hypothesis\<close> of a theorem are passed monotonically
  6.1025    through further derivations.  They are redundant, as long as the
  6.1026    statement of a theorem still contains the type variables that are
  6.1027    accounted here.  The logical significance of sort hypotheses is
  6.1028    limited to the boundary case where type variables disappear from the
  6.1029 -  proposition, e.g.\ @{text "\<lparr>\<alpha>\<^sub>s : s\<rparr> \<turnstile> \<phi>"}.  Since such dangling type
  6.1030 +  proposition, e.g.\ \<open>\<lparr>\<alpha>\<^sub>s : s\<rparr> \<turnstile> \<phi>\<close>.  Since such dangling type
  6.1031    variables can be renamed arbitrarily without changing the
  6.1032 -  proposition @{text "\<phi>"}, the inference kernel maintains sort
  6.1033 -  hypotheses in anonymous form @{text "s \<turnstile> \<phi>"}.
  6.1034 +  proposition \<open>\<phi>\<close>, the inference kernel maintains sort
  6.1035 +  hypotheses in anonymous form \<open>s \<turnstile> \<phi>\<close>.
  6.1036  
  6.1037    In most practical situations, such extra sort hypotheses may be
  6.1038    stripped in a final bookkeeping step, e.g.\ at the end of a proof:
  6.1039    they are typically left over from intermediate reasoning with type
  6.1040 -  classes that can be satisfied by some concrete type @{text "\<tau>"} of
  6.1041 -  sort @{text "s"} to replace the hypothetical type variable @{text
  6.1042 -  "\<alpha>\<^sub>s"}.\<close>
  6.1043 +  classes that can be satisfied by some concrete type \<open>\<tau>\<close> of
  6.1044 +  sort \<open>s\<close> to replace the hypothetical type variable \<open>\<alpha>\<^sub>s\<close>.\<close>
  6.1045  
  6.1046  text %mlref \<open>
  6.1047    \begin{mldecls}
  6.1048 @@ -943,11 +901,11 @@
  6.1049    @{index_ML Thm.strip_shyps: "thm -> thm"} \\
  6.1050    \end{mldecls}
  6.1051  
  6.1052 -  \<^descr> @{ML Thm.extra_shyps}~@{text "thm"} determines the extraneous
  6.1053 +  \<^descr> @{ML Thm.extra_shyps}~\<open>thm\<close> determines the extraneous
  6.1054    sort hypotheses of the given theorem, i.e.\ the sorts that are not
  6.1055    present within type variables of the statement.
  6.1056  
  6.1057 -  \<^descr> @{ML Thm.strip_shyps}~@{text "thm"} removes any extraneous
  6.1058 +  \<^descr> @{ML Thm.strip_shyps}~\<open>thm\<close> removes any extraneous
  6.1059    sort hypotheses that can be witnessed from the type signature.
  6.1060  \<close>
  6.1061  
  6.1062 @@ -976,9 +934,8 @@
  6.1063    purposes.  User-level reasoning usually works via object-level rules
  6.1064    that are represented as theorems of Pure.  Composition of rules
  6.1065    involves \<^emph>\<open>backchaining\<close>, \<^emph>\<open>higher-order unification\<close> modulo
  6.1066 -  @{text "\<alpha>\<beta>\<eta>"}-conversion of @{text "\<lambda>"}-terms, and so-called
  6.1067 -  \<^emph>\<open>lifting\<close> of rules into a context of @{text "\<And>"} and @{text
  6.1068 -  "\<Longrightarrow>"} connectives.  Thus the full power of higher-order Natural
  6.1069 +  \<open>\<alpha>\<beta>\<eta>\<close>-conversion of \<open>\<lambda>\<close>-terms, and so-called
  6.1070 +  \<^emph>\<open>lifting\<close> of rules into a context of \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> connectives.  Thus the full power of higher-order Natural
  6.1071    Deduction in Isabelle/Pure becomes readily available.
  6.1072  \<close>
  6.1073  
  6.1074 @@ -991,24 +948,24 @@
  6.1075    arbitrary nesting similar to @{cite extensions91}.  The most basic
  6.1076    rule format is that of a \<^emph>\<open>Horn Clause\<close>:
  6.1077    \[
  6.1078 -  \infer{@{text "A"}}{@{text "A\<^sub>1"} & @{text "\<dots>"} & @{text "A\<^sub>n"}}
  6.1079 +  \infer{\<open>A\<close>}{\<open>A\<^sub>1\<close> & \<open>\<dots>\<close> & \<open>A\<^sub>n\<close>}
  6.1080    \]
  6.1081 -  where @{text "A, A\<^sub>1, \<dots>, A\<^sub>n"} are atomic propositions
  6.1082 -  of the framework, usually of the form @{text "Trueprop B"}, where
  6.1083 -  @{text "B"} is a (compound) object-level statement.  This
  6.1084 +  where \<open>A, A\<^sub>1, \<dots>, A\<^sub>n\<close> are atomic propositions
  6.1085 +  of the framework, usually of the form \<open>Trueprop B\<close>, where
  6.1086 +  \<open>B\<close> is a (compound) object-level statement.  This
  6.1087    object-level inference corresponds to an iterated implication in
  6.1088    Pure like this:
  6.1089    \[
  6.1090 -  @{text "A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> A"}
  6.1091 +  \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> A\<close>
  6.1092    \]
  6.1093 -  As an example consider conjunction introduction: @{text "A \<Longrightarrow> B \<Longrightarrow> A \<and>
  6.1094 -  B"}.  Any parameters occurring in such rule statements are
  6.1095 +  As an example consider conjunction introduction: \<open>A \<Longrightarrow> B \<Longrightarrow> A \<and>
  6.1096 +  B\<close>.  Any parameters occurring in such rule statements are
  6.1097    conceptionally treated as arbitrary:
  6.1098    \[
  6.1099 -  @{text "\<And>x\<^sub>1 \<dots> x\<^sub>m. A\<^sub>1 x\<^sub>1 \<dots> x\<^sub>m \<Longrightarrow> \<dots> A\<^sub>n x\<^sub>1 \<dots> x\<^sub>m \<Longrightarrow> A x\<^sub>1 \<dots> x\<^sub>m"}
  6.1100 +  \<open>\<And>x\<^sub>1 \<dots> x\<^sub>m. A\<^sub>1 x\<^sub>1 \<dots> x\<^sub>m \<Longrightarrow> \<dots> A\<^sub>n x\<^sub>1 \<dots> x\<^sub>m \<Longrightarrow> A x\<^sub>1 \<dots> x\<^sub>m\<close>
  6.1101    \]
  6.1102  
  6.1103 -  Nesting of rules means that the positions of @{text "A\<^sub>i"} may
  6.1104 +  Nesting of rules means that the positions of \<open>A\<^sub>i\<close> may
  6.1105    again hold compound rules, not just atomic propositions.
  6.1106    Propositions of this format are called \<^emph>\<open>Hereditary Harrop
  6.1107    Formulae\<close> in the literature @{cite "Miller:1991"}.  Here we give an
  6.1108 @@ -1016,19 +973,18 @@
  6.1109  
  6.1110    \<^medskip>
  6.1111    \begin{tabular}{ll}
  6.1112 -  @{text "\<^bold>x"} & set of variables \\
  6.1113 -  @{text "\<^bold>A"} & set of atomic propositions \\
  6.1114 -  @{text "\<^bold>H  =  \<And>\<^bold>x\<^sup>*. \<^bold>H\<^sup>* \<Longrightarrow> \<^bold>A"} & set of Hereditary Harrop Formulas \\
  6.1115 +  \<open>\<^bold>x\<close> & set of variables \\
  6.1116 +  \<open>\<^bold>A\<close> & set of atomic propositions \\
  6.1117 +  \<open>\<^bold>H  =  \<And>\<^bold>x\<^sup>*. \<^bold>H\<^sup>* \<Longrightarrow> \<^bold>A\<close> & set of Hereditary Harrop Formulas \\
  6.1118    \end{tabular}
  6.1119    \<^medskip>
  6.1120  
  6.1121    Thus we essentially impose nesting levels on propositions formed
  6.1122 -  from @{text "\<And>"} and @{text "\<Longrightarrow>"}.  At each level there is a prefix
  6.1123 +  from \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close>.  At each level there is a prefix
  6.1124    of parameters and compound premises, concluding an atomic
  6.1125 -  proposition.  Typical examples are @{text "\<longrightarrow>"}-introduction @{text
  6.1126 -  "(A \<Longrightarrow> B) \<Longrightarrow> A \<longrightarrow> B"} or mathematical induction @{text "P 0 \<Longrightarrow> (\<And>n. P n
  6.1127 -  \<Longrightarrow> P (Suc n)) \<Longrightarrow> P n"}.  Even deeper nesting occurs in well-founded
  6.1128 -  induction @{text "(\<And>x. (\<And>y. y \<prec> x \<Longrightarrow> P y) \<Longrightarrow> P x) \<Longrightarrow> P x"}, but this
  6.1129 +  proposition.  Typical examples are \<open>\<longrightarrow>\<close>-introduction \<open>(A \<Longrightarrow> B) \<Longrightarrow> A \<longrightarrow> B\<close> or mathematical induction \<open>P 0 \<Longrightarrow> (\<And>n. P n
  6.1130 +  \<Longrightarrow> P (Suc n)) \<Longrightarrow> P n\<close>.  Even deeper nesting occurs in well-founded
  6.1131 +  induction \<open>(\<And>x. (\<And>y. y \<prec> x \<Longrightarrow> P y) \<Longrightarrow> P x) \<Longrightarrow> P x\<close>, but this
  6.1132    already marks the limit of rule complexity that is usually seen in
  6.1133    practice.
  6.1134  
  6.1135 @@ -1036,14 +992,14 @@
  6.1136    Regular user-level inferences in Isabelle/Pure always
  6.1137    maintain the following canonical form of results:
  6.1138  
  6.1139 -  \<^item> Normalization by @{text "(A \<Longrightarrow> (\<And>x. B x)) \<equiv> (\<And>x. A \<Longrightarrow> B x)"},
  6.1140 +  \<^item> Normalization by \<open>(A \<Longrightarrow> (\<And>x. B x)) \<equiv> (\<And>x. A \<Longrightarrow> B x)\<close>,
  6.1141    which is a theorem of Pure, means that quantifiers are pushed in
  6.1142    front of implication at each level of nesting.  The normal form is a
  6.1143    Hereditary Harrop Formula.
  6.1144  
  6.1145    \<^item> The outermost prefix of parameters is represented via
  6.1146 -  schematic variables: instead of @{text "\<And>\<^vec>x. \<^vec>H \<^vec>x
  6.1147 -  \<Longrightarrow> A \<^vec>x"} we have @{text "\<^vec>H ?\<^vec>x \<Longrightarrow> A ?\<^vec>x"}.
  6.1148 +  schematic variables: instead of \<open>\<And>\<^vec>x. \<^vec>H \<^vec>x
  6.1149 +  \<Longrightarrow> A \<^vec>x\<close> we have \<open>\<^vec>H ?\<^vec>x \<Longrightarrow> A ?\<^vec>x\<close>.
  6.1150    Note that this representation looses information about the order of
  6.1151    parameters, and vacuous quantifiers vanish automatically.
  6.1152  \<close>
  6.1153 @@ -1053,7 +1009,7 @@
  6.1154    @{index_ML Simplifier.norm_hhf: "Proof.context -> thm -> thm"} \\
  6.1155    \end{mldecls}
  6.1156  
  6.1157 -  \<^descr> @{ML Simplifier.norm_hhf}~@{text "ctxt thm"} normalizes the given
  6.1158 +  \<^descr> @{ML Simplifier.norm_hhf}~\<open>ctxt thm\<close> normalizes the given
  6.1159    theorem according to the canonical form specified above.  This is
  6.1160    occasionally helpful to repair some low-level tools that do not
  6.1161    handle Hereditary Harrop Formulae properly.
  6.1162 @@ -1071,41 +1027,40 @@
  6.1163  
  6.1164    To understand the all-important @{inference resolution} principle,
  6.1165    we first consider raw @{inference_def composition} (modulo
  6.1166 -  higher-order unification with substitution @{text "\<vartheta>"}):
  6.1167 +  higher-order unification with substitution \<open>\<vartheta>\<close>):
  6.1168    \[
  6.1169 -  \infer[(@{inference_def composition})]{@{text "\<^vec>A\<vartheta> \<Longrightarrow> C\<vartheta>"}}
  6.1170 -  {@{text "\<^vec>A \<Longrightarrow> B"} & @{text "B' \<Longrightarrow> C"} & @{text "B\<vartheta> = B'\<vartheta>"}}
  6.1171 +  \infer[(@{inference_def composition})]{\<open>\<^vec>A\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
  6.1172 +  {\<open>\<^vec>A \<Longrightarrow> B\<close> & \<open>B' \<Longrightarrow> C\<close> & \<open>B\<vartheta> = B'\<vartheta>\<close>}
  6.1173    \]
  6.1174    Here the conclusion of the first rule is unified with the premise of
  6.1175    the second; the resulting rule instance inherits the premises of the
  6.1176 -  first and conclusion of the second.  Note that @{text "C"} can again
  6.1177 +  first and conclusion of the second.  Note that \<open>C\<close> can again
  6.1178    consist of iterated implications.  We can also permute the premises
  6.1179 -  of the second rule back-and-forth in order to compose with @{text
  6.1180 -  "B'"} in any position (subsequently we shall always refer to
  6.1181 +  of the second rule back-and-forth in order to compose with \<open>B'\<close> in any position (subsequently we shall always refer to
  6.1182    position 1 w.l.o.g.).
  6.1183  
  6.1184    In @{inference composition} the internal structure of the common
  6.1185 -  part @{text "B"} and @{text "B'"} is not taken into account.  For
  6.1186 -  proper @{inference resolution} we require @{text "B"} to be atomic,
  6.1187 -  and explicitly observe the structure @{text "\<And>\<^vec>x. \<^vec>H
  6.1188 -  \<^vec>x \<Longrightarrow> B' \<^vec>x"} of the premise of the second rule.  The
  6.1189 +  part \<open>B\<close> and \<open>B'\<close> is not taken into account.  For
  6.1190 +  proper @{inference resolution} we require \<open>B\<close> to be atomic,
  6.1191 +  and explicitly observe the structure \<open>\<And>\<^vec>x. \<^vec>H
  6.1192 +  \<^vec>x \<Longrightarrow> B' \<^vec>x\<close> of the premise of the second rule.  The
  6.1193    idea is to adapt the first rule by ``lifting'' it into this context,
  6.1194    by means of iterated application of the following inferences:
  6.1195    \[
  6.1196 -  \infer[(@{inference_def imp_lift})]{@{text "(\<^vec>H \<Longrightarrow> \<^vec>A) \<Longrightarrow> (\<^vec>H \<Longrightarrow> B)"}}{@{text "\<^vec>A \<Longrightarrow> B"}}
  6.1197 +  \infer[(@{inference_def imp_lift})]{\<open>(\<^vec>H \<Longrightarrow> \<^vec>A) \<Longrightarrow> (\<^vec>H \<Longrightarrow> B)\<close>}{\<open>\<^vec>A \<Longrightarrow> B\<close>}
  6.1198    \]
  6.1199    \[
  6.1200 -  \infer[(@{inference_def all_lift})]{@{text "(\<And>\<^vec>x. \<^vec>A (?\<^vec>a \<^vec>x)) \<Longrightarrow> (\<And>\<^vec>x. B (?\<^vec>a \<^vec>x))"}}{@{text "\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a"}}
  6.1201 +  \infer[(@{inference_def all_lift})]{\<open>(\<And>\<^vec>x. \<^vec>A (?\<^vec>a \<^vec>x)) \<Longrightarrow> (\<And>\<^vec>x. B (?\<^vec>a \<^vec>x))\<close>}{\<open>\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a\<close>}
  6.1202    \]
  6.1203    By combining raw composition with lifting, we get full @{inference
  6.1204    resolution} as follows:
  6.1205    \[
  6.1206    \infer[(@{inference_def resolution})]
  6.1207 -  {@{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>A (?\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>"}}
  6.1208 +  {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>A (?\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
  6.1209    {\begin{tabular}{l}
  6.1210 -    @{text "\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a"} \\
  6.1211 -    @{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C"} \\
  6.1212 -    @{text "(\<lambda>\<^vec>x. B (?\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>"} \\
  6.1213 +    \<open>\<^vec>A ?\<^vec>a \<Longrightarrow> B ?\<^vec>a\<close> \\
  6.1214 +    \<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C\<close> \\
  6.1215 +    \<open>(\<lambda>\<^vec>x. B (?\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>\<close> \\
  6.1216     \end{tabular}}
  6.1217    \]
  6.1218  
  6.1219 @@ -1114,8 +1069,8 @@
  6.1220    a rule of 0 premises, or by producing a ``short-circuit'' within a
  6.1221    solved situation (again modulo unification):
  6.1222    \[
  6.1223 -  \infer[(@{inference_def assumption})]{@{text "C\<vartheta>"}}
  6.1224 -  {@{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> A \<^vec>x) \<Longrightarrow> C"} & @{text "A\<vartheta> = H\<^sub>i\<vartheta>"}~~\text{(for some~@{text i})}}
  6.1225 +  \infer[(@{inference_def assumption})]{\<open>C\<vartheta>\<close>}
  6.1226 +  {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> A \<^vec>x) \<Longrightarrow> C\<close> & \<open>A\<vartheta> = H\<^sub>i\<vartheta>\<close>~~\text{(for some~\<open>i\<close>)}}
  6.1227    \]
  6.1228  
  6.1229    %FIXME @{inference_def elim_resolution}, @{inference_def dest_resolution}
  6.1230 @@ -1133,8 +1088,8 @@
  6.1231    @{index_ML_op "OF": "thm * thm list -> thm"} \\
  6.1232    \end{mldecls}
  6.1233  
  6.1234 -  \<^descr> @{text "rule\<^sub>1 RSN (i, rule\<^sub>2)"} resolves the conclusion of
  6.1235 -  @{text "rule\<^sub>1"} with the @{text i}-th premise of @{text "rule\<^sub>2"},
  6.1236 +  \<^descr> \<open>rule\<^sub>1 RSN (i, rule\<^sub>2)\<close> resolves the conclusion of
  6.1237 +  \<open>rule\<^sub>1\<close> with the \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>,
  6.1238    according to the @{inference resolution} principle explained above.
  6.1239    Unless there is precisely one resolvent it raises exception @{ML
  6.1240    THM}.
  6.1241 @@ -1142,28 +1097,27 @@
  6.1242    This corresponds to the rule attribute @{attribute THEN} in Isar
  6.1243    source language.
  6.1244  
  6.1245 -  \<^descr> @{text "rule\<^sub>1 RS rule\<^sub>2"} abbreviates @{text "rule\<^sub>1 RSN (1,
  6.1246 -  rule\<^sub>2)"}.
  6.1247 +  \<^descr> \<open>rule\<^sub>1 RS rule\<^sub>2\<close> abbreviates \<open>rule\<^sub>1 RSN (1,
  6.1248 +  rule\<^sub>2)\<close>.
  6.1249  
  6.1250 -  \<^descr> @{text "rules\<^sub>1 RLN (i, rules\<^sub>2)"} joins lists of rules.  For
  6.1251 -  every @{text "rule\<^sub>1"} in @{text "rules\<^sub>1"} and @{text "rule\<^sub>2"} in
  6.1252 -  @{text "rules\<^sub>2"}, it resolves the conclusion of @{text "rule\<^sub>1"} with
  6.1253 -  the @{text "i"}-th premise of @{text "rule\<^sub>2"}, accumulating multiple
  6.1254 +  \<^descr> \<open>rules\<^sub>1 RLN (i, rules\<^sub>2)\<close> joins lists of rules.  For
  6.1255 +  every \<open>rule\<^sub>1\<close> in \<open>rules\<^sub>1\<close> and \<open>rule\<^sub>2\<close> in
  6.1256 +  \<open>rules\<^sub>2\<close>, it resolves the conclusion of \<open>rule\<^sub>1\<close> with
  6.1257 +  the \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>, accumulating multiple
  6.1258    results in one big list.  Note that such strict enumerations of
  6.1259    higher-order unifications can be inefficient compared to the lazy
  6.1260    variant seen in elementary tactics like @{ML resolve_tac}.
  6.1261  
  6.1262 -  \<^descr> @{text "rules\<^sub>1 RL rules\<^sub>2"} abbreviates @{text "rules\<^sub>1 RLN (1,
  6.1263 -  rules\<^sub>2)"}.
  6.1264 +  \<^descr> \<open>rules\<^sub>1 RL rules\<^sub>2\<close> abbreviates \<open>rules\<^sub>1 RLN (1,
  6.1265 +  rules\<^sub>2)\<close>.
  6.1266  
  6.1267 -  \<^descr> @{text "[rule\<^sub>1, \<dots>, rule\<^sub>n] MRS rule"} resolves @{text "rule\<^sub>i"}
  6.1268 -  against premise @{text "i"} of @{text "rule"}, for @{text "i = n, \<dots>,
  6.1269 -  1"}.  By working from right to left, newly emerging premises are
  6.1270 +  \<^descr> \<open>[rule\<^sub>1, \<dots>, rule\<^sub>n] MRS rule\<close> resolves \<open>rule\<^sub>i\<close>
  6.1271 +  against premise \<open>i\<close> of \<open>rule\<close>, for \<open>i = n, \<dots>,
  6.1272 +  1\<close>.  By working from right to left, newly emerging premises are
  6.1273    concatenated in the result, without interfering.
  6.1274  
  6.1275 -  \<^descr> @{text "rule OF rules"} is an alternative notation for @{text
  6.1276 -  "rules MRS rule"}, which makes rule composition look more like
  6.1277 -  function application.  Note that the argument @{text "rules"} need
  6.1278 +  \<^descr> \<open>rule OF rules\<close> is an alternative notation for \<open>rules MRS rule\<close>, which makes rule composition look more like
  6.1279 +  function application.  Note that the argument \<open>rules\<close> need
  6.1280    not be atomic.
  6.1281  
  6.1282    This corresponds to the rule attribute @{attribute OF} in Isar
  6.1283 @@ -1181,55 +1135,50 @@
  6.1284    proof-checker, for example.
  6.1285  
  6.1286    According to the well-known \<^emph>\<open>Curry-Howard isomorphism\<close>, a proof
  6.1287 -  can be viewed as a @{text "\<lambda>"}-term. Following this idea, proofs in
  6.1288 +  can be viewed as a \<open>\<lambda>\<close>-term. Following this idea, proofs in
  6.1289    Isabelle are internally represented by a datatype similar to the one
  6.1290    for terms described in \secref{sec:terms}.  On top of these
  6.1291 -  syntactic terms, two more layers of @{text "\<lambda>"}-calculus are added,
  6.1292 -  which correspond to @{text "\<And>x :: \<alpha>. B x"} and @{text "A \<Longrightarrow> B"}
  6.1293 +  syntactic terms, two more layers of \<open>\<lambda>\<close>-calculus are added,
  6.1294 +  which correspond to \<open>\<And>x :: \<alpha>. B x\<close> and \<open>A \<Longrightarrow> B\<close>
  6.1295    according to the propositions-as-types principle.  The resulting
  6.1296 -  3-level @{text "\<lambda>"}-calculus resembles ``@{text "\<lambda>HOL"}'' in the
  6.1297 +  3-level \<open>\<lambda>\<close>-calculus resembles ``\<open>\<lambda>HOL\<close>'' in the
  6.1298    more abstract setting of Pure Type Systems (PTS)
  6.1299    @{cite "Barendregt-Geuvers:2001"}, if some fine points like schematic
  6.1300    polymorphism and type classes are ignored.
  6.1301  
  6.1302    \<^medskip>
  6.1303 -  \<^emph>\<open>Proof abstractions\<close> of the form @{text "\<^bold>\<lambda>x :: \<alpha>. prf"}
  6.1304 -  or @{text "\<^bold>\<lambda>p : A. prf"} correspond to introduction of @{text
  6.1305 -  "\<And>"}/@{text "\<Longrightarrow>"}, and \<^emph>\<open>proof applications\<close> of the form @{text
  6.1306 -  "p \<cdot> t"} or @{text "p \<bullet> q"} correspond to elimination of @{text
  6.1307 -  "\<And>"}/@{text "\<Longrightarrow>"}.  Actual types @{text "\<alpha>"}, propositions @{text
  6.1308 -  "A"}, and terms @{text "t"} might be suppressed and reconstructed
  6.1309 +  \<^emph>\<open>Proof abstractions\<close> of the form \<open>\<^bold>\<lambda>x :: \<alpha>. prf\<close>
  6.1310 +  or \<open>\<^bold>\<lambda>p : A. prf\<close> correspond to introduction of \<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>, and \<^emph>\<open>proof applications\<close> of the form \<open>p \<cdot> t\<close> or \<open>p \<bullet> q\<close> correspond to elimination of \<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>.  Actual types \<open>\<alpha>\<close>, propositions \<open>A\<close>, and terms \<open>t\<close> might be suppressed and reconstructed
  6.1311    from the overall proof term.
  6.1312  
  6.1313    \<^medskip>
  6.1314    Various atomic proofs indicate special situations within
  6.1315    the proof construction as follows.
  6.1316  
  6.1317 -  A \<^emph>\<open>bound proof variable\<close> is a natural number @{text "b"} that
  6.1318 +  A \<^emph>\<open>bound proof variable\<close> is a natural number \<open>b\<close> that
  6.1319    acts as de-Bruijn index for proof term abstractions.
  6.1320  
  6.1321 -  A \<^emph>\<open>minimal proof\<close> ``@{text "?"}'' is a dummy proof term.  This
  6.1322 +  A \<^emph>\<open>minimal proof\<close> ``\<open>?\<close>'' is a dummy proof term.  This
  6.1323    indicates some unrecorded part of the proof.
  6.1324  
  6.1325 -  @{text "Hyp A"} refers to some pending hypothesis by giving its
  6.1326 +  \<open>Hyp A\<close> refers to some pending hypothesis by giving its
  6.1327    proposition.  This indicates an open context of implicit hypotheses,
  6.1328    similar to loose bound variables or free variables within a term
  6.1329    (\secref{sec:terms}).
  6.1330  
  6.1331 -  An \<^emph>\<open>axiom\<close> or \<^emph>\<open>oracle\<close> @{text "a : A[\<^vec>\<tau>]"} refers
  6.1332 -  some postulated @{text "proof constant"}, which is subject to
  6.1333 +  An \<^emph>\<open>axiom\<close> or \<^emph>\<open>oracle\<close> \<open>a : A[\<^vec>\<tau>]\<close> refers
  6.1334 +  some postulated \<open>proof constant\<close>, which is subject to
  6.1335    schematic polymorphism of theory content, and the particular type
  6.1336 -  instantiation may be given explicitly.  The vector of types @{text
  6.1337 -  "\<^vec>\<tau>"} refers to the schematic type variables in the generic
  6.1338 -  proposition @{text "A"} in canonical order.
  6.1339 +  instantiation may be given explicitly.  The vector of types \<open>\<^vec>\<tau>\<close> refers to the schematic type variables in the generic
  6.1340 +  proposition \<open>A\<close> in canonical order.
  6.1341  
  6.1342 -  A \<^emph>\<open>proof promise\<close> @{text "a : A[\<^vec>\<tau>]"} is a placeholder
  6.1343 -  for some proof of polymorphic proposition @{text "A"}, with explicit
  6.1344 -  type instantiation as given by the vector @{text "\<^vec>\<tau>"}, as
  6.1345 +  A \<^emph>\<open>proof promise\<close> \<open>a : A[\<^vec>\<tau>]\<close> is a placeholder
  6.1346 +  for some proof of polymorphic proposition \<open>A\<close>, with explicit
  6.1347 +  type instantiation as given by the vector \<open>\<^vec>\<tau>\<close>, as
  6.1348    above.  Unlike axioms or oracles, proof promises may be
  6.1349 -  \<^emph>\<open>fulfilled\<close> eventually, by substituting @{text "a"} by some
  6.1350 -  particular proof @{text "q"} at the corresponding type instance.
  6.1351 -  This acts like Hindley-Milner @{text "let"}-polymorphism: a generic
  6.1352 +  \<^emph>\<open>fulfilled\<close> eventually, by substituting \<open>a\<close> by some
  6.1353 +  particular proof \<open>q\<close> at the corresponding type instance.
  6.1354 +  This acts like Hindley-Milner \<open>let\<close>-polymorphism: a generic
  6.1355    local proof definition may get used at different type instances, and
  6.1356    is replaced by the concrete instance eventually.
  6.1357  
  6.1358 @@ -1249,7 +1198,7 @@
  6.1359    Therefore, the Isabelle/Pure inference kernel records only
  6.1360    \<^emph>\<open>implicit\<close> proof terms, by omitting all typing information in
  6.1361    terms, all term and type labels of proof abstractions, and some
  6.1362 -  argument terms of applications @{text "p \<cdot> t"} (if possible).
  6.1363 +  argument terms of applications \<open>p \<cdot> t\<close> (if possible).
  6.1364  
  6.1365    There are separate operations to reconstruct the full proof term
  6.1366    later on, using \<^emph>\<open>higher-order pattern unification\<close>
  6.1367 @@ -1270,29 +1219,28 @@
  6.1368    \begin{center}
  6.1369    \begin{supertabular}{rclr}
  6.1370  
  6.1371 -  @{syntax_def (inner) proof} & = & @{verbatim Lam} @{text params} @{verbatim "."} @{text proof} \\
  6.1372 -    & @{text "|"} & @{text "\<^bold>\<lambda>"} @{text "params"} @{verbatim "."} @{text proof} \\
  6.1373 -    & @{text "|"} & @{text proof} @{verbatim "%"} @{text any} \\
  6.1374 -    & @{text "|"} & @{text proof} @{text "\<cdot>"} @{text any} \\
  6.1375 -    & @{text "|"} & @{text proof} @{verbatim "%%"} @{text proof} \\
  6.1376 -    & @{text "|"} & @{text proof} @{text "\<bullet>"} @{text proof} \\
  6.1377 -    & @{text "|"} & @{text "id  |  longid"} \\
  6.1378 +  @{syntax_def (inner) proof} & = & @{verbatim Lam} \<open>params\<close> @{verbatim "."} \<open>proof\<close> \\
  6.1379 +    & \<open>|\<close> & \<open>\<^bold>\<lambda>\<close> \<open>params\<close> @{verbatim "."} \<open>proof\<close> \\
  6.1380 +    & \<open>|\<close> & \<open>proof\<close> @{verbatim "%"} \<open>any\<close> \\
  6.1381 +    & \<open>|\<close> & \<open>proof\<close> \<open>\<cdot>\<close> \<open>any\<close> \\
  6.1382 +    & \<open>|\<close> & \<open>proof\<close> @{verbatim "%%"} \<open>proof\<close> \\
  6.1383 +    & \<open>|\<close> & \<open>proof\<close> \<open>\<bullet>\<close> \<open>proof\<close> \\
  6.1384 +    & \<open>|\<close> & \<open>id  |  longid\<close> \\
  6.1385    \\
  6.1386  
  6.1387 -  @{text param} & = & @{text idt} \\
  6.1388 -    & @{text "|"} & @{text idt} @{verbatim ":"} @{text prop} \\
  6.1389 -    & @{text "|"} & @{verbatim "("} @{text param} @{verbatim ")"} \\
  6.1390 +  \<open>param\<close> & = & \<open>idt\<close> \\
  6.1391 +    & \<open>|\<close> & \<open>idt\<close> @{verbatim ":"} \<open>prop\<close> \\
  6.1392 +    & \<open>|\<close> & @{verbatim "("} \<open>param\<close> @{verbatim ")"} \\
  6.1393    \\
  6.1394  
  6.1395 -  @{text params} & = & @{text param} \\
  6.1396 -    & @{text "|"} & @{text param} @{text params} \\
  6.1397 +  \<open>params\<close> & = & \<open>param\<close> \\
  6.1398 +    & \<open>|\<close> & \<open>param\<close> \<open>params\<close> \\
  6.1399  
  6.1400    \end{supertabular}
  6.1401    \end{center}
  6.1402  
  6.1403 -  Implicit term arguments in partial proofs are indicated by ``@{text
  6.1404 -  "_"}''.  Type arguments for theorems and axioms may be specified
  6.1405 -  using @{text "p \<cdot> TYPE(type)"} (they must appear before any other
  6.1406 +  Implicit term arguments in partial proofs are indicated by ``\<open>_\<close>''.  Type arguments for theorems and axioms may be specified
  6.1407 +  using \<open>p \<cdot> TYPE(type)\<close> (they must appear before any other
  6.1408    term argument of a theorem or axiom, but may be omitted altogether).
  6.1409  
  6.1410    \<^medskip>
  6.1411 @@ -1328,8 +1276,8 @@
  6.1412    information, the implicit graph of nested theorems needs to be
  6.1413    traversed (e.g.\ using @{ML Proofterm.fold_body_thms}).
  6.1414  
  6.1415 -  \<^descr> @{ML Thm.proof_of}~@{text "thm"} and @{ML
  6.1416 -  Thm.proof_body_of}~@{text "thm"} produce the proof term or proof
  6.1417 +  \<^descr> @{ML Thm.proof_of}~\<open>thm\<close> and @{ML
  6.1418 +  Thm.proof_body_of}~\<open>thm\<close> produce the proof term or proof
  6.1419    body (with digest of oracles and theorems) from a given theorem.
  6.1420    Note that this involves a full join of internal futures that fulfill
  6.1421    pending proof promises, and thus disrupts the natural bottom-up
  6.1422 @@ -1344,31 +1292,30 @@
  6.1423    Officially named theorems that contribute to a result are recorded
  6.1424    in any case.
  6.1425  
  6.1426 -  \<^descr> @{ML Reconstruct.reconstruct_proof}~@{text "thy prop prf"}
  6.1427 -  turns the implicit proof term @{text "prf"} into a full proof of the
  6.1428 +  \<^descr> @{ML Reconstruct.reconstruct_proof}~\<open>thy prop prf\<close>
  6.1429 +  turns the implicit proof term \<open>prf\<close> into a full proof of the
  6.1430    given proposition.
  6.1431  
  6.1432 -  Reconstruction may fail if @{text "prf"} is not a proof of @{text
  6.1433 -  "prop"}, or if it does not contain sufficient information for
  6.1434 +  Reconstruction may fail if \<open>prf\<close> is not a proof of \<open>prop\<close>, or if it does not contain sufficient information for
  6.1435    reconstruction.  Failure may only happen for proofs that are
  6.1436    constructed manually, but not for those produced automatically by
  6.1437    the inference kernel.
  6.1438  
  6.1439 -  \<^descr> @{ML Reconstruct.expand_proof}~@{text "thy [thm\<^sub>1, \<dots>, thm\<^sub>n]
  6.1440 -  prf"} expands and reconstructs the proofs of all specified theorems,
  6.1441 +  \<^descr> @{ML Reconstruct.expand_proof}~\<open>thy [thm\<^sub>1, \<dots>, thm\<^sub>n]
  6.1442 +  prf\<close> expands and reconstructs the proofs of all specified theorems,
  6.1443    with the given (full) proof.  Theorems that are not unique specified
  6.1444    via their name may be disambiguated by giving their proposition.
  6.1445  
  6.1446 -  \<^descr> @{ML Proof_Checker.thm_of_proof}~@{text "thy prf"} turns the
  6.1447 +  \<^descr> @{ML Proof_Checker.thm_of_proof}~\<open>thy prf\<close> turns the
  6.1448    given (full) proof into a theorem, by replaying it using only
  6.1449    primitive rules of the inference kernel.
  6.1450  
  6.1451 -  \<^descr> @{ML Proof_Syntax.read_proof}~@{text "thy b\<^sub>1 b\<^sub>2 s"} reads in a
  6.1452 +  \<^descr> @{ML Proof_Syntax.read_proof}~\<open>thy b\<^sub>1 b\<^sub>2 s\<close> reads in a
  6.1453    proof term. The Boolean flags indicate the use of sort and type
  6.1454    information.  Usually, typing information is left implicit and is
  6.1455    inferred during proof reconstruction.  %FIXME eliminate flags!?
  6.1456  
  6.1457 -  \<^descr> @{ML Proof_Syntax.pretty_proof}~@{text "ctxt prf"}
  6.1458 +  \<^descr> @{ML Proof_Syntax.pretty_proof}~\<open>ctxt prf\<close>
  6.1459    pretty-prints the given proof term.
  6.1460  \<close>
  6.1461  
     7.1 --- a/src/Doc/Implementation/ML.thy	Tue Oct 20 23:03:46 2015 +0200
     7.2 +++ b/src/Doc/Implementation/ML.thy	Tue Oct 20 23:53:40 2015 +0200
     7.3 @@ -315,7 +315,7 @@
     7.4    Some special infixes (e.g.\ @{ML_text "|>"}) work better at the
     7.5    start of the line, but punctuation is always at the end.
     7.6  
     7.7 -  Function application follows the tradition of @{text "\<lambda>"}-calculus,
     7.8 +  Function application follows the tradition of \<open>\<lambda>\<close>-calculus,
     7.9    not informal mathematics.  For example: @{ML_text "f a b"} for a
    7.10    curried function, or @{ML_text "g (a, b)"} for a tupled function.
    7.11    Note that the space between @{ML_text g} and the pair @{ML_text
    7.12 @@ -627,10 +627,10 @@
    7.13    correctly.  Recall that evaluation of a function body is delayed
    7.14    until actual run-time.
    7.15  
    7.16 -  \<^descr> @{ML "Context.>>"}~@{text f} applies context transformation
    7.17 -  @{text f} to the implicit context of the ML toplevel.
    7.18 -
    7.19 -  \<^descr> @{ML ML_Thms.bind_thms}~@{text "(name, thms)"} stores a list of
    7.20 +  \<^descr> @{ML "Context.>>"}~\<open>f\<close> applies context transformation
    7.21 +  \<open>f\<close> to the implicit context of the ML toplevel.
    7.22 +
    7.23 +  \<^descr> @{ML ML_Thms.bind_thms}~\<open>(name, thms)\<close> stores a list of
    7.24    theorems produced in ML both in the (global) theory context and the
    7.25    ML toplevel, associating it with the provided name.
    7.26  
    7.27 @@ -660,11 +660,11 @@
    7.28    defined in @{cite "isabelle-isar-ref"}.
    7.29  
    7.30    \<^medskip>
    7.31 -  A regular antiquotation @{text "@{name args}"} processes
    7.32 +  A regular antiquotation \<open>@{name args}\<close> processes
    7.33    its arguments by the usual means of the Isar source language, and
    7.34    produces corresponding ML source text, either as literal
    7.35 -  \<^emph>\<open>inline\<close> text (e.g.\ @{text "@{term t}"}) or abstract
    7.36 -  \<^emph>\<open>value\<close> (e.g. @{text "@{thm th}"}).  This pre-compilation
    7.37 +  \<^emph>\<open>inline\<close> text (e.g.\ \<open>@{term t}\<close>) or abstract
    7.38 +  \<^emph>\<open>value\<close> (e.g. \<open>@{thm th}\<close>).  This pre-compilation
    7.39    scheme allows to refer to formal entities in a robust manner, with
    7.40    proper static scoping and with some degree of logical checking of
    7.41    small portions of the code.
    7.42 @@ -687,8 +687,8 @@
    7.43  
    7.44  text %mlantiq \<open>
    7.45    \begin{matharray}{rcl}
    7.46 -  @{ML_antiquotation_def "make_string"} & : & @{text ML_antiquotation} \\
    7.47 -  @{ML_antiquotation_def "print"} & : & @{text ML_antiquotation} \\
    7.48 +  @{ML_antiquotation_def "make_string"} & : & \<open>ML_antiquotation\<close> \\
    7.49 +  @{ML_antiquotation_def "print"} & : & \<open>ML_antiquotation\<close> \\
    7.50    \end{matharray}
    7.51  
    7.52    @{rail \<open>
    7.53 @@ -697,13 +697,13 @@
    7.54    @@{ML_antiquotation print} @{syntax name}?
    7.55    \<close>}
    7.56  
    7.57 -  \<^descr> @{text "@{make_string}"} inlines a function to print arbitrary values
    7.58 +  \<^descr> \<open>@{make_string}\<close> inlines a function to print arbitrary values
    7.59    similar to the ML toplevel. The result is compiler dependent and may fall
    7.60    back on "?" in certain situations. The value of configuration option
    7.61    @{attribute_ref ML_print_depth} determines further details of output.
    7.62  
    7.63 -  \<^descr> @{text "@{print f}"} uses the ML function @{text "f: string ->
    7.64 -  unit"} to output the result of @{text "@{make_string}"} above,
    7.65 +  \<^descr> \<open>@{print f}\<close> uses the ML function \<open>f: string ->
    7.66 +  unit\<close> to output the result of \<open>@{make_string}\<close> above,
    7.67    together with the source position of the antiquotation.  The default
    7.68    output function is @{ML writeln}.
    7.69  \<close>
    7.70 @@ -724,25 +724,24 @@
    7.71  
    7.72  section \<open>Canonical argument order \label{sec:canonical-argument-order}\<close>
    7.73  
    7.74 -text \<open>Standard ML is a language in the tradition of @{text
    7.75 -  "\<lambda>"}-calculus and \<^emph>\<open>higher-order functional programming\<close>,
    7.76 +text \<open>Standard ML is a language in the tradition of \<open>\<lambda>\<close>-calculus and \<^emph>\<open>higher-order functional programming\<close>,
    7.77    similar to OCaml, Haskell, or Isabelle/Pure and HOL as logical
    7.78    languages.  Getting acquainted with the native style of representing
    7.79    functions in that setting can save a lot of extra boiler-plate of
    7.80    redundant shuffling of arguments, auxiliary abstractions etc.
    7.81  
    7.82    Functions are usually \<^emph>\<open>curried\<close>: the idea of turning arguments
    7.83 -  of type @{text "\<tau>\<^sub>i"} (for @{text "i \<in> {1, \<dots> n}"}) into a result of
    7.84 -  type @{text "\<tau>"} is represented by the iterated function space
    7.85 -  @{text "\<tau>\<^sub>1 \<rightarrow> \<dots> \<rightarrow> \<tau>\<^sub>n \<rightarrow> \<tau>"}.  This is isomorphic to the well-known
    7.86 -  encoding via tuples @{text "\<tau>\<^sub>1 \<times> \<dots> \<times> \<tau>\<^sub>n \<rightarrow> \<tau>"}, but the curried
    7.87 +  of type \<open>\<tau>\<^sub>i\<close> (for \<open>i \<in> {1, \<dots> n}\<close>) into a result of
    7.88 +  type \<open>\<tau>\<close> is represented by the iterated function space
    7.89 +  \<open>\<tau>\<^sub>1 \<rightarrow> \<dots> \<rightarrow> \<tau>\<^sub>n \<rightarrow> \<tau>\<close>.  This is isomorphic to the well-known
    7.90 +  encoding via tuples \<open>\<tau>\<^sub>1 \<times> \<dots> \<times> \<tau>\<^sub>n \<rightarrow> \<tau>\<close>, but the curried
    7.91    version fits more smoothly into the basic calculus.\footnote{The
    7.92    difference is even more significant in HOL, because the redundant
    7.93    tuple structure needs to be accommodated extraneous proof steps.}
    7.94  
    7.95    Currying gives some flexibility due to \<^emph>\<open>partial application\<close>.  A
    7.96 -  function @{text "f: \<tau>\<^sub>1 \<rightarrow> \<tau>\<^sub>2 \<rightarrow> \<tau>"} can be applied to @{text "x: \<tau>\<^sub>1"}
    7.97 -  and the remaining @{text "(f x): \<tau>\<^sub>2 \<rightarrow> \<tau>"} passed to another function
    7.98 +  function \<open>f: \<tau>\<^sub>1 \<rightarrow> \<tau>\<^sub>2 \<rightarrow> \<tau>\<close> can be applied to \<open>x: \<tau>\<^sub>1\<close>
    7.99 +  and the remaining \<open>(f x): \<tau>\<^sub>2 \<rightarrow> \<tau>\<close> passed to another function
   7.100    etc.  How well this works in practice depends on the order of
   7.101    arguments.  In the worst case, arguments are arranged erratically,
   7.102    and using a function in a certain situation always requires some
   7.103 @@ -752,8 +751,8 @@
   7.104    This can be avoided by \<^emph>\<open>canonical argument order\<close>, which
   7.105    observes certain standard patterns and minimizes adhoc permutations
   7.106    in their application.  In Isabelle/ML, large portions of text can be
   7.107 -  written without auxiliary operations like @{text "swap: \<alpha> \<times> \<beta> \<rightarrow> \<beta> \<times>
   7.108 -  \<alpha>"} or @{text "C: (\<alpha> \<rightarrow> \<beta> \<rightarrow> \<gamma>) \<rightarrow> (\<beta> \<rightarrow> \<alpha> \<rightarrow> \<gamma>)"} (the latter is not
   7.109 +  written without auxiliary operations like \<open>swap: \<alpha> \<times> \<beta> \<rightarrow> \<beta> \<times>
   7.110 +  \<alpha>\<close> or \<open>C: (\<alpha> \<rightarrow> \<beta> \<rightarrow> \<gamma>) \<rightarrow> (\<beta> \<rightarrow> \<alpha> \<rightarrow> \<gamma>)\<close> (the latter is not
   7.111    present in the Isabelle/ML library).
   7.112  
   7.113    \<^medskip>
   7.114 @@ -763,32 +762,31 @@
   7.115    \<^emph>\<open>updates\<close>.
   7.116  
   7.117    The subsequent scheme is based on a hypothetical set-like container
   7.118 -  of type @{text "\<beta>"} that manages elements of type @{text "\<alpha>"}.  Both
   7.119 +  of type \<open>\<beta>\<close> that manages elements of type \<open>\<alpha>\<close>.  Both
   7.120    the names and types of the associated operations are canonical for
   7.121    Isabelle/ML.
   7.122  
   7.123    \begin{center}
   7.124    \begin{tabular}{ll}
   7.125    kind & canonical name and type \\\hline
   7.126 -  selector & @{text "member: \<beta> \<rightarrow> \<alpha> \<rightarrow> bool"} \\
   7.127 -  update & @{text "insert: \<alpha> \<rightarrow> \<beta> \<rightarrow> \<beta>"} \\
   7.128 +  selector & \<open>member: \<beta> \<rightarrow> \<alpha> \<rightarrow> bool\<close> \\
   7.129 +  update & \<open>insert: \<alpha> \<rightarrow> \<beta> \<rightarrow> \<beta>\<close> \\
   7.130    \end{tabular}
   7.131    \end{center}
   7.132  
   7.133 -  Given a container @{text "B: \<beta>"}, the partially applied @{text
   7.134 -  "member B"} is a predicate over elements @{text "\<alpha> \<rightarrow> bool"}, and
   7.135 +  Given a container \<open>B: \<beta>\<close>, the partially applied \<open>member B\<close> is a predicate over elements \<open>\<alpha> \<rightarrow> bool\<close>, and
   7.136    thus represents the intended denotation directly.  It is customary
   7.137    to pass the abstract predicate to further operations, not the
   7.138    concrete container.  The argument order makes it easy to use other
   7.139 -  combinators: @{text "forall (member B) list"} will check a list of
   7.140 -  elements for membership in @{text "B"} etc. Often the explicit
   7.141 -  @{text "list"} is pointless and can be contracted to @{text "forall
   7.142 -  (member B)"} to get directly a predicate again.
   7.143 +  combinators: \<open>forall (member B) list\<close> will check a list of
   7.144 +  elements for membership in \<open>B\<close> etc. Often the explicit
   7.145 +  \<open>list\<close> is pointless and can be contracted to \<open>forall
   7.146 +  (member B)\<close> to get directly a predicate again.
   7.147  
   7.148    In contrast, an update operation varies the container, so it moves
   7.149 -  to the right: @{text "insert a"} is a function @{text "\<beta> \<rightarrow> \<beta>"} to
   7.150 -  insert a value @{text "a"}.  These can be composed naturally as
   7.151 -  @{text "insert c \<circ> insert b \<circ> insert a"}.  The slightly awkward
   7.152 +  to the right: \<open>insert a\<close> is a function \<open>\<beta> \<rightarrow> \<beta>\<close> to
   7.153 +  insert a value \<open>a\<close>.  These can be composed naturally as
   7.154 +  \<open>insert c \<circ> insert b \<circ> insert a\<close>.  The slightly awkward
   7.155    inversion of the composition order is due to conventional
   7.156    mathematical notation, which can be easily amended as explained
   7.157    below.
   7.158 @@ -798,9 +796,9 @@
   7.159  subsection \<open>Forward application and composition\<close>
   7.160  
   7.161  text \<open>Regular function application and infix notation works best for
   7.162 -  relatively deeply structured expressions, e.g.\ @{text "h (f x y + g
   7.163 -  z)"}.  The important special case of \<^emph>\<open>linear transformation\<close>
   7.164 -  applies a cascade of functions @{text "f\<^sub>n (\<dots> (f\<^sub>1 x))"}.  This
   7.165 +  relatively deeply structured expressions, e.g.\ \<open>h (f x y + g
   7.166 +  z)\<close>.  The important special case of \<^emph>\<open>linear transformation\<close>
   7.167 +  applies a cascade of functions \<open>f\<^sub>n (\<dots> (f\<^sub>1 x))\<close>.  This
   7.168    becomes hard to read and maintain if the functions are themselves
   7.169    given as complex expressions.  The notation can be significantly
   7.170    improved by introducing \<^emph>\<open>forward\<close> versions of application and
   7.171 @@ -808,14 +806,13 @@
   7.172  
   7.173    \<^medskip>
   7.174    \begin{tabular}{lll}
   7.175 -  @{text "x |> f"} & @{text "\<equiv>"} & @{text "f x"} \\
   7.176 -  @{text "(f #> g) x"} & @{text "\<equiv>"} & @{text "x |> f |> g"} \\
   7.177 +  \<open>x |> f\<close> & \<open>\<equiv>\<close> & \<open>f x\<close> \\
   7.178 +  \<open>(f #> g) x\<close> & \<open>\<equiv>\<close> & \<open>x |> f |> g\<close> \\
   7.179    \end{tabular}
   7.180    \<^medskip>
   7.181  
   7.182 -  This enables to write conveniently @{text "x |> f\<^sub>1 |> \<dots> |> f\<^sub>n"} or
   7.183 -  @{text "f\<^sub>1 #> \<dots> #> f\<^sub>n"} for its functional abstraction over @{text
   7.184 -  "x"}.
   7.185 +  This enables to write conveniently \<open>x |> f\<^sub>1 |> \<dots> |> f\<^sub>n\<close> or
   7.186 +  \<open>f\<^sub>1 #> \<dots> #> f\<^sub>n\<close> for its functional abstraction over \<open>x\<close>.
   7.187  
   7.188    \<^medskip>
   7.189    There is an additional set of combinators to accommodate
   7.190 @@ -824,8 +821,8 @@
   7.191  
   7.192    \<^medskip>
   7.193    \begin{tabular}{lll}
   7.194 -  @{text "(x, y) |-> f"} & @{text "\<equiv>"} & @{text "f x y"} \\
   7.195 -  @{text "(f #-> g) x"} & @{text "\<equiv>"} & @{text "x |> f |-> g"} \\
   7.196 +  \<open>(x, y) |-> f\<close> & \<open>\<equiv>\<close> & \<open>f x y\<close> \\
   7.197 +  \<open>(f #-> g) x\<close> & \<open>\<equiv>\<close> & \<open>x |> f |-> g\<close> \\
   7.198    \end{tabular}
   7.199    \<^medskip>
   7.200  \<close>
   7.201 @@ -842,29 +839,25 @@
   7.202  
   7.203  subsection \<open>Canonical iteration\<close>
   7.204  
   7.205 -text \<open>As explained above, a function @{text "f: \<alpha> \<rightarrow> \<beta> \<rightarrow> \<beta>"} can be
   7.206 -  understood as update on a configuration of type @{text "\<beta>"},
   7.207 -  parameterized by an argument of type @{text "\<alpha>"}.  Given @{text "a: \<alpha>"}
   7.208 -  the partial application @{text "(f a): \<beta> \<rightarrow> \<beta>"} operates
   7.209 -  homogeneously on @{text "\<beta>"}.  This can be iterated naturally over a
   7.210 -  list of parameters @{text "[a\<^sub>1, \<dots>, a\<^sub>n]"} as @{text "f a\<^sub>1 #> \<dots> #> f a\<^sub>n"}.
   7.211 -  The latter expression is again a function @{text "\<beta> \<rightarrow> \<beta>"}.
   7.212 -  It can be applied to an initial configuration @{text "b: \<beta>"} to
   7.213 -  start the iteration over the given list of arguments: each @{text
   7.214 -  "a"} in @{text "a\<^sub>1, \<dots>, a\<^sub>n"} is applied consecutively by updating a
   7.215 +text \<open>As explained above, a function \<open>f: \<alpha> \<rightarrow> \<beta> \<rightarrow> \<beta>\<close> can be
   7.216 +  understood as update on a configuration of type \<open>\<beta>\<close>,
   7.217 +  parameterized by an argument of type \<open>\<alpha>\<close>.  Given \<open>a: \<alpha>\<close>
   7.218 +  the partial application \<open>(f a): \<beta> \<rightarrow> \<beta>\<close> operates
   7.219 +  homogeneously on \<open>\<beta>\<close>.  This can be iterated naturally over a
   7.220 +  list of parameters \<open>[a\<^sub>1, \<dots>, a\<^sub>n]\<close> as \<open>f a\<^sub>1 #> \<dots> #> f a\<^sub>n\<close>.
   7.221 +  The latter expression is again a function \<open>\<beta> \<rightarrow> \<beta>\<close>.
   7.222 +  It can be applied to an initial configuration \<open>b: \<beta>\<close> to
   7.223 +  start the iteration over the given list of arguments: each \<open>a\<close> in \<open>a\<^sub>1, \<dots>, a\<^sub>n\<close> is applied consecutively by updating a
   7.224    cumulative configuration.
   7.225  
   7.226 -  The @{text fold} combinator in Isabelle/ML lifts a function @{text
   7.227 -  "f"} as above to its iterated version over a list of arguments.
   7.228 -  Lifting can be repeated, e.g.\ @{text "(fold \<circ> fold) f"} iterates
   7.229 +  The \<open>fold\<close> combinator in Isabelle/ML lifts a function \<open>f\<close> as above to its iterated version over a list of arguments.
   7.230 +  Lifting can be repeated, e.g.\ \<open>(fold \<circ> fold) f\<close> iterates
   7.231    over a list of lists as expected.
   7.232  
   7.233 -  The variant @{text "fold_rev"} works inside-out over the list of
   7.234 -  arguments, such that @{text "fold_rev f \<equiv> fold f \<circ> rev"} holds.
   7.235 -
   7.236 -  The @{text "fold_map"} combinator essentially performs @{text
   7.237 -  "fold"} and @{text "map"} simultaneously: each application of @{text
   7.238 -  "f"} produces an updated configuration together with a side-result;
   7.239 +  The variant \<open>fold_rev\<close> works inside-out over the list of
   7.240 +  arguments, such that \<open>fold_rev f \<equiv> fold f \<circ> rev\<close> holds.
   7.241 +
   7.242 +  The \<open>fold_map\<close> combinator essentially performs \<open>fold\<close> and \<open>map\<close> simultaneously: each application of \<open>f\<close> produces an updated configuration together with a side-result;
   7.243    the iteration collects all such side-results as a separate list.
   7.244  \<close>
   7.245  
   7.246 @@ -875,20 +868,19 @@
   7.247    @{index_ML fold_map: "('a -> 'b -> 'c * 'b) -> 'a list -> 'b -> 'c list * 'b"} \\
   7.248    \end{mldecls}
   7.249  
   7.250 -  \<^descr> @{ML fold}~@{text f} lifts the parametrized update function
   7.251 -  @{text "f"} to a list of parameters.
   7.252 -
   7.253 -  \<^descr> @{ML fold_rev}~@{text "f"} is similar to @{ML fold}~@{text
   7.254 -  "f"}, but works inside-out, as if the list would be reversed.
   7.255 -
   7.256 -  \<^descr> @{ML fold_map}~@{text "f"} lifts the parametrized update
   7.257 -  function @{text "f"} (with side-result) to a list of parameters and
   7.258 +  \<^descr> @{ML fold}~\<open>f\<close> lifts the parametrized update function
   7.259 +  \<open>f\<close> to a list of parameters.
   7.260 +
   7.261 +  \<^descr> @{ML fold_rev}~\<open>f\<close> is similar to @{ML fold}~\<open>f\<close>, but works inside-out, as if the list would be reversed.
   7.262 +
   7.263 +  \<^descr> @{ML fold_map}~\<open>f\<close> lifts the parametrized update
   7.264 +  function \<open>f\<close> (with side-result) to a list of parameters and
   7.265    cumulative side-results.
   7.266  
   7.267  
   7.268    \begin{warn}
   7.269    The literature on functional programming provides a confusing multitude of
   7.270 -  combinators called @{text "foldl"}, @{text "foldr"} etc. SML97 provides its
   7.271 +  combinators called \<open>foldl\<close>, \<open>foldr\<close> etc. SML97 provides its
   7.272    own variations as @{ML List.foldl} and @{ML List.foldr}, while the classic
   7.273    Isabelle library also has the historic @{ML Library.foldl} and @{ML
   7.274    Library.foldr}. To avoid unnecessary complication, all these historical
   7.275 @@ -998,11 +990,11 @@
   7.276    @{index_ML error: "string -> 'a"} % FIXME Output.error_message (!?) \\
   7.277    \end{mldecls}
   7.278  
   7.279 -  \<^descr> @{ML writeln}~@{text "text"} outputs @{text "text"} as regular
   7.280 +  \<^descr> @{ML writeln}~\<open>text\<close> outputs \<open>text\<close> as regular
   7.281    message.  This is the primary message output operation of Isabelle
   7.282    and should be used by default.
   7.283  
   7.284 -  \<^descr> @{ML tracing}~@{text "text"} outputs @{text "text"} as special
   7.285 +  \<^descr> @{ML tracing}~\<open>text\<close> outputs \<open>text\<close> as special
   7.286    tracing message, indicating potential high-volume output to the
   7.287    front-end (hundreds or thousands of messages issued by a single
   7.288    command).  The idea is to allow the user-interface to downgrade the
   7.289 @@ -1012,17 +1004,16 @@
   7.290    output, e.g.\ switch to a different output window.  So this channel
   7.291    should not be used for regular output.
   7.292  
   7.293 -  \<^descr> @{ML warning}~@{text "text"} outputs @{text "text"} as
   7.294 +  \<^descr> @{ML warning}~\<open>text\<close> outputs \<open>text\<close> as
   7.295    warning, which typically means some extra emphasis on the front-end
   7.296    side (color highlighting, icons, etc.).
   7.297  
   7.298 -  \<^descr> @{ML error}~@{text "text"} raises exception @{ML ERROR}~@{text
   7.299 -  "text"} and thus lets the Isar toplevel print @{text "text"} on the
   7.300 +  \<^descr> @{ML error}~\<open>text\<close> raises exception @{ML ERROR}~\<open>text\<close> and thus lets the Isar toplevel print \<open>text\<close> on the
   7.301    error channel, which typically means some extra emphasis on the
   7.302    front-end side (color highlighting, icons, etc.).
   7.303  
   7.304    This assumes that the exception is not handled before the command
   7.305 -  terminates.  Handling exception @{ML ERROR}~@{text "text"} is a
   7.306 +  terminates.  Handling exception @{ML ERROR}~\<open>text\<close> is a
   7.307    perfectly legal alternative: it means that the error is absorbed
   7.308    without any message output.
   7.309  
   7.310 @@ -1107,7 +1098,7 @@
   7.311  
   7.312    It is considered bad style to refer to internal function names or
   7.313    values in ML source notation in user error messages.  Do not use
   7.314 -  @{text "@{make_string}"} nor @{text "@{here}"}!
   7.315 +  \<open>@{make_string}\<close> nor \<open>@{here}\<close>!
   7.316  
   7.317    Grammatical correctness of error messages can be improved by
   7.318    \<^emph>\<open>omitting\<close> final punctuation: messages are often concatenated
   7.319 @@ -1177,31 +1168,30 @@
   7.320    @{index_ML Runtime.exn_trace: "(unit -> 'a) -> 'a"} \\
   7.321    \end{mldecls}
   7.322  
   7.323 -  \<^descr> @{ML try}~@{text "f x"} makes the partiality of evaluating
   7.324 -  @{text "f x"} explicit via the option datatype.  Interrupts are
   7.325 +  \<^descr> @{ML try}~\<open>f x\<close> makes the partiality of evaluating
   7.326 +  \<open>f x\<close> explicit via the option datatype.  Interrupts are
   7.327    \<^emph>\<open>not\<close> handled here, i.e.\ this form serves as safe replacement
   7.328 -  for the \<^emph>\<open>unsafe\<close> version @{ML_text "(SOME"}~@{text "f
   7.329 -  x"}~@{ML_text "handle _ => NONE)"} that is occasionally seen in
   7.330 +  for the \<^emph>\<open>unsafe\<close> version @{ML_text "(SOME"}~\<open>f
   7.331 +  x\<close>~@{ML_text "handle _ => NONE)"} that is occasionally seen in
   7.332    books about SML97, but not in Isabelle/ML.
   7.333  
   7.334    \<^descr> @{ML can} is similar to @{ML try} with more abstract result.
   7.335  
   7.336 -  \<^descr> @{ML ERROR}~@{text "msg"} represents user errors; this
   7.337 +  \<^descr> @{ML ERROR}~\<open>msg\<close> represents user errors; this
   7.338    exception is normally raised indirectly via the @{ML error} function
   7.339    (see \secref{sec:message-channels}).
   7.340  
   7.341 -  \<^descr> @{ML Fail}~@{text "msg"} represents general program failures.
   7.342 +  \<^descr> @{ML Fail}~\<open>msg\<close> represents general program failures.
   7.343  
   7.344    \<^descr> @{ML Exn.is_interrupt} identifies interrupts robustly, without
   7.345    mentioning concrete exception constructors in user code.  Handled
   7.346    interrupts need to be re-raised promptly!
   7.347  
   7.348 -  \<^descr> @{ML reraise}~@{text "exn"} raises exception @{text "exn"}
   7.349 +  \<^descr> @{ML reraise}~\<open>exn\<close> raises exception \<open>exn\<close>
   7.350    while preserving its implicit position information (if possible,
   7.351    depending on the ML platform).
   7.352  
   7.353 -  \<^descr> @{ML Runtime.exn_trace}~@{ML_text "(fn () =>"}~@{text
   7.354 -  "e"}@{ML_text ")"} evaluates expression @{text "e"} while printing
   7.355 +  \<^descr> @{ML Runtime.exn_trace}~@{ML_text "(fn () =>"}~\<open>e\<close>@{ML_text ")"} evaluates expression \<open>e\<close> while printing
   7.356    a full trace of its stack of nested exceptions (if possible,
   7.357    depending on the ML platform).
   7.358  
   7.359 @@ -1211,10 +1201,10 @@
   7.360  
   7.361  text %mlantiq \<open>
   7.362    \begin{matharray}{rcl}
   7.363 -  @{ML_antiquotation_def "assert"} & : & @{text ML_antiquotation} \\
   7.364 +  @{ML_antiquotation_def "assert"} & : & \<open>ML_antiquotation\<close> \\
   7.365    \end{matharray}
   7.366  
   7.367 -  \<^descr> @{text "@{assert}"} inlines a function
   7.368 +  \<^descr> \<open>@{assert}\<close> inlines a function
   7.369    @{ML_type "bool -> unit"} that raises @{ML Fail} if the argument is
   7.370    @{ML false}.  Due to inlining the source position of failed
   7.371    assertions is included in the error output.
   7.372 @@ -1230,30 +1220,26 @@
   7.373    in itself a small string, which has either one of the following
   7.374    forms:
   7.375  
   7.376 -  \<^enum> a single ASCII character ``@{text "c"}'', for example
   7.377 +  \<^enum> a single ASCII character ``\<open>c\<close>'', for example
   7.378    ``@{verbatim a}'',
   7.379  
   7.380    \<^enum> a codepoint according to UTF-8 (non-ASCII byte sequence),
   7.381  
   7.382 -  \<^enum> a regular symbol ``@{verbatim \<open>\\<close>}@{verbatim "<"}@{text
   7.383 -  "ident"}@{verbatim ">"}'', for example ``@{verbatim "\<alpha>"}'',
   7.384 -
   7.385 -  \<^enum> a control symbol ``@{verbatim \<open>\\<close>}@{verbatim "<^"}@{text
   7.386 -  "ident"}@{verbatim ">"}'', for example ``@{verbatim "\<^bold>"}'',
   7.387 -
   7.388 -  \<^enum> a raw symbol ``@{verbatim \<open>\\<close>}@{verbatim "<^raw:"}@{text
   7.389 -  text}@{verbatim ">"}'' where @{text text} consists of printable characters
   7.390 +  \<^enum> a regular symbol ``@{verbatim \<open>\\<close>}@{verbatim "<"}\<open>ident\<close>@{verbatim ">"}'', for example ``@{verbatim "\<alpha>"}'',
   7.391 +
   7.392 +  \<^enum> a control symbol ``@{verbatim \<open>\\<close>}@{verbatim "<^"}\<open>ident\<close>@{verbatim ">"}'', for example ``@{verbatim "\<^bold>"}'',
   7.393 +
   7.394 +  \<^enum> a raw symbol ``@{verbatim \<open>\\<close>}@{verbatim "<^raw:"}\<open>text\<close>@{verbatim ">"}'' where \<open>text\<close> consists of printable characters
   7.395    excluding ``@{verbatim "."}'' and ``@{verbatim ">"}'', for example
   7.396    ``@{verbatim "\<^raw:$\sum_{i = 1}^n$>"}'',
   7.397  
   7.398    \<^enum> a numbered raw control symbol ``@{verbatim \<open>\\<close>}@{verbatim
   7.399 -  "<^raw"}@{text n}@{verbatim ">"}, where @{text n} consists of digits, for
   7.400 +  "<^raw"}\<open>n\<close>@{verbatim ">"}, where \<open>n\<close> consists of digits, for
   7.401    example ``@{verbatim "\<^raw42>"}''.
   7.402  
   7.403  
   7.404 -  The @{text "ident"} syntax for symbol names is @{text "letter
   7.405 -  (letter | digit)\<^sup>*"}, where @{text "letter = A..Za..z"} and @{text
   7.406 -  "digit = 0..9"}.  There are infinitely many regular symbols and
   7.407 +  The \<open>ident\<close> syntax for symbol names is \<open>letter
   7.408 +  (letter | digit)\<^sup>*\<close>, where \<open>letter = A..Za..z\<close> and \<open>digit = 0..9\<close>.  There are infinitely many regular symbols and
   7.409    control symbols, but a fixed collection of standard symbols is
   7.410    treated specifically.  For example, ``@{verbatim "\<alpha>"}'' is
   7.411    classified as a letter, which means it may occur within regular
   7.412 @@ -1269,8 +1255,8 @@
   7.413    \<^medskip>
   7.414    Output of Isabelle symbols depends on the print mode. For example,
   7.415    the standard {\LaTeX} setup of the Isabelle document preparation system
   7.416 -  would present ``@{verbatim "\<alpha>"}'' as @{text "\<alpha>"}, and ``@{verbatim
   7.417 -  "\<^bold>\<alpha>"}'' as @{text "\<^bold>\<alpha>"}. On-screen rendering usually works by mapping a
   7.418 +  would present ``@{verbatim "\<alpha>"}'' as \<open>\<alpha>\<close>, and ``@{verbatim
   7.419 +  "\<^bold>\<alpha>"}'' as \<open>\<^bold>\<alpha>\<close>. On-screen rendering usually works by mapping a
   7.420    finite subset of Isabelle symbols to suitable Unicode characters.
   7.421  \<close>
   7.422  
   7.423 @@ -1291,7 +1277,7 @@
   7.424    \<^descr> Type @{ML_type "Symbol.symbol"} represents individual Isabelle
   7.425    symbols.
   7.426  
   7.427 -  \<^descr> @{ML "Symbol.explode"}~@{text "str"} produces a symbol list
   7.428 +  \<^descr> @{ML "Symbol.explode"}~\<open>str\<close> produces a symbol list
   7.429    from the packed form.  This function supersedes @{ML
   7.430    "String.explode"} for virtually all purposes of manipulating text in
   7.431    Isabelle!\footnote{The runtime overhead for exploded strings is
   7.432 @@ -1392,7 +1378,7 @@
   7.433    @{assert} (size s = 4);
   7.434  \<close>
   7.435  
   7.436 -text \<open>Note that in Unicode renderings of the symbol @{text "\<A>"},
   7.437 +text \<open>Note that in Unicode renderings of the symbol \<open>\<A>\<close>,
   7.438    variations of encodings like UTF-8 or UTF-16 pose delicate questions
   7.439    about the multi-byte representations of its codepoint, which is outside
   7.440    of the 16-bit address space of the original Unicode standard from
   7.441 @@ -1435,8 +1421,7 @@
   7.442    to the SML97 basis library definition.  This is adequate for
   7.443    internal ML operations, but awkward in concrete time specifications.
   7.444  
   7.445 -  \<^descr> @{ML seconds}~@{text "s"} turns the concrete scalar @{text
   7.446 -  "s"} (measured in seconds) into an abstract time value.  Floating
   7.447 +  \<^descr> @{ML seconds}~\<open>s\<close> turns the concrete scalar \<open>s\<close> (measured in seconds) into an abstract time value.  Floating
   7.448    point numbers are easy to use as configuration options in the
   7.449    context (see \secref{sec:config-options}) or system options that
   7.450    are maintained externally.
   7.451 @@ -1479,7 +1464,7 @@
   7.452    @{index_ML update: "('a * 'a -> bool) -> 'a -> 'a list -> 'a list"} \\
   7.453    \end{mldecls}
   7.454  
   7.455 -  \<^descr> @{ML cons}~@{text "x xs"} evaluates to @{text "x :: xs"}.
   7.456 +  \<^descr> @{ML cons}~\<open>x xs\<close> evaluates to \<open>x :: xs\<close>.
   7.457  
   7.458    Tupled infix operators are a historical accident in Standard ML.
   7.459    The curried @{ML cons} amends this, but it should be only used when
   7.460 @@ -1559,9 +1544,9 @@
   7.461    Note that a function called @{verbatim lookup} is obliged to express its
   7.462    partiality via an explicit option element.  There is no choice to
   7.463    raise an exception, without changing the name to something like
   7.464 -  @{text "the_element"} or @{text "get"}.
   7.465 -
   7.466 -  The @{text "defined"} operation is essentially a contraction of @{ML
   7.467 +  \<open>the_element\<close> or \<open>get\<close>.
   7.468 +
   7.469 +  The \<open>defined\<close> operation is essentially a contraction of @{ML
   7.470    is_some} and @{verbatim "lookup"}, but this is sufficiently frequent to
   7.471    justify its independent existence.  This also gives the
   7.472    implementation some opportunity for peep-hole optimization.
   7.473 @@ -1717,7 +1702,7 @@
   7.474    synchronization, as long as each invocation gets its own copy and the
   7.475    tool itself is single-threaded.
   7.476  
   7.477 -  \<^item> Avoid raw output on @{text "stdout"} or @{text "stderr"}.  The
   7.478 +  \<^item> Avoid raw output on \<open>stdout\<close> or \<open>stderr\<close>.  The
   7.479    Poly/ML library is thread-safe for each individual output operation,
   7.480    but the ordering of parallel invocations is arbitrary.  This means
   7.481    raw output will appear on some system console with unpredictable
   7.482 @@ -1748,11 +1733,11 @@
   7.483    @{index_ML serial_string: "unit -> string"} \\
   7.484    \end{mldecls}
   7.485  
   7.486 -  \<^descr> @{ML File.tmp_path}~@{text "path"} relocates the base
   7.487 -  component of @{text "path"} into the unique temporary directory of
   7.488 +  \<^descr> @{ML File.tmp_path}~\<open>path\<close> relocates the base
   7.489 +  component of \<open>path\<close> into the unique temporary directory of
   7.490    the running Isabelle/ML process.
   7.491  
   7.492 -  \<^descr> @{ML serial_string}~@{text "()"} creates a new serial number
   7.493 +  \<^descr> @{ML serial_string}~\<open>()\<close> creates a new serial number
   7.494    that is unique over the runtime of the Isabelle/ML process.
   7.495  \<close>
   7.496  
   7.497 @@ -1794,19 +1779,18 @@
   7.498    \<^descr> Type @{ML_type "'a Synchronized.var"} represents synchronized
   7.499    variables with state of type @{ML_type 'a}.
   7.500  
   7.501 -  \<^descr> @{ML Synchronized.var}~@{text "name x"} creates a synchronized
   7.502 -  variable that is initialized with value @{text "x"}.  The @{text
   7.503 -  "name"} is used for tracing.
   7.504 -
   7.505 -  \<^descr> @{ML Synchronized.guarded_access}~@{text "var f"} lets the
   7.506 -  function @{text "f"} operate within a critical section on the state
   7.507 -  @{text "x"} as follows: if @{text "f x"} produces @{ML NONE}, it
   7.508 +  \<^descr> @{ML Synchronized.var}~\<open>name x\<close> creates a synchronized
   7.509 +  variable that is initialized with value \<open>x\<close>.  The \<open>name\<close> is used for tracing.
   7.510 +
   7.511 +  \<^descr> @{ML Synchronized.guarded_access}~\<open>var f\<close> lets the
   7.512 +  function \<open>f\<close> operate within a critical section on the state
   7.513 +  \<open>x\<close> as follows: if \<open>f x\<close> produces @{ML NONE}, it
   7.514    continues to wait on the internal condition variable, expecting that
   7.515    some other thread will eventually change the content in a suitable
   7.516 -  manner; if @{text "f x"} produces @{ML SOME}~@{text "(y, x')"} it is
   7.517 -  satisfied and assigns the new state value @{text "x'"}, broadcasts a
   7.518 +  manner; if \<open>f x\<close> produces @{ML SOME}~\<open>(y, x')\<close> it is
   7.519 +  satisfied and assigns the new state value \<open>x'\<close>, broadcasts a
   7.520    signal to all waiting threads on the associated condition variable,
   7.521 -  and returns the result @{text "y"}.
   7.522 +  and returns the result \<open>y\<close>.
   7.523  
   7.524  
   7.525    There are some further variants of the @{ML
   7.526 @@ -1864,10 +1848,10 @@
   7.527    occur routinely, and special care is required to tell them apart ---
   7.528    the static type-system of SML is only of limited help here.
   7.529  
   7.530 -  The first form is more intuitive: some combinator @{text "(unit ->
   7.531 -  'a) -> 'a"} applies the given function to @{text "()"} to initiate
   7.532 +  The first form is more intuitive: some combinator \<open>(unit ->
   7.533 +  'a) -> 'a\<close> applies the given function to \<open>()\<close> to initiate
   7.534    the postponed evaluation process.  The second form is more flexible:
   7.535 -  some combinator @{text "('a -> 'b) -> 'a -> 'b"} acts like a
   7.536 +  some combinator \<open>('a -> 'b) -> 'a -> 'b\<close> acts like a
   7.537    modified form of function application; several such combinators may
   7.538    be cascaded to modify a given function, before it is ultimately
   7.539    applied to some argument.
   7.540 @@ -1875,7 +1859,7 @@
   7.541    \<^medskip>
   7.542    \<^emph>\<open>Reified results\<close> make the disjoint sum of regular
   7.543    values versions exceptional situations explicit as ML datatype:
   7.544 -  @{text "'a result = Res of 'a | Exn of exn"}.  This is typically
   7.545 +  \<open>'a result = Res of 'a | Exn of exn\<close>.  This is typically
   7.546    used for administrative purposes, to store the overall outcome of an
   7.547    evaluation process.
   7.548  
   7.549 @@ -1905,8 +1889,8 @@
   7.550    ML results explicitly, with constructor @{ML Exn.Res} for regular
   7.551    values and @{ML "Exn.Exn"} for exceptions.
   7.552  
   7.553 -  \<^descr> @{ML Exn.capture}~@{text "f x"} manages the evaluation of
   7.554 -  @{text "f x"} such that exceptions are made explicit as @{ML
   7.555 +  \<^descr> @{ML Exn.capture}~\<open>f x\<close> manages the evaluation of
   7.556 +  \<open>f x\<close> such that exceptions are made explicit as @{ML
   7.557    "Exn.Exn"}.  Note that this includes physical interrupts (see also
   7.558    \secref{sec:exceptions}), so the same precautions apply to user
   7.559    code: interrupts must not be absorbed accidentally!
   7.560 @@ -1915,11 +1899,11 @@
   7.561    Exn.capture}, but interrupts are immediately re-raised as required
   7.562    for user code.
   7.563  
   7.564 -  \<^descr> @{ML Exn.release}~@{text "result"} releases the original
   7.565 +  \<^descr> @{ML Exn.release}~\<open>result\<close> releases the original
   7.566    runtime result, exposing its regular value or raising the reified
   7.567    exception.
   7.568  
   7.569 -  \<^descr> @{ML Par_Exn.release_all}~@{text "results"} combines results
   7.570 +  \<^descr> @{ML Par_Exn.release_all}~\<open>results\<close> combines results
   7.571    that were produced independently (e.g.\ by parallel evaluation).  If
   7.572    all results are regular values, that list is returned.  Otherwise,
   7.573    the collection of all exceptions is raised, wrapped-up as collective
   7.574 @@ -1938,8 +1922,8 @@
   7.575  
   7.576  text \<open>
   7.577    Algorithmic skeletons are combinators that operate on lists in
   7.578 -  parallel, in the manner of well-known @{text map}, @{text exists},
   7.579 -  @{text forall} etc.  Management of futures (\secref{sec:futures})
   7.580 +  parallel, in the manner of well-known \<open>map\<close>, \<open>exists\<close>,
   7.581 +  \<open>forall\<close> etc.  Management of futures (\secref{sec:futures})
   7.582    and their results as reified exceptions is wrapped up into simple
   7.583    programming interfaces that resemble the sequential versions.
   7.584  
   7.585 @@ -1958,19 +1942,19 @@
   7.586    @{index_ML Par_List.get_some: "('a -> 'b option) -> 'a list -> 'b option"} \\
   7.587    \end{mldecls}
   7.588  
   7.589 -  \<^descr> @{ML Par_List.map}~@{text "f [x\<^sub>1, \<dots>, x\<^sub>n]"} is like @{ML
   7.590 -  "map"}~@{text "f [x\<^sub>1, \<dots>, x\<^sub>n]"}, but the evaluation of @{text "f x\<^sub>i"}
   7.591 -  for @{text "i = 1, \<dots>, n"} is performed in parallel.
   7.592 -
   7.593 -  An exception in any @{text "f x\<^sub>i"} cancels the overall evaluation
   7.594 +  \<^descr> @{ML Par_List.map}~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> is like @{ML
   7.595 +  "map"}~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close>, but the evaluation of \<open>f x\<^sub>i\<close>
   7.596 +  for \<open>i = 1, \<dots>, n\<close> is performed in parallel.
   7.597 +
   7.598 +  An exception in any \<open>f x\<^sub>i\<close> cancels the overall evaluation
   7.599    process.  The final result is produced via @{ML
   7.600    Par_Exn.release_first} as explained above, which means the first
   7.601    program exception that happened to occur in the parallel evaluation
   7.602    is propagated, and all other failures are ignored.
   7.603  
   7.604 -  \<^descr> @{ML Par_List.get_some}~@{text "f [x\<^sub>1, \<dots>, x\<^sub>n]"} produces some
   7.605 -  @{text "f x\<^sub>i"} that is of the form @{text "SOME y\<^sub>i"}, if that
   7.606 -  exists, otherwise @{text "NONE"}.  Thus it is similar to @{ML
   7.607 +  \<^descr> @{ML Par_List.get_some}~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> produces some
   7.608 +  \<open>f x\<^sub>i\<close> that is of the form \<open>SOME y\<^sub>i\<close>, if that
   7.609 +  exists, otherwise \<open>NONE\<close>.  Thus it is similar to @{ML
   7.610    Library.get_first}, but subject to a non-deterministic parallel
   7.611    choice process.  The first successful result cancels the overall
   7.612    evaluation process; other exceptions are propagated as for @{ML
   7.613 @@ -1997,16 +1981,15 @@
   7.614  subsection \<open>Lazy evaluation\<close>
   7.615  
   7.616  text \<open>
   7.617 -  Classic lazy evaluation works via the @{text lazy}~/ @{text force} pair of
   7.618 -  operations: @{text lazy} to wrap an unevaluated expression, and @{text
   7.619 -  force} to evaluate it once and store its result persistently. Later
   7.620 -  invocations of @{text force} retrieve the stored result without another
   7.621 +  Classic lazy evaluation works via the \<open>lazy\<close>~/ \<open>force\<close> pair of
   7.622 +  operations: \<open>lazy\<close> to wrap an unevaluated expression, and \<open>force\<close> to evaluate it once and store its result persistently. Later
   7.623 +  invocations of \<open>force\<close> retrieve the stored result without another
   7.624    evaluation. Isabelle/ML refines this idea to accommodate the aspects of
   7.625    multi-threading, synchronous program exceptions and asynchronous interrupts.
   7.626  
   7.627 -  The first thread that invokes @{text force} on an unfinished lazy value
   7.628 +  The first thread that invokes \<open>force\<close> on an unfinished lazy value
   7.629    changes its state into a \<^emph>\<open>promise\<close> of the eventual result and starts
   7.630 -  evaluating it. Any other threads that @{text force} the same lazy value in
   7.631 +  evaluating it. Any other threads that \<open>force\<close> the same lazy value in
   7.632    the meantime need to wait for it to finish, by producing a regular result or
   7.633    program exception. If the evaluation attempt is interrupted, this event is
   7.634    propagated to all waiting threads and the lazy value is reset to its
   7.635 @@ -2030,16 +2013,16 @@
   7.636    \<^descr> Type @{ML_type "'a lazy"} represents lazy values over type @{verbatim
   7.637    "'a"}.
   7.638  
   7.639 -  \<^descr> @{ML Lazy.lazy}~@{text "(fn () => e)"} wraps the unevaluated
   7.640 -  expression @{text e} as unfinished lazy value.
   7.641 -
   7.642 -  \<^descr> @{ML Lazy.value}~@{text a} wraps the value @{text a} as finished lazy
   7.643 -  value.  When forced, it returns @{text a} without any further evaluation.
   7.644 +  \<^descr> @{ML Lazy.lazy}~\<open>(fn () => e)\<close> wraps the unevaluated
   7.645 +  expression \<open>e\<close> as unfinished lazy value.
   7.646 +
   7.647 +  \<^descr> @{ML Lazy.value}~\<open>a\<close> wraps the value \<open>a\<close> as finished lazy
   7.648 +  value.  When forced, it returns \<open>a\<close> without any further evaluation.
   7.649  
   7.650    There is very low overhead for this proforma wrapping of strict values as
   7.651    lazy values.
   7.652  
   7.653 -  \<^descr> @{ML Lazy.force}~@{text x} produces the result of the lazy value in a
   7.654 +  \<^descr> @{ML Lazy.force}~\<open>x\<close> produces the result of the lazy value in a
   7.655    thread-safe manner as explained above. Thus it may cause the current thread
   7.656    to wait on a pending evaluation attempt by another thread.
   7.657  \<close>
   7.658 @@ -2049,7 +2032,7 @@
   7.659  
   7.660  text \<open>
   7.661    Futures help to organize parallel execution in a value-oriented manner, with
   7.662 -  @{text fork}~/ @{text join} as the main pair of operations, and some further
   7.663 +  \<open>fork\<close>~/ \<open>join\<close> as the main pair of operations, and some further
   7.664    variants; see also @{cite "Wenzel:2009" and "Wenzel:2013:ITP"}. Unlike lazy
   7.665    values, futures are evaluated strictly and spontaneously on separate worker
   7.666    threads. Futures may be canceled, which leads to interrupts on running
   7.667 @@ -2119,28 +2102,28 @@
   7.668    \<^descr> Type @{ML_type "'a future"} represents future values over type
   7.669    @{verbatim "'a"}.
   7.670  
   7.671 -  \<^descr> @{ML Future.fork}~@{text "(fn () => e)"} registers the unevaluated
   7.672 -  expression @{text e} as unfinished future value, to be evaluated eventually
   7.673 +  \<^descr> @{ML Future.fork}~\<open>(fn () => e)\<close> registers the unevaluated
   7.674 +  expression \<open>e\<close> as unfinished future value, to be evaluated eventually
   7.675    on the parallel worker-thread farm. This is a shorthand for @{ML
   7.676    Future.forks} below, with default parameters and a single expression.
   7.677  
   7.678 -  \<^descr> @{ML Future.forks}~@{text "params exprs"} is the general interface to
   7.679 -  fork several futures simultaneously. The @{text params} consist of the
   7.680 +  \<^descr> @{ML Future.forks}~\<open>params exprs\<close> is the general interface to
   7.681 +  fork several futures simultaneously. The \<open>params\<close> consist of the
   7.682    following fields:
   7.683  
   7.684 -    \<^item> @{text "name : string"} (default @{ML "\"\""}) specifies a common name
   7.685 +    \<^item> \<open>name : string\<close> (default @{ML "\"\""}) specifies a common name
   7.686      for the tasks of the forked futures, which serves diagnostic purposes.
   7.687  
   7.688 -    \<^item> @{text "group : Future.group option"} (default @{ML NONE}) specifies
   7.689 +    \<^item> \<open>group : Future.group option\<close> (default @{ML NONE}) specifies
   7.690      an optional task group for the forked futures. @{ML NONE} means that a new
   7.691      sub-group of the current worker-thread task context is created. If this is
   7.692      not a worker thread, the group will be a new root in the group hierarchy.
   7.693  
   7.694 -    \<^item> @{text "deps : Future.task list"} (default @{ML "[]"}) specifies
   7.695 +    \<^item> \<open>deps : Future.task list\<close> (default @{ML "[]"}) specifies
   7.696      dependencies on other future tasks, i.e.\ the adjacency relation in the
   7.697      global task queue. Dependencies on already finished tasks are ignored.
   7.698  
   7.699 -    \<^item> @{text "pri : int"} (default @{ML 0}) specifies a priority within the
   7.700 +    \<^item> \<open>pri : int\<close> (default @{ML 0}) specifies a priority within the
   7.701      task queue.
   7.702  
   7.703      Typically there is only little deviation from the default priority @{ML 0}.
   7.704 @@ -2153,7 +2136,7 @@
   7.705      priority tasks that are queued later need to wait until this (or another)
   7.706      worker thread becomes free again.
   7.707  
   7.708 -    \<^item> @{text "interrupts : bool"} (default @{ML true}) tells whether the
   7.709 +    \<^item> \<open>interrupts : bool\<close> (default @{ML true}) tells whether the
   7.710      worker thread that processes the corresponding task is initially put into
   7.711      interruptible state. This state may change again while running, by modifying
   7.712      the thread attributes.
   7.713 @@ -2162,7 +2145,7 @@
   7.714      the responsibility of the programmer that this special state is retained
   7.715      only briefly.
   7.716  
   7.717 -  \<^descr> @{ML Future.join}~@{text x} retrieves the value of an already finished
   7.718 +  \<^descr> @{ML Future.join}~\<open>x\<close> retrieves the value of an already finished
   7.719    future, which may lead to an exception, according to the result of its
   7.720    previous evaluation.
   7.721  
   7.722 @@ -2181,12 +2164,11 @@
   7.723    some timeout.
   7.724  
   7.725    Whenever possible, static dependencies of futures should be specified
   7.726 -  explicitly when forked (see @{text deps} above). Thus the evaluation can
   7.727 +  explicitly when forked (see \<open>deps\<close> above). Thus the evaluation can
   7.728    work from the bottom up, without join conflicts and wait states.
   7.729  
   7.730 -  \<^descr> @{ML Future.joins}~@{text xs} joins the given list of futures
   7.731 -  simultaneously, which is more efficient than @{ML "map Future.join"}~@{text
   7.732 -  xs}.
   7.733 +  \<^descr> @{ML Future.joins}~\<open>xs\<close> joins the given list of futures
   7.734 +  simultaneously, which is more efficient than @{ML "map Future.join"}~\<open>xs\<close>.
   7.735  
   7.736    Based on the dependency graph of tasks, the current thread takes over the
   7.737    responsibility to evaluate future expressions that are required for the main
   7.738 @@ -2194,23 +2176,23 @@
   7.739    presently evaluated on other threads only happens as last resort, when no
   7.740    other unfinished futures are left over.
   7.741  
   7.742 -  \<^descr> @{ML Future.value}~@{text a} wraps the value @{text a} as finished
   7.743 +  \<^descr> @{ML Future.value}~\<open>a\<close> wraps the value \<open>a\<close> as finished
   7.744    future value, bypassing the worker-thread farm. When joined, it returns
   7.745 -  @{text a} without any further evaluation.
   7.746 +  \<open>a\<close> without any further evaluation.
   7.747  
   7.748    There is very low overhead for this proforma wrapping of strict values as
   7.749    futures.
   7.750  
   7.751 -  \<^descr> @{ML Future.map}~@{text "f x"} is a fast-path implementation of @{ML
   7.752 -  Future.fork}~@{text "(fn () => f ("}@{ML Future.join}~@{text "x))"}, which
   7.753 +  \<^descr> @{ML Future.map}~\<open>f x\<close> is a fast-path implementation of @{ML
   7.754 +  Future.fork}~\<open>(fn () => f (\<close>@{ML Future.join}~\<open>x))\<close>, which
   7.755    avoids the full overhead of the task queue and worker-thread farm as far as
   7.756 -  possible. The function @{text f} is supposed to be some trivial
   7.757 +  possible. The function \<open>f\<close> is supposed to be some trivial
   7.758    post-processing or projection of the future result.
   7.759  
   7.760 -  \<^descr> @{ML Future.cancel}~@{text "x"} cancels the task group of the given
   7.761 +  \<^descr> @{ML Future.cancel}~\<open>x\<close> cancels the task group of the given
   7.762    future, using @{ML Future.cancel_group} below.
   7.763  
   7.764 -  \<^descr> @{ML Future.cancel_group}~@{text "group"} cancels all tasks of the
   7.765 +  \<^descr> @{ML Future.cancel_group}~\<open>group\<close> cancels all tasks of the
   7.766    given task group for all time. Threads that are presently processing a task
   7.767    of the given group are interrupted: it may take some time until they are
   7.768    actually terminated. Tasks that are queued but not yet processed are
   7.769 @@ -2218,12 +2200,11 @@
   7.770    invalidated, any further attempt to fork a future that belongs to it will
   7.771    yield a canceled result as well.
   7.772  
   7.773 -  \<^descr> @{ML Future.promise}~@{text abort} registers a passive future with the
   7.774 -  given @{text abort} operation: it is invoked when the future task group is
   7.775 +  \<^descr> @{ML Future.promise}~\<open>abort\<close> registers a passive future with the
   7.776 +  given \<open>abort\<close> operation: it is invoked when the future task group is
   7.777    canceled.
   7.778  
   7.779 -  \<^descr> @{ML Future.fulfill}~@{text "x a"} finishes the passive future @{text
   7.780 -  x} by the given value @{text a}. If the promise has already been canceled,
   7.781 +  \<^descr> @{ML Future.fulfill}~\<open>x a\<close> finishes the passive future \<open>x\<close> by the given value \<open>a\<close>. If the promise has already been canceled,
   7.782    the attempt to fulfill it causes an exception.
   7.783  \<close>
   7.784  
     8.1 --- a/src/Doc/Implementation/Prelim.thy	Tue Oct 20 23:03:46 2015 +0200
     8.2 +++ b/src/Doc/Implementation/Prelim.thy	Tue Oct 20 23:53:40 2015 +0200
     8.3 @@ -13,13 +13,13 @@
     8.4    results etc.).
     8.5  
     8.6    For example, derivations within the Isabelle/Pure logic can be
     8.7 -  described as a judgment @{text "\<Gamma> \<turnstile>\<^sub>\<Theta> \<phi>"}, which means that a
     8.8 -  proposition @{text "\<phi>"} is derivable from hypotheses @{text "\<Gamma>"}
     8.9 -  within the theory @{text "\<Theta>"}.  There are logical reasons for
    8.10 -  keeping @{text "\<Theta>"} and @{text "\<Gamma>"} separate: theories can be
    8.11 +  described as a judgment \<open>\<Gamma> \<turnstile>\<^sub>\<Theta> \<phi>\<close>, which means that a
    8.12 +  proposition \<open>\<phi>\<close> is derivable from hypotheses \<open>\<Gamma>\<close>
    8.13 +  within the theory \<open>\<Theta>\<close>.  There are logical reasons for
    8.14 +  keeping \<open>\<Theta>\<close> and \<open>\<Gamma>\<close> separate: theories can be
    8.15    liberal about supporting type constructors and schematic
    8.16    polymorphism of constants and axioms, while the inner calculus of
    8.17 -  @{text "\<Gamma> \<turnstile> \<phi>"} is strictly limited to Simple Type Theory (with
    8.18 +  \<open>\<Gamma> \<turnstile> \<phi>\<close> is strictly limited to Simple Type Theory (with
    8.19    fixed type variables in the assumptions).
    8.20  
    8.21    \<^medskip>
    8.22 @@ -27,20 +27,20 @@
    8.23    principles:
    8.24  
    8.25    \<^item> Transfer: monotonicity of derivations admits results to be
    8.26 -  transferred into a \<^emph>\<open>larger\<close> context, i.e.\ @{text "\<Gamma> \<turnstile>\<^sub>\<Theta>
    8.27 -  \<phi>"} implies @{text "\<Gamma>' \<turnstile>\<^sub>\<Theta>\<^sub>' \<phi>"} for contexts @{text "\<Theta>'
    8.28 -  \<supseteq> \<Theta>"} and @{text "\<Gamma>' \<supseteq> \<Gamma>"}.
    8.29 +  transferred into a \<^emph>\<open>larger\<close> context, i.e.\ \<open>\<Gamma> \<turnstile>\<^sub>\<Theta>
    8.30 +  \<phi>\<close> implies \<open>\<Gamma>' \<turnstile>\<^sub>\<Theta>\<^sub>' \<phi>\<close> for contexts \<open>\<Theta>'
    8.31 +  \<supseteq> \<Theta>\<close> and \<open>\<Gamma>' \<supseteq> \<Gamma>\<close>.
    8.32  
    8.33    \<^item> Export: discharge of hypotheses admits results to be exported
    8.34 -  into a \<^emph>\<open>smaller\<close> context, i.e.\ @{text "\<Gamma>' \<turnstile>\<^sub>\<Theta> \<phi>"}
    8.35 -  implies @{text "\<Gamma> \<turnstile>\<^sub>\<Theta> \<Delta> \<Longrightarrow> \<phi>"} where @{text "\<Gamma>' \<supseteq> \<Gamma>"} and
    8.36 -  @{text "\<Delta> = \<Gamma>' - \<Gamma>"}.  Note that @{text "\<Theta>"} remains unchanged here,
    8.37 -  only the @{text "\<Gamma>"} part is affected.
    8.38 +  into a \<^emph>\<open>smaller\<close> context, i.e.\ \<open>\<Gamma>' \<turnstile>\<^sub>\<Theta> \<phi>\<close>
    8.39 +  implies \<open>\<Gamma> \<turnstile>\<^sub>\<Theta> \<Delta> \<Longrightarrow> \<phi>\<close> where \<open>\<Gamma>' \<supseteq> \<Gamma>\<close> and
    8.40 +  \<open>\<Delta> = \<Gamma>' - \<Gamma>\<close>.  Note that \<open>\<Theta>\<close> remains unchanged here,
    8.41 +  only the \<open>\<Gamma>\<close> part is affected.
    8.42  
    8.43  
    8.44    \<^medskip>
    8.45    By modeling the main characteristics of the primitive
    8.46 -  @{text "\<Theta>"} and @{text "\<Gamma>"} above, and abstracting over any
    8.47 +  \<open>\<Theta>\<close> and \<open>\<Gamma>\<close> above, and abstracting over any
    8.48    particular logical content, we arrive at the fundamental notions of
    8.49    \<^emph>\<open>theory context\<close> and \<^emph>\<open>proof context\<close> in Isabelle/Isar.
    8.50    These implement a certain policy to manage arbitrary \<^emph>\<open>context
    8.51 @@ -48,15 +48,14 @@
    8.52    data at compile time.
    8.53  
    8.54    The internal bootstrap process of Isabelle/Pure eventually reaches a
    8.55 -  stage where certain data slots provide the logical content of @{text
    8.56 -  "\<Theta>"} and @{text "\<Gamma>"} sketched above, but this does not stop there!
    8.57 +  stage where certain data slots provide the logical content of \<open>\<Theta>\<close> and \<open>\<Gamma>\<close> sketched above, but this does not stop there!
    8.58    Various additional data slots support all kinds of mechanisms that
    8.59    are not necessarily part of the core logic.
    8.60  
    8.61    For example, there would be data for canonical introduction and
    8.62    elimination rules for arbitrary operators (depending on the
    8.63    object-logic and application), which enables users to perform
    8.64 -  standard proof steps implicitly (cf.\ the @{text "rule"} method
    8.65 +  standard proof steps implicitly (cf.\ the \<open>rule\<close> method
    8.66    @{cite "isabelle-isar-ref"}).
    8.67  
    8.68    \<^medskip>
    8.69 @@ -80,28 +79,27 @@
    8.70    ancestor theories.  To this end, the system maintains a set of
    8.71    symbolic ``identification stamps'' within each theory.
    8.72  
    8.73 -  The @{text "begin"} operation starts a new theory by importing several
    8.74 +  The \<open>begin\<close> operation starts a new theory by importing several
    8.75    parent theories (with merged contents) and entering a special mode of
    8.76 -  nameless incremental updates, until the final @{text "end"} operation is
    8.77 +  nameless incremental updates, until the final \<open>end\<close> operation is
    8.78    performed.
    8.79  
    8.80    \<^medskip>
    8.81    The example in \figref{fig:ex-theory} below shows a theory
    8.82 -  graph derived from @{text "Pure"}, with theory @{text "Length"}
    8.83 -  importing @{text "Nat"} and @{text "List"}.  The body of @{text
    8.84 -  "Length"} consists of a sequence of updates, resulting in locally a
    8.85 +  graph derived from \<open>Pure\<close>, with theory \<open>Length\<close>
    8.86 +  importing \<open>Nat\<close> and \<open>List\<close>.  The body of \<open>Length\<close> consists of a sequence of updates, resulting in locally a
    8.87    linear sub-theory relation for each intermediate step.
    8.88  
    8.89    \begin{figure}[htb]
    8.90    \begin{center}
    8.91    \begin{tabular}{rcccl}
    8.92 -        &            & @{text "Pure"} \\
    8.93 -        &            & @{text "\<down>"} \\
    8.94 -        &            & @{text "FOL"} \\
    8.95 +        &            & \<open>Pure\<close> \\
    8.96 +        &            & \<open>\<down>\<close> \\
    8.97 +        &            & \<open>FOL\<close> \\
    8.98          & $\swarrow$ &              & $\searrow$ & \\
    8.99 -  @{text "Nat"} &    &              &            & @{text "List"} \\
   8.100 +  \<open>Nat\<close> &    &              &            & \<open>List\<close> \\
   8.101          & $\searrow$ &              & $\swarrow$ \\
   8.102 -        &            & @{text "Length"} \\
   8.103 +        &            & \<open>Length\<close> \\
   8.104          &            & \multicolumn{3}{l}{~~@{keyword "begin"}} \\
   8.105          &            & $\vdots$~~ \\
   8.106          &            & \multicolumn{3}{l}{~~@{command "end"}} \\
   8.107 @@ -128,30 +126,30 @@
   8.108  
   8.109    \<^descr> Type @{ML_type theory} represents theory contexts.
   8.110  
   8.111 -  \<^descr> @{ML "Context.eq_thy"}~@{text "(thy\<^sub>1, thy\<^sub>2)"} check strict
   8.112 +  \<^descr> @{ML "Context.eq_thy"}~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> check strict
   8.113    identity of two theories.
   8.114  
   8.115 -  \<^descr> @{ML "Context.subthy"}~@{text "(thy\<^sub>1, thy\<^sub>2)"} compares theories
   8.116 +  \<^descr> @{ML "Context.subthy"}~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> compares theories
   8.117    according to the intrinsic graph structure of the construction.
   8.118    This sub-theory relation is a nominal approximation of inclusion
   8.119 -  (@{text "\<subseteq>"}) of the corresponding content (according to the
   8.120 +  (\<open>\<subseteq>\<close>) of the corresponding content (according to the
   8.121    semantics of the ML modules that implement the data).
   8.122  
   8.123 -  \<^descr> @{ML "Theory.begin_theory"}~@{text "name parents"} constructs
   8.124 +  \<^descr> @{ML "Theory.begin_theory"}~\<open>name parents\<close> constructs
   8.125    a new theory based on the given parents.  This ML function is
   8.126    normally not invoked directly.
   8.127  
   8.128 -  \<^descr> @{ML "Theory.parents_of"}~@{text "thy"} returns the direct
   8.129 -  ancestors of @{text thy}.
   8.130 +  \<^descr> @{ML "Theory.parents_of"}~\<open>thy\<close> returns the direct
   8.131 +  ancestors of \<open>thy\<close>.
   8.132  
   8.133 -  \<^descr> @{ML "Theory.ancestors_of"}~@{text "thy"} returns all
   8.134 -  ancestors of @{text thy} (not including @{text thy} itself).
   8.135 +  \<^descr> @{ML "Theory.ancestors_of"}~\<open>thy\<close> returns all
   8.136 +  ancestors of \<open>thy\<close> (not including \<open>thy\<close> itself).
   8.137  \<close>
   8.138  
   8.139  text %mlantiq \<open>
   8.140    \begin{matharray}{rcl}
   8.141 -  @{ML_antiquotation_def "theory"} & : & @{text ML_antiquotation} \\
   8.142 -  @{ML_antiquotation_def "theory_context"} & : & @{text ML_antiquotation} \\
   8.143 +  @{ML_antiquotation_def "theory"} & : & \<open>ML_antiquotation\<close> \\
   8.144 +  @{ML_antiquotation_def "theory_context"} & : & \<open>ML_antiquotation\<close> \\
   8.145    \end{matharray}
   8.146  
   8.147    @{rail \<open>
   8.148 @@ -160,15 +158,15 @@
   8.149    @@{ML_antiquotation theory_context} nameref
   8.150    \<close>}
   8.151  
   8.152 -  \<^descr> @{text "@{theory}"} refers to the background theory of the
   8.153 +  \<^descr> \<open>@{theory}\<close> refers to the background theory of the
   8.154    current context --- as abstract value.
   8.155  
   8.156 -  \<^descr> @{text "@{theory A}"} refers to an explicitly named ancestor
   8.157 -  theory @{text "A"} of the background theory of the current context
   8.158 +  \<^descr> \<open>@{theory A}\<close> refers to an explicitly named ancestor
   8.159 +  theory \<open>A\<close> of the background theory of the current context
   8.160    --- as abstract value.
   8.161  
   8.162 -  \<^descr> @{text "@{theory_context A}"} is similar to @{text "@{theory
   8.163 -  A}"}, but presents the result as initial @{ML_type Proof.context}
   8.164 +  \<^descr> \<open>@{theory_context A}\<close> is similar to \<open>@{theory
   8.165 +  A}\<close>, but presents the result as initial @{ML_type Proof.context}
   8.166    (see also @{ML Proof_Context.init_global}).
   8.167  \<close>
   8.168  
   8.169 @@ -176,16 +174,16 @@
   8.170  subsection \<open>Proof context \label{sec:context-proof}\<close>
   8.171  
   8.172  text \<open>A proof context is a container for pure data that refers to
   8.173 -  the theory from which it is derived. The @{text "init"} operation
   8.174 +  the theory from which it is derived. The \<open>init\<close> operation
   8.175    creates a proof context from a given theory. There is an explicit
   8.176 -  @{text "transfer"} operation to force resynchronization with updates
   8.177 +  \<open>transfer\<close> operation to force resynchronization with updates
   8.178    to the background theory -- this is rarely required in practice.
   8.179  
   8.180    Entities derived in a proof context need to record logical
   8.181    requirements explicitly, since there is no separate context
   8.182    identification or symbolic inclusion as for theories.  For example,
   8.183    hypotheses used in primitive derivations (cf.\ \secref{sec:thms})
   8.184 -  are recorded separately within the sequent @{text "\<Gamma> \<turnstile> \<phi>"}, just to
   8.185 +  are recorded separately within the sequent \<open>\<Gamma> \<turnstile> \<phi>\<close>, just to
   8.186    make double sure.  Results could still leak into an alien proof
   8.187    context due to programming errors, but Isabelle/Isar includes some
   8.188    extra validity checks in critical positions, notably at the end of a
   8.189 @@ -211,23 +209,22 @@
   8.190  
   8.191    \<^descr> Type @{ML_type Proof.context} represents proof contexts.
   8.192  
   8.193 -  \<^descr> @{ML Proof_Context.init_global}~@{text "thy"} produces a proof
   8.194 -  context derived from @{text "thy"}, initializing all data.
   8.195 +  \<^descr> @{ML Proof_Context.init_global}~\<open>thy\<close> produces a proof
   8.196 +  context derived from \<open>thy\<close>, initializing all data.
   8.197  
   8.198 -  \<^descr> @{ML Proof_Context.theory_of}~@{text "ctxt"} selects the
   8.199 -  background theory from @{text "ctxt"}.
   8.200 +  \<^descr> @{ML Proof_Context.theory_of}~\<open>ctxt\<close> selects the
   8.201 +  background theory from \<open>ctxt\<close>.
   8.202  
   8.203 -  \<^descr> @{ML Proof_Context.transfer}~@{text "thy ctxt"} promotes the
   8.204 -  background theory of @{text "ctxt"} to the super theory @{text
   8.205 -  "thy"}.
   8.206 +  \<^descr> @{ML Proof_Context.transfer}~\<open>thy ctxt\<close> promotes the
   8.207 +  background theory of \<open>ctxt\<close> to the super theory \<open>thy\<close>.
   8.208  \<close>
   8.209  
   8.210  text %mlantiq \<open>
   8.211    \begin{matharray}{rcl}
   8.212 -  @{ML_antiquotation_def "context"} & : & @{text ML_antiquotation} \\
   8.213 +  @{ML_antiquotation_def "context"} & : & \<open>ML_antiquotation\<close> \\
   8.214    \end{matharray}
   8.215  
   8.216 -  \<^descr> @{text "@{context}"} refers to \<^emph>\<open>the\<close> context at
   8.217 +  \<^descr> \<open>@{context}\<close> refers to \<^emph>\<open>the\<close> context at
   8.218    compile-time --- as abstract value.  Independently of (local) theory
   8.219    or proof mode, this always produces a meaningful result.
   8.220  
   8.221 @@ -246,10 +243,9 @@
   8.222    and combinators for lifting operations on either component of the
   8.223    disjoint sum.
   8.224  
   8.225 -  Moreover, there are total operations @{text "theory_of"} and @{text
   8.226 -  "proof_of"} to convert a generic context into either kind: a theory
   8.227 +  Moreover, there are total operations \<open>theory_of\<close> and \<open>proof_of\<close> to convert a generic context into either kind: a theory
   8.228    can always be selected from the sum, while a proof context might
   8.229 -  have to be constructed by an ad-hoc @{text "init"} operation, which
   8.230 +  have to be constructed by an ad-hoc \<open>init\<close> operation, which
   8.231    incurs a small runtime overhead.
   8.232  \<close>
   8.233  
   8.234 @@ -264,12 +260,12 @@
   8.235    "theory"} and @{ML_type "Proof.context"}, with the datatype
   8.236    constructors @{ML "Context.Theory"} and @{ML "Context.Proof"}.
   8.237  
   8.238 -  \<^descr> @{ML Context.theory_of}~@{text "context"} always produces a
   8.239 -  theory from the generic @{text "context"}, using @{ML
   8.240 +  \<^descr> @{ML Context.theory_of}~\<open>context\<close> always produces a
   8.241 +  theory from the generic \<open>context\<close>, using @{ML
   8.242    "Proof_Context.theory_of"} as required.
   8.243  
   8.244 -  \<^descr> @{ML Context.proof_of}~@{text "context"} always produces a
   8.245 -  proof context from the generic @{text "context"}, using @{ML
   8.246 +  \<^descr> @{ML Context.proof_of}~\<open>context\<close> always produces a
   8.247 +  proof context from the generic \<open>context\<close>, using @{ML
   8.248    "Proof_Context.init_global"} as required (note that this re-initializes the
   8.249    context data with each invocation).
   8.250  \<close>
   8.251 @@ -287,20 +283,19 @@
   8.252  
   8.253    \<^medskip>
   8.254    \begin{tabular}{ll}
   8.255 -  @{text "\<type> T"} & representing type \\
   8.256 -  @{text "\<val> empty: T"} & empty default value \\
   8.257 -  @{text "\<val> extend: T \<rightarrow> T"} & re-initialize on import \\
   8.258 -  @{text "\<val> merge: T \<times> T \<rightarrow> T"} & join on import \\
   8.259 +  \<open>\<type> T\<close> & representing type \\
   8.260 +  \<open>\<val> empty: T\<close> & empty default value \\
   8.261 +  \<open>\<val> extend: T \<rightarrow> T\<close> & re-initialize on import \\
   8.262 +  \<open>\<val> merge: T \<times> T \<rightarrow> T\<close> & join on import \\
   8.263    \end{tabular}
   8.264    \<^medskip>
   8.265  
   8.266 -  The @{text "empty"} value acts as initial default for \<^emph>\<open>any\<close>
   8.267 -  theory that does not declare actual data content; @{text "extend"}
   8.268 -  is acts like a unitary version of @{text "merge"}.
   8.269 +  The \<open>empty\<close> value acts as initial default for \<^emph>\<open>any\<close>
   8.270 +  theory that does not declare actual data content; \<open>extend\<close>
   8.271 +  is acts like a unitary version of \<open>merge\<close>.
   8.272  
   8.273 -  Implementing @{text "merge"} can be tricky.  The general idea is
   8.274 -  that @{text "merge (data\<^sub>1, data\<^sub>2)"} inserts those parts of @{text
   8.275 -  "data\<^sub>2"} into @{text "data\<^sub>1"} that are not yet present, while
   8.276 +  Implementing \<open>merge\<close> can be tricky.  The general idea is
   8.277 +  that \<open>merge (data\<^sub>1, data\<^sub>2)\<close> inserts those parts of \<open>data\<^sub>2\<close> into \<open>data\<^sub>1\<close> that are not yet present, while
   8.278    keeping the general order of things.  The @{ML Library.merge}
   8.279    function on plain lists may serve as canonical template.
   8.280  
   8.281 @@ -313,15 +308,15 @@
   8.282  
   8.283    \<^medskip>
   8.284    \begin{tabular}{ll}
   8.285 -  @{text "\<type> T"} & representing type \\
   8.286 -  @{text "\<val> init: theory \<rightarrow> T"} & produce initial value \\
   8.287 +  \<open>\<type> T\<close> & representing type \\
   8.288 +  \<open>\<val> init: theory \<rightarrow> T\<close> & produce initial value \\
   8.289    \end{tabular}
   8.290    \<^medskip>
   8.291  
   8.292 -  The @{text "init"} operation is supposed to produce a pure value
   8.293 +  The \<open>init\<close> operation is supposed to produce a pure value
   8.294    from the given background theory and should be somehow
   8.295    ``immediate''.  Whenever a proof context is initialized, which
   8.296 -  happens frequently, the the system invokes the @{text "init"}
   8.297 +  happens frequently, the the system invokes the \<open>init\<close>
   8.298    operation of \<^emph>\<open>all\<close> theory data slots ever declared.  This also
   8.299    means that one needs to be economic about the total number of proof
   8.300    data declarations in the system, i.e.\ each ML module should declare
   8.301 @@ -330,19 +325,19 @@
   8.302    avoided!
   8.303  
   8.304    \paragraph{Generic data} provides a hybrid interface for both theory
   8.305 -  and proof data.  The @{text "init"} operation for proof contexts is
   8.306 +  and proof data.  The \<open>init\<close> operation for proof contexts is
   8.307    predefined to select the current data value from the background
   8.308    theory.
   8.309  
   8.310    \<^bigskip>
   8.311 -  Any of the above data declarations over type @{text "T"}
   8.312 +  Any of the above data declarations over type \<open>T\<close>
   8.313    result in an ML structure with the following signature:
   8.314  
   8.315    \<^medskip>
   8.316    \begin{tabular}{ll}
   8.317 -  @{text "get: context \<rightarrow> T"} \\
   8.318 -  @{text "put: T \<rightarrow> context \<rightarrow> context"} \\
   8.319 -  @{text "map: (T \<rightarrow> T) \<rightarrow> context \<rightarrow> context"} \\
   8.320 +  \<open>get: context \<rightarrow> T\<close> \\
   8.321 +  \<open>put: T \<rightarrow> context \<rightarrow> context\<close> \\
   8.322 +  \<open>map: (T \<rightarrow> T) \<rightarrow> context \<rightarrow> context\<close> \\
   8.323    \end{tabular}
   8.324    \<^medskip>
   8.325  
   8.326 @@ -360,15 +355,15 @@
   8.327    @{index_ML_functor Generic_Data} \\
   8.328    \end{mldecls}
   8.329  
   8.330 -  \<^descr> @{ML_functor Theory_Data}@{text "(spec)"} declares data for
   8.331 +  \<^descr> @{ML_functor Theory_Data}\<open>(spec)\<close> declares data for
   8.332    type @{ML_type theory} according to the specification provided as
   8.333    argument structure.  The resulting structure provides data init and
   8.334    access operations as described above.
   8.335  
   8.336 -  \<^descr> @{ML_functor Proof_Data}@{text "(spec)"} is analogous to
   8.337 +  \<^descr> @{ML_functor Proof_Data}\<open>(spec)\<close> is analogous to
   8.338    @{ML_functor Theory_Data} for type @{ML_type Proof.context}.
   8.339  
   8.340 -  \<^descr> @{ML_functor Generic_Data}@{text "(spec)"} is analogous to
   8.341 +  \<^descr> @{ML_functor Generic_Data}\<open>(spec)\<close> is analogous to
   8.342    @{ML_functor Theory_Data} for type @{ML_type Context.generic}.
   8.343  \<close>
   8.344  
   8.345 @@ -515,16 +510,16 @@
   8.346    string Config.T"} \\
   8.347    \end{mldecls}
   8.348  
   8.349 -  \<^descr> @{ML Config.get}~@{text "ctxt config"} gets the value of
   8.350 -  @{text "config"} in the given context.
   8.351 +  \<^descr> @{ML Config.get}~\<open>ctxt config\<close> gets the value of
   8.352 +  \<open>config\<close> in the given context.
   8.353  
   8.354 -  \<^descr> @{ML Config.map}~@{text "config f ctxt"} updates the context
   8.355 -  by updating the value of @{text "config"}.
   8.356 +  \<^descr> @{ML Config.map}~\<open>config f ctxt\<close> updates the context
   8.357 +  by updating the value of \<open>config\<close>.
   8.358  
   8.359 -  \<^descr> @{text "config ="}~@{ML Attrib.setup_config_bool}~@{text "name
   8.360 -  default"} creates a named configuration option of type @{ML_type
   8.361 -  bool}, with the given @{text "default"} depending on the application
   8.362 -  context.  The resulting @{text "config"} can be used to get/map its
   8.363 +  \<^descr> \<open>config =\<close>~@{ML Attrib.setup_config_bool}~\<open>name
   8.364 +  default\<close> creates a named configuration option of type @{ML_type
   8.365 +  bool}, with the given \<open>default\<close> depending on the application
   8.366 +  context.  The resulting \<open>config\<close> can be used to get/map its
   8.367    value in a given context.  There is an implicit update of the
   8.368    background theory that registers the option as attribute with some
   8.369    concrete syntax.
   8.370 @@ -535,7 +530,7 @@
   8.371  \<close>
   8.372  
   8.373  text %mlex \<open>The following example shows how to declare and use a
   8.374 -  Boolean configuration option called @{text "my_flag"} with constant
   8.375 +  Boolean configuration option called \<open>my_flag\<close> with constant
   8.376    default value @{ML false}.\<close>
   8.377  
   8.378  ML \<open>
   8.379 @@ -578,8 +573,8 @@
   8.380  
   8.381  text \<open>In principle, a name is just a string, but there are various
   8.382    conventions for representing additional structure.  For example,
   8.383 -  ``@{text "Foo.bar.baz"}'' is considered as a long name consisting of
   8.384 -  qualifier @{text "Foo.bar"} and base name @{text "baz"}.  The
   8.385 +  ``\<open>Foo.bar.baz\<close>'' is considered as a long name consisting of
   8.386 +  qualifier \<open>Foo.bar\<close> and base name \<open>baz\<close>.  The
   8.387    individual constituents of a name may have further substructure,
   8.388    e.g.\ the string ``@{verbatim \<alpha>}'' encodes as a single
   8.389    symbol (\secref{sec:symbols}).
   8.390 @@ -610,31 +605,27 @@
   8.391    \<^emph>\<open>internal name\<close>, two underscores means \<^emph>\<open>Skolem name\<close>,
   8.392    three underscores means \<^emph>\<open>internal Skolem name\<close>.
   8.393  
   8.394 -  For example, the basic name @{text "foo"} has the internal version
   8.395 -  @{text "foo_"}, with Skolem versions @{text "foo__"} and @{text
   8.396 -  "foo___"}, respectively.
   8.397 +  For example, the basic name \<open>foo\<close> has the internal version
   8.398 +  \<open>foo_\<close>, with Skolem versions \<open>foo__\<close> and \<open>foo___\<close>, respectively.
   8.399  
   8.400    These special versions provide copies of the basic name space, apart
   8.401    from anything that normally appears in the user text.  For example,
   8.402    system generated variables in Isar proof contexts are usually marked
   8.403 -  as internal, which prevents mysterious names like @{text "xaa"} to
   8.404 +  as internal, which prevents mysterious names like \<open>xaa\<close> to
   8.405    appear in human-readable text.
   8.406  
   8.407    \<^medskip>
   8.408    Manipulating binding scopes often requires on-the-fly
   8.409    renamings.  A \<^emph>\<open>name context\<close> contains a collection of already
   8.410 -  used names.  The @{text "declare"} operation adds names to the
   8.411 +  used names.  The \<open>declare\<close> operation adds names to the
   8.412    context.
   8.413  
   8.414 -  The @{text "invents"} operation derives a number of fresh names from
   8.415 +  The \<open>invents\<close> operation derives a number of fresh names from
   8.416    a given starting point.  For example, the first three names derived
   8.417 -  from @{text "a"} are @{text "a"}, @{text "b"}, @{text "c"}.
   8.418 +  from \<open>a\<close> are \<open>a\<close>, \<open>b\<close>, \<open>c\<close>.
   8.419  
   8.420 -  The @{text "variants"} operation produces fresh names by
   8.421 -  incrementing tentative names as base-26 numbers (with digits @{text
   8.422 -  "a..z"}) until all clashes are resolved.  For example, name @{text
   8.423 -  "foo"} results in variants @{text "fooa"}, @{text "foob"}, @{text
   8.424 -  "fooc"}, \dots, @{text "fooaa"}, @{text "fooab"} etc.; each renaming
   8.425 +  The \<open>variants\<close> operation produces fresh names by
   8.426 +  incrementing tentative names as base-26 numbers (with digits \<open>a..z\<close>) until all clashes are resolved.  For example, name \<open>foo\<close> results in variants \<open>fooa\<close>, \<open>foob\<close>, \<open>fooc\<close>, \dots, \<open>fooaa\<close>, \<open>fooab\<close> etc.; each renaming
   8.427    step picks the next unused variant from this sequence.
   8.428  \<close>
   8.429  
   8.430 @@ -654,25 +645,24 @@
   8.431    @{index_ML Variable.names_of: "Proof.context -> Name.context"} \\
   8.432    \end{mldecls}
   8.433  
   8.434 -  \<^descr> @{ML Name.internal}~@{text "name"} produces an internal name
   8.435 +  \<^descr> @{ML Name.internal}~\<open>name\<close> produces an internal name
   8.436    by adding one underscore.
   8.437  
   8.438 -  \<^descr> @{ML Name.skolem}~@{text "name"} produces a Skolem name by
   8.439 +  \<^descr> @{ML Name.skolem}~\<open>name\<close> produces a Skolem name by
   8.440    adding two underscores.
   8.441  
   8.442    \<^descr> Type @{ML_type Name.context} represents the context of already
   8.443    used names; the initial value is @{ML "Name.context"}.
   8.444  
   8.445 -  \<^descr> @{ML Name.declare}~@{text "name"} enters a used name into the
   8.446 +  \<^descr> @{ML Name.declare}~\<open>name\<close> enters a used name into the
   8.447    context.
   8.448  
   8.449 -  \<^descr> @{ML Name.invent}~@{text "context name n"} produces @{text
   8.450 -  "n"} fresh names derived from @{text "name"}.
   8.451 +  \<^descr> @{ML Name.invent}~\<open>context name n\<close> produces \<open>n\<close> fresh names derived from \<open>name\<close>.
   8.452  
   8.453 -  \<^descr> @{ML Name.variant}~@{text "name context"} produces a fresh
   8.454 -  variant of @{text "name"}; the result is declared to the context.
   8.455 +  \<^descr> @{ML Name.variant}~\<open>name context\<close> produces a fresh
   8.456 +  variant of \<open>name\<close>; the result is declared to the context.
   8.457  
   8.458 -  \<^descr> @{ML Variable.names_of}~@{text "ctxt"} retrieves the context
   8.459 +  \<^descr> @{ML Variable.names_of}~\<open>ctxt\<close> retrieves the context
   8.460    of declared type and term variable names.  Projecting a proof
   8.461    context down to a primitive name context is occasionally useful when
   8.462    invoking lower-level operations.  Regular management of ``fresh
   8.463 @@ -718,36 +708,36 @@
   8.464  subsection \<open>Indexed names \label{sec:indexname}\<close>
   8.465  
   8.466  text \<open>
   8.467 -  An \<^emph>\<open>indexed name\<close> (or @{text "indexname"}) is a pair of a basic
   8.468 +  An \<^emph>\<open>indexed name\<close> (or \<open>indexname\<close>) is a pair of a basic
   8.469    name and a natural number.  This representation allows efficient
   8.470    renaming by incrementing the second component only.  The canonical
   8.471    way to rename two collections of indexnames apart from each other is
   8.472 -  this: determine the maximum index @{text "maxidx"} of the first
   8.473 +  this: determine the maximum index \<open>maxidx\<close> of the first
   8.474    collection, then increment all indexes of the second collection by
   8.475 -  @{text "maxidx + 1"}; the maximum index of an empty collection is
   8.476 -  @{text "-1"}.
   8.477 +  \<open>maxidx + 1\<close>; the maximum index of an empty collection is
   8.478 +  \<open>-1\<close>.
   8.479  
   8.480    Occasionally, basic names are injected into the same pair type of
   8.481 -  indexed names: then @{text "(x, -1)"} is used to encode the basic
   8.482 -  name @{text "x"}.
   8.483 +  indexed names: then \<open>(x, -1)\<close> is used to encode the basic
   8.484 +  name \<open>x\<close>.
   8.485  
   8.486    \<^medskip>
   8.487    Isabelle syntax observes the following rules for
   8.488 -  representing an indexname @{text "(x, i)"} as a packed string:
   8.489 +  representing an indexname \<open>(x, i)\<close> as a packed string:
   8.490  
   8.491 -  \<^item> @{text "?x"} if @{text "x"} does not end with a digit and @{text "i = 0"},
   8.492 +  \<^item> \<open>?x\<close> if \<open>x\<close> does not end with a digit and \<open>i = 0\<close>,
   8.493  
   8.494 -  \<^item> @{text "?xi"} if @{text "x"} does not end with a digit,
   8.495 +  \<^item> \<open>?xi\<close> if \<open>x\<close> does not end with a digit,
   8.496  
   8.497 -  \<^item> @{text "?x.i"} otherwise.
   8.498 +  \<^item> \<open>?x.i\<close> otherwise.
   8.499  
   8.500  
   8.501    Indexnames may acquire large index numbers after several maxidx
   8.502    shifts have been applied.  Results are usually normalized towards
   8.503 -  @{text "0"} at certain checkpoints, notably at the end of a proof.
   8.504 +  \<open>0\<close> at certain checkpoints, notably at the end of a proof.
   8.505    This works by producing variants of the corresponding basic name
   8.506 -  components.  For example, the collection @{text "?x1, ?x7, ?x42"}
   8.507 -  becomes @{text "?x, ?xa, ?xb"}.
   8.508 +  components.  For example, the collection \<open>?x1, ?x7, ?x42\<close>
   8.509 +  becomes \<open>?x, ?xa, ?xb\<close>.
   8.510  \<close>
   8.511  
   8.512  text %mlref \<open>
   8.513 @@ -757,8 +747,8 @@
   8.514  
   8.515    \<^descr> Type @{ML_type indexname} represents indexed names.  This is
   8.516    an abbreviation for @{ML_type "string * int"}.  The second component
   8.517 -  is usually non-negative, except for situations where @{text "(x,
   8.518 -  -1)"} is used to inject basic names into this type.  Other negative
   8.519 +  is usually non-negative, except for situations where \<open>(x,
   8.520 +  -1)\<close> is used to inject basic names into this type.  Other negative
   8.521    indexes should not be used.
   8.522  \<close>
   8.523  
   8.524 @@ -767,16 +757,16 @@
   8.525  
   8.526  text \<open>A \<^emph>\<open>long name\<close> consists of a sequence of non-empty name
   8.527    components.  The packed representation uses a dot as separator, as
   8.528 -  in ``@{text "A.b.c"}''.  The last component is called \<^emph>\<open>base
   8.529 +  in ``\<open>A.b.c\<close>''.  The last component is called \<^emph>\<open>base
   8.530    name\<close>, the remaining prefix is called \<^emph>\<open>qualifier\<close> (which may be
   8.531    empty).  The qualifier can be understood as the access path to the
   8.532    named entity while passing through some nested block-structure,
   8.533    although our free-form long names do not really enforce any strict
   8.534    discipline.
   8.535  
   8.536 -  For example, an item named ``@{text "A.b.c"}'' may be understood as
   8.537 -  a local entity @{text "c"}, within a local structure @{text "b"},
   8.538 -  within a global structure @{text "A"}.  In practice, long names
   8.539 +  For example, an item named ``\<open>A.b.c\<close>'' may be understood as
   8.540 +  a local entity \<open>c\<close>, within a local structure \<open>b\<close>,
   8.541 +  within a global structure \<open>A\<close>.  In practice, long names
   8.542    usually represent 1--3 levels of qualification.  User ML code should
   8.543    not make any assumptions about the particular structure of long
   8.544    names!
   8.545 @@ -796,42 +786,41 @@
   8.546    @{index_ML Long_Name.explode: "string -> string list"} \\
   8.547    \end{mldecls}
   8.548  
   8.549 -  \<^descr> @{ML Long_Name.base_name}~@{text "name"} returns the base name
   8.550 +  \<^descr> @{ML Long_Name.base_name}~\<open>name\<close> returns the base name
   8.551    of a long name.
   8.552  
   8.553 -  \<^descr> @{ML Long_Name.qualifier}~@{text "name"} returns the qualifier
   8.554 +  \<^descr> @{ML Long_Name.qualifier}~\<open>name\<close> returns the qualifier
   8.555    of a long name.
   8.556  
   8.557 -  \<^descr> @{ML Long_Name.append}~@{text "name\<^sub>1 name\<^sub>2"} appends two long
   8.558 +  \<^descr> @{ML Long_Name.append}~\<open>name\<^sub>1 name\<^sub>2\<close> appends two long
   8.559    names.
   8.560  
   8.561 -  \<^descr> @{ML Long_Name.implode}~@{text "names"} and @{ML
   8.562 -  Long_Name.explode}~@{text "name"} convert between the packed string
   8.563 +  \<^descr> @{ML Long_Name.implode}~\<open>names\<close> and @{ML
   8.564 +  Long_Name.explode}~\<open>name\<close> convert between the packed string
   8.565    representation and the explicit list form of long names.
   8.566  \<close>
   8.567  
   8.568  
   8.569  subsection \<open>Name spaces \label{sec:name-space}\<close>
   8.570  
   8.571 -text \<open>A @{text "name space"} manages a collection of long names,
   8.572 +text \<open>A \<open>name space\<close> manages a collection of long names,
   8.573    together with a mapping between partially qualified external names
   8.574    and fully qualified internal names (in both directions).  Note that
   8.575 -  the corresponding @{text "intern"} and @{text "extern"} operations
   8.576 -  are mostly used for parsing and printing only!  The @{text
   8.577 -  "declare"} operation augments a name space according to the accesses
   8.578 +  the corresponding \<open>intern\<close> and \<open>extern\<close> operations
   8.579 +  are mostly used for parsing and printing only!  The \<open>declare\<close> operation augments a name space according to the accesses
   8.580    determined by a given binding, and a naming policy from the context.
   8.581  
   8.582    \<^medskip>
   8.583 -  A @{text "binding"} specifies details about the prospective
   8.584 +  A \<open>binding\<close> specifies details about the prospective
   8.585    long name of a newly introduced formal entity.  It consists of a
   8.586    base name, prefixes for qualification (separate ones for system
   8.587    infrastructure and user-space mechanisms), a slot for the original
   8.588    source position, and some additional flags.
   8.589  
   8.590    \<^medskip>
   8.591 -  A @{text "naming"} provides some additional details for
   8.592 +  A \<open>naming\<close> provides some additional details for
   8.593    producing a long name from a binding.  Normally, the naming is
   8.594 -  implicit in the theory or proof context.  The @{text "full"}
   8.595 +  implicit in the theory or proof context.  The \<open>full\<close>
   8.596    operation (and its variants for different context types) produces a
   8.597    fully qualified internal name to be entered into a name space.  The
   8.598    main equation of this ``chemical reaction'' when binding new
   8.599 @@ -839,7 +828,7 @@
   8.600  
   8.601    \<^medskip>
   8.602    \begin{tabular}{l}
   8.603 -  @{text "binding + naming \<longrightarrow> long name + name space accesses"}
   8.604 +  \<open>binding + naming \<longrightarrow> long name + name space accesses\<close>
   8.605    \end{tabular}
   8.606  
   8.607    \<^bigskip>
   8.608 @@ -847,13 +836,13 @@
   8.609    each kind of formal entity, e.g.\ fact, logical constant, type
   8.610    constructor, type class.  It is usually clear from the occurrence in
   8.611    concrete syntax (or from the scope) which kind of entity a name
   8.612 -  refers to.  For example, the very same name @{text "c"} may be used
   8.613 +  refers to.  For example, the very same name \<open>c\<close> may be used
   8.614    uniformly for a constant, type constructor, and type class.
   8.615  
   8.616    There are common schemes to name derived entities systematically
   8.617    according to the name of the main logical entity involved, e.g.\
   8.618 -  fact @{text "c.intro"} for a canonical introduction rule related to
   8.619 -  constant @{text "c"}.  This technique of mapping names from one
   8.620 +  fact \<open>c.intro\<close> for a canonical introduction rule related to
   8.621 +  constant \<open>c\<close>.  This technique of mapping names from one
   8.622    space into another requires some care in order to avoid conflicts.
   8.623    In particular, theorem names derived from a type constructor or type
   8.624    class should get an additional suffix in addition to the usual
   8.625 @@ -863,9 +852,9 @@
   8.626    \<^medskip>
   8.627    \begin{tabular}{ll}
   8.628    logical entity & fact name \\\hline
   8.629 -  constant @{text "c"} & @{text "c.intro"} \\
   8.630 -  type @{text "c"} & @{text "c_type.intro"} \\
   8.631 -  class @{text "c"} & @{text "c_class.intro"} \\
   8.632 +  constant \<open>c\<close> & \<open>c.intro\<close> \\
   8.633 +  type \<open>c\<close> & \<open>c_type.intro\<close> \\
   8.634 +  class \<open>c\<close> & \<open>c_class.intro\<close> \\
   8.635    \end{tabular}
   8.636  \<close>
   8.637  
   8.638 @@ -901,15 +890,14 @@
   8.639  
   8.640    \<^descr> @{ML Binding.empty} is the empty binding.
   8.641  
   8.642 -  \<^descr> @{ML Binding.name}~@{text "name"} produces a binding with base
   8.643 -  name @{text "name"}.  Note that this lacks proper source position
   8.644 +  \<^descr> @{ML Binding.name}~\<open>name\<close> produces a binding with base
   8.645 +  name \<open>name\<close>.  Note that this lacks proper source position
   8.646    information; see also the ML antiquotation @{ML_antiquotation
   8.647    binding}.
   8.648  
   8.649 -  \<^descr> @{ML Binding.qualify}~@{text "mandatory name binding"}
   8.650 -  prefixes qualifier @{text "name"} to @{text "binding"}.  The @{text
   8.651 -  "mandatory"} flag tells if this name component always needs to be
   8.652 -  given in name space accesses --- this is mostly @{text "false"} in
   8.653 +  \<^descr> @{ML Binding.qualify}~\<open>mandatory name binding\<close>
   8.654 +  prefixes qualifier \<open>name\<close> to \<open>binding\<close>.  The \<open>mandatory\<close> flag tells if this name component always needs to be
   8.655 +  given in name space accesses --- this is mostly \<open>false\<close> in
   8.656    practice.  Note that this part of qualification is typically used in
   8.657    derived specification mechanisms.
   8.658  
   8.659 @@ -918,14 +906,14 @@
   8.660    typically used in the infrastructure for modular specifications,
   8.661    notably ``local theory targets'' (see also \chref{ch:local-theory}).
   8.662  
   8.663 -  \<^descr> @{ML Binding.concealed}~@{text "binding"} indicates that the
   8.664 +  \<^descr> @{ML Binding.concealed}~\<open>binding\<close> indicates that the
   8.665    binding shall refer to an entity that serves foundational purposes
   8.666    only.  This flag helps to mark implementation details of
   8.667    specification mechanism etc.  Other tools should not depend on the
   8.668    particulars of concealed entities (cf.\ @{ML
   8.669    Name_Space.is_concealed}).
   8.670  
   8.671 -  \<^descr> @{ML Binding.print}~@{text "binding"} produces a string
   8.672 +  \<^descr> @{ML Binding.print}~\<open>binding\<close> produces a string
   8.673    representation for human-readable output, together with some formal
   8.674    markup that might get used in GUI front-ends, for example.
   8.675  
   8.676 @@ -936,26 +924,25 @@
   8.677    global and lacks any path prefix.  In a regular theory context this is
   8.678    augmented by a path prefix consisting of the theory name.
   8.679  
   8.680 -  \<^descr> @{ML Name_Space.add_path}~@{text "path naming"} augments the
   8.681 +  \<^descr> @{ML Name_Space.add_path}~\<open>path naming\<close> augments the
   8.682    naming policy by extending its path component.
   8.683  
   8.684 -  \<^descr> @{ML Name_Space.full_name}~@{text "naming binding"} turns a
   8.685 +  \<^descr> @{ML Name_Space.full_name}~\<open>naming binding\<close> turns a
   8.686    name binding (usually a basic name) into the fully qualified
   8.687    internal name, according to the given naming policy.
   8.688  
   8.689    \<^descr> Type @{ML_type Name_Space.T} represents name spaces.
   8.690  
   8.691 -  \<^descr> @{ML Name_Space.empty}~@{text "kind"} and @{ML Name_Space.merge}~@{text
   8.692 -  "(space\<^sub>1, space\<^sub>2)"} are the canonical operations for
   8.693 +  \<^descr> @{ML Name_Space.empty}~\<open>kind\<close> and @{ML Name_Space.merge}~\<open>(space\<^sub>1, space\<^sub>2)\<close> are the canonical operations for
   8.694    maintaining name spaces according to theory data management
   8.695 -  (\secref{sec:context-data}); @{text "kind"} is a formal comment
   8.696 +  (\secref{sec:context-data}); \<open>kind\<close> is a formal comment
   8.697    to characterize the purpose of a name space.
   8.698  
   8.699 -  \<^descr> @{ML Name_Space.declare}~@{text "context strict binding
   8.700 -  space"} enters a name binding as fully qualified internal name into
   8.701 +  \<^descr> @{ML Name_Space.declare}~\<open>context strict binding
   8.702 +  space\<close> enters a name binding as fully qualified internal name into
   8.703    the name space, using the naming of the context.
   8.704  
   8.705 -  \<^descr> @{ML Name_Space.intern}~@{text "space name"} internalizes a
   8.706 +  \<^descr> @{ML Name_Space.intern}~\<open>space name\<close> internalizes a
   8.707    (partially qualified) external name.
   8.708  
   8.709    This operation is mostly for parsing!  Note that fully qualified
   8.710 @@ -964,28 +951,28 @@
   8.711    (or their derivatives for @{ML_type theory} and
   8.712    @{ML_type Proof.context}).
   8.713  
   8.714 -  \<^descr> @{ML Name_Space.extern}~@{text "ctxt space name"} externalizes a
   8.715 +  \<^descr> @{ML Name_Space.extern}~\<open>ctxt space name\<close> externalizes a
   8.716    (fully qualified) internal name.
   8.717  
   8.718    This operation is mostly for printing!  User code should not rely on
   8.719    the precise result too much.
   8.720  
   8.721 -  \<^descr> @{ML Name_Space.is_concealed}~@{text "space name"} indicates
   8.722 -  whether @{text "name"} refers to a strictly private entity that
   8.723 +  \<^descr> @{ML Name_Space.is_concealed}~\<open>space name\<close> indicates
   8.724 +  whether \<open>name\<close> refers to a strictly private entity that
   8.725    other tools are supposed to ignore!
   8.726  \<close>
   8.727  
   8.728  text %mlantiq \<open>
   8.729    \begin{matharray}{rcl}
   8.730 -  @{ML_antiquotation_def "binding"} & : & @{text ML_antiquotation} \\
   8.731 +  @{ML_antiquotation_def "binding"} & : & \<open>ML_antiquotation\<close> \\
   8.732    \end{matharray}
   8.733  
   8.734    @{rail \<open>
   8.735    @@{ML_antiquotation binding} name
   8.736    \<close>}
   8.737  
   8.738 -  \<^descr> @{text "@{binding name}"} produces a binding with base name
   8.739 -  @{text "name"} and the source position taken from the concrete
   8.740 +  \<^descr> \<open>@{binding name}\<close> produces a binding with base name
   8.741 +  \<open>name\<close> and the source position taken from the concrete
   8.742    syntax of this antiquotation.  In many situations this is more
   8.743    appropriate than the more basic @{ML Binding.name} function.
   8.744  \<close>
     9.1 --- a/src/Doc/Implementation/Proof.thy	Tue Oct 20 23:03:46 2015 +0200
     9.2 +++ b/src/Doc/Implementation/Proof.thy	Tue Oct 20 23:53:40 2015 +0200
     9.3 @@ -7,27 +7,24 @@
     9.4  section \<open>Variables \label{sec:variables}\<close>
     9.5  
     9.6  text \<open>
     9.7 -  Any variable that is not explicitly bound by @{text "\<lambda>"}-abstraction
     9.8 +  Any variable that is not explicitly bound by \<open>\<lambda>\<close>-abstraction
     9.9    is considered as ``free''.  Logically, free variables act like
    9.10 -  outermost universal quantification at the sequent level: @{text
    9.11 -  "A\<^sub>1(x), \<dots>, A\<^sub>n(x) \<turnstile> B(x)"} means that the result
    9.12 -  holds \<^emph>\<open>for all\<close> values of @{text "x"}.  Free variables for
    9.13 -  terms (not types) can be fully internalized into the logic: @{text
    9.14 -  "\<turnstile> B(x)"} and @{text "\<turnstile> \<And>x. B(x)"} are interchangeable, provided
    9.15 -  that @{text "x"} does not occur elsewhere in the context.
    9.16 -  Inspecting @{text "\<turnstile> \<And>x. B(x)"} more closely, we see that inside the
    9.17 -  quantifier, @{text "x"} is essentially ``arbitrary, but fixed'',
    9.18 +  outermost universal quantification at the sequent level: \<open>A\<^sub>1(x), \<dots>, A\<^sub>n(x) \<turnstile> B(x)\<close> means that the result
    9.19 +  holds \<^emph>\<open>for all\<close> values of \<open>x\<close>.  Free variables for
    9.20 +  terms (not types) can be fully internalized into the logic: \<open>\<turnstile> B(x)\<close> and \<open>\<turnstile> \<And>x. B(x)\<close> are interchangeable, provided
    9.21 +  that \<open>x\<close> does not occur elsewhere in the context.
    9.22 +  Inspecting \<open>\<turnstile> \<And>x. B(x)\<close> more closely, we see that inside the
    9.23 +  quantifier, \<open>x\<close> is essentially ``arbitrary, but fixed'',
    9.24    while from outside it appears as a place-holder for instantiation
    9.25 -  (thanks to @{text "\<And>"} elimination).
    9.26 +  (thanks to \<open>\<And>\<close> elimination).
    9.27  
    9.28    The Pure logic represents the idea of variables being either inside
    9.29    or outside the current scope by providing separate syntactic
    9.30 -  categories for \<^emph>\<open>fixed variables\<close> (e.g.\ @{text "x"}) vs.\
    9.31 -  \<^emph>\<open>schematic variables\<close> (e.g.\ @{text "?x"}).  Incidently, a
    9.32 -  universal result @{text "\<turnstile> \<And>x. B(x)"} has the HHF normal form @{text
    9.33 -  "\<turnstile> B(?x)"}, which represents its generality without requiring an
    9.34 +  categories for \<^emph>\<open>fixed variables\<close> (e.g.\ \<open>x\<close>) vs.\
    9.35 +  \<^emph>\<open>schematic variables\<close> (e.g.\ \<open>?x\<close>).  Incidently, a
    9.36 +  universal result \<open>\<turnstile> \<And>x. B(x)\<close> has the HHF normal form \<open>\<turnstile> B(?x)\<close>, which represents its generality without requiring an
    9.37    explicit quantifier.  The same principle works for type variables:
    9.38 -  @{text "\<turnstile> B(?\<alpha>)"} represents the idea of ``@{text "\<turnstile> \<forall>\<alpha>. B(\<alpha>)"}''
    9.39 +  \<open>\<turnstile> B(?\<alpha>)\<close> represents the idea of ``\<open>\<turnstile> \<forall>\<alpha>. B(\<alpha>)\<close>''
    9.40    without demanding a truly polymorphic framework.
    9.41  
    9.42    \<^medskip>
    9.43 @@ -36,66 +33,64 @@
    9.44    depend on type variables, which means that type variables would have
    9.45    to be declared first.  For example, a raw type-theoretic framework
    9.46    would demand the context to be constructed in stages as follows:
    9.47 -  @{text "\<Gamma> = \<alpha>: type, x: \<alpha>, a: A(x\<^sub>\<alpha>)"}.
    9.48 +  \<open>\<Gamma> = \<alpha>: type, x: \<alpha>, a: A(x\<^sub>\<alpha>)\<close>.
    9.49  
    9.50    We allow a slightly less formalistic mode of operation: term
    9.51 -  variables @{text "x"} are fixed without specifying a type yet
    9.52 +  variables \<open>x\<close> are fixed without specifying a type yet
    9.53    (essentially \<^emph>\<open>all\<close> potential occurrences of some instance
    9.54 -  @{text "x\<^sub>\<tau>"} are fixed); the first occurrence of @{text "x"}
    9.55 +  \<open>x\<^sub>\<tau>\<close> are fixed); the first occurrence of \<open>x\<close>
    9.56    within a specific term assigns its most general type, which is then
    9.57    maintained consistently in the context.  The above example becomes
    9.58 -  @{text "\<Gamma> = x: term, \<alpha>: type, A(x\<^sub>\<alpha>)"}, where type @{text
    9.59 -  "\<alpha>"} is fixed \<^emph>\<open>after\<close> term @{text "x"}, and the constraint
    9.60 -  @{text "x :: \<alpha>"} is an implicit consequence of the occurrence of
    9.61 -  @{text "x\<^sub>\<alpha>"} in the subsequent proposition.
    9.62 +  \<open>\<Gamma> = x: term, \<alpha>: type, A(x\<^sub>\<alpha>)\<close>, where type \<open>\<alpha>\<close> is fixed \<^emph>\<open>after\<close> term \<open>x\<close>, and the constraint
    9.63 +  \<open>x :: \<alpha>\<close> is an implicit consequence of the occurrence of
    9.64 +  \<open>x\<^sub>\<alpha>\<close> in the subsequent proposition.
    9.65  
    9.66    This twist of dependencies is also accommodated by the reverse
    9.67    operation of exporting results from a context: a type variable
    9.68 -  @{text "\<alpha>"} is considered fixed as long as it occurs in some fixed
    9.69 -  term variable of the context.  For example, exporting @{text "x:
    9.70 -  term, \<alpha>: type \<turnstile> x\<^sub>\<alpha> \<equiv> x\<^sub>\<alpha>"} produces in the first step @{text "x: term
    9.71 -  \<turnstile> x\<^sub>\<alpha> \<equiv> x\<^sub>\<alpha>"} for fixed @{text "\<alpha>"}, and only in the second step
    9.72 -  @{text "\<turnstile> ?x\<^sub>?\<^sub>\<alpha> \<equiv> ?x\<^sub>?\<^sub>\<alpha>"} for schematic @{text "?x"} and @{text "?\<alpha>"}.
    9.73 +  \<open>\<alpha>\<close> is considered fixed as long as it occurs in some fixed
    9.74 +  term variable of the context.  For example, exporting \<open>x:
    9.75 +  term, \<alpha>: type \<turnstile> x\<^sub>\<alpha> \<equiv> x\<^sub>\<alpha>\<close> produces in the first step \<open>x: term
    9.76 +  \<turnstile> x\<^sub>\<alpha> \<equiv> x\<^sub>\<alpha>\<close> for fixed \<open>\<alpha>\<close>, and only in the second step
    9.77 +  \<open>\<turnstile> ?x\<^sub>?\<^sub>\<alpha> \<equiv> ?x\<^sub>?\<^sub>\<alpha>\<close> for schematic \<open>?x\<close> and \<open>?\<alpha>\<close>.
    9.78    The following Isar source text illustrates this scenario.
    9.79  \<close>
    9.80  
    9.81  notepad
    9.82  begin
    9.83    {
    9.84 -    fix x  -- \<open>all potential occurrences of some @{text "x::\<tau>"} are fixed\<close>
    9.85 +    fix x  -- \<open>all potential occurrences of some \<open>x::\<tau>\<close> are fixed\<close>
    9.86      {
    9.87        have "x::'a \<equiv> x"  -- \<open>implicit type assignment by concrete occurrence\<close>
    9.88          by (rule reflexive)
    9.89      }
    9.90 -    thm this  -- \<open>result still with fixed type @{text "'a"}\<close>
    9.91 +    thm this  -- \<open>result still with fixed type \<open>'a\<close>\<close>
    9.92    }
    9.93 -  thm this  -- \<open>fully general result for arbitrary @{text "?x::?'a"}\<close>
    9.94 +  thm this  -- \<open>fully general result for arbitrary \<open>?x::?'a\<close>\<close>
    9.95  end
    9.96  
    9.97  text \<open>The Isabelle/Isar proof context manages the details of term
    9.98    vs.\ type variables, with high-level principles for moving the
    9.99    frontier between fixed and schematic variables.
   9.100  
   9.101 -  The @{text "add_fixes"} operation explicitly declares fixed
   9.102 -  variables; the @{text "declare_term"} operation absorbs a term into
   9.103 +  The \<open>add_fixes\<close> operation explicitly declares fixed
   9.104 +  variables; the \<open>declare_term\<close> operation absorbs a term into
   9.105    a context by fixing new type variables and adding syntactic
   9.106    constraints.
   9.107  
   9.108 -  The @{text "export"} operation is able to perform the main work of
   9.109 +  The \<open>export\<close> operation is able to perform the main work of
   9.110    generalizing term and type variables as sketched above, assuming
   9.111    that fixing variables and terms have been declared properly.
   9.112  
   9.113 -  There @{text "import"} operation makes a generalized fact a genuine
   9.114 +  There \<open>import\<close> operation makes a generalized fact a genuine
   9.115    part of the context, by inventing fixed variables for the schematic
   9.116 -  ones.  The effect can be reversed by using @{text "export"} later,
   9.117 +  ones.  The effect can be reversed by using \<open>export\<close> later,
   9.118    potentially with an extended context; the result is equivalent to
   9.119    the original modulo renaming of schematic variables.
   9.120  
   9.121 -  The @{text "focus"} operation provides a variant of @{text "import"}
   9.122 -  for nested propositions (with explicit quantification): @{text
   9.123 -  "\<And>x\<^sub>1 \<dots> x\<^sub>n. B(x\<^sub>1, \<dots>, x\<^sub>n)"} is
   9.124 -  decomposed by inventing fixed variables @{text "x\<^sub>1, \<dots>,
   9.125 -  x\<^sub>n"} for the body.
   9.126 +  The \<open>focus\<close> operation provides a variant of \<open>import\<close>
   9.127 +  for nested propositions (with explicit quantification): \<open>\<And>x\<^sub>1 \<dots> x\<^sub>n. B(x\<^sub>1, \<dots>, x\<^sub>n)\<close> is
   9.128 +  decomposed by inventing fixed variables \<open>x\<^sub>1, \<dots>,
   9.129 +  x\<^sub>n\<close> for the body.
   9.130  \<close>
   9.131  
   9.132  text %mlref \<open>
   9.133 @@ -114,8 +109,8 @@
   9.134    ((string * (string * typ)) list * term) * Proof.context"} \\
   9.135    \end{mldecls}
   9.136  
   9.137 -  \<^descr> @{ML Variable.add_fixes}~@{text "xs ctxt"} fixes term
   9.138 -  variables @{text "xs"}, returning the resulting internal names.  By
   9.139 +  \<^descr> @{ML Variable.add_fixes}~\<open>xs ctxt\<close> fixes term
   9.140 +  variables \<open>xs\<close>, returning the resulting internal names.  By
   9.141    default, the internal representation coincides with the external
   9.142    one, which also means that the given variables must not be fixed
   9.143    already.  There is a different policy within a local proof body: the
   9.144 @@ -125,35 +120,33 @@
   9.145    Variable.add_fixes}, but always produces fresh variants of the given
   9.146    names.
   9.147  
   9.148 -  \<^descr> @{ML Variable.declare_term}~@{text "t ctxt"} declares term
   9.149 -  @{text "t"} to belong to the context.  This automatically fixes new
   9.150 +  \<^descr> @{ML Variable.declare_term}~\<open>t ctxt\<close> declares term
   9.151 +  \<open>t\<close> to belong to the context.  This automatically fixes new
   9.152    type variables, but not term variables.  Syntactic constraints for
   9.153    type and term variables are declared uniformly, though.
   9.154  
   9.155 -  \<^descr> @{ML Variable.declare_constraints}~@{text "t ctxt"} declares
   9.156 -  syntactic constraints from term @{text "t"}, without making it part
   9.157 +  \<^descr> @{ML Variable.declare_constraints}~\<open>t ctxt\<close> declares
   9.158 +  syntactic constraints from term \<open>t\<close>, without making it part
   9.159    of the context yet.
   9.160  
   9.161 -  \<^descr> @{ML Variable.export}~@{text "inner outer thms"} generalizes
   9.162 -  fixed type and term variables in @{text "thms"} according to the
   9.163 -  difference of the @{text "inner"} and @{text "outer"} context,
   9.164 +  \<^descr> @{ML Variable.export}~\<open>inner outer thms\<close> generalizes
   9.165 +  fixed type and term variables in \<open>thms\<close> according to the
   9.166 +  difference of the \<open>inner\<close> and \<open>outer\<close> context,
   9.167    following the principles sketched above.
   9.168  
   9.169 -  \<^descr> @{ML Variable.polymorphic}~@{text "ctxt ts"} generalizes type
   9.170 -  variables in @{text "ts"} as far as possible, even those occurring
   9.171 +  \<^descr> @{ML Variable.polymorphic}~\<open>ctxt ts\<close> generalizes type
   9.172 +  variables in \<open>ts\<close> as far as possible, even those occurring
   9.173    in fixed term variables.  The default policy of type-inference is to
   9.174    fix newly introduced type variables, which is essentially reversed
   9.175    with @{ML Variable.polymorphic}: here the given terms are detached
   9.176    from the context as far as possible.
   9.177  
   9.178 -  \<^descr> @{ML Variable.import}~@{text "open thms ctxt"} invents fixed
   9.179 -  type and term variables for the schematic ones occurring in @{text
   9.180 -  "thms"}.  The @{text "open"} flag indicates whether the fixed names
   9.181 +  \<^descr> @{ML Variable.import}~\<open>open thms ctxt\<close> invents fixed
   9.182 +  type and term variables for the schematic ones occurring in \<open>thms\<close>.  The \<open>open\<close> flag indicates whether the fixed names
   9.183    should be accessible to the user, otherwise newly introduced names
   9.184    are marked as ``internal'' (\secref{sec:names}).
   9.185  
   9.186 -  \<^descr> @{ML Variable.focus}~@{text "bindings B"} decomposes the outermost @{text
   9.187 -  "\<And>"} prefix of proposition @{text "B"}, using the given name bindings.
   9.188 +  \<^descr> @{ML Variable.focus}~\<open>bindings B\<close> decomposes the outermost \<open>\<And>\<close> prefix of proposition \<open>B\<close>, using the given name bindings.
   9.189  \<close>
   9.190  
   9.191  text %mlex \<open>The following example shows how to work with fixed term
   9.192 @@ -180,7 +173,7 @@
   9.193  
   9.194  text \<open>In the above example, the starting context is derived from the
   9.195    toplevel theory, which means that fixed variables are internalized
   9.196 -  literally: @{text "x"} is mapped again to @{text "x"}, and
   9.197 +  literally: \<open>x\<close> is mapped again to \<open>x\<close>, and
   9.198    attempting to fix it again in the subsequent context is an error.
   9.199    Alternatively, fixed parameters can be renamed explicitly as
   9.200    follows:\<close>
   9.201 @@ -192,7 +185,7 @@
   9.202  \<close>
   9.203  
   9.204  text \<open>The following ML code can now work with the invented names of
   9.205 -  @{text x1}, @{text x2}, @{text x3}, without depending on
   9.206 +  \<open>x1\<close>, \<open>x2\<close>, \<open>x3\<close>, without depending on
   9.207    the details on the system policy for introducing these variants.
   9.208    Recall that within a proof body the system always invents fresh
   9.209    ``Skolem constants'', e.g.\ as follows:\<close>
   9.210 @@ -227,19 +220,18 @@
   9.211    Assumptions are restricted to fixed non-schematic statements, i.e.\
   9.212    all generality needs to be expressed by explicit quantifiers.
   9.213    Nevertheless, the result will be in HHF normal form with outermost
   9.214 -  quantifiers stripped.  For example, by assuming @{text "\<And>x :: \<alpha>. P
   9.215 -  x"} we get @{text "\<And>x :: \<alpha>. P x \<turnstile> P ?x"} for schematic @{text "?x"}
   9.216 -  of fixed type @{text "\<alpha>"}.  Local derivations accumulate more and
   9.217 -  more explicit references to hypotheses: @{text "A\<^sub>1, \<dots>,
   9.218 -  A\<^sub>n \<turnstile> B"} where @{text "A\<^sub>1, \<dots>, A\<^sub>n"} needs to
   9.219 +  quantifiers stripped.  For example, by assuming \<open>\<And>x :: \<alpha>. P
   9.220 +  x\<close> we get \<open>\<And>x :: \<alpha>. P x \<turnstile> P ?x\<close> for schematic \<open>?x\<close>
   9.221 +  of fixed type \<open>\<alpha>\<close>.  Local derivations accumulate more and
   9.222 +  more explicit references to hypotheses: \<open>A\<^sub>1, \<dots>,
   9.223 +  A\<^sub>n \<turnstile> B\<close> where \<open>A\<^sub>1, \<dots>, A\<^sub>n\<close> needs to
   9.224    be covered by the assumptions of the current context.
   9.225  
   9.226    \<^medskip>
   9.227 -  The @{text "add_assms"} operation augments the context by
   9.228 -  local assumptions, which are parameterized by an arbitrary @{text
   9.229 -  "export"} rule (see below).
   9.230 +  The \<open>add_assms\<close> operation augments the context by
   9.231 +  local assumptions, which are parameterized by an arbitrary \<open>export\<close> rule (see below).
   9.232  
   9.233 -  The @{text "export"} operation moves facts from a (larger) inner
   9.234 +  The \<open>export\<close> operation moves facts from a (larger) inner
   9.235    context into a (smaller) outer context, by discharging the
   9.236    difference of the assumptions as specified by the associated export
   9.237    rules.  Note that the discharged portion is determined by the
   9.238 @@ -249,30 +241,30 @@
   9.239  
   9.240    \<^medskip>
   9.241    The most basic export rule discharges assumptions directly
   9.242 -  by means of the @{text "\<Longrightarrow>"} introduction rule:
   9.243 +  by means of the \<open>\<Longrightarrow>\<close> introduction rule:
   9.244    \[
   9.245 -  \infer[(@{text "\<Longrightarrow>\<hyphen>intro"})]{@{text "\<Gamma> - A \<turnstile> A \<Longrightarrow> B"}}{@{text "\<Gamma> \<turnstile> B"}}
   9.246 +  \infer[(\<open>\<Longrightarrow>\<hyphen>intro\<close>)]{\<open>\<Gamma> - A \<turnstile> A \<Longrightarrow> B\<close>}{\<open>\<Gamma> \<turnstile> B\<close>}
   9.247    \]
   9.248  
   9.249    The variant for goal refinements marks the newly introduced
   9.250    premises, which causes the canonical Isar goal refinement scheme to
   9.251    enforce unification with local premises within the goal:
   9.252    \[
   9.253 -  \infer[(@{text "#\<Longrightarrow>\<hyphen>intro"})]{@{text "\<Gamma> - A \<turnstile> #A \<Longrightarrow> B"}}{@{text "\<Gamma> \<turnstile> B"}}
   9.254 +  \infer[(\<open>#\<Longrightarrow>\<hyphen>intro\<close>)]{\<open>\<Gamma> - A \<turnstile> #A \<Longrightarrow> B\<close>}{\<open>\<Gamma> \<turnstile> B\<close>}
   9.255    \]
   9.256  
   9.257    \<^medskip>
   9.258    Alternative versions of assumptions may perform arbitrary
   9.259    transformations on export, as long as the corresponding portion of
   9.260    hypotheses is removed from the given facts.  For example, a local
   9.261 -  definition works by fixing @{text "x"} and assuming @{text "x \<equiv> t"},
   9.262 +  definition works by fixing \<open>x\<close> and assuming \<open>x \<equiv> t\<close>,
   9.263    with the following export rule to reverse the effect:
   9.264    \[
   9.265 -  \infer[(@{text "\<equiv>\<hyphen>expand"})]{@{text "\<Gamma> - (x \<equiv> t) \<turnstile> B t"}}{@{text "\<Gamma> \<turnstile> B x"}}
   9.266 +  \infer[(\<open>\<equiv>\<hyphen>expand\<close>)]{\<open>\<Gamma> - (x \<equiv> t) \<turnstile> B t\<close>}{\<open>\<Gamma> \<turnstile> B x\<close>}
   9.267    \]
   9.268 -  This works, because the assumption @{text "x \<equiv> t"} was introduced in
   9.269 -  a context with @{text "x"} being fresh, so @{text "x"} does not
   9.270 -  occur in @{text "\<Gamma>"} here.
   9.271 +  This works, because the assumption \<open>x \<equiv> t\<close> was introduced in
   9.272 +  a context with \<open>x\<close> being fresh, so \<open>x\<close> does not
   9.273 +  occur in \<open>\<Gamma>\<close> here.
   9.274  \<close>
   9.275  
   9.276  text %mlref \<open>
   9.277 @@ -293,23 +285,21 @@
   9.278    and the @{ML_type "cterm list"} the collection of assumptions to be
   9.279    discharged simultaneously.
   9.280  
   9.281 -  \<^descr> @{ML Assumption.assume}~@{text "ctxt A"} turns proposition @{text
   9.282 -  "A"} into a primitive assumption @{text "A \<turnstile> A'"}, where the
   9.283 -  conclusion @{text "A'"} is in HHF normal form.
   9.284 +  \<^descr> @{ML Assumption.assume}~\<open>ctxt A\<close> turns proposition \<open>A\<close> into a primitive assumption \<open>A \<turnstile> A'\<close>, where the
   9.285 +  conclusion \<open>A'\<close> is in HHF normal form.
   9.286  
   9.287 -  \<^descr> @{ML Assumption.add_assms}~@{text "r As"} augments the context
   9.288 -  by assumptions @{text "As"} with export rule @{text "r"}.  The
   9.289 +  \<^descr> @{ML Assumption.add_assms}~\<open>r As\<close> augments the context
   9.290 +  by assumptions \<open>As\<close> with export rule \<open>r\<close>.  The
   9.291    resulting facts are hypothetical theorems as produced by the raw
   9.292    @{ML Assumption.assume}.
   9.293  
   9.294 -  \<^descr> @{ML Assumption.add_assumes}~@{text "As"} is a special case of
   9.295 -  @{ML Assumption.add_assms} where the export rule performs @{text
   9.296 -  "\<Longrightarrow>\<hyphen>intro"} or @{text "#\<Longrightarrow>\<hyphen>intro"}, depending on goal
   9.297 +  \<^descr> @{ML Assumption.add_assumes}~\<open>As\<close> is a special case of
   9.298 +  @{ML Assumption.add_assms} where the export rule performs \<open>\<Longrightarrow>\<hyphen>intro\<close> or \<open>#\<Longrightarrow>\<hyphen>intro\<close>, depending on goal
   9.299    mode.
   9.300  
   9.301 -  \<^descr> @{ML Assumption.export}~@{text "is_goal inner outer thm"}
   9.302 -  exports result @{text "thm"} from the the @{text "inner"} context
   9.303 -  back into the @{text "outer"} one; @{text "is_goal = true"} means
   9.304 +  \<^descr> @{ML Assumption.export}~\<open>is_goal inner outer thm\<close>
   9.305 +  exports result \<open>thm\<close> from the the \<open>inner\<close> context
   9.306 +  back into the \<open>outer\<close> one; \<open>is_goal = true\<close> means
   9.307    this is a goal context.  The result is in HHF normal form.  Note
   9.308    that @{ML "Proof_Context.export"} combines @{ML "Variable.export"}
   9.309    and @{ML "Assumption.export"} in the canonical way.
   9.310 @@ -344,25 +334,24 @@
   9.311  text \<open>
   9.312    Local results are established by monotonic reasoning from facts
   9.313    within a context.  This allows common combinations of theorems,
   9.314 -  e.g.\ via @{text "\<And>/\<Longrightarrow>"} elimination, resolution rules, or equational
   9.315 +  e.g.\ via \<open>\<And>/\<Longrightarrow>\<close> elimination, resolution rules, or equational
   9.316    reasoning, see \secref{sec:thms}.  Unaccounted context manipulations
   9.317 -  should be avoided, notably raw @{text "\<And>/\<Longrightarrow>"} introduction or ad-hoc
   9.318 +  should be avoided, notably raw \<open>\<And>/\<Longrightarrow>\<close> introduction or ad-hoc
   9.319    references to free variables or assumptions not present in the proof
   9.320    context.
   9.321  
   9.322    \<^medskip>
   9.323 -  The @{text "SUBPROOF"} combinator allows to structure a
   9.324 +  The \<open>SUBPROOF\<close> combinator allows to structure a
   9.325    tactical proof recursively by decomposing a selected sub-goal:
   9.326 -  @{text "(\<And>x. A(x) \<Longrightarrow> B(x)) \<Longrightarrow> \<dots>"} is turned into @{text "B(x) \<Longrightarrow> \<dots>"}
   9.327 -  after fixing @{text "x"} and assuming @{text "A(x)"}.  This means
   9.328 +  \<open>(\<And>x. A(x) \<Longrightarrow> B(x)) \<Longrightarrow> \<dots>\<close> is turned into \<open>B(x) \<Longrightarrow> \<dots>\<close>
   9.329 +  after fixing \<open>x\<close> and assuming \<open>A(x)\<close>.  This means
   9.330    the tactic needs to solve the conclusion, but may use the premise as
   9.331    a local fact, for locally fixed variables.
   9.332  
   9.333 -  The family of @{text "FOCUS"} combinators is similar to @{text
   9.334 -  "SUBPROOF"}, but allows to retain schematic variables and pending
   9.335 +  The family of \<open>FOCUS\<close> combinators is similar to \<open>SUBPROOF\<close>, but allows to retain schematic variables and pending
   9.336    subgoals in the resulting goal state.
   9.337  
   9.338 -  The @{text "prove"} operation provides an interface for structured
   9.339 +  The \<open>prove\<close> operation provides an interface for structured
   9.340    backwards reasoning under program control, with some explicit sanity
   9.341    checks of the result.  The goal context can be augmented by
   9.342    additional fixed variables (cf.\ \secref{sec:variables}) and
   9.343 @@ -371,7 +360,7 @@
   9.344    the result.  Type and term variables are generalized as usual,
   9.345    according to the context.
   9.346  
   9.347 -  The @{text "obtain"} operation produces results by eliminating
   9.348 +  The \<open>obtain\<close> operation produces results by eliminating
   9.349    existing facts by means of a given tactic.  This acts like a dual
   9.350    conclusion: the proof demonstrates that the context may be augmented
   9.351    by parameters and assumptions, without affecting any conclusions
   9.352 @@ -411,7 +400,7 @@
   9.353    Proof.context -> ((string * cterm) list * thm list) * Proof.context"} \\
   9.354    \end{mldecls}
   9.355  
   9.356 -  \<^descr> @{ML SUBPROOF}~@{text "tac ctxt i"} decomposes the structure
   9.357 +  \<^descr> @{ML SUBPROOF}~\<open>tac ctxt i\<close> decomposes the structure
   9.358    of the specified sub-goal, producing an extended context and a
   9.359    reduced goal, which needs to be solved by the given tactic.  All
   9.360    schematic parameters of the goal are imported into the context as
   9.361 @@ -429,13 +418,12 @@
   9.362    occasionally useful to experiment without writing actual tactics
   9.363    yet.
   9.364  
   9.365 -  \<^descr> @{ML Goal.prove}~@{text "ctxt xs As C tac"} states goal @{text
   9.366 -  "C"} in the context augmented by fixed variables @{text "xs"} and
   9.367 -  assumptions @{text "As"}, and applies tactic @{text "tac"} to solve
   9.368 +  \<^descr> @{ML Goal.prove}~\<open>ctxt xs As C tac\<close> states goal \<open>C\<close> in the context augmented by fixed variables \<open>xs\<close> and
   9.369 +  assumptions \<open>As\<close>, and applies tactic \<open>tac\<close> to solve
   9.370    it.  The latter may depend on the local assumptions being presented
   9.371    as facts.  The result is in HHF normal form.
   9.372  
   9.373 -  \<^descr> @{ML Goal.prove_common}~@{text "ctxt fork_pri"} is the common form
   9.374 +  \<^descr> @{ML Goal.prove_common}~\<open>ctxt fork_pri\<close> is the common form
   9.375    to state and prove a simultaneous goal statement, where @{ML Goal.prove}
   9.376    is a convenient shorthand that is most frequently used in applications.
   9.377  
   9.378 @@ -452,7 +440,7 @@
   9.379    transaction. Thus the system is able to expose error messages ultimately
   9.380    to the end-user, even though the subsequent ML code misses them.
   9.381  
   9.382 -  \<^descr> @{ML Obtain.result}~@{text "tac thms ctxt"} eliminates the
   9.383 +  \<^descr> @{ML Obtain.result}~\<open>tac thms ctxt\<close> eliminates the
   9.384    given facts using a tactic, which results in additional fixed
   9.385    variables and assumptions in the context.  Final results need to be
   9.386    exported explicitly.
    10.1 --- a/src/Doc/Implementation/Syntax.thy	Tue Oct 20 23:03:46 2015 +0200
    10.2 +++ b/src/Doc/Implementation/Syntax.thy	Tue Oct 20 23:53:40 2015 +0200
    10.3 @@ -6,7 +6,7 @@
    10.4  
    10.5  chapter \<open>Concrete syntax and type-checking\<close>
    10.6  
    10.7 -text \<open>Pure @{text "\<lambda>"}-calculus as introduced in \chref{ch:logic} is
    10.8 +text \<open>Pure \<open>\<lambda>\<close>-calculus as introduced in \chref{ch:logic} is
    10.9    an adequate foundation for logical languages --- in the tradition of
   10.10    \<^emph>\<open>higher-order abstract syntax\<close> --- but end-users require
   10.11    additional means for reading and printing of terms and types.  This
   10.12 @@ -15,12 +15,11 @@
   10.13    the theory and proof language @{cite "isabelle-isar-ref"}.
   10.14  
   10.15    For example, according to @{cite church40} quantifiers are represented as
   10.16 -  higher-order constants @{text "All :: ('a \<Rightarrow> bool) \<Rightarrow> bool"} such that @{text
   10.17 -  "All (\<lambda>x::'a. B x)"} faithfully represents the idea that is displayed in
   10.18 -  Isabelle as @{text "\<forall>x::'a. B x"} via @{keyword "binder"} notation.
   10.19 +  higher-order constants \<open>All :: ('a \<Rightarrow> bool) \<Rightarrow> bool\<close> such that \<open>All (\<lambda>x::'a. B x)\<close> faithfully represents the idea that is displayed in
   10.20 +  Isabelle as \<open>\<forall>x::'a. B x\<close> via @{keyword "binder"} notation.
   10.21    Moreover, type-inference in the style of Hindley-Milner @{cite hindleymilner}
   10.22 -  (and extensions) enables users to write @{text "\<forall>x. B x"} concisely, when
   10.23 -  the type @{text "'a"} is already clear from the
   10.24 +  (and extensions) enables users to write \<open>\<forall>x. B x\<close> concisely, when
   10.25 +  the type \<open>'a\<close> is already clear from the
   10.26    context.\footnote{Type-inference taken to the extreme can easily confuse
   10.27    users. Beginners often stumble over unexpectedly general types inferred by
   10.28    the system.}
   10.29 @@ -36,22 +35,21 @@
   10.30    \secref{sec:term-check}, respectively.  This results in the
   10.31    following decomposition of the main operations:
   10.32  
   10.33 -  \<^item> @{text "read = parse; check"}
   10.34 +  \<^item> \<open>read = parse; check\<close>
   10.35  
   10.36 -  \<^item> @{text "pretty = uncheck; unparse"}
   10.37 +  \<^item> \<open>pretty = uncheck; unparse\<close>
   10.38  
   10.39  
   10.40    For example, some specification package might thus intercept syntax
   10.41 -  processing at a well-defined stage after @{text "parse"}, to a augment the
   10.42 -  resulting pre-term before full type-reconstruction is performed by @{text
   10.43 -  "check"}. Note that the formal status of bound variables, versus free
   10.44 +  processing at a well-defined stage after \<open>parse\<close>, to a augment the
   10.45 +  resulting pre-term before full type-reconstruction is performed by \<open>check\<close>. Note that the formal status of bound variables, versus free
   10.46    variables, versus constants must not be changed between these phases.
   10.47  
   10.48    \<^medskip>
   10.49 -  In general, @{text check} and @{text uncheck} operate
   10.50 +  In general, \<open>check\<close> and \<open>uncheck\<close> operate
   10.51    simultaneously on a list of terms. This is particular important for
   10.52    type-checking, to reconstruct types for several terms of the same context
   10.53 -  and scope. In contrast, @{text parse} and @{text unparse} operate separately
   10.54 +  and scope. In contrast, \<open>parse\<close> and \<open>unparse\<close> operate separately
   10.55    on single terms.
   10.56  
   10.57    There are analogous operations to read and print types, with the same
   10.58 @@ -63,11 +61,10 @@
   10.59  
   10.60  text \<open>
   10.61    Read and print operations are roughly dual to each other, such that for the
   10.62 -  user @{text "s' = pretty (read s)"} looks similar to the original source
   10.63 -  text @{text "s"}, but the details depend on many side-conditions. There are
   10.64 +  user \<open>s' = pretty (read s)\<close> looks similar to the original source
   10.65 +  text \<open>s\<close>, but the details depend on many side-conditions. There are
   10.66    also explicit options to control the removal of type information in the
   10.67 -  output. The default configuration routinely looses information, so @{text
   10.68 -  "t' = read (pretty t)"} might fail, or produce a differently typed term, or
   10.69 +  output. The default configuration routinely looses information, so \<open>t' = read (pretty t)\<close> might fail, or produce a differently typed term, or
   10.70    a completely different term in the face of syntactic overloading.
   10.71  \<close>
   10.72  
   10.73 @@ -85,10 +82,10 @@
   10.74    @{index_ML Syntax.string_of_term: "Proof.context -> term -> string"} \\
   10.75    \end{mldecls}
   10.76  
   10.77 -  \<^descr> @{ML Syntax.read_typs}~@{text "ctxt strs"} parses and checks a
   10.78 +  \<^descr> @{ML Syntax.read_typs}~\<open>ctxt strs\<close> parses and checks a
   10.79    simultaneous list of source strings as types of the logic.
   10.80  
   10.81 -  \<^descr> @{ML Syntax.read_terms}~@{text "ctxt strs"} parses and checks a
   10.82 +  \<^descr> @{ML Syntax.read_terms}~\<open>ctxt strs\<close> parses and checks a
   10.83    simultaneous list of source strings as terms of the logic.
   10.84    Type-reconstruction puts all parsed terms into the same scope: types of
   10.85    free variables ultimately need to coincide.
   10.86 @@ -98,7 +95,7 @@
   10.87    is possible to use @{ML Type.constraint} on the intermediate pre-terms
   10.88    (\secref{sec:term-check}).
   10.89  
   10.90 -  \<^descr> @{ML Syntax.read_props}~@{text "ctxt strs"} parses and checks a
   10.91 +  \<^descr> @{ML Syntax.read_props}~\<open>ctxt strs\<close> parses and checks a
   10.92    simultaneous list of source strings as terms of the logic, with an implicit
   10.93    type-constraint for each argument to enforce type @{typ prop}; this also
   10.94    affects the inner syntax for parsing. The remaining type-reconstruction
   10.95 @@ -110,8 +107,8 @@
   10.96    its own scope is processed. Do not use @{ML "map o Syntax.read_term"} where
   10.97    @{ML Syntax.read_terms} is actually intended!
   10.98  
   10.99 -  \<^descr> @{ML Syntax.pretty_typ}~@{text "ctxt T"} and @{ML
  10.100 -  Syntax.pretty_term}~@{text "ctxt t"} uncheck and pretty-print the given type
  10.101 +  \<^descr> @{ML Syntax.pretty_typ}~\<open>ctxt T\<close> and @{ML
  10.102 +  Syntax.pretty_term}~\<open>ctxt t\<close> uncheck and pretty-print the given type
  10.103    or term, respectively. Although the uncheck phase acts on a simultaneous
  10.104    list as well, this is rarely used in practice, so only the singleton case is
  10.105    provided as combined pretty operation. There is no distinction of term vs.\
  10.106 @@ -173,22 +170,22 @@
  10.107    @{index_ML Syntax.unparse_term: "Proof.context -> term -> Pretty.T"} \\
  10.108    \end{mldecls}
  10.109  
  10.110 -  \<^descr> @{ML Syntax.parse_typ}~@{text "ctxt str"} parses a source string as
  10.111 +  \<^descr> @{ML Syntax.parse_typ}~\<open>ctxt str\<close> parses a source string as
  10.112    pre-type that is ready to be used with subsequent check operations.
  10.113  
  10.114 -  \<^descr> @{ML Syntax.parse_term}~@{text "ctxt str"} parses a source string as
  10.115 +  \<^descr> @{ML Syntax.parse_term}~\<open>ctxt str\<close> parses a source string as
  10.116    pre-term that is ready to be used with subsequent check operations.
  10.117  
  10.118 -  \<^descr> @{ML Syntax.parse_prop}~@{text "ctxt str"} parses a source string as
  10.119 +  \<^descr> @{ML Syntax.parse_prop}~\<open>ctxt str\<close> parses a source string as
  10.120    pre-term that is ready to be used with subsequent check operations. The
  10.121    inner syntax category is @{typ prop} and a suitable type-constraint is
  10.122    included to ensure that this information is observed in subsequent type
  10.123    reconstruction.
  10.124  
  10.125 -  \<^descr> @{ML Syntax.unparse_typ}~@{text "ctxt T"} unparses a type after
  10.126 +  \<^descr> @{ML Syntax.unparse_typ}~\<open>ctxt T\<close> unparses a type after
  10.127    uncheck operations, to turn it into a pretty tree.
  10.128  
  10.129 -  \<^descr> @{ML Syntax.unparse_term}~@{text "ctxt T"} unparses a term after
  10.130 +  \<^descr> @{ML Syntax.unparse_term}~\<open>ctxt T\<close> unparses a term after
  10.131    uncheck operations, to turn it into a pretty tree. There is no distinction
  10.132    for propositions here.
  10.133  
  10.134 @@ -212,9 +209,8 @@
  10.135  
  10.136    A typical add-on for the check/uncheck syntax layer is the @{command
  10.137    abbreviation} mechanism @{cite "isabelle-isar-ref"}. Here the user specifies
  10.138 -  syntactic definitions that are managed by the system as polymorphic @{text
  10.139 -  "let"} bindings. These are expanded during the @{text "check"} phase, and
  10.140 -  contracted during the @{text "uncheck"} phase, without affecting the
  10.141 +  syntactic definitions that are managed by the system as polymorphic \<open>let\<close> bindings. These are expanded during the \<open>check\<close> phase, and
  10.142 +  contracted during the \<open>uncheck\<close> phase, without affecting the
  10.143    type-assignment of the given terms.
  10.144  
  10.145    \<^medskip>
  10.146 @@ -222,7 +218,7 @@
  10.147    additional check/uncheck modules might be defined in user space.
  10.148  
  10.149    For example, the @{command class} command defines a context where
  10.150 -  @{text "check"} treats certain type instances of overloaded
  10.151 +  \<open>check\<close> treats certain type instances of overloaded
  10.152    constants according to the ``dictionary construction'' of its
  10.153    logical foundation.  This involves ``type improvement''
  10.154    (specialization of slightly too general types) and replacement by
  10.155 @@ -238,11 +234,11 @@
  10.156    @{index_ML Syntax.uncheck_terms: "Proof.context -> term list -> term list"} \\
  10.157    \end{mldecls}
  10.158  
  10.159 -  \<^descr> @{ML Syntax.check_typs}~@{text "ctxt Ts"} checks a simultaneous list
  10.160 +  \<^descr> @{ML Syntax.check_typs}~\<open>ctxt Ts\<close> checks a simultaneous list
  10.161    of pre-types as types of the logic.  Typically, this involves normalization
  10.162    of type synonyms.
  10.163  
  10.164 -  \<^descr> @{ML Syntax.check_terms}~@{text "ctxt ts"} checks a simultaneous list
  10.165 +  \<^descr> @{ML Syntax.check_terms}~\<open>ctxt ts\<close> checks a simultaneous list
  10.166    of pre-terms as terms of the logic. Typically, this involves type-inference
  10.167    and normalization term abbreviations. The types within the given terms are
  10.168    treated in the same way as for @{ML Syntax.check_typs}.
  10.169 @@ -253,15 +249,15 @@
  10.170    is checked; afterwards the type arguments are recovered with @{ML
  10.171    Logic.dest_type}.
  10.172  
  10.173 -  \<^descr> @{ML Syntax.check_props}~@{text "ctxt ts"} checks a simultaneous list
  10.174 +  \<^descr> @{ML Syntax.check_props}~\<open>ctxt ts\<close> checks a simultaneous list
  10.175    of pre-terms as terms of the logic, such that all terms are constrained by
  10.176    type @{typ prop}. The remaining check operation works as @{ML
  10.177    Syntax.check_terms} above.
  10.178  
  10.179 -  \<^descr> @{ML Syntax.uncheck_typs}~@{text "ctxt Ts"} unchecks a simultaneous
  10.180 +  \<^descr> @{ML Syntax.uncheck_typs}~\<open>ctxt Ts\<close> unchecks a simultaneous
  10.181    list of types of the logic, in preparation of pretty printing.
  10.182  
  10.183 -  \<^descr> @{ML Syntax.uncheck_terms}~@{text "ctxt ts"} unchecks a simultaneous
  10.184 +  \<^descr> @{ML Syntax.uncheck_terms}~\<open>ctxt ts\<close> unchecks a simultaneous
  10.185    list of terms of the logic, in preparation of pretty printing. There is no
  10.186    distinction for propositions here.
  10.187  
    11.1 --- a/src/Doc/Implementation/Tactic.thy	Tue Oct 20 23:03:46 2015 +0200
    11.2 +++ b/src/Doc/Implementation/Tactic.thy	Tue Oct 20 23:53:40 2015 +0200
    11.3 @@ -5,40 +5,36 @@
    11.4  chapter \<open>Tactical reasoning\<close>
    11.5  
    11.6  text \<open>Tactical reasoning works by refining an initial claim in a
    11.7 -  backwards fashion, until a solved form is reached.  A @{text "goal"}
    11.8 +  backwards fashion, until a solved form is reached.  A \<open>goal\<close>
    11.9    consists of several subgoals that need to be solved in order to
   11.10    achieve the main statement; zero subgoals means that the proof may
   11.11 -  be finished.  A @{text "tactic"} is a refinement operation that maps
   11.12 -  a goal to a lazy sequence of potential successors.  A @{text
   11.13 -  "tactical"} is a combinator for composing tactics.\<close>
   11.14 +  be finished.  A \<open>tactic\<close> is a refinement operation that maps
   11.15 +  a goal to a lazy sequence of potential successors.  A \<open>tactical\<close> is a combinator for composing tactics.\<close>
   11.16  
   11.17  
   11.18  section \<open>Goals \label{sec:tactical-goals}\<close>
   11.19  
   11.20  text \<open>
   11.21    Isabelle/Pure represents a goal as a theorem stating that the
   11.22 -  subgoals imply the main goal: @{text "A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow>
   11.23 -  C"}.  The outermost goal structure is that of a Horn Clause: i.e.\
   11.24 +  subgoals imply the main goal: \<open>A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow>
   11.25 +  C\<close>.  The outermost goal structure is that of a Horn Clause: i.e.\
   11.26    an iterated implication without any quantifiers\footnote{Recall that
   11.27 -  outermost @{text "\<And>x. \<phi>[x]"} is always represented via schematic
   11.28 -  variables in the body: @{text "\<phi>[?x]"}.  These variables may get
   11.29 -  instantiated during the course of reasoning.}.  For @{text "n = 0"}
   11.30 +  outermost \<open>\<And>x. \<phi>[x]\<close> is always represented via schematic
   11.31 +  variables in the body: \<open>\<phi>[?x]\<close>.  These variables may get
   11.32 +  instantiated during the course of reasoning.}.  For \<open>n = 0\<close>
   11.33    a goal is called ``solved''.
   11.34  
   11.35 -  The structure of each subgoal @{text "A\<^sub>i"} is that of a
   11.36 -  general Hereditary Harrop Formula @{text "\<And>x\<^sub>1 \<dots>
   11.37 -  \<And>x\<^sub>k. H\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> H\<^sub>m \<Longrightarrow> B"}.  Here @{text
   11.38 -  "x\<^sub>1, \<dots>, x\<^sub>k"} are goal parameters, i.e.\
   11.39 -  arbitrary-but-fixed entities of certain types, and @{text
   11.40 -  "H\<^sub>1, \<dots>, H\<^sub>m"} are goal hypotheses, i.e.\ facts that may
   11.41 +  The structure of each subgoal \<open>A\<^sub>i\<close> is that of a
   11.42 +  general Hereditary Harrop Formula \<open>\<And>x\<^sub>1 \<dots>
   11.43 +  \<And>x\<^sub>k. H\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> H\<^sub>m \<Longrightarrow> B\<close>.  Here \<open>x\<^sub>1, \<dots>, x\<^sub>k\<close> are goal parameters, i.e.\
   11.44 +  arbitrary-but-fixed entities of certain types, and \<open>H\<^sub>1, \<dots>, H\<^sub>m\<close> are goal hypotheses, i.e.\ facts that may
   11.45    be assumed locally.  Together, this forms the goal context of the
   11.46 -  conclusion @{text B} to be established.  The goal hypotheses may be
   11.47 +  conclusion \<open>B\<close> to be established.  The goal hypotheses may be
   11.48    again arbitrary Hereditary Harrop Formulas, although the level of
   11.49    nesting rarely exceeds 1--2 in practice.
   11.50  
   11.51 -  The main conclusion @{text C} is internally marked as a protected
   11.52 -  proposition, which is represented explicitly by the notation @{text
   11.53 -  "#C"} here.  This ensures that the decomposition into subgoals and
   11.54 +  The main conclusion \<open>C\<close> is internally marked as a protected
   11.55 +  proposition, which is represented explicitly by the notation \<open>#C\<close> here.  This ensures that the decomposition into subgoals and
   11.56    main conclusion is well-defined for arbitrarily structured claims.
   11.57  
   11.58    \<^medskip>
   11.59 @@ -46,8 +42,8 @@
   11.60    Isabelle/Pure rules:
   11.61  
   11.62    \[
   11.63 -  \infer[@{text "(init)"}]{@{text "C \<Longrightarrow> #C"}}{} \qquad
   11.64 -  \infer[@{text "(finish)"}]{@{text "C"}}{@{text "#C"}}
   11.65 +  \infer[\<open>(init)\<close>]{\<open>C \<Longrightarrow> #C\<close>}{} \qquad
   11.66 +  \infer[\<open>(finish)\<close>]{\<open>C\<close>}{\<open>#C\<close>}
   11.67    \]
   11.68  
   11.69    \<^medskip>
   11.70 @@ -55,10 +51,10 @@
   11.71    with protected propositions:
   11.72  
   11.73    \[
   11.74 -  \infer[@{text "(protect n)"}]{@{text "A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> #C"}}{@{text "A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> C"}}
   11.75 +  \infer[\<open>(protect n)\<close>]{\<open>A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> #C\<close>}{\<open>A\<^sub>1 \<Longrightarrow> \<dots> \<Longrightarrow> A\<^sub>n \<Longrightarrow> C\<close>}
   11.76    \]
   11.77    \[
   11.78 -  \infer[@{text "(conclude)"}]{@{text "A \<Longrightarrow> \<dots> \<Longrightarrow> C"}}{@{text "A \<Longrightarrow> \<dots> \<Longrightarrow> #C"}}
   11.79 +  \infer[\<open>(conclude)\<close>]{\<open>A \<Longrightarrow> \<dots> \<Longrightarrow> C\<close>}{\<open>A \<Longrightarrow> \<dots> \<Longrightarrow> #C\<close>}
   11.80    \]
   11.81  \<close>
   11.82  
   11.83 @@ -70,26 +66,26 @@
   11.84    @{index_ML Goal.conclude: "thm -> thm"} \\
   11.85    \end{mldecls}
   11.86  
   11.87 -  \<^descr> @{ML "Goal.init"}~@{text C} initializes a tactical goal from
   11.88 -  the well-formed proposition @{text C}.
   11.89 +  \<^descr> @{ML "Goal.init"}~\<open>C\<close> initializes a tactical goal from
   11.90 +  the well-formed proposition \<open>C\<close>.
   11.91  
   11.92 -  \<^descr> @{ML "Goal.finish"}~@{text "ctxt thm"} checks whether theorem
   11.93 -  @{text "thm"} is a solved goal (no subgoals), and concludes the
   11.94 +  \<^descr> @{ML "Goal.finish"}~\<open>ctxt thm\<close> checks whether theorem
   11.95 +  \<open>thm\<close> is a solved goal (no subgoals), and concludes the
   11.96    result by removing the goal protection.  The context is only
   11.97    required for printing error messages.
   11.98  
   11.99 -  \<^descr> @{ML "Goal.protect"}~@{text "n thm"} protects the statement
  11.100 -  of theorem @{text "thm"}.  The parameter @{text n} indicates the
  11.101 +  \<^descr> @{ML "Goal.protect"}~\<open>n thm\<close> protects the statement
  11.102 +  of theorem \<open>thm\<close>.  The parameter \<open>n\<close> indicates the
  11.103    number of premises to be retained.
  11.104  
  11.105 -  \<^descr> @{ML "Goal.conclude"}~@{text "thm"} removes the goal
  11.106 +  \<^descr> @{ML "Goal.conclude"}~\<open>thm\<close> removes the goal
  11.107    protection, even if there are pending subgoals.
  11.108  \<close>
  11.109  
  11.110  
  11.111  section \<open>Tactics\label{sec:tactics}\<close>
  11.112  
  11.113 -text \<open>A @{text "tactic"} is a function @{text "goal \<rightarrow> goal\<^sup>*\<^sup>*"} that
  11.114 +text \<open>A \<open>tactic\<close> is a function \<open>goal \<rightarrow> goal\<^sup>*\<^sup>*\<close> that
  11.115    maps a given goal state (represented as a theorem, cf.\
  11.116    \secref{sec:tactical-goals}) to a lazy sequence of potential
  11.117    successor states.  The underlying sequence implementation is lazy
  11.118 @@ -121,7 +117,7 @@
  11.119    schematic goal variables).
  11.120  
  11.121    Tactics with explicit \<^emph>\<open>subgoal addressing\<close> are of the form
  11.122 -  @{text "int \<rightarrow> tactic"} and may be applied to a particular subgoal
  11.123 +  \<open>int \<rightarrow> tactic\<close> and may be applied to a particular subgoal
  11.124    (counting from 1).  If the subgoal number is out of range, the
  11.125    tactic should fail with an empty result sequence, but must not raise
  11.126    an exception!
  11.127 @@ -139,7 +135,7 @@
  11.128    very common error when implementing tactics!
  11.129  
  11.130    Tactics with internal subgoal addressing should expose the subgoal
  11.131 -  index as @{text "int"} argument in full generality; a hardwired
  11.132 +  index as \<open>int\<close> argument in full generality; a hardwired
  11.133    subgoal 1 is not acceptable.
  11.134    
  11.135    \<^medskip>
  11.136 @@ -195,16 +191,16 @@
  11.137    \<^descr> @{ML all_tac} is a tactic that always succeeds, returning a
  11.138    singleton sequence with unchanged goal state.
  11.139  
  11.140 -  \<^descr> @{ML print_tac}~@{text "ctxt message"} is like @{ML all_tac}, but
  11.141 +  \<^descr> @{ML print_tac}~\<open>ctxt message\<close> is like @{ML all_tac}, but
  11.142    prints a message together with the goal state on the tracing
  11.143    channel.
  11.144  
  11.145 -  \<^descr> @{ML PRIMITIVE}~@{text rule} turns a primitive inference rule
  11.146 +  \<^descr> @{ML PRIMITIVE}~\<open>rule\<close> turns a primitive inference rule
  11.147    into a tactic with unique result.  Exception @{ML THM} is considered
  11.148    a regular tactic failure and produces an empty result; other
  11.149    exceptions are passed through.
  11.150  
  11.151 -  \<^descr> @{ML SUBGOAL}~@{text "(fn (subgoal, i) => tactic)"} is the
  11.152 +  \<^descr> @{ML SUBGOAL}~\<open>(fn (subgoal, i) => tactic)\<close> is the
  11.153    most basic form to produce a tactic with subgoal addressing.  The
  11.154    given abstraction over the subgoal term and subgoal number allows to
  11.155    peek at the relevant information of the full goal state.  The
  11.156 @@ -215,14 +211,14 @@
  11.157    avoids expensive re-certification in situations where the subgoal is
  11.158    used directly for primitive inferences.
  11.159  
  11.160 -  \<^descr> @{ML SELECT_GOAL}~@{text "tac i"} confines a tactic to the
  11.161 -  specified subgoal @{text "i"}.  This rearranges subgoals and the
  11.162 +  \<^descr> @{ML SELECT_GOAL}~\<open>tac i\<close> confines a tactic to the
  11.163 +  specified subgoal \<open>i\<close>.  This rearranges subgoals and the
  11.164    main goal protection (\secref{sec:tactical-goals}), while retaining
  11.165    the syntactic context of the overall goal state (concerning
  11.166    schematic variables etc.).
  11.167  
  11.168 -  \<^descr> @{ML PREFER_GOAL}~@{text "tac i"} rearranges subgoals to put
  11.169 -  @{text "i"} in front.  This is similar to @{ML SELECT_GOAL}, but
  11.170 +  \<^descr> @{ML PREFER_GOAL}~\<open>tac i\<close> rearranges subgoals to put
  11.171 +  \<open>i\<close> in front.  This is similar to @{ML SELECT_GOAL}, but
  11.172    without changing the main goal protection.
  11.173  \<close>
  11.174  
  11.175 @@ -237,7 +233,7 @@
  11.176    \<^emph>\<open>Destruct-resolution\<close> is like elim-resolution, but the given
  11.177    destruction rules are first turned into canonical elimination
  11.178    format.  \<^emph>\<open>Forward-resolution\<close> is like destruct-resolution, but
  11.179 -  without deleting the selected assumption.  The @{text "r/e/d/f"}
  11.180 +  without deleting the selected assumption.  The \<open>r/e/d/f\<close>
  11.181    naming convention is maintained for several different kinds of
  11.182    resolution rules and tactics.
  11.183  
  11.184 @@ -281,20 +277,19 @@
  11.185    @{index_ML bimatch_tac: "Proof.context -> (bool * thm) list -> int -> tactic"} \\
  11.186    \end{mldecls}
  11.187  
  11.188 -  \<^descr> @{ML resolve_tac}~@{text "ctxt thms i"} refines the goal state
  11.189 +  \<^descr> @{ML resolve_tac}~\<open>ctxt thms i\<close> refines the goal state
  11.190    using the given theorems, which should normally be introduction
  11.191 -  rules.  The tactic resolves a rule's conclusion with subgoal @{text
  11.192 -  i}, replacing it by the corresponding versions of the rule's
  11.193 +  rules.  The tactic resolves a rule's conclusion with subgoal \<open>i\<close>, replacing it by the corresponding versions of the rule's
  11.194    premises.
  11.195  
  11.196 -  \<^descr> @{ML eresolve_tac}~@{text "ctxt thms i"} performs elim-resolution
  11.197 +  \<^descr> @{ML eresolve_tac}~\<open>ctxt thms i\<close> performs elim-resolution
  11.198    with the given theorems, which are normally be elimination rules.
  11.199  
  11.200    Note that @{ML_text "eresolve_tac ctxt [asm_rl]"} is equivalent to @{ML_text
  11.201    "assume_tac ctxt"}, which facilitates mixing of assumption steps with
  11.202    genuine eliminations.
  11.203  
  11.204 -  \<^descr> @{ML dresolve_tac}~@{text "ctxt thms i"} performs
  11.205 +  \<^descr> @{ML dresolve_tac}~\<open>ctxt thms i\<close> performs
  11.206    destruct-resolution with the given theorems, which should normally
  11.207    be destruction rules.  This replaces an assumption by the result of
  11.208    applying one of the rules.
  11.209 @@ -303,21 +298,20 @@
  11.210    selected assumption is not deleted.  It applies a rule to an
  11.211    assumption, adding the result as a new assumption.
  11.212  
  11.213 -  \<^descr> @{ML biresolve_tac}~@{text "ctxt brls i"} refines the proof state
  11.214 +  \<^descr> @{ML biresolve_tac}~\<open>ctxt brls i\<close> refines the proof state
  11.215    by resolution or elim-resolution on each rule, as indicated by its
  11.216 -  flag.  It affects subgoal @{text "i"} of the proof state.
  11.217 +  flag.  It affects subgoal \<open>i\<close> of the proof state.
  11.218  
  11.219 -  For each pair @{text "(flag, rule)"}, it applies resolution if the
  11.220 -  flag is @{text "false"} and elim-resolution if the flag is @{text
  11.221 -  "true"}.  A single tactic call handles a mixture of introduction and
  11.222 +  For each pair \<open>(flag, rule)\<close>, it applies resolution if the
  11.223 +  flag is \<open>false\<close> and elim-resolution if the flag is \<open>true\<close>.  A single tactic call handles a mixture of introduction and
  11.224    elimination rules, which is useful to organize the search process
  11.225    systematically in proof tools.
  11.226  
  11.227 -  \<^descr> @{ML assume_tac}~@{text "ctxt i"} attempts to solve subgoal @{text i}
  11.228 +  \<^descr> @{ML assume_tac}~\<open>ctxt i\<close> attempts to solve subgoal \<open>i\<close>
  11.229    by assumption (modulo higher-order unification).
  11.230  
  11.231    \<^descr> @{ML eq_assume_tac} is similar to @{ML assume_tac}, but checks
  11.232 -  only for immediate @{text "\<alpha>"}-convertibility instead of using
  11.233 +  only for immediate \<open>\<alpha>\<close>-convertibility instead of using
  11.234    unification.  It succeeds (with a unique next state) if one of the
  11.235    assumptions is equal to the subgoal's conclusion.  Since it does not
  11.236    instantiate variables, it cannot make other subgoals unprovable.
  11.237 @@ -346,25 +340,22 @@
  11.238    higher-order unification is not so useful.  This typically involves
  11.239    rules like universal elimination, existential introduction, or
  11.240    equational substitution.  Here the unification problem involves
  11.241 -  fully flexible @{text "?P ?x"} schemes, which are hard to manage
  11.242 +  fully flexible \<open>?P ?x\<close> schemes, which are hard to manage
  11.243    without further hints.
  11.244  
  11.245 -  By providing a (small) rigid term for @{text "?x"} explicitly, the
  11.246 -  remaining unification problem is to assign a (large) term to @{text
  11.247 -  "?P"}, according to the shape of the given subgoal.  This is
  11.248 +  By providing a (small) rigid term for \<open>?x\<close> explicitly, the
  11.249 +  remaining unification problem is to assign a (large) term to \<open>?P\<close>, according to the shape of the given subgoal.  This is
  11.250    sufficiently well-behaved in most practical situations.
  11.251  
  11.252    \<^medskip>
  11.253 -  Isabelle provides separate versions of the standard @{text
  11.254 -  "r/e/d/f"} resolution tactics that allow to provide explicit
  11.255 +  Isabelle provides separate versions of the standard \<open>r/e/d/f\<close> resolution tactics that allow to provide explicit
  11.256    instantiations of unknowns of the given rule, wrt.\ terms that refer
  11.257    to the implicit context of the selected subgoal.
  11.258  
  11.259 -  An instantiation consists of a list of pairs of the form @{text
  11.260 -  "(?x, t)"}, where @{text ?x} is a schematic variable occurring in
  11.261 -  the given rule, and @{text t} is a term from the current proof
  11.262 +  An instantiation consists of a list of pairs of the form \<open>(?x, t)\<close>, where \<open>?x\<close> is a schematic variable occurring in
  11.263 +  the given rule, and \<open>t\<close> is a term from the current proof
  11.264    context, augmented by the local goal parameters of the selected
  11.265 -  subgoal; cf.\ the @{text "focus"} operation described in
  11.266 +  subgoal; cf.\ the \<open>focus\<close> operation described in
  11.267    \secref{sec:variables}.
  11.268  
  11.269    Entering the syntactic context of a subgoal is a brittle operation,
  11.270 @@ -373,8 +364,7 @@
  11.271    global names.  Explicit renaming of subgoal parameters prior to
  11.272    explicit instantiation might help to achieve a bit more robustness.
  11.273  
  11.274 -  Type instantiations may be given as well, via pairs like @{text
  11.275 -  "(?'a, \<tau>)"}.  Type instantiations are distinguished from term
  11.276 +  Type instantiations may be given as well, via pairs like \<open>(?'a, \<tau>)\<close>.  Type instantiations are distinguished from term
  11.277    instantiations by the syntactic form of the schematic variable.
  11.278    Types are instantiated before terms are.  Since term instantiation
  11.279    already performs simple type-inference, so explicit type
  11.280 @@ -402,9 +392,9 @@
  11.281    @{index_ML rename_tac: "string list -> int -> tactic"} \\
  11.282    \end{mldecls}
  11.283  
  11.284 -  \<^descr> @{ML Rule_Insts.res_inst_tac}~@{text "ctxt insts thm i"} instantiates the
  11.285 -  rule @{text thm} with the instantiations @{text insts}, as described
  11.286 -  above, and then performs resolution on subgoal @{text i}.
  11.287 +  \<^descr> @{ML Rule_Insts.res_inst_tac}~\<open>ctxt insts thm i\<close> instantiates the
  11.288 +  rule \<open>thm\<close> with the instantiations \<open>insts\<close>, as described
  11.289 +  above, and then performs resolution on subgoal \<open>i\<close>.
  11.290    
  11.291    \<^descr> @{ML Rule_Insts.eres_inst_tac} is like @{ML Rule_Insts.res_inst_tac},
  11.292    but performs elim-resolution.
  11.293 @@ -415,20 +405,19 @@
  11.294    \<^descr> @{ML Rule_Insts.forw_inst_tac} is like @{ML Rule_Insts.dres_inst_tac}
  11.295    except that the selected assumption is not deleted.
  11.296  
  11.297 -  \<^descr> @{ML Rule_Insts.subgoal_tac}~@{text "ctxt \<phi> i"} adds the proposition
  11.298 -  @{text "\<phi>"} as local premise to subgoal @{text "i"}, and poses the
  11.299 -  same as a new subgoal @{text "i + 1"} (in the original context).
  11.300 +  \<^descr> @{ML Rule_Insts.subgoal_tac}~\<open>ctxt \<phi> i\<close> adds the proposition
  11.301 +  \<open>\<phi>\<close> as local premise to subgoal \<open>i\<close>, and poses the
  11.302 +  same as a new subgoal \<open>i + 1\<close> (in the original context).
  11.303  
  11.304 -  \<^descr> @{ML Rule_Insts.thin_tac}~@{text "ctxt \<phi> i"} deletes the specified
  11.305 -  premise from subgoal @{text i}.  Note that @{text \<phi>} may contain
  11.306 +  \<^descr> @{ML Rule_Insts.thin_tac}~\<open>ctxt \<phi> i\<close> deletes the specified
  11.307 +  premise from subgoal \<open>i\<close>.  Note that \<open>\<phi>\<close> may contain
  11.308    schematic variables, to abbreviate the intended proposition; the
  11.309    first matching subgoal premise will be deleted.  Removing useless
  11.310    premises from a subgoal increases its readability and can make
  11.311    search tactics run faster.
  11.312  
  11.313 -  \<^descr> @{ML rename_tac}~@{text "names i"} renames the innermost
  11.314 -  parameters of subgoal @{text i} according to the provided @{text
  11.315 -  names} (which need to be distinct identifiers).
  11.316 +  \<^descr> @{ML rename_tac}~\<open>names i\<close> renames the innermost
  11.317 +  parameters of subgoal \<open>i\<close> according to the provided \<open>names\<close> (which need to be distinct identifiers).
  11.318  
  11.319  
  11.320    For historical reasons, the above instantiation tactics take
  11.321 @@ -453,9 +442,9 @@
  11.322    @{index_ML flexflex_tac: "Proof.context -> tactic"} \\
  11.323    \end{mldecls}
  11.324  
  11.325 -  \<^descr> @{ML rotate_tac}~@{text "n i"} rotates the premises of subgoal
  11.326 -  @{text i} by @{text n} positions: from right to left if @{text n} is
  11.327 -  positive, and from left to right if @{text n} is negative.
  11.328 +  \<^descr> @{ML rotate_tac}~\<open>n i\<close> rotates the premises of subgoal
  11.329 +  \<open>i\<close> by \<open>n\<close> positions: from right to left if \<open>n\<close> is
  11.330 +  positive, and from left to right if \<open>n\<close> is negative.
  11.331  
  11.332    \<^descr> @{ML distinct_subgoals_tac} removes duplicate subgoals from a
  11.333    proof state.  This is potentially inefficient.
  11.334 @@ -489,24 +478,21 @@
  11.335    @{index_ML_op COMP: "thm * thm -> thm"} \\
  11.336    \end{mldecls}
  11.337  
  11.338 -  \<^descr> @{ML compose_tac}~@{text "ctxt (flag, rule, m) i"} refines subgoal
  11.339 -  @{text "i"} using @{text "rule"}, without lifting.  The @{text
  11.340 -  "rule"} is taken to have the form @{text "\<psi>\<^sub>1 \<Longrightarrow> \<dots> \<psi>\<^sub>m \<Longrightarrow> \<psi>"}, where
  11.341 -  @{text "\<psi>"} need not be atomic; thus @{text "m"} determines the
  11.342 -  number of new subgoals.  If @{text "flag"} is @{text "true"} then it
  11.343 -  performs elim-resolution --- it solves the first premise of @{text
  11.344 -  "rule"} by assumption and deletes that assumption.
  11.345 +  \<^descr> @{ML compose_tac}~\<open>ctxt (flag, rule, m) i\<close> refines subgoal
  11.346 +  \<open>i\<close> using \<open>rule\<close>, without lifting.  The \<open>rule\<close> is taken to have the form \<open>\<psi>\<^sub>1 \<Longrightarrow> \<dots> \<psi>\<^sub>m \<Longrightarrow> \<psi>\<close>, where
  11.347 +  \<open>\<psi>\<close> need not be atomic; thus \<open>m\<close> determines the
  11.348 +  number of new subgoals.  If \<open>flag\<close> is \<open>true\<close> then it
  11.349 +  performs elim-resolution --- it solves the first premise of \<open>rule\<close> by assumption and deletes that assumption.
  11.350  
  11.351 -  \<^descr> @{ML Drule.compose}~@{text "(thm\<^sub>1, i, thm\<^sub>2)"} uses @{text "thm\<^sub>1"},
  11.352 -  regarded as an atomic formula, to solve premise @{text "i"} of
  11.353 -  @{text "thm\<^sub>2"}.  Let @{text "thm\<^sub>1"} and @{text "thm\<^sub>2"} be @{text
  11.354 -  "\<psi>"} and @{text "\<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<phi>"}.  The unique @{text "s"} that
  11.355 -  unifies @{text "\<psi>"} and @{text "\<phi>\<^sub>i"} yields the theorem @{text "(\<phi>\<^sub>1 \<Longrightarrow>
  11.356 -  \<dots> \<phi>\<^sub>i\<^sub>-\<^sub>1 \<Longrightarrow> \<phi>\<^sub>i\<^sub>+\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<phi>)s"}.  Multiple results are considered as
  11.357 +  \<^descr> @{ML Drule.compose}~\<open>(thm\<^sub>1, i, thm\<^sub>2)\<close> uses \<open>thm\<^sub>1\<close>,
  11.358 +  regarded as an atomic formula, to solve premise \<open>i\<close> of
  11.359 +  \<open>thm\<^sub>2\<close>.  Let \<open>thm\<^sub>1\<close> and \<open>thm\<^sub>2\<close> be \<open>\<psi>\<close> and \<open>\<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<phi>\<close>.  The unique \<open>s\<close> that
  11.360 +  unifies \<open>\<psi>\<close> and \<open>\<phi>\<^sub>i\<close> yields the theorem \<open>(\<phi>\<^sub>1 \<Longrightarrow>
  11.361 +  \<dots> \<phi>\<^sub>i\<^sub>-\<^sub>1 \<Longrightarrow> \<phi>\<^sub>i\<^sub>+\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> \<phi>)s\<close>.  Multiple results are considered as
  11.362    error (exception @{ML THM}).
  11.363  
  11.364 -  \<^descr> @{text "thm\<^sub>1 COMP thm\<^sub>2"} is the same as @{text "Drule.compose
  11.365 -  (thm\<^sub>1, 1, thm\<^sub>2)"}.
  11.366 +  \<^descr> \<open>thm\<^sub>1 COMP thm\<^sub>2\<close> is the same as \<open>Drule.compose
  11.367 +  (thm\<^sub>1, 1, thm\<^sub>2)\<close>.
  11.368  
  11.369  
  11.370    \begin{warn}
  11.371 @@ -554,42 +540,35 @@
  11.372    @{index_ML "FIRST'": "('a -> tactic) list -> 'a -> tactic"} \\
  11.373    \end{mldecls}
  11.374  
  11.375 -  \<^descr> @{text "tac\<^sub>1"}~@{ML_op THEN}~@{text "tac\<^sub>2"} is the sequential
  11.376 -  composition of @{text "tac\<^sub>1"} and @{text "tac\<^sub>2"}.  Applied to a goal
  11.377 +  \<^descr> \<open>tac\<^sub>1\<close>~@{ML_op THEN}~\<open>tac\<^sub>2\<close> is the sequential
  11.378 +  composition of \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close>.  Applied to a goal
  11.379    state, it returns all states reachable in two steps by applying
  11.380 -  @{text "tac\<^sub>1"} followed by @{text "tac\<^sub>2"}.  First, it applies @{text
  11.381 -  "tac\<^sub>1"} to the goal state, getting a sequence of possible next
  11.382 -  states; then, it applies @{text "tac\<^sub>2"} to each of these and
  11.383 +  \<open>tac\<^sub>1\<close> followed by \<open>tac\<^sub>2\<close>.  First, it applies \<open>tac\<^sub>1\<close> to the goal state, getting a sequence of possible next
  11.384 +  states; then, it applies \<open>tac\<^sub>2\<close> to each of these and
  11.385    concatenates the results to produce again one flat sequence of
  11.386    states.
  11.387  
  11.388 -  \<^descr> @{text "tac\<^sub>1"}~@{ML_op ORELSE}~@{text "tac\<^sub>2"} makes a choice
  11.389 -  between @{text "tac\<^sub>1"} and @{text "tac\<^sub>2"}.  Applied to a state, it
  11.390 -  tries @{text "tac\<^sub>1"} and returns the result if non-empty; if @{text
  11.391 -  "tac\<^sub>1"} fails then it uses @{text "tac\<^sub>2"}.  This is a deterministic
  11.392 -  choice: if @{text "tac\<^sub>1"} succeeds then @{text "tac\<^sub>2"} is excluded
  11.393 +  \<^descr> \<open>tac\<^sub>1\<close>~@{ML_op ORELSE}~\<open>tac\<^sub>2\<close> makes a choice
  11.394 +  between \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close>.  Applied to a state, it
  11.395 +  tries \<open>tac\<^sub>1\<close> and returns the result if non-empty; if \<open>tac\<^sub>1\<close> fails then it uses \<open>tac\<^sub>2\<close>.  This is a deterministic
  11.396 +  choice: if \<open>tac\<^sub>1\<close> succeeds then \<open>tac\<^sub>2\<close> is excluded
  11.397    from the result.
  11.398  
  11.399 -  \<^descr> @{text "tac\<^sub>1"}~@{ML_op APPEND}~@{text "tac\<^sub>2"} concatenates the
  11.400 -  possible results of @{text "tac\<^sub>1"} and @{text "tac\<^sub>2"}.  Unlike
  11.401 +  \<^descr> \<open>tac\<^sub>1\<close>~@{ML_op APPEND}~\<open>tac\<^sub>2\<close> concatenates the
  11.402 +  possible results of \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close>.  Unlike
  11.403    @{ML_op "ORELSE"} there is \<^emph>\<open>no commitment\<close> to either tactic, so
  11.404    @{ML_op "APPEND"} helps to avoid incompleteness during search, at
  11.405    the cost of potential inefficiencies.
  11.406  
  11.407 -  \<^descr> @{ML EVERY}~@{text "[tac\<^sub>1, \<dots>, tac\<^sub>n]"} abbreviates @{text
  11.408 -  "tac\<^sub>1"}~@{ML_op THEN}~@{text "\<dots>"}~@{ML_op THEN}~@{text "tac\<^sub>n"}.
  11.409 +  \<^descr> @{ML EVERY}~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>n]\<close> abbreviates \<open>tac\<^sub>1\<close>~@{ML_op THEN}~\<open>\<dots>\<close>~@{ML_op THEN}~\<open>tac\<^sub>n\<close>.
  11.410    Note that @{ML "EVERY []"} is the same as @{ML all_tac}: it always
  11.411    succeeds.
  11.412  
  11.413 -  \<^descr> @{ML FIRST}~@{text "[tac\<^sub>1, \<dots>, tac\<^sub>n]"} abbreviates @{text
  11.414 -  "tac\<^sub>1"}~@{ML_op ORELSE}~@{text "\<dots>"}~@{ML_op "ORELSE"}~@{text
  11.415 -  "tac\<^sub>n"}.  Note that @{ML "FIRST []"} is the same as @{ML no_tac}: it
  11.416 +  \<^descr> @{ML FIRST}~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>n]\<close> abbreviates \<open>tac\<^sub>1\<close>~@{ML_op ORELSE}~\<open>\<dots>\<close>~@{ML_op "ORELSE"}~\<open>tac\<^sub>n\<close>.  Note that @{ML "FIRST []"} is the same as @{ML no_tac}: it
  11.417    always fails.
  11.418  
  11.419    \<^descr> @{ML_op "THEN'"} is the lifted version of @{ML_op "THEN"}, for
  11.420 -  tactics with explicit subgoal addressing.  So @{text
  11.421 -  "(tac\<^sub>1"}~@{ML_op THEN'}~@{text "tac\<^sub>2) i"} is the same as @{text
  11.422 -  "(tac\<^sub>1 i"}~@{ML_op THEN}~@{text "tac\<^sub>2 i)"}.
  11.423 +  tactics with explicit subgoal addressing.  So \<open>(tac\<^sub>1\<close>~@{ML_op THEN'}~\<open>tac\<^sub>2) i\<close> is the same as \<open>(tac\<^sub>1 i\<close>~@{ML_op THEN}~\<open>tac\<^sub>2 i)\<close>.
  11.424  
  11.425    The other primed tacticals work analogously.
  11.426  \<close>
  11.427 @@ -610,35 +589,33 @@
  11.428    @{index_ML "REPEAT_DETERM_N": "int -> tactic -> tactic"} \\
  11.429    \end{mldecls}
  11.430  
  11.431 -  \<^descr> @{ML TRY}~@{text "tac"} applies @{text "tac"} to the goal
  11.432 +  \<^descr> @{ML TRY}~\<open>tac\<close> applies \<open>tac\<close> to the goal
  11.433    state and returns the resulting sequence, if non-empty; otherwise it
  11.434 -  returns the original state.  Thus, it applies @{text "tac"} at most
  11.435 +  returns the original state.  Thus, it applies \<open>tac\<close> at most
  11.436    once.
  11.437  
  11.438    Note that for tactics with subgoal addressing, the combinator can be
  11.439 -  applied via functional composition: @{ML "TRY"}~@{ML_op o}~@{text
  11.440 -  "tac"}.  There is no need for @{verbatim TRY'}.
  11.441 +  applied via functional composition: @{ML "TRY"}~@{ML_op o}~\<open>tac\<close>.  There is no need for @{verbatim TRY'}.
  11.442  
  11.443 -  \<^descr> @{ML REPEAT}~@{text "tac"} applies @{text "tac"} to the goal
  11.444 +  \<^descr> @{ML REPEAT}~\<open>tac\<close> applies \<open>tac\<close> to the goal
  11.445    state and, recursively, to each element of the resulting sequence.
  11.446 -  The resulting sequence consists of those states that make @{text
  11.447 -  "tac"} fail.  Thus, it applies @{text "tac"} as many times as
  11.448 +  The resulting sequence consists of those states that make \<open>tac\<close> fail.  Thus, it applies \<open>tac\<close> as many times as
  11.449    possible (including zero times), and allows backtracking over each
  11.450 -  invocation of @{text "tac"}.  @{ML REPEAT} is more general than @{ML
  11.451 +  invocation of \<open>tac\<close>.  @{ML REPEAT} is more general than @{ML
  11.452    REPEAT_DETERM}, but requires more space.
  11.453  
  11.454 -  \<^descr> @{ML REPEAT1}~@{text "tac"} is like @{ML REPEAT}~@{text "tac"}
  11.455 -  but it always applies @{text "tac"} at least once, failing if this
  11.456 +  \<^descr> @{ML REPEAT1}~\<open>tac\<close> is like @{ML REPEAT}~\<open>tac\<close>
  11.457 +  but it always applies \<open>tac\<close> at least once, failing if this
  11.458    is impossible.
  11.459  
  11.460 -  \<^descr> @{ML REPEAT_DETERM}~@{text "tac"} applies @{text "tac"} to the
  11.461 +  \<^descr> @{ML REPEAT_DETERM}~\<open>tac\<close> applies \<open>tac\<close> to the
  11.462    goal state and, recursively, to the head of the resulting sequence.
  11.463 -  It returns the first state to make @{text "tac"} fail.  It is
  11.464 +  It returns the first state to make \<open>tac\<close> fail.  It is
  11.465    deterministic, discarding alternative outcomes.
  11.466  
  11.467 -  \<^descr> @{ML REPEAT_DETERM_N}~@{text "n tac"} is like @{ML
  11.468 -  REPEAT_DETERM}~@{text "tac"} but the number of repetitions is bound
  11.469 -  by @{text "n"} (where @{ML "~1"} means @{text "\<infinity>"}).
  11.470 +  \<^descr> @{ML REPEAT_DETERM_N}~\<open>n tac\<close> is like @{ML
  11.471 +  REPEAT_DETERM}~\<open>tac\<close> but the number of repetitions is bound
  11.472 +  by \<open>n\<close> (where @{ML "~1"} means \<open>\<infinity>\<close>).
  11.473  \<close>
  11.474  
  11.475  text %mlex \<open>The basic tactics and tacticals considered above follow
  11.476 @@ -649,7 +626,7 @@
  11.477  
  11.478    \<^item> @{ML no_tac} is the identity element of @{ML_op "ORELSE"} and
  11.479    @{ML_op "APPEND"}.  Also, it is a zero element for @{ML_op "THEN"},
  11.480 -  which means that @{text "tac"}~@{ML_op THEN}~@{ML no_tac} is
  11.481 +  which means that \<open>tac\<close>~@{ML_op THEN}~@{ML no_tac} is
  11.482    equivalent to @{ML no_tac}.
  11.483  
  11.484    \<^item> @{ML TRY} and @{ML REPEAT} can be expressed as (recursive)
  11.485 @@ -662,9 +639,9 @@
  11.486    fun REPEAT tac st = ((tac THEN REPEAT tac) ORELSE all_tac) st;
  11.487  \<close>
  11.488  
  11.489 -text \<open>If @{text "tac"} can return multiple outcomes then so can @{ML
  11.490 -  REPEAT}~@{text "tac"}.  @{ML REPEAT} uses @{ML_op "ORELSE"} and not
  11.491 -  @{ML_op "APPEND"}, it applies @{text "tac"} as many times as
  11.492 +text \<open>If \<open>tac\<close> can return multiple outcomes then so can @{ML
  11.493 +  REPEAT}~\<open>tac\<close>.  @{ML REPEAT} uses @{ML_op "ORELSE"} and not
  11.494 +  @{ML_op "APPEND"}, it applies \<open>tac\<close> as many times as
  11.495    possible in each outcome.
  11.496  
  11.497    \begin{warn}
  11.498 @@ -672,7 +649,7 @@
  11.499    definition of @{ML REPEAT}.  Recursive tacticals must be coded in
  11.500    this awkward fashion to avoid infinite recursion of eager functional
  11.501    evaluation in Standard ML.  The following attempt would make @{ML
  11.502 -  REPEAT}~@{text "tac"} loop:
  11.503 +  REPEAT}~\<open>tac\<close> loop:
  11.504    \end{warn}
  11.505  \<close>
  11.506  
  11.507 @@ -690,9 +667,9 @@
  11.508    tactic a certain range of subgoals is covered.  Thus the body tactic
  11.509    is applied to \<^emph>\<open>all\<close> subgoals, \<^emph>\<open>some\<close> subgoal etc.
  11.510  
  11.511 -  Suppose that the goal state has @{text "n \<ge> 0"} subgoals.  Many of
  11.512 +  Suppose that the goal state has \<open>n \<ge> 0\<close> subgoals.  Many of
  11.513    these tacticals address subgoal ranges counting downwards from
  11.514 -  @{text "n"} towards @{text "1"}.  This has the fortunate effect that
  11.515 +  \<open>n\<close> towards \<open>1\<close>.  This has the fortunate effect that
  11.516    newly emerging subgoals are concatenated in the result, without
  11.517    interfering each other.  Nonetheless, there might be situations
  11.518    where a different order is desired.\<close>
  11.519 @@ -708,30 +685,30 @@
  11.520    @{index_ML RANGE: "(int -> tactic) list -> int -> tactic"} \\
  11.521    \end{mldecls}
  11.522  
  11.523 -  \<^descr> @{ML ALLGOALS}~@{text "tac"} is equivalent to @{text "tac
  11.524 -  n"}~@{ML_op THEN}~@{text "\<dots>"}~@{ML_op THEN}~@{text "tac 1"}.  It
  11.525 -  applies the @{text tac} to all the subgoals, counting downwards.
  11.526 +  \<^descr> @{ML ALLGOALS}~\<open>tac\<close> is equivalent to \<open>tac
  11.527 +  n\<close>~@{ML_op THEN}~\<open>\<dots>\<close>~@{ML_op THEN}~\<open>tac 1\<close>.  It
  11.528 +  applies the \<open>tac\<close> to all the subgoals, counting downwards.
  11.529  
  11.530 -  \<^descr> @{ML SOMEGOAL}~@{text "tac"} is equivalent to @{text "tac
  11.531 -  n"}~@{ML_op ORELSE}~@{text "\<dots>"}~@{ML_op ORELSE}~@{text "tac 1"}.  It
  11.532 -  applies @{text "tac"} to one subgoal, counting downwards.
  11.533 +  \<^descr> @{ML SOMEGOAL}~\<open>tac\<close> is equivalent to \<open>tac
  11.534 +  n\<close>~@{ML_op ORELSE}~\<open>\<dots>\<close>~@{ML_op ORELSE}~\<open>tac 1\<close>.  It
  11.535 +  applies \<open>tac\<close> to one subgoal, counting downwards.
  11.536  
  11.537 -  \<^descr> @{ML FIRSTGOAL}~@{text "tac"} is equivalent to @{text "tac
  11.538 -  1"}~@{ML_op ORELSE}~@{text "\<dots>"}~@{ML_op ORELSE}~@{text "tac n"}.  It
  11.539 -  applies @{text "tac"} to one subgoal, counting upwards.
  11.540 +  \<^descr> @{ML FIRSTGOAL}~\<open>tac\<close> is equivalent to \<open>tac
  11.541 +  1\<close>~@{ML_op ORELSE}~\<open>\<dots>\<close>~@{ML_op ORELSE}~\<open>tac n\<close>.  It
  11.542 +  applies \<open>tac\<close> to one subgoal, counting upwards.
  11.543  
  11.544 -  \<^descr> @{ML HEADGOAL}~@{text "tac"} is equivalent to @{text "tac 1"}.
  11.545 -  It applies @{text "tac"} unconditionally to the first subgoal.
  11.546 +  \<^descr> @{ML HEADGOAL}~\<open>tac\<close> is equivalent to \<open>tac 1\<close>.
  11.547 +  It applies \<open>tac\<close> unconditionally to the first subgoal.
  11.548  
  11.549 -  \<^descr> @{ML REPEAT_SOME}~@{text "tac"} applies @{text "tac"} once or
  11.550 +  \<^descr> @{ML REPEAT_SOME}~\<open>tac\<close> applies \<open>tac\<close> once or
  11.551    more to a subgoal, counting downwards.
  11.552  
  11.553 -  \<^descr> @{ML REPEAT_FIRST}~@{text "tac"} applies @{text "tac"} once or
  11.554 +  \<^descr> @{ML REPEAT_FIRST}~\<open>tac\<close> applies \<open>tac\<close> once or
  11.555    more to a subgoal, counting upwards.
  11.556  
  11.557 -  \<^descr> @{ML RANGE}~@{text "[tac\<^sub>1, \<dots>, tac\<^sub>k] i"} is equivalent to
  11.558 -  @{text "tac\<^sub>k (i + k - 1)"}~@{ML_op THEN}~@{text "\<dots>"}~@{ML_op
  11.559 -  THEN}~@{text "tac\<^sub>1 i"}.  It applies the given list of tactics to the
  11.560 +  \<^descr> @{ML RANGE}~\<open>[tac\<^sub>1, \<dots>, tac\<^sub>k] i\<close> is equivalent to
  11.561 +  \<open>tac\<^sub>k (i + k - 1)\<close>~@{ML_op THEN}~\<open>\<dots>\<close>~@{ML_op
  11.562 +  THEN}~\<open>tac\<^sub>1 i\<close>.  It applies the given list of tactics to the
  11.563    corresponding range of subgoals, counting downwards.
  11.564  \<close>
  11.565  
  11.566 @@ -757,14 +734,14 @@
  11.567    @{index_ML CHANGED: "tactic -> tactic"} \\
  11.568    \end{mldecls}
  11.569  
  11.570 -  \<^descr> @{ML FILTER}~@{text "sat tac"} applies @{text "tac"} to the
  11.571 +  \<^descr> @{ML FILTER}~\<open>sat tac\<close> applies \<open>tac\<close> to the
  11.572    goal state and returns a sequence consisting of those result goal
  11.573 -  states that are satisfactory in the sense of @{text "sat"}.
  11.574 +  states that are satisfactory in the sense of \<open>sat\<close>.
  11.575  
  11.576 -  \<^descr> @{ML CHANGED}~@{text "tac"} applies @{text "tac"} to the goal
  11.577 +  \<^descr> @{ML CHANGED}~\<open>tac\<close> applies \<open>tac\<close> to the goal
  11.578    state and returns precisely those states that differ from the
  11.579    original state (according to @{ML Thm.eq_thm}).  Thus @{ML
  11.580 -  CHANGED}~@{text "tac"} always has some effect on the state.
  11.581 +  CHANGED}~\<open>tac\<close> always has some effect on the state.
  11.582  \<close>
  11.583  
  11.584  
  11.585 @@ -777,17 +754,17 @@
  11.586    @{index_ML DEPTH_SOLVE_1: "tactic -> tactic"} \\
  11.587    \end{mldecls}
  11.588  
  11.589 -  \<^descr> @{ML DEPTH_FIRST}~@{text "sat tac"} returns the goal state if
  11.590 -  @{text "sat"} returns true.  Otherwise it applies @{text "tac"},
  11.591 +  \<^descr> @{ML DEPTH_FIRST}~\<open>sat tac\<close> returns the goal state if
  11.592 +  \<open>sat\<close> returns true.  Otherwise it applies \<open>tac\<close>,
  11.593    then recursively searches from each element of the resulting
  11.594    sequence.  The code uses a stack for efficiency, in effect applying
  11.595 -  @{text "tac"}~@{ML_op THEN}~@{ML DEPTH_FIRST}~@{text "sat tac"} to
  11.596 +  \<open>tac\<close>~@{ML_op THEN}~@{ML DEPTH_FIRST}~\<open>sat tac\<close> to
  11.597    the state.
  11.598  
  11.599 -  \<^descr> @{ML DEPTH_SOLVE}@{text "tac"} uses @{ML DEPTH_FIRST} to
  11.600 +  \<^descr> @{ML DEPTH_SOLVE}\<open>tac\<close> uses @{ML DEPTH_FIRST} to
  11.601    search for states having no subgoals.
  11.602  
  11.603 -  \<^descr> @{ML DEPTH_SOLVE_1}~@{text "tac"} uses @{ML DEPTH_FIRST} to
  11.604 +  \<^descr> @{ML DEPTH_SOLVE_1}~\<open>tac\<close> uses @{ML DEPTH_FIRST} to
  11.605    search for states having fewer subgoals than the given state.  Thus,
  11.606    it insists upon solving at least one subgoal.
  11.607  \<close>
  11.608 @@ -804,16 +781,16 @@
  11.609  
  11.610    These search strategies will find a solution if one exists.
  11.611    However, they do not enumerate all solutions; they terminate after
  11.612 -  the first satisfactory result from @{text "tac"}.
  11.613 +  the first satisfactory result from \<open>tac\<close>.
  11.614  
  11.615 -  \<^descr> @{ML BREADTH_FIRST}~@{text "sat tac"} uses breadth-first
  11.616 -  search to find states for which @{text "sat"} is true.  For most
  11.617 +  \<^descr> @{ML BREADTH_FIRST}~\<open>sat tac\<close> uses breadth-first
  11.618 +  search to find states for which \<open>sat\<close> is true.  For most
  11.619    applications, it is too slow.
  11.620  
  11.621 -  \<^descr> @{ML BEST_FIRST}~@{text "(sat, dist) tac"} does a heuristic
  11.622 -  search, using @{text "dist"} to estimate the distance from a
  11.623 -  satisfactory state (in the sense of @{text "sat"}).  It maintains a
  11.624 -  list of states ordered by distance.  It applies @{text "tac"} to the
  11.625 +  \<^descr> @{ML BEST_FIRST}~\<open>(sat, dist) tac\<close> does a heuristic
  11.626 +  search, using \<open>dist\<close> to estimate the distance from a
  11.627 +  satisfactory state (in the sense of \<open>sat\<close>).  It maintains a
  11.628 +  list of states ordered by distance.  It applies \<open>tac\<close> to the
  11.629    head of this list; if the result contains any satisfactory states,
  11.630    then it returns them.  Otherwise, @{ML BEST_FIRST} adds the new
  11.631    states to the list, and continues.
  11.632 @@ -822,9 +799,9 @@
  11.633    the size of the state.  The smaller the state, the fewer and simpler
  11.634    subgoals it has.
  11.635  
  11.636 -  \<^descr> @{ML THEN_BEST_FIRST}~@{text "tac\<^sub>0 (sat, dist) tac"} is like
  11.637 +  \<^descr> @{ML THEN_BEST_FIRST}~\<open>tac\<^sub>0 (sat, dist) tac\<close> is like
  11.638    @{ML BEST_FIRST}, except that the priority queue initially contains
  11.639 -  the result of applying @{text "tac\<^sub>0"} to the goal state.  This
  11.640 +  the result of applying \<open>tac\<^sub>0\<close> to the goal state.  This
  11.641    tactical permits separate tactics for starting the search and
  11.642    continuing the search.
  11.643  \<close>
  11.644 @@ -840,22 +817,22 @@
  11.645    @{index_ML DETERM: "tactic -> tactic"} \\
  11.646    \end{mldecls}
  11.647  
  11.648 -  \<^descr> @{ML COND}~@{text "sat tac\<^sub>1 tac\<^sub>2"} applies @{text "tac\<^sub>1"} to
  11.649 -  the goal state if it satisfies predicate @{text "sat"}, and applies
  11.650 -  @{text "tac\<^sub>2"}.  It is a conditional tactical in that only one of
  11.651 -  @{text "tac\<^sub>1"} and @{text "tac\<^sub>2"} is applied to a goal state.
  11.652 -  However, both @{text "tac\<^sub>1"} and @{text "tac\<^sub>2"} are evaluated
  11.653 +  \<^descr> @{ML COND}~\<open>sat tac\<^sub>1 tac\<^sub>2\<close> applies \<open>tac\<^sub>1\<close> to
  11.654 +  the goal state if it satisfies predicate \<open>sat\<close>, and applies
  11.655 +  \<open>tac\<^sub>2\<close>.  It is a conditional tactical in that only one of
  11.656 +  \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close> is applied to a goal state.
  11.657 +  However, both \<open>tac\<^sub>1\<close> and \<open>tac\<^sub>2\<close> are evaluated
  11.658    because ML uses eager evaluation.
  11.659  
  11.660 -  \<^descr> @{ML IF_UNSOLVED}~@{text "tac"} applies @{text "tac"} to the
  11.661 +  \<^descr> @{ML IF_UNSOLVED}~\<open>tac\<close> applies \<open>tac\<close> to the
  11.662    goal state if it has any subgoals, and simply returns the goal state
  11.663    otherwise.  Many common tactics, such as @{ML resolve_tac}, fail if
  11.664    applied to a goal state that has no subgoals.
  11.665  
  11.666 -  \<^descr> @{ML SOLVE}~@{text "tac"} applies @{text "tac"} to the goal
  11.667 +  \<^descr> @{ML SOLVE}~\<open>tac\<close> applies \<open>tac\<close> to the goal
  11.668    state and then fails iff there are subgoals left.
  11.669  
  11.670 -  \<^descr> @{ML DETERM}~@{text "tac"} applies @{text "tac"} to the goal
  11.671 +  \<^descr> @{ML DETERM}~\<open>tac\<close> applies \<open>tac\<close> to the goal
  11.672    state and returns the head of the resulting sequence.  @{ML DETERM}
  11.673    limits the search space by making its argument deterministic.
  11.674  \<close>
  11.675 @@ -871,20 +848,17 @@
  11.676    @{index_ML size_of_thm: "thm -> int"} \\
  11.677    \end{mldecls}
  11.678  
  11.679 -  \<^descr> @{ML has_fewer_prems}~@{text "n thm"} reports whether @{text
  11.680 -  "thm"} has fewer than @{text "n"} premises.
  11.681 +  \<^descr> @{ML has_fewer_prems}~\<open>n thm\<close> reports whether \<open>thm\<close> has fewer than \<open>n\<close> premises.
  11.682  
  11.683 -  \<^descr> @{ML Thm.eq_thm}~@{text "(thm\<^sub>1, thm\<^sub>2)"} reports whether @{text
  11.684 -  "thm\<^sub>1"} and @{text "thm\<^sub>2"} are equal.  Both theorems must have the
  11.685 +  \<^descr> @{ML Thm.eq_thm}~\<open>(thm\<^sub>1, thm\<^sub>2)\<close> reports whether \<open>thm\<^sub>1\<close> and \<open>thm\<^sub>2\<close> are equal.  Both theorems must have the
  11.686    same conclusions, the same set of hypotheses, and the same set of sort
  11.687    hypotheses.  Names of bound variables are ignored as usual.
  11.688  
  11.689 -  \<^descr> @{ML Thm.eq_thm_prop}~@{text "(thm\<^sub>1, thm\<^sub>2)"} reports whether
  11.690 -  the propositions of @{text "thm\<^sub>1"} and @{text "thm\<^sub>2"} are equal.
  11.691 +  \<^descr> @{ML Thm.eq_thm_prop}~\<open>(thm\<^sub>1, thm\<^sub>2)\<close> reports whether
  11.692 +  the propositions of \<open>thm\<^sub>1\<close> and \<open>thm\<^sub>2\<close> are equal.
  11.693    Names of bound variables are ignored.
  11.694  
  11.695 -  \<^descr> @{ML size_of_thm}~@{text "thm"} computes the size of @{text
  11.696 -  "thm"}, namely the number of variables, constants and abstractions
  11.697 +  \<^descr> @{ML size_of_thm}~\<open>thm\<close> computes the size of \<open>thm\<close>, namely the number of variables, constants and abstractions
  11.698    in its conclusion.  It may serve as a distance function for
  11.699    @{ML BEST_FIRST}.
  11.700  \<close>
    12.1 --- a/src/Doc/Isar_Ref/Document_Preparation.thy	Tue Oct 20 23:03:46 2015 +0200
    12.2 +++ b/src/Doc/Isar_Ref/Document_Preparation.thy	Tue Oct 20 23:53:40 2015 +0200
    12.3 @@ -22,15 +22,15 @@
    12.4  
    12.5  text \<open>
    12.6    \begin{matharray}{rcl}
    12.7 -    @{command_def "chapter"} & : & @{text "any \<rightarrow> any"} \\
    12.8 -    @{command_def "section"} & : & @{text "any \<rightarrow> any"} \\
    12.9 -    @{command_def "subsection"} & : & @{text "any \<rightarrow> any"} \\
   12.10 -    @{command_def "subsubsection"} & : & @{text "any \<rightarrow> any"} \\
   12.11 -    @{command_def "paragraph"} & : & @{text "any \<rightarrow> any"} \\
   12.12 -    @{command_def "subparagraph"} & : & @{text "any \<rightarrow> any"} \\
   12.13 -    @{command_def "text"} & : & @{text "any \<rightarrow> any"} \\
   12.14 -    @{command_def "txt"} & : & @{text "any \<rightarrow> any"} \\
   12.15 -    @{command_def "text_raw"} & : & @{text "any \<rightarrow> any"} \\
   12.16 +    @{command_def "chapter"} & : & \<open>any \<rightarrow> any\<close> \\
   12.17 +    @{command_def "section"} & : & \<open>any \<rightarrow> any\<close> \\
   12.18 +    @{command_def "subsection"} & : & \<open>any \<rightarrow> any\<close> \\
   12.19 +    @{command_def "subsubsection"} & : & \<open>any \<rightarrow> any\<close> \\
   12.20 +    @{command_def "paragraph"} & : & \<open>any \<rightarrow> any\<close> \\
   12.21 +    @{command_def "subparagraph"} & : & \<open>any \<rightarrow> any\<close> \\
   12.22 +    @{command_def "text"} & : & \<open>any \<rightarrow> any\<close> \\
   12.23 +    @{command_def "txt"} & : & \<open>any \<rightarrow> any\<close> \\
   12.24 +    @{command_def "text_raw"} & : & \<open>any \<rightarrow> any\<close> \\
   12.25    \end{matharray}
   12.26  
   12.27    Markup commands provide a structured way to insert text into the
   12.28 @@ -58,7 +58,7 @@
   12.29  
   12.30    \<^descr> @{command text} and @{command txt} specify paragraphs of plain text.
   12.31    This corresponds to a {\LaTeX} environment @{verbatim
   12.32 -  \<open>\begin{isamarkuptext}\<close>} @{text "\<dots>"} @{verbatim \<open>\end{isamarkuptext}\<close>}
   12.33 +  \<open>\begin{isamarkuptext}\<close>} \<open>\<dots>\<close> @{verbatim \<open>\end{isamarkuptext}\<close>}
   12.34    etc.
   12.35  
   12.36    \<^descr> @{command text_raw} is similar to @{command text}, but without
   12.37 @@ -81,35 +81,35 @@
   12.38  
   12.39  text \<open>
   12.40    \begin{matharray}{rcl}
   12.41 -    @{antiquotation_def "theory"} & : & @{text antiquotation} \\
   12.42 -    @{antiquotation_def "thm"} & : & @{text antiquotation} \\
   12.43 -    @{antiquotation_def "lemma"} & : & @{text antiquotation} \\
   12.44 -    @{antiquotation_def "prop"} & : & @{text antiquotation} \\
   12.45 -    @{antiquotation_def "term"} & : & @{text antiquotation} \\
   12.46 -    @{antiquotation_def term_type} & : & @{text antiquotation} \\
   12.47 -    @{antiquotation_def typeof} & : & @{text antiquotation} \\
   12.48 -    @{antiquotation_def const} & : & @{text antiquotation} \\
   12.49 -    @{antiquotation_def abbrev} & : & @{text antiquotation} \\
   12.50 -    @{antiquotation_def typ} & : & @{text antiquotation} \\
   12.51 -    @{antiquotation_def type} & : & @{text antiquotation} \\
   12.52 -    @{antiquotation_def class} & : & @{text antiquotation} \\
   12.53 -    @{antiquotation_def "text"} & : & @{text antiquotation} \\
   12.54 -    @{antiquotation_def goals} & : & @{text antiquotation} \\
   12.55 -    @{antiquotation_def subgoals} & : & @{text antiquotation} \\
   12.56 -    @{antiquotation_def prf} & : & @{text antiquotation} \\
   12.57 -    @{antiquotation_def full_prf} & : & @{text antiquotation} \\
   12.58 -    @{antiquotation_def ML} & : & @{text antiquotation} \\
   12.59 -    @{antiquotation_def ML_op} & : & @{text antiquotation} \\
   12.60 -    @{antiquotation_def ML_type} & : & @{text antiquotation} \\
   12.61 -    @{antiquotation_def ML_structure} & : & @{text antiquotation} \\
   12.62 -    @{antiquotation_def ML_functor} & : & @{text antiquotation} \\
   12.63 -    @{antiquotation_def emph} & : & @{text antiquotation} \\
   12.64 -    @{antiquotation_def bold} & : & @{text antiquotation} \\
   12.65 -    @{antiquotation_def verbatim} & : & @{text antiquotation} \\
   12.66 -    @{antiquotation_def "file"} & : & @{text antiquotation} \\
   12.67 -    @{antiquotation_def "url"} & : & @{text antiquotation} \\
   12.68 -    @{antiquotation_def "cite"} & : & @{text antiquotation} \\
   12.69 -    @{command_def "print_antiquotations"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow> "} \\
   12.70 +    @{antiquotation_def "theory"} & : & \<open>antiquotation\<close> \\
   12.71 +    @{antiquotation_def "thm"} & : & \<open>antiquotation\<close> \\
   12.72 +    @{antiquotation_def "lemma"} & : & \<open>antiquotation\<close> \\
   12.73 +    @{antiquotation_def "prop"} & : & \<open>antiquotation\<close> \\
   12.74 +    @{antiquotation_def "term"} & : & \<open>antiquotation\<close> \\
   12.75 +    @{antiquotation_def term_type} & : & \<open>antiquotation\<close> \\
   12.76 +    @{antiquotation_def typeof} & : & \<open>antiquotation\<close> \\
   12.77 +    @{antiquotation_def const} & : & \<open>antiquotation\<close> \\
   12.78 +    @{antiquotation_def abbrev} & : & \<open>antiquotation\<close> \\
   12.79 +    @{antiquotation_def typ} & : & \<open>antiquotation\<close> \\
   12.80 +    @{antiquotation_def type} & : & \<open>antiquotation\<close> \\
   12.81 +    @{antiquotation_def class} & : & \<open>antiquotation\<close> \\
   12.82 +    @{antiquotation_def "text"} & : & \<open>antiquotation\<close> \\
   12.83 +    @{antiquotation_def goals} & : & \<open>antiquotation\<close> \\
   12.84 +    @{antiquotation_def subgoals} & : & \<open>antiquotation\<close> \\
   12.85 +    @{antiquotation_def prf} & : & \<open>antiquotation\<close> \\
   12.86 +    @{antiquotation_def full_prf} & : & \<open>antiquotation\<close> \\
   12.87 +    @{antiquotation_def ML} & : & \<open>antiquotation\<close> \\
   12.88 +    @{antiquotation_def ML_op} & : & \<open>antiquotation\<close> \\
   12.89 +    @{antiquotation_def ML_type} & : & \<open>antiquotation\<close> \\
   12.90 +    @{antiquotation_def ML_structure} & : & \<open>antiquotation\<close> \\
   12.91 +    @{antiquotation_def ML_functor} & : & \<open>antiquotation\<close> \\
   12.92 +    @{antiquotation_def emph} & : & \<open>antiquotation\<close> \\
   12.93 +    @{antiquotation_def bold} & : & \<open>antiquotation\<close> \\
   12.94 +    @{antiquotation_def verbatim} & : & \<open>antiquotation\<close> \\
   12.95 +    @{antiquotation_def "file"} & : & \<open>antiquotation\<close> \\
   12.96 +    @{antiquotation_def "url"} & : & \<open>antiquotation\<close> \\
   12.97 +    @{antiquotation_def "cite"} & : & \<open>antiquotation\<close> \\
   12.98 +    @{command_def "print_antiquotations"}\<open>\<^sup>*\<close> & : & \<open>context \<rightarrow> \<close> \\
   12.99    \end{matharray}
  12.100  
  12.101    The overall content of an Isabelle/Isar theory may alternate between
  12.102 @@ -131,17 +131,15 @@
  12.103    antiquotations are checked within the current theory or proof
  12.104    context.
  12.105  
  12.106 -  \<^medskip> Antiquotations are in general written as @{verbatim "@{"}@{text
  12.107 -  "name"}~@{verbatim "["}@{text options}@{verbatim "]"}~@{text
  12.108 -  "arguments"}@{verbatim "}"}. The short form @{verbatim \<open>\\<close>}@{verbatim
  12.109 -  "<^"}@{text name}@{verbatim ">"}@{text "\<open>argument_content\<close>"} (without
  12.110 -  surrounding @{verbatim "@{"}@{text "\<dots>"}@{verbatim "}"}) works for a single
  12.111 +  \<^medskip> Antiquotations are in general written as @{verbatim "@{"}\<open>name\<close>~@{verbatim "["}\<open>options\<close>@{verbatim "]"}~\<open>arguments\<close>@{verbatim "}"}. The short form @{verbatim \<open>\\<close>}@{verbatim
  12.112 +  "<^"}\<open>name\<close>@{verbatim ">"}\<open>\<open>argument_content\<close>\<close> (without
  12.113 +  surrounding @{verbatim "@{"}\<open>\<dots>\<close>@{verbatim "}"}) works for a single
  12.114    argument that is a cartouche.
  12.115  
  12.116    Omitting the control symbol is also possible: a cartouche without special
  12.117    decoration is equivalent to @{verbatim \<open>\\<close>}@{verbatim
  12.118 -  "<^cartouche>"}@{text "\<open>argument_content\<close>"}, which is equivalent to
  12.119 -  @{verbatim "@{cartouche"}~@{text "\<open>argument_content\<close>"}@{verbatim "}"}. The
  12.120 +  "<^cartouche>"}\<open>\<open>argument_content\<close>\<close>, which is equivalent to
  12.121 +  @{verbatim "@{cartouche"}~\<open>\<open>argument_content\<close>\<close>@{verbatim "}"}. The
  12.122    special name @{antiquotation_def cartouche} is defined in the context:
  12.123    Isabelle/Pure introduces that as an alias to @{antiquotation_ref text}
  12.124    (see below). Consequently, \<open>\<open>foo_bar + baz \<le> bazar\<close>\<close> prints literal
  12.125 @@ -163,8 +161,8 @@
  12.126    \endgroup
  12.127  
  12.128    Note that the syntax of antiquotations may \<^emph>\<open>not\<close> include source
  12.129 -  comments @{verbatim "(*"}~@{text "\<dots>"}~@{verbatim "*)"} nor verbatim
  12.130 -  text @{verbatim "{*"}~@{text "\<dots>"}~@{verbatim "*}"}.
  12.131 +  comments @{verbatim "(*"}~\<open>\<dots>\<close>~@{verbatim "*)"} nor verbatim
  12.132 +  text @{verbatim "{*"}~\<open>\<dots>\<close>~@{verbatim "*}"}.
  12.133  
  12.134    %% FIXME less monolithic presentation, move to individual sections!?
  12.135    @{rail \<open>
  12.136 @@ -209,8 +207,7 @@
  12.137      @@{command print_antiquotations} ('!'?)
  12.138    \<close>}
  12.139  
  12.140 -  \<^descr> @{text "@{text s}"} prints uninterpreted source text @{text
  12.141 -  s}.  This is particularly useful to print portions of text according
  12.142 +  \<^descr> \<open>@{text s}\<close> prints uninterpreted source text \<open>s\<close>.  This is particularly useful to print portions of text according
  12.143    to the Isabelle document style, without demanding well-formedness,
  12.144    e.g.\ small pieces of terms that should not be parsed or
  12.145    type-checked yet.
  12.146 @@ -218,45 +215,44 @@
  12.147    It is also possible to write this in the short form \<open>\<open>s\<close>\<close> without any
  12.148    further decoration.
  12.149  
  12.150 -  \<^descr> @{text "@{theory A}"} prints the name @{text "A"}, which is
  12.151 +  \<^descr> \<open>@{theory A}\<close> prints the name \<open>A\<close>, which is
  12.152    guaranteed to refer to a valid ancestor theory in the current
  12.153    context.
  12.154  
  12.155 -  \<^descr> @{text "@{thm a\<^sub>1 \<dots> a\<^sub>n}"} prints theorems @{text "a\<^sub>1 \<dots> a\<^sub>n"}.
  12.156 +  \<^descr> \<open>@{thm a\<^sub>1 \<dots> a\<^sub>n}\<close> prints theorems \<open>a\<^sub>1 \<dots> a\<^sub>n\<close>.
  12.157    Full fact expressions are allowed here, including attributes
  12.158    (\secref{sec:syn-att}).
  12.159  
  12.160 -  \<^descr> @{text "@{prop \<phi>}"} prints a well-typed proposition @{text
  12.161 -  "\<phi>"}.
  12.162 +  \<^descr> \<open>@{prop \<phi>}\<close> prints a well-typed proposition \<open>\<phi>\<close>.
  12.163  
  12.164 -  \<^descr> @{text "@{lemma \<phi> by m}"} proves a well-typed proposition
  12.165 -  @{text "\<phi>"} by method @{text m} and prints the original @{text "\<phi>"}.
  12.166 +  \<^descr> \<open>@{lemma \<phi> by m}\<close> proves a well-typed proposition
  12.167 +  \<open>\<phi>\<close> by method \<open>m\<close> and prints the original \<open>\<phi>\<close>.
  12.168  
  12.169 -  \<^descr> @{text "@{term t}"} prints a well-typed term @{text "t"}.
  12.170 +  \<^descr> \<open>@{term t}\<close> prints a well-typed term \<open>t\<close>.
  12.171    
  12.172 -  \<^descr> @{text "@{value t}"} evaluates a term @{text "t"} and prints
  12.173 +  \<^descr> \<open>@{value t}\<close> evaluates a term \<open>t\<close> and prints
  12.174    its result, see also @{command_ref (HOL) value}.
  12.175  
  12.176 -  \<^descr> @{text "@{term_type t}"} prints a well-typed term @{text "t"}
  12.177 +  \<^descr> \<open>@{term_type t}\<close> prints a well-typed term \<open>t\<close>
  12.178    annotated with its type.
  12.179  
  12.180 -  \<^descr> @{text "@{typeof t}"} prints the type of a well-typed term
  12.181 -  @{text "t"}.
  12.182 +  \<^descr> \<open>@{typeof t}\<close> prints the type of a well-typed term
  12.183 +  \<open>t\<close>.
  12.184  
  12.185 -  \<^descr> @{text "@{const c}"} prints a logical or syntactic constant
  12.186 -  @{text "c"}.
  12.187 +  \<^descr> \<open>@{const c}\<close> prints a logical or syntactic constant
  12.188 +  \<open>c\<close>.
  12.189    
  12.190 -  \<^descr> @{text "@{abbrev c x\<^sub>1 \<dots> x\<^sub>n}"} prints a constant abbreviation
  12.191 -  @{text "c x\<^sub>1 \<dots> x\<^sub>n \<equiv> rhs"} as defined in the current context.
  12.192 +  \<^descr> \<open>@{abbrev c x\<^sub>1 \<dots> x\<^sub>n}\<close> prints a constant abbreviation
  12.193 +  \<open>c x\<^sub>1 \<dots> x\<^sub>n \<equiv> rhs\<close> as defined in the current context.
  12.194  
  12.195 -  \<^descr> @{text "@{typ \<tau>}"} prints a well-formed type @{text "\<tau>"}.
  12.196 +  \<^descr> \<open>@{typ \<tau>}\<close> prints a well-formed type \<open>\<tau>\<close>.
  12.197  
  12.198 -  \<^descr> @{text "@{type \<kappa>}"} prints a (logical or syntactic) type
  12.199 -    constructor @{text "\<kappa>"}.
  12.200 +  \<^descr> \<open>@{type \<kappa>}\<close> prints a (logical or syntactic) type
  12.201 +    constructor \<open>\<kappa>\<close>.
  12.202  
  12.203 -  \<^descr> @{text "@{class c}"} prints a class @{text c}.
  12.204 +  \<^descr> \<open>@{class c}\<close> prints a class \<open>c\<close>.
  12.205  
  12.206 -  \<^descr> @{text "@{goals}"} prints the current \<^emph>\<open>dynamic\<close> goal
  12.207 +  \<^descr> \<open>@{goals}\<close> prints the current \<^emph>\<open>dynamic\<close> goal
  12.208    state.  This is mainly for support of tactic-emulation scripts
  12.209    within Isar.  Presentation of goal states does not conform to the
  12.210    idea of human-readable proof documents!
  12.211 @@ -265,84 +261,83 @@
  12.212    the reasoning via proper Isar proof commands, instead of peeking at
  12.213    the internal machine configuration.
  12.214    
  12.215 -  \<^descr> @{text "@{subgoals}"} is similar to @{text "@{goals}"}, but
  12.216 +  \<^descr> \<open>@{subgoals}\<close> is similar to \<open>@{goals}\<close>, but
  12.217    does not print the main goal.
  12.218    
  12.219 -  \<^descr> @{text "@{prf a\<^sub>1 \<dots> a\<^sub>n}"} prints the (compact) proof terms
  12.220 -  corresponding to the theorems @{text "a\<^sub>1 \<dots> a\<^sub>n"}. Note that this
  12.221 +  \<^descr> \<open>@{prf a\<^sub>1 \<dots> a\<^sub>n}\<close> prints the (compact) proof terms
  12.222 +  corresponding to the theorems \<open>a\<^sub>1 \<dots> a\<^sub>n\<close>. Note that this
  12.223    requires proof terms to be switched on for the current logic
  12.224    session.
  12.225    
  12.226 -  \<^descr> @{text "@{full_prf a\<^sub>1 \<dots> a\<^sub>n}"} is like @{text "@{prf a\<^sub>1 \<dots>
  12.227 -  a\<^sub>n}"}, but prints the full proof terms, i.e.\ also displays
  12.228 +  \<^descr> \<open>@{full_prf a\<^sub>1 \<dots> a\<^sub>n}\<close> is like \<open>@{prf a\<^sub>1 \<dots>
  12.229 +  a\<^sub>n}\<close>, but prints the full proof terms, i.e.\ also displays
  12.230    information omitted in the compact proof term, which is denoted by
  12.231 -  ``@{text _}'' placeholders there.
  12.232 +  ``\<open>_\<close>'' placeholders there.
  12.233    
  12.234 -  \<^descr> @{text "@{ML s}"}, @{text "@{ML_op s}"}, @{text "@{ML_type
  12.235 -  s}"}, @{text "@{ML_structure s}"}, and @{text "@{ML_functor s}"}
  12.236 -  check text @{text s} as ML value, infix operator, type, structure,
  12.237 +  \<^descr> \<open>@{ML s}\<close>, \<open>@{ML_op s}\<close>, \<open>@{ML_type
  12.238 +  s}\<close>, \<open>@{ML_structure s}\<close>, and \<open>@{ML_functor s}\<close>
  12.239 +  check text \<open>s\<close> as ML value, infix operator, type, structure,
  12.240    and functor respectively.  The source is printed verbatim.
  12.241  
  12.242 -  \<^descr> @{text "@{emph s}"} prints document source recursively, with {\LaTeX}
  12.243 -  markup @{verbatim \<open>\emph{\<close>}@{text "\<dots>"}@{verbatim \<open>}\<close>}.
  12.244 +  \<^descr> \<open>@{emph s}\<close> prints document source recursively, with {\LaTeX}
  12.245 +  markup @{verbatim \<open>\emph{\<close>}\<open>\<dots>\<close>@{verbatim \<open>}\<close>}.
  12.246  
  12.247 -  \<^descr> @{text "@{bold s}"} prints document source recursively, with {\LaTeX}
  12.248 -  markup @{verbatim \<open>\textbf{\<close>}@{text "\<dots>"}@{verbatim \<open>}\<close>}.
  12.249 +  \<^descr> \<open>@{bold s}\<close> prints document source recursively, with {\LaTeX}
  12.250 +  markup @{verbatim \<open>\textbf{\<close>}\<open>\<dots>\<close>@{verbatim \<open>}\<close>}.
  12.251  
  12.252 -  \<^descr> @{text "@{verbatim s}"} prints uninterpreted source text literally
  12.253 +  \<^descr> \<open>@{verbatim s}\<close> prints uninterpreted source text literally
  12.254    as ASCII characters, using some type-writer font style.
  12.255  
  12.256 -  \<^descr> @{text "@{file path}"} checks that @{text "path"} refers to a
  12.257 +  \<^descr> \<open>@{file path}\<close> checks that \<open>path\<close> refers to a
  12.258    file (or directory) and prints it verbatim.
  12.259  
  12.260 -  \<^descr> @{text "@{file_unchecked path}"} is like @{text "@{file
  12.261 -  path}"}, but does not check the existence of the @{text "path"}
  12.262 +  \<^descr> \<open>@{file_unchecked path}\<close> is like \<open>@{file
  12.263 +  path}\<close>, but does not check the existence of the \<open>path\<close>
  12.264    within the file-system.
  12.265  
  12.266 -  \<^descr> @{text "@{url name}"} produces markup for the given URL, which
  12.267 +  \<^descr> \<open>@{url name}\<close> produces markup for the given URL, which
  12.268    results in an active hyperlink within the text.
  12.269  
  12.270 -  \<^descr> @{text "@{cite name}"} produces a citation @{verbatim
  12.271 +  \<^descr> \<open>@{cite name}\<close> produces a citation @{verbatim
  12.272    \<open>\cite{name}\<close>} in {\LaTeX}, where the name refers to some Bib{\TeX}
  12.273    database entry.
  12.274  
  12.275 -  The variant @{text "@{cite \<open>opt\<close> name}"} produces @{verbatim
  12.276 +  The variant \<open>@{cite \<open>opt\<close> name}\<close> produces @{verbatim
  12.277    \<open>\cite[opt]{name}\<close>} with some free-form optional argument. Multiple names
  12.278 -  are output with commas, e.g. @{text "@{cite foo \<AND> bar}"} becomes
  12.279 +  are output with commas, e.g. \<open>@{cite foo \<AND> bar}\<close> becomes
  12.280    @{verbatim \<open>\cite{foo,bar}\<close>}.
  12.281  
  12.282    The {\LaTeX} macro name is determined by the antiquotation option
  12.283    @{antiquotation_option_def cite_macro}, or the configuration option
  12.284 -  @{attribute cite_macro} in the context. For example, @{text "@{cite
  12.285 -  [cite_macro = nocite] foobar}"} produces @{verbatim \<open>\nocite{foobar}\<close>}.
  12.286 +  @{attribute cite_macro} in the context. For example, \<open>@{cite
  12.287 +  [cite_macro = nocite] foobar}\<close> produces @{verbatim \<open>\nocite{foobar}\<close>}.
  12.288  
  12.289    \<^descr> @{command "print_antiquotations"} prints all document antiquotations
  12.290 -  that are defined in the current context; the ``@{text "!"}'' option
  12.291 +  that are defined in the current context; the ``\<open>!\<close>'' option
  12.292    indicates extra verbosity.
  12.293  \<close>
  12.294  
  12.295  
  12.296  subsection \<open>Styled antiquotations\<close>
  12.297  
  12.298 -text \<open>The antiquotations @{text thm}, @{text prop} and @{text
  12.299 -  term} admit an extra \<^emph>\<open>style\<close> specification to modify the
  12.300 +text \<open>The antiquotations \<open>thm\<close>, \<open>prop\<close> and \<open>term\<close> admit an extra \<^emph>\<open>style\<close> specification to modify the
  12.301    printed result.  A style is specified by a name with a possibly
  12.302    empty number of arguments;  multiple styles can be sequenced with
  12.303    commas.  The following standard styles are available:
  12.304  
  12.305 -  \<^descr> @{text lhs} extracts the first argument of any application
  12.306 +  \<^descr> \<open>lhs\<close> extracts the first argument of any application
  12.307    form with at least two arguments --- typically meta-level or
  12.308    object-level equality, or any other binary relation.
  12.309    
  12.310 -  \<^descr> @{text rhs} is like @{text lhs}, but extracts the second
  12.311 +  \<^descr> \<open>rhs\<close> is like \<open>lhs\<close>, but extracts the second
  12.312    argument.
  12.313    
  12.314 -  \<^descr> @{text "concl"} extracts the conclusion @{text C} from a rule
  12.315 -  in Horn-clause normal form @{text "A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> C"}.
  12.316 +  \<^descr> \<open>concl\<close> extracts the conclusion \<open>C\<close> from a rule
  12.317 +  in Horn-clause normal form \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> C\<close>.
  12.318    
  12.319 -  \<^descr> @{text "prem"} @{text n} extract premise number
  12.320 -  @{text "n"} from from a rule in Horn-clause
  12.321 -  normal form @{text "A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> C"}
  12.322 +  \<^descr> \<open>prem\<close> \<open>n\<close> extract premise number
  12.323 +  \<open>n\<close> from from a rule in Horn-clause
  12.324 +  normal form \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> C\<close>
  12.325  \<close>
  12.326  
  12.327  
  12.328 @@ -352,34 +347,34 @@
  12.329    of antiquotations.  Note that many of these coincide with system and
  12.330    configuration options of the same names.
  12.331  
  12.332 -  \<^descr> @{antiquotation_option_def show_types}~@{text "= bool"} and
  12.333 -  @{antiquotation_option_def show_sorts}~@{text "= bool"} control
  12.334 +  \<^descr> @{antiquotation_option_def show_types}~\<open>= bool\<close> and
  12.335 +  @{antiquotation_option_def show_sorts}~\<open>= bool\<close> control
  12.336    printing of explicit type and sort constraints.
  12.337  
  12.338 -  \<^descr> @{antiquotation_option_def show_structs}~@{text "= bool"}
  12.339 +  \<^descr> @{antiquotation_option_def show_structs}~\<open>= bool\<close>
  12.340    controls printing of implicit structures.
  12.341  
  12.342 -  \<^descr> @{antiquotation_option_def show_abbrevs}~@{text "= bool"}
  12.343 +  \<^descr> @{antiquotation_option_def show_abbrevs}~\<open>= bool\<close>
  12.344    controls folding of abbreviations.
  12.345  
  12.346 -  \<^descr> @{antiquotation_option_def names_long}~@{text "= bool"} forces
  12.347 +  \<^descr> @{antiquotation_option_def names_long}~\<open>= bool\<close> forces
  12.348    names of types and constants etc.\ to be printed in their fully
  12.349    qualified internal form.
  12.350  
  12.351 -  \<^descr> @{antiquotation_option_def names_short}~@{text "= bool"}
  12.352 +  \<^descr> @{antiquotation_option_def names_short}~\<open>= bool\<close>
  12.353    forces names of types and constants etc.\ to be printed unqualified.
  12.354    Note that internalizing the output again in the current context may
  12.355    well yield a different result.
  12.356  
  12.357 -  \<^descr> @{antiquotation_option_def names_unique}~@{text "= bool"}
  12.358 +  \<^descr> @{antiquotation_option_def names_unique}~\<open>= bool\<close>
  12.359    determines whether the printed version of qualified names should be
  12.360    made sufficiently long to avoid overlap with names declared further
  12.361 -  back.  Set to @{text false} for more concise output.
  12.362 +  back.  Set to \<open>false\<close> for more concise output.
  12.363  
  12.364 -  \<^descr> @{antiquotation_option_def eta_contract}~@{text "= bool"}
  12.365 -  prints terms in @{text \<eta>}-contracted form.
  12.366 +  \<^descr> @{antiquotation_option_def eta_contract}~\<open>= bool\<close>
  12.367 +  prints terms in \<open>\<eta>\<close>-contracted form.
  12.368  
  12.369 -  \<^descr> @{antiquotation_option_def display}~@{text "= bool"} indicates
  12.370 +  \<^descr> @{antiquotation_option_def display}~\<open>= bool\<close> indicates
  12.371    if the text is to be output as multi-line ``display material'',
  12.372    rather than a small piece of text without line breaks (which is the
  12.373    default).
  12.374 @@ -387,47 +382,45 @@
  12.375    In this mode the embedded entities are printed in the same style as
  12.376    the main theory text.
  12.377  
  12.378 -  \<^descr> @{antiquotation_option_def break}~@{text "= bool"} controls
  12.379 +  \<^descr> @{antiquotation_option_def break}~\<open>= bool\<close> controls
  12.380    line breaks in non-display material.
  12.381  
  12.382 -  \<^descr> @{antiquotation_option_def quotes}~@{text "= bool"} indicates
  12.383 +  \<^descr> @{antiquotation_option_def quotes}~\<open>= bool\<close> indicates
  12.384    if the output should be enclosed in double quotes.
  12.385  
  12.386 -  \<^descr> @{antiquotation_option_def mode}~@{text "= name"} adds @{text
  12.387 -  name} to the print mode to be used for presentation.  Note that the
  12.388 +  \<^descr> @{antiquotation_option_def mode}~\<open>= name\<close> adds \<open>name\<close> to the print mode to be used for presentation.  Note that the
  12.389    standard setup for {\LaTeX} output is already present by default,
  12.390 -  including the modes @{text latex} and @{text xsymbols}.
  12.391 +  including the modes \<open>latex\<close> and \<open>xsymbols\<close>.
  12.392  
  12.393 -  \<^descr> @{antiquotation_option_def margin}~@{text "= nat"} and
  12.394 -  @{antiquotation_option_def indent}~@{text "= nat"} change the margin
  12.395 +  \<^descr> @{antiquotation_option_def margin}~\<open>= nat\<close> and
  12.396 +  @{antiquotation_option_def indent}~\<open>= nat\<close> change the margin
  12.397    or indentation for pretty printing of display material.
  12.398  
  12.399 -  \<^descr> @{antiquotation_option_def goals_limit}~@{text "= nat"}
  12.400 +  \<^descr> @{antiquotation_option_def goals_limit}~\<open>= nat\<close>
  12.401    determines the maximum number of subgoals to be printed (for goal-based
  12.402    antiquotation).
  12.403  
  12.404 -  \<^descr> @{antiquotation_option_def source}~@{text "= bool"} prints the
  12.405 +  \<^descr> @{antiquotation_option_def source}~\<open>= bool\<close> prints the
  12.406    original source text of the antiquotation arguments, rather than its
  12.407    internal representation.  Note that formal checking of
  12.408    @{antiquotation "thm"}, @{antiquotation "term"}, etc. is still
  12.409    enabled; use the @{antiquotation "text"} antiquotation for unchecked
  12.410    output.
  12.411  
  12.412 -  Regular @{text "term"} and @{text "typ"} antiquotations with @{text
  12.413 -  "source = false"} involve a full round-trip from the original source
  12.414 +  Regular \<open>term\<close> and \<open>typ\<close> antiquotations with \<open>source = false\<close> involve a full round-trip from the original source
  12.415    to an internalized logical entity back to a source form, according
  12.416    to the syntax of the current context.  Thus the printed output is
  12.417    not under direct control of the author, it may even fluctuate a bit
  12.418    as the underlying theory is changed later on.
  12.419  
  12.420 -  In contrast, @{antiquotation_option source}~@{text "= true"}
  12.421 +  In contrast, @{antiquotation_option source}~\<open>= true\<close>
  12.422    admits direct printing of the given source text, with the desirable
  12.423    well-formedness check in the background, but without modification of
  12.424    the printed text.
  12.425  
  12.426  
  12.427 -  For Boolean flags, ``@{text "name = true"}'' may be abbreviated as
  12.428 -  ``@{text name}''.  All of the above flags are disabled by default,
  12.429 +  For Boolean flags, ``\<open>name = true\<close>'' may be abbreviated as
  12.430 +  ``\<open>name\<close>''.  All of the above flags are disabled by default,
  12.431    unless changed specifically for a logic session in the corresponding
  12.432    @{verbatim "ROOT"} file.
  12.433  \<close>
  12.434 @@ -450,9 +443,9 @@
  12.435  
  12.436    \<^medskip>
  12.437    \begin{tabular}{ll}
  12.438 -    @{text "theory"} & theory begin/end \\
  12.439 -    @{text "proof"} & all proof commands \\
  12.440 -    @{text "ML"} & all commands involving ML code \\
  12.441 +    \<open>theory\<close> & theory begin/end \\
  12.442 +    \<open>proof\<close> & all proof commands \\
  12.443 +    \<open>ML\<close> & all commands involving ML code \\
  12.444    \end{tabular}
  12.445    \<^medskip>
  12.446  
  12.447 @@ -461,17 +454,17 @@
  12.448    specifically, e.g.\ to fold proof texts, or drop parts of the text
  12.449    completely.
  12.450  
  12.451 -  For example ``@{command "by"}~@{text "%invisible auto"}'' causes
  12.452 -  that piece of proof to be treated as @{text invisible} instead of
  12.453 -  @{text "proof"} (the default), which may be shown or hidden
  12.454 +  For example ``@{command "by"}~\<open>%invisible auto\<close>'' causes
  12.455 +  that piece of proof to be treated as \<open>invisible\<close> instead of
  12.456 +  \<open>proof\<close> (the default), which may be shown or hidden
  12.457    depending on the document setup.  In contrast, ``@{command
  12.458 -  "by"}~@{text "%visible auto"}'' forces this text to be shown
  12.459 +  "by"}~\<open>%visible auto\<close>'' forces this text to be shown
  12.460    invariably.
  12.461  
  12.462    Explicit tag specifications within a proof apply to all subsequent
  12.463    commands of the same level of nesting.  For example, ``@{command
  12.464 -  "proof"}~@{text "%visible \<dots>"}~@{command "qed"}'' forces the whole
  12.465 -  sub-proof to be typeset as @{text visible} (unless some of its parts
  12.466 +  "proof"}~\<open>%visible \<dots>\<close>~@{command "qed"}'' forces the whole
  12.467 +  sub-proof to be typeset as \<open>visible\<close> (unless some of its parts
  12.468    are tagged differently).
  12.469  
  12.470    \<^medskip>
  12.471 @@ -491,7 +484,7 @@
  12.472  
  12.473  text \<open>
  12.474    \begin{matharray}{rcl}
  12.475 -    @{antiquotation_def "rail"} & : & @{text antiquotation} \\
  12.476 +    @{antiquotation_def "rail"} & : & \<open>antiquotation\<close> \\
  12.477    \end{matharray}
  12.478  
  12.479    @{rail \<open>
  12.480 @@ -525,12 +518,12 @@
  12.481    \<close>}
  12.482    \endgroup
  12.483  
  12.484 -  The lexical syntax of @{text "identifier"} coincides with that of
  12.485 -  @{syntax ident} in regular Isabelle syntax, but @{text string} uses
  12.486 +  The lexical syntax of \<open>identifier\<close> coincides with that of
  12.487 +  @{syntax ident} in regular Isabelle syntax, but \<open>string\<close> uses
  12.488    single quotes instead of double quotes of the standard @{syntax
  12.489    string} category.
  12.490  
  12.491 -  Each @{text rule} defines a formal language (with optional name),
  12.492 +  Each \<open>rule\<close> defines a formal language (with optional name),
  12.493    using a notation that is similar to EBNF or regular expressions with
  12.494    recursion.  The meaning and visual appearance of these rail language
  12.495    elements is illustrated by the following representative examples.
  12.496 @@ -600,14 +593,14 @@
  12.497  
  12.498  text \<open>
  12.499    \begin{matharray}{rcl}
  12.500 -    @{command_def "display_drafts"}@{text "\<^sup>*"} & : & @{text "any \<rightarrow>"} \\
  12.501 +    @{command_def "display_drafts"}\<open>\<^sup>*\<close> & : & \<open>any \<rightarrow>\<close> \\
  12.502    \end{matharray}
  12.503  
  12.504    @{rail \<open>
  12.505      @@{command display_drafts} (@{syntax name} +)
  12.506    \<close>}
  12.507  
  12.508 -  \<^descr> @{command "display_drafts"}~@{text paths} performs simple output of a
  12.509 +  \<^descr> @{command "display_drafts"}~\<open>paths\<close> performs simple output of a
  12.510    given list of raw source files. Only those symbols that do not require
  12.511    additional {\LaTeX} packages are displayed properly, everything else is left
  12.512    verbatim.
    13.1 --- a/src/Doc/Isar_Ref/First_Order_Logic.thy	Tue Oct 20 23:03:46 2015 +0200
    13.2 +++ b/src/Doc/Isar_Ref/First_Order_Logic.thy	Tue Oct 20 23:53:40 2015 +0200
    13.3 @@ -7,8 +7,8 @@
    13.4  
    13.5  text \<open>
    13.6    In order to commence a new object-logic within
    13.7 -  Isabelle/Pure we introduce abstract syntactic categories @{text "i"}
    13.8 -  for individuals and @{text "o"} for object-propositions.  The latter
    13.9 +  Isabelle/Pure we introduce abstract syntactic categories \<open>i\<close>
   13.10 +  for individuals and \<open>o\<close> for object-propositions.  The latter
   13.11    is embedded into the language of Pure propositions by means of a
   13.12    separate judgment.
   13.13  \<close>
   13.14 @@ -126,8 +126,7 @@
   13.15  text \<open>
   13.16    Reasoning from basic axioms is often tedious.  Our proofs
   13.17    work by producing various instances of the given rules (potentially
   13.18 -  the symmetric form) using the pattern ``@{command have}~@{text
   13.19 -  eq}~@{command "by"}~@{text "(rule r)"}'' and composing the chain of
   13.20 +  the symmetric form) using the pattern ``@{command have}~\<open>eq\<close>~@{command "by"}~\<open>(rule r)\<close>'' and composing the chain of
   13.21    results via @{command also}/@{command finally}.  These steps may
   13.22    involve any of the transitivity rules declared in
   13.23    \secref{sec:framework-ex-equal}, namely @{thm trans} in combining
   13.24 @@ -162,8 +161,7 @@
   13.25    realistic object-logic would include proper setup for the Simplifier
   13.26    (\secref{sec:simplifier}), the main automated tool for equational
   13.27    reasoning in Isabelle.  Then ``@{command unfolding}~@{thm
   13.28 -  left_inv}~@{command ".."}'' would become ``@{command "by"}~@{text
   13.29 -  "(simp only: left_inv)"}'' etc.
   13.30 +  left_inv}~@{command ".."}'' would become ``@{command "by"}~\<open>(simp only: left_inv)\<close>'' etc.
   13.31  \<close>
   13.32  
   13.33  end
   13.34 @@ -228,7 +226,7 @@
   13.35  
   13.36  text \<open>
   13.37    Note that the analogous elimination rule for disjunction
   13.38 -  ``@{text "\<ASSUMES> A \<or> B \<OBTAINS> A \<BBAR> B"}'' coincides with
   13.39 +  ``\<open>\<ASSUMES> A \<or> B \<OBTAINS> A \<BBAR> B\<close>'' coincides with
   13.40    the original axiomatization of @{thm disjE}.
   13.41  
   13.42    \<^medskip>
   13.43 @@ -320,9 +318,9 @@
   13.44    unchanged.  Note that @{prop "(\<not> C \<Longrightarrow> C) \<Longrightarrow> C"} fits again into our
   13.45    format for eliminations, despite the additional twist that the
   13.46    context refers to the main conclusion.  So we may write @{thm
   13.47 -  classical} as the Isar statement ``@{text "\<OBTAINS> \<not> thesis"}''.
   13.48 +  classical} as the Isar statement ``\<open>\<OBTAINS> \<not> thesis\<close>''.
   13.49    This also explains nicely how classical reasoning really works:
   13.50 -  whatever the main @{text thesis} might be, we may always assume its
   13.51 +  whatever the main \<open>thesis\<close> might be, we may always assume its
   13.52    negation!
   13.53  \<close>
   13.54  
   13.55 @@ -335,9 +333,9 @@
   13.56    Representing quantifiers is easy, thanks to the higher-order nature
   13.57    of the underlying framework.  According to the well-known technique
   13.58    introduced by Church @{cite "church40"}, quantifiers are operators on
   13.59 -  predicates, which are syntactically represented as @{text "\<lambda>"}-terms
   13.60 -  of type @{typ "i \<Rightarrow> o"}.  Binder notation turns @{text "All (\<lambda>x. B
   13.61 -  x)"} into @{text "\<forall>x. B x"} etc.
   13.62 +  predicates, which are syntactically represented as \<open>\<lambda>\<close>-terms
   13.63 +  of type @{typ "i \<Rightarrow> o"}.  Binder notation turns \<open>All (\<lambda>x. B
   13.64 +  x)\<close> into \<open>\<forall>x. B x\<close> etc.
   13.65  \<close>
   13.66  
   13.67  axiomatization
   13.68 @@ -351,8 +349,7 @@
   13.69    exE [elim]: "(\<exists>x. B x) \<Longrightarrow> (\<And>x. B x \<Longrightarrow> C) \<Longrightarrow> C"
   13.70  
   13.71  text \<open>
   13.72 -  The statement of @{thm exE} corresponds to ``@{text
   13.73 -  "\<ASSUMES> \<exists>x. B x \<OBTAINS> x \<WHERE> B x"}'' in Isar.  In the
   13.74 +  The statement of @{thm exE} corresponds to ``\<open>\<ASSUMES> \<exists>x. B x \<OBTAINS> x \<WHERE> B x\<close>'' in Isar.  In the
   13.75    subsequent example we illustrate quantifier reasoning involving all
   13.76    four rules:
   13.77  \<close>
   13.78 @@ -360,10 +357,10 @@
   13.79  theorem
   13.80    assumes "\<exists>x. \<forall>y. R x y"
   13.81    shows "\<forall>y. \<exists>x. R x y"
   13.82 -proof    -- \<open>@{text "\<forall>"} introduction\<close>
   13.83 -  obtain x where "\<forall>y. R x y" using \<open>\<exists>x. \<forall>y. R x y\<close> ..    -- \<open>@{text "\<exists>"} elimination\<close>
   13.84 -  fix y have "R x y" using \<open>\<forall>y. R x y\<close> ..    -- \<open>@{text "\<forall>"} destruction\<close>
   13.85 -  then show "\<exists>x. R x y" ..    -- \<open>@{text "\<exists>"} introduction\<close>
   13.86 +proof    -- \<open>\<open>\<forall>\<close> introduction\<close>
   13.87 +  obtain x where "\<forall>y. R x y" using \<open>\<exists>x. \<forall>y. R x y\<close> ..    -- \<open>\<open>\<exists>\<close> elimination\<close>
   13.88 +  fix y have "R x y" using \<open>\<forall>y. R x y\<close> ..    -- \<open>\<open>\<forall>\<close> destruction\<close>
   13.89 +  then show "\<exists>x. R x y" ..    -- \<open>\<open>\<exists>\<close> introduction\<close>
   13.90  qed
   13.91  
   13.92  
   13.93 @@ -377,27 +374,27 @@
   13.94  
   13.95    \<^medskip>
   13.96    \begin{tabular}{l}
   13.97 -  @{text "impI: \<ASSUMES> A \<Longrightarrow> B \<SHOWS> A \<longrightarrow> B"} \\
   13.98 -  @{text "impD: \<ASSUMES> A \<longrightarrow> B \<AND> A \<SHOWS> B"} \\[1ex]
   13.99 +  \<open>impI: \<ASSUMES> A \<Longrightarrow> B \<SHOWS> A \<longrightarrow> B\<close> \\
  13.100 +  \<open>impD: \<ASSUMES> A \<longrightarrow> B \<AND> A \<SHOWS> B\<close> \\[1ex]
  13.101  
  13.102 -  @{text "disjI\<^sub>1: \<ASSUMES> A \<SHOWS> A \<or> B"} \\
  13.103 -  @{text "disjI\<^sub>2: \<ASSUMES> B \<SHOWS> A \<or> B"} \\
  13.104 -  @{text "disjE: \<ASSUMES> A \<or> B \<OBTAINS> A \<BBAR> B"} \\[1ex]
  13.105 +  \<open>disjI\<^sub>1: \<ASSUMES> A \<SHOWS> A \<or> B\<close> \\
  13.106 +  \<open>disjI\<^sub>2: \<ASSUMES> B \<SHOWS> A \<or> B\<close> \\
  13.107 +  \<open>disjE: \<ASSUMES> A \<or> B \<OBTAINS> A \<BBAR> B\<close> \\[1ex]
  13.108  
  13.109 -  @{text "conjI: \<ASSUMES> A \<AND> B \<SHOWS> A \<and> B"} \\
  13.110 -  @{text "conjE: \<ASSUMES> A \<and> B \<OBTAINS> A \<AND> B"} \\[1ex]
  13.111 +  \<open>conjI: \<ASSUMES> A \<AND> B \<SHOWS> A \<and> B\<close> \\
  13.112 +  \<open>conjE: \<ASSUMES> A \<and> B \<OBTAINS> A \<AND> B\<close> \\[1ex]
  13.113  
  13.114 -  @{text "falseE: \<ASSUMES> \<bottom> \<SHOWS> A"} \\
  13.115 -  @{text "trueI: \<SHOWS> \<top>"} \\[1ex]
  13.116 +  \<open>falseE: \<ASSUMES> \<bottom> \<SHOWS> A\<close> \\
  13.117 +  \<open>trueI: \<SHOWS> \<top>\<close> \\[1ex]
  13.118  
  13.119 -  @{text "notI: \<ASSUMES> A \<Longrightarrow> \<bottom> \<SHOWS> \<not> A"} \\
  13.120 -  @{text "notE: \<ASSUMES> \<not> A \<AND> A \<SHOWS> B"} \\[1ex]
  13.121 +  \<open>notI: \<ASSUMES> A \<Longrightarrow> \<bottom> \<SHOWS> \<not> A\<close> \\
  13.122 +  \<open>notE: \<ASSUMES> \<not> A \<AND> A \<SHOWS> B\<close> \\[1ex]
  13.123  
  13.124 -  @{text "allI: \<ASSUMES> \<And>x. B x \<SHOWS> \<forall>x. B x"} \\
  13.125 -  @{text "allE: \<ASSUMES> \<forall>x. B x \<SHOWS> B a"} \\[1ex]
  13.126 +  \<open>allI: \<ASSUMES> \<And>x. B x \<SHOWS> \<forall>x. B x\<close> \\
  13.127 +  \<open>allE: \<ASSUMES> \<forall>x. B x \<SHOWS> B a\<close> \\[1ex]
  13.128  
  13.129 -  @{text "exI: \<ASSUMES> B a \<SHOWS> \<exists>x. B x"} \\
  13.130 -  @{text "exE: \<ASSUMES> \<exists>x. B x \<OBTAINS> a \<WHERE> B a"}
  13.131 +  \<open>exI: \<ASSUMES> B a \<SHOWS> \<exists>x. B x\<close> \\
  13.132 +  \<open>exE: \<ASSUMES> \<exists>x. B x \<OBTAINS> a \<WHERE> B a\<close>
  13.133    \end{tabular}
  13.134    \<^medskip>
  13.135  
    14.1 --- a/src/Doc/Isar_Ref/Framework.thy	Tue Oct 20 23:03:46 2015 +0200
    14.2 +++ b/src/Doc/Isar_Ref/Framework.thy	Tue Oct 20 23:53:40 2015 +0200
    14.3 @@ -27,7 +27,7 @@
    14.4    So Isar challenges the traditional way of recording informal proofs
    14.5    in mathematical prose, as well as the common tendency to see fully
    14.6    formal proofs directly as objects of some logical calculus (e.g.\
    14.7 -  @{text "\<lambda>"}-terms in a version of type theory).  In fact, Isar is
    14.8 +  \<open>\<lambda>\<close>-terms in a version of type theory).  In fact, Isar is
    14.9    better understood as an interpreter of a simple block-structured
   14.10    language for describing the data flow of local facts and goals,
   14.11    interspersed with occasional invocations of proof methods.
   14.12 @@ -58,11 +58,10 @@
   14.13    includes common notions of predicate logic, naive set-theory etc.\
   14.14    using fairly standard mathematical notation.  From the perspective
   14.15    of generic natural deduction there is nothing special about the
   14.16 -  logical connectives of HOL (@{text "\<and>"}, @{text "\<or>"}, @{text "\<forall>"},
   14.17 -  @{text "\<exists>"}, etc.), only the resulting reasoning principles are
   14.18 +  logical connectives of HOL (\<open>\<and>\<close>, \<open>\<or>\<close>, \<open>\<forall>\<close>,
   14.19 +  \<open>\<exists>\<close>, etc.), only the resulting reasoning principles are
   14.20    relevant to the user.  There are similar rules available for
   14.21 -  set-theory operators (@{text "\<inter>"}, @{text "\<union>"}, @{text "\<Inter>"}, @{text
   14.22 -  "\<Union>"}, etc.), or any other theory developed in the library (lattice
   14.23 +  set-theory operators (\<open>\<inter>\<close>, \<open>\<union>\<close>, \<open>\<Inter>\<close>, \<open>\<Union>\<close>, etc.), or any other theory developed in the library (lattice
   14.24    theory, topology etc.).
   14.25  
   14.26    Subsequently we briefly review fragments of Isar proof texts
   14.27 @@ -71,7 +70,7 @@
   14.28    understanding connectives of predicate logic as something special.
   14.29  
   14.30    \<^medskip>
   14.31 -  The following deduction performs @{text "\<inter>"}-introduction,
   14.32 +  The following deduction performs \<open>\<inter>\<close>-introduction,
   14.33    working forwards from assumptions towards the conclusion.  We give
   14.34    both the Isar text, and depict the primitive rule involved, as
   14.35    determined by unification of the problem against rules that are
   14.36 @@ -120,7 +119,7 @@
   14.37  (*>*)
   14.38  
   14.39  text \<open>
   14.40 -  The format of the @{text "\<inter>"}-introduction rule represents
   14.41 +  The format of the \<open>\<inter>\<close>-introduction rule represents
   14.42    the most basic inference, which proceeds from given premises to a
   14.43    conclusion, without any nested proof context involved.
   14.44  
   14.45 @@ -149,7 +148,7 @@
   14.46  text_raw \<open>\end{minipage}\begin{minipage}{0.4\textwidth}\<close>
   14.47  
   14.48  text \<open>
   14.49 -  \infer{@{prop "x \<in> \<Inter>\<A>"}}{\infer*{@{prop "x \<in> A"}}{@{text "[A][A \<in> \<A>]"}}}
   14.50 +  \infer{@{prop "x \<in> \<Inter>\<A>"}}{\infer*{@{prop "x \<in> A"}}{\<open>[A][A \<in> \<A>]\<close>}}
   14.51  \<close>
   14.52  
   14.53  text_raw \<open>\end{minipage}\<close>
   14.54 @@ -159,7 +158,7 @@
   14.55    This Isar reasoning pattern again refers to the
   14.56    primitive rule depicted above.  The system determines it in the
   14.57    ``@{command proof}'' step, which could have been spelled out more
   14.58 -  explicitly as ``@{command proof}~@{text "(rule InterI)"}''.  Note
   14.59 +  explicitly as ``@{command proof}~\<open>(rule InterI)\<close>''.  Note
   14.60    that the rule involves both a local parameter @{term "A"} and an
   14.61    assumption @{prop "A \<in> \<A>"} in the nested reasoning.  This kind of
   14.62    compound rule typically demands a genuine sub-proof in Isar, working
   14.63 @@ -174,7 +173,7 @@
   14.64    The next example involves @{term "\<Union>\<A>"}, which can be
   14.65    characterized as the set of all @{term "x"} such that @{prop "\<exists>A. x
   14.66    \<in> A \<and> A \<in> \<A>"}.  The elimination rule for @{prop "x \<in> \<Union>\<A>"} does
   14.67 -  not mention @{text "\<exists>"} and @{text "\<and>"} at all, but admits to obtain
   14.68 +  not mention \<open>\<exists>\<close> and \<open>\<and>\<close> at all, but admits to obtain
   14.69    directly a local @{term "A"} such that @{prop "x \<in> A"} and @{prop "A
   14.70    \<in> \<A>"} hold.  This corresponds to the following Isar proof and
   14.71    inference rule, respectively:
   14.72 @@ -200,7 +199,7 @@
   14.73  text_raw \<open>\end{minipage}\begin{minipage}{0.4\textwidth}\<close>
   14.74  
   14.75  text \<open>
   14.76 -  \infer{@{prop "C"}}{@{prop "x \<in> \<Union>\<A>"} & \infer*{@{prop "C"}~}{@{text "[A][x \<in> A, A \<in> \<A>]"}}}
   14.77 +  \infer{@{prop "C"}}{@{prop "x \<in> \<Union>\<A>"} & \infer*{@{prop "C"}~}{\<open>[A][x \<in> A, A \<in> \<A>]\<close>}}
   14.78  \<close>
   14.79  
   14.80  text_raw \<open>\end{minipage}\<close>
   14.81 @@ -239,20 +238,19 @@
   14.82  text \<open>
   14.83    The Pure logic @{cite "paulson-found" and "paulson700"} is an intuitionistic
   14.84    fragment of higher-order logic @{cite "church40"}.  In type-theoretic
   14.85 -  parlance, there are three levels of @{text "\<lambda>"}-calculus with
   14.86 -  corresponding arrows @{text "\<Rightarrow>"}/@{text "\<And>"}/@{text "\<Longrightarrow>"}:
   14.87 +  parlance, there are three levels of \<open>\<lambda>\<close>-calculus with
   14.88 +  corresponding arrows \<open>\<Rightarrow>\<close>/\<open>\<And>\<close>/\<open>\<Longrightarrow>\<close>:
   14.89  
   14.90    \<^medskip>
   14.91    \begin{tabular}{ll}
   14.92 -  @{text "\<alpha> \<Rightarrow> \<beta>"} & syntactic function space (terms depending on terms) \\
   14.93 -  @{text "\<And>x. B(x)"} & universal quantification (proofs depending on terms) \\
   14.94 -  @{text "A \<Longrightarrow> B"} & implication (proofs depending on proofs) \\
   14.95 +  \<open>\<alpha> \<Rightarrow> \<beta>\<close> & syntactic function space (terms depending on terms) \\
   14.96 +  \<open>\<And>x. B(x)\<close> & universal quantification (proofs depending on terms) \\
   14.97 +  \<open>A \<Longrightarrow> B\<close> & implication (proofs depending on proofs) \\
   14.98    \end{tabular}
   14.99    \<^medskip>
  14.100  
  14.101    Here only the types of syntactic terms, and the
  14.102 -  propositions of proof terms have been shown.  The @{text
  14.103 -  "\<lambda>"}-structure of proofs can be recorded as an optional feature of
  14.104 +  propositions of proof terms have been shown.  The \<open>\<lambda>\<close>-structure of proofs can be recorded as an optional feature of
  14.105    the Pure inference kernel @{cite "Berghofer-Nipkow:2000:TPHOL"}, but
  14.106    the formal system can never depend on them due to \<^emph>\<open>proof
  14.107    irrelevance\<close>.
  14.108 @@ -260,7 +258,7 @@
  14.109    On top of this most primitive layer of proofs, Pure implements a
  14.110    generic calculus for nested natural deduction rules, similar to
  14.111    @{cite "Schroeder-Heister:1984"}.  Here object-logic inferences are
  14.112 -  internalized as formulae over @{text "\<And>"} and @{text "\<Longrightarrow>"}.
  14.113 +  internalized as formulae over \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close>.
  14.114    Combining such rule statements may involve higher-order unification
  14.115    @{cite "paulson-natural"}.
  14.116  \<close>
  14.117 @@ -269,49 +267,49 @@
  14.118  subsection \<open>Primitive inferences\<close>
  14.119  
  14.120  text \<open>
  14.121 -  Term syntax provides explicit notation for abstraction @{text "\<lambda>x ::
  14.122 -  \<alpha>. b(x)"} and application @{text "b a"}, while types are usually
  14.123 -  implicit thanks to type-inference; terms of type @{text "prop"} are
  14.124 -  called propositions.  Logical statements are composed via @{text "\<And>x
  14.125 -  :: \<alpha>. B(x)"} and @{text "A \<Longrightarrow> B"}.  Primitive reasoning operates on
  14.126 -  judgments of the form @{text "\<Gamma> \<turnstile> \<phi>"}, with standard introduction
  14.127 -  and elimination rules for @{text "\<And>"} and @{text "\<Longrightarrow>"} that refer to
  14.128 -  fixed parameters @{text "x\<^sub>1, \<dots>, x\<^sub>m"} and hypotheses
  14.129 -  @{text "A\<^sub>1, \<dots>, A\<^sub>n"} from the context @{text "\<Gamma>"};
  14.130 +  Term syntax provides explicit notation for abstraction \<open>\<lambda>x ::
  14.131 +  \<alpha>. b(x)\<close> and application \<open>b a\<close>, while types are usually
  14.132 +  implicit thanks to type-inference; terms of type \<open>prop\<close> are
  14.133 +  called propositions.  Logical statements are composed via \<open>\<And>x
  14.134 +  :: \<alpha>. B(x)\<close> and \<open>A \<Longrightarrow> B\<close>.  Primitive reasoning operates on
  14.135 +  judgments of the form \<open>\<Gamma> \<turnstile> \<phi>\<close>, with standard introduction
  14.136 +  and elimination rules for \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> that refer to
  14.137 +  fixed parameters \<open>x\<^sub>1, \<dots>, x\<^sub>m\<close> and hypotheses
  14.138 +  \<open>A\<^sub>1, \<dots>, A\<^sub>n\<close> from the context \<open>\<Gamma>\<close>;
  14.139    the corresponding proof terms are left implicit.  The subsequent
  14.140 -  inference rules define @{text "\<Gamma> \<turnstile> \<phi>"} inductively, relative to a
  14.141 +  inference rules define \<open>\<Gamma> \<turnstile> \<phi>\<close> inductively, relative to a
  14.142    collection of axioms:
  14.143  
  14.144    \[
  14.145 -  \infer{@{text "\<turnstile> A"}}{(@{text "A"} \text{~axiom})}
  14.146 +  \infer{\<open>\<turnstile> A\<close>}{(\<open>A\<close> \text{~axiom})}
  14.147    \qquad
  14.148 -  \infer{@{text "A \<turnstile> A"}}{}
  14.149 +  \infer{\<open>A \<turnstile> A\<close>}{}
  14.150    \]
  14.151  
  14.152    \[
  14.153 -  \infer{@{text "\<Gamma> \<turnstile> \<And>x. B(x)"}}{@{text "\<Gamma> \<turnstile> B(x)"} & @{text "x \<notin> \<Gamma>"}}
  14.154 +  \infer{\<open>\<Gamma> \<turnstile> \<And>x. B(x)\<close>}{\<open>\<Gamma> \<turnstile> B(x)\<close> & \<open>x \<notin> \<Gamma>\<close>}
  14.155    \qquad
  14.156 -  \infer{@{text "\<Gamma> \<turnstile> B(a)"}}{@{text "\<Gamma> \<turnstile> \<And>x. B(x)"}}
  14.157 +  \infer{\<open>\<Gamma> \<turnstile> B(a)\<close>}{\<open>\<Gamma> \<turnstile> \<And>x. B(x)\<close>}
  14.158    \]
  14.159  
  14.160    \[
  14.161 -  \infer{@{text "\<Gamma> - A \<turnstile> A \<Longrightarrow> B"}}{@{text "\<Gamma> \<turnstile> B"}}
  14.162 +  \infer{\<open>\<Gamma> - A \<turnstile> A \<Longrightarrow> B\<close>}{\<open>\<Gamma> \<turnstile> B\<close>}
  14.163    \qquad
  14.164 -  \infer{@{text "\<Gamma>\<^sub>1 \<union> \<Gamma>\<^sub>2 \<turnstile> B"}}{@{text "\<Gamma>\<^sub>1 \<turnstile> A \<Longrightarrow> B"} & @{text "\<Gamma>\<^sub>2 \<turnstile> A"}}
  14.165 +  \infer{\<open>\<Gamma>\<^sub>1 \<union> \<Gamma>\<^sub>2 \<turnstile> B\<close>}{\<open>\<Gamma>\<^sub>1 \<turnstile> A \<Longrightarrow> B\<close> & \<open>\<Gamma>\<^sub>2 \<turnstile> A\<close>}
  14.166    \]
  14.167  
  14.168 -  Furthermore, Pure provides a built-in equality @{text "\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow>
  14.169 -  prop"} with axioms for reflexivity, substitution, extensionality,
  14.170 -  and @{text "\<alpha>\<beta>\<eta>"}-conversion on @{text "\<lambda>"}-terms.
  14.171 +  Furthermore, Pure provides a built-in equality \<open>\<equiv> :: \<alpha> \<Rightarrow> \<alpha> \<Rightarrow>
  14.172 +  prop\<close> with axioms for reflexivity, substitution, extensionality,
  14.173 +  and \<open>\<alpha>\<beta>\<eta>\<close>-conversion on \<open>\<lambda>\<close>-terms.
  14.174  
  14.175    \<^medskip>
  14.176    An object-logic introduces another layer on top of Pure,
  14.177 -  e.g.\ with types @{text "i"} for individuals and @{text "o"} for
  14.178 -  propositions, term constants @{text "Trueprop :: o \<Rightarrow> prop"} as
  14.179 -  (implicit) derivability judgment and connectives like @{text "\<and> :: o
  14.180 -  \<Rightarrow> o \<Rightarrow> o"} or @{text "\<forall> :: (i \<Rightarrow> o) \<Rightarrow> o"}, and axioms for object-level
  14.181 -  rules such as @{text "conjI: A \<Longrightarrow> B \<Longrightarrow> A \<and> B"} or @{text "allI: (\<And>x. B
  14.182 -  x) \<Longrightarrow> \<forall>x. B x"}.  Derived object rules are represented as theorems of
  14.183 +  e.g.\ with types \<open>i\<close> for individuals and \<open>o\<close> for
  14.184 +  propositions, term constants \<open>Trueprop :: o \<Rightarrow> prop\<close> as
  14.185 +  (implicit) derivability judgment and connectives like \<open>\<and> :: o
  14.186 +  \<Rightarrow> o \<Rightarrow> o\<close> or \<open>\<forall> :: (i \<Rightarrow> o) \<Rightarrow> o\<close>, and axioms for object-level
  14.187 +  rules such as \<open>conjI: A \<Longrightarrow> B \<Longrightarrow> A \<and> B\<close> or \<open>allI: (\<And>x. B
  14.188 +  x) \<Longrightarrow> \<forall>x. B x\<close>.  Derived object rules are represented as theorems of
  14.189    Pure.  After the initial object-logic setup, further axiomatizations
  14.190    are usually avoided; plain definitions and derived principles are
  14.191    used exclusively.
  14.192 @@ -323,51 +321,50 @@
  14.193  text \<open>
  14.194    Primitive inferences mostly serve foundational purposes.  The main
  14.195    reasoning mechanisms of Pure operate on nested natural deduction
  14.196 -  rules expressed as formulae, using @{text "\<And>"} to bind local
  14.197 -  parameters and @{text "\<Longrightarrow>"} to express entailment.  Multiple
  14.198 +  rules expressed as formulae, using \<open>\<And>\<close> to bind local
  14.199 +  parameters and \<open>\<Longrightarrow>\<close> to express entailment.  Multiple
  14.200    parameters and premises are represented by repeating these
  14.201    connectives in a right-associative manner.
  14.202  
  14.203 -  Since @{text "\<And>"} and @{text "\<Longrightarrow>"} commute thanks to the theorem
  14.204 +  Since \<open>\<And>\<close> and \<open>\<Longrightarrow>\<close> commute thanks to the theorem
  14.205    @{prop "(A \<Longrightarrow> (\<And>x. B x)) \<equiv> (\<And>x. A \<Longrightarrow> B x)"}, we may assume w.l.o.g.\
  14.206    that rule statements always observe the normal form where
  14.207    quantifiers are pulled in front of implications at each level of
  14.208    nesting.  This means that any Pure proposition may be presented as a
  14.209    \<^emph>\<open>Hereditary Harrop Formula\<close> @{cite "Miller:1991"} which is of the
  14.210 -  form @{text "\<And>x\<^sub>1 \<dots> x\<^sub>m. H\<^sub>1 \<Longrightarrow> \<dots> H\<^sub>n \<Longrightarrow>
  14.211 -  A"} for @{text "m, n \<ge> 0"}, and @{text "A"} atomic, and @{text
  14.212 -  "H\<^sub>1, \<dots>, H\<^sub>n"} being recursively of the same format.
  14.213 +  form \<open>\<And>x\<^sub>1 \<dots> x\<^sub>m. H\<^sub>1 \<Longrightarrow> \<dots> H\<^sub>n \<Longrightarrow>
  14.214 +  A\<close> for \<open>m, n \<ge> 0\<close>, and \<open>A\<close> atomic, and \<open>H\<^sub>1, \<dots>, H\<^sub>n\<close> being recursively of the same format.
  14.215    Following the convention that outermost quantifiers are implicit,
  14.216 -  Horn clauses @{text "A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> A"} are a special
  14.217 +  Horn clauses \<open>A\<^sub>1 \<Longrightarrow> \<dots> A\<^sub>n \<Longrightarrow> A\<close> are a special
  14.218    case of this.
  14.219  
  14.220 -  For example, @{text "\<inter>"}-introduction rule encountered before is
  14.221 +  For example, \<open>\<inter>\<close>-introduction rule encountered before is
  14.222    represented as a Pure theorem as follows:
  14.223    \[
  14.224 -  @{text "IntI:"}~@{prop "x \<in> A \<Longrightarrow> x \<in> B \<Longrightarrow> x \<in> A \<inter> B"}
  14.225 +  \<open>IntI:\<close>~@{prop "x \<in> A \<Longrightarrow> x \<in> B \<Longrightarrow> x \<in> A \<inter> B"}
  14.226    \]
  14.227  
  14.228    This is a plain Horn clause, since no further nesting on
  14.229 -  the left is involved.  The general @{text "\<Inter>"}-introduction
  14.230 +  the left is involved.  The general \<open>\<Inter>\<close>-introduction
  14.231    corresponds to a Hereditary Harrop Formula with one additional level
  14.232    of nesting:
  14.233    \[
  14.234 -  @{text "InterI:"}~@{prop "(\<And>A. A \<in> \<A> \<Longrightarrow> x \<in> A) \<Longrightarrow> x \<in> \<Inter>\<A>"}
  14.235 +  \<open>InterI:\<close>~@{prop "(\<And>A. A \<in> \<A> \<Longrightarrow> x \<in> A) \<Longrightarrow> x \<in> \<Inter>\<A>"}
  14.236    \]
  14.237  
  14.238    \<^medskip>
  14.239 -  Goals are also represented as rules: @{text "A\<^sub>1 \<Longrightarrow>
  14.240 -  \<dots> A\<^sub>n \<Longrightarrow> C"} states that the sub-goals @{text "A\<^sub>1, \<dots>,
  14.241 -  A\<^sub>n"} entail the result @{text "C"}; for @{text "n = 0"} the
  14.242 -  goal is finished.  To allow @{text "C"} being a rule statement
  14.243 -  itself, we introduce the protective marker @{text "# :: prop \<Rightarrow>
  14.244 -  prop"}, which is defined as identity and hidden from the user.  We
  14.245 +  Goals are also represented as rules: \<open>A\<^sub>1 \<Longrightarrow>
  14.246 +  \<dots> A\<^sub>n \<Longrightarrow> C\<close> states that the sub-goals \<open>A\<^sub>1, \<dots>,
  14.247 +  A\<^sub>n\<close> entail the result \<open>C\<close>; for \<open>n = 0\<close> the
  14.248 +  goal is finished.  To allow \<open>C\<close> being a rule statement
  14.249 +  itself, we introduce the protective marker \<open># :: prop \<Rightarrow>
  14.250 +  prop\<close>, which is defined as identity and hidden from the user.  We
  14.251    initialize and finish goal states as follows:
  14.252  
  14.253    \[
  14.254    \begin{array}{c@ {\qquad}c}
  14.255 -  \infer[(@{inference_def init})]{@{text "C \<Longrightarrow> #C"}}{} &
  14.256 -  \infer[(@{inference_def finish})]{@{text C}}{@{text "#C"}}
  14.257 +  \infer[(@{inference_def init})]{\<open>C \<Longrightarrow> #C\<close>}{} &
  14.258 +  \infer[(@{inference_def finish})]{\<open>C\<close>}{\<open>#C\<close>}
  14.259    \end{array}
  14.260    \]
  14.261  
  14.262 @@ -376,30 +373,29 @@
  14.263    are @{inference resolution}, for back-chaining a rule against a
  14.264    sub-goal (replacing it by zero or more sub-goals), and @{inference
  14.265    assumption}, for solving a sub-goal (finding a short-circuit with
  14.266 -  local assumptions).  Below @{text "\<^vec>x"} stands for @{text
  14.267 -  "x\<^sub>1, \<dots>, x\<^sub>n"} (@{text "n \<ge> 0"}).
  14.268 +  local assumptions).  Below \<open>\<^vec>x\<close> stands for \<open>x\<^sub>1, \<dots>, x\<^sub>n\<close> (\<open>n \<ge> 0\<close>).
  14.269  
  14.270    \[
  14.271    \infer[(@{inference_def resolution})]
  14.272 -  {@{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>A (\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>"}}
  14.273 +  {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>A (\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
  14.274    {\begin{tabular}{rl}
  14.275 -    @{text "rule:"} &
  14.276 -    @{text "\<^vec>A \<^vec>a \<Longrightarrow> B \<^vec>a"} \\
  14.277 -    @{text "goal:"} &
  14.278 -    @{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C"} \\
  14.279 -    @{text "goal unifier:"} &
  14.280 -    @{text "(\<lambda>\<^vec>x. B (\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>"} \\
  14.281 +    \<open>rule:\<close> &
  14.282 +    \<open>\<^vec>A \<^vec>a \<Longrightarrow> B \<^vec>a\<close> \\
  14.283 +    \<open>goal:\<close> &
  14.284 +    \<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C\<close> \\
  14.285 +    \<open>goal unifier:\<close> &
  14.286 +    \<open>(\<lambda>\<^vec>x. B (\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>\<close> \\
  14.287     \end{tabular}}
  14.288    \]
  14.289  
  14.290    \<^medskip>
  14.291  
  14.292    \[
  14.293 -  \infer[(@{inference_def assumption})]{@{text "C\<vartheta>"}}
  14.294 +  \infer[(@{inference_def assumption})]{\<open>C\<vartheta>\<close>}
  14.295    {\begin{tabular}{rl}
  14.296 -    @{text "goal:"} &
  14.297 -    @{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> A \<^vec>x) \<Longrightarrow> C"} \\
  14.298 -    @{text "assm unifier:"} & @{text "A\<vartheta> = H\<^sub>i\<vartheta>"}~~\text{(for some~@{text "H\<^sub>i"})} \\
  14.299 +    \<open>goal:\<close> &
  14.300 +    \<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> A \<^vec>x) \<Longrightarrow> C\<close> \\
  14.301 +    \<open>assm unifier:\<close> & \<open>A\<vartheta> = H\<^sub>i\<vartheta>\<close>~~\text{(for some~\<open>H\<^sub>i\<close>)} \\
  14.302     \end{tabular}}
  14.303    \]
  14.304  
  14.305 @@ -409,13 +405,13 @@
  14.306    {\footnotesize
  14.307    \<^medskip>
  14.308    \begin{tabular}{r@ {\quad}l}
  14.309 -  @{text "(A \<and> B \<Longrightarrow> B \<and> A) \<Longrightarrow> #(A \<and> B \<Longrightarrow> B \<and> A)"} & @{text "(init)"} \\
  14.310 -  @{text "(A \<and> B \<Longrightarrow> B) \<Longrightarrow> (A \<and> B \<Longrightarrow> A) \<Longrightarrow> #\<dots>"} & @{text "(resolution B \<Longrightarrow> A \<Longrightarrow> B \<and> A)"} \\
  14.311 -  @{text "(A \<and> B \<Longrightarrow> A \<and> B) \<Longrightarrow> (A \<and> B \<Longrightarrow> A) \<Longrightarrow> #\<dots>"} & @{text "(resolution A \<and> B \<Longrightarrow> B)"} \\
  14.312 -  @{text "(A \<and> B \<Longrightarrow> A) \<Longrightarrow> #\<dots>"} & @{text "(assumption)"} \\
  14.313 -  @{text "(A \<and> B \<Longrightarrow> A \<and> B) \<Longrightarrow> #\<dots>"} & @{text "(resolution A \<and> B \<Longrightarrow> A)"} \\
  14.314 -  @{text "#\<dots>"} & @{text "(assumption)"} \\
  14.315 -  @{text "A \<and> B \<Longrightarrow> B \<and> A"} & @{text "(finish)"} \\
  14.316 +  \<open>(A \<and> B \<Longrightarrow> B \<and> A) \<Longrightarrow> #(A \<and> B \<Longrightarrow> B \<and> A)\<close> & \<open>(init)\<close> \\
  14.317 +  \<open>(A \<and> B \<Longrightarrow> B) \<Longrightarrow> (A \<and> B \<Longrightarrow> A) \<Longrightarrow> #\<dots>\<close> & \<open>(resolution B \<Longrightarrow> A \<Longrightarrow> B \<and> A)\<close> \\
  14.318 +  \<open>(A \<and> B \<Longrightarrow> A \<and> B) \<Longrightarrow> (A \<and> B \<Longrightarrow> A) \<Longrightarrow> #\<dots>\<close> & \<open>(resolution A \<and> B \<Longrightarrow> B)\<close> \\
  14.319 +  \<open>(A \<and> B \<Longrightarrow> A) \<Longrightarrow> #\<dots>\<close> & \<open>(assumption)\<close> \\
  14.320 +  \<open>(A \<and> B \<Longrightarrow> A \<and> B) \<Longrightarrow> #\<dots>\<close> & \<open>(resolution A \<and> B \<Longrightarrow> A)\<close> \\
  14.321 +  \<open>#\<dots>\<close> & \<open>(assumption)\<close> \\
  14.322 +  \<open>A \<and> B \<Longrightarrow> B \<and> A\<close> & \<open>(finish)\<close> \\
  14.323    \end{tabular}
  14.324    \<^medskip>
  14.325    }
  14.326 @@ -426,28 +422,28 @@
  14.327    @{inference_def elim_resolution} principle.  In contrast, Isar uses
  14.328    a slightly more refined combination, where the assumptions to be
  14.329    closed are marked explicitly, using again the protective marker
  14.330 -  @{text "#"}:
  14.331 +  \<open>#\<close>:
  14.332  
  14.333    \[
  14.334    \infer[(@{inference refinement})]
  14.335 -  {@{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>G' (\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>"}}
  14.336 +  {\<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> \<^vec>G' (\<^vec>a \<^vec>x))\<vartheta> \<Longrightarrow> C\<vartheta>\<close>}
  14.337    {\begin{tabular}{rl}
  14.338 -    @{text "sub\<hyphen>proof:"} &
  14.339 -    @{text "\<^vec>G \<^vec>a \<Longrightarrow> B \<^vec>a"} \\
  14.340 -    @{text "goal:"} &
  14.341 -    @{text "(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C"} \\
  14.342 -    @{text "goal unifier:"} &
  14.343 -    @{text "(\<lambda>\<^vec>x. B (\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>"} \\
  14.344 -    @{text "assm unifiers:"} &
  14.345 -    @{text "(\<lambda>\<^vec>x. G\<^sub>j (\<^vec>a \<^vec>x))\<vartheta> = #H\<^sub>i\<vartheta>"} \\
  14.346 -    & \quad (for each marked @{text "G\<^sub>j"} some @{text "#H\<^sub>i"}) \\
  14.347 +    \<open>sub\<hyphen>proof:\<close> &
  14.348 +    \<open>\<^vec>G \<^vec>a \<Longrightarrow> B \<^vec>a\<close> \\
  14.349 +    \<open>goal:\<close> &
  14.350 +    \<open>(\<And>\<^vec>x. \<^vec>H \<^vec>x \<Longrightarrow> B' \<^vec>x) \<Longrightarrow> C\<close> \\
  14.351 +    \<open>goal unifier:\<close> &
  14.352 +    \<open>(\<lambda>\<^vec>x. B (\<^vec>a \<^vec>x))\<vartheta> = B'\<vartheta>\<close> \\
  14.353 +    \<open>assm unifiers:\<close> &
  14.354 +    \<open>(\<lambda>\<^vec>x. G\<^sub>j (\<^vec>a \<^vec>x))\<vartheta> = #H\<^sub>i\<vartheta>\<close> \\
  14.355 +    & \quad (for each marked \<open>G\<^sub>j\<close> some \<open>#H\<^sub>i\<close>) \\
  14.356     \end{tabular}}
  14.357    \]
  14.358  
  14.359 -  Here the @{text "sub\<hyphen>proof"} rule stems from the
  14.360 +  Here the \<open>sub\<hyphen>proof\<close> rule stems from the
  14.361    main @{command fix}-@{command assume}-@{command show} outline of
  14.362    Isar (cf.\ \secref{sec:framework-subproof}): each assumption
  14.363 -  indicated in the text results in a marked premise @{text "G"} above.
  14.364 +  indicated in the text results in a marked premise \<open>G\<close> above.
  14.365    The marking enforces resolution against one of the sub-goal's
  14.366    premises.  Consequently, @{command fix}-@{command assume}-@{command
  14.367    show} enables to fit the result of a sub-proof quite robustly into a
  14.368 @@ -467,29 +463,28 @@
  14.369    Isar is an exercise in sound minimalism.  Approximately half of the
  14.370    language is introduced as primitive, the rest defined as derived
  14.371    concepts.  The following grammar describes the core language
  14.372 -  (category @{text "proof"}), which is embedded into theory
  14.373 +  (category \<open>proof\<close>), which is embedded into theory
  14.374    specification elements such as @{command theorem}; see also
  14.375 -  \secref{sec:framework-stmt} for the separate category @{text
  14.376 -  "statement"}.
  14.377 +  \secref{sec:framework-stmt} for the separate category \<open>statement\<close>.
  14.378  
  14.379    \<^medskip>
  14.380    \begin{tabular}{rcl}
  14.381 -    @{text "theory\<hyphen>stmt"} & = & @{command "theorem"}~@{text "statement proof  |"}~~@{command "definition"}~@{text "\<dots>  |  \<dots>"} \\[1ex]
  14.382 +    \<open>theory\<hyphen>stmt\<close> & = & @{command "theorem"}~\<open>statement proof  |\<close>~~@{command "definition"}~\<open>\<dots>  |  \<dots>\<close> \\[1ex]
  14.383  
  14.384 -    @{text "proof"} & = & @{text "prfx\<^sup>*"}~@{command "proof"}~@{text "method\<^sup>? stmt\<^sup>*"}~@{command "qed"}~@{text "method\<^sup>?"} \\[1ex]
  14.385 +    \<open>proof\<close> & = & \<open>prfx\<^sup>*\<close>~@{command "proof"}~\<open>method\<^sup>? stmt\<^sup>*\<close>~@{command "qed"}~\<open>method\<^sup>?\<close> \\[1ex]
  14.386  
  14.387 -    @{text prfx} & = & @{command "using"}~@{text "facts"} \\
  14.388 -    & @{text "|"} & @{command "unfolding"}~@{text "facts"} \\
  14.389 +    \<open>prfx\<close> & = & @{command "using"}~\<open>facts\<close> \\
  14.390 +    & \<open>|\<close> & @{command "unfolding"}~\<open>facts\<close> \\
  14.391  
  14.392 -    @{text stmt} & = & @{command "{"}~@{text "stmt\<^sup>*"}~@{command "}"} \\
  14.393 -    & @{text "|"} & @{command "next"} \\
  14.394 -    & @{text "|"} & @{command "note"}~@{text "name = facts"} \\
  14.395 -    & @{text "|"} & @{command "let"}~@{text "term = term"} \\
  14.396 -    & @{text "|"} & @{command "fix"}~@{text "var\<^sup>+"} \\
  14.397 -    & @{text "|"} & @{command assume}~@{text "\<guillemotleft>inference\<guillemotright> name: props"} \\
  14.398 -    & @{text "|"} & @{command "then"}@{text "\<^sup>?"}~@{text goal} \\
  14.399 -    @{text goal} & = & @{command "have"}~@{text "name: props proof"} \\
  14.400 -    & @{text "|"} & @{command "show"}~@{text "name: props proof"} \\
  14.401 +    \<open>stmt\<close> & = & @{command "{"}~\<open>stmt\<^sup>*\<close>~@{command "}"} \\
  14.402 +    & \<open>|\<close> & @{command "next"} \\
  14.403 +    & \<open>|\<close> & @{command "note"}~\<open>name = facts\<close> \\
  14.404 +    & \<open>|\<close> & @{command "let"}~\<open>term = term\<close> \\
  14.405 +    & \<open>|\<close> & @{command "fix"}~\<open>var\<^sup>+\<close> \\
  14.406 +    & \<open>|\<close> & @{command assume}~\<open>\<guillemotleft>inference\<guillemotright> name: props\<close> \\
  14.407 +    & \<open>|\<close> & @{command "then"}\<open>\<^sup>?\<close>~\<open>goal\<close> \\
  14.408 +    \<open>goal\<close> & = & @{command "have"}~\<open>name: props proof\<close> \\
  14.409 +    & \<open>|\<close> & @{command "show"}~\<open>name: props proof\<close> \\
  14.410    \end{tabular}
  14.411  
  14.412    \<^medskip>
  14.413 @@ -498,20 +493,19 @@
  14.414  
  14.415    \<^medskip>
  14.416    The syntax for terms and propositions is inherited from
  14.417 -  Pure (and the object-logic).  A @{text "pattern"} is a @{text
  14.418 -  "term"} with schematic variables, to be bound by higher-order
  14.419 +  Pure (and the object-logic).  A \<open>pattern\<close> is a \<open>term\<close> with schematic variables, to be bound by higher-order
  14.420    matching.
  14.421  
  14.422    \<^medskip>
  14.423    Facts may be referenced by name or proposition.  For
  14.424 -  example, the result of ``@{command have}~@{text "a: A \<langle>proof\<rangle>"}''
  14.425 -  becomes available both as @{text "a"} and
  14.426 -  \isacharbackquoteopen@{text "A"}\isacharbackquoteclose.  Moreover,
  14.427 +  example, the result of ``@{command have}~\<open>a: A \<langle>proof\<rangle>\<close>''
  14.428 +  becomes available both as \<open>a\<close> and
  14.429 +  \isacharbackquoteopen\<open>A\<close>\isacharbackquoteclose.  Moreover,
  14.430    fact expressions may involve attributes that modify either the
  14.431    theorem or the background context.  For example, the expression
  14.432 -  ``@{text "a [OF b]"}'' refers to the composition of two facts
  14.433 +  ``\<open>a [OF b]\<close>'' refers to the composition of two facts
  14.434    according to the @{inference resolution} inference of
  14.435 -  \secref{sec:framework-resolution}, while ``@{text "a [intro]"}''
  14.436 +  \secref{sec:framework-resolution}, while ``\<open>a [intro]\<close>''
  14.437    declares a fact as introduction rule in the context.
  14.438  
  14.439    The special fact called ``@{fact this}'' always refers to the last
  14.440 @@ -522,12 +516,12 @@
  14.441  
  14.442    \<^medskip>
  14.443    \begin{tabular}{rcl}
  14.444 -    @{command from}~@{text a} & @{text "\<equiv>"} & @{command note}~@{text a}~@{command then} \\
  14.445 -    @{command with}~@{text a} & @{text "\<equiv>"} & @{command from}~@{text "a \<AND> this"} \\
  14.446 +    @{command from}~\<open>a\<close> & \<open>\<equiv>\<close> & @{command note}~\<open>a\<close>~@{command then} \\
  14.447 +    @{command with}~\<open>a\<close> & \<open>\<equiv>\<close> & @{command from}~\<open>a \<AND> this\<close> \\
  14.448    \end{tabular}
  14.449    \<^medskip>
  14.450  
  14.451 -  The @{text "method"} category is essentially a parameter and may be
  14.452 +  The \<open>method\<close> category is essentially a parameter and may be
  14.453    populated later.  Methods use the facts indicated by @{command
  14.454    "then"} or @{command using}, and then operate on the goal state.
  14.455    Some basic methods are predefined: ``@{method "-"}'' leaves the goal
  14.456 @@ -536,8 +530,8 @@
  14.457    result to the goal (both ``@{method this}'' and ``@{method (Pure) rule}''
  14.458    refer to @{inference resolution} of
  14.459    \secref{sec:framework-resolution}).  The secondary arguments to
  14.460 -  ``@{method (Pure) rule}'' may be specified explicitly as in ``@{text "(rule
  14.461 -  a)"}'', or picked from the context.  In the latter case, the system
  14.462 +  ``@{method (Pure) rule}'' may be specified explicitly as in ``\<open>(rule
  14.463 +  a)\<close>'', or picked from the context.  In the latter case, the system
  14.464    first tries rules declared as @{attribute (Pure) elim} or
  14.465    @{attribute (Pure) dest}, followed by those declared as @{attribute
  14.466    (Pure) intro}.
  14.467 @@ -545,16 +539,15 @@
  14.468    The default method for @{command proof} is ``@{method standard}''
  14.469    (arguments picked from the context), for @{command qed} it is
  14.470    ``@{method "succeed"}''.  Further abbreviations for terminal proof steps
  14.471 -  are ``@{command "by"}~@{text "method\<^sub>1 method\<^sub>2"}'' for
  14.472 -  ``@{command proof}~@{text "method\<^sub>1"}~@{command qed}~@{text
  14.473 -  "method\<^sub>2"}'', and ``@{command ".."}'' for ``@{command
  14.474 +  are ``@{command "by"}~\<open>method\<^sub>1 method\<^sub>2\<close>'' for
  14.475 +  ``@{command proof}~\<open>method\<^sub>1\<close>~@{command qed}~\<open>method\<^sub>2\<close>'', and ``@{command ".."}'' for ``@{command
  14.476    "by"}~@{method standard}, and ``@{command "."}'' for ``@{command
  14.477    "by"}~@{method this}''.  The @{command unfolding} element operates
  14.478    directly on the current facts and goal by applying equalities.
  14.479  
  14.480    \<^medskip>
  14.481    Block structure can be indicated explicitly by ``@{command
  14.482 -  "{"}~@{text "\<dots>"}~@{command "}"}'', although the body of a sub-proof
  14.483 +  "{"}~\<open>\<dots>\<close>~@{command "}"}'', although the body of a sub-proof
  14.484    already involves implicit nesting.  In any case, @{command next}
  14.485    jumps into the next section of a block, i.e.\ it acts like closing
  14.486    an implicit block scope and opening another one; there is no direct
  14.487 @@ -572,20 +565,18 @@
  14.488  subsection \<open>Context elements \label{sec:framework-context}\<close>
  14.489  
  14.490  text \<open>
  14.491 -  In judgments @{text "\<Gamma> \<turnstile> \<phi>"} of the primitive framework, @{text "\<Gamma>"}
  14.492 +  In judgments \<open>\<Gamma> \<turnstile> \<phi>\<close> of the primitive framework, \<open>\<Gamma>\<close>
  14.493    essentially acts like a proof context.  Isar elaborates this idea
  14.494    towards a higher-level notion, with additional information for
  14.495    type-inference, term abbreviations, local facts, hypotheses etc.
  14.496  
  14.497 -  The element @{command fix}~@{text "x :: \<alpha>"} declares a local
  14.498 +  The element @{command fix}~\<open>x :: \<alpha>\<close> declares a local
  14.499    parameter, i.e.\ an arbitrary-but-fixed entity of a given type; in
  14.500 -  results exported from the context, @{text "x"} may become anything.
  14.501 -  The @{command assume}~@{text "\<guillemotleft>inference\<guillemotright>"} element provides a
  14.502 -  general interface to hypotheses: ``@{command assume}~@{text
  14.503 -  "\<guillemotleft>inference\<guillemotright> A"}'' produces @{text "A \<turnstile> A"} locally, while the
  14.504 -  included inference tells how to discharge @{text A} from results
  14.505 -  @{text "A \<turnstile> B"} later on.  There is no user-syntax for @{text
  14.506 -  "\<guillemotleft>inference\<guillemotright>"}, i.e.\ it may only occur internally when derived
  14.507 +  results exported from the context, \<open>x\<close> may become anything.
  14.508 +  The @{command assume}~\<open>\<guillemotleft>inference\<guillemotright>\<close> element provides a
  14.509 +  general interface to hypotheses: ``@{command assume}~\<open>\<guillemotleft>inference\<guillemotright> A\<close>'' produces \<open>A \<turnstile> A\<close> locally, while the
  14.510 +  included inference tells how to discharge \<open>A\<close> from results
  14.511 +  \<open>A \<turnstile> B\<close> later on.  There is no user-syntax for \<open>\<guillemotleft>inference\<guillemotright>\<close>, i.e.\ it may only occur internally when derived
  14.512    commands are defined in ML.
  14.513  
  14.514    At the user-level, the default inference for @{command assume} is
  14.515 @@ -594,19 +585,19 @@
  14.516  
  14.517    \<^medskip>
  14.518    \begin{tabular}{rcl}
  14.519 -    @{command presume}~@{text A} & @{text "\<equiv>"} & @{command assume}~@{text "\<guillemotleft>weak\<hyphen>discharge\<guillemotright> A"} \\
  14.520 -    @{command def}~@{text "x \<equiv> a"} & @{text "\<equiv>"} & @{command fix}~@{text x}~@{command assume}~@{text "\<guillemotleft>expansion\<guillemotright> x \<equiv> a"} \\
  14.521 +    @{command presume}~\<open>A\<close> & \<open>\<equiv>\<close> & @{command assume}~\<open>\<guillemotleft>weak\<hyphen>discharge\<guillemotright> A\<close> \\
  14.522 +    @{command def}~\<open>x \<equiv> a\<close> & \<open>\<equiv>\<close> & @{command fix}~\<open>x\<close>~@{command assume}~\<open>\<guillemotleft>expansion\<guillemotright> x \<equiv> a\<close> \\
  14.523    \end{tabular}
  14.524    \<^medskip>
  14.525  
  14.526    \[
  14.527 -  \infer[(@{inference_def discharge})]{@{text "\<strut>\<Gamma> - A \<turnstile> #A \<Longrightarrow> B"}}{@{text "\<strut>\<Gamma> \<turnstile> B"}}
  14.528 +  \infer[(@{inference_def discharge})]{\<open>\<strut>\<Gamma> - A \<turnstile> #A \<Longrightarrow> B\<close>}{\<open>\<strut>\<Gamma> \<turnstile> B\<close>}
  14.529    \]
  14.530    \[
  14.531 -  \infer[(@{inference_def "weak\<hyphen>discharge"})]{@{text "\<strut>\<Gamma> - A \<turnstile> A \<Longrightarrow> B"}}{@{text "\<strut>\<Gamma> \<turnstile> B"}}
  14.532 +  \infer[(@{inference_def "weak\<hyphen>discharge"})]{\<open>\<strut>\<Gamma> - A \<turnstile> A \<Longrightarrow> B\<close>}{\<open>\<strut>\<Gamma> \<turnstile> B\<close>}
  14.533    \]
  14.534    \[
  14.535 -  \infer[(@{inference_def expansion})]{@{text "\<strut>\<Gamma> - (x \<equiv> a) \<turnstile> B a"}}{@{text "\<strut>\<Gamma> \<turnstile> B x"}}
  14.536 +  \infer[(@{inference_def expansion})]{\<open>\<strut>\<Gamma> - (x \<equiv> a) \<turnstile> B a\<close>}{\<open>\<strut>\<Gamma> \<turnstile> B x\<close>}
  14.537    \]
  14.538  
  14.539    \<^medskip>
  14.540 @@ -619,42 +610,42 @@
  14.541    The most interesting derived context element in Isar is @{command
  14.542    obtain} @{cite \<open>\S5.3\<close> "Wenzel-PhD"}, which supports generalized
  14.543    elimination steps in a purely forward manner.  The @{command obtain}
  14.544 -  command takes a specification of parameters @{text "\<^vec>x"} and
  14.545 -  assumptions @{text "\<^vec>A"} to be added to the context, together
  14.546 +  command takes a specification of parameters \<open>\<^vec>x\<close> and
  14.547 +  assumptions \<open>\<^vec>A\<close> to be added to the context, together
  14.548    with a proof of a case rule stating that this extension is
  14.549    conservative (i.e.\ may be removed from closed results later on):
  14.550  
  14.551    \<^medskip>
  14.552    \begin{tabular}{l}
  14.553 -  @{text "\<langle>facts\<rangle>"}~~@{command obtain}~@{text "\<^vec>x \<WHERE> \<^vec>A \<^vec>x  \<langle>proof\<rangle> \<equiv>"} \\[0.5ex]
  14.554 -  \quad @{command have}~@{text "case: \<And>thesis. (\<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis) \<Longrightarrow> thesis\<rangle>"} \\
  14.555 +  \<open>\<langle>facts\<rangle>\<close>~~@{command obtain}~\<open>\<^vec>x \<WHERE> \<^vec>A \<^vec>x  \<langle>proof\<rangle> \<equiv>\<close> \\[0.5ex]
  14.556 +  \quad @{command have}~\<open>case: \<And>thesis. (\<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis) \<Longrightarrow> thesis\<rangle>\<close> \\
  14.557    \quad @{command proof}~@{method "-"} \\
  14.558 -  \qquad @{command fix}~@{text thesis} \\
  14.559 -  \qquad @{command assume}~@{text "[intro]: \<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis"} \\
  14.560 -  \qquad @{command show}~@{text thesis}~@{command using}~@{text "\<langle>facts\<rangle> \<langle>proof\<rangle>"} \\
  14.561 +  \qquad @{command fix}~\<open>thesis\<close> \\
  14.562 +  \qquad @{command assume}~\<open>[intro]: \<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis\<close> \\
  14.563 +  \qquad @{command show}~\<open>thesis\<close>~@{command using}~\<open>\<langle>facts\<rangle> \<langle>proof\<rangle>\<close> \\
  14.564    \quad @{command qed} \\
  14.565 -  \quad @{command fix}~@{text "\<^vec>x"}~@{command assume}~@{text "\<guillemotleft>elimination case\<guillemotright> \<^vec>A \<^vec>x"} \\
  14.566 +  \quad @{command fix}~\<open>\<^vec>x\<close>~@{command assume}~\<open>\<guillemotleft>elimination case\<guillemotright> \<^vec>A \<^vec>x\<close> \\
  14.567    \end{tabular}
  14.568    \<^medskip>
  14.569  
  14.570    \[
  14.571 -  \infer[(@{inference elimination})]{@{text "\<Gamma> \<turnstile> B"}}{
  14.572 +  \infer[(@{inference elimination})]{\<open>\<Gamma> \<turnstile> B\<close>}{
  14.573      \begin{tabular}{rl}
  14.574 -    @{text "case:"} &
  14.575 -    @{text "\<Gamma> \<turnstile> \<And>thesis. (\<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis) \<Longrightarrow> thesis"} \\[0.2ex]
  14.576 -    @{text "result:"} &
  14.577 -    @{text "\<Gamma> \<union> \<^vec>A \<^vec>y \<turnstile> B"} \\[0.2ex]
  14.578 +    \<open>case:\<close> &
  14.579 +    \<open>\<Gamma> \<turnstile> \<And>thesis. (\<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis) \<Longrightarrow> thesis\<close> \\[0.2ex]
  14.580 +    \<open>result:\<close> &
  14.581 +    \<open>\<Gamma> \<union> \<^vec>A \<^vec>y \<turnstile> B\<close> \\[0.2ex]
  14.582      \end{tabular}}
  14.583    \]
  14.584  
  14.585 -  Here the name ``@{text thesis}'' is a specific convention
  14.586 +  Here the name ``\<open>thesis\<close>'' is a specific convention
  14.587    for an arbitrary-but-fixed proposition; in the primitive natural
  14.588 -  deduction rules shown before we have occasionally used @{text C}.
  14.589 -  The whole statement of ``@{command obtain}~@{text x}~@{keyword
  14.590 -  "where"}~@{text "A x"}'' may be read as a claim that @{text "A x"}
  14.591 -  may be assumed for some arbitrary-but-fixed @{text "x"}.  Also note
  14.592 -  that ``@{command obtain}~@{text "A \<AND> B"}'' without parameters
  14.593 -  is similar to ``@{command have}~@{text "A \<AND> B"}'', but the
  14.594 +  deduction rules shown before we have occasionally used \<open>C\<close>.
  14.595 +  The whole statement of ``@{command obtain}~\<open>x\<close>~@{keyword
  14.596 +  "where"}~\<open>A x\<close>'' may be read as a claim that \<open>A x\<close>
  14.597 +  may be assumed for some arbitrary-but-fixed \<open>x\<close>.  Also note
  14.598 +  that ``@{command obtain}~\<open>A \<AND> B\<close>'' without parameters
  14.599 +  is similar to ``@{command have}~\<open>A \<AND> B\<close>'', but the
  14.600    latter involves multiple sub-goals.
  14.601  
  14.602    \<^medskip>
  14.603 @@ -707,50 +698,49 @@
  14.604  subsection \<open>Structured statements \label{sec:framework-stmt}\<close>
  14.605  
  14.606  text \<open>
  14.607 -  The category @{text "statement"} of top-level theorem specifications
  14.608 +  The category \<open>statement\<close> of top-level theorem specifications
  14.609    is defined as follows:
  14.610  
  14.611    \<^medskip>
  14.612    \begin{tabular}{rcl}
  14.613 -  @{text "statement"} & @{text "\<equiv>"} & @{text "name: props \<AND> \<dots>"} \\
  14.614 -  & @{text "|"} & @{text "context\<^sup>* conclusion"} \\[0.5ex]
  14.615 +  \<open>statement\<close> & \<open>\<equiv>\<close> & \<open>name: props \<AND> \<dots>\<close> \\
  14.616 +  & \<open>|\<close> & \<open>context\<^sup>* conclusion\<close> \\[0.5ex]
  14.617  
  14.618 -  @{text "context"} & @{text "\<equiv>"} & @{text "\<FIXES> vars \<AND> \<dots>"} \\
  14.619 -  & @{text "|"} & @{text "\<ASSUMES> name: props \<AND> \<dots>"} \\
  14.620 +  \<open>context\<close> & \<open>\<equiv>\<close> & \<open>\<FIXES> vars \<AND> \<dots>\<close> \\
  14.621 +  & \<open>|\<close> & \<open>\<ASSUMES> name: props \<AND> \<dots>\<close> \\
  14.622  
  14.623 -  @{text "conclusion"} & @{text "\<equiv>"} & @{text "\<SHOWS> name: props \<AND> \<dots>"} \\
  14.624 -  & @{text "|"} & @{text "\<OBTAINS> vars \<AND> \<dots> \<WHERE> name: props \<AND> \<dots>"} \\
  14.625 -  & & \quad @{text "\<BBAR> \<dots>"} \\
  14.626 +  \<open>conclusion\<close> & \<open>\<equiv>\<close> & \<open>\<SHOWS> name: props \<AND> \<dots>\<close> \\
  14.627 +  & \<open>|\<close> & \<open>\<OBTAINS> vars \<AND> \<dots> \<WHERE> name: props \<AND> \<dots>\<close> \\
  14.628 +  & & \quad \<open>\<BBAR> \<dots>\<close> \\
  14.629    \end{tabular}
  14.630  
  14.631    \<^medskip>
  14.632 -  A simple @{text "statement"} consists of named
  14.633 +  A simple \<open>statement\<close> consists of named
  14.634    propositions.  The full form admits local context elements followed
  14.635 -  by the actual conclusions, such as ``@{keyword "fixes"}~@{text
  14.636 -  x}~@{keyword "assumes"}~@{text "A x"}~@{keyword "shows"}~@{text "B
  14.637 -  x"}''.  The final result emerges as a Pure rule after discharging
  14.638 +  by the actual conclusions, such as ``@{keyword "fixes"}~\<open>x\<close>~@{keyword "assumes"}~\<open>A x\<close>~@{keyword "shows"}~\<open>B
  14.639 +  x\<close>''.  The final result emerges as a Pure rule after discharging
  14.640    the context: @{prop "\<And>x. A x \<Longrightarrow> B x"}.
  14.641  
  14.642    The @{keyword "obtains"} variant is another abbreviation defined
  14.643    below; unlike @{command obtain} (cf.\
  14.644    \secref{sec:framework-context}) there may be several ``cases''
  14.645 -  separated by ``@{text "\<BBAR>"}'', each consisting of several
  14.646 -  parameters (@{text "vars"}) and several premises (@{text "props"}).
  14.647 +  separated by ``\<open>\<BBAR>\<close>'', each consisting of several
  14.648 +  parameters (\<open>vars\<close>) and several premises (\<open>props\<close>).
  14.649    This specifies multi-branch elimination rules.
  14.650  
  14.651    \<^medskip>
  14.652    \begin{tabular}{l}
  14.653 -  @{text "\<OBTAINS> \<^vec>x \<WHERE> \<^vec>A \<^vec>x   \<BBAR>   \<dots>   \<equiv>"} \\[0.5ex]
  14.654 -  \quad @{text "\<FIXES> thesis"} \\
  14.655 -  \quad @{text "\<ASSUMES> [intro]: \<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis  \<AND>  \<dots>"} \\
  14.656 -  \quad @{text "\<SHOWS> thesis"} \\
  14.657 +  \<open>\<OBTAINS> \<^vec>x \<WHERE> \<^vec>A \<^vec>x   \<BBAR>   \<dots>   \<equiv>\<close> \\[0.5ex]
  14.658 +  \quad \<open>\<FIXES> thesis\<close> \\
  14.659 +  \quad \<open>\<ASSUMES> [intro]: \<And>\<^vec>x. \<^vec>A \<^vec>x \<Longrightarrow> thesis  \<AND>  \<dots>\<close> \\
  14.660 +  \quad \<open>\<SHOWS> thesis\<close> \\
  14.661    \end{tabular}
  14.662    \<^medskip>
  14.663  
  14.664    Presenting structured