(* $Id$ *)

theory Generic

imports CPure

begin

chapter {* Generic tools and packages \label{ch:gen-tools} *}

section {* Specification commands *}

subsection {* Derived specifications *}

text {*

  \begin{matharray}{rcll}

    @{command_def "axiomatization"} & : & \isarkeep{local{\dsh}theory} & (axiomatic!)\\

    @{command_def "definition"} & : & \isarkeep{local{\dsh}theory} \\

    @{attribute_def "defn"} & : & \isaratt \\

    @{command_def "abbreviation"} & : & \isarkeep{local{\dsh}theory} \\

    @{command_def "print_abbrevs"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\

    @{command_def "notation"} & : & \isarkeep{local{\dsh}theory} \\

    @{command_def "no_notation"} & : & \isarkeep{local{\dsh}theory} \\

  \end{matharray}

  These specification mechanisms provide a slightly more abstract view

  than the underlying primitives of @{command "consts"}, @{command

  "defs"} (see \secref{sec:consts}), and @{command "axioms"} (see

  \secref{sec:axms-thms}).  In particular, type-inference is commonly

  available, and result names need not be given.

  \begin{rail}

    'axiomatization' target? fixes? ('where' specs)?

    ;

    'definition' target? (decl 'where')? thmdecl? prop

    ;

    'abbreviation' target? mode? (decl 'where')? prop

    ;

    ('notation' | 'no\_notation') target? mode? (nameref structmixfix + 'and')

    ;

    fixes: ((name ('::' type)? mixfix? | vars) + 'and')

    ;

    specs: (thmdecl? props + 'and')

    ;

    decl: name ('::' type)? mixfix?

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "axiomatization"}~@{text "c\<^sub>1 \<dots> c\<^sub>m

  \<WHERE> \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n"}] introduces several constants

  simultaneously and states axiomatic properties for these.  The

  constants are marked as being specified once and for all, which

  prevents additional specifications being issued later on.

  Note that axiomatic specifications are only appropriate when

  declaring a new logical system.  Normal applications should only use

  definitional mechanisms!

  \item [@{command "definition"}~@{text "c \<WHERE> eq"}] produces an

  internal definition @{text "c \<equiv> t"} according to the specification

  given as @{text eq}, which is then turned into a proven fact.  The

  given proposition may deviate from internal meta-level equality

  according to the rewrite rules declared as @{attribute defn} by the

  object-logic.  This usually covers object-level equality @{text "x =

  y"} and equivalence @{text "A \<leftrightarrow> B"}.  End-users normally need not

  change the @{attribute defn} setup.

  Definitions may be presented with explicit arguments on the LHS, as

  well as additional conditions, e.g.\ @{text "f x y = t"} instead of

  @{text "f \<equiv> \<lambda>x y. t"} and @{text "y \<noteq> 0 \<Longrightarrow> g x y = u"} instead of an

  unrestricted @{text "g \<equiv> \<lambda>x y. u"}.

  \item [@{command "abbreviation"}~@{text "c \<WHERE> eq"}] introduces

  a syntactic constant which is associated with a certain term

  according to the meta-level equality @{text eq}.

  Abbreviations participate in the usual type-inference process, but

  are expanded before the logic ever sees them.  Pretty printing of

  terms involves higher-order rewriting with rules stemming from

  reverted abbreviations.  This needs some care to avoid overlapping

  or looping syntactic replacements!

  The optional @{text mode} specification restricts output to a

  particular print mode; using ``@{text input}'' here achieves the

  effect of one-way abbreviations.  The mode may also include an

  ``@{keyword "output"}'' qualifier that affects the concrete syntax

  declared for abbreviations, cf.\ @{command "syntax"} in

  \secref{sec:syn-trans}.

  \item [@{command "print_abbrevs"}] prints all constant abbreviations

  of the current context.

  \item [@{command "notation"}~@{text "c (mx)"}] associates mixfix

  syntax with an existing constant or fixed variable.  This is a

  robust interface to the underlying @{command "syntax"} primitive

  (\secref{sec:syn-trans}).  Type declaration and internal syntactic

  representation of the given entity is retrieved from the context.

  \item [@{command "no_notation"}] is similar to @{command

  "notation"}, but removes the specified syntax annotation from the

  present context.

  \end{descr}

  All of these specifications support local theory targets (cf.\

  \secref{sec:target}).

*}

subsection {* Generic declarations *}

text {*

  Arbitrary operations on the background context may be wrapped-up as

  generic declaration elements.  Since the underlying concept of local

  theories may be subject to later re-interpretation, there is an

  additional dependency on a morphism that tells the difference of the

  original declaration context wrt.\ the application context

  encountered later on.  A fact declaration is an important special

  case: it consists of a theorem which is applied to the context by

  means of an attribute.

  \begin{matharray}{rcl}

    @{command_def "declaration"} & : & \isarkeep{local{\dsh}theory} \\

    @{command_def "declare"} & : & \isarkeep{local{\dsh}theory} \\

  \end{matharray}

  \begin{rail}

    'declaration' target? text

    ;

    'declare' target? (thmrefs + 'and')

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "declaration"}~@{text d}] adds the declaration

  function @{text d} of ML type @{ML_type declaration}, to the current

  local theory under construction.  In later application contexts, the

  function is transformed according to the morphisms being involved in

  the interpretation hierarchy.

  \item [@{command "declare"}~@{text thms}] declares theorems to the

  current local theory context.  No theorem binding is involved here,

  unlike @{command "theorems"} or @{command "lemmas"} (cf.\

  \secref{sec:axms-thms}), so @{command "declare"} only has the effect

  of applying attributes as included in the theorem specification.

  \end{descr}

*}

subsection {* Local theory targets \label{sec:target} *}

text {*

  A local theory target is a context managed separately within the

  enclosing theory.  Contexts may introduce parameters (fixed

  variables) and assumptions (hypotheses).  Definitions and theorems

  depending on the context may be added incrementally later on.  Named

  contexts refer to locales (cf.\ \secref{sec:locale}) or type classes

  (cf.\ \secref{sec:class}); the name ``@{text "-"}'' signifies the

  global theory context.

  \begin{matharray}{rcll}

    @{command_def "context"} & : & \isartrans{theory}{local{\dsh}theory} \\

    @{command_def "end"} & : & \isartrans{local{\dsh}theory}{theory} \\

  \end{matharray}

  \indexouternonterm{target}

  \begin{rail}

    'context' name 'begin'

    ;

    target: '(' 'in' name ')'

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "context"}~@{text "c \<BEGIN>"}] recommences an

  existing locale or class context @{text c}.  Note that locale and

  class definitions allow to include the @{keyword_ref "begin"}

  keyword as well, in order to continue the local theory immediately

  after the initial specification.

  \item [@{command "end"}] concludes the current local theory and

  continues the enclosing global theory.  Note that a non-local

  @{command "end"} has a different meaning: it concludes the theory

  itself (\secref{sec:begin-thy}).

  \item [@{text "(\<IN> c)"}] given after any local theory command

  specifies an immediate target, e.g.\ ``@{command

  "definition"}~@{text "(\<IN> c) \<dots>"}'' or ``@{command

  "theorem"}~@{text "(\<IN> c) \<dots>"}''.  This works both in a local or

  global theory context; the current target context will be suspended

  for this command only.  Note that ``@{text "(\<IN> -)"}'' will

  always produce a global result independently of the current target

  context.

  \end{descr}

  The exact meaning of results produced within a local theory context

  depends on the underlying target infrastructure (locale, type class

  etc.).  The general idea is as follows, considering a context named

  @{text c} with parameter @{text x} and assumption @{text "A[x]"}.

  Definitions are exported by introducing a global version with

  additional arguments; a syntactic abbreviation links the long form

  with the abstract version of the target context.  For example,

  @{text "a \<equiv> t[x]"} becomes @{text "c.a ?x \<equiv> t[?x]"} at the theory

  level (for arbitrary @{text "?x"}), together with a local

  abbreviation @{text "c \<equiv> c.a x"} in the target context (for the

  fixed parameter @{text x}).

  Theorems are exported by discharging the assumptions and

  generalizing the parameters of the context.  For example, @{text "a:

  B[x]"} becomes @{text "c.a: A[?x] \<Longrightarrow> B[?x]"}, again for arbitrary

  @{text "?x"}.

*}

subsection {* Locales \label{sec:locale} *}

text {*

  Locales are named local contexts, consisting of a list of

  declaration elements that are modeled after the Isar proof context

  commands (cf.\ \secref{sec:proof-context}).

*}

subsubsection {* Locale specifications *}

text {*

  \begin{matharray}{rcl}

    @{command_def "locale"} & : & \isartrans{theory}{local{\dsh}theory} \\

    @{command_def "print_locale"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\

    @{command_def "print_locales"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\

    @{method_def intro_locales} & : & \isarmeth \\

    @{method_def unfold_locales} & : & \isarmeth \\

  \end{matharray}

  \indexouternonterm{contextexpr}\indexouternonterm{contextelem}

  \indexisarelem{fixes}\indexisarelem{constrains}\indexisarelem{assumes}

  \indexisarelem{defines}\indexisarelem{notes}\indexisarelem{includes}

  \begin{rail}

    'locale' ('(open)')? name ('=' localeexpr)? 'begin'?

    ;

    'print\_locale' '!'? localeexpr

    ;

    localeexpr: ((contextexpr '+' (contextelem+)) | contextexpr | (contextelem+))

    ;

    contextexpr: nameref | '(' contextexpr ')' |

    (contextexpr (name mixfix? +)) | (contextexpr + '+')

    ;

    contextelem: fixes | constrains | assumes | defines | notes

    ;

    fixes: 'fixes' ((name ('::' type)? structmixfix? | vars) + 'and')

    ;

    constrains: 'constrains' (name '::' type + 'and')

    ;

    assumes: 'assumes' (thmdecl? props + 'and')

    ;

    defines: 'defines' (thmdecl? prop proppat? + 'and')

    ;

    notes: 'notes' (thmdef? thmrefs + 'and')

    ;

    includes: 'includes' contextexpr

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "locale"}~@{text "loc = import + body"}] defines a

  new locale @{text loc} as a context consisting of a certain view of

  existing locales (@{text import}) plus some additional elements

  (@{text body}).  Both @{text import} and @{text body} are optional;

  the degenerate form @{command "locale"}~@{text loc} defines an empty

  locale, which may still be useful to collect declarations of facts

  later on.  Type-inference on locale expressions automatically takes

  care of the most general typing that the combined context elements

  may acquire.

  The @{text import} consists of a structured context expression,

  consisting of references to existing locales, renamed contexts, or

  merged contexts.  Renaming uses positional notation: @{text "c

  x\<^sub>1 \<dots> x\<^sub>n"} means that (a prefix of) the fixed

  parameters of context @{text c} are named @{text "x\<^sub>1, \<dots>,

  x\<^sub>n"}; a ``@{text _}'' (underscore) means to skip that

  position.  Renaming by default deletes concrete syntax, but new

  syntax may by specified with a mixfix annotation.  An exeption of

  this rule is the special syntax declared with ``@{text

  "(\<STRUCTURE>)"}'' (see below), which is neither deleted nor can it

  be changed.  Merging proceeds from left-to-right, suppressing any

  duplicates stemming from different paths through the import

  hierarchy.

  The @{text body} consists of basic context elements, further context

  expressions may be included as well.

  \begin{descr}

  \item [@{element "fixes"}~@{text "x :: \<tau> (mx)"}] declares a local

  parameter of type @{text \<tau>} and mixfix annotation @{text mx} (both

  are optional).  The special syntax declaration ``@{text

  "(\<STRUCTURE>)"}'' means that @{text x} may be referenced

  implicitly in this context.

  \item [@{element "constrains"}~@{text "x :: \<tau>"}] introduces a type

  constraint @{text \<tau>} on the local parameter @{text x}.

  \item [@{element "assumes"}~@{text "a: \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n"}]

  introduces local premises, similar to @{command "assume"} within a

  proof (cf.\ \secref{sec:proof-context}).

  \item [@{element "defines"}~@{text "a: x \<equiv> t"}] defines a previously

  declared parameter.  This is similar to @{command "def"} within a

  proof (cf.\ \secref{sec:proof-context}), but @{element "defines"}

  takes an equational proposition instead of variable-term pair.  The

  left-hand side of the equation may have additional arguments, e.g.\

  ``@{element "defines"}~@{text "f x\<^sub>1 \<dots> x\<^sub>n \<equiv> t"}''.

  \item [@{element "notes"}~@{text "a = b\<^sub>1 \<dots> b\<^sub>n"}]

  reconsiders facts within a local context.  Most notably, this may

  include arbitrary declarations in any attribute specifications

  included here, e.g.\ a local @{attribute simp} rule.

  \item [@{element "includes"}~@{text c}] copies the specified context

  in a statically scoped manner.  Only available in the long goal

  format of \secref{sec:goals}.

  In contrast, the initial @{text import} specification of a locale

  expression maintains a dynamic relation to the locales being

  referenced (benefiting from any later fact declarations in the

  obvious manner).

  \end{descr}

  Note that ``@{text "(\<IS> p\<^sub>1 \<dots> p\<^sub>n)"}'' patterns given

  in the syntax of @{element "assumes"} and @{element "defines"} above

  are illegal in locale definitions.  In the long goal format of

  \secref{sec:goals}, term bindings may be included as expected,

  though.

  \medskip By default, locale specifications are ``closed up'' by

  turning the given text into a predicate definition @{text

  loc_axioms} and deriving the original assumptions as local lemmas

  (modulo local definitions).  The predicate statement covers only the

  newly specified assumptions, omitting the content of included locale

  expressions.  The full cumulative view is only provided on export,

  involving another predicate @{text loc} that refers to the complete

  specification text.

  In any case, the predicate arguments are those locale parameters

  that actually occur in the respective piece of text.  Also note that

  these predicates operate at the meta-level in theory, but the locale

  packages attempts to internalize statements according to the

  object-logic setup (e.g.\ replacing @{text \<And>} by @{text \<forall>}, and

  @{text "\<Longrightarrow>"} by @{text "\<longrightarrow>"} in HOL; see also

  \secref{sec:object-logic}).  Separate introduction rules @{text

  loc_axioms.intro} and @{text loc.intro} are provided as well.

  The @{text "(open)"} option of a locale specification prevents both

  the current @{text loc_axioms} and cumulative @{text loc} predicate

  constructions.  Predicates are also omitted for empty specification

  texts.

  \item [@{command "print_locale"}~@{text "import + body"}] prints the

  specified locale expression in a flattened form.  The notable

  special case @{command "print_locale"}~@{text loc} just prints the

  contents of the named locale, but keep in mind that type-inference

  will normalize type variables according to the usual alphabetical

  order.  The command omits @{element "notes"} elements by default.

  Use @{command "print_locale"}@{text "!"} to get them included.

  \item [@{command "print_locales"}] prints the names of all locales

  of the current theory.

  \item [@{method intro_locales} and @{method unfold_locales}]

  repeatedly expand all introduction rules of locale predicates of the

  theory.  While @{method intro_locales} only applies the @{text

  loc.intro} introduction rules and therefore does not decend to

  assumptions, @{method unfold_locales} is more aggressive and applies

  @{text loc_axioms.intro} as well.  Both methods are aware of locale

  specifications entailed by the context, both from target and

  @{element "includes"} statements, and from interpretations (see

  below).  New goals that are entailed by the current context are

  discharged automatically.

  \end{descr}

*}

subsubsection {* Interpretation of locales *}

text {*

  Locale expressions (more precisely, \emph{context expressions}) may

  be instantiated, and the instantiated facts added to the current

  context.  This requires a proof of the instantiated specification

  and is called \emph{locale interpretation}.  Interpretation is

  possible in theories and locales (command @{command

  "interpretation"}) and also within a proof body (command @{command

  "interpret"}).

  \begin{matharray}{rcl}

    @{command_def "interpretation"} & : & \isartrans{theory}{proof(prove)} \\

    @{command_def "interpret"} & : & \isartrans{proof(state) ~|~ proof(chain)}{proof(prove)} \\

    @{command_def "print_interps"}@{text "\<^sup>*"} & : &  \isarkeep{theory~|~proof} \\

  \end{matharray}

  \indexouternonterm{interp}

  \begin{rail}

    'interpretation' (interp | name ('<' | subseteq) contextexpr)

    ;

    'interpret' interp

    ;

    'print\_interps' '!'? name

    ;

    instantiation: ('[' (inst+) ']')?

    ;

    interp: thmdecl? \\ (contextexpr instantiation |

      name instantiation 'where' (thmdecl? prop + 'and'))

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "interpretation"}~@{text "expr insts \<WHERE> eqns"}]

  The first form of @{command "interpretation"} interprets @{text

  expr} in the theory.  The instantiation is given as a list of terms

  @{text insts} and is positional.  All parameters must receive an

  instantiation term --- with the exception of defined parameters.

  These are, if omitted, derived from the defining equation and other

  instantiations.  Use ``@{text _}'' to omit an instantiation term.

  The command generates proof obligations for the instantiated

  specifications (assumes and defines elements).  Once these are

  discharged by the user, instantiated facts are added to the theory

  in a post-processing phase.

  Additional equations, which are unfolded in facts during

  post-processing, may be given after the keyword @{keyword "where"}.

  This is useful for interpreting concepts introduced through

  definition specification elements.  The equations must be proved.

  Note that if equations are present, the context expression is

  restricted to a locale name.

  The command is aware of interpretations already active in the

  theory.  No proof obligations are generated for those, neither is

  post-processing applied to their facts.  This avoids duplication of

  interpreted facts, in particular.  Note that, in the case of a

  locale with import, parts of the interpretation may already be

  active.  The command will only generate proof obligations and

  process facts for new parts.

  The context expression may be preceded by a name and/or attributes.

  These take effect in the post-processing of facts.  The name is used

  to prefix fact names, for example to avoid accidental hiding of

  other facts.  Attributes are applied after attributes of the

  interpreted facts.

  Adding facts to locales has the effect of adding interpreted facts

  to the theory for all active interpretations also.  That is,

  interpretations dynamically participate in any facts added to

  locales.

  \item [@{command "interpretation"}~@{text "name \<subseteq> expr"}]

  This form of the command interprets @{text expr} in the locale

  @{text name}.  It requires a proof that the specification of @{text

  name} implies the specification of @{text expr}.  As in the

  localized version of the theorem command, the proof is in the

  context of @{text name}.  After the proof obligation has been

  dischared, the facts of @{text expr} become part of locale @{text

  name} as \emph{derived} context elements and are available when the

  context @{text name} is subsequently entered.  Note that, like

  import, this is dynamic: facts added to a locale part of @{text

  expr} after interpretation become also available in @{text name}.

  Like facts of renamed context elements, facts obtained by

  interpretation may be accessed by prefixing with the parameter

  renaming (where the parameters are separated by ``@{text _}'').

  Unlike interpretation in theories, instantiation is confined to the

  renaming of parameters, which may be specified as part of the

  context expression @{text expr}.  Using defined parameters in @{text

  name} one may achieve an effect similar to instantiation, though.

  Only specification fragments of @{text expr} that are not already

  part of @{text name} (be it imported, derived or a derived fragment

  of the import) are considered by interpretation.  This enables

  circular interpretations.

  If interpretations of @{text name} exist in the current theory, the

  command adds interpretations for @{text expr} as well, with the same

  prefix and attributes, although only for fragments of @{text expr}

  that are not interpreted in the theory already.

  \item [@{command "interpret"}~@{text "expr insts \<WHERE> eqns"}]

  interprets @{text expr} in the proof context and is otherwise

  similar to interpretation in theories.

  \item [@{command "print_interps"}~@{text loc}] prints the

  interpretations of a particular locale @{text loc} that are active

  in the current context, either theory or proof context.  The

  exclamation point argument triggers printing of \emph{witness}

  theorems justifying interpretations.  These are normally omitted

  from the output.

  \end{descr}

  \begin{warn}

    Since attributes are applied to interpreted theorems,

    interpretation may modify the context of common proof tools, e.g.\

    the Simplifier or Classical Reasoner.  Since the behavior of such

    automated reasoning tools is \emph{not} stable under

    interpretation morphisms, manual declarations might have to be

    issued.

  \end{warn}

  \begin{warn}

    An interpretation in a theory may subsume previous

    interpretations.  This happens if the same specification fragment

    is interpreted twice and the instantiation of the second

    interpretation is more general than the interpretation of the

    first.  A warning is issued, since it is likely that these could

    have been generalized in the first place.  The locale package does

    not attempt to remove subsumed interpretations.

  \end{warn}

*}

subsection {* Classes \label{sec:class} *}

text {*

  A class is a particular locale with \emph{exactly one} type variable

  @{text \<alpha>}.  Beyond the underlying locale, a corresponding type class

  is established which is interpreted logically as axiomatic type

  class \cite{Wenzel:1997:TPHOL} whose logical content are the

  assumptions of the locale.  Thus, classes provide the full

  generality of locales combined with the commodity of type classes

  (notably type-inference).  See \cite{isabelle-classes} for a short

  tutorial.

  \begin{matharray}{rcl}

    @{command_def "class"} & : & \isartrans{theory}{local{\dsh}theory} \\

    @{command_def "instantiation"} & : & \isartrans{theory}{local{\dsh}theory} \\

    @{command_def "instance"} & : & \isartrans{local{\dsh}theory}{local{\dsh}theory} \\

    @{command_def "subclass"} & : & \isartrans{local{\dsh}theory}{local{\dsh}theory} \\

    @{command_def "print_classes"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\

    @{method_def intro_classes} & : & \isarmeth \\

  \end{matharray}

  \begin{rail}

    'class' name '=' ((superclassexpr '+' (contextelem+)) | superclassexpr | (contextelem+)) \\

      'begin'?

    ;

    'instantiation' (nameref + 'and') '::' arity 'begin'

    ;

    'instance'

    ;

    'subclass' target? nameref

    ;

    'print\_classes'

    ;

    superclassexpr: nameref | (nameref '+' superclassexpr)

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "class"}~@{text "c = superclasses + body"}] defines

  a new class @{text c}, inheriting from @{text superclasses}.  This

  introduces a locale @{text c} with import of all locales @{text

  superclasses}.

  Any @{element "fixes"} in @{text body} are lifted to the global

  theory level (\emph{class operations} @{text "f\<^sub>1, \<dots>,

  f\<^sub>n"} of class @{text c}), mapping the local type parameter

  @{text \<alpha>} to a schematic type variable @{text "?\<alpha> :: c"}.

  Likewise, @{element "assumes"} in @{text body} are also lifted,

  mapping each local parameter @{text "f :: \<tau>[\<alpha>]"} to its

  corresponding global constant @{text "f :: \<tau>[?\<alpha> :: c]"}.  The

  corresponding introduction rule is provided as @{text

  c_class_axioms.intro}.  This rule should be rarely needed directly

  --- the @{method intro_classes} method takes care of the details of

  class membership proofs.

  \item [@{command "instantiation"}~@{text "t :: (s\<^sub>1, \<dots>,

  s\<^sub>n) s \<BEGIN>"}] opens a theory target (cf.\

  \secref{sec:target}) which allows to specify class operations @{text

  "f\<^sub>1, \<dots>, f\<^sub>n"} corresponding to sort @{text s} at the

  particular type instance @{text "(\<alpha>\<^sub>1 :: s\<^sub>1, \<dots>,

  \<alpha>\<^sub>n :: s\<^sub>n) t"}.  A plain @{command "instance"} command

  in the target body poses a goal stating these type arities.  The

  target is concluded by an @{command_ref "end"} command.

  Note that a list of simultaneous type constructors may be given;

  this corresponds nicely to mutual recursive type definitions, e.g.\

  in Isabelle/HOL.

  \item [@{command "instance"}] in an instantiation target body sets

  up a goal stating the type arities claimed at the opening @{command

  "instantiation"}.  The proof would usually proceed by @{method

  intro_classes}, and then establish the characteristic theorems of

  the type classes involved.  After finishing the proof, the

  background theory will be augmented by the proven type arities.

  \item [@{command "subclass"}~@{text c}] in a class context for class

  @{text d} sets up a goal stating that class @{text c} is logically

  contained in class @{text d}.  After finishing the proof, class

  @{text d} is proven to be subclass @{text c} and the locale @{text

  c} is interpreted into @{text d} simultaneously.

  \item [@{command "print_classes"}] prints all classes in the current

  theory.

  \item [@{method intro_classes}] repeatedly expands all class

  introduction rules of this theory.  Note that this method usually

  needs not be named explicitly, as it is already included in the

  default proof step (e.g.\ of @{command "proof"}).  In particular,

  instantiation of trivial (syntactic) classes may be performed by a

  single ``@{command ".."}'' proof step.

  \end{descr}

*}

subsubsection {* The class target *}

text {*

  %FIXME check

  A named context may refer to a locale (cf.\ \secref{sec:target}).

  If this locale is also a class @{text c}, apart from the common

  locale target behaviour the following happens.

  \begin{itemize}

  \item Local constant declarations @{text "g[\<alpha>]"} referring to the

  local type parameter @{text \<alpha>} and local parameters @{text "f[\<alpha>]"}

  are accompanied by theory-level constants @{text "g[?\<alpha> :: c]"}

  referring to theory-level class operations @{text "f[?\<alpha> :: c]"}.

  \item Local theorem bindings are lifted as are assumptions.

  \item Local syntax refers to local operations @{text "g[\<alpha>]"} and

  global operations @{text "g[?\<alpha> :: c]"} uniformly.  Type inference

  resolves ambiguities.  In rare cases, manual type annotations are

  needed.

  \end{itemize}

*}

subsection {* Axiomatic type classes \label{sec:axclass} *}

text {*

  \begin{matharray}{rcl}

    @{command_def "axclass"} & : & \isartrans{theory}{theory} \\

    @{command_def "instance"} & : & \isartrans{theory}{proof(prove)} \\

  \end{matharray}

  Axiomatic type classes are Isabelle/Pure's primitive

  \emph{definitional} interface to type classes.  For practical

  applications, you should consider using classes

  (cf.~\secref{sec:classes}) which provide high level interface.

  \begin{rail}

    'axclass' classdecl (axmdecl prop +)

    ;

    'instance' (nameref ('<' | subseteq) nameref | nameref '::' arity)

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "axclass"}~@{text "c \<subseteq> c\<^sub>1, \<dots>, c\<^sub>n

  axms"}] defines an axiomatic type class as the intersection of

  existing classes, with additional axioms holding.  Class axioms may

  not contain more than one type variable.  The class axioms (with

  implicit sort constraints added) are bound to the given names.

  Furthermore a class introduction rule is generated (being bound as

  @{text c_class.intro}); this rule is employed by method @{method

  intro_classes} to support instantiation proofs of this class.

  The ``class axioms'' are stored as theorems according to the given

  name specifications, adding @{text "c_class"} as name space prefix;

  the same facts are also stored collectively as @{text

  c_class.axioms}.

  \item [@{command "instance"}~@{text "c\<^sub>1 \<subseteq> c\<^sub>2"} and

  @{command "instance"}~@{text "t :: (s\<^sub>1, \<dots>, s\<^sub>n) s"}]

  setup a goal stating a class relation or type arity.  The proof

  would usually proceed by @{method intro_classes}, and then establish

  the characteristic theorems of the type classes involved.  After

  finishing the proof, the theory will be augmented by a type

  signature declaration corresponding to the resulting theorem.

  \end{descr}

*}

subsection {* Arbitrary overloading *}

text {*

  Isabelle/Pure's definitional schemes support certain forms of

  overloading (see \secref{sec:consts}).  At most occassions

  overloading will be used in a Haskell-like fashion together with

  type classes by means of @{command "instantiation"} (see

  \secref{sec:class}).  Sometimes low-level overloading is desirable.

  The @{command "overloading"} target provides a convenient view for

  end-users.

  \begin{matharray}{rcl}

    @{command_def "overloading"} & : & \isartrans{theory}{local{\dsh}theory} \\

  \end{matharray}

  \begin{rail}

    'overloading' \\

    ( string ( '==' | equiv ) term ( '(' 'unchecked' ')' )? + ) 'begin'

  \end{rail}

  \begin{descr}

  \item [@{command "overloading"}~@{text "x\<^sub>1 \<equiv> c\<^sub>1 ::

  \<tau>\<^sub>1 \<AND> \<dots> x\<^sub>n \<equiv> c\<^sub>n :: \<tau>\<^sub>n \<BEGIN>"}]

  opens a theory target (cf.\ \secref{sec:target}) which allows to

  specify constants with overloaded definitions.  These are identified

  by an explicitly given mapping from variable names @{text

  "x\<^sub>i"} to constants @{text "c\<^sub>i"} at particular type

  instances.  The definitions themselves are established using common

  specification tools, using the names @{text "x\<^sub>i"} as

  reference to the corresponding constants.  The target is concluded

  by @{command "end"}.

  A @{text "(unchecked)"} option disables global dependency checks for

  the corresponding definition, which is occasionally useful for

  exotic overloading.  It is at the discretion of the user to avoid

  malformed theory specifications!

  \end{descr}

*}

subsection {* Configuration options *}

text {*

  Isabelle/Pure maintains a record of named configuration options

  within the theory or proof context, with values of type @{ML_type

  bool}, @{ML_type int}, or @{ML_type string}.  Tools may declare

  options in ML, and then refer to these values (relative to the

  context).  Thus global reference variables are easily avoided.  The

  user may change the value of a configuration option by means of an

  associated attribute of the same name.  This form of context

  declaration works particularly well with commands such as @{command

  "declare"} or @{command "using"}.

  For historical reasons, some tools cannot take the full proof

  context into account and merely refer to the background theory.

  This is accommodated by configuration options being declared as

  ``global'', which may not be changed within a local context.

  \begin{matharray}{rcll}

    @{command_def "print_configs"} & : & \isarkeep{theory~|~proof} \\

  \end{matharray}

  \begin{rail}

    name ('=' ('true' | 'false' | int | name))?

  \end{rail}

  \begin{descr}

  \item [@{command "print_configs"}] prints the available

  configuration options, with names, types, and current values.

  \item [@{text "name = value"}] as an attribute expression modifies

  the named option, with the syntax of the value depending on the

  option's type.  For @{ML_type bool} the default value is @{text

  true}.  Any attempt to change a global option in a local context is

  ignored.

  \end{descr}

*}

section {* Derived proof schemes *}

subsection {* Generalized elimination \label{sec:obtain} *}

text {*

  \begin{matharray}{rcl}

    @{command_def "obtain"} & : & \isartrans{proof(state)}{proof(prove)} \\

    @{command_def "guess"}@{text "\<^sup>*"} & : & \isartrans{proof(state)}{proof(prove)} \\

  \end{matharray}

  Generalized elimination means that additional elements with certain

  properties may be introduced in the current context, by virtue of a

  locally proven ``soundness statement''.  Technically speaking, the

  @{command "obtain"} language element is like a declaration of

  @{command "fix"} and @{command "assume"} (see also see

  \secref{sec:proof-context}), together with a soundness proof of its

  additional claim.  According to the nature of existential reasoning,

  assumptions get eliminated from any result exported from the context

  later, provided that the corresponding parameters do \emph{not}

  occur in the conclusion.

  \begin{rail}

    'obtain' parname? (vars + 'and') 'where' (props + 'and')

    ;

    'guess' (vars + 'and')

    ;

  \end{rail}

  The derived Isar command @{command "obtain"} is defined as follows

  (where @{text "b\<^sub>1, \<dots>, b\<^sub>k"} shall refer to (optional)

  facts indicated for forward chaining).

  \begin{matharray}{l}

    @{text "\<langle>using b\<^sub>1 \<dots> b\<^sub>k\<rangle>"}~~@{command "obtain"}~@{text "x\<^sub>1 \<dots> x\<^sub>m \<WHERE> a: \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n  \<langle>proof\<rangle> \<equiv>"} \\[1ex]

    \quad @{command "have"}~@{text "\<And>thesis. (\<And>x\<^sub>1 \<dots> x\<^sub>m. \<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> thesis) \<Longrightarrow> thesis"} \\

    \quad @{command "proof"}~@{text succeed} \\

    \qquad @{command "fix"}~@{text thesis} \\

    \qquad @{command "assume"}~@{text "that [Pure.intro?]: \<And>x\<^sub>1 \<dots> x\<^sub>m. \<phi>\<^sub>1 \<Longrightarrow> \<dots> \<phi>\<^sub>n \<Longrightarrow> thesis"} \\

    \qquad @{command "then"}~@{command "show"}~@{text thesis} \\

    \quad\qquad @{command "apply"}~@{text -} \\

    \quad\qquad @{command "using"}~@{text "b\<^sub>1 \<dots> b\<^sub>k  \<langle>proof\<rangle>"} \\

    \quad @{command "qed"} \\

    \quad @{command "fix"}~@{text "x\<^sub>1 \<dots> x\<^sub>m"}~@{command "assume"}@{text "\<^sup>* a: \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n"} \\

  \end{matharray}

  Typically, the soundness proof is relatively straight-forward, often

  just by canonical automated tools such as ``@{command "by"}~@{text

  simp}'' or ``@{command "by"}~@{text blast}''.  Accordingly, the

  ``@{text that}'' reduction above is declared as simplification and

  introduction rule.

  In a sense, @{command "obtain"} represents at the level of Isar

  proofs what would be meta-logical existential quantifiers and

  conjunctions.  This concept has a broad range of useful

  applications, ranging from plain elimination (or introduction) of

  object-level existential and conjunctions, to elimination over

  results of symbolic evaluation of recursive definitions, for

  example.  Also note that @{command "obtain"} without parameters acts

  much like @{command "have"}, where the result is treated as a

  genuine assumption.

  An alternative name to be used instead of ``@{text that}'' above may

  be given in parentheses.

  \medskip The improper variant @{command "guess"} is similar to

  @{command "obtain"}, but derives the obtained statement from the

  course of reasoning!  The proof starts with a fixed goal @{text

  thesis}.  The subsequent proof may refine this to anything of the

  form like @{text "\<And>x\<^sub>1 \<dots> x\<^sub>m. \<phi>\<^sub>1 \<Longrightarrow> \<dots>

  \<phi>\<^sub>n \<Longrightarrow> thesis"}, but must not introduce new subgoals.  The

  final goal state is then used as reduction rule for the obtain

  scheme described above.  Obtained parameters @{text "x\<^sub>1, \<dots>,

  x\<^sub>m"} are marked as internal by default, which prevents the

  proof context from being polluted by ad-hoc variables.  The variable

  names and type constraints given as arguments for @{command "guess"}

  specify a prefix of obtained parameters explicitly in the text.

  It is important to note that the facts introduced by @{command

  "obtain"} and @{command "guess"} may not be polymorphic: any

  type-variables occurring here are fixed in the present context!

*}

subsection {* Calculational reasoning \label{sec:calculation} *}

text {*

  \begin{matharray}{rcl}

    @{command_def "also"} & : & \isartrans{proof(state)}{proof(state)} \\

    @{command_def "finally"} & : & \isartrans{proof(state)}{proof(chain)} \\

    @{command_def "moreover"} & : & \isartrans{proof(state)}{proof(state)} \\

    @{command_def "ultimately"} & : & \isartrans{proof(state)}{proof(chain)} \\

    @{command_def "print_trans_rules"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\

    @{attribute trans} & : & \isaratt \\

    @{attribute sym} & : & \isaratt \\

    @{attribute symmetric} & : & \isaratt \\

  \end{matharray}

  Calculational proof is forward reasoning with implicit application

  of transitivity rules (such those of @{text "="}, @{text "\<le>"},

  @{text "<"}).  Isabelle/Isar maintains an auxiliary fact register

  @{fact_ref calculation} for accumulating results obtained by

  transitivity composed with the current result.  Command @{command

  "also"} updates @{fact calculation} involving @{fact this}, while

  @{command "finally"} exhibits the final @{fact calculation} by

  forward chaining towards the next goal statement.  Both commands

  require valid current facts, i.e.\ may occur only after commands

  that produce theorems such as @{command "assume"}, @{command

  "note"}, or some finished proof of @{command "have"}, @{command

  "show"} etc.  The @{command "moreover"} and @{command "ultimately"}

  commands are similar to @{command "also"} and @{command "finally"},

  but only collect further results in @{fact calculation} without

  applying any rules yet.

  Also note that the implicit term abbreviation ``@{text "\<dots>"}'' has

  its canonical application with calculational proofs.  It refers to

  the argument of the preceding statement. (The argument of a curried

  infix expression happens to be its right-hand side.)

  Isabelle/Isar calculations are implicitly subject to block structure

  in the sense that new threads of calculational reasoning are

  commenced for any new block (as opened by a local goal, for

  example).  This means that, apart from being able to nest

  calculations, there is no separate \emph{begin-calculation} command

  required.

  \medskip The Isar calculation proof commands may be defined as

  follows:\footnote{We suppress internal bookkeeping such as proper

  handling of block-structure.}

  \begin{matharray}{rcl}

    @{command "also"}@{text "\<^sub>0"} & \equiv & @{command "note"}~@{text "calculation = this"} \\

    @{command "also"}@{text "\<^sub>n\<^sub>+\<^sub>1"} & \equiv & @{command "note"}~@{text "calculation = trans [OF calculation this]"} \\[0.5ex]

    @{command "finally"} & \equiv & @{command "also"}~@{command "from"}~@{text calculation} \\[0.5ex]

    @{command "moreover"} & \equiv & @{command "note"}~@{text "calculation = calculation this"} \\

    @{command "ultimately"} & \equiv & @{command "moreover"}~@{command "from"}~@{text calculation} \\

  \end{matharray}

  \begin{rail}

    ('also' | 'finally') ('(' thmrefs ')')?

    ;

    'trans' (() | 'add' | 'del')

    ;

  \end{rail}

  \begin{descr}

  \item [@{command "also"}~@{text "(a\<^sub>1 \<dots> a\<^sub>n)"}]

  maintains the auxiliary @{fact calculation} register as follows.

  The first occurrence of @{command "also"} in some calculational

  thread initializes @{fact calculation} by @{fact this}. Any

  subsequent @{command "also"} on the same level of block-structure

  updates @{fact calculation} by some transitivity rule applied to

  @{fact calculation} and @{fact this} (in that order).  Transitivity

  rules are picked from the current context, unless alternative rules

  are given as explicit arguments.

  \item [@{command "finally"}~@{text "(a\<^sub>1 \<dots> a\<^sub>n)"}]

  maintaining @{fact calculation} in the same way as @{command

  "also"}, and concludes the current calculational thread.  The final

  result is exhibited as fact for forward chaining towards the next

  goal. Basically, @{command "finally"} just abbreviates @{command

  "also"}~@{command "from"}~@{fact calculation}.  Typical idioms for

  concluding calculational proofs are ``@{command "finally"}~@{command

  "show"}~@{text ?thesis}~@{command "."}'' and ``@{command

  "finally"}~@{command "have"}~@{text \<phi>}~@{command "."}''.

  \item [@{command "moreover"} and @{command "ultimately"}] are

  analogous to @{command "also"} and @{command "finally"}, but collect

  results only, without applying rules.

  \item [@{command "print_trans_rules"}] prints the list of

  transitivity rules (for calculational commands @{command "also"} and

  @{command "finally"}) and symmetry rules (for the @{attribute

  symmetric} operation and single step elimination patters) of the

  current context.

  \item [@{attribute trans}] declares theorems as transitivity rules.

  \item [@{attribute sym}] declares symmetry rules, as well as

  @{attribute "Pure.elim?"} rules.

  \item [@{attribute symmetric}] resolves a theorem with some rule

  declared as @{attribute sym} in the current context.  For example,

  ``@{command "assume"}~@{text "[symmetric]: x = y"}'' produces a

  swapped fact derived from that assumption.

  In structured proof texts it is often more appropriate to use an

  explicit single-step elimination proof, such as ``@{command

  "assume"}~@{text "x = y"}~@{command "then"}~@{command "have"}~@{text

  "y = x"}~@{command ".."}''.

  \end{descr}

*}

section {* Proof tools *}

subsection {* Miscellaneous methods and attributes \label{sec:misc-meth-att} *}

text {*

  \begin{matharray}{rcl}

    @{method_def unfold} & : & \isarmeth \\

    @{method_def fold} & : & \isarmeth \\

    @{method_def insert} & : & \isarmeth \\[0.5ex]

    @{method_def erule}@{text "\<^sup>*"} & : & \isarmeth \\

    @{method_def drule}@{text "\<^sup>*"} & : & \isarmeth \\