doc-src/IsarImplementation/Thy/prelim.thy
author wenzelm
Tue Aug 29 18:56:11 2006 +0200 (2006-08-29)
changeset 20430 fd646e926983
parent 20429 116255c9209b
child 20437 0eb5e30fd620
permissions -rw-r--r--
tuned;
wenzelm@18537
     1
wenzelm@18537
     2
(* $Id$ *)
wenzelm@18537
     3
wenzelm@18537
     4
theory prelim imports base begin
wenzelm@18537
     5
wenzelm@18537
     6
chapter {* Preliminaries *}
wenzelm@18537
     7
wenzelm@18537
     8
section {* Named entities *}
wenzelm@18537
     9
wenzelm@18537
    10
text {* Named entities of different kinds (logical constant, type,
wenzelm@18537
    11
type class, theorem, method etc.) live in separate name spaces.  It is
wenzelm@18537
    12
usually clear from the occurrence of a name which kind of entity it
wenzelm@18537
    13
refers to.  For example, proof method @{text "foo"} vs.\ theorem
wenzelm@18537
    14
@{text "foo"} vs.\ logical constant @{text "foo"} are easily
wenzelm@18537
    15
distinguished by means of the syntactic context.  A notable exception
wenzelm@18537
    16
are logical identifiers within a term (\secref{sec:terms}): constants,
wenzelm@18537
    17
fixed variables, and bound variables all share the same identifier
wenzelm@18537
    18
syntax, but are distinguished by their scope.
wenzelm@18537
    19
wenzelm@18537
    20
Each name space is organized as a collection of \emph{qualified
wenzelm@18537
    21
names}, which consist of a sequence of basic name components separated
wenzelm@18537
    22
by dots: @{text "Bar.bar.foo"}, @{text "Bar.foo"}, and @{text "foo"}
wenzelm@18537
    23
are examples for valid qualified names.  Name components are
wenzelm@18537
    24
subdivided into \emph{symbols}, which constitute the smallest textual
wenzelm@18537
    25
unit in Isabelle --- raw characters are normally not encountered
wenzelm@18537
    26
directly. *}
wenzelm@18537
    27
wenzelm@18537
    28
wenzelm@18537
    29
subsection {* Strings of symbols *}
wenzelm@18537
    30
wenzelm@18537
    31
text {* Isabelle strings consist of a sequence of
wenzelm@18537
    32
symbols\glossary{Symbol}{The smalles unit of text in Isabelle,
wenzelm@18537
    33
subsumes plain ASCII characters as well as an infinite collection of
wenzelm@18537
    34
named symbols (for greek, math etc.).}, which are either packed as an
wenzelm@18537
    35
actual @{text "string"}, or represented as a list.  Each symbol is in
wenzelm@18537
    36
itself a small string of the following form:
wenzelm@18537
    37
wenzelm@18537
    38
\begin{enumerate}
wenzelm@18537
    39
wenzelm@18537
    40
\item either a singleton ASCII character ``@{text "c"}'' (with
wenzelm@18537
    41
character code 0--127), for example ``\verb,a,'',
wenzelm@18537
    42
wenzelm@18537
    43
\item or a regular symbol ``\verb,\,\verb,<,@{text "ident"}\verb,>,'',
wenzelm@18537
    44
for example ``\verb,\,\verb,<alpha>,'',
wenzelm@18537
    45
wenzelm@18537
    46
\item or a control symbol ``\verb,\,\verb,<^,@{text
wenzelm@18537
    47
"ident"}\verb,>,'', for example ``\verb,\,\verb,<^bold>,'',
wenzelm@18537
    48
wenzelm@18537
    49
\item or a raw control symbol ``\verb,\,\verb,<^raw:,@{text
wenzelm@20205
    50
"\<dots>"}\verb,>,'' where ``@{text "\<dots>"}'' refers to any
wenzelm@20205
    51
printable ASCII character (excluding ``\verb,.,'' and ``\verb,>,'') or
wenzelm@20214
    52
non-ASCII character, for example ``\verb,\,\verb,<^raw:$\sum_{i = 1}^n$>,'',
wenzelm@18537
    53
wenzelm@18537
    54
\item or a numbered raw control symbol ``\verb,\,\verb,<^raw,@{text
wenzelm@18537
    55
"nnn"}\verb,>, where @{text "nnn"} are digits, for example
wenzelm@18537
    56
``\verb,\,\verb,<^raw42>,''.
wenzelm@18537
    57
wenzelm@18537
    58
\end{enumerate}
wenzelm@18537
    59
wenzelm@18537
    60
The @{text "ident"} syntax for symbol names is @{text "letter (letter
wenzelm@18537
    61
| digit)\<^sup>*"}, where @{text "letter = A..Za..Z"} and @{text
wenzelm@18537
    62
"digit = 0..9"}.  There are infinitely many regular symbols and
wenzelm@18537
    63
control symbols available, but a certain collection of standard
wenzelm@18537
    64
symbols is treated specifically.  For example,
wenzelm@18537
    65
``\verb,\,\verb,<alpha>,'' is classified as a (non-ASCII) letter,
wenzelm@18537
    66
which means it may occur within regular Isabelle identifier syntax.
wenzelm@18537
    67
wenzelm@18537
    68
Output of symbols depends on the print mode (\secref{sec:print-mode}).
wenzelm@18537
    69
For example, the standard {\LaTeX} setup of the Isabelle document
wenzelm@18537
    70
preparation system would present ``\verb,\,\verb,<alpha>,'' as @{text
wenzelm@18537
    71
"\<alpha>"}, and ``\verb,\,\verb,<^bold>,\verb,\,\verb,<alpha>,'' as @{text
wenzelm@18537
    72
"\<^bold>\<alpha>"}.
wenzelm@18537
    73
wenzelm@18537
    74
\medskip It is important to note that the character set underlying
wenzelm@18537
    75
Isabelle symbols is plain 7-bit ASCII.  Since 8-bit characters are
wenzelm@18537
    76
passed through transparently, Isabelle may easily process actual
wenzelm@18537
    77
Unicode/UCS data (using the well-known UTF-8 encoding, for example).
wenzelm@18537
    78
Unicode provides its own collection of mathematical symbols, but there
wenzelm@18537
    79
is presently no link to Isabelle's named ones; both kinds of symbols
wenzelm@18537
    80
coexist independently. *}
wenzelm@18537
    81
wenzelm@18537
    82
text %mlref {*
wenzelm@18537
    83
  \begin{mldecls}
wenzelm@18537
    84
  @{index_ML_type "Symbol.symbol"} \\
wenzelm@18537
    85
  @{index_ML Symbol.explode: "string -> Symbol.symbol list"} \\
wenzelm@18537
    86
  @{index_ML Symbol.is_letter: "Symbol.symbol -> bool"} \\
wenzelm@18537
    87
  @{index_ML Symbol.is_digit: "Symbol.symbol -> bool"} \\
wenzelm@18537
    88
  @{index_ML Symbol.is_quasi: "Symbol.symbol -> bool"} \\
wenzelm@18537
    89
  @{index_ML Symbol.is_blank: "Symbol.symbol -> bool"} \\
wenzelm@18537
    90
  @{index_ML_type "Symbol.sym"} \\
wenzelm@18537
    91
  @{index_ML Symbol.decode: "Symbol.symbol -> Symbol.sym"} \\
wenzelm@18537
    92
  \end{mldecls}
wenzelm@18537
    93
wenzelm@18537
    94
  \begin{description}
wenzelm@18537
    95
wenzelm@18537
    96
  \item @{ML_type "Symbol.symbol"} represents Isabelle symbols; this type
wenzelm@18537
    97
  is merely an alias for @{ML_type "string"}, but emphasizes the
wenzelm@18537
    98
  specific format encountered here.
wenzelm@18537
    99
wenzelm@18537
   100
  \item @{ML "Symbol.explode"}~@{text "s"} produces an actual symbol
wenzelm@18537
   101
  list from the packed form usually encountered as user input.  This
wenzelm@18537
   102
  function replaces @{ML "String.explode"} for virtually all purposes
wenzelm@18537
   103
  of manipulating text in Isabelle!  Plain @{text "implode"} may be
wenzelm@18537
   104
  used for the reverse operation.
wenzelm@18537
   105
wenzelm@18537
   106
  \item @{ML "Symbol.is_letter"}, @{ML "Symbol.is_digit"}, @{ML
wenzelm@18537
   107
  "Symbol.is_quasi"}, @{ML "Symbol.is_blank"} classify certain symbols
wenzelm@18537
   108
  (both ASCII and several named ones) according to fixed syntactic
wenzelm@18537
   109
  convections of Isabelle, e.g.\ see \cite{isabelle-isar-ref}.
wenzelm@18537
   110
wenzelm@18537
   111
  \item @{ML_type "Symbol.sym"} is a concrete datatype that represents
wenzelm@18537
   112
  the different kinds of symbols explicitly as @{ML "Symbol.Char"},
wenzelm@18537
   113
  @{ML "Symbol.Sym"}, @{ML "Symbol.Ctrl"}, or @{ML "Symbol.Raw"}.
wenzelm@18537
   114
wenzelm@18537
   115
  \item @{ML "Symbol.decode"} converts the string representation of a
wenzelm@18537
   116
  symbol into the explicit datatype version.
wenzelm@18537
   117
wenzelm@18537
   118
  \end{description}
wenzelm@18537
   119
*}
wenzelm@18537
   120
wenzelm@18537
   121
wenzelm@20429
   122
subsection {* Simple names *}
wenzelm@20429
   123
wenzelm@20429
   124
text FIXME
wenzelm@20429
   125
wenzelm@20429
   126
wenzelm@18537
   127
subsection {* Qualified names and name spaces *}
wenzelm@18537
   128
wenzelm@18537
   129
text %FIXME {* Qualified names are constructed according to implicit naming
wenzelm@18537
   130
principles of the present context.
wenzelm@18537
   131
wenzelm@18537
   132
wenzelm@18537
   133
The last component is called \emph{base name}; the remaining prefix of
wenzelm@18537
   134
qualification may be empty.
wenzelm@18537
   135
wenzelm@18537
   136
Some practical conventions help to organize named entities more
wenzelm@18537
   137
systematically:
wenzelm@18537
   138
wenzelm@18537
   139
\begin{itemize}
wenzelm@18537
   140
wenzelm@18537
   141
\item Names are qualified first by the theory name, second by an
wenzelm@18537
   142
optional ``structure''.  For example, a constant @{text "c"} declared
wenzelm@18537
   143
as part of a certain structure @{text "b"} (say a type definition) in
wenzelm@18537
   144
theory @{text "A"} will be named @{text "A.b.c"} internally.
wenzelm@18537
   145
wenzelm@18537
   146
\item
wenzelm@18537
   147
wenzelm@18537
   148
\item
wenzelm@18537
   149
wenzelm@18537
   150
\item
wenzelm@18537
   151
wenzelm@18537
   152
\item
wenzelm@18537
   153
wenzelm@18537
   154
\end{itemize}
wenzelm@18537
   155
wenzelm@18537
   156
Names of different kinds of entities are basically independent, but
wenzelm@18537
   157
some practical naming conventions relate them to each other.  For
wenzelm@18537
   158
example, a constant @{text "foo"} may be accompanied with theorems
wenzelm@18537
   159
@{text "foo.intro"}, @{text "foo.elim"}, @{text "foo.simps"} etc.  The
wenzelm@18537
   160
same may happen for a type @{text "foo"}, which is then apt to cause
wenzelm@18537
   161
clashes in the theorem name space!  To avoid this, we occasionally
wenzelm@18537
   162
follow an additional convention of suffixes that determine the
wenzelm@18537
   163
original kind of entity that a name has been derived.  For example,
wenzelm@18537
   164
constant @{text "foo"} is associated with theorem @{text "foo.intro"},
wenzelm@18537
   165
type @{text "foo"} with theorem @{text "foo_type.intro"}, and type
wenzelm@18537
   166
class @{text "foo"} with @{text "foo_class.intro"}.
wenzelm@18537
   167
wenzelm@18537
   168
*}
wenzelm@18537
   169
wenzelm@18537
   170
wenzelm@18537
   171
section {* Structured output *}
wenzelm@18537
   172
wenzelm@18537
   173
subsection {* Pretty printing *}
wenzelm@18537
   174
wenzelm@18537
   175
text FIXME
wenzelm@18537
   176
wenzelm@18537
   177
subsection {* Output channels *}
wenzelm@18537
   178
wenzelm@18537
   179
text FIXME
wenzelm@18537
   180
wenzelm@18537
   181
subsection {* Print modes *}
wenzelm@18537
   182
wenzelm@18537
   183
text FIXME
wenzelm@18537
   184
wenzelm@18537
   185
wenzelm@20429
   186
section {* Contexts \label{sec:context} *}
wenzelm@18537
   187
wenzelm@20429
   188
text {*
wenzelm@20429
   189
  A logical context represents the background that is taken for
wenzelm@20429
   190
  granted when formulating statements and composing proofs.  It acts
wenzelm@20429
   191
  as a medium to produce formal content, depending on earlier material
wenzelm@20429
   192
  (declarations, results etc.).
wenzelm@18537
   193
wenzelm@20429
   194
  In particular, derivations within the primitive Pure logic can be
wenzelm@20429
   195
  described as a judgment @{text "\<Gamma> \<turnstile>\<^sub>\<Theta> \<phi>"}, meaning that a
wenzelm@20429
   196
  proposition @{text "\<phi>"} is derivable from hypotheses @{text "\<Gamma>"}
wenzelm@20429
   197
  within the theory @{text "\<Theta>"}.  There are logical reasons for
wenzelm@20429
   198
  keeping @{text "\<Theta>"} and @{text "\<Gamma>"} separate: theories support type
wenzelm@20429
   199
  constructors and schematic polymorphism of constants and axioms,
wenzelm@20429
   200
  while the inner calculus of @{text "\<Gamma> \<turnstile> \<phi>"} is limited to Simple
wenzelm@20429
   201
  Type Theory (with fixed type variables in the assumptions).
wenzelm@18537
   202
wenzelm@20429
   203
  \medskip Contexts and derivations are linked by the following key
wenzelm@20429
   204
  principles:
wenzelm@20429
   205
wenzelm@20429
   206
  \begin{itemize}
wenzelm@20429
   207
wenzelm@20429
   208
  \item Transfer: monotonicity of derivations admits results to be
wenzelm@20429
   209
  transferred into a larger context, i.e.\ @{text "\<Gamma> \<turnstile>\<^sub>\<Theta> \<phi>"}
wenzelm@20429
   210
  implies @{text "\<Gamma>' \<turnstile>\<^sub>\<Theta>\<^sub>' \<phi>"} for contexts @{text "\<Theta>' \<supseteq>
wenzelm@20429
   211
  \<Theta>"} and @{text "\<Gamma>' \<supseteq> \<Gamma>"}.
wenzelm@18537
   212
wenzelm@20429
   213
  \item Export: discharge of hypotheses admits results to be exported
wenzelm@20429
   214
  into a smaller context, i.e.\ @{text "\<Gamma>' \<turnstile>\<^sub>\<Theta> \<phi>"} implies
wenzelm@20429
   215
  @{text "\<Gamma> \<turnstile>\<^sub>\<Theta> \<Delta> \<Longrightarrow> \<phi>"} where @{text "\<Gamma>' \<supseteq> \<Gamma>"} and @{text "\<Delta> =
wenzelm@20429
   216
  \<Gamma>' - \<Gamma>"}.  Note that @{text "\<Theta>"} remains unchanged here, only the
wenzelm@20429
   217
  @{text "\<Gamma>"} part is affected.
wenzelm@20429
   218
wenzelm@20429
   219
  \end{itemize}
wenzelm@18537
   220
wenzelm@20429
   221
  \medskip Isabelle/Isar provides two different notions of abstract
wenzelm@20429
   222
  containers called \emph{theory context} and \emph{proof context},
wenzelm@20429
   223
  respectively.  These model the main characteristics of the primitive
wenzelm@20429
   224
  @{text "\<Theta>"} and @{text "\<Gamma>"} above, without subscribing to any
wenzelm@20429
   225
  particular kind of content yet.  Instead, contexts merely impose a
wenzelm@20429
   226
  certain policy of managing arbitrary \emph{context data}.  The
wenzelm@20429
   227
  system provides strongly typed mechanisms to declare new kinds of
wenzelm@20429
   228
  data at compile time.
wenzelm@18537
   229
wenzelm@20429
   230
  Thus the internal bootstrap process of Isabelle/Pure eventually
wenzelm@20429
   231
  reaches a stage where certain data slots provide the logical content
wenzelm@20429
   232
  of @{text "\<Theta>"} and @{text "\<Gamma>"} sketched above, but this does not
wenzelm@20429
   233
  stop there!  Various additional data slots support all kinds of
wenzelm@20429
   234
  mechanisms that are not necessarily part of the core logic.
wenzelm@18537
   235
wenzelm@20429
   236
  For example, there would be data for canonical introduction and
wenzelm@20429
   237
  elimination rules for arbitrary operators (depending on the
wenzelm@20429
   238
  object-logic and application), which enables users to perform
wenzelm@20429
   239
  standard proof steps implicitly (cf.\ the @{text "rule"} method).
wenzelm@18537
   240
wenzelm@20429
   241
  Isabelle is able to bring forth more and more concepts successively.
wenzelm@20429
   242
  In particular, an object-logic like Isabelle/HOL continues the
wenzelm@20429
   243
  Isabelle/Pure setup by adding specific components for automated
wenzelm@20429
   244
  reasoning (classical reasoner, tableau prover, structured induction
wenzelm@20429
   245
  etc.) and derived specification mechanisms (inductive predicates,
wenzelm@20429
   246
  recursive functions etc.).  All of this is based on the generic data
wenzelm@20429
   247
  management by theory and proof contexts.
wenzelm@18537
   248
*}
wenzelm@18537
   249
wenzelm@18537
   250
wenzelm@18537
   251
subsection {* Theory context \label{sec:context-theory} *}
wenzelm@18537
   252
wenzelm@20429
   253
text {*
wenzelm@20429
   254
  Each theory is explicitly named and holds a unique identifier.
wenzelm@20429
   255
  There is a separate \emph{theory reference} for pointing backwards
wenzelm@20429
   256
  to the enclosing theory context of derived entities.  Theories are
wenzelm@20429
   257
  related by a (nominal) sub-theory relation, which corresponds to the
wenzelm@20429
   258
  canonical dependency graph: each theory is derived from a certain
wenzelm@20429
   259
  sub-graph of ancestor theories.  The @{text "merge"} of two theories
wenzelm@20429
   260
  refers to the least upper bound, which actually degenerates into
wenzelm@20429
   261
  absorption of one theory into the other, due to the nominal
wenzelm@20429
   262
  sub-theory relation this.
wenzelm@18537
   263
wenzelm@20429
   264
  The @{text "begin"} operation starts a new theory by importing
wenzelm@20429
   265
  several parent theories and entering a special @{text "draft"} mode,
wenzelm@20429
   266
  which is sustained until the final @{text "end"} operation.  A draft
wenzelm@20429
   267
  mode theory acts like a linear type, where updates invalidate
wenzelm@20429
   268
  earlier drafts, but theory reference values will be propagated
wenzelm@20429
   269
  automatically.  Thus derived entities that ``belong'' to a draft
wenzelm@20429
   270
  might be transferred spontaneously to a larger context.  An
wenzelm@20429
   271
  invalidated draft is called ``stale''.  The @{text "copy"} operation
wenzelm@20429
   272
  produces an auxiliary version with the same data content, but is
wenzelm@20429
   273
  unrelated to the original: updates of the copy do not affect the
wenzelm@20429
   274
  original, neither does the sub-theory relation hold.
wenzelm@20429
   275
wenzelm@20429
   276
  The example below shows a theory graph derived from @{text "Pure"}.
wenzelm@20429
   277
  Theory @{text "Length"} imports @{text "Nat"} and @{text "List"}.
wenzelm@20429
   278
  The linear draft mode is enabled during the ``@{text "\<dots>"}'' stage of
wenzelm@20429
   279
  the theory body.
wenzelm@20429
   280
wenzelm@20429
   281
  \bigskip
wenzelm@20429
   282
  \begin{tabular}{rcccl}
wenzelm@18537
   283
        &            & $Pure$ \\
wenzelm@18537
   284
        &            & $\downarrow$ \\
wenzelm@18537
   285
        &            & $FOL$ \\
wenzelm@18537
   286
        & $\swarrow$ &              & $\searrow$ & \\
wenzelm@18537
   287
  $Nat$ &            &              &            & $List$ \\
wenzelm@18537
   288
        & $\searrow$ &              & $\swarrow$ \\
wenzelm@18537
   289
        &            & $Length$ \\
wenzelm@18537
   290
        &            & \multicolumn{3}{l}{~~$\isarkeyword{imports}$} \\
wenzelm@18537
   291
        &            & \multicolumn{3}{l}{~~$\isarkeyword{begin}$} \\
wenzelm@18537
   292
        &            & $\vdots$~~ \\
wenzelm@18537
   293
        &            & \multicolumn{3}{l}{~~$\isarkeyword{end}$} \\
wenzelm@20429
   294
  \end{tabular}
wenzelm@20429
   295
wenzelm@20429
   296
  \medskip In practice, derived theory operations mostly operate
wenzelm@20429
   297
  drafts, namely the body of the current portion of theory that the
wenzelm@20429
   298
  user happens to be composing.
wenzelm@18537
   299
wenzelm@20429
   300
 \medskip There is also a builtin theory history mechanism that amends for
wenzelm@20429
   301
  the destructive behaviour of theory drafts.  The @{text
wenzelm@20429
   302
  "checkpoint"} operation produces an intermediate stepping stone that
wenzelm@20429
   303
  survives the next update unscathed: both the original and the
wenzelm@20429
   304
  changed theory remain valid and are related by the sub-theory
wenzelm@20429
   305
  relation.  This recovering of pure theory values comes at the cost
wenzelm@20429
   306
  of extra internal bookeeping.  The cumulative effect of
wenzelm@20429
   307
  checkpointing is purged by the @{text "finish"} operation.
wenzelm@18537
   308
wenzelm@20429
   309
  History operations are usually managed by the system, e.g.\ notably
wenzelm@20429
   310
  in the Isar transaction loop.
wenzelm@18537
   311
wenzelm@20429
   312
  \medskip
wenzelm@20429
   313
  FIXME theory data
wenzelm@18537
   314
*}
wenzelm@18537
   315
wenzelm@20430
   316
text %mlref {*
wenzelm@20430
   317
*}
wenzelm@20430
   318
wenzelm@18537
   319
wenzelm@18537
   320
subsection {* Proof context \label{sec:context-proof} *}
wenzelm@18537
   321
wenzelm@18537
   322
text {*
wenzelm@20429
   323
  A proof context is an arbitrary container that is initialized from a
wenzelm@20429
   324
  given theory.  The result contains a back-reference to the theory it
wenzelm@20429
   325
  belongs to, together with pure data.  No further bookkeeping is
wenzelm@20429
   326
  required here, thanks to the lack of destructive features.
wenzelm@20429
   327
wenzelm@20429
   328
  There is no restriction on producing proof contexts, although the
wenzelm@20429
   329
  usual discipline is to follow block structure as a mental model: a
wenzelm@20429
   330
  given context is extended consecutively, results are exported back
wenzelm@20429
   331
  into the original context.  In particular, the concept of Isar proof
wenzelm@20429
   332
  state models block-structured reasoning explicitly, using a stack of
wenzelm@20429
   333
  proof contexts.
wenzelm@20429
   334
wenzelm@20429
   335
  Due to the lack of identification and back-referencing, entities
wenzelm@20429
   336
  derived in a proof context need to record inherent logical
wenzelm@20429
   337
  requirements explicitly.  For example, hypotheses used in a
wenzelm@20429
   338
  derivation will be recorded separately within the sequent @{text "\<Gamma>
wenzelm@20429
   339
  \<turnstile> \<phi>"}, just to make double sure.  Results could leak into an alien
wenzelm@20429
   340
  proof context do to programming errors, but Isabelle/Isar
wenzelm@20429
   341
  occasionally includes extra validity checks at the end of a
wenzelm@20429
   342
  sub-proof.
wenzelm@20429
   343
wenzelm@20429
   344
  \medskip
wenzelm@20429
   345
  FIXME proof data
wenzelm@18537
   346
wenzelm@18537
   347
\glossary{Proof context}{The static context of a structured proof,
wenzelm@18537
   348
acts like a local ``theory'' of the current portion of Isar proof
wenzelm@18537
   349
text, generalizes the idea of local hypotheses @{text "\<Gamma>"} in
wenzelm@18537
   350
judgments @{text "\<Gamma> \<turnstile> \<phi>"} of natural deduction calculi.  There is a
wenzelm@18537
   351
generic notion of introducing and discharging hypotheses.  Arbritrary
wenzelm@18537
   352
auxiliary context data may be adjoined.}
wenzelm@18537
   353
wenzelm@18537
   354
*}
wenzelm@18537
   355
wenzelm@20430
   356
text %mlref {* FIXME *}
wenzelm@20430
   357
wenzelm@20429
   358
wenzelm@20429
   359
subsection {* Generic contexts *}
wenzelm@20429
   360
wenzelm@20430
   361
text FIXME
wenzelm@20430
   362
wenzelm@20430
   363
text %mlref {* FIXME *}
wenzelm@20430
   364
wenzelm@18537
   365
end