doc-src/IsarImplementation/Thy/Local_Theory.thy
changeset 30242 aea5d7fa7ef5
parent 29766 da411bda1d41
child 30270 61811c9224a6
equal deleted inserted replaced
30241:3a1aef73b2b2 30242:aea5d7fa7ef5
       
     1 theory Local_Theory
       
     2 imports Base
       
     3 begin
       
     4 
       
     5 chapter {* Local theory specifications *}
       
     6 
       
     7 text {*
       
     8   A \emph{local theory} combines aspects of both theory and proof
       
     9   context (cf.\ \secref{sec:context}), such that definitional
       
    10   specifications may be given relatively to parameters and
       
    11   assumptions.  A local theory is represented as a regular proof
       
    12   context, augmented by administrative data about the \emph{target
       
    13   context}.
       
    14 
       
    15   The target is usually derived from the background theory by adding
       
    16   local @{text "\<FIX>"} and @{text "\<ASSUME>"} elements, plus
       
    17   suitable modifications of non-logical context data (e.g.\ a special
       
    18   type-checking discipline).  Once initialized, the target is ready to
       
    19   absorb definitional primitives: @{text "\<DEFINE>"} for terms and
       
    20   @{text "\<NOTE>"} for theorems.  Such definitions may get
       
    21   transformed in a target-specific way, but the programming interface
       
    22   hides such details.
       
    23 
       
    24   Isabelle/Pure provides target mechanisms for locales, type-classes,
       
    25   type-class instantiations, and general overloading.  In principle,
       
    26   users can implement new targets as well, but this rather arcane
       
    27   discipline is beyond the scope of this manual.  In contrast,
       
    28   implementing derived definitional packages to be used within a local
       
    29   theory context is quite easy: the interfaces are even simpler and
       
    30   more abstract than the underlying primitives for raw theories.
       
    31 
       
    32   Many definitional packages for local theories are available in
       
    33   Isabelle.  Although a few old packages only work for global
       
    34   theories, the local theory interface is already the standard way of
       
    35   implementing definitional packages in Isabelle.
       
    36 *}
       
    37 
       
    38 
       
    39 section {* Definitional elements *}
       
    40 
       
    41 text {*
       
    42   There are separate elements @{text "\<DEFINE> c \<equiv> t"} for terms, and
       
    43   @{text "\<NOTE> b = thm"} for theorems.  Types are treated
       
    44   implicitly, according to Hindley-Milner discipline (cf.\
       
    45   \secref{sec:variables}).  These definitional primitives essentially
       
    46   act like @{text "let"}-bindings within a local context that may
       
    47   already contain earlier @{text "let"}-bindings and some initial
       
    48   @{text "\<lambda>"}-bindings.  Thus we gain \emph{dependent definitions}
       
    49   that are relative to an initial axiomatic context.  The following
       
    50   diagram illustrates this idea of axiomatic elements versus
       
    51   definitional elements:
       
    52 
       
    53   \begin{center}
       
    54   \begin{tabular}{|l|l|l|}
       
    55   \hline
       
    56   & @{text "\<lambda>"}-binding & @{text "let"}-binding \\
       
    57   \hline
       
    58   types & fixed @{text "\<alpha>"} & arbitrary @{text "\<beta>"} \\
       
    59   terms & @{text "\<FIX> x :: \<tau>"} & @{text "\<DEFINE> c \<equiv> t"} \\
       
    60   theorems & @{text "\<ASSUME> a: A"} & @{text "\<NOTE> b = \<^BG>B\<^EN>"} \\
       
    61   \hline
       
    62   \end{tabular}
       
    63   \end{center}
       
    64 
       
    65   A user package merely needs to produce suitable @{text "\<DEFINE>"}
       
    66   and @{text "\<NOTE>"} elements according to the application.  For
       
    67   example, a package for inductive definitions might first @{text
       
    68   "\<DEFINE>"} a certain predicate as some fixed-point construction,
       
    69   then @{text "\<NOTE>"} a proven result about monotonicity of the
       
    70   functor involved here, and then produce further derived concepts via
       
    71   additional @{text "\<DEFINE>"} and @{text "\<NOTE>"} elements.
       
    72 
       
    73   The cumulative sequence of @{text "\<DEFINE>"} and @{text "\<NOTE>"}
       
    74   produced at package runtime is managed by the local theory
       
    75   infrastructure by means of an \emph{auxiliary context}.  Thus the
       
    76   system holds up the impression of working within a fully abstract
       
    77   situation with hypothetical entities: @{text "\<DEFINE> c \<equiv> t"}
       
    78   always results in a literal fact @{text "\<^BG>c \<equiv> t\<^EN>"}, where
       
    79   @{text "c"} is a fixed variable @{text "c"}.  The details about
       
    80   global constants, name spaces etc. are handled internally.
       
    81 
       
    82   So the general structure of a local theory is a sandwich of three
       
    83   layers:
       
    84 
       
    85   \begin{center}
       
    86   \framebox{\quad auxiliary context \quad\framebox{\quad target context \quad\framebox{\quad background theory\quad}}}
       
    87   \end{center}
       
    88 
       
    89   \noindent When a definitional package is finished, the auxiliary
       
    90   context is reset to the target context.  The target now holds
       
    91   definitions for terms and theorems that stem from the hypothetical
       
    92   @{text "\<DEFINE>"} and @{text "\<NOTE>"} elements, transformed by
       
    93   the particular target policy (see
       
    94   \cite[\S4--5]{Haftmann-Wenzel:2009} for details).
       
    95 *}
       
    96 
       
    97 text %mlref {*
       
    98   \begin{mldecls}
       
    99   @{index_ML_type local_theory: Proof.context} \\
       
   100   @{index_ML TheoryTarget.init: "string option -> theory -> local_theory"} \\[1ex]
       
   101   @{index_ML LocalTheory.define: "string ->
       
   102     (binding * mixfix) * (Attrib.binding * term) -> local_theory ->
       
   103     (term * (string * thm)) * local_theory"} \\
       
   104   @{index_ML LocalTheory.note: "string ->
       
   105     Attrib.binding * thm list -> local_theory ->
       
   106     (string * thm list) * local_theory"} \\
       
   107   \end{mldecls}
       
   108 
       
   109   \begin{description}
       
   110 
       
   111   \item @{ML_type local_theory} represents local theories.  Although
       
   112   this is merely an alias for @{ML_type Proof.context}, it is
       
   113   semantically a subtype of the same: a @{ML_type local_theory} holds
       
   114   target information as special context data.  Subtyping means that
       
   115   any value @{text "lthy:"}~@{ML_type local_theory} can be also used
       
   116   with operations on expecting a regular @{text "ctxt:"}~@{ML_type
       
   117   Proof.context}.
       
   118 
       
   119   \item @{ML TheoryTarget.init}~@{text "NONE thy"} initializes a
       
   120   trivial local theory from the given background theory.
       
   121   Alternatively, @{text "SOME name"} may be given to initialize a
       
   122   @{command locale} or @{command class} context (a fully-qualified
       
   123   internal name is expected here).  This is useful for experimentation
       
   124   --- normally the Isar toplevel already takes care to initialize the
       
   125   local theory context.
       
   126 
       
   127   \item @{ML LocalTheory.define}~@{text "kind ((b, mx), (a, rhs))
       
   128   lthy"} defines a local entity according to the specification that is
       
   129   given relatively to the current @{text "lthy"} context.  In
       
   130   particular the term of the RHS may refer to earlier local entities
       
   131   from the auxiliary context, or hypothetical parameters from the
       
   132   target context.  The result is the newly defined term (which is
       
   133   always a fixed variable with exactly the same name as specified for
       
   134   the LHS), together with an equational theorem that states the
       
   135   definition as a hypothetical fact.
       
   136 
       
   137   Unless an explicit name binding is given for the RHS, the resulting
       
   138   fact will be called @{text "b_def"}.  Any given attributes are
       
   139   applied to that same fact --- immediately in the auxiliary context
       
   140   \emph{and} in any transformed versions stemming from target-specific
       
   141   policies or any later interpretations of results from the target
       
   142   context (think of @{command locale} and @{command interpretation},
       
   143   for example).  This means that attributes should be usually plain
       
   144   declarations such as @{attribute simp}, while non-trivial rules like
       
   145   @{attribute simplified} are better avoided.
       
   146 
       
   147   The @{text kind} determines the theorem kind tag of the resulting
       
   148   fact.  Typical examples are @{ML Thm.definitionK}, @{ML
       
   149   Thm.theoremK}, or @{ML Thm.internalK}.
       
   150 
       
   151   \item @{ML LocalTheory.note}~@{text "kind (a, ths) lthy"} is
       
   152   analogous to @{ML LocalTheory.define}, but defines facts instead of
       
   153   terms.  There is also a slightly more general variant @{ML
       
   154   LocalTheory.notes} that defines several facts (with attribute
       
   155   expressions) simultaneously.
       
   156 
       
   157   This is essentially the internal version of the @{command lemmas}
       
   158   command, or @{command declare} if an empty name binding is given.
       
   159 
       
   160   \end{description}
       
   161 *}
       
   162 
       
   163 
       
   164 section {* Morphisms and declarations *}
       
   165 
       
   166 text FIXME
       
   167 
       
   168 end