isabelle update -u control_cartouches;
authorwenzelm
Sat Jan 05 17:24:33 2019 +0100 (6 months ago)
changeset 69597ff784d5a5bfb
parent 69596 c8a2755bf220
child 69598 81caae4fc4fa
isabelle update -u control_cartouches;
src/Benchmarks/Quickcheck_Benchmark/Needham_Schroeder_Base.thy
src/Benchmarks/Record_Benchmark/Record_Benchmark.thy
src/Doc/Classes/Classes.thy
src/Doc/Classes/Setup.thy
src/Doc/Codegen/Adaptation.thy
src/Doc/Codegen/Computations.thy
src/Doc/Codegen/Evaluation.thy
src/Doc/Codegen/Foundations.thy
src/Doc/Codegen/Further.thy
src/Doc/Codegen/Inductive_Predicate.thy
src/Doc/Codegen/Introduction.thy
src/Doc/Codegen/Refinement.thy
src/Doc/Corec/Corec.thy
src/Doc/Datatypes/Datatypes.thy
src/Doc/Eisbach/Manual.thy
src/Doc/Eisbach/Preface.thy
src/Doc/Functions/Functions.thy
src/Doc/How_to_Prove_it/How_to_Prove_it.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/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/Proof.thy
src/Doc/Isar_Ref/Proof_Script.thy
src/Doc/Isar_Ref/Spec.thy
src/Doc/Isar_Ref/Synopsis.thy
src/Doc/JEdit/JEdit.thy
src/Doc/Locales/Examples.thy
src/Doc/Locales/Examples1.thy
src/Doc/Locales/Examples2.thy
src/Doc/Locales/Examples3.thy
src/Doc/Main/Main_Doc.thy
src/Doc/Prog_Prove/Basics.thy
src/Doc/Prog_Prove/Bool_nat_list.thy
src/Doc/Prog_Prove/Isar.thy
src/Doc/Prog_Prove/Logic.thy
src/Doc/Prog_Prove/Types_and_funs.thy
src/Doc/Sugar/Sugar.thy
src/Doc/Tutorial/Advanced/simp2.thy
src/Doc/Tutorial/CTL/Base.thy
src/Doc/Tutorial/CTL/CTL.thy
src/Doc/Tutorial/CTL/CTLind.thy
src/Doc/Tutorial/CTL/PDL.thy
src/Doc/Tutorial/CodeGen/CodeGen.thy
src/Doc/Tutorial/Datatype/ABexpr.thy
src/Doc/Tutorial/Datatype/Fundata.thy
src/Doc/Tutorial/Datatype/Nested.thy
src/Doc/Tutorial/Documents/Documents.thy
src/Doc/Tutorial/Fun/fun0.thy
src/Doc/Tutorial/Ifexpr/Ifexpr.thy
src/Doc/Tutorial/Inductive/AB.thy
src/Doc/Tutorial/Inductive/Advanced.thy
src/Doc/Tutorial/Inductive/Even.thy
src/Doc/Tutorial/Inductive/Mutual.thy
src/Doc/Tutorial/Inductive/Star.thy
src/Doc/Tutorial/Misc/AdvancedInd.thy
src/Doc/Tutorial/Misc/Itrev.thy
src/Doc/Tutorial/Misc/Option2.thy
src/Doc/Tutorial/Misc/Tree.thy
src/Doc/Tutorial/Misc/Tree2.thy
src/Doc/Tutorial/Misc/case_exprs.thy
src/Doc/Tutorial/Misc/natsum.thy
src/Doc/Tutorial/Misc/pairs2.thy
src/Doc/Tutorial/Misc/prime_def.thy
src/Doc/Tutorial/Misc/simp.thy
src/Doc/Tutorial/Misc/types.thy
src/Doc/Tutorial/Protocol/Event.thy
src/Doc/Tutorial/Protocol/Message.thy
src/Doc/Tutorial/Protocol/NS_Public.thy
src/Doc/Tutorial/Rules/Basic.thy
src/Doc/Tutorial/Sets/Recur.thy
src/Doc/Tutorial/ToyList/ToyList.thy
src/Doc/Tutorial/ToyList/ToyList_Test.thy
src/Doc/Tutorial/Trie/Trie.thy
src/Doc/Tutorial/Types/Axioms.thy
src/Doc/Tutorial/Types/Numbers.thy
src/Doc/Tutorial/Types/Overloading.thy
src/Doc/Tutorial/Types/Pairs.thy
src/Doc/Tutorial/Types/Records.thy
src/Doc/Tutorial/Types/Typedefs.thy
src/Doc/Typeclass_Hierarchy/Setup.thy
src/Doc/Typeclass_Hierarchy/Typeclass_Hierarchy.thy
src/Doc/more_antiquote.ML
src/FOL/FOL.thy
src/HOL/Algebra/AbelCoset.thy
src/HOL/Algebra/Complete_Lattice.thy
src/HOL/Algebra/Coset.thy
src/HOL/Algebra/Divisibility.thy
src/HOL/Algebra/Embedded_Algebras.thy
src/HOL/Algebra/Group.thy
src/HOL/Algebra/Ideal.thy
src/HOL/Algebra/IntRing.thy
src/HOL/Algebra/Multiplicative_Group.thy
src/HOL/Algebra/Order.thy
src/HOL/Algebra/QuotRing.thy
src/HOL/Algebra/Ring_Divisibility.thy
src/HOL/Algebra/Sylow.thy
src/HOL/Algebra/Sym_Groups.thy
src/HOL/Algebra/UnivPoly.thy
src/HOL/Analysis/Bochner_Integration.thy
src/HOL/Analysis/Borel_Space.thy
src/HOL/Analysis/Bounded_Linear_Function.thy
src/HOL/Analysis/Cartesian_Euclidean_Space.thy
src/HOL/Analysis/Cauchy_Integral_Theorem.thy
src/HOL/Analysis/Complex_Transcendental.thy
src/HOL/Analysis/Conformal_Mappings.thy
src/HOL/Analysis/Connected.thy
src/HOL/Analysis/Continuum_Not_Denumerable.thy
src/HOL/Analysis/Derivative.thy
src/HOL/Analysis/Equivalence_Lebesgue_Henstock_Integration.thy
src/HOL/Analysis/Euclidean_Space.thy
src/HOL/Analysis/FPS_Convergence.thy
src/HOL/Analysis/Finite_Cartesian_Product.thy
src/HOL/Analysis/Finite_Product_Measure.thy
src/HOL/Analysis/Function_Topology.thy
src/HOL/Analysis/Gamma_Function.thy
src/HOL/Analysis/Harmonic_Numbers.thy
src/HOL/Analysis/Henstock_Kurzweil_Integration.thy
src/HOL/Analysis/Infinite_Set_Sum.thy
src/HOL/Analysis/Inner_Product.thy
src/HOL/Analysis/Linear_Algebra.thy
src/HOL/Analysis/Measurable.thy
src/HOL/Analysis/Measure_Space.thy
src/HOL/Analysis/Polytope.thy
src/HOL/Analysis/Sigma_Algebra.thy
src/HOL/Analysis/Summation_Tests.thy
src/HOL/Analysis/Tagged_Division.thy
src/HOL/Analysis/Uniform_Limit.thy
src/HOL/Analysis/Weierstrass_Theorems.thy
src/HOL/Analysis/ex/Approximations.thy
src/HOL/Analysis/measurable.ML
src/HOL/Analysis/normarith.ML
src/HOL/Auth/CertifiedEmail.thy
src/HOL/Auth/Event.thy
src/HOL/Auth/Guard/Analz.thy
src/HOL/Auth/Guard/Extensions.thy
src/HOL/Auth/Guard/Guard.thy
src/HOL/Auth/Guard/GuardK.thy
src/HOL/Auth/Guard/Guard_Public.thy
src/HOL/Auth/Guard/Guard_Shared.thy
src/HOL/Auth/KerberosIV.thy
src/HOL/Auth/KerberosIV_Gets.thy
src/HOL/Auth/KerberosV.thy
src/HOL/Auth/Message.thy
src/HOL/Auth/NS_Shared.thy
src/HOL/Auth/OtwayRees.thy
src/HOL/Auth/OtwayReesBella.thy
src/HOL/Auth/OtwayRees_AN.thy
src/HOL/Auth/OtwayRees_Bad.thy
src/HOL/Auth/Public.thy
src/HOL/Auth/Recur.thy
src/HOL/Auth/Shared.thy
src/HOL/Auth/Smartcard/EventSC.thy
src/HOL/Auth/Smartcard/ShoupRubin.thy
src/HOL/Auth/Smartcard/ShoupRubinBella.thy
src/HOL/Auth/Smartcard/Smartcard.thy
src/HOL/Auth/TLS.thy
src/HOL/Auth/Yahalom.thy
src/HOL/Auth/Yahalom2.thy
src/HOL/Auth/Yahalom_Bad.thy
src/HOL/Auth/ZhouGollmann.thy
src/HOL/Bali/AxCompl.thy
src/HOL/Bali/AxExample.thy
src/HOL/Bali/AxSem.thy
src/HOL/Bali/AxSound.thy
src/HOL/Bali/DeclConcepts.thy
src/HOL/Bali/DefiniteAssignment.thy
src/HOL/Bali/DefiniteAssignmentCorrect.thy
src/HOL/Bali/Eval.thy
src/HOL/Bali/Evaln.thy
src/HOL/Bali/Example.thy
src/HOL/Bali/Table.thy
src/HOL/Bali/Term.thy
src/HOL/Bali/TypeSafe.thy
src/HOL/Bali/WellForm.thy
src/HOL/Bali/WellType.thy
src/HOL/Cardinals/Wellorder_Extension.thy
src/HOL/Codegenerator_Test/Candidates.thy
src/HOL/Codegenerator_Test/Code_Lazy_Test.thy
src/HOL/Codegenerator_Test/Code_Test_GHC.thy
src/HOL/Codegenerator_Test/Code_Test_OCaml.thy
src/HOL/Codegenerator_Test/Code_Test_Scala.thy
src/HOL/Computational_Algebra/Formal_Power_Series.thy
src/HOL/Computational_Algebra/Polynomial.thy
src/HOL/Computational_Algebra/Polynomial_FPS.thy
src/HOL/Computational_Algebra/Primes.thy
src/HOL/Data_Structures/AA_Set.thy
src/HOL/Data_Structures/AList_Upd_Del.thy
src/HOL/Data_Structures/AVL_Set.thy
src/HOL/Data_Structures/Array_Braun.thy
src/HOL/Data_Structures/Binomial_Heap.thy
src/HOL/Data_Structures/Less_False.thy
src/HOL/Data_Structures/List_Ins_Del.thy
src/HOL/Data_Structures/Set2_Join.thy
src/HOL/Data_Structures/Set2_Join_RBT.thy
src/HOL/Data_Structures/Sorted_Less.thy
src/HOL/Data_Structures/Sorting.thy
src/HOL/Data_Structures/Tree234_Set.thy
src/HOL/Data_Structures/Tree23_Set.thy
src/HOL/Datatype_Examples/Compat.thy
src/HOL/Datatype_Examples/Stream_Processor.thy
src/HOL/Decision_Procs/Approximation.thy
src/HOL/Decision_Procs/Approximation_Bounds.thy
src/HOL/Decision_Procs/Commutative_Ring.thy
src/HOL/Decision_Procs/Conversions.thy
src/HOL/Decision_Procs/Cooper.thy
src/HOL/Decision_Procs/Dense_Linear_Order.thy
src/HOL/Decision_Procs/Ferrack.thy
src/HOL/Decision_Procs/MIR.thy
src/HOL/Decision_Procs/Parametric_Ferrante_Rackoff.thy
src/HOL/Decision_Procs/Polynomial_List.thy
src/HOL/Decision_Procs/Rat_Pair.thy
src/HOL/Decision_Procs/Reflective_Field.thy
src/HOL/Decision_Procs/approximation.ML
src/HOL/Decision_Procs/approximation_generator.ML
src/HOL/Decision_Procs/cooper_tac.ML
src/HOL/Decision_Procs/ex/Approximation_Ex.thy
src/HOL/Decision_Procs/ex/Approximation_Quickcheck_Ex.thy
src/HOL/Decision_Procs/ferrack_tac.ML
src/HOL/Decision_Procs/ferrante_rackoff.ML
src/HOL/Decision_Procs/ferrante_rackoff_data.ML
src/HOL/Decision_Procs/langford.ML
src/HOL/Decision_Procs/langford_data.ML
src/HOL/Decision_Procs/mir_tac.ML
src/HOL/Eisbach/Examples.thy
src/HOL/Eisbach/Tests.thy
src/HOL/HOL.thy
src/HOL/HOLCF/Bifinite.thy
src/HOL/HOLCF/Cfun.thy
src/HOL/HOLCF/Cpodef.thy
src/HOL/HOLCF/Domain.thy
src/HOL/HOLCF/FOCUS/Buffer_adm.thy
src/HOL/HOLCF/FOCUS/Fstream.thy
src/HOL/HOLCF/Fix.thy
src/HOL/HOLCF/Fixrec.thy
src/HOL/HOLCF/Fun_Cpo.thy
src/HOL/HOLCF/IOA/ABP/Correctness.thy
src/HOL/HOLCF/IOA/Automata.thy
src/HOL/HOLCF/IOA/CompoScheds.thy
src/HOL/HOLCF/IOA/CompoTraces.thy
src/HOL/HOLCF/IOA/NTP/Impl.thy
src/HOL/HOLCF/IOA/ShortExecutions.thy
src/HOL/HOLCF/Library/Bool_Discrete.thy
src/HOL/HOLCF/Library/Char_Discrete.thy
src/HOL/HOLCF/Library/Int_Discrete.thy
src/HOL/HOLCF/Library/List_Cpo.thy
src/HOL/HOLCF/Library/List_Predomain.thy
src/HOL/HOLCF/Library/Nat_Discrete.thy
src/HOL/HOLCF/Library/Option_Cpo.thy
src/HOL/HOLCF/Library/Sum_Cpo.thy
src/HOL/HOLCF/Lift.thy
src/HOL/HOLCF/One.thy
src/HOL/HOLCF/Pcpo.thy
src/HOL/HOLCF/Porder.thy
src/HOL/HOLCF/Powerdomains.thy
src/HOL/HOLCF/Product_Cpo.thy
src/HOL/HOLCF/Representable.thy
src/HOL/HOLCF/Tools/Domain/domain.ML
src/HOL/HOLCF/Tools/Domain/domain_axioms.ML
src/HOL/HOLCF/Tools/Domain/domain_constructors.ML
src/HOL/HOLCF/Tools/Domain/domain_induction.ML
src/HOL/HOLCF/Tools/Domain/domain_isomorphism.ML
src/HOL/HOLCF/Tools/Domain/domain_take_proofs.ML
src/HOL/HOLCF/Tools/cont_consts.ML
src/HOL/HOLCF/Tools/cont_proc.ML
src/HOL/HOLCF/Tools/cpodef.ML
src/HOL/HOLCF/Tools/domaindef.ML
src/HOL/HOLCF/Tools/fixrec.ML
src/HOL/HOLCF/Tools/holcf_library.ML
src/HOL/HOLCF/Tr.thy
src/HOL/HOLCF/Tutorial/Fixrec_ex.thy
src/HOL/HOLCF/Up.thy
src/HOL/HOLCF/ex/Focus_ex.thy
src/HOL/HOLCF/ex/Pattern_Match.thy
src/HOL/Hahn_Banach/Vector_Space.thy
src/HOL/Hoare/Heap.thy
src/HOL/Hoare/HeapSyntaxAbort.thy
src/HOL/Hoare/Hoare_Logic.thy
src/HOL/Hoare/Hoare_Logic_Abort.thy
src/HOL/Hoare/Pointer_Examples.thy
src/HOL/Hoare/Pointers0.thy
src/HOL/Hoare/SchorrWaite.thy
src/HOL/Hoare/Separation.thy
src/HOL/Hoare/hoare_syntax.ML
src/HOL/Hoare/hoare_tac.ML
src/HOL/Hoare_Parallel/Gar_Coll.thy
src/HOL/Hoare_Parallel/Mul_Gar_Coll.thy
src/HOL/Hoare_Parallel/OG_Examples.thy
src/HOL/Hoare_Parallel/OG_Syntax.thy
src/HOL/Hoare_Parallel/Quote_Antiquote.thy
src/HOL/Hoare_Parallel/RG_Syntax.thy
src/HOL/IMP/AExp.thy
src/HOL/IMP/Abs_Int0.thy
src/HOL/IMP/Abs_Int1_parity.thy
src/HOL/IMP/Abs_Int2.thy
src/HOL/IMP/Abs_Int3.thy
src/HOL/IMP/Big_Step.thy
src/HOL/IMP/C_like.thy
src/HOL/IMP/Collecting1.thy
src/HOL/IMP/Compiler.thy
src/HOL/IMP/Compiler2.thy
src/HOL/IMP/Def_Init_Big.thy
src/HOL/IMP/Hoare_Total.thy
src/HOL/IMP/Live_True.thy
src/HOL/IMP/Sec_Typing.thy
src/HOL/IMP/Sec_TypingT.thy
src/HOL/IMP/Types.thy
src/HOL/IMP/Vars.thy
src/HOL/IMPP/Hoare.thy
src/HOL/IMPP/Misc.thy
src/HOL/IMPP/Natural.thy
src/HOL/IOA/Solve.thy
src/HOL/Imperative_HOL/Heap.thy
src/HOL/Imperative_HOL/Heap_Monad.thy
src/HOL/Imperative_HOL/Overview.thy
src/HOL/Imperative_HOL/ex/Linked_Lists.thy
src/HOL/Import/import_data.ML
src/HOL/Import/import_rule.ML
src/HOL/Induct/Comb.thy
src/HOL/Induct/PropLog.thy
src/HOL/Induct/QuoDataType.thy
src/HOL/Induct/QuoNestedDataType.thy
src/HOL/Isar_Examples/Cantor.thy
src/HOL/Isar_Examples/Hoare.thy
src/HOL/Isar_Examples/Structured_Statements.thy
src/HOL/Lattice/Lattice.thy
src/HOL/Lattice/Orders.thy
src/HOL/Library/Going_To_Filter.thy
src/HOL/Library/Landau_Symbols.thy
src/HOL/Library/Lub_Glb.thy
src/HOL/Library/Omega_Words_Fun.thy
src/HOL/Library/Pattern_Aliases.thy
src/HOL/Library/Permutation.thy
src/HOL/Library/Stream.thy
src/HOL/Library/Type_Length.thy
src/HOL/Library/code_lazy.ML
src/HOL/Library/code_test.ML
src/HOL/Matrix_LP/Compute_Oracle/compute.ML
src/HOL/Matrix_LP/float_arith.ML
src/HOL/Matrix_LP/fspmlp.ML
src/HOL/Matrix_LP/matrixlp.ML
src/HOL/Metis_Examples/Message.thy
src/HOL/MicroJava/BV/BVExample.thy
src/HOL/MicroJava/BV/BVSpec.thy
src/HOL/MicroJava/BV/Effect.thy
src/HOL/MicroJava/BV/Typing_Framework_JVM.thy
src/HOL/MicroJava/DFA/Err.thy
src/HOL/MicroJava/DFA/Typing_Framework_err.thy
src/HOL/MicroJava/J/JTypeSafe.thy
src/HOL/MicroJava/J/State.thy
src/HOL/MicroJava/J/WellForm.thy
src/HOL/MicroJava/JVM/JVMExceptions.thy
src/HOL/MicroJava/JVM/JVMListExample.thy
src/HOL/Mirabelle/Tools/mirabelle.ML
src/HOL/Mutabelle/MutabelleExtra.thy
src/HOL/Mutabelle/mutabelle.ML
src/HOL/Mutabelle/mutabelle_extra.ML
src/HOL/NanoJava/AxSem.thy
src/HOL/NanoJava/Equivalence.thy
src/HOL/NanoJava/Example.thy
src/HOL/NanoJava/State.thy
src/HOL/Nitpick_Examples/Manual_Nits.thy
src/HOL/Nitpick_Examples/Mini_Nits.thy
src/HOL/Nitpick_Examples/Mono_Nits.thy
src/HOL/Nitpick_Examples/Refute_Nits.thy
src/HOL/Nitpick_Examples/minipick.ML
src/HOL/Nominal/Examples/Crary.thy
src/HOL/Nominal/Examples/Fsub.thy
src/HOL/Nominal/Examples/Standardization.thy
src/HOL/Nominal/Nominal.thy
src/HOL/Nominal/nominal_atoms.ML
src/HOL/Nominal/nominal_datatype.ML
src/HOL/Nominal/nominal_fresh_fun.ML
src/HOL/Nominal/nominal_inductive.ML
src/HOL/Nominal/nominal_inductive2.ML
src/HOL/Nominal/nominal_permeq.ML
src/HOL/Nominal/nominal_primrec.ML
src/HOL/Nominal/nominal_thmdecls.ML
src/HOL/Nonstandard_Analysis/CLim.thy
src/HOL/Nonstandard_Analysis/Free_Ultrafilter.thy
src/HOL/Nonstandard_Analysis/HDeriv.thy
src/HOL/Nonstandard_Analysis/HLim.thy
src/HOL/Nonstandard_Analysis/HSEQ.thy
src/HOL/Nonstandard_Analysis/HSeries.thy
src/HOL/Nonstandard_Analysis/HTranscendental.thy
src/HOL/Nonstandard_Analysis/HyperDef.thy
src/HOL/Nonstandard_Analysis/HyperNat.thy
src/HOL/Nonstandard_Analysis/NSA.thy
src/HOL/Nonstandard_Analysis/NSCA.thy
src/HOL/Nonstandard_Analysis/NSComplex.thy
src/HOL/Nonstandard_Analysis/NatStar.thy
src/HOL/Nonstandard_Analysis/StarDef.thy
src/HOL/Nonstandard_Analysis/transfer_principle.ML
src/HOL/Number_Theory/Cong.thy
src/HOL/Number_Theory/Eratosthenes.thy
src/HOL/Number_Theory/Fib.thy
src/HOL/Orderings.thy
src/HOL/Predicate_Compile_Examples/Lambda_Example.thy
src/HOL/Predicate_Compile_Examples/List_Examples.thy
src/HOL/Predicate_Compile_Examples/Predicate_Compile_Quickcheck_Examples.thy
src/HOL/Predicate_Compile_Examples/Reg_Exp_Example.thy
src/HOL/Predicate_Compile_Examples/Specialisation_Examples.thy
src/HOL/Probability/Fin_Map.thy
src/HOL/Probability/Information.thy
src/HOL/Probability/Probability_Mass_Function.thy
src/HOL/Probability/Probability_Measure.thy
src/HOL/Probability/SPMF.thy
src/HOL/Probability/ex/Dining_Cryptographers.thy
src/HOL/Probability/ex/Measure_Not_CCC.thy
src/HOL/Prolog/Test.thy
src/HOL/Prolog/prolog.ML
src/HOL/Proofs/Lambda/Commutation.thy
src/HOL/Proofs/Lambda/Eta.thy
src/HOL/Proofs/Lambda/Lambda.thy
src/HOL/Proofs/Lambda/NormalForm.thy
src/HOL/Proofs/Lambda/StrongNorm.thy
src/HOL/Proofs/ex/Proof_Terms.thy
src/HOL/Proofs/ex/XML_Data.thy
src/HOL/Quickcheck_Examples/Hotel_Example.thy
src/HOL/Quickcheck_Examples/Quickcheck_Interfaces.thy
src/HOL/Quickcheck_Examples/Quickcheck_Lattice_Examples.thy
src/HOL/Quickcheck_Examples/Quickcheck_Narrowing_Examples.thy
src/HOL/Quickcheck_Examples/Quickcheck_Nesting.thy
src/HOL/Quotient_Examples/Quotient_FSet.thy
src/HOL/Quotient_Examples/Quotient_Int.thy
src/HOL/Quotient_Examples/Quotient_Message.thy
src/HOL/Real_Asymp/Eventuallize.thy
src/HOL/Real_Asymp/Inst_Existentials.thy
src/HOL/Real_Asymp/Manual/Real_Asymp_Doc.thy
src/HOL/Real_Asymp/Multiseries_Expansion.thy
src/HOL/Real_Asymp/Real_Asymp_Approx.thy
src/HOL/Real_Asymp/Real_Asymp_Examples.thy
src/HOL/Real_Asymp/asymptotic_basis.ML
src/HOL/Real_Asymp/exp_log_expression.ML
src/HOL/Real_Asymp/multiseries_expansion.ML
src/HOL/Real_Asymp/multiseries_expansion_bounds.ML
src/HOL/Real_Asymp/real_asymp.ML
src/HOL/Real_Asymp/real_asymp_diag.ML
src/HOL/SET_Protocol/Cardholder_Registration.thy
src/HOL/SET_Protocol/Event_SET.thy
src/HOL/SET_Protocol/Merchant_Registration.thy
src/HOL/SET_Protocol/Message_SET.thy
src/HOL/SET_Protocol/Public_SET.thy
src/HOL/SET_Protocol/Purchase.thy
src/HOL/SMT_Examples/boogie.ML
src/HOL/SPARK/Manual/Reference.thy
src/HOL/Statespace/DistinctTreeProver.thy
src/HOL/Statespace/StateSpaceEx.thy
src/HOL/Statespace/StateSpaceSyntax.thy
src/HOL/Statespace/distinct_tree_prover.ML
src/HOL/Statespace/state_fun.ML
src/HOL/Statespace/state_space.ML
src/HOL/TLA/Action.thy
src/HOL/TLA/Buffer/DBuffer.thy
src/HOL/TLA/Inc/Inc.thy
src/HOL/TLA/Intensional.thy
src/HOL/TLA/Memory/MemClerk.thy
src/HOL/TLA/Memory/Memory.thy
src/HOL/TLA/Memory/MemoryImplementation.thy
src/HOL/TLA/Memory/RPC.thy
src/HOL/TLA/TLA.thy
src/HOL/TPTP/ATP_Theory_Export.thy
src/HOL/TPTP/MaSh_Eval.thy
src/HOL/TPTP/MaSh_Export_Base.thy
src/HOL/TPTP/TPTP_Parser/tptp_interpret.ML
src/HOL/TPTP/TPTP_Parser/tptp_reconstruct.ML
src/HOL/TPTP/TPTP_Parser/tptp_reconstruct_library.ML
src/HOL/TPTP/TPTP_Proof_Reconstruction.thy
src/HOL/TPTP/atp_problem_import.ML
src/HOL/TPTP/atp_theory_export.ML
src/HOL/TPTP/mash_export.ML
src/HOL/Tools/ATP/atp_problem_generate.ML
src/HOL/Tools/ATP/atp_proof_reconstruct.ML
src/HOL/Tools/ATP/atp_util.ML
src/HOL/Tools/BNF/bnf_fp_def_sugar.ML
src/HOL/Tools/BNF/bnf_fp_rec_sugar_transfer.ML
src/HOL/Tools/BNF/bnf_gfp_grec_sugar.ML
src/HOL/Tools/BNF/bnf_gfp_grec_sugar_util.ML
src/HOL/Tools/BNF/bnf_gfp_rec_sugar.ML
src/HOL/Tools/BNF/bnf_gfp_rec_sugar_tactics.ML
src/HOL/Tools/BNF/bnf_lfp_countable.ML
src/HOL/Tools/Ctr_Sugar/ctr_sugar.ML
src/HOL/Tools/Lifting/lifting_def_code_dt.ML
src/HOL/Tools/Metis/metis_reconstruct.ML
src/HOL/Tools/Nitpick/nitpick.ML
src/HOL/Tools/Nitpick/nitpick_hol.ML
src/HOL/Tools/Nitpick/nitpick_model.ML
src/HOL/Tools/Nitpick/nitpick_mono.ML
src/HOL/Tools/Nitpick/nitpick_preproc.ML
src/HOL/Tools/Nunchaku/nunchaku.ML
src/HOL/Tools/Nunchaku/nunchaku_collect.ML
src/HOL/Tools/Nunchaku/nunchaku_reconstruct.ML
src/HOL/Tools/SMT/smt_replay_methods.ML
src/HOL/Tools/SMT/smt_util.ML
src/HOL/Tools/SMT/smtlib_interface.ML
src/HOL/Tools/SMT/smtlib_proof.ML
src/HOL/Tools/SMT/verit_proof.ML
src/HOL/Tools/SMT/z3_interface.ML
src/HOL/Tools/SMT/z3_replay_methods.ML
src/HOL/Tools/Sledgehammer/sledgehammer_fact.ML
src/HOL/Tools/Sledgehammer/sledgehammer_mepo.ML
src/HOL/Tools/Sledgehammer/sledgehammer_prover_atp.ML
src/HOL/Tools/Transfer/transfer.ML
src/HOL/Tools/set_comprehension_pointfree.ML
src/HOL/Transitive_Closure.thy
src/HOL/Types_To_Sets/Examples/Linear_Algebra_On.thy
src/HOL/Types_To_Sets/Examples/Prerequisites.thy
src/HOL/Types_To_Sets/Examples/T2_Spaces.thy
src/HOL/Types_To_Sets/internalize_sort.ML
src/HOL/Types_To_Sets/local_typedef.ML
src/HOL/Types_To_Sets/unoverload_type.ML
src/HOL/Types_To_Sets/unoverloading.ML
src/HOL/UNITY/Comp/Alloc.thy
src/HOL/UNITY/Comp/Priority.thy
src/HOL/UNITY/Comp/Progress.thy
src/HOL/UNITY/Extend.thy
src/HOL/UNITY/Lift_prog.thy
src/HOL/UNITY/PPROD.thy
src/HOL/UNITY/ProgressSets.thy
src/HOL/UNITY/Simple/NSP_Bad.thy
src/HOL/UNITY/Transformers.thy
src/HOL/UNITY/UNITY.thy
src/HOL/UNITY/Union.thy
src/HOL/UNITY/WFair.thy
src/HOL/Unix/Nested_Environment.thy
src/HOL/Unix/Unix.thy
src/HOL/Word/Tools/smt_word.ML
src/HOL/Word/Tools/word_lib.ML
src/HOL/Word/WordBitwise.thy
src/HOL/ex/Adhoc_Overloading_Examples.thy
src/HOL/ex/Antiquote.thy
src/HOL/ex/Arith_Examples.thy
src/HOL/ex/Ballot.thy
src/HOL/ex/CTL.thy
src/HOL/ex/Cartouche_Examples.thy
src/HOL/ex/Classical.thy
src/HOL/ex/Code_Lazy_Demo.thy
src/HOL/ex/Code_Timing.thy
src/HOL/ex/Commands.thy
src/HOL/ex/Computations.thy
src/HOL/ex/Datatype_Record_Examples.thy
src/HOL/ex/Dedekind_Real.thy
src/HOL/ex/Erdoes_Szekeres.thy
src/HOL/ex/Execute_Choice.thy
src/HOL/ex/Function_Growth.thy
src/HOL/ex/Groebner_Examples.thy
src/HOL/ex/Hex_Bin_Examples.thy
src/HOL/ex/Iff_Oracle.thy
src/HOL/ex/LocaleTest2.thy
src/HOL/ex/ML.thy
src/HOL/ex/Meson_Test.thy
src/HOL/ex/Multiquote.thy
src/HOL/ex/PER.thy
src/HOL/ex/Primrec.thy
src/HOL/ex/Radix_Sort.thy
src/HOL/ex/Records.thy
src/HOL/ex/Reflection_Examples.thy
src/HOL/ex/Refute_Examples.thy
src/HOL/ex/Rewrite_Examples.thy
src/HOL/ex/SAT_Examples.thy
src/HOL/ex/Simproc_Tests.thy
src/HOL/ex/Sorting_Algorithms_Examples.thy
src/HOL/ex/Sum_of_Powers.thy
src/HOL/ex/Termination.thy
src/HOL/ex/ThreeDivides.thy
src/HOL/ex/Tree23.thy
src/HOL/ex/While_Combinator_Example.thy
src/HOL/ex/veriT_Preprocessing.thy
src/Tools/Code/code_runtime.ML
src/ZF/Inductive.thy
src/ZF/Tools/datatype_package.ML
src/ZF/Tools/inductive_package.ML
src/ZF/ind_syntax.ML
src/ZF/int_arith.ML
     1.1 --- a/src/Benchmarks/Quickcheck_Benchmark/Needham_Schroeder_Base.thy	Sat Jan 05 17:00:43 2019 +0100
     1.2 +++ b/src/Benchmarks/Quickcheck_Benchmark/Needham_Schroeder_Base.thy	Sat Jan 05 17:24:33 2019 +0100
     1.3 @@ -151,15 +151,15 @@
     1.4    fun of_set compfuns (Type ("fun", [T, _])) =
     1.5      case body_type (Predicate_Compile_Aux.mk_monadT compfuns T) of
     1.6        Type ("Quickcheck_Exhaustive.three_valued", _) => 
     1.7 -        Const(@{const_name neg_cps_of_set}, HOLogic.mk_setT T --> (Predicate_Compile_Aux.mk_monadT compfuns T))
     1.8 -    | Type ("Predicate.pred", _) => Const(@{const_name pred_of_set}, HOLogic.mk_setT T --> Predicate_Compile_Aux.mk_monadT compfuns T)
     1.9 -    | _ => Const(@{const_name pos_cps_of_set}, HOLogic.mk_setT T --> (Predicate_Compile_Aux.mk_monadT compfuns T))
    1.10 +        Const(\<^const_name>\<open>neg_cps_of_set\<close>, HOLogic.mk_setT T --> (Predicate_Compile_Aux.mk_monadT compfuns T))
    1.11 +    | Type ("Predicate.pred", _) => Const(\<^const_name>\<open>pred_of_set\<close>, HOLogic.mk_setT T --> Predicate_Compile_Aux.mk_monadT compfuns T)
    1.12 +    | _ => Const(\<^const_name>\<open>pos_cps_of_set\<close>, HOLogic.mk_setT T --> (Predicate_Compile_Aux.mk_monadT compfuns T))
    1.13    fun member compfuns (U as Type ("fun", [T, _])) =
    1.14      (absdummy T (absdummy (HOLogic.mk_setT T) (Predicate_Compile_Aux.mk_if compfuns
    1.15 -      (Const (@{const_name "Set.member"}, T --> HOLogic.mk_setT T --> @{typ bool}) $ Bound 1 $ Bound 0))))
    1.16 +      (Const (\<^const_name>\<open>Set.member\<close>, T --> HOLogic.mk_setT T --> \<^typ>\<open>bool\<close>) $ Bound 1 $ Bound 0))))
    1.17   
    1.18  in
    1.19 -  Core_Data.force_modes_and_compilations @{const_name Set.member}
    1.20 +  Core_Data.force_modes_and_compilations \<^const_name>\<open>Set.member\<close>
    1.21      [(oi, (of_set, false)), (ii, (member, false))]
    1.22  end
    1.23  \<close>
    1.24 @@ -186,7 +186,7 @@
    1.25  
    1.26  code_pred [generator_cps] synth' unfolding synth'_def by (rule synth.cases) fastforce+
    1.27  
    1.28 -setup \<open>Predicate_Compile_Data.ignore_consts [@{const_name analz}, @{const_name knows}]\<close>
    1.29 +setup \<open>Predicate_Compile_Data.ignore_consts [\<^const_name>\<open>analz\<close>, \<^const_name>\<open>knows\<close>]\<close>
    1.30  declare ListMem_iff[symmetric, code_pred_inline]
    1.31  declare [[quickcheck_timing]]
    1.32  
     2.1 --- a/src/Benchmarks/Record_Benchmark/Record_Benchmark.thy	Sat Jan 05 17:00:43 2019 +0100
     2.2 +++ b/src/Benchmarks/Record_Benchmark/Record_Benchmark.thy	Sat Jan 05 17:24:33 2019 +0100
     2.3 @@ -356,49 +356,49 @@
     2.4  
     2.5  lemma "(r\<lparr>A255:=x,A253:=y,A255:=z \<rparr>) = r\<lparr>A253:=y,A255:=z\<rparr>"
     2.6    apply (tactic \<open>simp_tac
     2.7 -    (put_simpset HOL_basic_ss @{context} addsimprocs [Record.upd_simproc]) 1\<close>)
     2.8 +    (put_simpset HOL_basic_ss \<^context> addsimprocs [Record.upd_simproc]) 1\<close>)
     2.9    done
    2.10  
    2.11  lemma "(\<forall>r. P (A155 r)) \<longrightarrow> (\<forall>x. P x)"
    2.12    apply (tactic \<open>simp_tac
    2.13 -    (put_simpset HOL_basic_ss @{context} addsimprocs [Record.split_simproc (K ~1)]) 1\<close>)
    2.14 +    (put_simpset HOL_basic_ss \<^context> addsimprocs [Record.split_simproc (K ~1)]) 1\<close>)
    2.15    apply simp
    2.16    done
    2.17  
    2.18  lemma "(\<forall>r. P (A155 r)) \<longrightarrow> (\<forall>x. P x)"
    2.19 -  apply (tactic \<open>Record.split_simp_tac @{context} [] (K ~1) 1\<close>)
    2.20 +  apply (tactic \<open>Record.split_simp_tac \<^context> [] (K ~1) 1\<close>)
    2.21    apply simp
    2.22    done
    2.23  
    2.24  lemma "(\<exists>r. P (A155 r)) \<longrightarrow> (\<exists>x. P x)"
    2.25    apply (tactic \<open>simp_tac
    2.26 -    (put_simpset HOL_basic_ss @{context} addsimprocs [Record.split_simproc (K ~1)]) 1\<close>)
    2.27 +    (put_simpset HOL_basic_ss \<^context> addsimprocs [Record.split_simproc (K ~1)]) 1\<close>)
    2.28    apply simp
    2.29    done
    2.30  
    2.31  lemma "(\<exists>r. P (A155 r)) \<longrightarrow> (\<exists>x. P x)"
    2.32 -  apply (tactic \<open>Record.split_simp_tac @{context} [] (K ~1) 1\<close>)
    2.33 +  apply (tactic \<open>Record.split_simp_tac \<^context> [] (K ~1) 1\<close>)
    2.34    apply simp
    2.35    done
    2.36  
    2.37  lemma "\<And>r. P (A155 r) \<Longrightarrow> (\<exists>x. P x)"
    2.38    apply (tactic \<open>simp_tac
    2.39 -    (put_simpset HOL_basic_ss @{context} addsimprocs [Record.split_simproc (K ~1)]) 1\<close>)
    2.40 +    (put_simpset HOL_basic_ss \<^context> addsimprocs [Record.split_simproc (K ~1)]) 1\<close>)
    2.41    apply auto
    2.42    done
    2.43  
    2.44  lemma "\<And>r. P (A155 r) \<Longrightarrow> (\<exists>x. P x)"
    2.45 -  apply (tactic \<open>Record.split_simp_tac @{context} [] (K ~1) 1\<close>)
    2.46 +  apply (tactic \<open>Record.split_simp_tac \<^context> [] (K ~1) 1\<close>)
    2.47    apply auto
    2.48    done
    2.49  
    2.50  lemma "P (A155 r) \<Longrightarrow> (\<exists>x. P x)"
    2.51 -  apply (tactic \<open>Record.split_simp_tac @{context} [] (K ~1) 1\<close>)
    2.52 +  apply (tactic \<open>Record.split_simp_tac \<^context> [] (K ~1) 1\<close>)
    2.53    apply auto
    2.54    done
    2.55  
    2.56  lemma fixes r shows "P (A155 r) \<Longrightarrow> (\<exists>x. P x)"
    2.57 -  apply (tactic \<open>Record.split_simp_tac @{context} [] (K ~1) 1\<close>)
    2.58 +  apply (tactic \<open>Record.split_simp_tac \<^context> [] (K ~1) 1\<close>)
    2.59    apply auto
    2.60    done
    2.61  
    2.62 @@ -409,7 +409,7 @@
    2.63    assume "P (A155 r)"
    2.64    then have "\<exists>x. P x"
    2.65      apply -
    2.66 -    apply (tactic \<open>Record.split_simp_tac @{context} [] (K ~1) 1\<close>)
    2.67 +    apply (tactic \<open>Record.split_simp_tac \<^context> [] (K ~1) 1\<close>)
    2.68      apply auto 
    2.69      done
    2.70  end
    2.71 @@ -417,7 +417,7 @@
    2.72  
    2.73  lemma "\<exists>r. A155 r = x"
    2.74    apply (tactic \<open>simp_tac
    2.75 -    (put_simpset HOL_basic_ss @{context} addsimprocs [Record.ex_sel_eq_simproc]) 1\<close>)
    2.76 +    (put_simpset HOL_basic_ss \<^context> addsimprocs [Record.ex_sel_eq_simproc]) 1\<close>)
    2.77    done
    2.78  
    2.79  print_record many_A
     3.1 --- a/src/Doc/Classes/Classes.thy	Sat Jan 05 17:00:43 2019 +0100
     3.2 +++ b/src/Doc/Classes/Classes.thy	Sat Jan 05 17:24:33 2019 +0100
     3.3 @@ -119,7 +119,7 @@
     3.4  subsection \<open>Class instantiation \label{sec:class_inst}\<close>
     3.5  
     3.6  text \<open>
     3.7 -  The concrete type @{typ int} is made a @{class semigroup} instance
     3.8 +  The concrete type \<^typ>\<open>int\<close> is made a \<^class>\<open>semigroup\<close> instance
     3.9    by providing a suitable definition for the class parameter \<open>(\<otimes>)\<close> and a proof for the specification of @{fact assoc}.  This is
    3.10    accomplished by the @{command instantiation} target:
    3.11  \<close>
    3.12 @@ -149,11 +149,10 @@
    3.13    relevant primitive proof goals; typically it is the first method
    3.14    applied in an instantiation proof.
    3.15  
    3.16 -  From now on, the type-checker will consider @{typ int} as a @{class
    3.17 -  semigroup} automatically, i.e.\ any general results are immediately
    3.18 +  From now on, the type-checker will consider \<^typ>\<open>int\<close> as a \<^class>\<open>semigroup\<close> automatically, i.e.\ any general results are immediately
    3.19    available on concrete instances.
    3.20  
    3.21 -  \<^medskip> Another instance of @{class semigroup} yields the natural
    3.22 +  \<^medskip> Another instance of \<^class>\<open>semigroup\<close> yields the natural
    3.23    numbers:
    3.24  \<close>
    3.25  
    3.26 @@ -206,7 +205,7 @@
    3.27    \<^noindent> Associativity of product semigroups is established using
    3.28    the definition of \<open>(\<otimes>)\<close> on products and the hypothetical
    3.29    associativity of the type components; these hypotheses are
    3.30 -  legitimate due to the @{class semigroup} constraints imposed on the
    3.31 +  legitimate due to the \<^class>\<open>semigroup\<close> constraints imposed on the
    3.32    type components by the @{command instance} proposition.  Indeed,
    3.33    this pattern often occurs with parametric types and type classes.
    3.34  \<close>
    3.35 @@ -216,7 +215,7 @@
    3.36  
    3.37  text \<open>
    3.38    We define a subclass \<open>monoidl\<close> (a semigroup with a left-hand
    3.39 -  neutral) by extending @{class semigroup} with one additional
    3.40 +  neutral) by extending \<^class>\<open>semigroup\<close> with one additional
    3.41    parameter \<open>neutral\<close> together with its characteristic property:
    3.42  \<close>
    3.43  
    3.44 @@ -388,7 +387,7 @@
    3.45  qed
    3.46  
    3.47  text \<open>
    3.48 -  \<^noindent> Here the \qt{@{keyword "in"} @{class group}} target
    3.49 +  \<^noindent> Here the \qt{@{keyword "in"} \<^class>\<open>group\<close>} target
    3.50    specification indicates that the result is recorded within that
    3.51    context for later use.  This local theorem is also lifted to the
    3.52    global one @{fact "group.left_cancel:"} @{prop [source] "\<And>x y z ::
    3.53 @@ -433,7 +432,7 @@
    3.54    functors that have a canonical interpretation as type classes.
    3.55    There is also the possibility of other interpretations.  For
    3.56    example, \<open>list\<close>s also form a monoid with \<open>append\<close> and
    3.57 -  @{term "[]"} as operations, but it seems inappropriate to apply to
    3.58 +  \<^term>\<open>[]\<close> as operations, but it seems inappropriate to apply to
    3.59    lists the same operations as for genuinely algebraic types.  In such
    3.60    a case, we can simply make a particular interpretation of monoids
    3.61    for lists:
    3.62 @@ -469,7 +468,7 @@
    3.63  text \<open>
    3.64    \<^noindent> This pattern is also helpful to reuse abstract
    3.65    specifications on the \emph{same} type.  For example, think of a
    3.66 -  class \<open>preorder\<close>; for type @{typ nat}, there are at least two
    3.67 +  class \<open>preorder\<close>; for type \<^typ>\<open>nat\<close>, there are at least two
    3.68    possible instances: the natural order or the order induced by the
    3.69    divides relation.  But only one of these instances can be used for
    3.70    @{command instantiation}; using the locale behind the class \<open>preorder\<close>, it is still possible to utilise the same abstract
     4.1 --- a/src/Doc/Classes/Setup.thy	Sat Jan 05 17:00:43 2019 +0100
     4.2 +++ b/src/Doc/Classes/Setup.thy	Sat Jan 05 17:24:33 2019 +0100
     4.3 @@ -18,18 +18,18 @@
     4.4      fun alpha_ast_tr [] = Ast.Variable "'a"
     4.5        | alpha_ast_tr asts = raise Ast.AST ("alpha_ast_tr", asts);
     4.6      fun alpha_ofsort_ast_tr [ast] =
     4.7 -          Ast.Appl [Ast.Constant @{syntax_const "_ofsort"}, Ast.Variable "'a", ast]
     4.8 +          Ast.Appl [Ast.Constant \<^syntax_const>\<open>_ofsort\<close>, Ast.Variable "'a", ast]
     4.9        | alpha_ofsort_ast_tr asts = raise Ast.AST ("alpha_ast_tr", asts);
    4.10      fun beta_ast_tr [] = Ast.Variable "'b"
    4.11        | beta_ast_tr asts = raise Ast.AST ("beta_ast_tr", asts);
    4.12      fun beta_ofsort_ast_tr [ast] =
    4.13 -          Ast.Appl [Ast.Constant @{syntax_const "_ofsort"}, Ast.Variable "'b", ast]
    4.14 +          Ast.Appl [Ast.Constant \<^syntax_const>\<open>_ofsort\<close>, Ast.Variable "'b", ast]
    4.15        | beta_ofsort_ast_tr asts = raise Ast.AST ("beta_ast_tr", asts);
    4.16    in
    4.17 -   [(@{syntax_const "_alpha"}, K alpha_ast_tr),
    4.18 -    (@{syntax_const "_alpha_ofsort"}, K alpha_ofsort_ast_tr),
    4.19 -    (@{syntax_const "_beta"}, K beta_ast_tr),
    4.20 -    (@{syntax_const "_beta_ofsort"}, K beta_ofsort_ast_tr)]
    4.21 +   [(\<^syntax_const>\<open>_alpha\<close>, K alpha_ast_tr),
    4.22 +    (\<^syntax_const>\<open>_alpha_ofsort\<close>, K alpha_ofsort_ast_tr),
    4.23 +    (\<^syntax_const>\<open>_beta\<close>, K beta_ast_tr),
    4.24 +    (\<^syntax_const>\<open>_beta_ofsort\<close>, K beta_ofsort_ast_tr)]
    4.25    end
    4.26  \<close>
    4.27  
     5.1 --- a/src/Doc/Codegen/Adaptation.thy	Sat Jan 05 17:00:43 2019 +0100
     5.2 +++ b/src/Doc/Codegen/Adaptation.thy	Sat Jan 05 17:24:33 2019 +0100
     5.3 @@ -127,10 +127,9 @@
     5.4        \secref{sec:adaptation_mechanisms})
     5.5  
     5.6      \item Such parametrisations can involve references to a
     5.7 -      target-specific standard \<open>library\<close> (e.g. using the \<open>Haskell\<close> @{verbatim Maybe} type instead of the \<open>HOL\<close>
     5.8 -      @{type "option"} type); if such are used, the corresponding
     5.9 -      identifiers (in our example, @{verbatim Maybe}, @{verbatim
    5.10 -      Nothing} and @{verbatim Just}) also have to be considered \<open>reserved\<close>.
    5.11 +      target-specific standard \<open>library\<close> (e.g. using the \<open>Haskell\<close> \<^verbatim>\<open>Maybe\<close> type instead of the \<open>HOL\<close>
    5.12 +      \<^type>\<open>option\<close> type); if such are used, the corresponding
    5.13 +      identifiers (in our example, \<^verbatim>\<open>Maybe\<close>, \<^verbatim>\<open>Nothing\<close> and \<^verbatim>\<open>Just\<close>) also have to be considered \<open>reserved\<close>.
    5.14  
    5.15      \item Even more, the user can enrich the library of the
    5.16        target-language by providing code snippets (\qt{\<open>includes\<close>}) which are prepended to any generated code (see
    5.17 @@ -147,7 +146,7 @@
    5.18  subsection \<open>Common adaptation applications \label{sec:common_adaptation}\<close>
    5.19  
    5.20  text \<open>
    5.21 -  The @{theory Main} theory of Isabelle/HOL already provides a code
    5.22 +  The \<^theory>\<open>Main\<close> theory of Isabelle/HOL already provides a code
    5.23    generator setup which should be suitable for most applications.
    5.24    Common extensions and modifications are available by certain
    5.25    theories in \<^dir>\<open>~~/src/HOL/Library\<close>; beside being useful in
    5.26 @@ -156,22 +155,21 @@
    5.27  
    5.28    \begin{description}
    5.29  
    5.30 -    \item[@{theory "HOL.Code_Numeral"}] provides additional numeric
    5.31 -       types @{typ integer} and @{typ natural} isomorphic to types
    5.32 -       @{typ int} and @{typ nat} respectively.  Type @{typ integer}
    5.33 -       is mapped to target-language built-in integers; @{typ natural}
    5.34 -       is implemented as abstract type over @{typ integer}.
    5.35 +    \item[\<^theory>\<open>HOL.Code_Numeral\<close>] provides additional numeric
    5.36 +       types \<^typ>\<open>integer\<close> and \<^typ>\<open>natural\<close> isomorphic to types
    5.37 +       \<^typ>\<open>int\<close> and \<^typ>\<open>nat\<close> respectively.  Type \<^typ>\<open>integer\<close>
    5.38 +       is mapped to target-language built-in integers; \<^typ>\<open>natural\<close>
    5.39 +       is implemented as abstract type over \<^typ>\<open>integer\<close>.
    5.40         Useful for code setups which involve e.g.~indexing
    5.41         of target-language arrays.  Part of \<open>HOL-Main\<close>.
    5.42  
    5.43 -    \item[@{theory "HOL.String"}] provides an additional datatype @{typ
    5.44 -       String.literal} which is isomorphic to lists of 7-bit (ASCII) characters;
    5.45 -       @{typ String.literal}s are mapped to target-language strings.
    5.46 +    \item[\<^theory>\<open>HOL.String\<close>] provides an additional datatype \<^typ>\<open>String.literal\<close> which is isomorphic to lists of 7-bit (ASCII) characters;
    5.47 +       \<^typ>\<open>String.literal\<close>s are mapped to target-language strings.
    5.48  
    5.49 -       Literal values of type @{typ String.literal} can be written
    5.50 +       Literal values of type \<^typ>\<open>String.literal\<close> can be written
    5.51         as \<open>STR ''\<dots>''\<close> for sequences of printable characters and
    5.52         \<open>STR 0x\<dots>\<close> for one single ASCII code point given
    5.53 -       as hexadecimal numeral; @{typ String.literal} supports concatenation
    5.54 +       as hexadecimal numeral; \<^typ>\<open>String.literal\<close> supports concatenation
    5.55         \<open>\<dots> + \<dots>\<close> for all standard target languages.
    5.56  
    5.57         Note that the particular notion of \qt{string} is target-language
    5.58 @@ -181,37 +179,36 @@
    5.59         like verifying parsing algorithms require a dedicated
    5.60         target-language specific model.
    5.61  
    5.62 -       Nevertheless @{typ String.literal}s can be analyzed; the core operations
    5.63 -       for this are @{term_type String.asciis_of_literal} and
    5.64 -       @{term_type String.literal_of_asciis} which are implemented
    5.65 -       in a target-language-specific way; particularly @{const String.asciis_of_literal}
    5.66 +       Nevertheless \<^typ>\<open>String.literal\<close>s can be analyzed; the core operations
    5.67 +       for this are \<^term_type>\<open>String.asciis_of_literal\<close> and
    5.68 +       \<^term_type>\<open>String.literal_of_asciis\<close> which are implemented
    5.69 +       in a target-language-specific way; particularly \<^const>\<open>String.asciis_of_literal\<close>
    5.70         checks its argument at runtime to make sure that it does
    5.71         not contain non-ASCII-characters, to safeguard consistency.
    5.72 -       On top of these, more abstract conversions like @{term_type
    5.73 -       String.explode} and @{term_type String.implode}
    5.74 +       On top of these, more abstract conversions like \<^term_type>\<open>String.explode\<close> and \<^term_type>\<open>String.implode\<close>
    5.75         are implemented.
    5.76         
    5.77         Part of \<open>HOL-Main\<close>.
    5.78  
    5.79 -    \item[\<open>Code_Target_Int\<close>] implements type @{typ int}
    5.80 -       by @{typ integer} and thus by target-language built-in integers.
    5.81 +    \item[\<open>Code_Target_Int\<close>] implements type \<^typ>\<open>int\<close>
    5.82 +       by \<^typ>\<open>integer\<close> and thus by target-language built-in integers.
    5.83  
    5.84      \item[\<open>Code_Binary_Nat\<close>] implements type
    5.85 -       @{typ nat} using a binary rather than a linear representation,
    5.86 +       \<^typ>\<open>nat\<close> using a binary rather than a linear representation,
    5.87         which yields a considerable speedup for computations.
    5.88 -       Pattern matching with @{term "0::nat"} / @{const "Suc"} is eliminated
    5.89 +       Pattern matching with \<^term>\<open>0::nat\<close> / \<^const>\<open>Suc\<close> is eliminated
    5.90         by a preprocessor.\label{abstract_nat}
    5.91  
    5.92 -    \item[\<open>Code_Target_Nat\<close>] implements type @{typ nat}
    5.93 -       by @{typ integer} and thus by target-language built-in integers.
    5.94 -       Pattern matching with @{term "0::nat"} / @{const "Suc"} is eliminated
    5.95 +    \item[\<open>Code_Target_Nat\<close>] implements type \<^typ>\<open>nat\<close>
    5.96 +       by \<^typ>\<open>integer\<close> and thus by target-language built-in integers.
    5.97 +       Pattern matching with \<^term>\<open>0::nat\<close> / \<^const>\<open>Suc\<close> is eliminated
    5.98         by a preprocessor.
    5.99  
   5.100      \item[\<open>Code_Target_Numeral\<close>] is a convenience theory
   5.101         containing both \<open>Code_Target_Nat\<close> and
   5.102         \<open>Code_Target_Int\<close>.
   5.103  
   5.104 -    \item[@{theory "HOL-Library.IArray"}] provides a type @{typ "'a iarray"}
   5.105 +    \item[\<^theory>\<open>HOL-Library.IArray\<close>] provides a type \<^typ>\<open>'a iarray\<close>
   5.106         isomorphic to lists but implemented by (effectively immutable)
   5.107         arrays \emph{in SML only}.
   5.108  
   5.109 @@ -245,9 +242,7 @@
   5.110    distinguished entities with have nothing to do with the SML-built-in
   5.111    notion of \qt{bool}.  This results in less readable code;
   5.112    additionally, eager evaluation may cause programs to loop or break
   5.113 -  which would perfectly terminate when the existing SML @{verbatim
   5.114 -  "bool"} would be used.  To map the HOL @{typ bool} on SML @{verbatim
   5.115 -  "bool"}, we may use \qn{custom serialisations}:
   5.116 +  which would perfectly terminate when the existing SML \<^verbatim>\<open>bool\<close> would be used.  To map the HOL \<^typ>\<open>bool\<close> on SML \<^verbatim>\<open>bool\<close>, we may use \qn{custom serialisations}:
   5.117  \<close>
   5.118  
   5.119  code_printing %quotett
   5.120 @@ -263,7 +258,7 @@
   5.121    custom serialisation starts with a target language identifier
   5.122    followed by an expression, which during code serialisation is
   5.123    inserted whenever the type constructor would occur.  Each
   5.124 -  ``@{verbatim "_"}'' in a serialisation expression is treated as a
   5.125 +  ``\<^verbatim>\<open>_\<close>'' in a serialisation expression is treated as a
   5.126    placeholder for the constant's or the type constructor's arguments.
   5.127  \<close>
   5.128  
   5.129 @@ -300,7 +295,7 @@
   5.130  
   5.131  text \<open>
   5.132    \noindent Next, we try to map HOL pairs to SML pairs, using the
   5.133 -  infix ``@{verbatim "*"}'' type constructor and parentheses:
   5.134 +  infix ``\<^verbatim>\<open>*\<close>'' type constructor and parentheses:
   5.135  \<close>
   5.136  (*<*)
   5.137  code_printing %invisible
   5.138 @@ -312,11 +307,11 @@
   5.139  | constant Pair \<rightharpoonup> (SML) "!((_),/ (_))"
   5.140  
   5.141  text \<open>
   5.142 -  \noindent The initial bang ``@{verbatim "!"}'' tells the serialiser
   5.143 +  \noindent The initial bang ``\<^verbatim>\<open>!\<close>'' tells the serialiser
   5.144    never to put parentheses around the whole expression (they are
   5.145    already present), while the parentheses around argument place
   5.146    holders tell not to put parentheses around the arguments.  The slash
   5.147 -  ``@{verbatim "/"}'' (followed by arbitrary white space) inserts a
   5.148 +  ``\<^verbatim>\<open>/\<close>'' (followed by arbitrary white space) inserts a
   5.149    space which may be used as a break if necessary during pretty
   5.150    printing.
   5.151  
   5.152 @@ -326,9 +321,9 @@
   5.153    serialisations are completely axiomatic.
   5.154  
   5.155    A further noteworthy detail is that any special character in a
   5.156 -  custom serialisation may be quoted using ``@{verbatim "'"}''; thus,
   5.157 -  in ``@{verbatim "fn '_ => _"}'' the first ``@{verbatim "_"}'' is a
   5.158 -  proper underscore while the second ``@{verbatim "_"}'' is a
   5.159 +  custom serialisation may be quoted using ``\<^verbatim>\<open>'\<close>''; thus,
   5.160 +  in ``\<^verbatim>\<open>fn '_ => _\<close>'' the first ``\<^verbatim>\<open>_\<close>'' is a
   5.161 +  proper underscore while the second ``\<^verbatim>\<open>_\<close>'' is a
   5.162    placeholder.
   5.163  \<close>
   5.164  
   5.165 @@ -337,8 +332,8 @@
   5.166  
   5.167  text \<open>
   5.168    For convenience, the default \<open>HOL\<close> setup for \<open>Haskell\<close>
   5.169 -  maps the @{class equal} class to its counterpart in \<open>Haskell\<close>,
   5.170 -  giving custom serialisations for the class @{class equal}
   5.171 +  maps the \<^class>\<open>equal\<close> class to its counterpart in \<open>Haskell\<close>,
   5.172 +  giving custom serialisations for the class \<^class>\<open>equal\<close>
   5.173    and its operation @{const [source] HOL.equal}.
   5.174  \<close>
   5.175  
   5.176 @@ -348,7 +343,7 @@
   5.177  
   5.178  text \<open>
   5.179    \noindent A problem now occurs whenever a type which is an instance
   5.180 -  of @{class equal} in \<open>HOL\<close> is mapped on a \<open>Haskell\<close>-built-in type which is also an instance of \<open>Haskell\<close>
   5.181 +  of \<^class>\<open>equal\<close> in \<open>HOL\<close> is mapped on a \<open>Haskell\<close>-built-in type which is also an instance of \<open>Haskell\<close>
   5.182    \<open>Eq\<close>:
   5.183  \<close>
   5.184  
     6.1 --- a/src/Doc/Codegen/Computations.thy	Sat Jan 05 17:00:43 2019 +0100
     6.2 +++ b/src/Doc/Codegen/Computations.thy	Sat Jan 05 17:24:33 2019 +0100
     6.3 @@ -80,7 +80,7 @@
     6.4        placeholder for its corresponding type in ML under code generation.
     6.5  
     6.6      \<^item> Then the corresponding computation is an ML function of type
     6.7 -      @{ML_type "Proof.context -> term -> 'ml"}
     6.8 +      \<^ML_type>\<open>Proof.context -> term -> 'ml\<close>
     6.9        partially implementing the morphism \<open>\<Phi> :: \<tau> \<rightarrow> T\<close> for all
    6.10        \<^emph>\<open>input terms\<close> consisting only of input constants and applications.
    6.11  
    6.12 @@ -154,7 +154,7 @@
    6.13  
    6.14        Hence the functional argument accepts the following parameters
    6.15  
    6.16 -        \<^item> A postprocessor function @{ML_type "term -> term"}.
    6.17 +        \<^item> A postprocessor function \<^ML_type>\<open>term -> term\<close>.
    6.18  
    6.19          \<^item> The resulting value as optional argument.
    6.20  
    6.21 @@ -165,7 +165,7 @@
    6.22  \<close>
    6.23  
    6.24  ML_val %quotetypewriter \<open>
    6.25 -  comp_nat @{context} @{term "sum_list [Suc 0, Suc (Suc 0)] * Suc (Suc 0)"}
    6.26 +  comp_nat \<^context> \<^term>\<open>sum_list [Suc 0, Suc (Suc 0)] * Suc (Suc 0)\<close>
    6.27  \<close>
    6.28  
    6.29  text \<open>
    6.30 @@ -193,7 +193,7 @@
    6.31      (fn post => post o HOLogic.mk_nat o int_of_nat o the);
    6.32  
    6.33    val comp_nat_list = @{computation "nat list"}
    6.34 -    (fn post => post o HOLogic.mk_list @{typ nat} o
    6.35 +    (fn post => post o HOLogic.mk_list \<^typ>\<open>nat\<close> o
    6.36        map (HOLogic.mk_nat o int_of_nat) o the);
    6.37  
    6.38    end
    6.39 @@ -272,11 +272,11 @@
    6.40  ML %quotetypewriter \<open>
    6.41    local
    6.42  
    6.43 -  fun raw_dvd (b, ct) = Thm.mk_binop @{cterm "Pure.eq :: bool \<Rightarrow> bool \<Rightarrow> prop"}
    6.44 -    ct (if b then @{cterm True} else @{cterm False});
    6.45 +  fun raw_dvd (b, ct) = Thm.mk_binop \<^cterm>\<open>Pure.eq :: bool \<Rightarrow> bool \<Rightarrow> prop\<close>
    6.46 +    ct (if b then \<^cterm>\<open>True\<close> else \<^cterm>\<open>False\<close>);
    6.47  
    6.48    val (_, dvd_oracle) = Context.>>> (Context.map_theory_result
    6.49 -    (Thm.add_oracle (@{binding dvd}, raw_dvd)));
    6.50 +    (Thm.add_oracle (\<^binding>\<open>dvd\<close>, raw_dvd)));
    6.51  
    6.52    in
    6.53  
    6.54 @@ -293,7 +293,7 @@
    6.55  
    6.56  text \<open>
    6.57      \<^item> Antiquotation @{ML_antiquotation computation_conv} basically yields
    6.58 -      a conversion of type @{ML_type "Proof.context -> cterm -> thm"}
    6.59 +      a conversion of type \<^ML_type>\<open>Proof.context -> cterm -> thm\<close>
    6.60        (see further @{cite "isabelle-implementation"}).
    6.61  
    6.62      \<^item> The antiquotation expects one functional argument to bridge the
    6.63 @@ -311,8 +311,8 @@
    6.64  \<close> (*<*)
    6.65  
    6.66  (*>*) ML_val %quotetypewriter \<open>
    6.67 -  conv_dvd @{context} @{cterm "7 dvd ( 62437867527846782 :: int)"};
    6.68 -  conv_dvd @{context} @{cterm "7 dvd (-62437867527846783 :: int)"};
    6.69 +  conv_dvd \<^context> \<^cterm>\<open>7 dvd ( 62437867527846782 :: int)\<close>;
    6.70 +  conv_dvd \<^context> \<^cterm>\<open>7 dvd (-62437867527846783 :: int)\<close>;
    6.71  \<close>
    6.72  
    6.73  text \<open>
    6.74 @@ -341,7 +341,7 @@
    6.75  
    6.76    fun integer_of_int (@{code int_of_integer} k) = k
    6.77  
    6.78 -  val cterm_of_int = Thm.cterm_of @{context} o HOLogic.mk_numeral o integer_of_int;
    6.79 +  val cterm_of_int = Thm.cterm_of \<^context> o HOLogic.mk_numeral o integer_of_int;
    6.80  
    6.81    val divisor = Thm.dest_arg o Thm.dest_arg;
    6.82  
    6.83 @@ -366,8 +366,8 @@
    6.84  \<close>
    6.85  
    6.86  ML_val %quotetypewriter \<open>
    6.87 -  conv_div @{context}
    6.88 -    @{cterm "46782454343499999992777742432342242323423425 div (7 :: int)"}
    6.89 +  conv_div \<^context>
    6.90 +    \<^cterm>\<open>46782454343499999992777742432342242323423425 div (7 :: int)\<close>
    6.91  \<close>
    6.92  
    6.93  text \<open>
    6.94 @@ -388,7 +388,7 @@
    6.95  text \<open>
    6.96    The \<open>computation_check\<close> antiquotation is convenient if
    6.97    only a positive checking of propositions is desired, because then
    6.98 -  the result type is fixed (@{typ prop}) and all the technical
    6.99 +  the result type is fixed (\<^typ>\<open>prop\<close>) and all the technical
   6.100    matter concerning postprocessing and oracles is done in the framework
   6.101    once and for all:
   6.102  \<close>
   6.103 @@ -402,17 +402,17 @@
   6.104  \<close>
   6.105  
   6.106  text \<open>
   6.107 -  \noindent The HOL judgement @{term Trueprop} embeds an expression
   6.108 -  of type @{typ bool} into @{typ prop}.
   6.109 +  \noindent The HOL judgement \<^term>\<open>Trueprop\<close> embeds an expression
   6.110 +  of type \<^typ>\<open>bool\<close> into \<^typ>\<open>prop\<close>.
   6.111  \<close>
   6.112  
   6.113  ML_val %quotetypewriter \<open>
   6.114 -  check_nat @{context} @{cprop "less (Suc (Suc 0)) (Suc (Suc (Suc 0)))"}
   6.115 +  check_nat \<^context> \<^cprop>\<open>less (Suc (Suc 0)) (Suc (Suc (Suc 0)))\<close>
   6.116  \<close>
   6.117  
   6.118  text \<open>
   6.119    \noindent Note that such computations can only \<^emph>\<open>check\<close>
   6.120 -  for @{typ prop}s to hold but not \<^emph>\<open>decide\<close>.
   6.121 +  for \<^typ>\<open>prop\<close>s to hold but not \<^emph>\<open>decide\<close>.
   6.122  \<close>
   6.123  
   6.124  
   6.125 @@ -436,7 +436,7 @@
   6.126    naively: the compilation pattern for computations fails whenever
   6.127    target-language literals are involved; since various
   6.128    common code generator setups (see \secref{sec:common_adaptation})
   6.129 -  implement @{typ nat} and @{typ int} by target-language literals,
   6.130 +  implement \<^typ>\<open>nat\<close> and \<^typ>\<open>int\<close> by target-language literals,
   6.131    this problem manifests whenever numeric types are involved.
   6.132    In practice, this is circumvented with a dedicated preprocessor
   6.133    setup for literals (see also \secref{sec:input_constants_pitfalls}).
   6.134 @@ -446,7 +446,7 @@
   6.135    too much detail:
   6.136  \<close>
   6.137  
   6.138 -paragraph \<open>An example for @{typ nat}\<close>
   6.139 +paragraph \<open>An example for \<^typ>\<open>nat\<close>\<close>
   6.140  
   6.141  ML %quotetypewriter \<open>
   6.142    val check_nat = @{computation_check terms:
   6.143 @@ -456,10 +456,10 @@
   6.144  \<close>
   6.145  
   6.146  ML_val %quotetypewriter \<open>
   6.147 -  check_nat @{context} @{cprop "even (Suc 0 + 1 + 2 + 3 + 4 + 5)"}
   6.148 +  check_nat \<^context> \<^cprop>\<open>even (Suc 0 + 1 + 2 + 3 + 4 + 5)\<close>
   6.149  \<close>
   6.150    
   6.151 -paragraph \<open>An example for @{typ int}\<close>
   6.152 +paragraph \<open>An example for \<^typ>\<open>int\<close>\<close>
   6.153  
   6.154  ML %quotetypewriter \<open>
   6.155    val check_int = @{computation_check terms:
   6.156 @@ -469,10 +469,10 @@
   6.157  \<close>
   6.158  
   6.159  ML_val %quotetypewriter \<open>
   6.160 -  check_int @{context} @{cprop "even ((0::int) + 1 + 2 + 3 + -1 + -2 + -3)"}
   6.161 +  check_int \<^context> \<^cprop>\<open>even ((0::int) + 1 + 2 + 3 + -1 + -2 + -3)\<close>
   6.162  \<close>
   6.163    
   6.164 -paragraph \<open>An example for @{typ String.literal}\<close>
   6.165 +paragraph \<open>An example for \<^typ>\<open>String.literal\<close>\<close>
   6.166  
   6.167  definition %quote is_cap_letter :: "String.literal \<Rightarrow> bool"
   6.168    where "is_cap_letter s \<longleftrightarrow> (case String.asciis_of_literal s
   6.169 @@ -485,7 +485,7 @@
   6.170  \<close>
   6.171  
   6.172  ML_val %quotetypewriter \<open>
   6.173 -  check_literal @{context} @{cprop "is_cap_letter (STR ''Q'')"}
   6.174 +  check_literal \<^context> \<^cprop>\<open>is_cap_letter (STR ''Q'')\<close>
   6.175  \<close>
   6.176  
   6.177    
   6.178 @@ -500,7 +500,7 @@
   6.179  
   6.180    One option is to hardcode using code antiquotations (see \secref{sec:code_antiq}).
   6.181    Another option is to use pre-existing infrastructure in HOL:
   6.182 -  @{ML "Reification.conv"} and @{ML "Reification.tac"}.
   6.183 +  \<^ML>\<open>Reification.conv\<close> and \<^ML>\<open>Reification.tac\<close>.
   6.184  
   6.185    A simplistic example:
   6.186  \<close>
   6.187 @@ -518,23 +518,23 @@
   6.188  | "interp (Neg f) vs \<longleftrightarrow> \<not> interp f vs"
   6.189  
   6.190  text \<open>
   6.191 -  \noindent The datatype @{type form_ord} represents formulae whose semantics is given by
   6.192 -  @{const interp}.  Note that values are represented by variable indices (@{typ nat})
   6.193 -  whose concrete values are given in list @{term vs}.
   6.194 +  \noindent The datatype \<^type>\<open>form_ord\<close> represents formulae whose semantics is given by
   6.195 +  \<^const>\<open>interp\<close>.  Note that values are represented by variable indices (\<^typ>\<open>nat\<close>)
   6.196 +  whose concrete values are given in list \<^term>\<open>vs\<close>.
   6.197  \<close>
   6.198  
   6.199  ML %quotetypewriter (*<*) \<open>\<close>
   6.200  lemma "thm": fixes x y z :: "'a::order" shows "x < y \<and> x < z \<equiv> interp (And (Less (Suc 0) (Suc (Suc 0))) (Less (Suc 0) 0)) [z, x, y]"
   6.201  ML_prf %quotetypewriter
   6.202  (*>*) \<open>val thm =
   6.203 -  Reification.conv @{context} @{thms interp.simps} @{cterm "x < y \<and> x < z"}\<close> (*<*)
   6.204 -by (tactic \<open>ALLGOALS (resolve_tac @{context} [thm])\<close>)
   6.205 +  Reification.conv \<^context> @{thms interp.simps} \<^cterm>\<open>x < y \<and> x < z\<close>\<close> (*<*)
   6.206 +by (tactic \<open>ALLGOALS (resolve_tac \<^context> [thm])\<close>)
   6.207  (*>*) 
   6.208  
   6.209  text \<open>
   6.210 -  \noindent By virtue of @{fact interp.simps}, @{ML "Reification.conv"} provides a conversion
   6.211 +  \noindent By virtue of @{fact interp.simps}, \<^ML>\<open>Reification.conv\<close> provides a conversion
   6.212    which, for this concrete example, yields @{thm thm [no_vars]}.  Note that the argument
   6.213 -  to @{const interp} does not contain any free variables and can thus be evaluated
   6.214 +  to \<^const>\<open>interp\<close> does not contain any free variables and can thus be evaluated
   6.215    using evaluation.
   6.216  
   6.217    A less meager example can be found in the AFP, session \<open>Regular-Sets\<close>,
     7.1 --- a/src/Doc/Codegen/Evaluation.thy	Sat Jan 05 17:00:43 2019 +0100
     7.2 +++ b/src/Doc/Codegen/Evaluation.thy	Sat Jan 05 17:24:33 2019 +0100
     7.3 @@ -12,8 +12,8 @@
     7.4    Recalling \secref{sec:principle}, code generation turns a system of
     7.5    equations into a program with the \emph{same} equational semantics.
     7.6    As a consequence, this program can be used as a \emph{rewrite
     7.7 -  engine} for terms: rewriting a term @{term "t"} using a program to a
     7.8 -  term @{term "t'"} yields the theorems @{prop "t \<equiv> t'"}.  This
     7.9 +  engine} for terms: rewriting a term \<^term>\<open>t\<close> using a program to a
    7.10 +  term \<^term>\<open>t'\<close> yields the theorems \<^prop>\<open>t \<equiv> t'\<close>.  This
    7.11    application of code generation in the following is referred to as
    7.12    \emph{evaluation}.
    7.13  \<close>
    7.14 @@ -158,10 +158,10 @@
    7.15    \begin{tabular}{l||c|c|c}
    7.16      & \<open>simp\<close> & \<open>nbe\<close> & \<open>code\<close> \tabularnewline \hline \hline
    7.17      interactive evaluation & @{command value} \<open>[simp]\<close> & @{command value} \<open>[nbe]\<close> & @{command value} \<open>[code]\<close> \tabularnewline
    7.18 -    plain evaluation & & & \ttsize@{ML "Code_Evaluation.dynamic_value"} \tabularnewline \hline
    7.19 +    plain evaluation & & & \ttsize\<^ML>\<open>Code_Evaluation.dynamic_value\<close> \tabularnewline \hline
    7.20      evaluation method & @{method code_simp} & @{method normalization} & @{method eval} \tabularnewline
    7.21 -    property conversion & & & \ttsize@{ML "Code_Runtime.dynamic_holds_conv"} \tabularnewline \hline
    7.22 -    conversion & \ttsize@{ML "Code_Simp.dynamic_conv"} & \ttsize@{ML "Nbe.dynamic_conv"}
    7.23 +    property conversion & & & \ttsize\<^ML>\<open>Code_Runtime.dynamic_holds_conv\<close> \tabularnewline \hline
    7.24 +    conversion & \ttsize\<^ML>\<open>Code_Simp.dynamic_conv\<close> & \ttsize\<^ML>\<open>Nbe.dynamic_conv\<close>
    7.25    \end{tabular}
    7.26  \<close>
    7.27  
    7.28 @@ -181,8 +181,8 @@
    7.29    
    7.30  text \<open>
    7.31    For \<open>simp\<close> and \<open>nbe\<close> static evaluation can be achieved using 
    7.32 -  @{ML Code_Simp.static_conv} and @{ML Nbe.static_conv}.
    7.33 -  Note that @{ML Nbe.static_conv} by its very nature
    7.34 +  \<^ML>\<open>Code_Simp.static_conv\<close> and \<^ML>\<open>Nbe.static_conv\<close>.
    7.35 +  Note that \<^ML>\<open>Nbe.static_conv\<close> by its very nature
    7.36    requires an invocation of the ML compiler for every call,
    7.37    which can produce significant overhead.
    7.38  \<close>
     8.1 --- a/src/Doc/Codegen/Foundations.thy	Sat Jan 05 17:00:43 2019 +0100
     8.2 +++ b/src/Doc/Codegen/Foundations.thy	Sat Jan 05 17:24:33 2019 +0100
     8.3 @@ -119,7 +119,7 @@
     8.4    Pre- and postprocessor can be setup to transfer between
     8.5    expressions suitable for logical reasoning and expressions 
     8.6    suitable for execution.  As example, take list membership; logically
     8.7 -  it is expressed as @{term "x \<in> set xs"}.  But for execution
     8.8 +  it is expressed as \<^term>\<open>x \<in> set xs\<close>.  But for execution
     8.9    the intermediate set is not desirable.  Hence the following
    8.10    specification:
    8.11  \<close>
    8.12 @@ -144,7 +144,7 @@
    8.13    \emph{Function transformers} provide a very general
    8.14    interface, transforming a list of function theorems to another list
    8.15    of function theorems, provided that neither the heading constant nor
    8.16 -  its type change.  The @{term "0::nat"} / @{const Suc} pattern
    8.17 +  its type change.  The \<^term>\<open>0::nat\<close> / \<^const>\<open>Suc\<close> pattern
    8.18    used in theory \<open>Code_Abstract_Nat\<close> (see \secref{abstract_nat})
    8.19    uses this interface.
    8.20  
    8.21 @@ -195,8 +195,8 @@
    8.22  \<close>
    8.23  
    8.24  text \<open>
    8.25 -  \noindent You may note that the equality test @{term "xs = []"} has
    8.26 -  been replaced by the predicate @{term "List.null xs"}.  This is due
    8.27 +  \noindent You may note that the equality test \<^term>\<open>xs = []\<close> has
    8.28 +  been replaced by the predicate \<^term>\<open>List.null xs\<close>.  This is due
    8.29    to the default setup of the \qn{preprocessor}.
    8.30  
    8.31    This possibility to select arbitrary code equations is the key
    8.32 @@ -218,8 +218,7 @@
    8.33  code_thms %quote dequeue
    8.34  
    8.35  text \<open>
    8.36 -  \noindent This prints a table with the code equations for @{const
    8.37 -  dequeue}, including \emph{all} code equations those equations depend
    8.38 +  \noindent This prints a table with the code equations for \<^const>\<open>dequeue\<close>, including \emph{all} code equations those equations depend
    8.39    on recursively.  These dependencies themselves can be visualized using
    8.40    the @{command_def code_deps} command.
    8.41  \<close>
    8.42 @@ -242,7 +241,7 @@
    8.43  
    8.44  text \<open>
    8.45    \noindent During preprocessing, the membership test is rewritten,
    8.46 -  resulting in @{const List.member}, which itself performs an explicit
    8.47 +  resulting in \<^const>\<open>List.member\<close>, which itself performs an explicit
    8.48    equality check, as can be seen in the corresponding \<open>SML\<close> code:
    8.49  \<close>
    8.50  
    8.51 @@ -253,11 +252,10 @@
    8.52  text \<open>
    8.53    \noindent Obviously, polymorphic equality is implemented the Haskell
    8.54    way using a type class.  How is this achieved?  HOL introduces an
    8.55 -  explicit class @{class equal} with a corresponding operation @{const
    8.56 -  HOL.equal} such that @{thm equal [no_vars]}.  The preprocessing
    8.57 -  framework does the rest by propagating the @{class equal} constraints
    8.58 +  explicit class \<^class>\<open>equal\<close> with a corresponding operation \<^const>\<open>HOL.equal\<close> such that @{thm equal [no_vars]}.  The preprocessing
    8.59 +  framework does the rest by propagating the \<^class>\<open>equal\<close> constraints
    8.60    through all dependent code equations.  For datatypes, instances of
    8.61 -  @{class equal} are implicitly derived when possible.  For other types,
    8.62 +  \<^class>\<open>equal\<close> are implicitly derived when possible.  For other types,
    8.63    you may instantiate \<open>equal\<close> manually like any other type class.
    8.64  \<close>
    8.65  
    8.66 @@ -281,7 +279,7 @@
    8.67  
    8.68  text \<open>
    8.69    \noindent In the corresponding code, there is no equation
    8.70 -  for the pattern @{term "AQueue [] []"}:
    8.71 +  for the pattern \<^term>\<open>AQueue [] []\<close>:
    8.72  \<close>
    8.73  
    8.74  text %quotetypewriter \<open>
    8.75 @@ -307,10 +305,9 @@
    8.76    by (simp_all add: strict_dequeue'_def split: list.splits)
    8.77  
    8.78  text \<open>
    8.79 -  Observe that on the right hand side of the definition of @{const
    8.80 -  "strict_dequeue'"}, the unspecified constant @{const empty_queue} occurs.
    8.81 -  An attempt to generate code for @{const strict_dequeue'} would
    8.82 -  make the code generator complain that @{const empty_queue} has
    8.83 +  Observe that on the right hand side of the definition of \<^const>\<open>strict_dequeue'\<close>, the unspecified constant \<^const>\<open>empty_queue\<close> occurs.
    8.84 +  An attempt to generate code for \<^const>\<open>strict_dequeue'\<close> would
    8.85 +  make the code generator complain that \<^const>\<open>empty_queue\<close> has
    8.86    no associated code equations.  In most situations unimplemented
    8.87    constants indeed indicated a broken program; however such
    8.88    constants can also be thought of as function definitions which always fail,
    8.89 @@ -339,7 +336,7 @@
    8.90  declare %quote [[code abort: undefined]]
    8.91  
    8.92  text \<open>
    8.93 -  \noindent -- hence @{const undefined} can always be used in such
    8.94 +  \noindent -- hence \<^const>\<open>undefined\<close> can always be used in such
    8.95    situations.
    8.96  \<close>
    8.97  
     9.1 --- a/src/Doc/Codegen/Further.thy	Sat Jan 05 17:00:43 2019 +0100
     9.2 +++ b/src/Doc/Codegen/Further.thy	Sat Jan 05 17:24:33 2019 +0100
     9.3 @@ -30,7 +30,7 @@
     9.4    arbitrary ML code as well.
     9.5  
     9.6    A typical example for @{command code_reflect} can be found in the
     9.7 -  @{theory HOL.Predicate} theory.
     9.8 +  \<^theory>\<open>HOL.Predicate\<close> theory.
     9.9  \<close>
    9.10  
    9.11  
    9.12 @@ -188,7 +188,7 @@
    9.13  text \<open>
    9.14    \noindent This amends the interpretation morphisms such that
    9.15    occurrences of the foundational term @{term [source] "power.powers (\<lambda>n (f :: 'a \<Rightarrow> 'a). f ^^ n)"}
    9.16 -  are folded to a newly defined constant @{const funpows}.
    9.17 +  are folded to a newly defined constant \<^const>\<open>funpows\<close>.
    9.18  
    9.19    After this setup procedure, code generation can continue as usual:
    9.20  \<close>
    10.1 --- a/src/Doc/Codegen/Inductive_Predicate.thy	Sat Jan 05 17:00:43 2019 +0100
    10.2 +++ b/src/Doc/Codegen/Inductive_Predicate.thy	Sat Jan 05 17:24:33 2019 +0100
    10.3 @@ -25,7 +25,7 @@
    10.4    this compiler are described in detail in
    10.5    @{cite "Berghofer-Bulwahn-Haftmann:2009:TPHOL"}.
    10.6  
    10.7 -  Consider the simple predicate @{const append} given by these two
    10.8 +  Consider the simple predicate \<^const>\<open>append\<close> given by these two
    10.9    introduction rules:
   10.10  \<close>
   10.11  
   10.12 @@ -49,7 +49,7 @@
   10.13    output. Modes are similar to types, but use the notation \<open>i\<close>
   10.14    for input and \<open>o\<close> for output.
   10.15   
   10.16 -  For @{term "append"}, the compiler can infer the following modes:
   10.17 +  For \<^term>\<open>append\<close>, the compiler can infer the following modes:
   10.18    \begin{itemize}
   10.19      \item \<open>i \<Rightarrow> i \<Rightarrow> i \<Rightarrow> bool\<close>
   10.20      \item \<open>i \<Rightarrow> i \<Rightarrow> o \<Rightarrow> bool\<close>
   10.21 @@ -203,8 +203,7 @@
   10.22    predicate could be inferred that are not disambiguated by the
   10.23    pattern of the set comprehension.  To disambiguate the modes for the
   10.24    arguments of a predicate, you can state the modes explicitly in the
   10.25 -  @{command "values"} command.  Consider the simple predicate @{term
   10.26 -  "succ"}:
   10.27 +  @{command "values"} command.  Consider the simple predicate \<^term>\<open>succ\<close>:
   10.28  \<close>
   10.29  
   10.30  inductive %quote succ :: "nat \<Rightarrow> nat \<Rightarrow> bool" where
   10.31 @@ -243,14 +242,13 @@
   10.32    (if append [Suc 0, 2] ys zs then Some ys else None)\<close>}
   10.33  
   10.34    \item If you know that the execution returns only one value (it is
   10.35 -    deterministic), then you can use the combinator @{term
   10.36 -    "Predicate.the"}, e.g., a functional concatenation of lists is
   10.37 +    deterministic), then you can use the combinator \<^term>\<open>Predicate.the\<close>, e.g., a functional concatenation of lists is
   10.38      defined with
   10.39  
   10.40      @{term [display] "functional_concat xs ys = Predicate.the (append_i_i_o xs ys)"}
   10.41  
   10.42      Note that if the evaluation does not return a unique value, it
   10.43 -    raises a run-time error @{term "not_unique"}.
   10.44 +    raises a run-time error \<^term>\<open>not_unique\<close>.
   10.45  
   10.46    \end{itemize}
   10.47  \<close>
    11.1 --- a/src/Doc/Codegen/Introduction.thy	Sat Jan 05 17:00:43 2019 +0100
    11.2 +++ b/src/Doc/Codegen/Introduction.thy	Sat Jan 05 17:24:33 2019 +0100
    11.3 @@ -186,8 +186,7 @@
    11.4  \<close>
    11.5  
    11.6  text \<open>
    11.7 -  \noindent Note the parameters with trailing underscore (@{verbatim
    11.8 -  "A_"}), which are the dictionary parameters.
    11.9 +  \noindent Note the parameters with trailing underscore (\<^verbatim>\<open>A_\<close>), which are the dictionary parameters.
   11.10  \<close>
   11.11  
   11.12  
    12.1 --- a/src/Doc/Codegen/Refinement.thy	Sat Jan 05 17:00:43 2019 +0100
    12.2 +++ b/src/Doc/Codegen/Refinement.thy	Sat Jan 05 17:24:33 2019 +0100
    12.3 @@ -56,8 +56,7 @@
    12.4    by (simp_all add: fib_step_def)
    12.5  
    12.6  text \<open>
    12.7 -  \noindent What remains is to implement @{const fib} by @{const
    12.8 -  fib_step} as follows:
    12.9 +  \noindent What remains is to implement \<^const>\<open>fib\<close> by \<^const>\<open>fib_step\<close> as follows:
   12.10  \<close>
   12.11  
   12.12  lemma %quote [code]:
   12.13 @@ -110,7 +109,7 @@
   12.14  code_datatype %quote AQueue
   12.15  
   12.16  text \<open>
   12.17 -  \noindent Here we define a \qt{constructor} @{const "AQueue"} which
   12.18 +  \noindent Here we define a \qt{constructor} \<^const>\<open>AQueue\<close> which
   12.19    is defined in terms of \<open>Queue\<close> and interprets its arguments
   12.20    according to what the \emph{content} of an amortised queue is supposed
   12.21    to be.
   12.22 @@ -147,7 +146,7 @@
   12.23    \noindent It is good style, although no absolute requirement, to
   12.24    provide code equations for the original artefacts of the implemented
   12.25    type, if possible; in our case, these are the datatype constructor
   12.26 -  @{const Queue} and the case combinator @{const case_queue}:
   12.27 +  \<^const>\<open>Queue\<close> and the case combinator \<^const>\<open>case_queue\<close>:
   12.28  \<close>
   12.29  
   12.30  lemma %quote Queue_AQueue [code]:
   12.31 @@ -168,10 +167,10 @@
   12.32  
   12.33  text \<open>
   12.34    The same techniques can also be applied to types which are not
   12.35 -  specified as datatypes, e.g.~type @{typ int} is originally specified
   12.36 +  specified as datatypes, e.g.~type \<^typ>\<open>int\<close> is originally specified
   12.37    as quotient type by means of @{command_def typedef}, but for code
   12.38    generation constants allowing construction of binary numeral values
   12.39 -  are used as constructors for @{typ int}.
   12.40 +  are used as constructors for \<^typ>\<open>int\<close>.
   12.41  
   12.42    This approach however fails if the representation of a type demands
   12.43    invariants; this issue is discussed in the next section.
   12.44 @@ -183,20 +182,20 @@
   12.45  text \<open>
   12.46    Datatype representation involving invariants require a dedicated
   12.47    setup for the type and its primitive operations.  As a running
   12.48 -  example, we implement a type @{typ "'a dlist"} of lists consisting
   12.49 +  example, we implement a type \<^typ>\<open>'a dlist\<close> of lists consisting
   12.50    of distinct elements.
   12.51  
   12.52 -  The specification of @{typ "'a dlist"} itself can be found in theory
   12.53 -  @{theory "HOL-Library.Dlist"}.
   12.54 +  The specification of \<^typ>\<open>'a dlist\<close> itself can be found in theory
   12.55 +  \<^theory>\<open>HOL-Library.Dlist\<close>.
   12.56  
   12.57    The first step is to decide on which representation the abstract
   12.58 -  type (in our example @{typ "'a dlist"}) should be implemented.
   12.59 -  Here we choose @{typ "'a list"}.  Then a conversion from the concrete
   12.60 +  type (in our example \<^typ>\<open>'a dlist\<close>) should be implemented.
   12.61 +  Here we choose \<^typ>\<open>'a list\<close>.  Then a conversion from the concrete
   12.62    type to the abstract type must be specified, here:
   12.63  \<close>
   12.64  
   12.65  text %quote \<open>
   12.66 -  @{term_type Dlist}
   12.67 +  \<^term_type>\<open>Dlist\<close>
   12.68  \<close>
   12.69  
   12.70  text \<open>
   12.71 @@ -205,7 +204,7 @@
   12.72  \<close>
   12.73  
   12.74  text %quote \<open>
   12.75 -  @{term_type list_of_dlist}
   12.76 +  \<^term_type>\<open>list_of_dlist\<close>
   12.77  \<close>
   12.78  
   12.79  text \<open>
   12.80 @@ -219,19 +218,19 @@
   12.81  
   12.82  text \<open>
   12.83    \noindent Note that so far the invariant on representations
   12.84 -  (@{term_type distinct}) has never been mentioned explicitly:
   12.85 +  (\<^term_type>\<open>distinct\<close>) has never been mentioned explicitly:
   12.86    the invariant is only referred to implicitly: all values in
   12.87 -  set @{term "{xs. list_of_dlist (Dlist xs) = xs}"} are invariant,
   12.88 -  and in our example this is exactly @{term "{xs. distinct xs}"}.
   12.89 +  set \<^term>\<open>{xs. list_of_dlist (Dlist xs) = xs}\<close> are invariant,
   12.90 +  and in our example this is exactly \<^term>\<open>{xs. distinct xs}\<close>.
   12.91    
   12.92 -  The primitive operations on @{typ "'a dlist"} are specified
   12.93 -  indirectly using the projection @{const list_of_dlist}.  For
   12.94 -  the empty \<open>dlist\<close>, @{const Dlist.empty}, we finally want
   12.95 +  The primitive operations on \<^typ>\<open>'a dlist\<close> are specified
   12.96 +  indirectly using the projection \<^const>\<open>list_of_dlist\<close>.  For
   12.97 +  the empty \<open>dlist\<close>, \<^const>\<open>Dlist.empty\<close>, we finally want
   12.98    the code equation
   12.99  \<close>
  12.100  
  12.101  text %quote \<open>
  12.102 -  @{term "Dlist.empty = Dlist []"}
  12.103 +  \<^term>\<open>Dlist.empty = Dlist []\<close>
  12.104  \<close>
  12.105  
  12.106  text \<open>
  12.107 @@ -244,7 +243,7 @@
  12.108  
  12.109  text \<open>
  12.110    \noindent This equation logically encodes both the desired code
  12.111 -  equation and that the expression @{const Dlist} is applied to obeys
  12.112 +  equation and that the expression \<^const>\<open>Dlist\<close> is applied to obeys
  12.113    the implicit invariant.  Equations for insertion and removal are
  12.114    similar:
  12.115  \<close>
  12.116 @@ -270,9 +269,9 @@
  12.117    for the meta theory of datatype refinement involving invariants.
  12.118  
  12.119    Typical data structures implemented by representations involving
  12.120 -  invariants are available in the library, theory @{theory "HOL-Library.Mapping"}
  12.121 -  specifies key-value-mappings (type @{typ "('a, 'b) mapping"});
  12.122 -  these can be implemented by red-black-trees (theory @{theory "HOL-Library.RBT"}).
  12.123 +  invariants are available in the library, theory \<^theory>\<open>HOL-Library.Mapping\<close>
  12.124 +  specifies key-value-mappings (type \<^typ>\<open>('a, 'b) mapping\<close>);
  12.125 +  these can be implemented by red-black-trees (theory \<^theory>\<open>HOL-Library.RBT\<close>).
  12.126  \<close>
  12.127  
  12.128  end
    13.1 --- a/src/Doc/Corec/Corec.thy	Sat Jan 05 17:00:43 2019 +0100
    13.2 +++ b/src/Doc/Corec/Corec.thy	Sat Jan 05 17:24:33 2019 +0100
    13.3 @@ -34,7 +34,7 @@
    13.4  primitive corecursion. It describes @{command corec} and related commands:\
    13.5  @{command corecursive}, @{command friend_of_corec}, and @{command coinduction_upto}.
    13.6  It also covers the @{method corec_unique} proof method.
    13.7 -The package is not part of @{theory Main}; it is located in
    13.8 +The package is not part of \<^theory>\<open>Main\<close>; it is located in
    13.9  \<^file>\<open>~~/src/HOL/Library/BNF_Corec.thy\<close>.
   13.10  
   13.11  The @{command corec} command generalizes \keyw{primcorec} in three main
   13.12 @@ -149,7 +149,7 @@
   13.13  \noindent
   13.14  Pointwise sum meets the friendliness criterion. We register it as a friend using
   13.15  the @{command friend_of_corec} command. The command requires us to give a
   13.16 -specification of @{const ssum} where a constructor (@{const SCons}) occurs at
   13.17 +specification of \<^const>\<open>ssum\<close> where a constructor (\<^const>\<open>SCons\<close>) occurs at
   13.18  the outermost position on the right-hand side. Here, we can simply reuse the
   13.19  \keyw{primcorec} specification above:
   13.20  \<close>
   13.21 @@ -171,7 +171,7 @@
   13.22  @{thm [source] relator_eq} theorem collection before it invokes
   13.23  @{method transfer_prover}.
   13.24  
   13.25 -After registering @{const ssum} as a friend, we can use it in the corecursive
   13.26 +After registering \<^const>\<open>ssum\<close> as a friend, we can use it in the corecursive
   13.27  call context, either inside or outside the constructor guard:
   13.28  \<close>
   13.29  
   13.30 @@ -204,7 +204,7 @@
   13.31  The parametricity subgoal is given to \<open>transfer_prover_eq\<close>
   13.32  (Section~\ref{ssec:transfer-prover-eq}).
   13.33  
   13.34 -The @{const sprod} and @{const sexp} functions provide shuffle product and
   13.35 +The \<^const>\<open>sprod\<close> and \<^const>\<open>sexp\<close> functions provide shuffle product and
   13.36  exponentiation on streams. We can use them to define the stream of factorial
   13.37  numbers in two different ways:
   13.38  \<close>
   13.39 @@ -230,7 +230,7 @@
   13.40  \noindent
   13.41  In general, the arguments may be any bounded natural functor (BNF)
   13.42  @{cite "isabelle-datatypes"}, with the restriction that the target codatatype
   13.43 -(@{typ "nat stream"}) may occur only in a \emph{live} position of the BNF. For
   13.44 +(\<^typ>\<open>nat stream\<close>) may occur only in a \emph{live} position of the BNF. For
   13.45  this reason, the following function, on unbounded sets, cannot be registered as
   13.46  a friend:
   13.47  \<close>
   13.48 @@ -252,7 +252,7 @@
   13.49        Node (lab: 'a) (sub: "'a tree list")
   13.50  
   13.51  text \<open>
   13.52 -We first define the pointwise sum of two trees analogously to @{const ssum}:
   13.53 +We first define the pointwise sum of two trees analogously to \<^const>\<open>ssum\<close>:
   13.54  \<close>
   13.55  
   13.56      corec (friend) tsum :: "('a :: plus) tree \<Rightarrow> 'a tree \<Rightarrow> 'a tree" where
   13.57 @@ -261,13 +261,13 @@
   13.58  
   13.59  text \<open>
   13.60  \noindent
   13.61 -Here, @{const map} is the standard map function on lists, and @{const zip}
   13.62 -converts two parallel lists into a list of pairs. The @{const tsum} function is
   13.63 +Here, \<^const>\<open>map\<close> is the standard map function on lists, and \<^const>\<open>zip\<close>
   13.64 +converts two parallel lists into a list of pairs. The \<^const>\<open>tsum\<close> function is
   13.65  primitively corecursive. Instead of @{command corec} \<open>(friend)\<close>, we could
   13.66  also have used \keyw{primcorec} and @{command friend_of_corec}, as we did for
   13.67 -@{const ssum}.
   13.68 +\<^const>\<open>ssum\<close>.
   13.69  
   13.70 -Once @{const tsum} is registered as friendly, we can use it in the corecursive
   13.71 +Once \<^const>\<open>tsum\<close> is registered as friendly, we can use it in the corecursive
   13.72  call context of another function:
   13.73  \<close>
   13.74  
   13.75 @@ -280,7 +280,7 @@
   13.76  @{command corec}, @{command corecursive}, and @{command friend_of_corec}. In
   13.77  particular, nesting through the function type can be expressed using
   13.78  \<open>\<lambda>\<close>-abstractions and function applications rather than through composition
   13.79 -(@{term "(\<circ>)"}, the map function for \<open>\<Rightarrow>\<close>). For example:
   13.80 +(\<^term>\<open>(\<circ>)\<close>, the map function for \<open>\<Rightarrow>\<close>). For example:
   13.81  \<close>
   13.82  
   13.83      codatatype 'a language =
   13.84 @@ -322,7 +322,7 @@
   13.85  finite number of unguarded recursive calls perform this calculation before
   13.86  reaching a guarded corecursive call. Intuitively, the unguarded recursive call
   13.87  can be unfolded to arbitrary finite depth, ultimately yielding a purely
   13.88 -corecursive definition. An example is the @{term primes} function from Di
   13.89 +corecursive definition. An example is the \<^term>\<open>primes\<close> function from Di
   13.90  Gianantonio and Miculan @{cite "di-gianantonio-miculan-2003"}:
   13.91  \<close>
   13.92  
   13.93 @@ -343,15 +343,15 @@
   13.94  The @{command corecursive} command is a variant of @{command corec} that allows
   13.95  us to specify a termination argument for any unguarded self-call.
   13.96  
   13.97 -When called with \<open>m = 1\<close> and \<open>n = 2\<close>, the @{const primes}
   13.98 +When called with \<open>m = 1\<close> and \<open>n = 2\<close>, the \<^const>\<open>primes\<close>
   13.99  function computes the stream of prime numbers. The unguarded call in the
  13.100 -\<open>else\<close> branch increments @{term n} until it is coprime to the first
  13.101 -argument @{term m} (i.e., the greatest common divisor of @{term m} and
  13.102 -@{term n} is \<open>1\<close>).
  13.103 +\<open>else\<close> branch increments \<^term>\<open>n\<close> until it is coprime to the first
  13.104 +argument \<^term>\<open>m\<close> (i.e., the greatest common divisor of \<^term>\<open>m\<close> and
  13.105 +\<^term>\<open>n\<close> is \<open>1\<close>).
  13.106  
  13.107 -For any positive integers @{term m} and @{term n}, the numbers @{term m} and
  13.108 +For any positive integers \<^term>\<open>m\<close> and \<^term>\<open>n\<close>, the numbers \<^term>\<open>m\<close> and
  13.109  \<open>m * n + 1\<close> are coprime, yielding an upper bound on the number of times
  13.110 -@{term n} is increased. Hence, the function will take the \<open>else\<close> branch at
  13.111 +\<^term>\<open>n\<close> is increased. Hence, the function will take the \<open>else\<close> branch at
  13.112  most finitely often before taking the then branch and producing one constructor.
  13.113  There is a slight complication when \<open>m = 0 \<and> n > 1\<close>: Without the first
  13.114  disjunct in the \<open>if\<close> condition, the function could stall. (This corner
  13.115 @@ -410,7 +410,7 @@
  13.116  specifications, our package provides the more advanced proof principle of
  13.117  \emph{coinduction up to congruence}---or simply \emph{coinduction up-to}.
  13.118  
  13.119 -The structural coinduction principle for @{typ "'a stream"}, called
  13.120 +The structural coinduction principle for \<^typ>\<open>'a stream\<close>, called
  13.121  @{thm [source] stream.coinduct}, is as follows:
  13.122  %
  13.123  \begin{indentblock}
  13.124 @@ -421,9 +421,9 @@
  13.125  providing a relation \<open>R\<close> that relates \<open>l\<close> and \<open>r\<close> (first
  13.126  premise) and that constitutes a bisimulation (second premise). Streams that are
  13.127  related by a bisimulation cannot be distinguished by taking observations (via
  13.128 -the selectors @{const shd} and @{const stl}); hence they must be equal.
  13.129 +the selectors \<^const>\<open>shd\<close> and \<^const>\<open>stl\<close>); hence they must be equal.
  13.130  
  13.131 -The coinduction up-to principle after registering @{const sskew} as friendly is
  13.132 +The coinduction up-to principle after registering \<^const>\<open>sskew\<close> as friendly is
  13.133  available as @{thm [source] sskew.coinduct} and as one of the components of
  13.134  the theorem collection @{thm [source] stream.coinduct_upto}:
  13.135  %
  13.136 @@ -432,10 +432,10 @@
  13.137  \end{indentblock}
  13.138  %
  13.139  This rule is almost identical to structural coinduction, except that the
  13.140 -corecursive application of @{term R} is generalized to
  13.141 -@{term "stream.v5.congclp R"}.
  13.142 +corecursive application of \<^term>\<open>R\<close> is generalized to
  13.143 +\<^term>\<open>stream.v5.congclp R\<close>.
  13.144  
  13.145 -The @{const stream.v5.congclp} predicate is equipped with the following
  13.146 +The \<^const>\<open>stream.v5.congclp\<close> predicate is equipped with the following
  13.147  introduction rules:
  13.148  
  13.149  \begin{indentblock}
  13.150 @@ -471,9 +471,9 @@
  13.151  The introduction rules are also available as
  13.152  @{thm [source] sskew.cong_intros}.
  13.153  
  13.154 -Notice that there is no introduction rule corresponding to @{const sexp},
  13.155 -because @{const sexp} has a more restrictive result type than @{const sskew}
  13.156 -(@{typ "nat stream"} vs. @{typ "('a :: {plus,times}) stream"}.
  13.157 +Notice that there is no introduction rule corresponding to \<^const>\<open>sexp\<close>,
  13.158 +because \<^const>\<open>sexp\<close> has a more restrictive result type than \<^const>\<open>sskew\<close>
  13.159 +(\<^typ>\<open>nat stream\<close> vs. \<^typ>\<open>('a :: {plus,times}) stream\<close>.
  13.160  
  13.161  The version numbers, here \<open>v5\<close>, distinguish the different congruence
  13.162  closures generated for a given codatatype as more friends are registered. As
  13.163 @@ -486,10 +486,10 @@
  13.164  most situations. For this purpose, the package maintains the collection
  13.165  @{thm [source] stream.coinduct_upto} of coinduction principles ordered by
  13.166  increasing generality, which works well with Isabelle's philosophy of applying
  13.167 -the first rule that matches. For example, after registering @{const ssum} as a
  13.168 -friend, proving the equality @{term "l = r"} on @{typ "nat stream"} might
  13.169 -require coinduction principle for @{term "nat stream"}, which is up to
  13.170 -@{const ssum}.
  13.171 +the first rule that matches. For example, after registering \<^const>\<open>ssum\<close> as a
  13.172 +friend, proving the equality \<^term>\<open>l = r\<close> on \<^typ>\<open>nat stream\<close> might
  13.173 +require coinduction principle for \<^term>\<open>nat stream\<close>, which is up to
  13.174 +\<^const>\<open>ssum\<close>.
  13.175  
  13.176  The collection @{thm [source] stream.coinduct_upto} is guaranteed to be complete
  13.177  and up to date with respect to the type instances of definitions considered so
  13.178 @@ -523,18 +523,18 @@
  13.179  coinduction principles:
  13.180  %
  13.181  \begin{itemize}
  13.182 -\item @{typ "('a, int) tllist"} up to @{const TNil}, @{const TCons}, and
  13.183 -  @{const square_terminal};
  13.184 -\item @{typ "(nat, 'b) tllist"} up to @{const TNil}, @{const TCons}, and
  13.185 -  @{const square_elems};
  13.186 -\item @{typ "('a, 'b) tllist"} up to @{const TNil} and @{const TCons}.
  13.187 +\item \<^typ>\<open>('a, int) tllist\<close> up to \<^const>\<open>TNil\<close>, \<^const>\<open>TCons\<close>, and
  13.188 +  \<^const>\<open>square_terminal\<close>;
  13.189 +\item \<^typ>\<open>(nat, 'b) tllist\<close> up to \<^const>\<open>TNil\<close>, \<^const>\<open>TCons\<close>, and
  13.190 +  \<^const>\<open>square_elems\<close>;
  13.191 +\item \<^typ>\<open>('a, 'b) tllist\<close> up to \<^const>\<open>TNil\<close> and \<^const>\<open>TCons\<close>.
  13.192  \end{itemize}
  13.193  %
  13.194  The following variant is missing:
  13.195  %
  13.196  \begin{itemize}
  13.197 -\item @{typ "(nat, int) tllist"} up to @{const TNil}, @{const TCons},
  13.198 -  @{const square_elems}, and @{const square_terminal}.
  13.199 +\item \<^typ>\<open>(nat, int) tllist\<close> up to \<^const>\<open>TNil\<close>, \<^const>\<open>TCons\<close>,
  13.200 +  \<^const>\<open>square_elems\<close>, and \<^const>\<open>square_terminal\<close>.
  13.201  \end{itemize}
  13.202  %
  13.203  To generate it without having to define a new function with @{command corec},
  13.204 @@ -569,23 +569,23 @@
  13.205  
  13.206  The @{command corec}, @{command corecursive}, and @{command friend_of_corec}
  13.207  commands generate a property \<open>f.unique\<close> about the function of interest
  13.208 -@{term f} that can be used to prove that any function that satisfies
  13.209 -@{term f}'s corecursive specification must be equal to~@{term f}. For example:
  13.210 +\<^term>\<open>f\<close> that can be used to prove that any function that satisfies
  13.211 +\<^term>\<open>f\<close>'s corecursive specification must be equal to~\<^term>\<open>f\<close>. For example:
  13.212  \[@{thm ssum.unique[no_vars]}\]
  13.213  
  13.214  The uniqueness principles are not restricted to functions defined using
  13.215  @{command corec} or @{command corecursive} or registered with
  13.216 -@{command friend_of_corec}. Suppose @{term "t x"} is an arbitrary term
  13.217 -depending on @{term x}. The @{method corec_unique} proof method, provided by our
  13.218 +@{command friend_of_corec}. Suppose \<^term>\<open>t x\<close> is an arbitrary term
  13.219 +depending on \<^term>\<open>x\<close>. The @{method corec_unique} proof method, provided by our
  13.220  tool, transforms subgoals of the form
  13.221 -\[@{term "(\<forall>x. f x = H x f) \<Longrightarrow> f x = t x"}\]
  13.222 +\[\<^term>\<open>(\<forall>x. f x = H x f) \<Longrightarrow> f x = t x\<close>\]
  13.223  into
  13.224 -\[@{term "\<forall>x. t x = H x t"}\]
  13.225 -The higher-order functional @{term H} must be such that @{term "f x = H x f"}
  13.226 +\[\<^term>\<open>\<forall>x. t x = H x t\<close>\]
  13.227 +The higher-order functional \<^term>\<open>H\<close> must be such that \<^term>\<open>f x = H x f\<close>
  13.228  would be a valid @{command corec} specification, but without nested self-calls
  13.229  or unguarded (recursive) calls. Thus, @{method corec_unique} proves uniqueness
  13.230 -of @{term t} with respect to the given corecursive equation regardless of how
  13.231 -@{term t} was defined. For example:
  13.232 +of \<^term>\<open>t\<close> with respect to the given corecursive equation regardless of how
  13.233 +\<^term>\<open>t\<close> was defined. For example:
  13.234  \<close>
  13.235  
  13.236      lemma
  13.237 @@ -625,12 +625,12 @@
  13.238    @{command_def "corecursive"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close>
  13.239  \end{matharray}
  13.240  
  13.241 -@{rail \<open>
  13.242 +\<^rail>\<open>
  13.243    (@@{command corec} | @@{command corecursive}) target? \<newline>
  13.244      @{syntax cr_options}? fix @'where' prop
  13.245    ;
  13.246    @{syntax_def cr_options}: '(' ((@{syntax plugins} | 'friend' | 'transfer') + ',') ')'
  13.247 -\<close>}
  13.248 +\<close>
  13.249  
  13.250  \medskip
  13.251  
  13.252 @@ -677,12 +677,12 @@
  13.253    @{command_def "friend_of_corec"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close>
  13.254  \end{matharray}
  13.255  
  13.256 -@{rail \<open>
  13.257 +\<^rail>\<open>
  13.258    @@{command friend_of_corec} target? \<newline>
  13.259      @{syntax foc_options}? fix @'where' prop
  13.260    ;
  13.261    @{syntax_def foc_options}: '(' ((@{syntax plugins} | 'transfer') + ',') ')'
  13.262 -\<close>}
  13.263 +\<close>
  13.264  
  13.265  \medskip
  13.266  
  13.267 @@ -720,9 +720,9 @@
  13.268    @{command_def "coinduction_upto"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  13.269  \end{matharray}
  13.270  
  13.271 -@{rail \<open>
  13.272 +\<^rail>\<open>
  13.273    @@{command coinduction_upto} target? name ':' type
  13.274 -\<close>}
  13.275 +\<close>
  13.276  
  13.277  \medskip
  13.278  
  13.279 @@ -774,9 +774,9 @@
  13.280    \label{ssec:corec-and-corecursive-theorems}\<close>
  13.281  
  13.282  text \<open>
  13.283 -For a function @{term f} over codatatype \<open>t\<close>, the @{command corec} and
  13.284 +For a function \<^term>\<open>f\<close> over codatatype \<open>t\<close>, the @{command corec} and
  13.285  @{command corecursive} commands generate the following properties (listed for
  13.286 -@{const sexp}, cf. Section~\ref{ssec:simple-corecursion}):
  13.287 +\<^const>\<open>sexp\<close>, cf. Section~\ref{ssec:simple-corecursion}):
  13.288  
  13.289  \begin{indentblock}
  13.290  \begin{description}
  13.291 @@ -799,7 +799,7 @@
  13.292  
  13.293  \item[\<open>f.\<close>\hthm{inner_induct}\rm:] ~ \\
  13.294  This property is only generated for mixed recursive--corecursive definitions.
  13.295 -For @{const primes} (Section~\ref{ssec:mixed-recursion-corecursion}, it reads as
  13.296 +For \<^const>\<open>primes\<close> (Section~\ref{ssec:mixed-recursion-corecursion}, it reads as
  13.297  follows: \\[\jot]
  13.298  @{thm primes.inner_induct[no_vars]}
  13.299  
  13.300 @@ -892,7 +892,7 @@
  13.301  
  13.302  text \<open>
  13.303  The @{method transfer_prover_eq} proof method replaces the equality relation
  13.304 -@{term "(=)"} with compound relator expressions according to
  13.305 +\<^term>\<open>(=)\<close> with compound relator expressions according to
  13.306  @{thm [source] relator_eq} before calling @{method transfer_prover} on the
  13.307  current subgoal. It tends to work better than plain @{method transfer_prover} on
  13.308  the parametricity proof obligations of @{command corecursive} and
  13.309 @@ -917,7 +917,7 @@
  13.310  this derivation fails if in the arguments of a higher-order constant a type variable
  13.311  occurs on both sides of the function type constructor. The required naturality
  13.312  theorem can then be declared with @{attribute friend_of_corec_simps}. See
  13.313 -@{file "~~/src/HOL/Corec_Examples/Tests/Iterate_GPV.thy"} for an example.
  13.314 +\<^file>\<open>~~/src/HOL/Corec_Examples/Tests/Iterate_GPV.thy\<close> for an example.
  13.315  \<close>
  13.316  
  13.317  
    14.1 --- a/src/Doc/Datatypes/Datatypes.thy	Sat Jan 05 17:00:43 2019 +0100
    14.2 +++ b/src/Doc/Datatypes/Datatypes.thy	Sat Jan 05 17:24:33 2019 +0100
    14.3 @@ -77,7 +77,7 @@
    14.4  finitely many direct subtrees, whereas those of the second and fourth may have
    14.5  infinite branching.
    14.6  
    14.7 -The package is part of @{theory Main}. Additional functionality is provided by
    14.8 +The package is part of \<^theory>\<open>Main\<close>. Additional functionality is provided by
    14.9  the theory \<^file>\<open>~~/src/HOL/Library/BNF_Axiomatization.thy\<close>.
   14.10  
   14.11  The package, like its predecessor, fully adheres to the LCF philosophy
   14.12 @@ -180,10 +180,10 @@
   14.13  
   14.14  text \<open>
   14.15  \noindent
   14.16 -@{const Truue}, @{const Faalse}, and @{const Perhaaps} have the type @{typ trool}.
   14.17 +\<^const>\<open>Truue\<close>, \<^const>\<open>Faalse\<close>, and \<^const>\<open>Perhaaps\<close> have the type \<^typ>\<open>trool\<close>.
   14.18  
   14.19  Polymorphic types are possible, such as the following option type, modeled after
   14.20 -its homologue from the @{theory HOL.Option} theory:
   14.21 +its homologue from the \<^theory>\<open>HOL.Option\<close> theory:
   14.22  \<close>
   14.23  
   14.24  (*<*)
   14.25 @@ -231,7 +231,7 @@
   14.26  text \<open>
   14.27  \noindent
   14.28  Lists were shown in the introduction. Terminated lists are a variant that
   14.29 -stores a value of type @{typ 'b} at the very end:
   14.30 +stores a value of type \<^typ>\<open>'b\<close> at the very end:
   14.31  \<close>
   14.32  
   14.33      datatype (*<*)(in early) (*>*)('a, 'b) tlist = TNil 'b | TCons 'a "('a, 'b) tlist"
   14.34 @@ -269,7 +269,7 @@
   14.35  text \<open>
   14.36  \emph{Nested recursion} occurs when recursive occurrences of a type appear under
   14.37  a type constructor. The introduction showed some examples of trees with nesting
   14.38 -through lists. A more complex example, that reuses our @{type option} type,
   14.39 +through lists. A more complex example, that reuses our \<^type>\<open>option\<close> type,
   14.40  follows:
   14.41  \<close>
   14.42  
   14.43 @@ -297,7 +297,7 @@
   14.44  
   14.45  text \<open>
   14.46  \noindent
   14.47 -The following definition of @{typ 'a}-branching trees is legal:
   14.48 +The following definition of \<^typ>\<open>'a\<close>-branching trees is legal:
   14.49  \<close>
   14.50  
   14.51      datatype 'a ftree = FTLeaf 'a | FTNode "'a \<Rightarrow> 'a ftree"
   14.52 @@ -314,9 +314,9 @@
   14.53  In general, type constructors \<open>('a\<^sub>1, \<dots>, 'a\<^sub>m) t\<close>
   14.54  allow recursion on a subset of their type arguments \<open>'a\<^sub>1\<close>, \ldots,
   14.55  \<open>'a\<^sub>m\<close>. These type arguments are called \emph{live}; the remaining
   14.56 -type arguments are called \emph{dead}. In @{typ "'a \<Rightarrow> 'b"} and
   14.57 -@{typ "('a, 'b) fun_copy"}, the type variable @{typ 'a} is dead and
   14.58 -@{typ 'b} is live.
   14.59 +type arguments are called \emph{dead}. In \<^typ>\<open>'a \<Rightarrow> 'b\<close> and
   14.60 +\<^typ>\<open>('a, 'b) fun_copy\<close>, the type variable \<^typ>\<open>'a\<close> is dead and
   14.61 +\<^typ>\<open>'b\<close> is live.
   14.62  
   14.63  Type constructors must be registered as BNFs to have live arguments. This is
   14.64  done automatically for datatypes and codatatypes introduced by the
   14.65 @@ -403,24 +403,24 @@
   14.66  
   14.67  \medskip
   14.68  
   14.69 -The discriminator @{const null} and the selectors @{const hd} and @{const tl}
   14.70 +The discriminator \<^const>\<open>null\<close> and the selectors \<^const>\<open>hd\<close> and \<^const>\<open>tl\<close>
   14.71  are characterized by the following conditional equations:
   14.72  %
   14.73  \[@{thm list.collapse(1)[of xs, no_vars]}
   14.74    \qquad @{thm list.collapse(2)[of xs, no_vars]}\]
   14.75  %
   14.76  For two-constructor datatypes, a single discriminator constant is sufficient.
   14.77 -The discriminator associated with @{const Cons} is simply
   14.78 -@{term "\<lambda>xs. \<not> null xs"}.
   14.79 +The discriminator associated with \<^const>\<open>Cons\<close> is simply
   14.80 +\<^term>\<open>\<lambda>xs. \<not> null xs\<close>.
   14.81  
   14.82  The \keyw{where} clause at the end of the command specifies a default value for
   14.83  selectors applied to constructors on which they are not a priori specified.
   14.84  In the example, it is used to ensure that the tail of the empty list is itself
   14.85  (instead of being left unspecified).
   14.86  
   14.87 -Because @{const Nil} is nullary, it is also possible to use
   14.88 -@{term "\<lambda>xs. xs = Nil"} as a discriminator. This is the default behavior
   14.89 -if we omit the identifier @{const null} and the associated colon. Some users
   14.90 +Because \<^const>\<open>Nil\<close> is nullary, it is also possible to use
   14.91 +\<^term>\<open>\<lambda>xs. xs = Nil\<close> as a discriminator. This is the default behavior
   14.92 +if we omit the identifier \<^const>\<open>null\<close> and the associated colon. Some users
   14.93  argue against this, because the mixture of constructors and selectors in the
   14.94  characteristic theorems can lead Isabelle's automation to switch between the
   14.95  constructor and the destructor view in surprising ways.
   14.96 @@ -469,7 +469,7 @@
   14.97    @{command_def "datatype"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
   14.98  \end{matharray}
   14.99  
  14.100 -@{rail \<open>
  14.101 +\<^rail>\<open>
  14.102    @@{command datatype} target? @{syntax dt_options}? @{syntax dt_spec}
  14.103    ;
  14.104    @{syntax_def dt_options}: '(' ((@{syntax plugins} | 'discs_sels') + ',') ')'
  14.105 @@ -480,7 +480,7 @@
  14.106       @{syntax map_rel_pred}? (@'where' (prop + '|'))? + @'and')
  14.107    ;
  14.108    @{syntax_def map_rel_pred}: @'for' ((('map' | 'rel' | 'pred') ':' name) +)
  14.109 -\<close>}
  14.110 +\<close>
  14.111  
  14.112  \medskip
  14.113  
  14.114 @@ -516,18 +516,18 @@
  14.115  The left-hand sides of the datatype equations specify the name of the type to
  14.116  define, its type parameters, and additional information:
  14.117  
  14.118 -@{rail \<open>
  14.119 +\<^rail>\<open>
  14.120    @{syntax_def dt_name}: @{syntax tyargs}? name mixfix?
  14.121    ;
  14.122    @{syntax_def tyargs}: typefree | '(' (('dead' | name ':')? typefree + ',') ')'
  14.123 -\<close>}
  14.124 +\<close>
  14.125  
  14.126  \medskip
  14.127  
  14.128  \noindent
  14.129  The syntactic entity \synt{name} denotes an identifier, \synt{mixfix} denotes
  14.130  the usual parenthesized mixfix notation, and \synt{typefree} denotes fixed type
  14.131 -variable (@{typ 'a}, @{typ 'b}, \ldots) @{cite "isabelle-isar-ref"}.
  14.132 +variable (\<^typ>\<open>'a\<close>, \<^typ>\<open>'b\<close>, \ldots) @{cite "isabelle-isar-ref"}.
  14.133  
  14.134  The optional names preceding the type variables allow to override the default
  14.135  names of the set functions (\<open>set\<^sub>1_t\<close>, \ldots, \<open>set\<^sub>m_t\<close>). Type
  14.136 @@ -541,9 +541,9 @@
  14.137  Inside a mutually recursive specification, all defined datatypes must
  14.138  mention exactly the same type variables in the same order.
  14.139  
  14.140 -@{rail \<open>
  14.141 +\<^rail>\<open>
  14.142    @{syntax_def dt_ctor}: (name ':')? name (@{syntax dt_ctor_arg} * ) mixfix?
  14.143 -\<close>}
  14.144 +\<close>
  14.145  
  14.146  \medskip
  14.147  
  14.148 @@ -555,9 +555,9 @@
  14.149  \<open>\<lambda>x. x = C\<^sub>j\<close> for nullary constructors and
  14.150  \<open>t.is_C\<^sub>j\<close> otherwise.
  14.151  
  14.152 -@{rail \<open>
  14.153 +\<^rail>\<open>
  14.154    @{syntax_def dt_ctor_arg}: type | '(' name ':' type ')'
  14.155 -\<close>}
  14.156 +\<close>
  14.157  
  14.158  \medskip
  14.159  
  14.160 @@ -580,9 +580,9 @@
  14.161    @{command_def "datatype_compat"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.162  \end{matharray}
  14.163  
  14.164 -@{rail \<open>
  14.165 +\<^rail>\<open>
  14.166    @@{command datatype_compat} (name +)
  14.167 -\<close>}
  14.168 +\<close>
  14.169  
  14.170  \medskip
  14.171  
  14.172 @@ -595,7 +595,7 @@
  14.173  
  14.174  text \<open>\blankline\<close>
  14.175  
  14.176 -    ML \<open>Old_Datatype_Data.get_info @{theory} @{type_name even_nat}\<close>
  14.177 +    ML \<open>Old_Datatype_Data.get_info \<^theory> \<^type_name>\<open>even_nat\<close>\<close>
  14.178  
  14.179  text \<open>
  14.180  The syntactic entity \synt{name} denotes an identifier @{cite "isabelle-isar-ref"}.
  14.181 @@ -712,7 +712,7 @@
  14.182  text \<open>
  14.183  The free constructor theorems are partitioned in three subgroups. The first
  14.184  subgroup of properties is concerned with the constructors. They are listed below
  14.185 -for @{typ "'a list"}:
  14.186 +for \<^typ>\<open>'a list\<close>:
  14.187  
  14.188  \begin{indentblock}
  14.189  \begin{description}
  14.190 @@ -803,14 +803,14 @@
  14.191  @{thm list.collapse(2)[no_vars]} \\
  14.192  The \<open>[simp]\<close> attribute is exceptionally omitted for datatypes equipped
  14.193  with a single nullary constructor, because a property of the form
  14.194 -@{prop "x = C"} is not suitable as a simplification rule.
  14.195 +\<^prop>\<open>x = C\<close> is not suitable as a simplification rule.
  14.196  
  14.197  \item[\<open>t.\<close>\hthm{distinct_disc} \<open>[dest]\<close>\rm:] ~ \\
  14.198 -These properties are missing for @{typ "'a list"} because there is only one
  14.199 +These properties are missing for \<^typ>\<open>'a list\<close> because there is only one
  14.200  proper discriminator. If the datatype had been introduced with a second
  14.201 -discriminator called @{const nonnull}, they would have read as follows: \\[\jot]
  14.202 -@{prop "null list \<Longrightarrow> \<not> nonnull list"} \\
  14.203 -@{prop "nonnull list \<Longrightarrow> \<not> null list"}
  14.204 +discriminator called \<^const>\<open>nonnull\<close>, they would have read as follows: \\[\jot]
  14.205 +\<^prop>\<open>null list \<Longrightarrow> \<not> nonnull list\<close> \\
  14.206 +\<^prop>\<open>nonnull list \<Longrightarrow> \<not> null list\<close>
  14.207  
  14.208  \item[\<open>t.\<close>\hthm{exhaust_disc} \<open>[case_names C\<^sub>1 \<dots> C\<^sub>n]\<close>\rm:] ~ \\
  14.209  @{thm list.exhaust_disc[no_vars]}
  14.210 @@ -851,7 +851,7 @@
  14.211  
  14.212  text \<open>
  14.213  The functorial theorems are generated for type constructors with at least
  14.214 -one live type argument (e.g., @{typ "'a list"}). They are partitioned in two
  14.215 +one live type argument (e.g., \<^typ>\<open>'a list\<close>). They are partitioned in two
  14.216  subgroups. The first subgroup consists of properties involving the
  14.217  constructors or the destructors and either a set function, the map function,
  14.218  the predicator, or the relator:
  14.219 @@ -867,7 +867,7 @@
  14.220  %(Section~\ref{ssec:transfer}).
  14.221  
  14.222  \item[\<open>t.\<close>\hthm{sel_transfer} \<open>[transfer_rule]\<close>\rm:] ~ \\
  14.223 -This property is missing for @{typ "'a list"} because there is no common
  14.224 +This property is missing for \<^typ>\<open>'a list\<close> because there is no common
  14.225  selector to all constructors. \\
  14.226  The \<open>[transfer_rule]\<close> attribute is set by the \<open>transfer\<close> plugin
  14.227  (Section~\ref{ssec:transfer}).
  14.228 @@ -1182,10 +1182,10 @@
  14.229  induction rule can be obtained by applying the \<open>[unfolded
  14.230  all_mem_range]\<close> attribute on \<open>t.induct\<close>.
  14.231  
  14.232 -\item \emph{The @{const size} function has a slightly different definition.}
  14.233 +\item \emph{The \<^const>\<open>size\<close> function has a slightly different definition.}
  14.234  The new function returns \<open>1\<close> instead of \<open>0\<close> for some nonrecursive
  14.235  constructors. This departure from the old behavior made it possible to implement
  14.236 -@{const size} in terms of the generic function \<open>t.size_t\<close>. Moreover,
  14.237 +\<^const>\<open>size\<close> in terms of the generic function \<open>t.size_t\<close>. Moreover,
  14.238  the new function considers nested occurrences of a value, in the nested
  14.239  recursive case. The old behavior can be obtained by disabling the \<open>size\<close>
  14.240  plugin (Section~\ref{sec:selecting-plugins}) and instantiating the
  14.241 @@ -1381,7 +1381,7 @@
  14.242  text \<open>
  14.243  In a departure from the old datatype package, nested recursion is normally
  14.244  handled via the map functions of the nesting type constructors. For example,
  14.245 -recursive calls are lifted to lists using @{const map}:
  14.246 +recursive calls are lifted to lists using \<^const>\<open>map\<close>:
  14.247  \<close>
  14.248  
  14.249  (*<*)
  14.250 @@ -1397,7 +1397,7 @@
  14.251  \noindent
  14.252  The next example features recursion through the \<open>option\<close> type. Although
  14.253  \<open>option\<close> is not a new-style datatype, it is registered as a BNF with the
  14.254 -map function @{const map_option}:
  14.255 +map function \<^const>\<open>map_option\<close>:
  14.256  \<close>
  14.257  
  14.258      primrec (*<*)(in early) (*>*)sum_btree :: "('a::{zero,plus}) btree \<Rightarrow> 'a" where
  14.259 @@ -1435,7 +1435,7 @@
  14.260  text \<open>
  14.261  \noindent
  14.262  For recursion through curried $n$-ary functions, $n$ applications of
  14.263 -@{term "(\<circ>)"} are necessary. The examples below illustrate the case where
  14.264 +\<^term>\<open>(\<circ>)\<close> are necessary. The examples below illustrate the case where
  14.265  $n = 2$:
  14.266  \<close>
  14.267  
  14.268 @@ -1532,7 +1532,7 @@
  14.269  %
  14.270  %  * higher-order approach, considering nesting as nesting, is more
  14.271  %    compositional -- e.g. we saw how we could reuse an existing polymorphic
  14.272 -%    at or the_default, whereas @{const ats\<^sub>f\<^sub>f} is much more specific
  14.273 +%    at or the_default, whereas \<^const>\<open>ats\<^sub>f\<^sub>f\<close> is much more specific
  14.274  %
  14.275  %  * but:
  14.276  %     * is perhaps less intuitive, because it requires higher-order thinking
  14.277 @@ -1540,7 +1540,7 @@
  14.278  %       mutually recursive version might be nicer
  14.279  %     * is somewhat indirect -- must apply a map first, then compute a result
  14.280  %       (cannot mix)
  14.281 -%     * the auxiliary functions like @{const ats\<^sub>f\<^sub>f} are sometimes useful in own right
  14.282 +%     * the auxiliary functions like \<^const>\<open>ats\<^sub>f\<^sub>f\<close> are sometimes useful in own right
  14.283  %
  14.284  %  * impact on automation unclear
  14.285  %
  14.286 @@ -1561,14 +1561,14 @@
  14.287    @{command_def "primrec"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.288  \end{matharray}
  14.289  
  14.290 -@{rail \<open>
  14.291 +\<^rail>\<open>
  14.292    @@{command primrec} target? @{syntax pr_options}? fixes \<newline>
  14.293    @'where' (@{syntax pr_equation} + '|')
  14.294    ;
  14.295    @{syntax_def pr_options}: '(' ((@{syntax plugins} | 'nonexhaustive' | 'transfer') + ',') ')'
  14.296    ;
  14.297    @{syntax_def pr_equation}: thmdecl? prop
  14.298 -\<close>}
  14.299 +\<close>
  14.300  
  14.301  \medskip
  14.302  
  14.303 @@ -1617,7 +1617,7 @@
  14.304  
  14.305  text \<open>
  14.306  The @{command primrec} command generates the following properties (listed
  14.307 -for @{const tfold}):
  14.308 +for \<^const>\<open>tfold\<close>):
  14.309  
  14.310  \begin{indentblock}
  14.311  \begin{description}
  14.312 @@ -1816,8 +1816,8 @@
  14.313  
  14.314  text \<open>
  14.315  \noindent
  14.316 -Notice that the @{const cont} selector is associated with both @{const Skip}
  14.317 -and @{const Action}.
  14.318 +Notice that the \<^const>\<open>cont\<close> selector is associated with both \<^const>\<open>Skip\<close>
  14.319 +and \<^const>\<open>Action\<close>.
  14.320  \<close>
  14.321  
  14.322  
  14.323 @@ -1863,9 +1863,9 @@
  14.324    @{command_def "codatatype"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.325  \end{matharray}
  14.326  
  14.327 -@{rail \<open>
  14.328 +\<^rail>\<open>
  14.329    @@{command codatatype} target? @{syntax dt_options}? @{syntax dt_spec}
  14.330 -\<close>}
  14.331 +\<close>
  14.332  
  14.333  \medskip
  14.334  
  14.335 @@ -1927,7 +1927,7 @@
  14.336    \label{sssec:coinductive-theorems}\<close>
  14.337  
  14.338  text \<open>
  14.339 -The coinductive theorems are listed below for @{typ "'a llist"}:
  14.340 +The coinductive theorems are listed below for \<^typ>\<open>'a llist\<close>:
  14.341  
  14.342  \begin{indentblock}
  14.343  \begin{description}
  14.344 @@ -2206,7 +2206,7 @@
  14.345    \label{sssec:primcorec-nested-corecursion}\<close>
  14.346  
  14.347  text \<open>
  14.348 -The next pair of examples generalize the @{const literate} and @{const siterate}
  14.349 +The next pair of examples generalize the \<^const>\<open>literate\<close> and \<^const>\<open>siterate\<close>
  14.350  functions (Section~\ref{sssec:primcorec-nested-corecursion}) to possibly
  14.351  infinite trees in which subnodes are organized either as a lazy list (\<open>tree\<^sub>i\<^sub>i\<close>) or as a finite set (\<open>tree\<^sub>i\<^sub>s\<close>). They rely on the map functions of
  14.352  the nesting type constructors to lift the corecursive calls:
  14.353 @@ -2224,9 +2224,9 @@
  14.354  \noindent
  14.355  Both examples follow the usual format for constructor arguments associated
  14.356  with nested recursive occurrences of the datatype. Consider
  14.357 -@{const iterate\<^sub>i\<^sub>i}. The term @{term "g x"} constructs an @{typ "'a llist"}
  14.358 -value, which is turned into an @{typ "'a tree\<^sub>i\<^sub>i llist"} value using
  14.359 -@{const lmap}.
  14.360 +\<^const>\<open>iterate\<^sub>i\<^sub>i\<close>. The term \<^term>\<open>g x\<close> constructs an \<^typ>\<open>'a llist\<close>
  14.361 +value, which is turned into an \<^typ>\<open>'a tree\<^sub>i\<^sub>i llist\<close> value using
  14.362 +\<^const>\<open>lmap\<close>.
  14.363  
  14.364  This format may sometimes feel artificial. The following function constructs
  14.365  a tree with a single, infinite branch from a stream:
  14.366 @@ -2288,7 +2288,7 @@
  14.367  text \<open>
  14.368  \noindent
  14.369  For recursion through curried $n$-ary functions, $n$ applications of
  14.370 -@{term "(\<circ>)"} are necessary. The examples below illustrate the case where
  14.371 +\<^term>\<open>(\<circ>)\<close> are necessary. The examples below illustrate the case where
  14.372  $n = 2$:
  14.373  \<close>
  14.374  
  14.375 @@ -2361,8 +2361,8 @@
  14.376  text \<open>
  14.377  The constructor view is similar to the code view, but there is one separate
  14.378  conditional equation per constructor rather than a single unconditional
  14.379 -equation. Examples that rely on a single constructor, such as @{const literate}
  14.380 -and @{const siterate}, are identical in both styles.
  14.381 +equation. Examples that rely on a single constructor, such as \<^const>\<open>literate\<close>
  14.382 +and \<^const>\<open>siterate\<close>, are identical in both styles.
  14.383  
  14.384  Here is an example where there is a difference:
  14.385  \<close>
  14.386 @@ -2374,15 +2374,15 @@
  14.387  
  14.388  text \<open>
  14.389  \noindent
  14.390 -With the constructor view, we must distinguish between the @{const LNil} and
  14.391 -the @{const LCons} case. The condition for @{const LCons} is
  14.392 -left implicit, as the negation of that for @{const LNil}.
  14.393 +With the constructor view, we must distinguish between the \<^const>\<open>LNil\<close> and
  14.394 +the \<^const>\<open>LCons\<close> case. The condition for \<^const>\<open>LCons\<close> is
  14.395 +left implicit, as the negation of that for \<^const>\<open>LNil\<close>.
  14.396  
  14.397  For this example, the constructor view is slightly more involved than the
  14.398  code equation. Recall the code view version presented in
  14.399  Section~\ref{sssec:primcorec-simple-corecursion}.
  14.400  % TODO: \[{thm code_view.lapp.code}\]
  14.401 -The constructor view requires us to analyze the second argument (@{term ys}).
  14.402 +The constructor view requires us to analyze the second argument (\<^term>\<open>ys\<close>).
  14.403  The code equation generated from the constructor view also suffers from this.
  14.404  % TODO: \[{thm lapp.code}\]
  14.405  
  14.406 @@ -2407,14 +2407,14 @@
  14.407  
  14.408  text \<open>
  14.409  \noindent
  14.410 -Since there is no sequentiality, we can apply the equation for @{const Choice}
  14.411 -without having first to discharge @{term "n mod (4::int) \<noteq> 0"},
  14.412 -@{term "n mod (4::int) \<noteq> 1"}, and
  14.413 -@{term "n mod (4::int) \<noteq> 2"}.
  14.414 +Since there is no sequentiality, we can apply the equation for \<^const>\<open>Choice\<close>
  14.415 +without having first to discharge \<^term>\<open>n mod (4::int) \<noteq> 0\<close>,
  14.416 +\<^term>\<open>n mod (4::int) \<noteq> 1\<close>, and
  14.417 +\<^term>\<open>n mod (4::int) \<noteq> 2\<close>.
  14.418  The price to pay for this elegance is that we must discharge exclusiveness proof
  14.419  obligations, one for each pair of conditions
  14.420 -@{term "(n mod (4::int) = i, n mod (4::int) = j)"}
  14.421 -with @{term "i < j"}. If we prefer not to discharge any obligations, we can
  14.422 +\<^term>\<open>(n mod (4::int) = i, n mod (4::int) = j)\<close>
  14.423 +with \<^term>\<open>i < j\<close>. If we prefer not to discharge any obligations, we can
  14.424  enable the \<open>sequential\<close> option. This pushes the problem to the users of
  14.425  the generated properties.
  14.426  %Here are more examples to conclude:
  14.427 @@ -2455,8 +2455,8 @@
  14.428  
  14.429  text \<open>
  14.430  \noindent
  14.431 -The first formula in the @{const literate} specification indicates which
  14.432 -constructor to choose. For @{const siterate} and @{const every_snd}, no such
  14.433 +The first formula in the \<^const>\<open>literate\<close> specification indicates which
  14.434 +constructor to choose. For \<^const>\<open>siterate\<close> and \<^const>\<open>every_snd\<close>, no such
  14.435  formula is necessary, since the type has only one constructor. The last two
  14.436  formulas are equations specifying the value of the result for the relevant
  14.437  selectors. Corecursive calls appear directly to the right of the equal sign.
  14.438 @@ -2514,8 +2514,7 @@
  14.439  
  14.440  text \<open>
  14.441  \noindent
  14.442 -Using the \<open>of\<close> keyword, different equations are specified for @{const
  14.443 -cont} depending on which constructor is selected.
  14.444 +Using the \<open>of\<close> keyword, different equations are specified for \<^const>\<open>cont\<close> depending on which constructor is selected.
  14.445  
  14.446  Here are more examples to conclude:
  14.447  \<close>
  14.448 @@ -2550,14 +2549,14 @@
  14.449    @{command_def "primcorecursive"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close>
  14.450  \end{matharray}
  14.451  
  14.452 -@{rail \<open>
  14.453 +\<^rail>\<open>
  14.454    (@@{command primcorec} | @@{command primcorecursive}) target? \<newline>
  14.455      @{syntax pcr_options}? fixes @'where' (@{syntax pcr_formula} + '|')
  14.456    ;
  14.457    @{syntax_def pcr_options}: '(' ((@{syntax plugins} | 'sequential' | 'exhaustive' | 'transfer') + ',') ')'
  14.458    ;
  14.459    @{syntax_def pcr_formula}: thmdecl? prop (@'of' (term * ))?
  14.460 -\<close>}
  14.461 +\<close>
  14.462  
  14.463  \medskip
  14.464  
  14.465 @@ -2610,7 +2609,7 @@
  14.466  
  14.467  text \<open>
  14.468  The @{command primcorec} and @{command primcorecursive} commands generate the
  14.469 -following properties (listed for @{const literate}):
  14.470 +following properties (listed for \<^const>\<open>literate\<close>):
  14.471  
  14.472  \begin{indentblock}
  14.473  \begin{description}
  14.474 @@ -2640,12 +2639,12 @@
  14.475  (Section~\ref{ssec:code-generator}).
  14.476  
  14.477  \item[\<open>f.\<close>\hthm{exclude}\rm:] ~ \\
  14.478 -These properties are missing for @{const literate} because no exclusiveness
  14.479 +These properties are missing for \<^const>\<open>literate\<close> because no exclusiveness
  14.480  proof obligations arose. In general, the properties correspond to the
  14.481  discharged proof obligations.
  14.482  
  14.483  \item[\<open>f.\<close>\hthm{exhaust}\rm:] ~ \\
  14.484 -This property is missing for @{const literate} because no exhaustiveness
  14.485 +This property is missing for \<^const>\<open>literate\<close> because no exhaustiveness
  14.486  proof obligation arose. In general, the property correspond to the discharged
  14.487  proof obligation.
  14.488  
  14.489 @@ -2734,7 +2733,7 @@
  14.490  An $n$-ary BNF is a type constructor equipped with a map function
  14.491  (functorial action), $n$ set functions (natural transformations),
  14.492  and an infinite cardinal bound that satisfy certain properties.
  14.493 -For example, @{typ "'a llist"} is a unary BNF.
  14.494 +For example, \<^typ>\<open>'a llist\<close> is a unary BNF.
  14.495  Its predicator \<open>llist_all ::
  14.496    ('a \<Rightarrow> bool) \<Rightarrow>
  14.497    'a llist \<Rightarrow> bool\<close>
  14.498 @@ -2745,7 +2744,7 @@
  14.499    'a llist \<Rightarrow> 'b llist \<Rightarrow> bool\<close>
  14.500  extends binary predicates over elements to binary predicates over parallel
  14.501  lazy lists. The cardinal bound limits the number of elements returned by the
  14.502 -set function; it may not depend on the cardinality of @{typ 'a}.
  14.503 +set function; it may not depend on the cardinality of \<^typ>\<open>'a\<close>.
  14.504  
  14.505  The type constructors introduced by @{command datatype} and
  14.506  @{command codatatype} are automatically registered as BNFs. In addition, a
  14.507 @@ -2765,8 +2764,8 @@
  14.508  command. Some of the proof obligations are best viewed with the theory
  14.509  \<^file>\<open>~~/src/HOL/Library/Cardinal_Notations.thy\<close> imported.
  14.510  
  14.511 -The type is simply a copy of the function space @{typ "'d \<Rightarrow> 'a"}, where @{typ 'a}
  14.512 -is live and @{typ 'd} is dead. We introduce it together with its map function,
  14.513 +The type is simply a copy of the function space \<^typ>\<open>'d \<Rightarrow> 'a\<close>, where \<^typ>\<open>'a\<close>
  14.514 +is live and \<^typ>\<open>'d\<close> is dead. We introduce it together with its map function,
  14.515  set function, predicator, and relator.
  14.516  \<close>
  14.517  
  14.518 @@ -2870,7 +2869,7 @@
  14.519  
  14.520  For many typedefs, lifting the BNF structure from the raw type to the abstract
  14.521  type can be done uniformly. This is the task of the @{command lift_bnf} command.
  14.522 -Using @{command lift_bnf}, the above registration of @{typ "('d, 'a) fn"} as a
  14.523 +Using @{command lift_bnf}, the above registration of \<^typ>\<open>('d, 'a) fn\<close> as a
  14.524  BNF becomes much shorter:
  14.525  \<close>
  14.526  
  14.527 @@ -2885,7 +2884,7 @@
  14.528  (*>*)
  14.529  
  14.530  text \<open>
  14.531 -For type copies (@{command typedef}s with @{term UNIV} as the representing set),
  14.532 +For type copies (@{command typedef}s with \<^term>\<open>UNIV\<close> as the representing set),
  14.533  the proof obligations are so simple that they can be
  14.534  discharged automatically, yielding another command, @{command copy_bnf}, which
  14.535  does not emit any proof obligations:
  14.536 @@ -2925,7 +2924,7 @@
  14.537  The @{command lift_bnf} command requires us to prove that the set of nonempty lists
  14.538  is closed under the map function and the zip function. The latter only
  14.539  occurs implicitly in the goal, in form of the variable
  14.540 -@{term "zs :: ('a \<times> 'b) list"}.
  14.541 +\<^term>\<open>zs :: ('a \<times> 'b) list\<close>.
  14.542  \<close>
  14.543  
  14.544      lift_bnf (*<*)(no_warn_wits) (*>*)'a nonempty_list
  14.545 @@ -2946,8 +2945,8 @@
  14.546  reasoning abstractly about an arbitrary BNF. The @{command bnf_axiomatization}
  14.547  command below introduces a type \<open>('a, 'b, 'c) F\<close>, three set constants,
  14.548  a map function, a predicator, a relator, and a nonemptiness witness that depends only on
  14.549 -@{typ 'a}. The type \<open>'a \<Rightarrow> ('a, 'b, 'c) F\<close> of the witness can be read
  14.550 -as an implication: Given a witness for @{typ 'a}, we can construct a witness for
  14.551 +\<^typ>\<open>'a\<close>. The type \<open>'a \<Rightarrow> ('a, 'b, 'c) F\<close> of the witness can be read
  14.552 +as an implication: Given a witness for \<^typ>\<open>'a\<close>, we can construct a witness for
  14.553  \<open>('a, 'b, 'c) F\<close>. The BNF properties are postulated as axioms.
  14.554  \<close>
  14.555  
  14.556 @@ -2971,12 +2970,12 @@
  14.557    @{command_def "bnf"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close>
  14.558  \end{matharray}
  14.559  
  14.560 -@{rail \<open>
  14.561 +\<^rail>\<open>
  14.562    @@{command bnf} target? (name ':')? type \<newline>
  14.563      'map:' term ('sets:' (term +))? 'bd:' term \<newline>
  14.564      ('wits:' (term +))? ('rel:' term)? \<newline>
  14.565      ('pred:' term)? @{syntax plugins}?
  14.566 -\<close>}
  14.567 +\<close>
  14.568  
  14.569  \medskip
  14.570  
  14.571 @@ -3004,7 +3003,7 @@
  14.572    @{command_def "lift_bnf"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close>
  14.573  \end{matharray}
  14.574  
  14.575 -@{rail \<open>
  14.576 +\<^rail>\<open>
  14.577    @@{command lift_bnf} target? lb_options? \<newline>
  14.578      @{syntax tyargs} name wit_terms?  \<newline>
  14.579      ('via' thm)? @{syntax map_rel_pred}?
  14.580 @@ -3012,15 +3011,14 @@
  14.581    @{syntax_def lb_options}: '(' ((@{syntax plugins} | 'no_warn_wits') + ',') ')'
  14.582    ;
  14.583    @{syntax_def wit_terms}: '[' 'wits' ':' terms ']'
  14.584 -\<close>}
  14.585 +\<close>
  14.586  \medskip
  14.587  
  14.588  \noindent
  14.589  The @{command lift_bnf} command registers as a BNF an existing type (the
  14.590  \emph{abstract type}) that was defined as a subtype of a BNF (the \emph{raw
  14.591  type}) using the @{command typedef} command. To achieve this, it lifts the BNF
  14.592 -structure on the raw type to the abstract type following a @{term
  14.593 -type_definition} theorem. The theorem is usually inferred from the type, but can
  14.594 +structure on the raw type to the abstract type following a \<^term>\<open>type_definition\<close> theorem. The theorem is usually inferred from the type, but can
  14.595  also be explicitly supplied by means of the optional \<open>via\<close> clause. In
  14.596  addition, custom names for the set functions, the map function, the predicator, and the relator,
  14.597  as well as nonemptiness witnesses can be specified.
  14.598 @@ -3040,15 +3038,15 @@
  14.599    @{command_def "copy_bnf"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.600  \end{matharray}
  14.601  
  14.602 -@{rail \<open>
  14.603 +\<^rail>\<open>
  14.604    @@{command copy_bnf} target? ('(' @{syntax plugins} ')')? \<newline>
  14.605      @{syntax tyargs} name ('via' thm)? @{syntax map_rel_pred}?
  14.606 -\<close>}
  14.607 +\<close>
  14.608  \medskip
  14.609  
  14.610  \noindent
  14.611  The @{command copy_bnf} command performs the same lifting as @{command lift_bnf}
  14.612 -for type copies (@{command typedef}s with @{term UNIV} as the representing set),
  14.613 +for type copies (@{command typedef}s with \<^term>\<open>UNIV\<close> as the representing set),
  14.614  without requiring the user to discharge any proof obligations or provide
  14.615  nonemptiness witnesses.
  14.616  \<close>
  14.617 @@ -3061,13 +3059,13 @@
  14.618    @{command_def "bnf_axiomatization"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.619  \end{matharray}
  14.620  
  14.621 -@{rail \<open>
  14.622 +\<^rail>\<open>
  14.623    @@{command bnf_axiomatization} target? ('(' @{syntax plugins} ')')? \<newline>
  14.624      @{syntax tyargs}? name @{syntax wit_types}? \<newline>
  14.625      mixfix? @{syntax map_rel_pred}?
  14.626    ;
  14.627    @{syntax_def wit_types}: '[' 'wits' ':' types ']'
  14.628 -\<close>}
  14.629 +\<close>
  14.630  
  14.631  \medskip
  14.632  
  14.633 @@ -3078,7 +3076,7 @@
  14.634  
  14.635  The syntactic entity \synt{target} can be used to specify a local context,
  14.636  \synt{name} denotes an identifier, \synt{typefree} denotes fixed type variable
  14.637 -(@{typ 'a}, @{typ 'b}, \ldots), \synt{mixfix} denotes the usual parenthesized
  14.638 +(\<^typ>\<open>'a\<close>, \<^typ>\<open>'b\<close>, \ldots), \synt{mixfix} denotes the usual parenthesized
  14.639  mixfix notation, and \synt{types} denotes a space-separated list of types
  14.640  @{cite "isabelle-isar-ref"}.
  14.641  
  14.642 @@ -3107,9 +3105,9 @@
  14.643    @{command_def "print_bnfs"} & : & \<open>local_theory \<rightarrow>\<close>
  14.644  \end{matharray}
  14.645  
  14.646 -@{rail \<open>
  14.647 +\<^rail>\<open>
  14.648    @@{command print_bnfs}
  14.649 -\<close>}
  14.650 +\<close>
  14.651  \<close>
  14.652  
  14.653  
  14.654 @@ -3147,13 +3145,13 @@
  14.655    @{command_def "free_constructors"} & : & \<open>local_theory \<rightarrow> proof(prove)\<close>
  14.656  \end{matharray}
  14.657  
  14.658 -@{rail \<open>
  14.659 +\<^rail>\<open>
  14.660    @@{command free_constructors} target? @{syntax dt_options} \<newline>
  14.661      name 'for' (@{syntax fc_ctor} + '|') \<newline>
  14.662    (@'where' (prop + '|'))?
  14.663    ;
  14.664    @{syntax_def fc_ctor}: (name ':')? term (name * )
  14.665 -\<close>}
  14.666 +\<close>
  14.667  
  14.668  \medskip
  14.669  
  14.670 @@ -3188,10 +3186,10 @@
  14.671    @{command_def "simps_of_case"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.672  \end{matharray}
  14.673  
  14.674 -@{rail \<open>
  14.675 +\<^rail>\<open>
  14.676    @@{command simps_of_case} target? (name ':')? \<newline>
  14.677      (thm + ) (@'splits' ':' (thm + ))?
  14.678 -\<close>}
  14.679 +\<close>
  14.680  
  14.681  \medskip
  14.682  
  14.683 @@ -3227,10 +3225,10 @@
  14.684    @{command_def "case_of_simps"} & : & \<open>local_theory \<rightarrow> local_theory\<close>
  14.685  \end{matharray}
  14.686  
  14.687 -@{rail \<open>
  14.688 +\<^rail>\<open>
  14.689    @@{command case_of_simps} target? (name ':')? \<newline>
  14.690      (thm + )
  14.691 -\<close>}
  14.692 +\<close>
  14.693  
  14.694  \medskip
  14.695  
  14.696 @@ -3334,7 +3332,7 @@
  14.697  For each datatype \<open>t\<close>, the \hthm{size} plugin generates a generic size
  14.698  function \<open>t.size_t\<close> as well as a specific instance
  14.699  \<open>size :: t \<Rightarrow> nat\<close> belonging to the \<open>size\<close> type class. The
  14.700 -\keyw{fun} command relies on @{const size} to prove termination of recursive
  14.701 +\keyw{fun} command relies on \<^const>\<open>size\<close> to prove termination of recursive
  14.702  functions on datatypes.
  14.703  
  14.704  The plugin derives the following properties:
  14.705 @@ -3356,9 +3354,9 @@
  14.706  @{thm list.size_gen_o_map[no_vars]}
  14.707  
  14.708  \item[\<open>t.\<close>\hthm{size_neq}\rm:] ~ \\
  14.709 -This property is missing for @{typ "'a list"}. If the @{term size} function
  14.710 +This property is missing for \<^typ>\<open>'a list\<close>. If the \<^term>\<open>size\<close> function
  14.711  always evaluates to a non-zero value, this theorem has the form
  14.712 -@{prop "\<not> size x = 0"}.
  14.713 +\<^prop>\<open>\<not> size x = 0\<close>.
  14.714  
  14.715  \end{description}
  14.716  \end{indentblock}
  14.717 @@ -3371,8 +3369,8 @@
  14.718  \<open>'a\<^sub>1, \<dots>, 'a\<^sub>m\<close>, by default \<open>u\<close> values are given a size of 0. This
  14.719  can be improved upon by registering a custom size function of type
  14.720  \<open>('a\<^sub>1 \<Rightarrow> nat) \<Rightarrow> \<dots> \<Rightarrow> ('a\<^sub>m \<Rightarrow> nat) \<Rightarrow> u \<Rightarrow> nat\<close> using
  14.721 -the ML function @{ML BNF_LFP_Size.register_size} or
  14.722 -@{ML BNF_LFP_Size.register_size_global}. See theory
  14.723 +the ML function \<^ML>\<open>BNF_LFP_Size.register_size\<close> or
  14.724 +\<^ML>\<open>BNF_LFP_Size.register_size_global\<close>. See theory
  14.725  \<^file>\<open>~~/src/HOL/Library/Multiset.thy\<close> for an example.
  14.726  \<close>
  14.727  
    15.1 --- a/src/Doc/Eisbach/Manual.thy	Sat Jan 05 17:00:43 2019 +0100
    15.2 +++ b/src/Doc/Eisbach/Manual.thy	Sat Jan 05 17:24:33 2019 +0100
    15.3 @@ -17,7 +17,7 @@
    15.4    The syntax diagram below refers to some syntactic categories that are
    15.5    further defined in @{cite "isabelle-isar-ref"}.
    15.6  
    15.7 -  @{rail \<open>
    15.8 +  \<^rail>\<open>
    15.9      @@{command method} name args @'=' method
   15.10      ;
   15.11      args: term_args? method_args? \<newline> fact_args? decl_args?
   15.12 @@ -29,7 +29,7 @@
   15.13      fact_args: @'uses' (name+)
   15.14      ;
   15.15      decl_args: @'declares' (name+)
   15.16 -  \<close>}
   15.17 +  \<close>
   15.18  \<close>
   15.19  
   15.20  
   15.21 @@ -68,12 +68,12 @@
   15.22  text \<open>
   15.23    Methods can also abstract over terms using the @{keyword_def "for"} keyword,
   15.24    optionally providing type constraints. For instance, the following proof
   15.25 -  method \<open>intro_ex\<close> takes a term @{term y} of any type, which it uses to
   15.26 -  instantiate the @{term x}-variable of \<open>exI\<close> (existential introduction)
   15.27 +  method \<open>intro_ex\<close> takes a term \<^term>\<open>y\<close> of any type, which it uses to
   15.28 +  instantiate the \<^term>\<open>x\<close>-variable of \<open>exI\<close> (existential introduction)
   15.29    before applying the result as a rule. The instantiation is performed here by
   15.30    Isar's @{attribute_ref "where"} attribute. If the current subgoal is to find
   15.31 -  a witness for the given predicate @{term Q}, then this has the effect of
   15.32 -  committing to @{term y}.
   15.33 +  a witness for the given predicate \<^term>\<open>Q\<close>, then this has the effect of
   15.34 +  committing to \<^term>\<open>y\<close>.
   15.35  \<close>
   15.36  
   15.37      method intro_ex for Q :: "'a \<Rightarrow> bool" and y :: 'a =
   15.38 @@ -81,7 +81,7 @@
   15.39  
   15.40  
   15.41  text \<open>
   15.42 -  The term parameters @{term y} and @{term Q} can be used arbitrarily inside
   15.43 +  The term parameters \<^term>\<open>y\<close> and \<^term>\<open>Q\<close> can be used arbitrarily inside
   15.44    the method body, as part of attribute applications or arguments to other
   15.45    methods. The expression is type-checked as far as possible when the method
   15.46    is defined, however dynamic type errors can still occur when it is invoked
   15.47 @@ -224,15 +224,15 @@
   15.48  text \<open>
   15.49    The only non-trivial part above is the final alternative \<open>(erule notE ;
   15.50    solve \<open>prop_solver\<close>)\<close>. Here, in the case that all other alternatives fail,
   15.51 -  the method takes one of the assumptions @{term "\<not> P"} of the current goal
   15.52 +  the method takes one of the assumptions \<^term>\<open>\<not> P\<close> of the current goal
   15.53    and eliminates it with the rule \<open>notE\<close>, causing the goal to be proved to
   15.54 -  become @{term P}. The method then recursively invokes itself on the
   15.55 +  become \<^term>\<open>P\<close>. The method then recursively invokes itself on the
   15.56    remaining goals. The job of the recursive call is to demonstrate that there
   15.57 -  is a contradiction in the original assumptions (i.e.\ that @{term P} can be
   15.58 +  is a contradiction in the original assumptions (i.e.\ that \<^term>\<open>P\<close> can be
   15.59    derived from them). Note this recursive invocation is applied with the
   15.60    @{method solve} method combinator to ensure that a contradiction will indeed
   15.61    be shown. In the case where a contradiction cannot be found, backtracking
   15.62 -  will occur and a different assumption @{term "\<not> Q"} will be chosen for
   15.63 +  will occur and a different assumption \<^term>\<open>\<not> Q\<close> will be chosen for
   15.64    elimination.
   15.65  
   15.66    Note that the recursive call to @{method prop_solver} does not have any
   15.67 @@ -283,7 +283,7 @@
   15.68    The syntax diagram below refers to some syntactic categories that are
   15.69    further defined in @{cite "isabelle-isar-ref"}.
   15.70  
   15.71 -  @{rail \<open>
   15.72 +  \<^rail>\<open>
   15.73      @@{method match} kind @'in' (pattern '\<Rightarrow>' @{syntax text} + '\<bar>')
   15.74      ;
   15.75      kind:
   15.76 @@ -295,7 +295,7 @@
   15.77      fact_name: @{syntax name} @{syntax attributes}? ':'
   15.78      ;
   15.79      args: '(' (('multi' | 'cut' nat?) + ',') ')'
   15.80 -  \<close>}
   15.81 +  \<close>
   15.82  
   15.83    Matching allows methods to introspect the goal state, and to implement more
   15.84    explicit control flow. In the basic case, a term or fact \<open>ts\<close> is given to
   15.85 @@ -313,8 +313,8 @@
   15.86  
   15.87  text \<open>
   15.88    In this example we have a structured Isar proof, with the named assumption
   15.89 -  \<open>X\<close> and a conclusion @{term "P"}. With the match method we can find the
   15.90 -  local facts @{term "Q \<longrightarrow> P"} and @{term "Q"}, binding them to separately as
   15.91 +  \<open>X\<close> and a conclusion \<^term>\<open>P\<close>. With the match method we can find the
   15.92 +  local facts \<^term>\<open>Q \<longrightarrow> P\<close> and \<^term>\<open>Q\<close>, binding them to separately as
   15.93    \<open>I\<close> and \<open>I'\<close>. We then specialize the modus-ponens rule @{thm mp [of Q P]} to
   15.94    these facts to solve the goal.
   15.95  \<close>
   15.96 @@ -354,10 +354,9 @@
   15.97              \<open>match conclusion in A \<Rightarrow> \<open>insert mp [OF I I']\<close>\<close>)
   15.98  
   15.99  text \<open>
  15.100 -  In this example @{term A} is a match variable which is bound to @{term P}
  15.101 +  In this example \<^term>\<open>A\<close> is a match variable which is bound to \<^term>\<open>P\<close>
  15.102    upon a successful match. The inner @{method match} then matches the
  15.103 -  now-bound @{term A} (bound to @{term P}) against the conclusion (also @{term
  15.104 -  P}), finally applying the specialized rule to solve the goal.
  15.105 +  now-bound \<^term>\<open>A\<close> (bound to \<^term>\<open>P\<close>) against the conclusion (also \<^term>\<open>P\<close>), finally applying the specialized rule to solve the goal.
  15.106  
  15.107    Schematic terms like \<open>?P\<close> may also be used to specify match variables, but
  15.108    the result of the match is not bound, and thus cannot be used in the inner
  15.109 @@ -377,14 +376,14 @@
  15.110            \<open>rule exI [where P = Q and x = y, OF U]\<close>\<close>)
  15.111  
  15.112  text \<open>
  15.113 -  The first @{method match} matches the pattern @{term "\<exists>x. Q x"} against the
  15.114 -  current conclusion, binding the term @{term "Q"} in the inner match. Next
  15.115 +  The first @{method match} matches the pattern \<^term>\<open>\<exists>x. Q x\<close> against the
  15.116 +  current conclusion, binding the term \<^term>\<open>Q\<close> in the inner match. Next
  15.117    the pattern \<open>Q y\<close> is matched against all premises of the current subgoal. In
  15.118 -  this case @{term "Q"} is fixed and @{term "y"} may be instantiated. Once a
  15.119 +  this case \<^term>\<open>Q\<close> is fixed and \<^term>\<open>y\<close> may be instantiated. Once a
  15.120    match is found, the local fact \<open>U\<close> is bound to the matching premise and the
  15.121 -  variable @{term "y"} is bound to the matching witness. The existential
  15.122 -  introduction rule \<open>exI:\<close>~@{thm exI} is then instantiated with @{term "y"} as
  15.123 -  the witness and @{term "Q"} as the predicate, with its proof obligation
  15.124 +  variable \<^term>\<open>y\<close> is bound to the matching witness. The existential
  15.125 +  introduction rule \<open>exI:\<close>~@{thm exI} is then instantiated with \<^term>\<open>y\<close> as
  15.126 +  the witness and \<^term>\<open>Q\<close> as the predicate, with its proof obligation
  15.127    solved by the local fact U (using the Isar attribute @{attribute OF}). The
  15.128    following example is a trivial use of this method.
  15.129  \<close>
  15.130 @@ -413,11 +412,10 @@
  15.131          \<open>erule allE [where x = y]\<close>)
  15.132  
  15.133  text \<open>
  15.134 -  Here we take a single parameter @{term y} and specialize the universal
  15.135 +  Here we take a single parameter \<^term>\<open>y\<close> and specialize the universal
  15.136    elimination rule (@{thm allE}) to it, then attempt to apply this specialized
  15.137    rule with @{method erule}. The method @{method erule} will attempt to unify
  15.138 -  with a universal quantifier in the premises that matches the type of @{term
  15.139 -  y}. Since @{keyword "premises"} causes a focus, however, there are no
  15.140 +  with a universal quantifier in the premises that matches the type of \<^term>\<open>y\<close>. Since @{keyword "premises"} causes a focus, however, there are no
  15.141    subgoal premises to be found and thus @{method my_allE_bad} will always
  15.142    fail. If focusing instead left the premises in place, using methods like
  15.143    @{method erule} would lead to unintended behaviour, specifically during
  15.144 @@ -475,8 +473,8 @@
  15.145  
  15.146  text \<open>
  15.147    In this example, the inner @{method match} can find the focused premise
  15.148 -  @{term B}. In contrast, the @{method assumption} method would fail here due
  15.149 -  to @{term B} not being logically accessible.
  15.150 +  \<^term>\<open>B\<close>. In contrast, the @{method assumption} method would fail here due
  15.151 +  to \<^term>\<open>B\<close> not being logically accessible.
  15.152  \<close>
  15.153  
  15.154      lemma "A \<Longrightarrow> A \<and> (B \<longrightarrow> B)"
  15.155 @@ -485,10 +483,8 @@
  15.156                                   \<bar> H': B \<Rightarrow> \<open>rule H'\<close>\<close>)
  15.157  
  15.158  text \<open>
  15.159 -  In this example, the only premise that exists in the first focus is @{term
  15.160 -  "A"}. Prior to the inner match, the rule \<open>impI\<close> changes the goal @{term "B \<longrightarrow>
  15.161 -  B"} into @{term "B \<Longrightarrow> B"}. A standard premise match would also include @{term
  15.162 -  A} as an original premise of the outer match. The \<open>local\<close> argument limits
  15.163 +  In this example, the only premise that exists in the first focus is \<^term>\<open>A\<close>. Prior to the inner match, the rule \<open>impI\<close> changes the goal \<^term>\<open>B \<longrightarrow>
  15.164 +  B\<close> into \<^term>\<open>B \<Longrightarrow> B\<close>. A standard premise match would also include \<^term>\<open>A\<close> as an original premise of the outer match. The \<open>local\<close> argument limits
  15.165    the match to newly focused premises.
  15.166  \<close>
  15.167  
  15.168 @@ -558,8 +554,7 @@
  15.169  text \<open>
  15.170    In this example, the order of schematics in \<open>asm\<close> is actually \<open>?y ?x\<close>, but
  15.171    we instantiate our matched rule in the opposite order. This is because the
  15.172 -  effective rule @{term I} was bound from the match, which declared the @{typ
  15.173 -  'a} slot first and the @{typ 'b} slot second.
  15.174 +  effective rule \<^term>\<open>I\<close> was bound from the match, which declared the \<^typ>\<open>'a\<close> slot first and the \<^typ>\<open>'b\<close> slot second.
  15.175  
  15.176    To get the dynamic behaviour of @{attribute of} we can choose to invoke it
  15.177    \<^emph>\<open>unchecked\<close>. This avoids trying to do any type inference for the provided
  15.178 @@ -586,8 +581,8 @@
  15.179  
  15.180  text \<open>
  15.181    In this example, the pattern \<open>\<And>x :: 'a. ?P x \<Longrightarrow> ?Q x\<close> matches against the
  15.182 -  only premise, giving an appropriately typed slot for @{term y}. After the
  15.183 -  match, the resulting rule is instantiated to @{term y} and then declared as
  15.184 +  only premise, giving an appropriately typed slot for \<^term>\<open>y\<close>. After the
  15.185 +  match, the resulting rule is instantiated to \<^term>\<open>y\<close> and then declared as
  15.186    an @{attribute intros} rule. This is then picked up by @{method prop_solver}
  15.187    to solve the goal.
  15.188  \<close>
  15.189 @@ -611,7 +606,7 @@
  15.190        done
  15.191  
  15.192  text \<open>
  15.193 -  In the first @{method match}, without the \<open>(multi)\<close> argument, @{term I} is
  15.194 +  In the first @{method match}, without the \<open>(multi)\<close> argument, \<^term>\<open>I\<close> is
  15.195    only ever be bound to one of the members of \<open>asms\<close>. This backtracks over
  15.196    both possibilities (see next section), however neither assumption in
  15.197    isolation is sufficient to solve to goal. The use of the @{method solves}
  15.198 @@ -623,7 +618,7 @@
  15.199  
  15.200    Using for-fixed variables in patterns imposes additional constraints on the
  15.201    results. In all previous examples, the choice of using \<open>?P\<close> or a for-fixed
  15.202 -  @{term P} only depended on whether or not @{term P} was mentioned in another
  15.203 +  \<^term>\<open>P\<close> only depended on whether or not \<^term>\<open>P\<close> was mentioned in another
  15.204    pattern or the inner method. When using a multi-match, however, all
  15.205    for-fixed terms must agree in the results.
  15.206  \<close>
  15.207 @@ -653,10 +648,9 @@
  15.208  text \<open>
  15.209    Dummy patterns may be given as placeholders for unique schematics in
  15.210    patterns. They implicitly receive all currently bound variables as
  15.211 -  arguments, and are coerced into the @{typ prop} type whenever possible. For
  15.212 +  arguments, and are coerced into the \<^typ>\<open>prop\<close> type whenever possible. For
  15.213    example, the trivial dummy pattern \<open>_\<close> will match any proposition. In
  15.214 -  contrast, by default the pattern \<open>?P\<close> is considered to have type @{typ
  15.215 -  bool}. It will not bind anything with meta-logical connectives (e.g. \<open>_ \<Longrightarrow> _\<close>
  15.216 +  contrast, by default the pattern \<open>?P\<close> is considered to have type \<^typ>\<open>bool\<close>. It will not bind anything with meta-logical connectives (e.g. \<open>_ \<Longrightarrow> _\<close>
  15.217    or \<open>_ &&& _\<close>).
  15.218  \<close>
  15.219  
  15.220 @@ -718,8 +712,8 @@
  15.221          \<open>rule mp [OF I' I [THEN conjunct1]]\<close>)
  15.222  
  15.223  text \<open>
  15.224 -  In this example, once a conjunction is found (@{term "P \<and> Q"}), all possible
  15.225 -  implications of @{term "P"} in the premises are considered, evaluating the
  15.226 +  In this example, once a conjunction is found (\<^term>\<open>P \<and> Q\<close>), all possible
  15.227 +  implications of \<^term>\<open>P\<close> in the premises are considered, evaluating the
  15.228    inner @{method rule} with each consequent. No other conjunctions will be
  15.229    considered, with method failure occurring once all implications of the form
  15.230    \<open>P \<longrightarrow> ?U\<close> have been explored. Here the left-right processing of individual
  15.231 @@ -735,8 +729,8 @@
  15.232  
  15.233  text \<open>
  15.234    In this example, the first lemma is solved by \<open>foo\<^sub>2\<close>, by first picking
  15.235 -  @{term "A \<longrightarrow> D"} for \<open>I'\<close>, then backtracking and ultimately succeeding after
  15.236 -  picking @{term "A \<longrightarrow> C"}. In the second lemma, however, @{term "C \<and> D"} is
  15.237 +  \<^term>\<open>A \<longrightarrow> D\<close> for \<open>I'\<close>, then backtracking and ultimately succeeding after
  15.238 +  picking \<^term>\<open>A \<longrightarrow> C\<close>. In the second lemma, however, \<^term>\<open>C \<and> D\<close> is
  15.239    matched first, the second pattern in the match cannot be found and so the
  15.240    method fails, falling through to @{method prop_solver}.
  15.241  
  15.242 @@ -768,14 +762,14 @@
  15.243  
  15.244  text \<open>
  15.245    Intuitively it seems like this proof should fail to check. The first match
  15.246 -  result, which binds @{term I} to the first two members of \<open>asms\<close>, fails the
  15.247 -  second inner match due to binding @{term P} to @{term A}. Backtracking then
  15.248 -  attempts to bind @{term I} to the third member of \<open>asms\<close>. This passes all
  15.249 +  result, which binds \<^term>\<open>I\<close> to the first two members of \<open>asms\<close>, fails the
  15.250 +  second inner match due to binding \<^term>\<open>P\<close> to \<^term>\<open>A\<close>. Backtracking then
  15.251 +  attempts to bind \<^term>\<open>I\<close> to the third member of \<open>asms\<close>. This passes all
  15.252    inner matches, but fails when @{method rule} cannot successfully apply this
  15.253    to the current goal. After this, a valid match that is produced by the
  15.254 -  unifier is one which binds @{term P} to simply \<open>\<lambda>a. A ?x\<close>. The first inner
  15.255 -  match succeeds because \<open>\<lambda>a. A ?x\<close> does not match @{term A}. The next inner
  15.256 -  match succeeds because @{term I} has only been bound to the first member of
  15.257 +  unifier is one which binds \<^term>\<open>P\<close> to simply \<open>\<lambda>a. A ?x\<close>. The first inner
  15.258 +  match succeeds because \<open>\<lambda>a. A ?x\<close> does not match \<^term>\<open>A\<close>. The next inner
  15.259 +  match succeeds because \<^term>\<open>I\<close> has only been bound to the first member of
  15.260    \<open>asms\<close>. This is due to @{method match} considering \<open>\<lambda>a. A ?x\<close> and \<open>\<lambda>a. A ?y\<close>
  15.261    as distinct terms.
  15.262  
  15.263 @@ -808,7 +802,7 @@
  15.264  
  15.265  text \<open>
  15.266    For the first member of \<open>asms\<close> the dummy pattern successfully matches
  15.267 -  against @{term "B \<Longrightarrow> C"} and so the proof is successful.
  15.268 +  against \<^term>\<open>B \<Longrightarrow> C\<close> and so the proof is successful.
  15.269  \<close>
  15.270  
  15.271      lemma
  15.272 @@ -820,16 +814,16 @@
  15.273  
  15.274  text \<open>
  15.275    This proof will fail to solve the goal. Our match pattern will only match
  15.276 -  rules which have a single premise, and conclusion @{term C}, so the first
  15.277 +  rules which have a single premise, and conclusion \<^term>\<open>C\<close>, so the first
  15.278    member of \<open>asms\<close> is not bound and thus the proof fails. Matching a pattern
  15.279 -  of the form @{term "P \<Longrightarrow> Q"} against this fact will bind @{term "P"} to
  15.280 -  @{term "A"} and @{term Q} to @{term "B \<Longrightarrow> C"}. Our pattern, with a concrete
  15.281 -  @{term "C"} in the conclusion, will fail to match this fact.
  15.282 +  of the form \<^term>\<open>P \<Longrightarrow> Q\<close> against this fact will bind \<^term>\<open>P\<close> to
  15.283 +  \<^term>\<open>A\<close> and \<^term>\<open>Q\<close> to \<^term>\<open>B \<Longrightarrow> C\<close>. Our pattern, with a concrete
  15.284 +  \<^term>\<open>C\<close> in the conclusion, will fail to match this fact.
  15.285  
  15.286    To express our desired match, we may \<^emph>\<open>uncurry\<close> our rules before matching
  15.287    against them. This forms a meta-conjunction of all premises in a fact, so
  15.288    that only one implication remains. For example the uncurried version of
  15.289 -  @{term "A \<Longrightarrow> B \<Longrightarrow> C"} is @{term "A &&& B \<Longrightarrow> C"}. This will now match our
  15.290 +  \<^term>\<open>A \<Longrightarrow> B \<Longrightarrow> C\<close> is \<^term>\<open>A &&& B \<Longrightarrow> C\<close>. This will now match our
  15.291    desired pattern \<open>_ \<Longrightarrow> C\<close>, and can be \<^emph>\<open>curried\<close> after the match to put it
  15.292    back into normal form.
  15.293  \<close>
  15.294 @@ -861,8 +855,7 @@
  15.295    In the first @{method match} we attempt to find a member of \<open>asms\<close> which
  15.296    matches our goal precisely. This fails due to no such member existing. The
  15.297    second match reverses the role of the fact in the match, by first giving a
  15.298 -  general pattern @{term P}. This bound pattern is then matched against @{term
  15.299 -  "A y"}. In this case, @{term P} is bound to \<open>A ?x\<close> and so it successfully
  15.300 +  general pattern \<^term>\<open>P\<close>. This bound pattern is then matched against \<^term>\<open>A y\<close>. In this case, \<^term>\<open>P\<close> is bound to \<open>A ?x\<close> and so it successfully
  15.301    matches.
  15.302  \<close>
  15.303  
  15.304 @@ -885,7 +878,7 @@
  15.305  text \<open>
  15.306    In this example the type \<open>'b\<close> is matched to \<open>'a\<close>, however statically they
  15.307    are formally distinct types. The first match binds \<open>'b\<close> while the inner
  15.308 -  match serves to coerce @{term y} into having the type \<open>'b\<close>. This allows the
  15.309 +  match serves to coerce \<^term>\<open>y\<close> into having the type \<open>'b\<close>. This allows the
  15.310    rule instantiation to successfully apply.
  15.311  \<close>
  15.312  
  15.313 @@ -895,8 +888,7 @@
  15.314  section \<open>Tracing methods\<close>
  15.315  
  15.316  text \<open>
  15.317 -  Method tracing is supported by auxiliary print methods provided by @{theory
  15.318 -  "HOL-Eisbach.Eisbach_Tools"}. These include @{method print_fact}, @{method
  15.319 +  Method tracing is supported by auxiliary print methods provided by \<^theory>\<open>HOL-Eisbach.Eisbach_Tools\<close>. These include @{method print_fact}, @{method
  15.320    print_term} and @{method print_type}. Whenever a print method is evaluated
  15.321    it leaves the goal unchanged and writes its argument as tracing output.
  15.322  
  15.323 @@ -957,7 +949,7 @@
  15.324  
  15.325  text \<open>
  15.326    Here the new @{method splits} method transforms the goal to use only logical
  15.327 -  connectives: @{term "L = [] \<longrightarrow> False \<and> (\<forall>x y. L = x # y \<longrightarrow> True)"}. This goal
  15.328 +  connectives: \<^term>\<open>L = [] \<longrightarrow> False \<and> (\<forall>x y. L = x # y \<longrightarrow> True)\<close>. This goal
  15.329    is then in a form solvable by @{method prop_solver} when given the universal
  15.330    quantifier introduction rule \<open>allI\<close>.
  15.331  \<close>
    16.1 --- a/src/Doc/Eisbach/Preface.thy	Sat Jan 05 17:00:43 2019 +0100
    16.2 +++ b/src/Doc/Eisbach/Preface.thy	Sat Jan 05 17:24:33 2019 +0100
    16.3 @@ -32,9 +32,8 @@
    16.4    well as the @{method match} method, as well as discussing their integration
    16.5    with existing Isar concepts such as @{command named_theorems}.
    16.6  
    16.7 -  These commands are provided by theory @{theory "HOL-Eisbach.Eisbach"}: it
    16.8 -  needs to be imported by all Eisbach applications. Theory theory @{theory
    16.9 -  "HOL-Eisbach.Eisbach_Tools"} provides additional proof methods and
   16.10 +  These commands are provided by theory \<^theory>\<open>HOL-Eisbach.Eisbach\<close>: it
   16.11 +  needs to be imported by all Eisbach applications. Theory theory \<^theory>\<open>HOL-Eisbach.Eisbach_Tools\<close> provides additional proof methods and
   16.12    attributes that are occasionally useful.
   16.13  \<close>
   16.14  
    17.1 --- a/src/Doc/Functions/Functions.thy	Sat Jan 05 17:00:43 2019 +0100
    17.2 +++ b/src/Doc/Functions/Functions.thy	Sat Jan 05 17:24:33 2019 +0100
    17.3 @@ -25,8 +25,7 @@
    17.4    giving its name, its type, 
    17.5    and a set of defining recursive equations.
    17.6    If we leave out the type, the most general type will be
    17.7 -  inferred, which can sometimes lead to surprises: Since both @{term
    17.8 -  "1::nat"} and \<open>+\<close> are overloaded, we would end up
    17.9 +  inferred, which can sometimes lead to surprises: Since both \<^term>\<open>1::nat\<close> and \<open>+\<close> are overloaded, we would end up
   17.10    with \<open>fib :: nat \<Rightarrow> 'a::{one,plus}\<close>.
   17.11  \<close>
   17.12  
   17.13 @@ -88,13 +87,13 @@
   17.14    Isabelle provides customized induction rules for recursive
   17.15    functions. These rules follow the recursive structure of the
   17.16    definition. Here is the rule @{thm [source] sep.induct} arising from the
   17.17 -  above definition of @{const sep}:
   17.18 +  above definition of \<^const>\<open>sep\<close>:
   17.19  
   17.20    @{thm [display] sep.induct}
   17.21    
   17.22    We have a step case for list with at least two elements, and two
   17.23    base cases for the zero- and the one-element list. Here is a simple
   17.24 -  proof about @{const sep} and @{const map}
   17.25 +  proof about \<^const>\<open>sep\<close> and \<^const>\<open>map\<close>
   17.26  \<close>
   17.27  
   17.28  lemma "map f (sep x ys) = sep (f x) (map f ys)"
   17.29 @@ -219,7 +218,7 @@
   17.30    implicitly refers to the last function definition.
   17.31  
   17.32    The \<open>relation\<close> method takes a relation of
   17.33 -  type @{typ "('a \<times> 'a) set"}, where @{typ "'a"} is the argument type of
   17.34 +  type \<^typ>\<open>('a \<times> 'a) set\<close>, where \<^typ>\<open>'a\<close> is the argument type of
   17.35    the function. If the function has multiple curried arguments, then
   17.36    these are packed together into a tuple, as it happened in the above
   17.37    example.
   17.38 @@ -259,8 +258,7 @@
   17.39    This corresponds to a nested
   17.40    loop where one index counts up and the other down. Termination can
   17.41    be proved using a lexicographic combination of two measures, namely
   17.42 -  the value of \<open>N\<close> and the above difference. The @{const
   17.43 -  "measures"} combinator generalizes \<open>measure\<close> by taking a
   17.44 +  the value of \<open>N\<close> and the above difference. The \<^const>\<open>measures\<close> combinator generalizes \<open>measure\<close> by taking a
   17.45    list of measure functions.  
   17.46  \<close>
   17.47  
   17.48 @@ -368,7 +366,7 @@
   17.49  text \<open>
   17.50    To eliminate the mutual dependencies, Isabelle internally
   17.51    creates a single function operating on the sum
   17.52 -  type @{typ "nat + nat"}. Then, @{const even} and @{const odd} are
   17.53 +  type \<^typ>\<open>nat + nat\<close>. Then, \<^const>\<open>even\<close> and \<^const>\<open>odd\<close> are
   17.54    defined as projections. Consequently, termination has to be proved
   17.55    simultaneously for both functions, by specifying a measure on the
   17.56    sum type: 
   17.57 @@ -390,7 +388,7 @@
   17.58    generally requires simultaneous induction. The induction rule @{thm [source] "even_odd.induct"}
   17.59    generated from the above definition reflects this.
   17.60  
   17.61 -  Let us prove something about @{const even} and @{const odd}:
   17.62 +  Let us prove something about \<^const>\<open>even\<close> and \<^const>\<open>odd\<close>:
   17.63  \<close>
   17.64  
   17.65  lemma even_odd_mod2:
   17.66 @@ -405,7 +403,7 @@
   17.67  
   17.68  text \<open>
   17.69    We get four subgoals, which correspond to the clauses in the
   17.70 -  definition of @{const even} and @{const odd}:
   17.71 +  definition of \<^const>\<open>even\<close> and \<^const>\<open>odd\<close>:
   17.72    @{subgoals[display,indent=0]}
   17.73    Simplification solves the first two goals, leaving us with two
   17.74    statements about the \<open>mod\<close> operation to prove:
   17.75 @@ -428,7 +426,7 @@
   17.76    In proofs like this, the simultaneous induction is really essential:
   17.77    Even if we are just interested in one of the results, the other
   17.78    one is necessary to strengthen the induction hypothesis. If we leave
   17.79 -  out the statement about @{const odd} and just write @{term True} instead,
   17.80 +  out the statement about \<^const>\<open>odd\<close> and just write \<^term>\<open>True\<close> instead,
   17.81    the same proof fails:
   17.82  \<close>
   17.83  
   17.84 @@ -471,7 +469,7 @@
   17.85    @{thm[display] list_to_option.elims}
   17.86  
   17.87    \noindent
   17.88 -  This lets us eliminate an assumption of the form @{prop "list_to_option xs = y"} and replace it
   17.89 +  This lets us eliminate an assumption of the form \<^prop>\<open>list_to_option xs = y\<close> and replace it
   17.90    with the two cases, e.g.:
   17.91  \<close>
   17.92  
   17.93 @@ -488,7 +486,7 @@
   17.94  text \<open>
   17.95    Sometimes it is convenient to derive specialized versions of the \<open>elim\<close> rules above and
   17.96    keep them around as facts explicitly. For example, it is natural to show that if 
   17.97 -  @{prop "list_to_option xs = Some y"}, then @{term xs} must be a singleton. The command 
   17.98 +  \<^prop>\<open>list_to_option xs = Some y\<close>, then \<^term>\<open>xs\<close> must be a singleton. The command 
   17.99    \cmd{fun\_cases} derives such facts automatically, by instantiating and simplifying the general 
  17.100    elimination rules given some pattern:
  17.101  \<close>
  17.102 @@ -511,15 +509,15 @@
  17.103    Up to now, we used pattern matching only on datatypes, and the
  17.104    patterns were always disjoint and complete, and if they weren't,
  17.105    they were made disjoint automatically like in the definition of
  17.106 -  @{const "sep"} in \S\ref{patmatch}.
  17.107 +  \<^const>\<open>sep\<close> in \S\ref{patmatch}.
  17.108  
  17.109    This automatic splitting can significantly increase the number of
  17.110    equations involved, and this is not always desirable. The following
  17.111    example shows the problem:
  17.112    
  17.113    Suppose we are modeling incomplete knowledge about the world by a
  17.114 -  three-valued datatype, which has values @{term "T"}, @{term "F"}
  17.115 -  and @{term "X"} for true, false and uncertain propositions, respectively. 
  17.116 +  three-valued datatype, which has values \<^term>\<open>T\<close>, \<^term>\<open>F\<close>
  17.117 +  and \<^term>\<open>X\<close> for true, false and uncertain propositions, respectively. 
  17.118  \<close>
  17.119  
  17.120  datatype P3 = T | F | X
  17.121 @@ -538,7 +536,7 @@
  17.122  text \<open>
  17.123    This definition is useful, because the equations can directly be used
  17.124    as simplification rules. But the patterns overlap: For example,
  17.125 -  the expression @{term "And T T"} is matched by both the first and
  17.126 +  the expression \<^term>\<open>And T T\<close> is matched by both the first and
  17.127    the second equation. By default, Isabelle makes the patterns disjoint by
  17.128    splitting them up, producing instances:
  17.129  \<close>
  17.130 @@ -553,14 +551,14 @@
  17.131  
  17.132    \begin{enumerate}
  17.133    \item If the datatype has many constructors, there can be an
  17.134 -  explosion of equations. For @{const "And"}, we get seven instead of
  17.135 +  explosion of equations. For \<^const>\<open>And\<close>, we get seven instead of
  17.136    five equations, which can be tolerated, but this is just a small
  17.137    example.
  17.138  
  17.139    \item Since splitting makes the equations \qt{less general}, they
  17.140 -  do not always match in rewriting. While the term @{term "And x F"}
  17.141 -  can be simplified to @{term "F"} with the original equations, a
  17.142 -  (manual) case split on @{term "x"} is now necessary.
  17.143 +  do not always match in rewriting. While the term \<^term>\<open>And x F\<close>
  17.144 +  can be simplified to \<^term>\<open>F\<close> with the original equations, a
  17.145 +  (manual) case split on \<^term>\<open>x\<close> is now necessary.
  17.146  
  17.147    \item The splitting also concerns the induction rule @{thm [source]
  17.148    "And.induct"}. Instead of five premises it now has seven, which
  17.149 @@ -573,8 +571,8 @@
  17.150    If we do not want the automatic splitting, we can switch it off by
  17.151    leaving out the \cmd{sequential} option. However, we will have to
  17.152    prove that our pattern matching is consistent\footnote{This prevents
  17.153 -  us from defining something like @{term "f x = True"} and @{term "f x
  17.154 -  = False"} simultaneously.}:
  17.155 +  us from defining something like \<^term>\<open>f x = True\<close> and \<^term>\<open>f x
  17.156 +  = False\<close> simultaneously.}:
  17.157  \<close>
  17.158  
  17.159  function And2 :: "P3 \<Rightarrow> P3 \<Rightarrow> P3"
  17.160 @@ -592,11 +590,11 @@
  17.161    @{subgoals[display,indent=0]}\vspace{-1.2em}\hspace{3cm}\vdots\vspace{1.2em}
  17.162  
  17.163    The first subgoal expresses the completeness of the patterns. It has
  17.164 -  the form of an elimination rule and states that every @{term x} of
  17.165 +  the form of an elimination rule and states that every \<^term>\<open>x\<close> of
  17.166    the function's input type must match at least one of the patterns\footnote{Completeness could
  17.167    be equivalently stated as a disjunction of existential statements: 
  17.168 -@{term "(\<exists>p. x = (T, p)) \<or> (\<exists>p. x = (p, T)) \<or> (\<exists>p. x = (p, F)) \<or>
  17.169 -  (\<exists>p. x = (F, p)) \<or> (x = (X, X))"}, and you can use the method \<open>atomize_elim\<close> to get that form instead.}. If the patterns just involve
  17.170 +\<^term>\<open>(\<exists>p. x = (T, p)) \<or> (\<exists>p. x = (p, T)) \<or> (\<exists>p. x = (p, F)) \<or>
  17.171 +  (\<exists>p. x = (F, p)) \<or> (x = (X, X))\<close>, and you can use the method \<open>atomize_elim\<close> to get that form instead.}. If the patterns just involve
  17.172    datatypes, we can solve it with the \<open>pat_completeness\<close>
  17.173    method:
  17.174  \<close>
  17.175 @@ -640,8 +638,8 @@
  17.176    This kind of matching is again justified by the proof of pattern
  17.177    completeness and compatibility. 
  17.178    The proof obligation for pattern completeness states that every natural number is
  17.179 -  either @{term "0::nat"}, @{term "1::nat"} or @{term "n +
  17.180 -  (2::nat)"}:
  17.181 +  either \<^term>\<open>0::nat\<close>, \<^term>\<open>1::nat\<close> or \<^term>\<open>n +
  17.182 +  (2::nat)\<close>:
  17.183  
  17.184    @{subgoals[display,indent=0,goals_limit=1]}
  17.185  
  17.186 @@ -746,8 +744,8 @@
  17.187  section \<open>Partiality\<close>
  17.188  
  17.189  text \<open>
  17.190 -  In HOL, all functions are total. A function @{term "f"} applied to
  17.191 -  @{term "x"} always has the value @{term "f x"}, and there is no notion
  17.192 +  In HOL, all functions are total. A function \<^term>\<open>f\<close> applied to
  17.193 +  \<^term>\<open>x\<close> always has the value \<^term>\<open>f x\<close>, and there is no notion
  17.194    of undefinedness. 
  17.195    This is why we have to do termination
  17.196    proofs when defining functions: The proof justifies that the
  17.197 @@ -772,8 +770,8 @@
  17.198  subsection \<open>Domain predicates\<close>
  17.199  
  17.200  text \<open>
  17.201 -  The trick is that Isabelle has not only defined the function @{const findzero}, but also
  17.202 -  a predicate @{term "findzero_dom"} that characterizes the values where the function
  17.203 +  The trick is that Isabelle has not only defined the function \<^const>\<open>findzero\<close>, but also
  17.204 +  a predicate \<^term>\<open>findzero_dom\<close> that characterizes the values where the function
  17.205    terminates: the \emph{domain} of the function. If we treat a
  17.206    partial function just as a total function with an additional domain
  17.207    predicate, we can derive simplification and
  17.208 @@ -793,14 +791,14 @@
  17.209  text \<open>
  17.210    Remember that all we
  17.211    are doing here is use some tricks to make a total function appear
  17.212 -  as if it was partial. We can still write the term @{term "findzero
  17.213 -  (\<lambda>x. 1) 0"} and like any other term of type @{typ nat} it is equal
  17.214 +  as if it was partial. We can still write the term \<^term>\<open>findzero
  17.215 +  (\<lambda>x. 1) 0\<close> and like any other term of type \<^typ>\<open>nat\<close> it is equal
  17.216    to some natural number, although we might not be able to find out
  17.217    which one. The function is \emph{underdefined}.
  17.218  
  17.219    But it is defined enough to prove something interesting about it. We
  17.220 -  can prove that if @{term "findzero f n"}
  17.221 -  terminates, it indeed returns a zero of @{term f}:
  17.222 +  can prove that if \<^term>\<open>findzero f n\<close>
  17.223 +  terminates, it indeed returns a zero of \<^term>\<open>f\<close>:
  17.224  \<close>
  17.225  
  17.226  lemma findzero_zero: "findzero_dom (f, n) \<Longrightarrow> f (findzero f n) = 0"
  17.227 @@ -815,9 +813,8 @@
  17.228    @{subgoals[display,indent=0]}
  17.229  
  17.230    \noindent The hypothesis in our lemma was used to satisfy the first premise in
  17.231 -  the induction rule. However, we also get @{term
  17.232 -  "findzero_dom (f, n)"} as a local assumption in the induction step. This
  17.233 -  allows unfolding @{term "findzero f n"} using the \<open>psimps\<close>
  17.234 +  the induction rule. However, we also get \<^term>\<open>findzero_dom (f, n)\<close> as a local assumption in the induction step. This
  17.235 +  allows unfolding \<^term>\<open>findzero f n\<close> using the \<open>psimps\<close>
  17.236    rule, and the rest is trivial.
  17.237  \<close>
  17.238  apply (simp add: findzero.psimps)
  17.239 @@ -829,7 +826,7 @@
  17.240    complicated proof written in Isar. It is verbose enough to show how
  17.241    partiality comes into play: From the partial induction, we get an
  17.242    additional domain condition hypothesis. Observe how this condition
  17.243 -  is applied when calls to @{term findzero} are unfolded.
  17.244 +  is applied when calls to \<^term>\<open>findzero\<close> are unfolded.
  17.245  \<close>
  17.246  
  17.247  text_raw \<open>
  17.248 @@ -876,7 +873,7 @@
  17.249    Now that we have proved some interesting properties about our
  17.250    function, we should turn to the domain predicate and see if it is
  17.251    actually true for some values. Otherwise we would have just proved
  17.252 -  lemmas with @{term False} as a premise.
  17.253 +  lemmas with \<^term>\<open>False\<close> as a premise.
  17.254  
  17.255    Essentially, we need some introduction rules for \<open>findzero_dom\<close>. The function package can prove such domain
  17.256    introduction rules automatically. But since they are not used very
  17.257 @@ -912,7 +909,7 @@
  17.258  
  17.259    Figure \ref{findzero_term} gives a detailed Isar proof of the fact
  17.260    that \<open>findzero\<close> terminates if there is a zero which is greater
  17.261 -  or equal to @{term n}. First we derive two useful rules which will
  17.262 +  or equal to \<^term>\<open>n\<close>. First we derive two useful rules which will
  17.263    solve the base case and the step case of the induction. The
  17.264    induction is then straightforward, except for the unusual induction
  17.265    principle.
  17.266 @@ -983,28 +980,27 @@
  17.267  
  17.268    @{abbrev[display] findzero_dom}
  17.269  
  17.270 -  The domain predicate is the \emph{accessible part} of a relation @{const
  17.271 -  findzero_rel}, which was also created internally by the function
  17.272 -  package. @{const findzero_rel} is just a normal
  17.273 +  The domain predicate is the \emph{accessible part} of a relation \<^const>\<open>findzero_rel\<close>, which was also created internally by the function
  17.274 +  package. \<^const>\<open>findzero_rel\<close> is just a normal
  17.275    inductive predicate, so we can inspect its definition by
  17.276    looking at the introduction rules @{thm [source] findzero_rel.intros}.
  17.277    In our case there is just a single rule:
  17.278  
  17.279    @{thm[display] findzero_rel.intros}
  17.280  
  17.281 -  The predicate @{const findzero_rel}
  17.282 +  The predicate \<^const>\<open>findzero_rel\<close>
  17.283    describes the \emph{recursion relation} of the function
  17.284    definition. The recursion relation is a binary relation on
  17.285    the arguments of the function that relates each argument to its
  17.286    recursive calls. In general, there is one introduction rule for each
  17.287    recursive call.
  17.288  
  17.289 -  The predicate @{term "Wellfounded.accp findzero_rel"} is the accessible part of
  17.290 +  The predicate \<^term>\<open>Wellfounded.accp findzero_rel\<close> is the accessible part of
  17.291    that relation. An argument belongs to the accessible part, if it can
  17.292    be reached in a finite number of steps (cf.~its definition in \<open>Wellfounded.thy\<close>).
  17.293  
  17.294    Since the domain predicate is just an abbreviation, you can use
  17.295 -  lemmas for @{const Wellfounded.accp} and @{const findzero_rel} directly. Some
  17.296 +  lemmas for \<^const>\<open>Wellfounded.accp\<close> and \<^const>\<open>findzero_rel\<close> directly. Some
  17.297    lemmas which are occasionally useful are @{thm [source] accpI}, @{thm [source]
  17.298    accp_downward}, and of course the introduction and elimination rules
  17.299    for the recursion relation @{thm [source] "findzero_rel.intros"} and @{thm
  17.300 @@ -1041,7 +1037,7 @@
  17.301  
  17.302    @{subgoals[display]}
  17.303  
  17.304 -  Of course this statement is true, since we know that @{const nz} is
  17.305 +  Of course this statement is true, since we know that \<^const>\<open>nz\<close> is
  17.306    the zero function. And in fact we have no problem proving this
  17.307    property by induction.
  17.308  \<close>
  17.309 @@ -1051,7 +1047,7 @@
  17.310  
  17.311  text \<open>
  17.312    We formulate this as a partial correctness lemma with the condition
  17.313 -  @{term "nz_dom n"}. This allows us to prove it with the \<open>pinduct\<close> rule before we have proved termination. With this lemma,
  17.314 +  \<^term>\<open>nz_dom n\<close>. This allows us to prove it with the \<open>pinduct\<close> rule before we have proved termination. With this lemma,
  17.315    the termination proof works as expected:
  17.316  \<close>
  17.317  
  17.318 @@ -1111,8 +1107,7 @@
  17.319  
  17.320  text \<open>
  17.321    Higher-order recursion occurs when recursive calls
  17.322 -  are passed as arguments to higher-order combinators such as @{const
  17.323 -  map}, @{term filter} etc.
  17.324 +  are passed as arguments to higher-order combinators such as \<^const>\<open>map\<close>, \<^term>\<open>filter\<close> etc.
  17.325    As an example, imagine a datatype of n-ary trees:
  17.326  \<close>
  17.327  
  17.328 @@ -1122,7 +1117,7 @@
  17.329  
  17.330  
  17.331  text \<open>\noindent We can define a function which swaps the left and right subtrees recursively, using the 
  17.332 -  list functions @{const rev} and @{const map}:\<close>
  17.333 +  list functions \<^const>\<open>rev\<close> and \<^const>\<open>map\<close>:\<close>
  17.334  
  17.335  fun mirror :: "'a tree \<Rightarrow> 'a tree"
  17.336  where
  17.337 @@ -1139,39 +1134,37 @@
  17.338    As usual, we have to give a wellfounded relation, such that the
  17.339    arguments of the recursive calls get smaller. But what exactly are
  17.340    the arguments of the recursive calls when mirror is given as an
  17.341 -  argument to @{const map}? Isabelle gives us the
  17.342 +  argument to \<^const>\<open>map\<close>? Isabelle gives us the
  17.343    subgoals
  17.344  
  17.345    @{subgoals[display,indent=0]} 
  17.346  
  17.347 -  So the system seems to know that @{const map} only
  17.348 -  applies the recursive call @{term "mirror"} to elements
  17.349 -  of @{term "l"}, which is essential for the termination proof.
  17.350 +  So the system seems to know that \<^const>\<open>map\<close> only
  17.351 +  applies the recursive call \<^term>\<open>mirror\<close> to elements
  17.352 +  of \<^term>\<open>l\<close>, which is essential for the termination proof.
  17.353  
  17.354 -  This knowledge about @{const map} is encoded in so-called congruence rules,
  17.355 +  This knowledge about \<^const>\<open>map\<close> is encoded in so-called congruence rules,
  17.356    which are special theorems known to the \cmd{function} command. The
  17.357 -  rule for @{const map} is
  17.358 +  rule for \<^const>\<open>map\<close> is
  17.359  
  17.360    @{thm[display] map_cong}
  17.361  
  17.362 -  You can read this in the following way: Two applications of @{const
  17.363 -  map} are equal, if the list arguments are equal and the functions
  17.364 +  You can read this in the following way: Two applications of \<^const>\<open>map\<close> are equal, if the list arguments are equal and the functions
  17.365    coincide on the elements of the list. This means that for the value 
  17.366 -  @{term "map f l"} we only have to know how @{term f} behaves on
  17.367 -  the elements of @{term l}.
  17.368 +  \<^term>\<open>map f l\<close> we only have to know how \<^term>\<open>f\<close> behaves on
  17.369 +  the elements of \<^term>\<open>l\<close>.
  17.370  
  17.371    Usually, one such congruence rule is
  17.372    needed for each higher-order construct that is used when defining
  17.373 -  new functions. In fact, even basic functions like @{const
  17.374 -  If} and @{const Let} are handled by this mechanism. The congruence
  17.375 -  rule for @{const If} states that the \<open>then\<close> branch is only
  17.376 +  new functions. In fact, even basic functions like \<^const>\<open>If\<close> and \<^const>\<open>Let\<close> are handled by this mechanism. The congruence
  17.377 +  rule for \<^const>\<open>If\<close> states that the \<open>then\<close> branch is only
  17.378    relevant if the condition is true, and the \<open>else\<close> branch only if it
  17.379    is false:
  17.380  
  17.381    @{thm[display] if_cong}
  17.382    
  17.383    Congruence rules can be added to the
  17.384 -  function package by giving them the @{term fundef_cong} attribute.
  17.385 +  function package by giving them the \<^term>\<open>fundef_cong\<close> attribute.
  17.386  
  17.387    The constructs that are predefined in Isabelle, usually
  17.388    come with the respective congruence rules.
    18.1 --- a/src/Doc/How_to_Prove_it/How_to_Prove_it.thy	Sat Jan 05 17:00:43 2019 +0100
    18.2 +++ b/src/Doc/How_to_Prove_it/How_to_Prove_it.thy	Sat Jan 05 17:24:33 2019 +0100
    18.3 @@ -4,7 +4,7 @@
    18.4  begin
    18.5  (*>*)
    18.6  text\<open>
    18.7 -\chapter{@{theory Main}}
    18.8 +\chapter{\<^theory>\<open>Main\<close>}
    18.9  
   18.10  \section{Natural numbers}
   18.11  
   18.12 @@ -19,7 +19,7 @@
   18.13  \begin{quote}
   18.14  (\<open>induction n rule: less_induct\<close>)
   18.15  \end{quote}
   18.16 -In fact, it is not restricted to @{typ nat} but works for any wellfounded
   18.17 +In fact, it is not restricted to \<^typ>\<open>nat\<close> but works for any wellfounded
   18.18  order \<open><\<close>.
   18.19  
   18.20  There are many more special induction rules. You can find all of them
   18.21 @@ -29,7 +29,7 @@
   18.22  \end{quote}
   18.23  
   18.24  
   18.25 -\paragraph{How to convert numerals into @{const Suc} terms}~\\
   18.26 +\paragraph{How to convert numerals into \<^const>\<open>Suc\<close> terms}~\\
   18.27  Solution: simplify with the lemma @{thm[source] numeral_eq_Suc}.
   18.28  
   18.29  \noindent
   18.30 @@ -40,7 +40,7 @@
   18.31  by (simp add: numeral_eq_Suc)
   18.32  
   18.33  text\<open>This is a typical situation: function ``\<open>^\<close>'' is defined
   18.34 -by pattern matching on @{const Suc} but is applied to a numeral.
   18.35 +by pattern matching on \<^const>\<open>Suc\<close> but is applied to a numeral.
   18.36  
   18.37  Note: simplification with @{thm[source] numeral_eq_Suc} will convert all numerals.
   18.38  One can be more specific with the lemmas @{thm [source] numeral_2_eq_2}
   18.39 @@ -73,10 +73,10 @@
   18.40  %Tobias Nipkow
   18.41  \section{Algebraic simplification}
   18.42  
   18.43 -On the numeric types @{typ nat}, @{typ int} and @{typ real},
   18.44 +On the numeric types \<^typ>\<open>nat\<close>, \<^typ>\<open>int\<close> and \<^typ>\<open>real\<close>,
   18.45  proof method \<open>simp\<close> and friends can deal with a limited amount of linear
   18.46  arithmetic (no multiplication except by numerals) and method \<open>arith\<close> can
   18.47 -handle full linear arithmetic (on @{typ nat}, @{typ int} including quantifiers).
   18.48 +handle full linear arithmetic (on \<^typ>\<open>nat\<close>, \<^typ>\<open>int\<close> including quantifiers).
   18.49  But what to do when proper multiplication is involved?
   18.50  At this point it can be helpful to simplify with the lemma list
   18.51  @{thm [source] algebra_simps}. Examples:
   18.52 @@ -95,10 +95,10 @@
   18.53  terms are rewritten into a normal form by multiplying out,
   18.54  rearranging sums and products into some canonical order.
   18.55  In the above lemma the normal form will be something like
   18.56 -@{term"x*y + y*y - x*z - y*z"}.
   18.57 -This works for concrete types like @{typ int} as well as for classes like
   18.58 -@{class comm_ring} (commutative rings). For some classes (e.g.\ @{class ring}
   18.59 -and @{class comm_ring}) this yields a decision procedure for equality.
   18.60 +\<^term>\<open>x*y + y*y - x*z - y*z\<close>.
   18.61 +This works for concrete types like \<^typ>\<open>int\<close> as well as for classes like
   18.62 +\<^class>\<open>comm_ring\<close> (commutative rings). For some classes (e.g.\ \<^class>\<open>ring\<close>
   18.63 +and \<^class>\<open>comm_ring\<close>) this yields a decision procedure for equality.
   18.64  
   18.65  Additional function and predicate symbols are not a problem either:
   18.66  \<close>
   18.67 @@ -107,8 +107,8 @@
   18.68  by(simp add: algebra_simps)
   18.69  
   18.70  text\<open>Here @{thm[source]algebra_simps} merely has the effect of rewriting
   18.71 -@{term"y*x"} to @{term"x*y"} (or the other way around). This yields
   18.72 -a problem of the form @{prop"2*t - t < t + (1::int)"} and we are back in the
   18.73 +\<^term>\<open>y*x\<close> to \<^term>\<open>x*y\<close> (or the other way around). This yields
   18.74 +a problem of the form \<^prop>\<open>2*t - t < t + (1::int)\<close> and we are back in the
   18.75  realm of linear arithmetic.
   18.76  
   18.77  Because @{thm[source]algebra_simps} multiplies out, terms can explode.
    19.1 --- a/src/Doc/Implementation/Eq.thy	Sat Jan 05 17:00:43 2019 +0100
    19.2 +++ b/src/Doc/Implementation/Eq.thy	Sat Jan 05 17:24:33 2019 +0100
    19.3 @@ -43,12 +43,12 @@
    19.4    same reasoning schemes as theorems that can be composed like object-level
    19.5    rules as explained in \secref{sec:obj-rules}.
    19.6  
    19.7 -  For example, @{ML Thm.symmetric} as Pure inference is an ML function that
    19.8 +  For example, \<^ML>\<open>Thm.symmetric\<close> as Pure inference is an ML function that
    19.9    maps a theorem \<open>th\<close> stating \<open>t \<equiv> u\<close> to one stating \<open>u \<equiv> t\<close>. In contrast,
   19.10    @{thm [source] Pure.symmetric} as Pure theorem expresses the same reasoning
   19.11    in declarative form. If used like \<open>th [THEN Pure.symmetric]\<close> in Isar source
   19.12    notation, it achieves a similar effect as the ML inference function,
   19.13 -  although the rule attribute @{attribute THEN} or ML operator @{ML "op RS"}
   19.14 +  although the rule attribute @{attribute THEN} or ML operator \<^ML>\<open>op RS\<close>
   19.15    involve the full machinery of higher-order unification (modulo
   19.16    \<open>\<beta>\<eta>\<close>-conversion) and lifting of \<open>\<And>/\<Longrightarrow>\<close> contexts.
   19.17  \<close>
   19.18 @@ -99,21 +99,21 @@
   19.19    @{index_ML fold_goals_tac: "Proof.context -> thm list -> tactic"} \\
   19.20    \end{mldecls}
   19.21  
   19.22 -  \<^descr> @{ML rewrite_rule}~\<open>ctxt rules thm\<close> rewrites the whole theorem by the
   19.23 +  \<^descr> \<^ML>\<open>rewrite_rule\<close>~\<open>ctxt rules thm\<close> rewrites the whole theorem by the
   19.24    given rules.
   19.25  
   19.26 -  \<^descr> @{ML rewrite_goals_rule}~\<open>ctxt rules thm\<close> rewrites the outer premises of
   19.27 +  \<^descr> \<^ML>\<open>rewrite_goals_rule\<close>~\<open>ctxt rules thm\<close> rewrites the outer premises of
   19.28    the given theorem. Interpreting the same as a goal state
   19.29    (\secref{sec:tactical-goals}) it means to rewrite all subgoals (in the same
   19.30 -  manner as @{ML rewrite_goals_tac}).
   19.31 +  manner as \<^ML>\<open>rewrite_goals_tac\<close>).
   19.32  
   19.33 -  \<^descr> @{ML rewrite_goal_tac}~\<open>ctxt rules i\<close> rewrites subgoal \<open>i\<close> by the given
   19.34 +  \<^descr> \<^ML>\<open>rewrite_goal_tac\<close>~\<open>ctxt rules i\<close> rewrites subgoal \<open>i\<close> by the given
   19.35    rewrite rules.
   19.36  
   19.37 -  \<^descr> @{ML rewrite_goals_tac}~\<open>ctxt rules\<close> rewrites all subgoals by the given
   19.38 +  \<^descr> \<^ML>\<open>rewrite_goals_tac\<close>~\<open>ctxt rules\<close> rewrites all subgoals by the given
   19.39    rewrite rules.
   19.40  
   19.41 -  \<^descr> @{ML fold_goals_tac}~\<open>ctxt rules\<close> essentially uses @{ML rewrite_goals_tac}
   19.42 +  \<^descr> \<^ML>\<open>fold_goals_tac\<close>~\<open>ctxt rules\<close> essentially uses \<^ML>\<open>rewrite_goals_tac\<close>
   19.43    with the symmetric form of each member of \<open>rules\<close>, re-ordered to fold longer
   19.44    expression first. This supports to idea to fold primitive definitions that
   19.45    appear in expended form in the proof state.
    20.1 --- a/src/Doc/Implementation/Integration.thy	Sat Jan 05 17:00:43 2019 +0100
    20.2 +++ b/src/Doc/Implementation/Integration.thy	Sat Jan 05 17:24:33 2019 +0100
    20.3 @@ -44,20 +44,19 @@
    20.4    @{index_ML Toplevel.proof_of: "Toplevel.state -> Proof.state"} \\
    20.5    \end{mldecls}
    20.6  
    20.7 -  \<^descr> Type @{ML_type Toplevel.state} represents Isar toplevel states, which are
    20.8 +  \<^descr> Type \<^ML_type>\<open>Toplevel.state\<close> represents Isar toplevel states, which are
    20.9    normally manipulated through the concept of toplevel transitions only
   20.10    (\secref{sec:toplevel-transition}).
   20.11  
   20.12 -  \<^descr> @{ML Toplevel.UNDEF} is raised for undefined toplevel operations. Many
   20.13 -  operations work only partially for certain cases, since @{ML_type
   20.14 -  Toplevel.state} is a sum type.
   20.15 +  \<^descr> \<^ML>\<open>Toplevel.UNDEF\<close> is raised for undefined toplevel operations. Many
   20.16 +  operations work only partially for certain cases, since \<^ML_type>\<open>Toplevel.state\<close> is a sum type.
   20.17 +
   20.18 +  \<^descr> \<^ML>\<open>Toplevel.is_toplevel\<close>~\<open>state\<close> checks for an empty toplevel state.
   20.19  
   20.20 -  \<^descr> @{ML Toplevel.is_toplevel}~\<open>state\<close> checks for an empty toplevel state.
   20.21 +  \<^descr> \<^ML>\<open>Toplevel.theory_of\<close>~\<open>state\<close> selects the background theory of \<open>state\<close>,
   20.22 +  it raises \<^ML>\<open>Toplevel.UNDEF\<close> for an empty toplevel state.
   20.23  
   20.24 -  \<^descr> @{ML Toplevel.theory_of}~\<open>state\<close> selects the background theory of \<open>state\<close>,
   20.25 -  it raises @{ML Toplevel.UNDEF} for an empty toplevel state.
   20.26 -
   20.27 -  \<^descr> @{ML Toplevel.proof_of}~\<open>state\<close> selects the Isar proof state if available,
   20.28 +  \<^descr> \<^ML>\<open>Toplevel.proof_of\<close>~\<open>state\<close> selects the Isar proof state if available,
   20.29    otherwise it raises an error.
   20.30  \<close>
   20.31  
   20.32 @@ -110,23 +109,23 @@
   20.33    Toplevel.transition -> Toplevel.transition"} \\
   20.34    \end{mldecls}
   20.35  
   20.36 -  \<^descr> @{ML Toplevel.keep}~\<open>tr\<close> adjoins a diagnostic function.
   20.37 +  \<^descr> \<^ML>\<open>Toplevel.keep\<close>~\<open>tr\<close> adjoins a diagnostic function.
   20.38  
   20.39 -  \<^descr> @{ML Toplevel.theory}~\<open>tr\<close> adjoins a theory transformer.
   20.40 +  \<^descr> \<^ML>\<open>Toplevel.theory\<close>~\<open>tr\<close> adjoins a theory transformer.
   20.41  
   20.42 -  \<^descr> @{ML Toplevel.theory_to_proof}~\<open>tr\<close> adjoins a global goal function, which
   20.43 +  \<^descr> \<^ML>\<open>Toplevel.theory_to_proof\<close>~\<open>tr\<close> adjoins a global goal function, which
   20.44    turns a theory into a proof state. The theory may be changed before entering
   20.45    the proof; the generic Isar goal setup includes an \<^verbatim>\<open>after_qed\<close> argument
   20.46    that specifies how to apply the proven result to the enclosing context, when
   20.47    the proof is finished.
   20.48  
   20.49 -  \<^descr> @{ML Toplevel.proof}~\<open>tr\<close> adjoins a deterministic proof command, with a
   20.50 +  \<^descr> \<^ML>\<open>Toplevel.proof\<close>~\<open>tr\<close> adjoins a deterministic proof command, with a
   20.51    singleton result.
   20.52  
   20.53 -  \<^descr> @{ML Toplevel.proofs}~\<open>tr\<close> adjoins a general proof command, with zero or
   20.54 +  \<^descr> \<^ML>\<open>Toplevel.proofs\<close>~\<open>tr\<close> adjoins a general proof command, with zero or
   20.55    more result states (represented as a lazy list).
   20.56  
   20.57 -  \<^descr> @{ML Toplevel.end_proof}~\<open>tr\<close> adjoins a concluding proof command, that
   20.58 +  \<^descr> \<^ML>\<open>Toplevel.end_proof\<close>~\<open>tr\<close> adjoins a concluding proof command, that
   20.59    returns the resulting theory, after applying the resulting facts to the
   20.60    target context.
   20.61  \<close>
   20.62 @@ -157,17 +156,17 @@
   20.63    @{index_ML Thy_Info.register_thy: "theory -> unit"} \\
   20.64    \end{mldecls}
   20.65  
   20.66 -  \<^descr> @{ML use_thy}~\<open>A\<close> ensures that theory \<open>A\<close> is fully up-to-date wrt.\ the
   20.67 +  \<^descr> \<^ML>\<open>use_thy\<close>~\<open>A\<close> ensures that theory \<open>A\<close> is fully up-to-date wrt.\ the
   20.68    external file store; outdated ancestors are reloaded on demand.
   20.69  
   20.70 -  \<^descr> @{ML Thy_Info.get_theory}~\<open>A\<close> retrieves the theory value presently
   20.71 +  \<^descr> \<^ML>\<open>Thy_Info.get_theory\<close>~\<open>A\<close> retrieves the theory value presently
   20.72    associated with name \<open>A\<close>. Note that the result might be outdated wrt.\ the
   20.73    file-system content.
   20.74  
   20.75 -  \<^descr> @{ML Thy_Info.remove_thy}~\<open>A\<close> deletes theory \<open>A\<close> and all descendants from
   20.76 +  \<^descr> \<^ML>\<open>Thy_Info.remove_thy\<close>~\<open>A\<close> deletes theory \<open>A\<close> and all descendants from
   20.77    the theory database.
   20.78  
   20.79 -  \<^descr> @{ML Thy_Info.register_thy}~\<open>text thy\<close> registers an existing theory value
   20.80 +  \<^descr> \<^ML>\<open>Thy_Info.register_thy\<close>~\<open>text thy\<close> registers an existing theory value
   20.81    with the theory loader database and updates source version information
   20.82    according to the file store.
   20.83  \<close>
    21.1 --- a/src/Doc/Implementation/Isar.thy	Sat Jan 05 17:00:43 2019 +0100
    21.2 +++ b/src/Doc/Implementation/Isar.thy	Sat Jan 05 17:24:33 2019 +0100
    21.3 @@ -74,7 +74,7 @@
    21.4    (term * term list) list list -> Proof.context -> Proof.state"} \\
    21.5    \end{mldecls}
    21.6  
    21.7 -  \<^descr> Type @{ML_type Proof.state} represents Isar proof states. This is a
    21.8 +  \<^descr> Type \<^ML_type>\<open>Proof.state\<close> represents Isar proof states. This is a
    21.9    block-structured configuration with proof context, linguistic mode, and
   21.10    optional goal. The latter consists of goal context, goal facts
   21.11    (``\<open>using\<close>''), and tactical goal state (see \secref{sec:tactical-goals}).
   21.12 @@ -83,8 +83,7 @@
   21.13    some parts of the tactical goal --- how exactly is defined by the proof
   21.14    method that is applied in that situation.
   21.15  
   21.16 -  \<^descr> @{ML Proof.assert_forward}, @{ML Proof.assert_chain}, @{ML
   21.17 -  Proof.assert_backward} are partial identity functions that fail unless a
   21.18 +  \<^descr> \<^ML>\<open>Proof.assert_forward\<close>, \<^ML>\<open>Proof.assert_chain\<close>, \<^ML>\<open>Proof.assert_backward\<close> are partial identity functions that fail unless a
   21.19    certain linguistic mode is active, namely ``\<open>proof(state)\<close>'',
   21.20    ``\<open>proof(chain)\<close>'', ``\<open>proof(prove)\<close>'', respectively (using the terminology
   21.21    of @{cite "isabelle-isar-ref"}).
   21.22 @@ -92,22 +91,21 @@
   21.23    It is advisable study the implementations of existing proof commands for
   21.24    suitable modes to be asserted.
   21.25  
   21.26 -  \<^descr> @{ML Proof.simple_goal}~\<open>state\<close> returns the structured Isar goal (if
   21.27 +  \<^descr> \<^ML>\<open>Proof.simple_goal\<close>~\<open>state\<close> returns the structured Isar goal (if
   21.28    available) in the form seen by ``simple'' methods (like @{method simp} or
   21.29    @{method blast}). The Isar goal facts are already inserted as premises into
   21.30 -  the subgoals, which are presented individually as in @{ML Proof.goal}.
   21.31 +  the subgoals, which are presented individually as in \<^ML>\<open>Proof.goal\<close>.
   21.32  
   21.33 -  \<^descr> @{ML Proof.goal}~\<open>state\<close> returns the structured Isar goal (if available)
   21.34 +  \<^descr> \<^ML>\<open>Proof.goal\<close>~\<open>state\<close> returns the structured Isar goal (if available)
   21.35    in the form seen by regular methods (like @{method rule}). The auxiliary
   21.36    internal encoding of Pure conjunctions is split into individual subgoals as
   21.37    usual.
   21.38  
   21.39 -  \<^descr> @{ML Proof.raw_goal}~\<open>state\<close> returns the structured Isar goal (if
   21.40 +  \<^descr> \<^ML>\<open>Proof.raw_goal\<close>~\<open>state\<close> returns the structured Isar goal (if
   21.41    available) in the raw internal form seen by ``raw'' methods (like @{method
   21.42 -  induct}). This form is rarely appropriate for diagnostic tools; @{ML
   21.43 -  Proof.simple_goal} or @{ML Proof.goal} should be used in most situations.
   21.44 +  induct}). This form is rarely appropriate for diagnostic tools; \<^ML>\<open>Proof.simple_goal\<close> or \<^ML>\<open>Proof.goal\<close> should be used in most situations.
   21.45  
   21.46 -  \<^descr> @{ML Proof.theorem}~\<open>before_qed after_qed statement ctxt\<close> initializes a
   21.47 +  \<^descr> \<^ML>\<open>Proof.theorem\<close>~\<open>before_qed after_qed statement ctxt\<close> initializes a
   21.48    toplevel Isar proof state within a given context.
   21.49  
   21.50    The optional \<open>before_qed\<close> method is applied at the end of the proof, just
   21.51 @@ -115,9 +113,8 @@
   21.52  
   21.53    The \<open>after_qed\<close> continuation receives the extracted result in order to apply
   21.54    it to the final context in a suitable way (e.g.\ storing named facts). Note
   21.55 -  that at this generic level the target context is specified as @{ML_type
   21.56 -  Proof.context}, but the usual wrapping of toplevel proofs into command
   21.57 -  transactions will provide a @{ML_type local_theory} here
   21.58 +  that at this generic level the target context is specified as \<^ML_type>\<open>Proof.context\<close>, but the usual wrapping of toplevel proofs into command
   21.59 +  transactions will provide a \<^ML_type>\<open>local_theory\<close> here
   21.60    (\chref{ch:local-theory}). This affects the way how results are stored.
   21.61  
   21.62    The \<open>statement\<close> is given as a nested list of terms, each associated with
   21.63 @@ -148,7 +145,7 @@
   21.64    have A and B and C
   21.65      ML_val
   21.66       \<open>val n = Thm.nprems_of (#goal @{Isar.goal});
   21.67 -      @{assert} (n = 3);\<close>
   21.68 +      \<^assert> (n = 3);\<close>
   21.69      sorry
   21.70  end
   21.71  
   21.72 @@ -285,30 +282,28 @@
   21.73    string -> theory -> theory"} \\
   21.74    \end{mldecls}
   21.75  
   21.76 -  \<^descr> Type @{ML_type Proof.method} represents proof methods as abstract type.
   21.77 +  \<^descr> Type \<^ML_type>\<open>Proof.method\<close> represents proof methods as abstract type.
   21.78  
   21.79 -  \<^descr> @{ML CONTEXT_METHOD}~\<open>(fn facts => context_tactic)\<close> wraps \<open>context_tactic\<close>
   21.80 +  \<^descr> \<^ML>\<open>CONTEXT_METHOD\<close>~\<open>(fn facts => context_tactic)\<close> wraps \<open>context_tactic\<close>
   21.81    depending on goal facts as a general proof method that may change the proof
   21.82 -  context dynamically. A typical operation is @{ML
   21.83 -  Proof_Context.update_cases}, which is wrapped up as combinator @{index_ML
   21.84 +  context dynamically. A typical operation is \<^ML>\<open>Proof_Context.update_cases\<close>, which is wrapped up as combinator @{index_ML
   21.85    CONTEXT_CASES} for convenience.
   21.86  
   21.87 -  \<^descr> @{ML METHOD}~\<open>(fn facts => tactic)\<close> wraps \<open>tactic\<close> depending on goal facts
   21.88 +  \<^descr> \<^ML>\<open>METHOD\<close>~\<open>(fn facts => tactic)\<close> wraps \<open>tactic\<close> depending on goal facts
   21.89    as regular proof method; the goal context is passed via method syntax.
   21.90  
   21.91 -  \<^descr> @{ML SIMPLE_METHOD}~\<open>tactic\<close> wraps a tactic that addresses all subgoals
   21.92 +  \<^descr> \<^ML>\<open>SIMPLE_METHOD\<close>~\<open>tactic\<close> wraps a tactic that addresses all subgoals
   21.93    uniformly as simple proof method. Goal facts are already inserted into all
   21.94    subgoals before \<open>tactic\<close> is applied.
   21.95  
   21.96 -  \<^descr> @{ML SIMPLE_METHOD'}~\<open>tactic\<close> wraps a tactic that addresses a specific
   21.97 +  \<^descr> \<^ML>\<open>SIMPLE_METHOD'\<close>~\<open>tactic\<close> wraps a tactic that addresses a specific
   21.98    subgoal as simple proof method that operates on subgoal 1. Goal facts are
   21.99    inserted into the subgoal then the \<open>tactic\<close> is applied.
  21.100  
  21.101 -  \<^descr> @{ML Method.insert_tac}~\<open>ctxt facts i\<close> inserts \<open>facts\<close> into subgoal \<open>i\<close>.
  21.102 -  This is convenient to reproduce part of the @{ML SIMPLE_METHOD} or @{ML
  21.103 -  SIMPLE_METHOD'} wrapping within regular @{ML METHOD}, for example.
  21.104 +  \<^descr> \<^ML>\<open>Method.insert_tac\<close>~\<open>ctxt facts i\<close> inserts \<open>facts\<close> into subgoal \<open>i\<close>.
  21.105 +  This is convenient to reproduce part of the \<^ML>\<open>SIMPLE_METHOD\<close> or \<^ML>\<open>SIMPLE_METHOD'\<close> wrapping within regular \<^ML>\<open>METHOD\<close>, for example.
  21.106  
  21.107 -  \<^descr> @{ML Method.setup}~\<open>name parser description\<close> provides the functionality of
  21.108 +  \<^descr> \<^ML>\<open>Method.setup\<close>~\<open>name parser description\<close> provides the functionality of
  21.109    the Isar command @{command method_setup} as ML function.
  21.110  \<close>
  21.111  
  21.112 @@ -319,8 +314,8 @@
  21.113    \<^medskip>
  21.114    The following toy examples illustrate how the goal facts and state are
  21.115    passed to proof methods. The predefined proof method called ``@{method
  21.116 -  tactic}'' wraps ML source of type @{ML_type tactic} (abstracted over
  21.117 -  @{ML_text facts}). This allows immediate experimentation without parsing of
  21.118 +  tactic}'' wraps ML source of type \<^ML_type>\<open>tactic\<close> (abstracted over
  21.119 +  \<^ML_text>\<open>facts\<close>). This allows immediate experimentation without parsing of
  21.120    concrete syntax.
  21.121  \<close>
  21.122  
  21.123 @@ -330,16 +325,16 @@
  21.124    assume a: A and b: B
  21.125  
  21.126    have "A \<and> B"
  21.127 -    apply (tactic \<open>resolve_tac @{context} @{thms conjI} 1\<close>)
  21.128 -    using a apply (tactic \<open>resolve_tac @{context} facts 1\<close>)
  21.129 -    using b apply (tactic \<open>resolve_tac @{context} facts 1\<close>)
  21.130 +    apply (tactic \<open>resolve_tac \<^context> @{thms conjI} 1\<close>)
  21.131 +    using a apply (tactic \<open>resolve_tac \<^context> facts 1\<close>)
  21.132 +    using b apply (tactic \<open>resolve_tac \<^context> facts 1\<close>)
  21.133      done
  21.134  
  21.135    have "A \<and> B"
  21.136      using a and b
  21.137      ML_val \<open>@{Isar.goal}\<close>
  21.138 -    apply (tactic \<open>Method.insert_tac @{context} facts 1\<close>)
  21.139 -    apply (tactic \<open>(resolve_tac @{context} @{thms conjI} THEN_ALL_NEW assume_tac @{context}) 1\<close>)
  21.140 +    apply (tactic \<open>Method.insert_tac \<^context> facts 1\<close>)
  21.141 +    apply (tactic \<open>(resolve_tac \<^context> @{thms conjI} THEN_ALL_NEW assume_tac \<^context>) 1\<close>)
  21.142      done
  21.143  end
  21.144  
  21.145 @@ -361,14 +356,14 @@
  21.146    passes-through the proof context at the end of parsing, but it is not used
  21.147    in this example.
  21.148  
  21.149 -  The @{ML Attrib.thms} parser produces a list of theorems from the usual Isar
  21.150 +  The \<^ML>\<open>Attrib.thms\<close> parser produces a list of theorems from the usual Isar
  21.151    syntax involving attribute expressions etc.\ (syntax category @{syntax
  21.152 -  thms}) @{cite "isabelle-isar-ref"}. The resulting @{ML_text thms} are
  21.153 -  added to @{ML HOL_basic_ss} which already contains the basic Simplifier
  21.154 +  thms}) @{cite "isabelle-isar-ref"}. The resulting \<^ML_text>\<open>thms\<close> are
  21.155 +  added to \<^ML>\<open>HOL_basic_ss\<close> which already contains the basic Simplifier
  21.156    setup for HOL.
  21.157  
  21.158 -  The tactic @{ML asm_full_simp_tac} is the one that is also used in method
  21.159 -  @{method simp} by default. The extra wrapping by the @{ML CHANGED} tactical
  21.160 +  The tactic \<^ML>\<open>asm_full_simp_tac\<close> is the one that is also used in method
  21.161 +  @{method simp} by default. The extra wrapping by the \<^ML>\<open>CHANGED\<close> tactical
  21.162    ensures progress of simplification: identical goal states are filtered out
  21.163    explicitly to make the raw tactic conform to standard Isar method behaviour.
  21.164  
  21.165 @@ -422,7 +417,7 @@
  21.166  method_setup my_simp' =
  21.167    \<open>Attrib.thms >> (fn thms => fn ctxt =>
  21.168      let
  21.169 -      val my_simps = Named_Theorems.get ctxt @{named_theorems my_simp}
  21.170 +      val my_simps = Named_Theorems.get ctxt \<^named_theorems>\<open>my_simp\<close>
  21.171      in
  21.172        SIMPLE_METHOD' (fn i =>
  21.173          CHANGED (asm_full_simp_tac
  21.174 @@ -447,8 +442,7 @@
  21.175  text \<open>
  21.176    \<^medskip>
  21.177    The @{method my_simp} variants defined above are ``simple'' methods, i.e.\
  21.178 -  the goal facts are merely inserted as goal premises by the @{ML
  21.179 -  SIMPLE_METHOD'} or @{ML SIMPLE_METHOD} wrapper. For proof methods that are
  21.180 +  the goal facts are merely inserted as goal premises by the \<^ML>\<open>SIMPLE_METHOD'\<close> or \<^ML>\<open>SIMPLE_METHOD\<close> wrapper. For proof methods that are
  21.181    similar to the standard collection of @{method simp}, @{method blast},
  21.182    @{method fast}, @{method auto} there is little more that can be done.
  21.183  
  21.184 @@ -461,7 +455,7 @@
  21.185  
  21.186    \<^medskip>
  21.187    The technical treatment of rules from the context requires further
  21.188 -  attention. Above we rebuild a fresh @{ML_type simpset} from the arguments
  21.189 +  attention. Above we rebuild a fresh \<^ML_type>\<open>simpset\<close> from the arguments
  21.190    and \<^emph>\<open>all\<close> rules retrieved from the context on every invocation of the
  21.191    method. This does not scale to really large collections of rules, which
  21.192    easily emerges in the context of a big theory library, for example.
  21.193 @@ -471,7 +465,7 @@
  21.194    retrieval. More realistic applications require efficient index-structures
  21.195    that organize theorems in a customized manner, such as a discrimination net
  21.196    that is indexed by the left-hand sides of rewrite rules. For variations on
  21.197 -  the Simplifier, re-use of the existing type @{ML_type simpset} is adequate,
  21.198 +  the Simplifier, re-use of the existing type \<^ML_type>\<open>simpset\<close> is adequate,
  21.199    but scalability would require it be maintained statically within the context
  21.200    data, not dynamically on each tool invocation.
  21.201  \<close>
  21.202 @@ -510,23 +504,23 @@
  21.203    string -> theory -> theory"} \\
  21.204    \end{mldecls}
  21.205  
  21.206 -  \<^descr> Type @{ML_type attribute} represents attributes as concrete type alias.
  21.207 +  \<^descr> Type \<^ML_type>\<open>attribute\<close> represents attributes as concrete type alias.
  21.208  
  21.209 -  \<^descr> @{ML Thm.rule_attribute}~\<open>thms (fn context => rule)\<close> wraps a
  21.210 -  context-dependent rule (mapping on @{ML_type thm}) as attribute.
  21.211 +  \<^descr> \<^ML>\<open>Thm.rule_attribute\<close>~\<open>thms (fn context => rule)\<close> wraps a
  21.212 +  context-dependent rule (mapping on \<^ML_type>\<open>thm\<close>) as attribute.
  21.213  
  21.214    The \<open>thms\<close> are additional parameters: when forming an abstract closure, the
  21.215    system may provide dummy facts that are propagated according to strict
  21.216    evaluation discipline. In that case, \<open>rule\<close> is bypassed.
  21.217  
  21.218 -  \<^descr> @{ML Thm.declaration_attribute}~\<open>(fn thm => decl)\<close> wraps a
  21.219 -  theorem-dependent declaration (mapping on @{ML_type Context.generic}) as
  21.220 +  \<^descr> \<^ML>\<open>Thm.declaration_attribute\<close>~\<open>(fn thm => decl)\<close> wraps a
  21.221 +  theorem-dependent declaration (mapping on \<^ML_type>\<open>Context.generic\<close>) as
  21.222    attribute.
  21.223  
  21.224    When forming an abstract closure, the system may provide a dummy fact as
  21.225    \<open>thm\<close>. In that case, \<open>decl\<close> is bypassed.
  21.226  
  21.227 -  \<^descr> @{ML Attrib.setup}~\<open>name parser description\<close> provides the functionality of
  21.228 +  \<^descr> \<^ML>\<open>Attrib.setup\<close>~\<open>name parser description\<close> provides the functionality of
  21.229    the Isar command @{command attribute_setup} as ML function.
  21.230  \<close>
  21.231  
  21.232 @@ -535,13 +529,12 @@
  21.233    @{ML_antiquotation_def attributes} & : & \<open>ML_antiquotation\<close> \\
  21.234    \end{matharray}
  21.235  
  21.236 -  @{rail \<open>
  21.237 +  \<^rail>\<open>
  21.238    @@{ML_antiquotation attributes} attributes
  21.239 -  \<close>}
  21.240 +  \<close>
  21.241  
  21.242    \<^descr> \<open>@{attributes [\<dots>]}\<close> embeds attribute source representation into the ML
  21.243 -  text, which is particularly useful with declarations like @{ML
  21.244 -  Local_Theory.note}. Attribute names are internalized at compile time, but
  21.245 +  text, which is particularly useful with declarations like \<^ML>\<open>Local_Theory.note\<close>. Attribute names are internalized at compile time, but
  21.246    the source is unevaluated. This means attributes with formal arguments
  21.247    (types, terms, theorems) may be subject to odd effects of dynamic scoping!
  21.248  \<close>
    22.1 --- a/src/Doc/Implementation/Local_Theory.thy	Sat Jan 05 17:00:43 2019 +0100
    22.2 +++ b/src/Doc/Implementation/Local_Theory.thy	Sat Jan 05 17:24:33 2019 +0100
    22.3 @@ -98,21 +98,20 @@
    22.4      local_theory -> (string * thm list) * local_theory"} \\
    22.5    \end{mldecls}
    22.6  
    22.7 -  \<^descr> Type @{ML_type local_theory} represents local theories. Although this is
    22.8 -  merely an alias for @{ML_type Proof.context}, it is semantically a subtype
    22.9 -  of the same: a @{ML_type local_theory} holds target information as special
   22.10 -  context data. Subtyping means that any value \<open>lthy:\<close>~@{ML_type local_theory}
   22.11 -  can be also used with operations on expecting a regular \<open>ctxt:\<close>~@{ML_type
   22.12 -  Proof.context}.
   22.13 +  \<^descr> Type \<^ML_type>\<open>local_theory\<close> represents local theories. Although this is
   22.14 +  merely an alias for \<^ML_type>\<open>Proof.context\<close>, it is semantically a subtype
   22.15 +  of the same: a \<^ML_type>\<open>local_theory\<close> holds target information as special
   22.16 +  context data. Subtyping means that any value \<open>lthy:\<close>~\<^ML_type>\<open>local_theory\<close>
   22.17 +  can be also used with operations on expecting a regular \<open>ctxt:\<close>~\<^ML_type>\<open>Proof.context\<close>.
   22.18  
   22.19 -  \<^descr> @{ML Named_Target.init}~\<open>before_exit name thy\<close> initializes a local theory
   22.20 +  \<^descr> \<^ML>\<open>Named_Target.init\<close>~\<open>before_exit name thy\<close> initializes a local theory
   22.21    derived from the given background theory. An empty name refers to a \<^emph>\<open>global
   22.22    theory\<close> context, and a non-empty name refers to a @{command locale} or
   22.23    @{command class} context (a fully-qualified internal name is expected here).
   22.24    This is useful for experimentation --- normally the Isar toplevel already
   22.25    takes care to initialize the local theory context.
   22.26  
   22.27 -  \<^descr> @{ML Local_Theory.define}~\<open>((b, mx), (a, rhs)) lthy\<close> defines a local
   22.28 +  \<^descr> \<^ML>\<open>Local_Theory.define\<close>~\<open>((b, mx), (a, rhs)) lthy\<close> defines a local
   22.29    entity according to the specification that is given relatively to the
   22.30    current \<open>lthy\<close> context. In particular the term of the RHS may refer to
   22.31    earlier local entities from the auxiliary context, or hypothetical
   22.32 @@ -130,9 +129,8 @@
   22.33    plain declarations such as @{attribute simp}, while non-trivial rules like
   22.34    @{attribute simplified} are better avoided.
   22.35  
   22.36 -  \<^descr> @{ML Local_Theory.note}~\<open>(a, ths) lthy\<close> is analogous to @{ML
   22.37 -  Local_Theory.define}, but defines facts instead of terms. There is also a
   22.38 -  slightly more general variant @{ML Local_Theory.notes} that defines several
   22.39 +  \<^descr> \<^ML>\<open>Local_Theory.note\<close>~\<open>(a, ths) lthy\<close> is analogous to \<^ML>\<open>Local_Theory.define\<close>, but defines facts instead of terms. There is also a
   22.40 +  slightly more general variant \<^ML>\<open>Local_Theory.notes\<close> that defines several
   22.41    facts (with attribute expressions) simultaneously.
   22.42  
   22.43    This is essentially the internal version of the @{command lemmas} command,
    23.1 --- a/src/Doc/Implementation/Logic.thy	Sat Jan 05 17:00:43 2019 +0100
    23.2 +++ b/src/Doc/Implementation/Logic.thy	Sat Jan 05 17:24:33 2019 +0100
    23.3 @@ -120,43 +120,43 @@
    23.4    @{index_ML Sign.primitive_arity: "arity -> theory -> theory"} \\
    23.5    \end{mldecls}
    23.6  
    23.7 -  \<^descr> Type @{ML_type class} represents type classes.
    23.8 +  \<^descr> Type \<^ML_type>\<open>class\<close> represents type classes.
    23.9  
   23.10 -  \<^descr> Type @{ML_type sort} represents sorts, i.e.\ finite intersections of
   23.11 -  classes. The empty list @{ML "[]: sort"} refers to the empty class
   23.12 +  \<^descr> Type \<^ML_type>\<open>sort\<close> represents sorts, i.e.\ finite intersections of
   23.13 +  classes. The empty list \<^ML>\<open>[]: sort\<close> refers to the empty class
   23.14    intersection, i.e.\ the ``full sort''.
   23.15  
   23.16 -  \<^descr> Type @{ML_type arity} represents type arities. A triple \<open>(\<kappa>, \<^vec>s, s)
   23.17 +  \<^descr> Type \<^ML_type>\<open>arity\<close> represents type arities. A triple \<open>(\<kappa>, \<^vec>s, s)
   23.18    : arity\<close> represents \<open>\<kappa> :: (\<^vec>s)s\<close> as described above.
   23.19  
   23.20 -  \<^descr> Type @{ML_type typ} represents types; this is a datatype with constructors
   23.21 -  @{ML TFree}, @{ML TVar}, @{ML Type}.
   23.22 +  \<^descr> Type \<^ML_type>\<open>typ\<close> represents types; this is a datatype with constructors
   23.23 +  \<^ML>\<open>TFree\<close>, \<^ML>\<open>TVar\<close>, \<^ML>\<open>Type\<close>.
   23.24  
   23.25 -  \<^descr> @{ML Term.map_atyps}~\<open>f \<tau>\<close> applies the mapping \<open>f\<close> to all atomic types
   23.26 -  (@{ML TFree}, @{ML TVar}) occurring in \<open>\<tau>\<close>.
   23.27 +  \<^descr> \<^ML>\<open>Term.map_atyps\<close>~\<open>f \<tau>\<close> applies the mapping \<open>f\<close> to all atomic types
   23.28 +  (\<^ML>\<open>TFree\<close>, \<^ML>\<open>TVar\<close>) occurring in \<open>\<tau>\<close>.
   23.29  
   23.30 -  \<^descr> @{ML Term.fold_atyps}~\<open>f \<tau>\<close> iterates the operation \<open>f\<close> over all
   23.31 -  occurrences of atomic types (@{ML TFree}, @{ML TVar}) in \<open>\<tau>\<close>; the type
   23.32 +  \<^descr> \<^ML>\<open>Term.fold_atyps\<close>~\<open>f \<tau>\<close> iterates the operation \<open>f\<close> over all
   23.33 +  occurrences of atomic types (\<^ML>\<open>TFree\<close>, \<^ML>\<open>TVar\<close>) in \<open>\<tau>\<close>; the type
   23.34    structure is traversed from left to right.
   23.35  
   23.36 -  \<^descr> @{ML Sign.subsort}~\<open>thy (s\<^sub>1, s\<^sub>2)\<close> tests the subsort relation \<open>s\<^sub>1 \<subseteq>
   23.37 +  \<^descr> \<^ML>\<open>Sign.subsort\<close>~\<open>thy (s\<^sub>1, s\<^sub>2)\<close> tests the subsort relation \<open>s\<^sub>1 \<subseteq>
   23.38    s\<^sub>2\<close>.
   23.39  
   23.40 -  \<^descr> @{ML Sign.of_sort}~\<open>thy (\<tau>, s)\<close> tests whether type \<open>\<tau>\<close> is of sort \<open>s\<close>.
   23.41 +  \<^descr> \<^ML>\<open>Sign.of_sort\<close>~\<open>thy (\<tau>, s)\<close> tests whether type \<open>\<tau>\<close> is of sort \<open>s\<close>.
   23.42  
   23.43 -  \<^descr> @{ML Sign.add_type}~\<open>ctxt (\<kappa>, k, mx)\<close> declares a new type constructors \<open>\<kappa>\<close>
   23.44 +  \<^descr> \<^ML>\<open>Sign.add_type\<close>~\<open>ctxt (\<kappa>, k, mx)\<close> declares a new type constructors \<open>\<kappa>\<close>
   23.45    with \<open>k\<close> arguments and optional mixfix syntax.
   23.46  
   23.47 -  \<^descr> @{ML Sign.add_type_abbrev}~\<open>ctxt (\<kappa>, \<^vec>\<alpha>, \<tau>)\<close> defines a new type
   23.48 +  \<^descr> \<^ML>\<open>Sign.add_type_abbrev\<close>~\<open>ctxt (\<kappa>, \<^vec>\<alpha>, \<tau>)\<close> defines a new type
   23.49    abbreviation \<open>(\<^vec>\<alpha>)\<kappa> = \<tau>\<close>.
   23.50  
   23.51 -  \<^descr> @{ML Sign.primitive_class}~\<open>(c, [c\<^sub>1, \<dots>, c\<^sub>n])\<close> declares a new class \<open>c\<close>,
   23.52 +  \<^descr> \<^ML>\<open>Sign.primitive_class\<close>~\<open>(c, [c\<^sub>1, \<dots>, c\<^sub>n])\<close> declares a new class \<open>c\<close>,
   23.53    together with class relations \<open>c \<subseteq> c\<^sub>i\<close>, for \<open>i = 1, \<dots>, n\<close>.
   23.54  
   23.55 -  \<^descr> @{ML Sign.primitive_classrel}~\<open>(c\<^sub>1, c\<^sub>2)\<close> declares the class relation
   23.56 +  \<^descr> \<^ML>\<open>Sign.primitive_classrel\<close>~\<open>(c\<^sub>1, c\<^sub>2)\<close> declares the class relation
   23.57    \<open>c\<^sub>1 \<subseteq> c\<^sub>2\<close>.
   23.58  
   23.59 -  \<^descr> @{ML Sign.primitive_arity}~\<open>(\<kappa>, \<^vec>s, s)\<close> declares the arity \<open>\<kappa> ::
   23.60 +  \<^descr> \<^ML>\<open>Sign.primitive_arity\<close>~\<open>(\<kappa>, \<^vec>s, s)\<close> declares the arity \<open>\<kappa> ::
   23.61    (\<^vec>s)s\<close>.
   23.62  \<close>
   23.63  
   23.64 @@ -170,7 +170,7 @@
   23.65    @{ML_antiquotation_def "typ"} & : & \<open>ML_antiquotation\<close> \\
   23.66    \end{matharray}
   23.67  
   23.68 -  @{rail \<open>
   23.69 +  \<^rail>\<open>
   23.70    @@{ML_antiquotation class} embedded
   23.71    ;
   23.72    @@{ML_antiquotation sort} sort
   23.73 @@ -180,25 +180,25 @@
   23.74     @@{ML_antiquotation nonterminal}) embedded
   23.75    ;
   23.76    @@{ML_antiquotation typ} type
   23.77 -  \<close>}
   23.78 +  \<close>
   23.79  
   23.80 -  \<^descr> \<open>@{class c}\<close> inlines the internalized class \<open>c\<close> --- as @{ML_type string}
   23.81 +  \<^descr> \<open>@{class c}\<close> inlines the internalized class \<open>c\<close> --- as \<^ML_type>\<open>string\<close>
   23.82    literal.
   23.83  
   23.84 -  \<^descr> \<open>@{sort s}\<close> inlines the internalized sort \<open>s\<close> --- as @{ML_type "string
   23.85 -  list"} literal.
   23.86 +  \<^descr> \<open>@{sort s}\<close> inlines the internalized sort \<open>s\<close> --- as \<^ML_type>\<open>string
   23.87 +  list\<close> literal.
   23.88  
   23.89    \<^descr> \<open>@{type_name c}\<close> inlines the internalized type constructor \<open>c\<close> --- as
   23.90 -  @{ML_type string} literal.
   23.91 +  \<^ML_type>\<open>string\<close> literal.
   23.92  
   23.93    \<^descr> \<open>@{type_abbrev c}\<close> inlines the internalized type abbreviation \<open>c\<close> --- as
   23.94 -  @{ML_type string} literal.
   23.95 +  \<^ML_type>\<open>string\<close> literal.
   23.96  
   23.97    \<^descr> \<open>@{nonterminal c}\<close> inlines the internalized syntactic type~/ grammar
   23.98 -  nonterminal \<open>c\<close> --- as @{ML_type string} literal.
   23.99 +  nonterminal \<open>c\<close> --- as \<^ML_type>\<open>string\<close> literal.
  23.100  
  23.101    \<^descr> \<open>@{typ \<tau>}\<close> inlines the internalized type \<open>\<tau>\<close> --- as constructor term for
  23.102 -  datatype @{ML_type typ}.
  23.103 +  datatype \<^ML_type>\<open>typ\<close>.
  23.104  \<close>
  23.105  
  23.106  
  23.107 @@ -333,50 +333,49 @@
  23.108    @{index_ML Sign.const_instance: "theory -> string * typ list -> typ"} \\
  23.109    \end{mldecls}
  23.110  
  23.111 -  \<^descr> Type @{ML_type term} represents de-Bruijn terms, with comments in
  23.112 +  \<^descr> Type \<^ML_type>\<open>term\<close> represents de-Bruijn terms, with comments in
  23.113    abstractions, and explicitly named free variables and constants; this is a
  23.114    datatype with constructors @{index_ML Bound}, @{index_ML Free}, @{index_ML
  23.115    Var}, @{index_ML Const}, @{index_ML Abs}, @{index_ML_op "$"}.
  23.116  
  23.117 -  \<^descr> \<open>t\<close>~@{ML_text aconv}~\<open>u\<close> checks \<open>\<alpha>\<close>-equivalence of two terms. This is the
  23.118 -  basic equality relation on type @{ML_type term}; raw datatype equality
  23.119 +  \<^descr> \<open>t\<close>~\<^ML_text>\<open>aconv\<close>~\<open>u\<close> checks \<open>\<alpha>\<close>-equivalence of two terms. This is the
  23.120 +  basic equality relation on type \<^ML_type>\<open>term\<close>; raw datatype equality
  23.121    should only be used for operations related to parsing or printing!
  23.122  
  23.123 -  \<^descr> @{ML Term.map_types}~\<open>f t\<close> applies the mapping \<open>f\<close> to all types occurring
  23.124 +  \<^descr> \<^ML>\<open>Term.map_types\<close>~\<open>f t\<close> applies the mapping \<open>f\<close> to all types occurring
  23.125    in \<open>t\<close>.
  23.126  
  23.127 -  \<^descr> @{ML Term.fold_types}~\<open>f t\<close> iterates the operation \<open>f\<close> over all
  23.128 +  \<^descr> \<^ML>\<open>Term.fold_types\<close>~\<open>f t\<close> iterates the operation \<open>f\<close> over all
  23.129    occurrences of types in \<open>t\<close>; the term structure is traversed from left to
  23.130    right.
  23.131  
  23.132 -  \<^descr> @{ML Term.map_aterms}~\<open>f t\<close> applies the mapping \<open>f\<close> to all atomic terms
  23.133 -  (@{ML Bound}, @{ML Free}, @{ML Var}, @{ML Const}) occurring in \<open>t\<close>.
  23.134 +  \<^descr> \<^ML>\<open>Term.map_aterms\<close>~\<open>f t\<close> applies the mapping \<open>f\<close> to all atomic terms
  23.135 +  (\<^ML>\<open>Bound\<close>, \<^ML>\<open>Free\<close>, \<^ML>\<open>Var\<close>, \<^ML>\<open>Const\<close>) occurring in \<open>t\<close>.
  23.136  
  23.137 -  \<^descr> @{ML Term.fold_aterms}~\<open>f t\<close> iterates the operation \<open>f\<close> over all
  23.138 -  occurrences of atomic terms (@{ML Bound}, @{ML Free}, @{ML Var}, @{ML
  23.139 -  Const}) in \<open>t\<close>; the term structure is traversed from left to right.
  23.140 +  \<^descr> \<^ML>\<open>Term.fold_aterms\<close>~\<open>f t\<close> iterates the operation \<open>f\<close> over all
  23.141 +  occurrences of atomic terms (\<^ML>\<open>Bound\<close>, \<^ML>\<open>Free\<close>, \<^ML>\<open>Var\<close>, \<^ML>\<open>Const\<close>) in \<open>t\<close>; the term structure is traversed from left to right.
  23.142  
  23.143 -  \<^descr> @{ML fastype_of}~\<open>t\<close> determines the type of a well-typed term. This
  23.144 +  \<^descr> \<^ML>\<open>fastype_of\<close>~\<open>t\<close> determines the type of a well-typed term. This
  23.145    operation is relatively slow, despite the omission of any sanity checks.
  23.146  
  23.147 -  \<^descr> @{ML lambda}~\<open>a b\<close> produces an abstraction \<open>\<lambda>a. b\<close>, where occurrences of
  23.148 +  \<^descr> \<^ML>\<open>lambda\<close>~\<open>a b\<close> produces an abstraction \<open>\<lambda>a. b\<close>, where occurrences of
  23.149    the atomic term \<open>a\<close> in the body \<open>b\<close> are replaced by bound variables.
  23.150  
  23.151 -  \<^descr> @{ML betapply}~\<open>(t, u)\<close> produces an application \<open>t u\<close>, with topmost
  23.152 +  \<^descr> \<^ML>\<open>betapply\<close>~\<open>(t, u)\<close> produces an application \<open>t u\<close>, with topmost
  23.153    \<open>\<beta>\<close>-conversion if \<open>t\<close> is an abstraction.
  23.154  
  23.155 -  \<^descr> @{ML incr_boundvars}~\<open>j\<close> increments a term's dangling bound variables by
  23.156 +  \<^descr> \<^ML>\<open>incr_boundvars\<close>~\<open>j\<close> increments a term's dangling bound variables by
  23.157    the offset \<open>j\<close>. This is required when moving a subterm into a context where
  23.158    it is enclosed by a different number of abstractions. Bound variables with a
  23.159    matching abstraction are unaffected.
  23.160  
  23.161 -  \<^descr> @{ML Sign.declare_const}~\<open>ctxt ((c, \<sigma>), mx)\<close> declares a new constant \<open>c ::
  23.162 +  \<^descr> \<^ML>\<open>Sign.declare_const\<close>~\<open>ctxt ((c, \<sigma>), mx)\<close> declares a new constant \<open>c ::
  23.163    \<sigma>\<close> with optional mixfix syntax.
  23.164  
  23.165 -  \<^descr> @{ML Sign.add_abbrev}~\<open>print_mode (c, t)\<close> introduces a new term
  23.166 +  \<^descr> \<^ML>\<open>Sign.add_abbrev\<close>~\<open>print_mode (c, t)\<close> introduces a new term
  23.167    abbreviation \<open>c \<equiv> t\<close>.
  23.168  
  23.169 -  \<^descr> @{ML Sign.const_typargs}~\<open>thy (c, \<tau>)\<close> and @{ML Sign.const_instance}~\<open>thy
  23.170 +  \<^descr> \<^ML>\<open>Sign.const_typargs\<close>~\<open>thy (c, \<tau>)\<close> and \<^ML>\<open>Sign.const_instance\<close>~\<open>thy
  23.171    (c, [\<tau>\<^sub>1, \<dots>, \<tau>\<^sub>n])\<close> convert between two representations of polymorphic
  23.172    constants: full type instance vs.\ compact type arguments form.
  23.173  \<close>
  23.174 @@ -390,7 +389,7 @@
  23.175    @{ML_antiquotation_def "prop"} & : & \<open>ML_antiquotation\<close> \\
  23.176    \end{matharray}
  23.177  
  23.178 -  @{rail \<open>
  23.179 +  \<^rail>\<open>
  23.180    (@@{ML_antiquotation const_name} |
  23.181     @@{ML_antiquotation const_abbrev}) embedded
  23.182    ;
  23.183 @@ -399,23 +398,22 @@
  23.184    @@{ML_antiquotation term} term
  23.185    ;
  23.186    @@{ML_antiquotation prop} prop
  23.187 -  \<close>}
  23.188 +  \<close>
  23.189  
  23.190    \<^descr> \<open>@{const_name c}\<close> inlines the internalized logical constant name \<open>c\<close> ---
  23.191 -  as @{ML_type string} literal.
  23.192 +  as \<^ML_type>\<open>string\<close> literal.
  23.193  
  23.194    \<^descr> \<open>@{const_abbrev c}\<close> inlines the internalized abbreviated constant name \<open>c\<close>
  23.195 -  --- as @{ML_type string} literal.
  23.196 +  --- as \<^ML_type>\<open>string\<close> literal.
  23.197  
  23.198    \<^descr> \<open>@{const c(\<^vec>\<tau>)}\<close> inlines the internalized constant \<open>c\<close> with precise
  23.199 -  type instantiation in the sense of @{ML Sign.const_instance} --- as @{ML
  23.200 -  Const} constructor term for datatype @{ML_type term}.
  23.201 +  type instantiation in the sense of \<^ML>\<open>Sign.const_instance\<close> --- as \<^ML>\<open>Const\<close> constructor term for datatype \<^ML_type>\<open>term\<close>.
  23.202  
  23.203    \<^descr> \<open>@{term t}\<close> inlines the internalized term \<open>t\<close> --- as constructor term for
  23.204 -  datatype @{ML_type term}.
  23.205 +  datatype \<^ML_type>\<open>term\<close>.
  23.206  
  23.207    \<^descr> \<open>@{prop \<phi>}\<close> inlines the internalized proposition \<open>\<phi>\<close> --- as constructor
  23.208 -  term for datatype @{ML_type term}.
  23.209 +  term for datatype \<^ML_type>\<open>term\<close>.
  23.210  \<close>
  23.211  
  23.212  
  23.213 @@ -601,84 +599,82 @@
  23.214    Defs.entry -> Defs.entry list -> theory -> theory"} \\
  23.215    \end{mldecls}
  23.216  
  23.217 -  \<^descr> @{ML Thm.peek_status}~\<open>thm\<close> informs about the current status of the
  23.218 +  \<^descr> \<^ML>\<open>Thm.peek_status\<close>~\<open>thm\<close> informs about the current status of the
  23.219    derivation object behind the given theorem. This is a snapshot of a
  23.220    potentially ongoing (parallel) evaluation of proofs. The three Boolean
  23.221    values indicate the following: \<^verbatim>\<open>oracle\<close> if the finished part contains some
  23.222    oracle invocation; \<^verbatim>\<open>unfinished\<close> if some future proofs are still pending;
  23.223    \<^verbatim>\<open>failed\<close> if some future proof has failed, rendering the theorem invalid!
  23.224  
  23.225 -  \<^descr> @{ML Logic.all}~\<open>a B\<close> produces a Pure quantification \<open>\<And>a. B\<close>, where
  23.226 +  \<^descr> \<^ML>\<open>Logic.all\<close>~\<open>a B\<close> produces a Pure quantification \<open>\<And>a. B\<close>, where
  23.227    occurrences of the atomic term \<open>a\<close> in the body proposition \<open>B\<close> are replaced
  23.228 -  by bound variables. (See also @{ML lambda} on terms.)
  23.229 +  by bound variables. (See also \<^ML>\<open>lambda\<close> on terms.)
  23.230  
  23.231 -  \<^descr> @{ML Logic.mk_implies}~\<open>(A, B)\<close> produces a Pure implication \<open>A \<Longrightarrow> B\<close>.
  23.232 +  \<^descr> \<^ML>\<open>Logic.mk_implies\<close>~\<open>(A, B)\<close> produces a Pure implication \<open>A \<Longrightarrow> B\<close>.
  23.233  
  23.234 -  \<^descr> Types @{ML_type ctyp} and @{ML_type cterm} represent certified types and
  23.235 +  \<^descr> Types \<^ML_type>\<open>ctyp\<close> and \<^ML_type>\<open>cterm\<close> represent certified types and
  23.236    terms, respectively. These are abstract datatypes that guarantee that its
  23.237    values have passed the full well-formedness (and well-typedness) checks,
  23.238    relative to the declarations of type constructors, constants etc.\ in the
  23.239 -  background theory. The abstract types @{ML_type ctyp} and @{ML_type cterm}
  23.240 +  background theory. The abstract types \<^ML_type>\<open>ctyp\<close> and \<^ML_type>\<open>cterm\<close>
  23.241    are part of the same inference kernel that is mainly responsible for
  23.242 -  @{ML_type thm}. Thus syntactic operations on @{ML_type ctyp} and @{ML_type
  23.243 -  cterm} are located in the @{ML_structure Thm} module, even though theorems
  23.244 +  \<^ML_type>\<open>thm\<close>. Thus syntactic operations on \<^ML_type>\<open>ctyp\<close> and \<^ML_type>\<open>cterm\<close> are located in the \<^ML_structure>\<open>Thm\<close> module, even though theorems
  23.245    are not yet involved at that stage.
  23.246  
  23.247 -  \<^descr> @{ML Thm.ctyp_of}~\<open>ctxt \<tau>\<close> and @{ML Thm.cterm_of}~\<open>ctxt t\<close> explicitly
  23.248 +  \<^descr> \<^ML>\<open>Thm.ctyp_of\<close>~\<open>ctxt \<tau>\<close> and \<^ML>\<open>Thm.cterm_of\<close>~\<open>ctxt t\<close> explicitly
  23.249    check types and terms, respectively. This also involves some basic
  23.250    normalizations, such expansion of type and term abbreviations from the
  23.251    underlying theory context. Full re-certification is relatively slow and
  23.252    should be avoided in tight reasoning loops.
  23.253  
  23.254 -  \<^descr> @{ML Thm.apply}, @{ML Thm.lambda}, @{ML Thm.all}, @{ML Drule.mk_implies}
  23.255 +  \<^descr> \<^ML>\<open>Thm.apply\<close>, \<^ML>\<open>Thm.lambda\<close>, \<^ML>\<open>Thm.all\<close>, \<^ML>\<open>Drule.mk_implies\<close>
  23.256    etc.\ compose certified terms (or propositions) incrementally. This is
  23.257 -  equivalent to @{ML Thm.cterm_of} after unchecked @{ML_op "$"}, @{ML lambda},
  23.258 -  @{ML Logic.all}, @{ML Logic.mk_implies} etc., but there can be a big
  23.259 +  equivalent to \<^ML>\<open>Thm.cterm_of\<close> after unchecked \<^ML_op>\<open>$\<close>, \<^ML>\<open>lambda\<close>,
  23.260 +  \<^ML>\<open>Logic.all\<close>, \<^ML>\<open>Logic.mk_implies\<close> etc., but there can be a big
  23.261    difference in performance when large existing entities are composed by a few
  23.262    extra constructions on top. There are separate operations to decompose
  23.263    certified terms and theorems to produce certified terms again.
  23.264  
  23.265 -  \<^descr> Type @{ML_type thm} represents proven propositions. This is an abstract
  23.266 +  \<^descr> Type \<^ML_type>\<open>thm\<close> represents proven propositions. This is an abstract
  23.267    datatype that guarantees that its values have been constructed by basic
  23.268 -  principles of the @{ML_structure Thm} module. Every @{ML_type thm} value
  23.269 +  principles of the \<^ML_structure>\<open>Thm\<close> module. Every \<^ML_type>\<open>thm\<close> value
  23.270    refers its background theory, cf.\ \secref{sec:context-theory}.
  23.271  
  23.272 -  \<^descr> @{ML Thm.transfer}~\<open>thy thm\<close> transfers the given theorem to a \<^emph>\<open>larger\<close>
  23.273 +  \<^descr> \<^ML>\<open>Thm.transfer\<close>~\<open>thy thm\<close> transfers the given theorem to a \<^emph>\<open>larger\<close>
  23.274    theory, see also \secref{sec:context}. This formal adjustment of the
  23.275    background context has no logical significance, but is occasionally required
  23.276    for formal reasons, e.g.\ when theorems that are imported from more basic
  23.277    theories are used in the current situation.
  23.278  
  23.279 -  \<^descr> @{ML Thm.assume}, @{ML Thm.forall_intr}, @{ML Thm.forall_elim}, @{ML
  23.280 -  Thm.implies_intr}, and @{ML Thm.implies_elim} correspond to the primitive
  23.281 +  \<^descr> \<^ML>\<open>Thm.assume\<close>, \<^ML>\<open>Thm.forall_intr\<close>, \<^ML>\<open>Thm.forall_elim\<close>, \<^ML>\<open>Thm.implies_intr\<close>, and \<^ML>\<open>Thm.implies_elim\<close> correspond to the primitive
  23.282    inferences of \figref{fig:prim-rules}.
  23.283  
  23.284 -  \<^descr> @{ML Thm.generalize}~\<open>(\<^vec>\<alpha>, \<^vec>x)\<close> corresponds to the
  23.285 +  \<^descr> \<^ML>\<open>Thm.generalize\<close>~\<open>(\<^vec>\<alpha>, \<^vec>x)\<close> corresponds to the
  23.286    \<open>generalize\<close> rules of \figref{fig:subst-rules}. Here collections of type and
  23.287    term variables are generalized simultaneously, specified by the given basic
  23.288    names.
  23.289  
  23.290 -  \<^descr> @{ML Thm.instantiate}~\<open>(\<^vec>\<alpha>\<^sub>s, \<^vec>x\<^sub>\<tau>)\<close> corresponds to the
  23.291 +  \<^descr> \<^ML>\<open>Thm.instantiate\<close>~\<open>(\<^vec>\<alpha>\<^sub>s, \<^vec>x\<^sub>\<tau>)\<close> corresponds to the
  23.292    \<open>instantiate\<close> rules of \figref{fig:subst-rules}. Type variables are
  23.293    substituted before term variables. Note that the types in \<open>\<^vec>x\<^sub>\<tau>\<close> refer
  23.294    to the instantiated versions.
  23.295  
  23.296 -  \<^descr> @{ML Thm.add_axiom}~\<open>ctxt (name, A)\<close> declares an arbitrary proposition as
  23.297 +  \<^descr> \<^ML>\<open>Thm.add_axiom\<close>~\<open>ctxt (name, A)\<close> declares an arbitrary proposition as
  23.298    axiom, and retrieves it as a theorem from the resulting theory, cf.\ \<open>axiom\<close>
  23.299    in \figref{fig:prim-rules}. Note that the low-level representation in the
  23.300    axiom table may differ slightly from the returned theorem.
  23.301  
  23.302 -  \<^descr> @{ML Thm.add_oracle}~\<open>(binding, oracle)\<close> produces a named oracle rule,
  23.303 +  \<^descr> \<^ML>\<open>Thm.add_oracle\<close>~\<open>(binding, oracle)\<close> produces a named oracle rule,
  23.304    essentially generating arbitrary axioms on the fly, cf.\ \<open>axiom\<close> in
  23.305    \figref{fig:prim-rules}.
  23.306  
  23.307 -  \<^descr> @{ML Thm.add_def}~\<open>ctxt unchecked overloaded (name, c \<^vec>x \<equiv> t)\<close>
  23.308 +  \<^descr> \<^ML>\<open>Thm.add_def\<close>~\<open>ctxt unchecked overloaded (name, c \<^vec>x \<equiv> t)\<close>
  23.309    states a definitional axiom for an existing constant \<open>c\<close>. Dependencies are
  23.310 -  recorded via @{ML Theory.add_deps}, unless the \<open>unchecked\<close> option is set.
  23.311 +  recorded via \<^ML>\<open>Theory.add_deps\<close>, unless the \<open>unchecked\<close> option is set.
  23.312    Note that the low-level representation in the axiom table may differ
  23.313    slightly from the returned theorem.
  23.314  
  23.315 -  \<^descr> @{ML Theory.add_deps}~\<open>ctxt name c\<^sub>\<tau> \<^vec>d\<^sub>\<sigma>\<close> declares dependencies of
  23.316 +  \<^descr> \<^ML>\<open>Theory.add_deps\<close>~\<open>ctxt name c\<^sub>\<tau> \<^vec>d\<^sub>\<sigma>\<close> declares dependencies of
  23.317    a named specification for constant \<open>c\<^sub>\<tau>\<close>, relative to existing
  23.318    specifications for constants \<open>\<^vec>d\<^sub>\<sigma>\<close>. This also works for type
  23.319    constructors.
  23.320 @@ -694,7 +690,7 @@
  23.321    @{ML_antiquotation_def "lemma"} & : & \<open>ML_antiquotation\<close> \\
  23.322    \end{matharray}
  23.323  
  23.324 -  @{rail \<open>
  23.325 +  \<^rail>\<open>
  23.326    @@{ML_antiquotation ctyp} typ
  23.327    ;
  23.328    @@{ML_antiquotation cterm} term
  23.329 @@ -707,23 +703,23 @@
  23.330    ;
  23.331    @@{ML_antiquotation lemma} ('(' @'open' ')')? ((prop +) + @'and') \<newline>
  23.332      @'by' method method?
  23.333 -  \<close>}
  23.334 +  \<close>
  23.335  
  23.336    \<^descr> \<open>@{ctyp \<tau>}\<close> produces a certified type wrt.\ the current background theory
  23.337 -  --- as abstract value of type @{ML_type ctyp}.
  23.338 +  --- as abstract value of type \<^ML_type>\<open>ctyp\<close>.
  23.339  
  23.340    \<^descr> \<open>@{cterm t}\<close> and \<open>@{cprop \<phi>}\<close> produce a certified term wrt.\ the current
  23.341 -  background theory --- as abstract value of type @{ML_type cterm}.
  23.342 +  background theory --- as abstract value of type \<^ML_type>\<open>cterm\<close>.
  23.343  
  23.344    \<^descr> \<open>@{thm a}\<close> produces a singleton fact --- as abstract value of type
  23.345 -  @{ML_type thm}.
  23.346 +  \<^ML_type>\<open>thm\<close>.
  23.347  
  23.348    \<^descr> \<open>@{thms a}\<close> produces a general fact --- as abstract value of type
  23.349 -  @{ML_type "thm list"}.
  23.350 +  \<^ML_type>\<open>thm list\<close>.
  23.351  
  23.352    \<^descr> \<open>@{lemma \<phi> by meth}\<close> produces a fact that is proven on the spot according
  23.353    to the minimal proof, which imitates a terminal Isar proof. The result is an
  23.354 -  abstract value of type @{ML_type thm} or @{ML_type "thm list"}, depending on
  23.355 +  abstract value of type \<^ML_type>\<open>thm\<close> or \<^ML_type>\<open>thm list\<close>, depending on
  23.356    the number of propositions given here.
  23.357  
  23.358    The internal derivation object lacks a proper theorem name, but it is
  23.359 @@ -800,17 +796,17 @@
  23.360    @{index_ML Logic.dest_type: "term -> typ"} \\
  23.361    \end{mldecls}
  23.362  
  23.363 -  \<^descr> @{ML Conjunction.intr} derives \<open>A &&& B\<close> from \<open>A\<close> and \<open>B\<close>.
  23.364 +  \<^descr> \<^ML>\<open>Conjunction.intr\<close> derives \<open>A &&& B\<close> from \<open>A\<close> and \<open>B\<close>.
  23.365  
  23.366 -  \<^descr> @{ML Conjunction.elim} derives \<open>A\<close> and \<open>B\<close> from \<open>A &&& B\<close>.
  23.367 +  \<^descr> \<^ML>\<open>Conjunction.elim\<close> derives \<open>A\<close> and \<open>B\<close> from \<open>A &&& B\<close>.
  23.368  
  23.369 -  \<^descr> @{ML Drule.mk_term} derives \<open>TERM t\<close>.
  23.370 +  \<^descr> \<^ML>\<open>Drule.mk_term\<close> derives \<open>TERM t\<close>.
  23.371  
  23.372 -  \<^descr> @{ML Drule.dest_term} recovers term \<open>t\<close> from \<open>TERM t\<close>.
  23.373 +  \<^descr> \<^ML>\<open>Drule.dest_term\<close> recovers term \<open>t\<close> from \<open>TERM t\<close>.
  23.374  
  23.375 -  \<^descr> @{ML Logic.mk_type}~\<open>\<tau>\<close> produces the term \<open>TYPE(\<tau>)\<close>.
  23.376 +  \<^descr> \<^ML>\<open>Logic.mk_type\<close>~\<open>\<tau>\<close> produces the term \<open>TYPE(\<tau>)\<close>.
  23.377  
  23.378 -  \<^descr> @{ML Logic.dest_type}~\<open>TYPE(\<tau>)\<close> recovers the type \<open>\<tau>\<close>.
  23.379 +  \<^descr> \<^ML>\<open>Logic.dest_type\<close>~\<open>TYPE(\<tau>)\<close> recovers the type \<open>\<tau>\<close>.
  23.380  \<close>
  23.381  
  23.382  
  23.383 @@ -846,17 +842,16 @@
  23.384    @{index_ML Thm.strip_shyps: "thm -> thm"} \\
  23.385    \end{mldecls}
  23.386  
  23.387 -  \<^descr> @{ML Thm.extra_shyps}~\<open>thm\<close> determines the extraneous sort hypotheses of
  23.388 +  \<^descr> \<^ML>\<open>Thm.extra_shyps\<close>~\<open>thm\<close> determines the extraneous sort hypotheses of
  23.389    the given theorem, i.e.\ the sorts that are not present within type
  23.390    variables of the statement.
  23.391  
  23.392 -  \<^descr> @{ML Thm.strip_shyps}~\<open>thm\<close> removes any extraneous sort hypotheses that
  23.393 +  \<^descr> \<^ML>\<open>Thm.strip_shyps\<close>~\<open>thm\<close> removes any extraneous sort hypotheses that
  23.394    can be witnessed from the type signature.
  23.395  \<close>
  23.396  
  23.397  text %mlex \<open>
  23.398 -  The following artificial example demonstrates the derivation of @{prop
  23.399 -  False} with a pending sort hypothesis involving a logically empty sort.
  23.400 +  The following artificial example demonstrates the derivation of \<^prop>\<open>False\<close> with a pending sort hypothesis involving a logically empty sort.
  23.401  \<close>
  23.402  
  23.403  class empty =
  23.404 @@ -865,7 +860,7 @@
  23.405  theorem (in empty) false: False
  23.406    using bad by blast
  23.407  
  23.408 -ML_val \<open>@{assert} (Thm.extra_shyps @{thm false} = [@{sort empty}])\<close>
  23.409 +ML_val \<open>\<^assert> (Thm.extra_shyps @{thm false} = [\<^sort>\<open>empty\<close>])\<close>
  23.410  
  23.411  text \<open>
  23.412    Thanks to the inference kernel managing sort hypothesis according to their
  23.413 @@ -951,7 +946,7 @@
  23.414    @{index_ML Simplifier.norm_hhf: "Proof.context -> thm -> thm"} \\
  23.415    \end{mldecls}
  23.416  
  23.417 -  \<^descr> @{ML Simplifier.norm_hhf}~\<open>ctxt thm\<close> normalizes the given theorem
  23.418 +  \<^descr> \<^ML>\<open>Simplifier.norm_hhf\<close>~\<open>ctxt thm\<close> normalizes the given theorem
  23.419    according to the canonical form specified above. This is occasionally
  23.420    helpful to repair some low-level tools that do not handle Hereditary Harrop
  23.421    Formulae properly.
  23.422 @@ -1032,7 +1027,7 @@
  23.423    \<^descr> \<open>rule\<^sub>1 RSN (i, rule\<^sub>2)\<close> resolves the conclusion of \<open>rule\<^sub>1\<close> with the
  23.424    \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>, according to the @{inference resolution}
  23.425    principle explained above. Unless there is precisely one resolvent it raises
  23.426 -  exception @{ML THM}.
  23.427 +  exception \<^ML>\<open>THM\<close>.
  23.428  
  23.429    This corresponds to the rule attribute @{attribute THEN} in Isar source
  23.430    language.
  23.431 @@ -1044,7 +1039,7 @@
  23.432    with the \<open>i\<close>-th premise of \<open>rule\<^sub>2\<close>, accumulating multiple results in one
  23.433    big list. Note that such strict enumerations of higher-order unifications
  23.434    can be inefficient compared to the lazy variant seen in elementary tactics
  23.435 -  like @{ML resolve_tac}.
  23.436 +  like \<^ML>\<open>resolve_tac\<close>.
  23.437  
  23.438    \<^descr> \<open>rules\<^sub>1 RL rules\<^sub>2\<close> abbreviates \<open>rules\<^sub>1 RLN (1, rules\<^sub>2)\<close>.
  23.439  
  23.440 @@ -1196,32 +1191,32 @@
  23.441    @{index_ML Proof_Syntax.pretty_proof: "Proof.context -> proof -> Pretty.T"} \\
  23.442    \end{mldecls}
  23.443  
  23.444 -  \<^descr> Type @{ML_type proof} represents proof terms; this is a datatype with
  23.445 +  \<^descr> Type \<^ML_type>\<open>proof\<close> represents proof terms; this is a datatype with
  23.446    constructors @{index_ML Abst}, @{index_ML AbsP}, @{index_ML_op "%"},
  23.447    @{index_ML_op "%%"}, @{index_ML PBound}, @{index_ML MinProof}, @{index_ML
  23.448    Hyp}, @{index_ML PAxm}, @{index_ML Oracle}, @{index_ML Promise}, @{index_ML
  23.449    PThm} as explained above. %FIXME OfClass (!?)
  23.450  
  23.451 -  \<^descr> Type @{ML_type proof_body} represents the nested proof information of a
  23.452 +  \<^descr> Type \<^ML_type>\<open>proof_body\<close> represents the nested proof information of a
  23.453    named theorem, consisting of a digest of oracles and named theorem over some
  23.454    proof term. The digest only covers the directly visible part of the proof:
  23.455    in order to get the full information, the implicit graph of nested theorems
  23.456 -  needs to be traversed (e.g.\ using @{ML Proofterm.fold_body_thms}).
  23.457 +  needs to be traversed (e.g.\ using \<^ML>\<open>Proofterm.fold_body_thms\<close>).
  23.458  
  23.459 -  \<^descr> @{ML Thm.proof_of}~\<open>thm\<close> and @{ML Thm.proof_body_of}~\<open>thm\<close> produce the
  23.460 +  \<^descr> \<^ML>\<open>Thm.proof_of\<close>~\<open>thm\<close> and \<^ML>\<open>Thm.proof_body_of\<close>~\<open>thm\<close> produce the
  23.461    proof term or proof body (with digest of oracles and theorems) from a given
  23.462    theorem. Note that this involves a full join of internal futures that
  23.463    fulfill pending proof promises, and thus disrupts the natural bottom-up
  23.464    construction of proofs by introducing dynamic ad-hoc dependencies. Parallel
  23.465    performance may suffer by inspecting proof terms at run-time.
  23.466  
  23.467 -  \<^descr> @{ML Proofterm.proofs} specifies the detail of proof recording within
  23.468 -  @{ML_type thm} values produced by the inference kernel: @{ML 0} records only
  23.469 -  the names of oracles, @{ML 1} records oracle names and propositions, @{ML 2}
  23.470 +  \<^descr> \<^ML>\<open>Proofterm.proofs\<close> specifies the detail of proof recording within
  23.471 +  \<^ML_type>\<open>thm\<close> values produced by the inference kernel: \<^ML>\<open>0\<close> records only
  23.472 +  the names of oracles, \<^ML>\<open>1\<close> records oracle names and propositions, \<^ML>\<open>2\<close>
  23.473    additionally records full proof terms. Officially named theorems that
  23.474    contribute to a result are recorded in any case.
  23.475  
  23.476 -  \<^descr> @{ML Reconstruct.reconstruct_proof}~\<open>ctxt prop prf\<close> turns the implicit
  23.477 +  \<^descr> \<^ML>\<open>Reconstruct.reconstruct_proof\<close>~\<open>ctxt prop prf\<close> turns the implicit
  23.478    proof term \<open>prf\<close> into a full proof of the given proposition.
  23.479  
  23.480    Reconstruction may fail if \<open>prf\<close> is not a proof of \<open>prop\<close>, or if it does not
  23.481 @@ -1229,21 +1224,21 @@
  23.482    for proofs that are constructed manually, but not for those produced
  23.483    automatically by the inference kernel.
  23.484  
  23.485 -  \<^descr> @{ML Reconstruct.expand_proof}~\<open>ctxt [thm\<^sub>1, \<dots>, thm\<^sub>n] prf\<close> expands and
  23.486 +  \<^descr> \<^ML>\<open>Reconstruct.expand_proof\<close>~\<open>ctxt [thm\<^sub>1, \<dots>, thm\<^sub>n] prf\<close> expands and
  23.487    reconstructs the proofs of all specified theorems, with the given (full)
  23.488    proof. Theorems that are not unique specified via their name may be
  23.489    disambiguated by giving their proposition.
  23.490  
  23.491 -  \<^descr> @{ML Proof_Checker.thm_of_proof}~\<open>thy prf\<close> turns the given (full) proof
  23.492 +  \<^descr> \<^ML>\<open>Proof_Checker.thm_of_proof\<close>~\<open>thy prf\<close> turns the given (full) proof
  23.493    into a theorem, by replaying it using only primitive rules of the inference
  23.494    kernel.
  23.495  
  23.496 -  \<^descr> @{ML Proof_Syntax.read_proof}~\<open>thy b\<^sub>1 b\<^sub>2 s\<close> reads in a proof term. The
  23.497 +  \<^descr> \<^ML>\<open>Proof_Syntax.read_proof\<close>~\<open>thy b\<^sub>1 b\<^sub>2 s\<close> reads in a proof term. The
  23.498    Boolean flags indicate the use of sort and type information. Usually, typing
  23.499    information is left implicit and is inferred during proof reconstruction.
  23.500    %FIXME eliminate flags!?
  23.501  
  23.502 -  \<^descr> @{ML Proof_Syntax.pretty_proof}~\<open>ctxt prf\<close> pretty-prints the given proof
  23.503 +  \<^descr> \<^ML>\<open>Proof_Syntax.pretty_proof\<close>~\<open>ctxt prf\<close> pretty-prints the given proof
  23.504    term.
  23.505  \<close>
  23.506  
    24.1 --- a/src/Doc/Implementation/ML.thy	Sat Jan 05 17:00:43 2019 +0100
    24.2 +++ b/src/Doc/Implementation/ML.thy	Sat Jan 05 17:24:33 2019 +0100
    24.3 @@ -115,34 +115,32 @@
    24.4    \<^medskip>
    24.5    \begin{tabular}{lll}
    24.6    variant & example & ML categories \\\hline
    24.7 -  lower-case & @{ML_text foo_bar} & values, types, record fields \\
    24.8 -  capitalized & @{ML_text Foo_Bar} & datatype constructors, structures, functors \\
    24.9 -  upper-case & @{ML_text FOO_BAR} & special values, exception constructors, signatures \\
   24.10 +  lower-case & \<^ML_text>\<open>foo_bar\<close> & values, types, record fields \\
   24.11 +  capitalized & \<^ML_text>\<open>Foo_Bar\<close> & datatype constructors, structures, functors \\
   24.12 +  upper-case & \<^ML_text>\<open>FOO_BAR\<close> & special values, exception constructors, signatures \\
   24.13    \end{tabular}
   24.14    \<^medskip>
   24.15  
   24.16    For historical reasons, many capitalized names omit underscores, e.g.\
   24.17 -  old-style @{ML_text FooBar} instead of @{ML_text Foo_Bar}. Genuine
   24.18 +  old-style \<^ML_text>\<open>FooBar\<close> instead of \<^ML_text>\<open>Foo_Bar\<close>. Genuine
   24.19    mixed-case names are \<^emph>\<open>not\<close> used, because clear division of words is
   24.20    essential for readability.\<^footnote>\<open>Camel-case was invented to workaround the lack
   24.21    of underscore in some early non-ASCII character sets. Later it became
   24.22    habitual in some language communities that are now strong in numbers.\<close>
   24.23  
   24.24    A single (capital) character does not count as ``word'' in this respect:
   24.25 -  some Isabelle/ML names are suffixed by extra markers like this: @{ML_text
   24.26 -  foo_barT}.
   24.27 -
   24.28 -  Name variants are produced by adding 1--3 primes, e.g.\ @{ML_text foo'},
   24.29 -  @{ML_text foo''}, or @{ML_text foo'''}, but not @{ML_text foo''''} or more.
   24.30 -  Decimal digits scale better to larger numbers, e.g.\ @{ML_text foo0},
   24.31 -  @{ML_text foo1}, @{ML_text foo42}.
   24.32 +  some Isabelle/ML names are suffixed by extra markers like this: \<^ML_text>\<open>foo_barT\<close>.
   24.33 +
   24.34 +  Name variants are produced by adding 1--3 primes, e.g.\ \<^ML_text>\<open>foo'\<close>,
   24.35 +  \<^ML_text>\<open>foo''\<close>, or \<^ML_text>\<open>foo'''\<close>, but not \<^ML_text>\<open>foo''''\<close> or more.
   24.36 +  Decimal digits scale better to larger numbers, e.g.\ \<^ML_text>\<open>foo0\<close>,
   24.37 +  \<^ML_text>\<open>foo1\<close>, \<^ML_text>\<open>foo42\<close>.
   24.38  \<close>
   24.39  
   24.40  paragraph \<open>Scopes.\<close>
   24.41  text \<open>
   24.42    Apart from very basic library modules, ML structures are not ``opened'', but
   24.43 -  names are referenced with explicit qualification, as in @{ML
   24.44 -  Syntax.string_of_term} for example. When devising names for structures and
   24.45 +  names are referenced with explicit qualification, as in \<^ML>\<open>Syntax.string_of_term\<close> for example. When devising names for structures and
   24.46    their components it is important to aim at eye-catching compositions of both
   24.47    parts, because this is how they are seen in the sources and documentation.
   24.48    For the same reasons, aliases of well-known library functions should be
   24.49 @@ -150,8 +148,8 @@
   24.50  
   24.51    Local names of function abstraction or case/let bindings are typically
   24.52    shorter, sometimes using only rudiments of ``words'', while still avoiding
   24.53 -  cryptic shorthands. An auxiliary function called @{ML_text helper},
   24.54 -  @{ML_text aux}, or @{ML_text f} is considered bad style.
   24.55 +  cryptic shorthands. An auxiliary function called \<^ML_text>\<open>helper\<close>,
   24.56 +  \<^ML_text>\<open>aux\<close>, or \<^ML_text>\<open>f\<close> is considered bad style.
   24.57  
   24.58    Example:
   24.59  
   24.60 @@ -187,15 +185,13 @@
   24.61  text \<open>
   24.62    Here are some specific name forms that occur frequently in the sources.
   24.63  
   24.64 -  \<^item> A function that maps @{ML_text foo} to @{ML_text bar} is called @{ML_text
   24.65 -  foo_to_bar} or @{ML_text bar_of_foo} (never @{ML_text foo2bar}, nor
   24.66 -  @{ML_text bar_from_foo}, nor @{ML_text bar_for_foo}, nor @{ML_text
   24.67 -  bar4foo}).
   24.68 -
   24.69 -  \<^item> The name component @{ML_text legacy} means that the operation is about to
   24.70 +  \<^item> A function that maps \<^ML_text>\<open>foo\<close> to \<^ML_text>\<open>bar\<close> is called \<^ML_text>\<open>foo_to_bar\<close> or \<^ML_text>\<open>bar_of_foo\<close> (never \<^ML_text>\<open>foo2bar\<close>, nor
   24.71 +  \<^ML_text>\<open>bar_from_foo\<close>, nor \<^ML_text>\<open>bar_for_foo\<close>, nor \<^ML_text>\<open>bar4foo\<close>).
   24.72 +
   24.73 +  \<^item> The name component \<^ML_text>\<open>legacy\<close> means that the operation is about to
   24.74    be discontinued soon.
   24.75  
   24.76 -  \<^item> The name component @{ML_text global} means that this works with the
   24.77 +  \<^item> The name component \<^ML_text>\<open>global\<close> means that this works with the
   24.78    background theory instead of the regular local context
   24.79    (\secref{sec:context}), sometimes for historical reasons, sometimes due a
   24.80    genuine lack of locality of the concept involved, sometimes as a fall-back
   24.81 @@ -207,58 +203,57 @@
   24.82    (\secref{sec:context} and \chref{ch:local-theory}) have firm naming
   24.83    conventions as follows:
   24.84  
   24.85 -    \<^item> theories are called @{ML_text thy}, rarely @{ML_text theory}
   24.86 -    (never @{ML_text thry})
   24.87 -
   24.88 -    \<^item> proof contexts are called @{ML_text ctxt}, rarely @{ML_text
   24.89 -    context} (never @{ML_text ctx})
   24.90 -
   24.91 -    \<^item> generic contexts are called @{ML_text context}
   24.92 -
   24.93 -    \<^item> local theories are called @{ML_text lthy}, except for local
   24.94 +    \<^item> theories are called \<^ML_text>\<open>thy\<close>, rarely \<^ML_text>\<open>theory\<close>
   24.95 +    (never \<^ML_text>\<open>thry\<close>)
   24.96 +
   24.97 +    \<^item> proof contexts are called \<^ML_text>\<open>ctxt\<close>, rarely \<^ML_text>\<open>context\<close> (never \<^ML_text>\<open>ctx\<close>)
   24.98 +
   24.99 +    \<^item> generic contexts are called \<^ML_text>\<open>context\<close>
  24.100 +
  24.101 +    \<^item> local theories are called \<^ML_text>\<open>lthy\<close>, except for local
  24.102      theories that are treated as proof context (which is a semantic
  24.103      super-type)
  24.104  
  24.105    Variations with primed or decimal numbers are always possible, as well as
  24.106 -  semantic prefixes like @{ML_text foo_thy} or @{ML_text bar_ctxt}, but the
  24.107 +  semantic prefixes like \<^ML_text>\<open>foo_thy\<close> or \<^ML_text>\<open>bar_ctxt\<close>, but the
  24.108    base conventions above need to be preserved. This allows to emphasize their
  24.109    data flow via plain regular expressions in the text editor.
  24.110  
  24.111    \<^item> The main logical entities (\secref{ch:logic}) have established naming
  24.112    convention as follows:
  24.113  
  24.114 -    \<^item> sorts are called @{ML_text S}
  24.115 -
  24.116 -    \<^item> types are called @{ML_text T}, @{ML_text U}, or @{ML_text ty} (never
  24.117 -    @{ML_text t})
  24.118 -
  24.119 -    \<^item> terms are called @{ML_text t}, @{ML_text u}, or @{ML_text tm} (never
  24.120 -    @{ML_text trm})
  24.121 -
  24.122 -    \<^item> certified types are called @{ML_text cT}, rarely @{ML_text T}, with
  24.123 +    \<^item> sorts are called \<^ML_text>\<open>S\<close>
  24.124 +
  24.125 +    \<^item> types are called \<^ML_text>\<open>T\<close>, \<^ML_text>\<open>U\<close>, or \<^ML_text>\<open>ty\<close> (never
  24.126 +    \<^ML_text>\<open>t\<close>)
  24.127 +
  24.128 +    \<^item> terms are called \<^ML_text>\<open>t\<close>, \<^ML_text>\<open>u\<close>, or \<^ML_text>\<open>tm\<close> (never
  24.129 +    \<^ML_text>\<open>trm\<close>)
  24.130 +
  24.131 +    \<^item> certified types are called \<^ML_text>\<open>cT\<close>, rarely \<^ML_text>\<open>T\<close>, with
  24.132      variants as for types
  24.133  
  24.134 -    \<^item> certified terms are called @{ML_text ct}, rarely @{ML_text t}, with
  24.135 -    variants as for terms (never @{ML_text ctrm})
  24.136 -
  24.137 -    \<^item> theorems are called @{ML_text th}, or @{ML_text thm}
  24.138 +    \<^item> certified terms are called \<^ML_text>\<open>ct\<close>, rarely \<^ML_text>\<open>t\<close>, with
  24.139 +    variants as for terms (never \<^ML_text>\<open>ctrm\<close>)
  24.140 +
  24.141 +    \<^item> theorems are called \<^ML_text>\<open>th\<close>, or \<^ML_text>\<open>thm\<close>
  24.142  
  24.143    Proper semantic names override these conventions completely. For example,
  24.144 -  the left-hand side of an equation (as a term) can be called @{ML_text lhs}
  24.145 -  (not @{ML_text lhs_tm}). Or a term that is known to be a variable can be
  24.146 -  called @{ML_text v} or @{ML_text x}.
  24.147 +  the left-hand side of an equation (as a term) can be called \<^ML_text>\<open>lhs\<close>
  24.148 +  (not \<^ML_text>\<open>lhs_tm\<close>). Or a term that is known to be a variable can be
  24.149 +  called \<^ML_text>\<open>v\<close> or \<^ML_text>\<open>x\<close>.
  24.150  
  24.151    \<^item> Tactics (\secref{sec:tactics}) are sufficiently important to have specific
  24.152    naming conventions. The name of a basic tactic definition always has a
  24.153 -  @{ML_text "_tac"} suffix, the subgoal index (if applicable) is always called
  24.154 -  @{ML_text i}, and the goal state (if made explicit) is usually called
  24.155 -  @{ML_text st} instead of the somewhat misleading @{ML_text thm}. Any other
  24.156 +  \<^ML_text>\<open>_tac\<close> suffix, the subgoal index (if applicable) is always called
  24.157 +  \<^ML_text>\<open>i\<close>, and the goal state (if made explicit) is usually called
  24.158 +  \<^ML_text>\<open>st\<close> instead of the somewhat misleading \<^ML_text>\<open>thm\<close>. Any other
  24.159    arguments are given before the latter two, and the general context is given
  24.160    first. Example:
  24.161  
  24.162    @{verbatim [display] \<open>  fun my_tac ctxt arg1 arg2 i st = ...\<close>}
  24.163  
  24.164 -  Note that the goal state @{ML_text st} above is rarely made explicit, if
  24.165 +  Note that the goal state \<^ML_text>\<open>st\<close> above is rarely made explicit, if
  24.166    tactic combinators (tacticals) are used as usual.
  24.167  
  24.168    A tactic that requires a proof context needs to make that explicit as seen
  24.169 @@ -314,16 +309,16 @@
  24.170      c);
  24.171  \<close>}
  24.172  
  24.173 -  Some special infixes (e.g.\ @{ML_text "|>"}) work better at the start of the
  24.174 +  Some special infixes (e.g.\ \<^ML_text>\<open>|>\<close>) work better at the start of the
  24.175    line, but punctuation is always at the end.
  24.176  
  24.177    Function application follows the tradition of \<open>\<lambda>\<close>-calculus, not informal
  24.178 -  mathematics. For example: @{ML_text "f a b"} for a curried function, or
  24.179 -  @{ML_text "g (a, b)"} for a tupled function. Note that the space between
  24.180 -  @{ML_text g} and the pair @{ML_text "(a, b)"} follows the important
  24.181 -  principle of \<^emph>\<open>compositionality\<close>: the layout of @{ML_text "g p"} does not
  24.182 -  change when @{ML_text "p"} is refined to the concrete pair @{ML_text "(a,
  24.183 -  b)"}.
  24.184 +  mathematics. For example: \<^ML_text>\<open>f a b\<close> for a curried function, or
  24.185 +  \<^ML_text>\<open>g (a, b)\<close> for a tupled function. Note that the space between
  24.186 +  \<^ML_text>\<open>g\<close> and the pair \<^ML_text>\<open>(a, b)\<close> follows the important
  24.187 +  principle of \<^emph>\<open>compositionality\<close>: the layout of \<^ML_text>\<open>g p\<close> does not
  24.188 +  change when \<^ML_text>\<open>p\<close> is refined to the concrete pair \<^ML_text>\<open>(a,
  24.189 +  b)\<close>.
  24.190  \<close>
  24.191  
  24.192  paragraph \<open>Indentation\<close>
  24.193 @@ -372,13 +367,13 @@
  24.194  
  24.195  paragraph \<open>Complex expressions\<close>
  24.196  text \<open>
  24.197 -  that consist of multi-clausal function definitions, @{ML_text handle},
  24.198 -  @{ML_text case}, @{ML_text let} (and combinations) require special
  24.199 +  that consist of multi-clausal function definitions, \<^ML_text>\<open>handle\<close>,
  24.200 +  \<^ML_text>\<open>case\<close>, \<^ML_text>\<open>let\<close> (and combinations) require special
  24.201    attention. The syntax of Standard ML is quite ambitious and admits a lot of
  24.202    variance that can distort the meaning of the text.
  24.203  
  24.204 -  Multiple clauses of @{ML_text fun}, @{ML_text fn}, @{ML_text handle},
  24.205 -  @{ML_text case} get extra indentation to indicate the nesting clearly.
  24.206 +  Multiple clauses of \<^ML_text>\<open>fun\<close>, \<^ML_text>\<open>fn\<close>, \<^ML_text>\<open>handle\<close>,
  24.207 +  \<^ML_text>\<open>case\<close> get extra indentation to indicate the nesting clearly.
  24.208    Example:
  24.209  
  24.210    @{verbatim [display]
  24.211 @@ -397,7 +392,7 @@
  24.212      | foo p2 =
  24.213      expr2\<close>}
  24.214  
  24.215 -  Body expressions consisting of @{ML_text case} or @{ML_text let} require
  24.216 +  Body expressions consisting of \<^ML_text>\<open>case\<close> or \<^ML_text>\<open>let\<close> require
  24.217    care to maintain compositionality, to prevent loss of logical indentation
  24.218    where it is especially important to see the structure of the text. Example:
  24.219  
  24.220 @@ -428,14 +423,14 @@
  24.221        ...
  24.222      end\<close>}
  24.223  
  24.224 -  Extra parentheses around @{ML_text case} expressions are optional, but help
  24.225 +  Extra parentheses around \<^ML_text>\<open>case\<close> expressions are optional, but help
  24.226    to analyse the nesting based on character matching in the text editor.
  24.227  
  24.228    \<^medskip>
  24.229    There are two main exceptions to the overall principle of compositionality
  24.230    in the layout of complex expressions.
  24.231  
  24.232 -  \<^enum> @{ML_text "if"} expressions are iterated as if ML had multi-branch
  24.233 +  \<^enum> \<^ML_text>\<open>if\<close> expressions are iterated as if ML had multi-branch
  24.234    conditionals, e.g.
  24.235  
  24.236    @{verbatim [display]
  24.237 @@ -445,7 +440,7 @@
  24.238    else if b2 then e2
  24.239    else e3\<close>}
  24.240  
  24.241 -  \<^enum> @{ML_text fn} abstractions are often layed-out as if they would lack any
  24.242 +  \<^enum> \<^ML_text>\<open>fn\<close> abstractions are often layed-out as if they would lack any
  24.243    structure by themselves. This traditional form is motivated by the
  24.244    possibility to shift function arguments back and forth wrt.\ additional
  24.245    combinators. Example:
  24.246 @@ -456,12 +451,12 @@
  24.247    fun foo x y = fold (fn z =>
  24.248      expr)\<close>}
  24.249  
  24.250 -  Here the visual appearance is that of three arguments @{ML_text x},
  24.251 -  @{ML_text y}, @{ML_text z} in a row.
  24.252 +  Here the visual appearance is that of three arguments \<^ML_text>\<open>x\<close>,
  24.253 +  \<^ML_text>\<open>y\<close>, \<^ML_text>\<open>z\<close> in a row.
  24.254  
  24.255  
  24.256    Such weakly structured layout should be use with great care. Here are some
  24.257 -  counter-examples involving @{ML_text let} expressions:
  24.258 +  counter-examples involving \<^ML_text>\<open>let\<close> expressions:
  24.259  
  24.260    @{verbatim [display]
  24.261  \<open>  (* WRONG *)
  24.262 @@ -537,7 +532,7 @@
  24.263    more commands that refer to ML source, such as @{command_ref setup} or
  24.264    @{command_ref declaration}. Even more fine-grained embedding of ML into Isar
  24.265    is encountered in the proof method @{method_ref tactic}, which refines the
  24.266 -  pending goal state via a given expression of type @{ML_type tactic}.
  24.267 +  pending goal state via a given expression of type \<^ML_type>\<open>tactic\<close>.
  24.268  \<close>
  24.269  
  24.270  text %mlex \<open>
  24.271 @@ -552,8 +547,7 @@
  24.272  \<close>
  24.273  
  24.274  text \<open>
  24.275 -  Here the ML environment is already managed by Isabelle, i.e.\ the @{ML
  24.276 -  factorial} function is not yet accessible in the preceding paragraph, nor in
  24.277 +  Here the ML environment is already managed by Isabelle, i.e.\ the \<^ML>\<open>factorial\<close> function is not yet accessible in the preceding paragraph, nor in
  24.278    a different theory that is independent from the current one in the import
  24.279    hierarchy.
  24.280  
  24.281 @@ -589,8 +583,7 @@
  24.282    Two further ML commands are useful in certain situations: @{command_ref
  24.283    ML_val} and @{command_ref ML_command} are \<^emph>\<open>diagnostic\<close> in the sense that
  24.284    there is no effect on the underlying environment, and can thus be used
  24.285 -  anywhere. The examples below produce long strings of digits by invoking @{ML
  24.286 -  factorial}: @{command ML_val} takes care of printing the ML toplevel result,
  24.287 +  anywhere. The examples below produce long strings of digits by invoking \<^ML>\<open>factorial\<close>: @{command ML_val} takes care of printing the ML toplevel result,
  24.288    but @{command ML_command} is silent so we produce an explicit output
  24.289    message.
  24.290  \<close>
  24.291 @@ -624,19 +617,19 @@
  24.292    @{index_ML ML_Thms.bind_thm: "string * thm -> unit"} \\
  24.293    \end{mldecls}
  24.294  
  24.295 -    \<^descr> @{ML "Context.the_generic_context ()"} refers to the theory context of
  24.296 +    \<^descr> \<^ML>\<open>Context.the_generic_context ()\<close> refers to the theory context of
  24.297      the ML toplevel --- at compile time. ML code needs to take care to refer to
  24.298 -    @{ML "Context.the_generic_context ()"} correctly. Recall that evaluation
  24.299 +    \<^ML>\<open>Context.the_generic_context ()\<close> correctly. Recall that evaluation
  24.300      of a function body is delayed until actual run-time.
  24.301  
  24.302 -    \<^descr> @{ML "Context.>>"}~\<open>f\<close> applies context transformation \<open>f\<close> to the implicit
  24.303 +    \<^descr> \<^ML>\<open>Context.>>\<close>~\<open>f\<close> applies context transformation \<open>f\<close> to the implicit
  24.304      context of the ML toplevel.
  24.305  
  24.306 -    \<^descr> @{ML ML_Thms.bind_thms}~\<open>(name, thms)\<close> stores a list of theorems produced
  24.307 +    \<^descr> \<^ML>\<open>ML_Thms.bind_thms\<close>~\<open>(name, thms)\<close> stores a list of theorems produced
  24.308      in ML both in the (global) theory context and the ML toplevel, associating
  24.309      it with the provided name.
  24.310  
  24.311 -    \<^descr> @{ML ML_Thms.bind_thm} is similar to @{ML ML_Thms.bind_thms} but refers to
  24.312 +    \<^descr> \<^ML>\<open>ML_Thms.bind_thm\<close> is similar to \<^ML>\<open>ML_Thms.bind_thms\<close> but refers to
  24.313      a singleton fact.
  24.314  
  24.315    It is important to note that the above functions are really restricted to
  24.316 @@ -654,9 +647,9 @@
  24.317    \<^emph>\<open>ML antiquotation\<close>. The standard token language of ML is augmented by
  24.318    special syntactic entities of the following form:
  24.319  
  24.320 -  @{rail \<open>
  24.321 +  \<^rail>\<open>
  24.322    @{syntax_def antiquote}: '@{' name args '}'
  24.323 -  \<close>}
  24.324 +  \<close>
  24.325  
  24.326    Here @{syntax name} and @{syntax args} are outer syntax categories, as
  24.327    defined in @{cite "isabelle-isar-ref"}.
  24.328 @@ -692,11 +685,11 @@
  24.329    @{ML_antiquotation_def "print"} & : & \<open>ML_antiquotation\<close> \\
  24.330    \end{matharray}
  24.331  
  24.332 -  @{rail \<open>
  24.333 +  \<^rail>\<open>
  24.334    @@{ML_antiquotation make_string}
  24.335    ;
  24.336    @@{ML_antiquotation print} embedded?
  24.337 -  \<close>}
  24.338 +  \<close>
  24.339  
  24.340    \<^descr> \<open>@{make_string}\<close> inlines a function to print arbitrary values similar to
  24.341    the ML toplevel. The result is compiler dependent and may fall back on "?"
  24.342 @@ -705,7 +698,7 @@
  24.343  
  24.344    \<^descr> \<open>@{print f}\<close> uses the ML function \<open>f: string -> unit\<close> to output the result
  24.345    of \<open>@{make_string}\<close> above, together with the source position of the
  24.346 -  antiquotation. The default output function is @{ML writeln}.
  24.347 +  antiquotation. The default output function is \<^ML>\<open>writeln\<close>.
  24.348  \<close>
  24.349  
  24.350  text %mlex \<open>
  24.351 @@ -717,10 +710,10 @@
  24.352    val x = 42;
  24.353    val y = true;
  24.354  
  24.355 -  writeln (@{make_string} {x = x, y = y});
  24.356 -
  24.357 -  @{print} {x = x, y = y};
  24.358 -  @{print tracing} {x = x, y = y};
  24.359 +  writeln (\<^make_string> {x = x, y = y});
  24.360 +
  24.361 +  \<^print> {x = x, y = y};
  24.362 +  \<^print>\<open>tracing\<close> {x = x, y = y};
  24.363  \<close>
  24.364  
  24.365  
  24.366 @@ -865,23 +858,23 @@
  24.367    @{index_ML fold_map: "('a -> 'b -> 'c * 'b) -> 'a list -> 'b -> 'c list * 'b"} \\
  24.368    \end{mldecls}
  24.369  
  24.370 -  \<^descr> @{ML fold}~\<open>f\<close> lifts the parametrized update function \<open>f\<close> to a list of
  24.371 +  \<^descr> \<^ML>\<open>fold\<close>~\<open>f\<close> lifts the parametrized update function \<open>f\<close> to a list of
  24.372    parameters.
  24.373  
  24.374 -  \<^descr> @{ML fold_rev}~\<open>f\<close> is similar to @{ML fold}~\<open>f\<close>, but works inside-out, as
  24.375 +  \<^descr> \<^ML>\<open>fold_rev\<close>~\<open>f\<close> is similar to \<^ML>\<open>fold\<close>~\<open>f\<close>, but works inside-out, as
  24.376    if the list would be reversed.
  24.377  
  24.378 -  \<^descr> @{ML fold_map}~\<open>f\<close> lifts the parametrized update function \<open>f\<close> (with
  24.379 +  \<^descr> \<^ML>\<open>fold_map\<close>~\<open>f\<close> lifts the parametrized update function \<open>f\<close> (with
  24.380    side-result) to a list of parameters and cumulative side-results.
  24.381  
  24.382  
  24.383    \begin{warn}
  24.384    The literature on functional programming provides a confusing multitude of
  24.385    combinators called \<open>foldl\<close>, \<open>foldr\<close> etc. SML97 provides its own variations
  24.386 -  as @{ML List.foldl} and @{ML List.foldr}, while the classic Isabelle library
  24.387 -  also has the historic @{ML Library.foldl} and @{ML Library.foldr}. To avoid
  24.388 +  as \<^ML>\<open>List.foldl\<close> and \<^ML>\<open>List.foldr\<close>, while the classic Isabelle library
  24.389 +  also has the historic \<^ML>\<open>Library.foldl\<close> and \<^ML>\<open>Library.foldr\<close>. To avoid
  24.390    unnecessary complication, all these historical versions should be ignored,
  24.391 -  and the canonical @{ML fold} (or @{ML fold_rev}) used exclusively.
  24.392 +  and the canonical \<^ML>\<open>fold\<close> (or \<^ML>\<open>fold_rev\<close>) used exclusively.
  24.393    \end{warn}
  24.394  \<close>
  24.395  
  24.396 @@ -897,12 +890,11 @@
  24.397      |> fold (Buffer.add o string_of_int) (0 upto 9)
  24.398      |> Buffer.content;
  24.399  
  24.400 -  @{assert} (s = "digits: 0123456789");
  24.401 +  \<^assert> (s = "digits: 0123456789");
  24.402  \<close>
  24.403  
  24.404  text \<open>
  24.405 -  Note how @{ML "fold (Buffer.add o string_of_int)"} above saves an extra @{ML
  24.406 -  "map"} over the given list. This kind of peephole optimization reduces both
  24.407 +  Note how \<^ML>\<open>fold (Buffer.add o string_of_int)\<close> above saves an extra \<^ML>\<open>map\<close> over the given list. This kind of peephole optimization reduces both
  24.408    the code size and the tree structures in memory (``deforestation''), but it
  24.409    requires some practice to read and write fluently.
  24.410  
  24.411 @@ -931,28 +923,26 @@
  24.412  \<close>
  24.413  
  24.414  text \<open>
  24.415 -  The slowness of @{ML slow_content} is due to the @{ML implode} of the
  24.416 +  The slowness of \<^ML>\<open>slow_content\<close> is due to the \<^ML>\<open>implode\<close> of the
  24.417    recursive results, because it copies previously produced strings again and
  24.418    again.
  24.419  
  24.420 -  The incremental @{ML add_content} avoids this by operating on a buffer that
  24.421 -  is passed through in a linear fashion. Using @{ML_text "#>"} and contraction
  24.422 +  The incremental \<^ML>\<open>add_content\<close> avoids this by operating on a buffer that
  24.423 +  is passed through in a linear fashion. Using \<^ML_text>\<open>#>\<close> and contraction
  24.424    over the actual buffer argument saves some additional boiler-plate. Of
  24.425 -  course, the two @{ML "Buffer.add"} invocations with concatenated strings
  24.426 +  course, the two \<^ML>\<open>Buffer.add\<close> invocations with concatenated strings
  24.427    could have been split into smaller parts, but this would have obfuscated the
  24.428    source without making a big difference in performance. Here we have done
  24.429    some peephole-optimization for the sake of readability.
  24.430  
  24.431 -  Another benefit of @{ML add_content} is its ``open'' form as a function on
  24.432 +  Another benefit of \<^ML>\<open>add_content\<close> is its ``open'' form as a function on
  24.433    buffers that can be continued in further linear transformations, folding
  24.434 -  etc. Thus it is more compositional than the naive @{ML slow_content}. As
  24.435 +  etc. Thus it is more compositional than the naive \<^ML>\<open>slow_content\<close>. As
  24.436    realistic example, compare the old-style
  24.437 -  @{ML "Term.maxidx_of_term: term -> int"} with the newer @{ML
  24.438 -  "Term.maxidx_term: term -> int -> int"} in Isabelle/Pure.
  24.439 -
  24.440 -  Note that @{ML fast_content} above is only defined as example. In many
  24.441 -  practical situations, it is customary to provide the incremental @{ML
  24.442 -  add_content} only and leave the initialization and termination to the
  24.443 +  \<^ML>\<open>Term.maxidx_of_term: term -> int\<close> with the newer \<^ML>\<open>Term.maxidx_term: term -> int -> int\<close> in Isabelle/Pure.
  24.444 +
  24.445 +  Note that \<^ML>\<open>fast_content\<close> above is only defined as example. In many
  24.446 +  practical situations, it is customary to provide the incremental \<^ML>\<open>add_content\<close> only and leave the initialization and termination to the
  24.447    concrete application to the user.
  24.448  \<close>
  24.449  
  24.450 @@ -985,10 +975,10 @@
  24.451    @{index_ML error: "string -> 'a"} % FIXME Output.error_message (!?) \\
  24.452    \end{mldecls}
  24.453  
  24.454 -  \<^descr> @{ML writeln}~\<open>text\<close> outputs \<open>text\<close> as regular message. This is the
  24.455 +  \<^descr> \<^ML>\<open>writeln\<close>~\<open>text\<close> outputs \<open>text\<close> as regular message. This is the
  24.456    primary message output operation of Isabelle and should be used by default.
  24.457  
  24.458 -  \<^descr> @{ML tracing}~\<open>text\<close> outputs \<open>text\<close> as special tracing message, indicating
  24.459 +  \<^descr> \<^ML>\<open>tracing\<close>~\<open>text\<close> outputs \<open>text\<close> as special tracing message, indicating
  24.460    potential high-volume output to the front-end (hundreds or thousands of
  24.461    messages issued by a single command). The idea is to allow the
  24.462    user-interface to downgrade the quality of message display to achieve higher
  24.463 @@ -998,27 +988,26 @@
  24.464    e.g.\ switch to a different output window. So this channel should not be
  24.465    used for regular output.
  24.466  
  24.467 -  \<^descr> @{ML warning}~\<open>text\<close> outputs \<open>text\<close> as warning, which typically means some
  24.468 +  \<^descr> \<^ML>\<open>warning\<close>~\<open>text\<close> outputs \<open>text\<close> as warning, which typically means some
  24.469    extra emphasis on the front-end side (color highlighting, icons, etc.).
  24.470  
  24.471 -  \<^descr> @{ML error}~\<open>text\<close> raises exception @{ML ERROR}~\<open>text\<close> and thus lets the
  24.472 +  \<^descr> \<^ML>\<open>error\<close>~\<open>text\<close> raises exception \<^ML>\<open>ERROR\<close>~\<open>text\<close> and thus lets the
  24.473    Isar toplevel print \<open>text\<close> on the error channel, which typically means some
  24.474    extra emphasis on the front-end side (color highlighting, icons, etc.).
  24.475  
  24.476    This assumes that the exception is not handled before the command
  24.477 -  terminates. Handling exception @{ML ERROR}~\<open>text\<close> is a perfectly legal
  24.478 +  terminates. Handling exception \<^ML>\<open>ERROR\<close>~\<open>text\<close> is a perfectly legal
  24.479    alternative: it means that the error is absorbed without any message output.
  24.480  
  24.481    \begin{warn}
  24.482 -  The actual error channel is accessed via @{ML Output.error_message}, but
  24.483 +  The actual error channel is accessed via \<^ML>\<open>Output.error_message\<close>, but
  24.484    this is normally not used directly in user code.
  24.485    \end{warn}
  24.486  
  24.487  
  24.488    \begin{warn}
  24.489    Regular Isabelle/ML code should output messages exclusively by the official
  24.490 -  channels. Using raw I/O on \<^emph>\<open>stdout\<close> or \<^emph>\<open>stderr\<close> instead (e.g.\ via @{ML
  24.491 -  TextIO.output}) is apt to cause problems in the presence of parallel and
  24.492 +  channels. Using raw I/O on \<^emph>\<open>stdout\<close> or \<^emph>\<open>stderr\<close> instead (e.g.\ via \<^ML>\<open>TextIO.output\<close>) is apt to cause problems in the presence of parallel and
  24.493    asynchronous processing of Isabelle theories. Such raw output might be
  24.494    displayed by the front-end in some system console log, with a low chance
  24.495    that the user will ever see it. Moreover, as a genuine side-effect on global
  24.496 @@ -1029,7 +1018,7 @@
  24.497    \begin{warn}
  24.498    The message channels should be used in a message-oriented manner. This means
  24.499    that multi-line output that logically belongs together is issued by a single
  24.500 -  invocation of @{ML writeln} etc.\ with the functional concatenation of all
  24.501 +  invocation of \<^ML>\<open>writeln\<close> etc.\ with the functional concatenation of all
  24.502    message constituents.
  24.503    \end{warn}
  24.504  \<close>
  24.505 @@ -1081,11 +1070,11 @@
  24.506  text \<open>
  24.507    These are meant to provide informative feedback about malformed input etc.
  24.508  
  24.509 -  The \<^emph>\<open>error\<close> function raises the corresponding @{ML ERROR} exception, with a
  24.510 -  plain text message as argument. @{ML ERROR} exceptions can be handled
  24.511 +  The \<^emph>\<open>error\<close> function raises the corresponding \<^ML>\<open>ERROR\<close> exception, with a
  24.512 +  plain text message as argument. \<^ML>\<open>ERROR\<close> exceptions can be handled
  24.513    internally, in order to be ignored, turned into other exceptions, or
  24.514    cascaded by appending messages. If the corresponding Isabelle/Isar command
  24.515 -  terminates with an @{ML ERROR} exception state, the system will print the
  24.516 +  terminates with an \<^ML>\<open>ERROR\<close> exception state, the system will print the
  24.517    result on the error channel (see \secref{sec:message-channels}).
  24.518  
  24.519    It is considered bad style to refer to internal function names or values in
  24.520 @@ -1109,7 +1098,7 @@
  24.521    purpose is to determine quickly what has happened where. Traditionally, the
  24.522    (short) exception message would include the name of an ML function, although
  24.523    this is no longer necessary, because the ML runtime system attaches detailed
  24.524 -  source position stemming from the corresponding @{ML_text raise} keyword.
  24.525 +  source position stemming from the corresponding \<^ML_text>\<open>raise\<close> keyword.
  24.526  
  24.527    \<^medskip>
  24.528    User modules can always introduce their own custom exceptions locally, e.g.\
  24.529 @@ -1123,7 +1112,7 @@
  24.530  text \<open>
  24.531    These indicate arbitrary system events: both the ML runtime system and the
  24.532    Isabelle/ML infrastructure signal various exceptional situations by raising
  24.533 -  the special @{ML Exn.Interrupt} exception in user code.
  24.534 +  the special \<^ML>\<open>Exn.Interrupt\<close> exception in user code.
  24.535  
  24.536    This is the one and only way that physical events can intrude an Isabelle/ML
  24.537    program. Such an interrupt can mean out-of-memory, stack overflow, timeout,
  24.538 @@ -1160,32 +1149,32 @@
  24.539    @{index_ML Runtime.exn_trace: "(unit -> 'a) -> 'a"} \\
  24.540    \end{mldecls}
  24.541  
  24.542 -  \<^descr> @{ML try}~\<open>f x\<close> makes the partiality of evaluating \<open>f x\<close> explicit via the
  24.543 +  \<^descr> \<^ML>\<open>try\<close>~\<open>f x\<close> makes the partiality of evaluating \<open>f x\<close> explicit via the
  24.544    option datatype. Interrupts are \<^emph>\<open>not\<close> handled here, i.e.\ this form serves
  24.545 -  as safe replacement for the \<^emph>\<open>unsafe\<close> version @{ML_text "(SOME"}~\<open>f
  24.546 -  x\<close>~@{ML_text "handle _ => NONE)"} that is occasionally seen in books about
  24.547 +  as safe replacement for the \<^emph>\<open>unsafe\<close> version \<^ML_text>\<open>(SOME\<close>~\<open>f
  24.548 +  x\<close>~\<^ML_text>\<open>handle _ => NONE)\<close> that is occasionally seen in books about
  24.549    SML97, but not in Isabelle/ML.
  24.550  
  24.551 -  \<^descr> @{ML can} is similar to @{ML try} with more abstract result.
  24.552 -
  24.553 -  \<^descr> @{ML ERROR}~\<open>msg\<close> represents user errors; this exception is normally
  24.554 -  raised indirectly via the @{ML error} function (see
  24.555 +  \<^descr> \<^ML>\<open>can\<close> is similar to \<^ML>\<open>try\<close> with more abstract result.
  24.556 +
  24.557 +  \<^descr> \<^ML>\<open>ERROR\<close>~\<open>msg\<close> represents user errors; this exception is normally
  24.558 +  raised indirectly via the \<^ML>\<open>error\<close> function (see
  24.559    \secref{sec:message-channels}).
  24.560  
  24.561 -  \<^descr> @{ML Fail}~\<open>msg\<close> represents general program failures.
  24.562 -
  24.563 -  \<^descr> @{ML Exn.is_interrupt} identifies interrupts robustly, without mentioning
  24.564 +  \<^descr> \<^ML>\<open>Fail\<close>~\<open>msg\<close> represents general program failures.
  24.565 +
  24.566 +  \<^descr> \<^ML>\<open>Exn.is_interrupt\<close> identifies interrupts robustly, without mentioning
  24.567    concrete exception constructors in user code. Handled interrupts need to be
  24.568    re-raised promptly!
  24.569  
  24.570 -  \<^descr> @{ML Exn.reraise}~\<open>exn\<close> raises exception \<open>exn\<close> while preserving its implicit
  24.571 +  \<^descr> \<^ML>\<open>Exn.reraise\<close>~\<open>exn\<close> raises exception \<open>exn\<close> while preserving its implicit
  24.572    position information (if possible, depending on the ML platform).
  24.573  
  24.574 -  \<^descr> @{ML Runtime.exn_trace}~@{ML_text "(fn () =>"}~\<open>e\<close>@{ML_text ")"} evaluates
  24.575 +  \<^descr> \<^ML>\<open>Runtime.exn_trace\<close>~\<^ML_text>\<open>(fn () =>\<close>~\<open>e\<close>\<^ML_text>\<open>)\<close> evaluates
  24.576    expression \<open>e\<close> while printing a full trace of its stack of nested exceptions
  24.577    (if possible, depending on the ML platform).
  24.578  
  24.579 -  Inserting @{ML Runtime.exn_trace} into ML code temporarily is useful for
  24.580 +  Inserting \<^ML>\<open>Runtime.exn_trace\<close> into ML code temporarily is useful for
  24.581    debugging, but not suitable for production code.
  24.582  \<close>
  24.583  
  24.584 @@ -1195,16 +1184,15 @@
  24.585    @{ML_antiquotation_def "undefined"} & : & \<open>ML_antiquotation\<close> \\
  24.586    \end{matharray}
  24.587  
  24.588 -  \<^descr> \<open>@{assert}\<close> inlines a function @{ML_type "bool -> unit"} that raises @{ML
  24.589 -  Fail} if the argument is @{ML false}. Due to inlining the source position of
  24.590 +  \<^descr> \<open>@{assert}\<close> inlines a function \<^ML_type>\<open>bool -> unit\<close> that raises \<^ML>\<open>Fail\<close> if the argument is \<^ML>\<open>false\<close>. Due to inlining the source position of
  24.591    failed assertions is included in the error output.
  24.592  
  24.593 -  \<^descr> \<open>@{undefined}\<close> inlines @{verbatim raise}~@{ML Match}, i.e.\ the ML program
  24.594 +  \<^descr> \<open>@{undefined}\<close> inlines \<^verbatim>\<open>raise\<close>~\<^ML>\<open>Match\<close>, i.e.\ the ML program
  24.595    behaves as in some function application of an undefined case.
  24.596  \<close>
  24.597  
  24.598  text %mlex \<open>
  24.599 -  The ML function @{ML undefined} is defined in \<^file>\<open>~~/src/Pure/library.ML\<close>
  24.600 +  The ML function \<^ML>\<open>undefined\<close> is defined in \<^file>\<open>~~/src/Pure/library.ML\<close>
  24.601    as follows:
  24.602  \<close>
  24.603  
  24.604 @@ -1216,7 +1204,7 @@
  24.605    instead:
  24.606  \<close>
  24.607  
  24.608 -ML \<open>fun undefined _ = @{undefined}\<close>
  24.609 +ML \<open>fun undefined _ = \<^undefined>\<close>
  24.610  
  24.611  text \<open>
  24.612    \<^medskip>
  24.613 @@ -1284,33 +1272,30 @@
  24.614    @{index_ML Symbol.decode: "Symbol.symbol -> Symbol.sym"} \\
  24.615    \end{mldecls}
  24.616  
  24.617 -  \<^descr> Type @{ML_type "Symbol.symbol"} represents individual Isabelle symbols.
  24.618 -
  24.619 -  \<^descr> @{ML "Symbol.explode"}~\<open>str\<close> produces a symbol list from the packed form.
  24.620 -  This function supersedes @{ML "String.explode"} for virtually all purposes
  24.621 +  \<^descr> Type \<^ML_type>\<open>Symbol.symbol\<close> represents individual Isabelle symbols.
  24.622 +
  24.623 +  \<^descr> \<^ML>\<open>Symbol.explode\<close>~\<open>str\<close> produces a symbol list from the packed form.
  24.624 +  This function supersedes \<^ML>\<open>String.explode\<close> for virtually all purposes
  24.625    of manipulating text in Isabelle!\<^footnote>\<open>The runtime overhead for exploded strings
  24.626    is mainly that of the list structure: individual symbols that happen to be a
  24.627    singleton string do not require extra memory in Poly/ML.\<close>
  24.628  
  24.629 -  \<^descr> @{ML "Symbol.is_letter"}, @{ML "Symbol.is_digit"}, @{ML
  24.630 -  "Symbol.is_quasi"}, @{ML "Symbol.is_blank"} classify standard symbols
  24.631 +  \<^descr> \<^ML>\<open>Symbol.is_letter\<close>, \<^ML>\<open>Symbol.is_digit\<close>, \<^ML>\<open>Symbol.is_quasi\<close>, \<^ML>\<open>Symbol.is_blank\<close> classify standard symbols
  24.632    according to fixed syntactic conventions of Isabelle, cf.\ @{cite
  24.633    "isabelle-isar-ref"}.
  24.634  
  24.635 -  \<^descr> Type @{ML_type "Symbol.sym"} is a concrete datatype that represents the
  24.636 -  different kinds of symbols explicitly, with constructors @{ML
  24.637 -  "Symbol.Char"}, @{ML "Symbol.UTF8"}, @{ML "Symbol.Sym"}, @{ML
  24.638 -  "Symbol.Control"}, @{ML "Symbol.Malformed"}.
  24.639 -
  24.640 -  \<^descr> @{ML "Symbol.decode"} converts the string representation of a symbol into
  24.641 +  \<^descr> Type \<^ML_type>\<open>Symbol.sym\<close> is a concrete datatype that represents the
  24.642 +  different kinds of symbols explicitly, with constructors \<^ML>\<open>Symbol.Char\<close>, \<^ML>\<open>Symbol.UTF8\<close>, \<^ML>\<open>Symbol.Sym\<close>, \<^ML>\<open>Symbol.Control\<close>, \<^ML>\<open>Symbol.Malformed\<close>.
  24.643 +
  24.644 +  \<^descr> \<^ML>\<open>Symbol.decode\<close> converts the string representation of a symbol into
  24.645    the datatype version.
  24.646  \<close>
  24.647  
  24.648  paragraph \<open>Historical note.\<close>
  24.649  text \<open>
  24.650 -  In the original SML90 standard the primitive ML type @{ML_type char} did not
  24.651 -  exists, and @{ML_text "explode: string -> string list"} produced a list of
  24.652 -  singleton strings like @{ML "raw_explode: string -> string list"} in
  24.653 +  In the original SML90 standard the primitive ML type \<^ML_type>\<open>char\<close> did not
  24.654 +  exists, and \<^ML_text>\<open>explode: string -> string list\<close> produced a list of
  24.655 +  singleton strings like \<^ML>\<open>raw_explode: string -> string list\<close> in
  24.656    Isabelle/ML today. When SML97 came out, Isabelle did not adopt its somewhat
  24.657    anachronistic 8-bit or 16-bit characters, but the idea of exploding a string
  24.658    into a list of small strings was extended to ``symbols'' as explained above.
  24.659 @@ -1327,8 +1312,7 @@
  24.660    of its operations simply do not fit with important Isabelle/ML conventions
  24.661    (like ``canonical argument order'', see
  24.662    \secref{sec:canonical-argument-order}), others cause problems with the
  24.663 -  parallel evaluation model of Isabelle/ML (such as @{ML TextIO.print} or @{ML
  24.664 -  OS.Process.system}).
  24.665 +  parallel evaluation model of Isabelle/ML (such as \<^ML>\<open>TextIO.print\<close> or \<^ML>\<open>OS.Process.system\<close>).
  24.666  
  24.667    Subsequently we give a brief overview of important operations on basic ML
  24.668    data types.
  24.669 @@ -1342,7 +1326,7 @@
  24.670    @{index_ML_type char} \\
  24.671    \end{mldecls}
  24.672  
  24.673 -  \<^descr> Type @{ML_type char} is \<^emph>\<open>not\<close> used. The smallest textual unit in Isabelle
  24.674 +  \<^descr> Type \<^ML_type>\<open>char\<close> is \<^emph>\<open>not\<close> used. The smallest textual unit in Isabelle
  24.675    is represented as a ``symbol'' (see \secref{sec:symbols}).
  24.676  \<close>
  24.677  
  24.678 @@ -1354,7 +1338,7 @@
  24.679    @{index_ML_type string} \\
  24.680    \end{mldecls}
  24.681  
  24.682 -  \<^descr> Type @{ML_type string} represents immutable vectors of 8-bit characters.
  24.683 +  \<^descr> Type \<^ML_type>\<open>string\<close> represents immutable vectors of 8-bit characters.
  24.684    There are operations in SML to convert back and forth to actual byte
  24.685    vectors, which are seldom used.
  24.686  
  24.687 @@ -1362,11 +1346,10 @@
  24.688    Isabelle-specific purposes with the following implicit substructures packed
  24.689    into the string content:
  24.690  
  24.691 -    \<^enum> sequence of Isabelle symbols (see also \secref{sec:symbols}), with @{ML
  24.692 -    Symbol.explode} as key operation;
  24.693 +    \<^enum> sequence of Isabelle symbols (see also \secref{sec:symbols}), with \<^ML>\<open>Symbol.explode\<close> as key operation;
  24.694    
  24.695      \<^enum> XML tree structure via YXML (see also @{cite "isabelle-system"}), with
  24.696 -    @{ML YXML.parse_body} as key operation.
  24.697 +    \<^ML>\<open>YXML.parse_body\<close> as key operation.
  24.698  
  24.699    Note that Isabelle/ML string literals may refer Isabelle symbols like
  24.700    ``\<^verbatim>\<open>\<alpha>\<close>'' natively, \<^emph>\<open>without\<close> escaping the backslash. This is a consequence
  24.701 @@ -1382,8 +1365,8 @@
  24.702  ML_val \<open>
  24.703    val s = "\<A>";
  24.704  
  24.705 -  @{assert} (length (Symbol.explode s) = 1);
  24.706 -  @{assert} (size s = 4);
  24.707 +  \<^assert> (length (Symbol.explode s) = 1);
  24.708 +  \<^assert> (size s = 4);
  24.709  \<close>
  24.710  
  24.711  text \<open>
  24.712 @@ -1403,13 +1386,13 @@
  24.713    @{index_ML_type int} \\
  24.714    \end{mldecls}
  24.715  
  24.716 -  \<^descr> Type @{ML_type int} represents regular mathematical integers, which are
  24.717 +  \<^descr> Type \<^ML_type>\<open>int\<close> represents regular mathematical integers, which are
  24.718    \<^emph>\<open>unbounded\<close>. Overflow is treated properly, but should never happen in
  24.719    practice.\<^footnote>\<open>The size limit for integer bit patterns in memory is 64\,MB for
  24.720    32-bit Poly/ML, and much higher for 64-bit systems.\<close>
  24.721  
  24.722 -  Structure @{ML_structure IntInf} of SML97 is obsolete and superseded by
  24.723 -  @{ML_structure Int}. Structure @{ML_structure Integer} in
  24.724 +  Structure \<^ML_structure>\<open>IntInf\<close> of SML97 is obsolete and superseded by
  24.725 +  \<^ML_structure>\<open>Int\<close>. Structure \<^ML_structure>\<open>Integer\<close> in
  24.726    \<^file>\<open>~~/src/Pure/General/integer.ML\<close> provides some additional operations.
  24.727  \<close>
  24.728  
  24.729 @@ -1421,7 +1404,7 @@
  24.730    @{index_ML_type Rat.rat} \\
  24.731    \end{mldecls}
  24.732  
  24.733 -  \<^descr> Type @{ML_type Rat.rat} represents rational numbers, based on the
  24.734 +  \<^descr> Type \<^ML_type>\<open>Rat.rat\<close> represents rational numbers, based on the
  24.735    unbounded integers of Poly/ML.
  24.736  
  24.737    Literal rationals may be written with special antiquotation syntax
  24.738 @@ -1441,11 +1424,11 @@
  24.739    @{index_ML seconds: "real -> Time.time"} \\
  24.740    \end{mldecls}
  24.741  
  24.742 -  \<^descr> Type @{ML_type Time.time} represents time abstractly according to the
  24.743 +  \<^descr> Type \<^ML_type>\<open>Time.time\<close> represents time abstractly according to the
  24.744    SML97 basis library definition. This is adequate for internal ML operations,
  24.745    but awkward in concrete time specifications.
  24.746  
  24.747 -  \<^descr> @{ML seconds}~\<open>s\<close> turns the concrete scalar \<open>s\<close> (measured in seconds) into
  24.748 +  \<^descr> \<^ML>\<open>seconds\<close>~\<open>s\<close> turns the concrete scalar \<open>s\<close> (measured in seconds) into
  24.749    an abstract time value. Floating point numbers are easy to use as
  24.750    configuration options in the context (see \secref{sec:config-options}) or
  24.751    system options that are maintained externally.
  24.752 @@ -1467,8 +1450,8 @@
  24.753  \<close>
  24.754  
  24.755  text \<open>
  24.756 -  Apart from @{ML Option.map} most other operations defined in structure
  24.757 -  @{ML_structure Option} are alien to Isabelle/ML and never used. The
  24.758 +  Apart from \<^ML>\<open>Option.map\<close> most other operations defined in structure
  24.759 +  \<^ML_structure>\<open>Option\<close> are alien to Isabelle/ML and never used. The
  24.760    operations shown above are defined in \<^file>\<open>~~/src/Pure/General/basics.ML\<close>.
  24.761  \<close>
  24.762  
  24.763 @@ -1490,29 +1473,29 @@
  24.764    @{index_ML update: "('a * 'a -> bool) -> 'a -> 'a list -> 'a list"} \\
  24.765    \end{mldecls}
  24.766  
  24.767 -  \<^descr> @{ML cons}~\<open>x xs\<close> evaluates to \<open>x :: xs\<close>.
  24.768 +  \<^descr> \<^ML>\<open>cons\<close>~\<open>x xs\<close> evaluates to \<open>x :: xs\<close>.
  24.769  
  24.770    Tupled infix operators are a historical accident in Standard ML. The curried
  24.771 -  @{ML cons} amends this, but it should be only used when partial application
  24.772 +  \<^ML>\<open>cons\<close> amends this, but it should be only used when partial application
  24.773    is required.
  24.774  
  24.775 -  \<^descr> @{ML member}, @{ML insert}, @{ML remove}, @{ML update} treat lists as a
  24.776 +  \<^descr> \<^ML>\<open>member\<close>, \<^ML>\<open>insert\<close>, \<^ML>\<open>remove\<close>, \<^ML>\<open>update\<close> treat lists as a
  24.777    set-like container that maintains the order of elements. See
  24.778    \<^file>\<open>~~/src/Pure/library.ML\<close> for the full specifications (written in ML).
  24.779 -  There are some further derived operations like @{ML union} or @{ML inter}.
  24.780 -
  24.781 -  Note that @{ML insert} is conservative about elements that are already a
  24.782 -  @{ML member} of the list, while @{ML update} ensures that the latest entry
  24.783 +  There are some further derived operations like \<^ML>\<open>union\<close> or \<^ML>\<open>inter\<close>.
  24.784 +
  24.785 +  Note that \<^ML>\<open>insert\<close> is conservative about elements that are already a
  24.786 +  \<^ML>\<open>member\<close> of the list, while \<^ML>\<open>update\<close> ensures that the latest entry
  24.787    is always put in front. The latter discipline is often more appropriate in
  24.788    declarations of context data (\secref{sec:context-data}) that are issued by
  24.789    the user in Isar source: later declarations take precedence over earlier
  24.790    ones. \<close>
  24.791  
  24.792  text %mlex \<open>
  24.793 -  Using canonical @{ML fold} together with @{ML cons} (or similar standard
  24.794 +  Using canonical \<^ML>\<open>fold\<close> together with \<^ML>\<open>cons\<close> (or similar standard
  24.795    operations) alternates the orientation of data. The is quite natural and
  24.796 -  should not be altered forcible by inserting extra applications of @{ML rev}.
  24.797 -  The alternative @{ML fold_rev} can be used in the few situations, where
  24.798 +  should not be altered forcible by inserting extra applications of \<^ML>\<open>rev\<close>.
  24.799 +  The alternative \<^ML>\<open>fold_rev\<close> can be used in the few situations, where
  24.800    alternation should be prevented.
  24.801  \<close>
  24.802  
  24.803 @@ -1520,10 +1503,10 @@
  24.804    val items = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
  24.805  
  24.806    val list1 = fold cons items [];
  24.807 -  @{assert} (list1 = rev items);
  24.808 +  \<^assert> (list1 = rev items);
  24.809  
  24.810    val list2 = fold_rev cons items [];
  24.811 -  @{assert} (list2 = items);
  24.812 +  \<^assert> (list2 = items);
  24.813  \<close>
  24.814  
  24.815  text \<open>
  24.816 @@ -1537,11 +1520,10 @@
  24.817  
  24.818  text \<open>
  24.819    Here the first list is treated conservatively: only the new elements from
  24.820 -  the second list are inserted. The inside-out order of insertion via @{ML
  24.821 -  fold_rev} attempts to preserve the order of elements in the result.
  24.822 +  the second list are inserted. The inside-out order of insertion via \<^ML>\<open>fold_rev\<close> attempts to preserve the order of elements in the result.
  24.823  
  24.824    This way of merging lists is typical for context data
  24.825 -  (\secref{sec:context-data}). See also @{ML merge} as defined in
  24.826 +  (\secref{sec:context-data}). See also \<^ML>\<open>merge\<close> as defined in
  24.827    \<^file>\<open>~~/src/Pure/library.ML\<close>.
  24.828  \<close>
  24.829  
  24.830 @@ -1562,7 +1544,7 @@
  24.831    @{index_ML AList.update: "('a * 'a -> bool) -> 'a * 'b -> ('a * 'b) list -> ('a * 'b) list"} \\
  24.832    \end{mldecls}
  24.833  
  24.834 -  \<^descr> @{ML AList.lookup}, @{ML AList.defined}, @{ML AList.update} implement the
  24.835 +  \<^descr> \<^ML>\<open>AList.lookup\<close>, \<^ML>\<open>AList.defined\<close>, \<^ML>\<open>AList.update\<close> implement the
  24.836    main ``framework operations'' for mappings in Isabelle/ML, following
  24.837    standard conventions for their names and types.
  24.838  
  24.839 @@ -1570,7 +1552,7 @@
  24.840    via an explicit option element. There is no choice to raise an exception,
  24.841    without changing the name to something like \<open>the_element\<close> or \<open>get\<close>.
  24.842  
  24.843 -  The \<open>defined\<close> operation is essentially a contraction of @{ML is_some} and
  24.844 +  The \<open>defined\<close> operation is essentially a contraction of \<^ML>\<open>is_some\<close> and
  24.845    \<^verbatim>\<open>lookup\<close>, but this is sufficiently frequent to justify its independent
  24.846    existence. This also gives the implementation some opportunity for peep-hole
  24.847    optimization.
  24.848 @@ -1600,15 +1582,15 @@
  24.849    are notorious for causing problems. In a highly parallel system, both
  24.850    correctness \<^emph>\<open>and\<close> performance are easily degraded when using mutable data.
  24.851  
  24.852 -  The unwieldy name of @{ML Unsynchronized.ref} for the constructor for
  24.853 +  The unwieldy name of \<^ML>\<open>Unsynchronized.ref\<close> for the constructor for
  24.854    references in Isabelle/ML emphasizes the inconveniences caused by
  24.855 -  mutability. Existing operations @{ML "!"} and @{ML_op ":="} are unchanged,
  24.856 +  mutability. Existing operations \<^ML>\<open>!\<close> and \<^ML_op>\<open>:=\<close> are unchanged,
  24.857    but should be used with special precautions, say in a strictly local
  24.858    situation that is guaranteed to be restricted to sequential evaluation ---
  24.859    now and in the future.
  24.860  
  24.861    \begin{warn}
  24.862 -  Never @{ML_text "open Unsynchronized"}, not even in a local scope!
  24.863 +  Never \<^ML_text>\<open>open Unsynchronized\<close>, not even in a local scope!
  24.864    Pretending that mutable state is no problem is a very bad idea.
  24.865    \end{warn}
  24.866  \<close>
  24.867 @@ -1746,10 +1728,10 @@
  24.868    @{index_ML serial_string: "unit -> string"} \\
  24.869    \end{mldecls}
  24.870  
  24.871 -  \<^descr> @{ML File.tmp_path}~\<open>path\<close> relocates the base component of \<open>path\<close> into the
  24.872 +  \<^descr> \<^ML>\<open>File.tmp_path\<close>~\<open>path\<close> relocates the base component of \<open>path\<close> into the
  24.873    unique temporary directory of the running Isabelle/ML process.
  24.874  
  24.875 -  \<^descr> @{ML serial_string}~\<open>()\<close> creates a new serial number that is unique over
  24.876 +  \<^descr> \<^ML>\<open>serial_string\<close>~\<open>()\<close> creates a new serial number that is unique over
  24.877    the runtime of the Isabelle/ML process.
  24.878  \<close>
  24.879  
  24.880 @@ -1760,7 +1742,7 @@
  24.881  ML_val \<open>
  24.882    val tmp1 = File.tmp_path (Path.basic ("foo" ^ serial_string ()));
  24.883    val tmp2 = File.tmp_path (Path.basic ("foo" ^ serial_string ()));
  24.884 -  @{assert} (tmp1 <> tmp2);
  24.885 +  \<^assert> (tmp1 <> tmp2);
  24.886  \<close>
  24.887  
  24.888  
  24.889 @@ -1790,21 +1772,21 @@
  24.890    ('a -> ('b * 'a) option) -> 'b"} \\
  24.891    \end{mldecls}
  24.892  
  24.893 -    \<^descr> Type @{ML_type "'a Synchronized.var"} represents synchronized variables
  24.894 -    with state of type @{ML_type 'a}.
  24.895 -
  24.896 -    \<^descr> @{ML Synchronized.var}~\<open>name x\<close> creates a synchronized variable that is
  24.897 +    \<^descr> Type \<^ML_type>\<open>'a Synchronized.var\<close> represents synchronized variables
  24.898 +    with state of type \<^ML_type>\<open>'a\<close>.
  24.899 +
  24.900 +    \<^descr> \<^ML>\<open>Synchronized.var\<close>~\<open>name x\<close> creates a synchronized variable that is
  24.901      initialized with value \<open>x\<close>. The \<open>name\<close> is used for tracing.
  24.902  
  24.903 -    \<^descr> @{ML Synchronized.guarded_access}~\<open>var f\<close> lets the function \<open>f\<close> operate
  24.904 +    \<^descr> \<^ML>\<open>Synchronized.guarded_access\<close>~\<open>var f\<close> lets the function \<open>f\<close> operate
  24.905      within a critical section on the state \<open>x\<close> as follows: if \<open>f x\<close> produces
  24.906 -    @{ML NONE}, it continues to wait on the internal condition variable,
  24.907 +    \<^ML>\<open>NONE\<close>, it continues to wait on the internal condition variable,
  24.908      expecting that some other thread will eventually change the content in a
  24.909 -    suitable manner; if \<open>f x\<close> produces @{ML SOME}~\<open>(y, x')\<close> it is satisfied and
  24.910 +    suitable manner; if \<open>f x\<close> produces \<^ML>\<open>SOME\<close>~\<open>(y, x')\<close> it is satisfied and
  24.911      assigns the new state value \<open>x'\<close>, broadcasts a signal to all waiting threads
  24.912      on the associated condition variable, and returns the result \<open>y\<close>.
  24.913  
  24.914 -  There are some further variants of the @{ML Synchronized.guarded_access}
  24.915 +  There are some further variants of the \<^ML>\<open>Synchronized.guarded_access\<close>
  24.916    combinator, see \<^file>\<open>~~/src/Pure/Concurrent/synchronized.ML\<close> for details.
  24.917  \<close>
  24.918  
  24.919 @@ -1826,7 +1808,7 @@
  24.920  
  24.921    val a = next ();
  24.922    val b = next ();
  24.923 -  @{assert} (a <> b);
  24.924 +  \<^assert> (a <> b);
  24.925  \<close>
  24.926  
  24.927  text \<open>
  24.928 @@ -1892,29 +1874,28 @@
  24.929    @{index_ML Par_Exn.release_first: "'a Exn.result list -> 'a list"} \\
  24.930    \end{mldecls}
  24.931  
  24.932 -  \<^descr> Type @{ML_type "'a Exn.result"} represents the disjoint sum of ML results
  24.933 -  explicitly, with constructor @{ML Exn.Res} for regular values and @{ML
  24.934 -  "Exn.Exn"} for exceptions.
  24.935 -
  24.936 -  \<^descr> @{ML Exn.capture}~\<open>f x\<close> manages the evaluation of \<open>f x\<close> such that
  24.937 -  exceptions are made explicit as @{ML "Exn.Exn"}. Note that this includes
  24.938 +  \<^descr> Type \<^ML_type>\<open>'a Exn.result\<close> represents the disjoint sum of ML results
  24.939 +  explicitly, with constructor \<^ML>\<open>Exn.Res\<close> for regular values and \<^ML>\<open>Exn.Exn\<close> for exceptions.
  24.940 +
  24.941 +  \<^descr> \<^ML>\<open>Exn.capture\<close>~\<open>f x\<close> manages the evaluation of \<open>f x\<close> such that
  24.942 +  exceptions are made explicit as \<^ML>\<open>Exn.Exn\<close>. Note that this includes
  24.943    physical interrupts (see also \secref{sec:exceptions}), so the same
  24.944    precautions apply to user code: interrupts must not be absorbed
  24.945    accidentally!
  24.946  
  24.947 -  \<^descr> @{ML Exn.interruptible_capture} is similar to @{ML Exn.capture}, but
  24.948 +  \<^descr> \<^ML>\<open>Exn.interruptible_capture\<close> is similar to \<^ML>\<open>Exn.capture\<close>, but
  24.949    interrupts are immediately re-raised as required for user code.
  24.950  
  24.951 -  \<^descr> @{ML Exn.release}~\<open>result\<close> releases the original runtime result, exposing
  24.952 +  \<^descr> \<^ML>\<open>Exn.release\<close>~\<open>result\<close> releases the original runtime result, exposing
  24.953    its regular value or raising the reified exception.
  24.954  
  24.955 -  \<^descr> @{ML Par_Exn.release_all}~\<open>results\<close> combines results that were produced
  24.956 +  \<^descr> \<^ML>\<open>Par_Exn.release_all\<close>~\<open>results\<close> combines results that were produced
  24.957    independently (e.g.\ by parallel evaluation). If all results are regular
  24.958    values, that list is returned. Otherwise, the collection of all exceptions
  24.959    is raised, wrapped-up as collective parallel exception. Note that the latter
  24.960    prevents access to individual exceptions by conventional \<^verbatim>\<open>handle\<close> of ML.
  24.961  
  24.962 -  \<^descr> @{ML Par_Exn.release_first} is similar to @{ML Par_Exn.release_all}, but
  24.963 +  \<^descr> \<^ML>\<open>Par_Exn.release_first\<close> is similar to \<^ML>\<open>Par_Exn.release_all\<close>, but
  24.964    only the first (meaningful) exception that has occurred in the original
  24.965    evaluation process is raised again, the others are ignored. That single
  24.966    exception may get handled by conventional means in ML.
  24.967 @@ -1944,23 +1925,23 @@
  24.968    @{index_ML Par_List.get_some: "('a -> 'b option) -> 'a list -> 'b option"} \\
  24.969    \end{mldecls}
  24.970  
  24.971 -  \<^descr> @{ML Par_List.map}~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> is like @{ML "map"}~\<open>f [x\<^sub>1, \<dots>,
  24.972 +  \<^descr> \<^ML>\<open>Par_List.map\<close>~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> is like \<^ML>\<open>map\<close>~\<open>f [x\<^sub>1, \<dots>,
  24.973    x\<^sub>n]\<close>, but the evaluation of \<open>f x\<^sub>i\<close> for \<open>i = 1, \<dots>, n\<close> is performed in
  24.974    parallel.
  24.975  
  24.976    An exception in any \<open>f x\<^sub>i\<close> cancels the overall evaluation process. The
  24.977 -  final result is produced via @{ML Par_Exn.release_first} as explained above,
  24.978 +  final result is produced via \<^ML>\<open>Par_Exn.release_first\<close> as explained above,
  24.979    which means the first program exception that happened to occur in the
  24.980    parallel evaluation is propagated, and all other failures are ignored.
  24.981  
  24.982 -  \<^descr> @{ML Par_List.get_some}~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> produces some \<open>f x\<^sub>i\<close> that is of
  24.983 +  \<^descr> \<^ML>\<open>Par_List.get_some\<close>~\<open>f [x\<^sub>1, \<dots>, x\<^sub>n]\<close> produces some \<open>f x\<^sub>i\<close> that is of
  24.984    the form \<open>SOME y\<^sub>i\<close>, if that exists, otherwise \<open>NONE\<close>. Thus it is similar to
  24.985 -  @{ML Library.get_first}, but subject to a non-deterministic parallel choice
  24.986 +  \<^ML>\<open>Library.get_first\<close>, but subject to a non-deterministic parallel choice
  24.987    process. The first successful result cancels the overall evaluation process;
  24.988 -  other exceptions are propagated as for @{ML Par_List.map}.
  24.989 +  other exceptions are propagated as for \<^ML>\<open>Par_List.map\<close>.
  24.990  
  24.991    This generic parallel choice combinator is the basis for derived forms, such
  24.992 -  as @{ML Par_List.find_some}, @{ML Par_List.exists}, @{ML Par_List.forall}.
  24.993 +  as \<^ML>\<open>Par_List.find_some\<close>, \<^ML>\<open>Par_List.exists\<close>, \<^ML>\<open>Par_List.forall\<close>.
  24.994  \<close>
  24.995  
  24.996  text %mlex \<open>
  24.997 @@ -2010,18 +1991,18 @@
  24.998    @{index_ML Lazy.force: "'a lazy -> 'a"} \\
  24.999    \end{mldecls}
 24.1000  
 24.1001 -  \<^descr> Type @{ML_type "'a lazy"} represents lazy values over type \<^verbatim>\<open>'a\<close>.
 24.1002 -
 24.1003 -  \<^descr> @{ML Lazy.lazy}~\<open>(fn () => e)\<close> wraps the unevaluated expression \<open>e\<close> as
 24.1004 +  \<^descr> Type \<^ML_type>\<open>'a lazy\<close> represents lazy values over type \<^verbatim>\<open>'a\<close>.
 24.1005 +
 24.1006 +  \<^descr> \<^ML>\<open>Lazy.lazy\<close>~\<open>(fn () => e)\<close> wraps the unevaluated expression \<open>e\<close> as
 24.1007    unfinished lazy value.
 24.1008  
 24.1009 -  \<^descr> @{ML Lazy.value}~\<open>a\<close> wraps the value \<open>a\<close> as finished lazy value. When
 24.1010 +  \<^descr> \<^ML>\<open>Lazy.value\<close>~\<open>a\<close> wraps the value \<open>a\<close> as finished lazy value. When
 24.1011    forced, it returns \<open>a\<close> without any further evaluation.
 24.1012  
 24.1013    There is very low overhead for this proforma wrapping of strict values as
 24.1014    lazy values.
 24.1015  
 24.1016 -  \<^descr> @{ML Lazy.force}~\<open>x\<close> produces the result of the lazy value in a
 24.1017 +  \<^descr> \<^ML>\<open>Lazy.force\<close>~\<open>x\<close> produces the result of the lazy value in a
 24.1018    thread-safe manner as explained above. Thus it may cause the current thread
 24.1019    to wait on a pending evaluation attempt by another thread.
 24.1020  \<close>
 24.1021 @@ -2098,33 +2079,32 @@
 24.1022    @{index_ML Future.fulfill: "'a future -> 'a -> unit"} \\
 24.1023    \end{mldecls}
 24.1024  
 24.1025 -  \<^descr> Type @{ML_type "'a future"} represents future values over type \<^verbatim>\<open>'a\<close>.
 24.1026 -
 24.1027 -  \<^descr> @{ML Future.fork}~\<open>(fn () => e)\<close> registers the unevaluated expression \<open>e\<close>
 24.1028 +  \<^descr> Type \<^ML_type>\<open>'a future\<close> represents future values over type \<^verbatim>\<open>'a\<close>.
 24.1029 +
 24.1030 +  \<^descr> \<^ML>\<open>Future.fork\<close>~\<open>(fn () => e)\<close> registers the unevaluated expression \<open>e\<close>
 24.1031    as unfinished future value, to be evaluated eventually on the parallel
 24.1032 -  worker-thread farm. This is a shorthand for @{ML Future.forks} below, with
 24.1033 +  worker-thread farm. This is a shorthand for \<^ML>\<open>Future.forks\<close> below, with
 24.1034    default parameters and a single expression.
 24.1035  
 24.1036 -  \<^descr> @{ML Future.forks}~\<open>params exprs\<close> is the general interface to fork several
 24.1037 +  \<^descr> \<^ML>\<open>Future.forks\<close>~\<open>params exprs\<close> is the general interface to fork several
 24.1038    futures simultaneously. The \<open>params\<close> consist of the following fields:
 24.1039  
 24.1040 -    \<^item> \<open>name : string\<close> (default @{ML "\"\""}) specifies a common name for the
 24.1041 +    \<^item> \<open>name : string\<close> (default \<^ML>\<open>""\<close>) specifies a common name for the
 24.1042      tasks of the forked futures, which serves diagnostic purposes.
 24.1043  
 24.1044 -    \<^item> \<open>group : Future.group option\<close> (default @{ML NONE}) specifies an optional
 24.1045 -    task group for the forked futures. @{ML NONE} means that a new sub-group
 24.1046 +    \<^item> \<open>group : Future.group option\<close> (default \<^ML>\<open>NONE\<close>) specifies an optional
 24.1047 +    task group for the forked futures. \<^ML>\<open>NONE\<close> means that a new sub-group
 24.1048      of the current worker-thread task context is created. If this is not a
 24.1049      worker thread, the group will be a new root in the group hierarchy.
 24.1050  
 24.1051 -    \<^item> \<open>deps : Future.task list\<close> (default @{ML "[]"}) specifies dependencies on
 24.1052 +    \<^item> \<open>deps : Future.task list\<close> (default \<^ML>\<open>[]\<close>) specifies dependencies on
 24.1053      other future tasks, i.e.\ the adjacency relation in the global task queue.
 24.1054      Dependencies on already finished tasks are ignored.
 24.1055  
 24.1056 -    \<^item> \<open>pri : int\<close> (default @{ML 0}) specifies a priority within the task
 24.1057 +    \<^item> \<open>pri : int\<close> (default \<^ML>\<open>0\<close>) specifies a priority within the task
 24.1058      queue.
 24.1059  
 24.1060 -    Typically there is only little deviation from the default priority @{ML
 24.1061 -    0}. As a rule of thumb, @{ML "~1"} means ``low priority" and @{ML 1} means
 24.1062 +    Typically there is only little deviation from the default priority \<^ML>\<open>0\<close>. As a rule of thumb, \<^ML>\<open>~1\<close> means ``low priority" and \<^ML>\<open>1\<close> means
 24.1063      ``high priority''.
 24.1064  
 24.1065      Note that the task priority only affects the position in the queue, not
 24.1066 @@ -2133,7 +2113,7 @@
 24.1067      Higher priority tasks that are queued later need to wait until this (or
 24.1068      another) worker thread becomes free again.
 24.1069  
 24.1070 -    \<^item> \<open>interrupts : bool\<close> (default @{ML true}) tells whether the worker thread
 24.1071 +    \<^item> \<open>interrupts : bool\<close> (default \<^ML>\<open>true\<close>) tells whether the worker thread
 24.1072      that processes the corresponding task is initially put into interruptible
 24.1073      state. This state may change again while running, by modifying the thread
 24.1074      attributes.
 24.1075 @@ -2142,7 +2122,7 @@
 24.1076      the responsibility of the programmer that this special state is retained
 24.1077      only briefly.
 24.1078  
 24.1079 -  \<^descr> @{ML Future.join}~\<open>x\<close> retrieves the value of an already finished future,
 24.1080 +  \<^descr> \<^ML>\<open>Future.join\<close>~\<open>x\<close> retrieves the value of an already finished future,
 24.1081    which may lead to an exception, according to the result of its previous
 24.1082    evaluation.
 24.1083  
 24.1084 @@ -2164,8 +2144,8 @@
 24.1085    explicitly when forked (see \<open>deps\<close> above). Thus the evaluation can work from
 24.1086    the bottom up, without join conflicts and wait states.
 24.1087  
 24.1088 -  \<^descr> @{ML Future.joins}~\<open>xs\<close> joins the given list of futures simultaneously,
 24.1089 -  which is more efficient than @{ML "map Future.join"}~\<open>xs\<close>.
 24.1090 +  \<^descr> \<^ML>\<open>Future.joins\<close>~\<open>xs\<close> joins the given list of futures simultaneously,
 24.1091 +  which is more efficient than \<^ML>\<open>map Future.join\<close>~\<open>xs\<close>.
 24.1092  
 24.1093    Based on the dependency graph of tasks, the current thread takes over the
 24.1094    responsibility to evaluate future expressions that are required for the main
 24.1095 @@ -2173,23 +2153,22 @@
 24.1096    presently evaluated on other threads only happens as last resort, when no
 24.1097    other unfinished futures are left over.
 24.1098  
 24.1099 -  \<^descr> @{ML Future.value}~\<open>a\<close> wraps the value \<open>a\<close> as finished future value,
 24.1100 +  \<^descr> \<^ML>\<open>Future.value\<close>~\<open>a\<close> wraps the value \<open>a\<close> as finished future value,
 24.1101    bypassing the worker-thread farm. When joined, it returns \<open>a\<close> without any
 24.1102    further evaluation.
 24.1103  
 24.1104    There is very low overhead for this proforma wrapping of strict values as
 24.1105    futures.
 24.1106  
 24.1107 -  \<^descr> @{ML Future.map}~\<open>f x\<close> is a fast-path implementation of @{ML
 24.1108 -  Future.fork}~\<open>(fn () => f (\<close>@{ML Future.join}~\<open>x))\<close>, which avoids the full
 24.1109 +  \<^descr> \<^ML>\<open>Future.map\<close>~\<open>f x\<close> is a fast-path implementation of \<^ML>\<open>Future.fork\<close>~\<open>(fn () => f (\<close>\<^ML>\<open>Future.join\<close>~\<open>x))\<close>, which avoids the full
 24.1110    overhead of the task queue and worker-thread farm as far as possible. The
 24.1111    function \<open>f\<close> is supposed to be some trivial post-processing or projection of
 24.1112    the future result.
 24.1113  
 24.1114 -  \<^descr> @{ML Future.cancel}~\<open>x\<close> cancels the task group of the given future, using
 24.1115 -  @{ML Future.cancel_group} below.
 24.1116 -
 24.1117 -  \<^descr> @{ML Future.cancel_group}~\<open>group\<close> cancels all tasks of the given task
 24.1118 +  \<^descr> \<^ML>\<open>Future.cancel\<close>~\<open>x\<close> cancels the task group of the given future, using
 24.1119 +  \<^ML>\<open>Future.cancel_group\<close> below.
 24.1120 +
 24.1121 +  \<^descr> \<^ML>\<open>Future.cancel_group\<close>~\<open>group\<close> cancels all tasks of the given task
 24.1122    group for all time. Threads that are presently processing a task of the
 24.1123    given group are interrupted: it may take some time until they are actually
 24.1124    terminated. Tasks that are queued but not yet processed are dequeued and
 24.1125 @@ -2197,10 +2176,10 @@
 24.1126    any further attempt to fork a future that belongs to it will yield a
 24.1127    canceled result as well.
 24.1128  
 24.1129 -  \<^descr> @{ML Future.promise}~\<open>abort\<close> registers a passive future with the given
 24.1130 +  \<^descr> \<^ML>\<open>Future.promise\<close>~\<open>abort\<close> registers a passive future with the given
 24.1131    \<open>abort\<close> operation: it is invoked when the future task group is canceled.
 24.1132  
 24.1133 -  \<^descr> @{ML Future.fulfill}~\<open>x a\<close> finishes the passive future \<open>x\<close> by the given
 24.1134 +  \<^descr> \<^ML>\<open>Future.fulfill\<close>~\<open>x a\<close> finishes the passive future \<open>x\<close> by the given
 24.1135    value \<open>a\<close>. If the promise has already been canceled, the attempt to fulfill
 24.1136    it causes an exception.
 24.1137  \<close>
    25.1 --- a/src/Doc/Implementation/Prelim.thy	Sat Jan 05 17:00:43 2019 +0100
    25.2 +++ b/src/Doc/Implementation/Prelim.thy	Sat Jan 05 17:24:33 2019 +0100
    25.3 @@ -116,22 +116,22 @@
    25.4    @{index_ML Theory.ancestors_of: "theory -> theory list"} \\
    25.5    \end{mldecls}
    25.6  
    25.7 -  \<^descr> Type @{ML_type theory} represents theory contexts.
    25.8 +  \<^descr> Type \<^ML_type>\<open>theory\<close> represents theory contexts.
    25.9  
   25.10 -  \<^descr> @{ML "Context.eq_thy"}~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> check strict identity of two
   25.11 +  \<^descr> \<^ML>\<open>Context.eq_thy\<close>~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> check strict identity of two
   25.12    theories.
   25.13  
   25.14 -  \<^descr> @{ML "Context.subthy"}~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> compares theories according to the
   25.15 +  \<^descr> \<^ML>\<open>Context.subthy\<close>~\<open>(thy\<^sub>1, thy\<^sub>2)\<close> compares theories according to the
   25.16    intrinsic graph structure of the construction. This sub-theory relation is a
   25.17    nominal approximation of inclusion (\<open>\<subseteq>\<close>) of the corresponding content
   25.18    (according to the semantics of the ML modules that implement the data).
   25.19  
   25.20 -  \<^descr> @{ML "Theory.begin_theory"}~\<open>name parents\<close> constructs a new theory based
   25.21 +  \<^descr> \<^ML>\<open>Theory.begin_theory\<close>~\<open>name parents\<close> constructs a new theory based
   25.22    on the given parents. This ML function is normally not invoked directly.
   25.23  
   25.24 -  \<^descr> @{ML "Theory.parents_of"}~\<open>thy\<close> returns the direct ancestors of \<open>thy\<close>.
   25.25 +  \<^descr> \<^ML>\<open>Theory.parents_of\<close>~\<open>thy\<close> returns the direct ancestors of \<open>thy\<close>.
   25.26  
   25.27 -  \<^descr> @{ML "Theory.ancestors_of"}~\<open>thy\<close> returns all ancestors of \<open>thy\<close> (not
   25.28 +  \<^descr> \<^ML>\<open>Theory.ancestors_of\<close>~\<open>thy\<close> returns all ancestors of \<open>thy\<close> (not
   25.29    including \<open>thy\<close> itself).
   25.30  \<close>
   25.31  
   25.32 @@ -141,11 +141,11 @@
   25.33    @{ML_antiquotation_def "theory_context"} & : & \<open>ML_antiquotation\<close> \\
   25.34    \end{matharray}
   25.35  
   25.36 -  @{rail \<open>
   25.37 +  \<^rail>\<open>
   25.38    @@{ML_antiquotation theory} embedded?
   25.39    ;
   25.40    @@{ML_antiquotation theory_context} embedded
   25.41 -  \<close>}
   25.42 +  \<close>
   25.43  
   25.44    \<^descr> \<open>@{theory}\<close> refers to the background theory of the current context --- as
   25.45    abstract value.
   25.46 @@ -154,8 +154,7 @@
   25.47    background theory of the current context --- as abstract value.
   25.48  
   25.49    \<^descr> \<open>@{theory_context A}\<close> is similar to \<open>@{theory A}\<close>, but presents the result
   25.50 -  as initial @{ML_type Proof.context} (see also @{ML
   25.51 -  Proof_Context.init_global}).
   25.52 +  as initial \<^ML_type>\<open>Proof.context\<close> (see also \<^ML>\<open>Proof_Context.init_global\<close>).
   25.53  \<close>
   25.54  
   25.55  
   25.56 @@ -194,15 +193,15 @@
   25.57    @{index_ML Proof_Context.transfer: "theory -> Proof.context -> Proof.context"} \\
   25.58    \end{mldecls}
   25.59  
   25.60 -  \<^descr> Type @{ML_type Proof.context} represents proof contexts.
   25.61 +  \<^descr> Type \<^ML_type>\<open>Proof.context\<close> represents proof contexts.
   25.62  
   25.63 -  \<^descr> @{ML Proof_Context.init_global}~\<open>thy\<close> produces a proof context derived
   25.64 +  \<^descr> \<^ML>\<open>Proof_Context.init_global\<close>~\<open>thy\<close> produces a proof context derived
   25.65    from \<open>thy\<close>, initializing all data.
   25.66  
   25.67 -  \<^descr> @{ML Proof_Context.theory_of}~\<open>ctxt\<close> selects the background theory from
   25.68 +  \<^descr> \<^ML>\<open>Proof_Context.theory_of\<close>~\<open>ctxt\<close> selects the background theory from
   25.69    \<open>ctxt\<close>.
   25.70  
   25.71 -  \<^descr> @{ML Proof_Context.transfer}~\<open>thy ctxt\<close> promotes the background theory of
   25.72 +  \<^descr> \<^ML>\<open>Proof_Context.transfer\<close>~\<open>thy ctxt\<close> promotes the background theory of
   25.73    \<open>ctxt\<close> to the super theory \<open>thy\<close>.
   25.74  \<close>
   25.75  
   25.76 @@ -242,15 +241,14 @@
   25.77    @{index_ML Context.proof_of: "Context.generic -> Proof.context"} \\
   25.78    \end{mldecls}
   25.79  
   25.80 -  \<^descr> Type @{ML_type Context.generic} is the direct sum of @{ML_type "theory"}
   25.81 -  and @{ML_type "Proof.context"}, with the datatype constructors @{ML
   25.82 -  "Context.Theory"} and @{ML "Context.Proof"}.
   25.83 +  \<^descr> Type \<^ML_type>\<open>Context.generic\<close> is the direct sum of \<^ML_type>\<open>theory\<close>
   25.84 +  and \<^ML_type>\<open>Proof.context\<close>, with the datatype constructors \<^ML>\<open>Context.Theory\<close> and \<^ML>\<open>Context.Proof\<close>.
   25.85  
   25.86 -  \<^descr> @{ML Context.theory_of}~\<open>context\<close> always produces a theory from the
   25.87 -  generic \<open>context\<close>, using @{ML "Proof_Context.theory_of"} as required.
   25.88 +  \<^descr> \<^ML>\<open>Context.theory_of\<close>~\<open>context\<close> always produces a theory from the
   25.89 +  generic \<open>context\<close>, using \<^ML>\<open>Proof_Context.theory_of\<close> as required.
   25.90  
   25.91 -  \<^descr> @{ML Context.proof_of}~\<open>context\<close> always produces a proof context from the
   25.92 -  generic \<open>context\<close>, using @{ML "Proof_Context.init_global"} as required (note
   25.93 +  \<^descr> \<^ML>\<open>Context.proof_of\<close>~\<open>context\<close> always produces a proof context from the
   25.94 +  generic \<open>context\<close>, using \<^ML>\<open>Proof_Context.init_global\<close> as required (note
   25.95    that this re-initializes the context data with each invocation).
   25.96  \<close>