lcp@104
|
1 |
%% $Id$
|
wenzelm@145
|
2 |
|
lcp@104
|
3 |
\chapter{Theories, Terms and Types} \label{theories}
|
lcp@104
|
4 |
\index{theories|(}\index{signatures|bold}
|
nipkow@478
|
5 |
\index{reading!axioms|see{{\tt assume_ax}}}
|
lcp@104
|
6 |
Theories organize the syntax, declarations and axioms of a mathematical
|
lcp@104
|
7 |
development. They are built, starting from the Pure theory, by extending
|
lcp@324
|
8 |
and merging existing theories. They have the \ML\ type \mltydx{theory}.
|
lcp@324
|
9 |
Theory operations signal errors by raising exception \xdx{THEORY},
|
lcp@104
|
10 |
returning a message and a list of theories.
|
lcp@104
|
11 |
|
lcp@104
|
12 |
Signatures, which contain information about sorts, types, constants and
|
lcp@332
|
13 |
syntax, have the \ML\ type~\mltydx{Sign.sg}. For identification, each
|
wenzelm@864
|
14 |
signature carries a unique list of \bfindex{stamps}, which are \ML\
|
lcp@324
|
15 |
references to strings. The strings serve as human-readable names; the
|
lcp@104
|
16 |
references serve as unique identifiers. Each primitive signature has a
|
lcp@104
|
17 |
single stamp. When two signatures are merged, their lists of stamps are
|
lcp@104
|
18 |
also merged. Every theory carries a unique signature.
|
lcp@104
|
19 |
|
lcp@104
|
20 |
Terms and types are the underlying representation of logical syntax. Their
|
nipkow@275
|
21 |
\ML\ definitions are irrelevant to naive Isabelle users. Programmers who
|
nipkow@275
|
22 |
wish to extend Isabelle may need to know such details, say to code a tactic
|
nipkow@275
|
23 |
that looks for subgoals of a particular form. Terms and types may be
|
lcp@104
|
24 |
`certified' to be well-formed with respect to a given signature.
|
lcp@104
|
25 |
|
lcp@324
|
26 |
|
lcp@324
|
27 |
\section{Defining theories}\label{sec:ref-defining-theories}
|
lcp@104
|
28 |
|
wenzelm@864
|
29 |
Theories are usually defined using theory definition files (which have a name
|
wenzelm@864
|
30 |
suffix {\tt .thy}). There is also a low level interface provided by certain
|
wenzelm@864
|
31 |
\ML{} functions (see \S\ref{BuildingATheory}).
|
wenzelm@864
|
32 |
Appendix~\ref{app:TheorySyntax} presents the concrete syntax for theory
|
wenzelm@864
|
33 |
definitions; here is an explanation of the constituent parts:
|
wenzelm@864
|
34 |
\begin{description}
|
wenzelm@864
|
35 |
\item[{\it theoryDef}]
|
lcp@324
|
36 |
is the full definition. The new theory is called $id$. It is the union
|
lcp@324
|
37 |
of the named {\bf parent theories}\indexbold{theories!parent}, possibly
|
lcp@324
|
38 |
extended with new classes, etc. The basic theory, which contains only
|
lcp@324
|
39 |
the meta-logic, is called \thydx{Pure}.
|
clasohm@138
|
40 |
|
wenzelm@864
|
41 |
Normally each {\it name\/} is an identifier, the name of the parent theory.
|
wenzelm@864
|
42 |
Quoted strings can be used to document additional file dependencies; see
|
nipkow@275
|
43 |
\S\ref{LoadingTheories} for details.
|
lcp@324
|
44 |
|
wenzelm@864
|
45 |
\item[$classes$]
|
wenzelm@864
|
46 |
is a series of class declarations. Declaring {\tt$id$ < $id@1$ \dots\
|
lcp@324
|
47 |
$id@n$} makes $id$ a subclass of the existing classes $id@1\dots
|
lcp@324
|
48 |
id@n$. This rules out cyclic class structures. Isabelle automatically
|
lcp@324
|
49 |
computes the transitive closure of subclass hierarchies; it is not
|
lcp@324
|
50 |
necessary to declare {\tt c < e} in addition to {\tt c < d} and {\tt d <
|
lcp@324
|
51 |
e}.
|
lcp@324
|
52 |
|
wenzelm@864
|
53 |
\item[$default$]
|
wenzelm@864
|
54 |
introduces $sort$ as the new default sort for type variables. This applies
|
wenzelm@864
|
55 |
to unconstrained type variables in an input string but not to type
|
wenzelm@864
|
56 |
variables created internally. If omitted, the default sort is the listwise
|
wenzelm@864
|
57 |
union of the default sorts of the parent theories (i.e.\ their logical
|
wenzelm@864
|
58 |
intersection).
|
lcp@324
|
59 |
|
wenzelm@864
|
60 |
\item[$sort$]
|
lcp@324
|
61 |
is a finite set of classes. A single class $id$ abbreviates the singleton
|
lcp@324
|
62 |
set {\tt\{}$id${\tt\}}.
|
lcp@324
|
63 |
|
wenzelm@864
|
64 |
\item[$types$]
|
lcp@324
|
65 |
is a series of type declarations. Each declares a new type constructor
|
lcp@324
|
66 |
or type synonym. An $n$-place type constructor is specified by
|
lcp@324
|
67 |
$(\alpha@1,\dots,\alpha@n)name$, where the type variables serve only to
|
lcp@324
|
68 |
indicate the number~$n$.
|
lcp@324
|
69 |
|
lcp@332
|
70 |
A {\bf type synonym}\indexbold{type synonyms} is an abbreviation
|
clasohm@1387
|
71 |
$(\alpha@1,\dots,\alpha@n)name = \tau$, where $name$ and $\tau$ can
|
clasohm@1387
|
72 |
be strings.
|
wenzelm@864
|
73 |
|
wenzelm@864
|
74 |
\item[$infix$]
|
lcp@324
|
75 |
declares a type or constant to be an infix operator of priority $nat$
|
wenzelm@864
|
76 |
associating to the left ({\tt infixl}) or right ({\tt infixr}). Only
|
wenzelm@864
|
77 |
2-place type constructors can have infix status; an example is {\tt
|
wenzelm@864
|
78 |
('a,'b)~"*"~(infixr~20)}, which expresses binary product types.
|
lcp@324
|
79 |
|
wenzelm@864
|
80 |
\item[$arities$]
|
lcp@324
|
81 |
is a series of arity declarations. Each assigns arities to type
|
lcp@324
|
82 |
constructors. The $name$ must be an existing type constructor, which is
|
nipkow@273
|
83 |
given the additional arity $arity$.
|
lcp@324
|
84 |
|
wenzelm@864
|
85 |
\item[$constDecl$]
|
lcp@324
|
86 |
is a series of constant declarations. Each new constant $name$ is given
|
clasohm@1380
|
87 |
the specified type. The optional $mixfix$ annotations may
|
wenzelm@864
|
88 |
attach concrete syntax to the constant. A variant of {\tt consts} is the
|
wenzelm@864
|
89 |
{\tt syntax} section\index{*syntax section}, which adds just syntax without
|
wenzelm@864
|
90 |
declaring logical constants.
|
lcp@324
|
91 |
|
lcp@324
|
92 |
\item[$mixfix$] \index{mixfix declarations}
|
lcp@324
|
93 |
annotations can take three forms:
|
nipkow@273
|
94 |
\begin{itemize}
|
nipkow@273
|
95 |
\item A mixfix template given as a $string$ of the form
|
nipkow@273
|
96 |
{\tt"}\dots{\tt\_}\dots{\tt\_}\dots{\tt"} where the $i$-th underscore
|
lcp@324
|
97 |
indicates the position where the $i$-th argument should go. The list
|
lcp@324
|
98 |
of numbers gives the priority of each argument. The final number gives
|
lcp@324
|
99 |
the priority of the whole construct.
|
lcp@104
|
100 |
|
lcp@324
|
101 |
\item A constant $f$ of type $\tau@1\To(\tau@2\To\tau)$ can be given {\bf
|
lcp@324
|
102 |
infix} status.
|
lcp@104
|
103 |
|
lcp@324
|
104 |
\item A constant $f$ of type $(\tau@1\To\tau@2)\To\tau$ can be given {\bf
|
lcp@324
|
105 |
binder} status. The declaration {\tt binder} $\cal Q$ $p$ causes
|
lcp@286
|
106 |
${\cal Q}\,x.F(x)$ to be treated
|
lcp@286
|
107 |
like $f(F)$, where $p$ is the priority.
|
nipkow@273
|
108 |
\end{itemize}
|
lcp@324
|
109 |
|
wenzelm@864
|
110 |
\item[$trans$]
|
wenzelm@864
|
111 |
specifies syntactic translation rules (macros). There are three forms:
|
wenzelm@864
|
112 |
parse rules ({\tt =>}), print rules ({\tt <=}), and parse/print rules ({\tt
|
wenzelm@864
|
113 |
==}).
|
lcp@324
|
114 |
|
nipkow@1650
|
115 |
\item[$rules$]
|
wenzelm@864
|
116 |
is a series of rule declarations. Each has a name $id$ and the formula is
|
wenzelm@864
|
117 |
given by the $string$. Rule names must be distinct within any single
|
wenzelm@864
|
118 |
theory file.
|
lcp@324
|
119 |
|
nipkow@1650
|
120 |
\item[$defs$]
|
nipkow@1650
|
121 |
is a series of definitions. Just like $rules$, except that every $string$
|
nipkow@1650
|
122 |
must be a definition.
|
nipkow@1650
|
123 |
|
nipkow@1650
|
124 |
\item[$constdefs$] combines the declaration of constants and their
|
nipkow@1650
|
125 |
definition. The first $string$ is the type, the second the definition.
|
nipkow@1650
|
126 |
|
lcp@324
|
127 |
\item[$ml$] \index{*ML section}
|
wenzelm@864
|
128 |
consists of \ML\ code, typically for parse and print translation functions.
|
lcp@104
|
129 |
\end{description}
|
lcp@324
|
130 |
%
|
wenzelm@864
|
131 |
Chapters~\ref{Defining-Logics} and \ref{chap:syntax} explain mixfix
|
wenzelm@864
|
132 |
declarations, translation rules and the {\tt ML} section in more detail.
|
wenzelm@145
|
133 |
|
wenzelm@145
|
134 |
|
nipkow@275
|
135 |
\subsection{*Classes and arities}
|
lcp@324
|
136 |
\index{classes!context conditions}\index{arities!context conditions}
|
wenzelm@145
|
137 |
|
lcp@286
|
138 |
In order to guarantee principal types~\cite{nipkow-prehofer},
|
lcp@324
|
139 |
arity declarations must obey two conditions:
|
wenzelm@145
|
140 |
\begin{itemize}
|
lcp@286
|
141 |
\item There must be no two declarations $ty :: (\vec{r})c$ and $ty ::
|
lcp@286
|
142 |
(\vec{s})c$ with $\vec{r} \neq \vec{s}$. For example, the following is
|
lcp@286
|
143 |
forbidden:
|
wenzelm@145
|
144 |
\begin{ttbox}
|
wenzelm@864
|
145 |
types
|
wenzelm@864
|
146 |
'a ty
|
wenzelm@864
|
147 |
arities
|
wenzelm@864
|
148 |
ty :: ({\ttlbrace}logic{\ttrbrace}) logic
|
wenzelm@864
|
149 |
ty :: ({\ttlbrace}{\ttrbrace})logic
|
wenzelm@145
|
150 |
\end{ttbox}
|
lcp@286
|
151 |
|
wenzelm@145
|
152 |
\item If there are two declarations $ty :: (s@1,\dots,s@n)c$ and $ty ::
|
wenzelm@145
|
153 |
(s@1',\dots,s@n')c'$ such that $c' < c$ then $s@i' \preceq s@i$ must hold
|
wenzelm@145
|
154 |
for $i=1,\dots,n$. The relationship $\preceq$, defined as
|
wenzelm@145
|
155 |
\[ s' \preceq s \iff \forall c\in s. \exists c'\in s'.~ c'\le c, \]
|
wenzelm@145
|
156 |
expresses that the set of types represented by $s'$ is a subset of the set of
|
lcp@286
|
157 |
types represented by $s$. For example, the following is forbidden:
|
wenzelm@145
|
158 |
\begin{ttbox}
|
wenzelm@864
|
159 |
classes
|
wenzelm@864
|
160 |
term < logic
|
wenzelm@864
|
161 |
types
|
wenzelm@864
|
162 |
'a ty
|
wenzelm@864
|
163 |
arities
|
wenzelm@864
|
164 |
ty :: ({\ttlbrace}logic{\ttrbrace})logic
|
wenzelm@864
|
165 |
ty :: ({\ttlbrace}{\ttrbrace})term
|
wenzelm@145
|
166 |
\end{ttbox}
|
lcp@286
|
167 |
|
wenzelm@145
|
168 |
\end{itemize}
|
wenzelm@145
|
169 |
|
lcp@104
|
170 |
|
lcp@324
|
171 |
\section{Loading a new theory}\label{LoadingTheories}
|
lcp@324
|
172 |
\index{theories!loading}\index{files!reading}
|
wenzelm@864
|
173 |
\begin{ttbox}
|
lcp@286
|
174 |
use_thy : string -> unit
|
lcp@286
|
175 |
time_use_thy : string -> unit
|
lcp@286
|
176 |
loadpath : string list ref \hfill{\bf initially {\tt["."]}}
|
lcp@286
|
177 |
delete_tmpfiles : bool ref \hfill{\bf initially true}
|
lcp@286
|
178 |
\end{ttbox}
|
nipkow@275
|
179 |
|
lcp@324
|
180 |
\begin{ttdescription}
|
wenzelm@864
|
181 |
\item[\ttindexbold{use_thy} $thyname$]
|
lcp@286
|
182 |
reads the theory $thyname$ and creates an \ML{} structure as described below.
|
clasohm@138
|
183 |
|
wenzelm@864
|
184 |
\item[\ttindexbold{time_use_thy} $thyname$]
|
lcp@286
|
185 |
calls {\tt use_thy} $thyname$ and reports the time taken.
|
lcp@286
|
186 |
|
wenzelm@864
|
187 |
\item[\ttindexbold{loadpath}]
|
lcp@286
|
188 |
contains a list of directories to search when locating the files that
|
lcp@286
|
189 |
define a theory. This list is only used if the theory name in {\tt
|
lcp@286
|
190 |
use_thy} does not specify the path explicitly.
|
lcp@286
|
191 |
|
wenzelm@864
|
192 |
\item[\ttindexbold{delete_tmpfiles} := false;]
|
lcp@286
|
193 |
suppresses the deletion of temporary files.
|
lcp@324
|
194 |
\end{ttdescription}
|
lcp@286
|
195 |
%
|
lcp@104
|
196 |
Each theory definition must reside in a separate file. Let the file {\it
|
lcp@332
|
197 |
T}{\tt.thy} contain the definition of a theory called~$T$, whose parent
|
lcp@332
|
198 |
theories are $TB@1$ \dots $TB@n$. Calling \ttindexbold{use_thy}~{\tt"{\it
|
lcp@332
|
199 |
T\/}"} reads the file {\it T}{\tt.thy}, writes a temporary \ML{}
|
lcp@332
|
200 |
file {\tt.{\it T}.thy.ML}, and reads the latter file. Recursive {\tt
|
lcp@286
|
201 |
use_thy} calls load those parent theories that have not been loaded
|
lcp@332
|
202 |
previously; the recursive calls may continue to any depth. One {\tt use_thy}
|
lcp@332
|
203 |
call can read an entire logic provided all theories are linked appropriately.
|
clasohm@138
|
204 |
|
wenzelm@864
|
205 |
The result is an \ML\ structure~$T$ containing at least a component {\tt thy}
|
wenzelm@864
|
206 |
for the new theory and components for each of the rules. The structure also
|
lcp@332
|
207 |
contains the definitions of the {\tt ML} section, if present. The file
|
wenzelm@864
|
208 |
{\tt.{\it T}.thy.ML} is then deleted if {\tt delete_tmpfiles} is set to {\tt
|
wenzelm@864
|
209 |
true} and no errors occurred.
|
clasohm@138
|
210 |
|
lcp@332
|
211 |
Finally the file {\it T}{\tt.ML} is read, if it exists. This file normally
|
lcp@332
|
212 |
begins with the declaration {\tt open~$T$} and contains proofs involving
|
lcp@332
|
213 |
the new theory.
|
clasohm@138
|
214 |
|
wenzelm@864
|
215 |
Some applications construct theories directly by calling \ML\ functions. In
|
wenzelm@864
|
216 |
this situation there is no {\tt.thy} file, only an {\tt.ML} file. The
|
wenzelm@864
|
217 |
{\tt.ML} file must declare an \ML\ structure having the theory's name and a
|
wenzelm@864
|
218 |
component {\tt thy} containing the new theory object.
|
wenzelm@864
|
219 |
Section~\ref{sec:pseudo-theories} below describes a way of linking such
|
wenzelm@864
|
220 |
theories to their parents.
|
lcp@159
|
221 |
|
lcp@324
|
222 |
\begin{warn}
|
wenzelm@864
|
223 |
Temporary files are written to the current directory, so this must be
|
wenzelm@864
|
224 |
writable. Isabelle inherits the current directory from the operating
|
wenzelm@864
|
225 |
system; you can change it within Isabelle by typing {\tt
|
wenzelm@864
|
226 |
cd"$dir$"}\index{*cd}.
|
lcp@324
|
227 |
\end{warn}
|
clasohm@138
|
228 |
|
lcp@324
|
229 |
|
lcp@324
|
230 |
\section{Reloading modified theories}\label{sec:reloading-theories}
|
lcp@324
|
231 |
\indexbold{theories!reloading}
|
wenzelm@864
|
232 |
\begin{ttbox}
|
lcp@286
|
233 |
update : unit -> unit
|
lcp@286
|
234 |
unlink_thy : string -> unit
|
lcp@286
|
235 |
\end{ttbox}
|
lcp@332
|
236 |
Changing a theory on disk often makes it necessary to reload all theories
|
lcp@332
|
237 |
descended from it. However, {\tt use_thy} reads only one theory, even if
|
lcp@332
|
238 |
some of the parent theories are out of date. In this case you should call
|
lcp@332
|
239 |
{\tt update()}.
|
lcp@332
|
240 |
|
lcp@286
|
241 |
Isabelle keeps track of all loaded theories and their files. If
|
lcp@286
|
242 |
\ttindex{use_thy} finds that the theory to be loaded has been read before,
|
lcp@286
|
243 |
it determines whether to reload the theory as follows. First it looks for
|
lcp@286
|
244 |
the theory's files in their previous location. If it finds them, it
|
lcp@286
|
245 |
compares their modification times to the internal data and stops if they
|
lcp@286
|
246 |
are equal. If the files have been moved, {\tt use_thy} searches for them
|
lcp@286
|
247 |
as it would for a new theory. After {\tt use_thy} reloads a theory, it
|
lcp@286
|
248 |
marks the children as out-of-date.
|
clasohm@138
|
249 |
|
lcp@324
|
250 |
\begin{ttdescription}
|
wenzelm@864
|
251 |
\item[\ttindexbold{update}()]
|
wenzelm@864
|
252 |
reloads all modified theories and their descendants in the correct order.
|
clasohm@138
|
253 |
|
lcp@286
|
254 |
\item[\ttindexbold{unlink_thy} $thyname$]\indexbold{theories!removing}
|
lcp@286
|
255 |
informs Isabelle that theory $thyname$ no longer exists. If you delete the
|
lcp@286
|
256 |
theory files for $thyname$ then you must execute {\tt unlink_thy};
|
lcp@286
|
257 |
otherwise {\tt update} will complain about a missing file.
|
lcp@324
|
258 |
\end{ttdescription}
|
clasohm@138
|
259 |
|
lcp@286
|
260 |
|
lcp@332
|
261 |
\goodbreak
|
lcp@324
|
262 |
\subsection{Important note for Poly/ML users}\index{Poly/{\ML} compiler}
|
lcp@286
|
263 |
The theory mechanism depends upon reference variables. At the end of a
|
lcp@286
|
264 |
Poly/\ML{} session, the contents of references are lost unless they are
|
wenzelm@864
|
265 |
declared in the current database. In particular, assignments to references
|
wenzelm@864
|
266 |
of the {\tt Pure} database are lost, including all information about loaded
|
wenzelm@864
|
267 |
theories. To avoid losing this information simply call
|
lcp@286
|
268 |
\begin{ttbox}
|
nipkow@478
|
269 |
init_thy_reader();
|
lcp@286
|
270 |
\end{ttbox}
|
nipkow@478
|
271 |
when building the new database.
|
lcp@286
|
272 |
|
lcp@286
|
273 |
|
lcp@332
|
274 |
\subsection{*Pseudo theories}\label{sec:pseudo-theories}
|
lcp@332
|
275 |
\indexbold{theories!pseudo}%
|
nipkow@275
|
276 |
Any automatic reloading facility requires complete knowledge of all
|
lcp@286
|
277 |
dependencies. Sometimes theories depend on objects created in \ML{} files
|
wenzelm@864
|
278 |
with no associated theory definition file. These objects may be theories but
|
wenzelm@864
|
279 |
they could also be theorems, proof procedures, etc.
|
lcp@332
|
280 |
|
lcp@332
|
281 |
Unless such dependencies are documented, {\tt update} fails to reload these
|
lcp@332
|
282 |
\ML{} files and the system is left in a state where some objects, such as
|
lcp@332
|
283 |
theorems, still refer to old versions of theories. This may lead to the
|
lcp@332
|
284 |
error
|
nipkow@275
|
285 |
\begin{ttbox}
|
wenzelm@864
|
286 |
Attempt to merge different versions of theories: \dots
|
nipkow@275
|
287 |
\end{ttbox}
|
lcp@324
|
288 |
Therefore there is a way to link theories and {\bf orphaned} \ML{} files ---
|
wenzelm@864
|
289 |
those not associated with a theory definition.
|
clasohm@138
|
290 |
|
lcp@324
|
291 |
Let us assume we have an orphaned \ML{} file named {\tt orphan.ML} and a
|
lcp@332
|
292 |
theory~$B$ that depends on {\tt orphan.ML} --- for example, {\tt B.ML} uses
|
lcp@332
|
293 |
theorems proved in {\tt orphan.ML}. Then {\tt B.thy} should
|
wenzelm@864
|
294 |
mention this dependency as follows:
|
clasohm@138
|
295 |
\begin{ttbox}
|
wenzelm@864
|
296 |
B = \(\ldots\) + "orphan" + \(\ldots\)
|
clasohm@138
|
297 |
\end{ttbox}
|
clasohm@1369
|
298 |
Quoted strings stand for theories which have to be loaded before the
|
clasohm@1369
|
299 |
current theory is read but which are not used in building the base of
|
clasohm@1369
|
300 |
theory~$B$. Whenever {\tt orphan} changes and is reloaded, Isabelle
|
clasohm@1369
|
301 |
knows that $B$ has to be updated, too.
|
nipkow@275
|
302 |
|
clasohm@1369
|
303 |
Note that it's necessary for {\tt orphan} to declare a special ML
|
clasohm@1369
|
304 |
object of type {\tt theory} which is present in all theories. This is
|
clasohm@1369
|
305 |
normally achieved by adding the file {\tt orphan.thy} to make {\tt
|
clasohm@1369
|
306 |
orphan} a {\bf pseudo theory}. A minimum version of {\tt orphan.thy}
|
clasohm@1369
|
307 |
would be
|
clasohm@1369
|
308 |
|
clasohm@1369
|
309 |
\begin{ttbox}
|
clasohm@1369
|
310 |
orphan = Pure
|
clasohm@1369
|
311 |
\end{ttbox}
|
clasohm@1369
|
312 |
|
clasohm@1369
|
313 |
which uses {\tt Pure} to make a dummy theory. Normally though the
|
clasohm@1369
|
314 |
orphaned file has its own dependencies. If {\tt orphan.ML} depends on
|
clasohm@1369
|
315 |
theories or files $A@1$, \ldots, $A@n$, record this by creating the
|
clasohm@1369
|
316 |
pseudo theory in the following way:
|
nipkow@275
|
317 |
\begin{ttbox}
|
wenzelm@864
|
318 |
orphan = \(A@1\) + \(\ldots\) + \(A@n\)
|
nipkow@275
|
319 |
\end{ttbox}
|
clasohm@1369
|
320 |
The resulting theory ensures that {\tt update} reloads {\tt orphan}
|
clasohm@1369
|
321 |
whenever it reloads one of the $A@i$.
|
clasohm@138
|
322 |
|
wenzelm@864
|
323 |
For an extensive example of how this technique can be used to link lots of
|
wenzelm@864
|
324 |
theory files and load them by just a few {\tt use_thy} calls, consult the
|
wenzelm@864
|
325 |
sources of \ZF{} set theory.
|
clasohm@138
|
326 |
|
lcp@104
|
327 |
|
lcp@104
|
328 |
|
clasohm@866
|
329 |
\section{Basic operations on theories}\label{BasicOperationsOnTheories}
|
wenzelm@864
|
330 |
\subsection{Extracting an axiom or theorem from a theory}
|
lcp@324
|
331 |
\index{theories!axioms of}\index{axioms!extracting}
|
wenzelm@864
|
332 |
\index{theories!theorems of}\index{theorems!extracting}
|
wenzelm@864
|
333 |
\begin{ttbox}
|
wenzelm@864
|
334 |
get_axiom : theory -> string -> thm
|
wenzelm@864
|
335 |
get_thm : theory -> string -> thm
|
wenzelm@864
|
336 |
assume_ax : theory -> string -> thm
|
lcp@104
|
337 |
\end{ttbox}
|
lcp@324
|
338 |
\begin{ttdescription}
|
wenzelm@864
|
339 |
\item[\ttindexbold{get_axiom} $thy$ $name$]
|
clasohm@866
|
340 |
returns an axiom with the given $name$ from $thy$, raising exception
|
clasohm@866
|
341 |
\xdx{THEORY} if none exists. Merging theories can cause several axioms
|
clasohm@866
|
342 |
to have the same name; {\tt get_axiom} returns an arbitrary one.
|
lcp@104
|
343 |
|
wenzelm@864
|
344 |
\item[\ttindexbold{get_thm} $thy$ $name$]
|
clasohm@866
|
345 |
is analogous to {\tt get_axiom}, but looks for a stored theorem. Like
|
clasohm@866
|
346 |
{\tt get_axiom} it searches all parents of a theory if the theorem
|
clasohm@866
|
347 |
is not associated with $thy$.
|
wenzelm@864
|
348 |
|
wenzelm@864
|
349 |
\item[\ttindexbold{assume_ax} $thy$ $formula$]
|
lcp@286
|
350 |
reads the {\it formula} using the syntax of $thy$, following the same
|
lcp@286
|
351 |
conventions as axioms in a theory definition. You can thus pretend that
|
lcp@286
|
352 |
{\it formula} is an axiom and use the resulting theorem like an axiom.
|
lcp@286
|
353 |
Actually {\tt assume_ax} returns an assumption; \ttindex{result}
|
lcp@286
|
354 |
complains about additional assumptions, but \ttindex{uresult} does not.
|
lcp@104
|
355 |
|
lcp@104
|
356 |
For example, if {\it formula} is
|
lcp@332
|
357 |
\hbox{\tt a=b ==> b=a} then the resulting theorem has the form
|
lcp@332
|
358 |
\hbox{\verb'?a=?b ==> ?b=?a [!!a b. a=b ==> b=a]'}
|
lcp@324
|
359 |
\end{ttdescription}
|
lcp@104
|
360 |
|
lcp@286
|
361 |
\subsection{Building a theory}
|
lcp@286
|
362 |
\label{BuildingATheory}
|
lcp@286
|
363 |
\index{theories!constructing|bold}
|
wenzelm@864
|
364 |
\begin{ttbox}
|
lcp@332
|
365 |
pure_thy : theory
|
lcp@332
|
366 |
merge_theories : theory * theory -> theory
|
lcp@286
|
367 |
\end{ttbox}
|
lcp@324
|
368 |
\begin{ttdescription}
|
wenzelm@864
|
369 |
\item[\ttindexbold{pure_thy}] contains just the syntax and signature
|
lcp@286
|
370 |
of the meta-logic. There are no axioms: meta-level inferences are carried
|
lcp@286
|
371 |
out by \ML\ functions.
|
lcp@286
|
372 |
\item[\ttindexbold{merge_theories} ($thy@1$, $thy@2$)] merges the two
|
wenzelm@864
|
373 |
theories $thy@1$ and $thy@2$. The resulting theory contains all of the
|
wenzelm@864
|
374 |
syntax, signature and axioms of the constituent theories. Merging theories
|
wenzelm@864
|
375 |
that contain different identification stamps of the same name fails with
|
wenzelm@864
|
376 |
the following message
|
wenzelm@864
|
377 |
\begin{ttbox}
|
wenzelm@864
|
378 |
Attempt to merge different versions of theories: "\(T@1\)", \(\ldots\), "\(T@n\)"
|
wenzelm@864
|
379 |
\end{ttbox}
|
wenzelm@864
|
380 |
This error may especially occur when a theory is redeclared --- say to
|
wenzelm@864
|
381 |
change an incorrect axiom --- and bindings to old versions persist.
|
wenzelm@864
|
382 |
Isabelle ensures that old and new theories of the same name are not
|
wenzelm@864
|
383 |
involved in a proof.
|
wenzelm@864
|
384 |
|
wenzelm@864
|
385 |
%% FIXME
|
nipkow@478
|
386 |
%\item [\ttindexbold{extend_theory} $thy$ {\tt"}$T${\tt"} $\cdots$] extends
|
nipkow@478
|
387 |
% the theory $thy$ with new types, constants, etc. $T$ identifies the theory
|
nipkow@478
|
388 |
% internally. When a theory is redeclared, say to change an incorrect axiom,
|
nipkow@478
|
389 |
% bindings to the old axiom may persist. Isabelle ensures that the old and
|
nipkow@478
|
390 |
% new theories are not involved in the same proof. Attempting to combine
|
nipkow@478
|
391 |
% different theories having the same name $T$ yields the fatal error
|
nipkow@478
|
392 |
%extend_theory : theory -> string -> \(\cdots\) -> theory
|
wenzelm@864
|
393 |
%\begin{ttbox}
|
wenzelm@864
|
394 |
%Attempt to merge different versions of theory: \(T\)
|
wenzelm@864
|
395 |
%\end{ttbox}
|
lcp@324
|
396 |
\end{ttdescription}
|
lcp@286
|
397 |
|
wenzelm@864
|
398 |
%% FIXME
|
nipkow@275
|
399 |
%\item [\ttindexbold{extend_theory} $thy$ {\tt"}$T${\tt"}
|
nipkow@275
|
400 |
% ($classes$, $default$, $types$, $arities$, $consts$, $sextopt$) $rules$]
|
nipkow@275
|
401 |
%\hfill\break %%% include if line is just too short
|
lcp@286
|
402 |
%is the \ML{} equivalent of the following theory definition:
|
nipkow@275
|
403 |
%\begin{ttbox}
|
nipkow@275
|
404 |
%\(T\) = \(thy\) +
|
nipkow@275
|
405 |
%classes \(c\) < \(c@1\),\(\dots\),\(c@m\)
|
nipkow@275
|
406 |
% \dots
|
nipkow@275
|
407 |
%default {\(d@1,\dots,d@r\)}
|
nipkow@275
|
408 |
%types \(tycon@1\),\dots,\(tycon@i\) \(n\)
|
nipkow@275
|
409 |
% \dots
|
nipkow@275
|
410 |
%arities \(tycon@1'\),\dots,\(tycon@j'\) :: (\(s@1\),\dots,\(s@n\))\(c\)
|
nipkow@275
|
411 |
% \dots
|
nipkow@275
|
412 |
%consts \(b@1\),\dots,\(b@k\) :: \(\tau\)
|
nipkow@275
|
413 |
% \dots
|
nipkow@275
|
414 |
%rules \(name\) \(rule\)
|
nipkow@275
|
415 |
% \dots
|
nipkow@275
|
416 |
%end
|
nipkow@275
|
417 |
%\end{ttbox}
|
nipkow@275
|
418 |
%where
|
nipkow@275
|
419 |
%\begin{tabular}[t]{l@{~=~}l}
|
nipkow@275
|
420 |
%$classes$ & \tt[("$c$",["$c@1$",\dots,"$c@m$"]),\dots] \\
|
nipkow@275
|
421 |
%$default$ & \tt["$d@1$",\dots,"$d@r$"]\\
|
nipkow@275
|
422 |
%$types$ & \tt[([$tycon@1$,\dots,$tycon@i$], $n$),\dots] \\
|
nipkow@275
|
423 |
%$arities$ & \tt[([$tycon'@1$,\dots,$tycon'@j$], ([$s@1$,\dots,$s@n$],$c$)),\dots]
|
nipkow@275
|
424 |
%\\
|
nipkow@275
|
425 |
%$consts$ & \tt[([$b@1$,\dots,$b@k$],$\tau$),\dots] \\
|
nipkow@275
|
426 |
%$rules$ & \tt[("$name$",$rule$),\dots]
|
nipkow@275
|
427 |
%\end{tabular}
|
lcp@104
|
428 |
|
lcp@104
|
429 |
|
wenzelm@864
|
430 |
\subsection{Inspecting a theory}\label{sec:inspct-thy}
|
lcp@104
|
431 |
\index{theories!inspecting|bold}
|
wenzelm@864
|
432 |
\begin{ttbox}
|
lcp@104
|
433 |
print_theory : theory -> unit
|
wenzelm@864
|
434 |
axioms_of : theory -> (string * thm) list
|
wenzelm@864
|
435 |
thms_of : theory -> (string * thm) list
|
lcp@104
|
436 |
parents_of : theory -> theory list
|
lcp@104
|
437 |
sign_of : theory -> Sign.sg
|
lcp@104
|
438 |
stamps_of_thy : theory -> string ref list
|
lcp@104
|
439 |
\end{ttbox}
|
wenzelm@864
|
440 |
These provide means of viewing a theory's components.
|
lcp@324
|
441 |
\begin{ttdescription}
|
wenzelm@864
|
442 |
\item[\ttindexbold{print_theory} $thy$]
|
wenzelm@864
|
443 |
prints the contents of $thy$ excluding the syntax related parts (which are
|
wenzelm@864
|
444 |
shown by {\tt print_syntax}). The output is quite verbose.
|
lcp@104
|
445 |
|
wenzelm@864
|
446 |
\item[\ttindexbold{axioms_of} $thy$]
|
wenzelm@864
|
447 |
returns the additional axioms of the most recent extend node of~$thy$.
|
lcp@104
|
448 |
|
wenzelm@864
|
449 |
\item[\ttindexbold{thms_of} $thy$]
|
clasohm@866
|
450 |
returns all theorems that are associated with $thy$.
|
wenzelm@864
|
451 |
|
wenzelm@864
|
452 |
\item[\ttindexbold{parents_of} $thy$]
|
wenzelm@864
|
453 |
returns the direct ancestors of~$thy$.
|
wenzelm@864
|
454 |
|
wenzelm@864
|
455 |
\item[\ttindexbold{sign_of} $thy$]
|
wenzelm@864
|
456 |
returns the signature associated with~$thy$. It is useful with functions
|
wenzelm@864
|
457 |
like {\tt read_instantiate_sg}, which take a signature as an argument.
|
lcp@104
|
458 |
|
lcp@104
|
459 |
\item[\ttindexbold{stamps_of_thy} $thy$]\index{signatures}
|
wenzelm@864
|
460 |
returns the identification \rmindex{stamps} of the signature associated
|
wenzelm@864
|
461 |
with~$thy$.
|
lcp@324
|
462 |
\end{ttdescription}
|
lcp@104
|
463 |
|
lcp@104
|
464 |
|
clasohm@1380
|
465 |
\section{Generating HTML documents}
|
clasohm@1369
|
466 |
\index{HTML|bold}
|
clasohm@1369
|
467 |
|
clasohm@1369
|
468 |
Isabelle is able to make HTML documents that show a theory's
|
clasohm@1369
|
469 |
definition, the theorems proved in its ML file and the relationship
|
clasohm@1369
|
470 |
with its ancestors and descendants. HTML stands for Hypertext Markup
|
clasohm@1369
|
471 |
Language and is used in the World Wide Web to represent text
|
clasohm@1380
|
472 |
containing images and links to other documents. Web browsers like
|
clasohm@1380
|
473 |
{\tt xmosaic} or {\tt netscape} are used to view these documents.
|
clasohm@1369
|
474 |
|
clasohm@1369
|
475 |
Besides the three HTML files that are made for every theory
|
clasohm@1369
|
476 |
(definition and theorems, ancestors, descendants), Isabelle stores
|
clasohm@1369
|
477 |
links to all theories in an index file. These indexes are themself
|
clasohm@1380
|
478 |
linked with other indexes to represent the hierarchic structure of
|
clasohm@1380
|
479 |
Isabelle's logics.
|
clasohm@1369
|
480 |
|
clasohm@1369
|
481 |
To make HTML files for logics that are part of the Isabelle
|
clasohm@1380
|
482 |
distribution, simply set the shell environment variable {\tt
|
clasohm@1380
|
483 |
MAKE_HTML} before compiling a logic. This works for single logics as
|
clasohm@1380
|
484 |
well as for the shell script {\tt make-all} (see
|
clasohm@1380
|
485 |
\ref{sec:shell-scripts}). To make HTML files for {\tt FOL} using a
|
clasohm@1380
|
486 |
{\tt csh} style shell, the following commands can be used:
|
clasohm@1380
|
487 |
|
clasohm@1380
|
488 |
\begin{ttbox}
|
clasohm@1380
|
489 |
cd FOL
|
clasohm@1380
|
490 |
setenv MAKE_HTML
|
clasohm@1380
|
491 |
make
|
clasohm@1380
|
492 |
\end{ttbox}
|
clasohm@1380
|
493 |
|
clasohm@1497
|
494 |
The databases made this way do not differ from the ones made with an
|
clasohm@1497
|
495 |
unset {\tt MAKE_HTML}; in particular no HTML files are written if the
|
clasohm@1497
|
496 |
database is used to manually load a theory.
|
clasohm@1497
|
497 |
|
clasohm@1497
|
498 |
As you will see below, the HTML generation is controlled by a boolean
|
clasohm@1497
|
499 |
reference variable. If you want to make databases which define this
|
clasohm@1497
|
500 |
variable's value as {\tt true} and where therefore HTML files are
|
clasohm@1497
|
501 |
written each time {\tt use_thy} is invoked, you have to set {\tt
|
clasohm@1497
|
502 |
MAKE_HTML} to ``{\tt true}'':
|
clasohm@1497
|
503 |
|
clasohm@1497
|
504 |
\begin{ttbox}
|
clasohm@1497
|
505 |
cd FOL
|
clasohm@1497
|
506 |
setenv MAKE_HTML true
|
clasohm@1497
|
507 |
make
|
clasohm@1497
|
508 |
\end{ttbox}
|
clasohm@1497
|
509 |
|
clasohm@1497
|
510 |
All theories loaded from within the {\tt FOL} database and all
|
clasohm@1497
|
511 |
databases derived from it will now cause HTML files to be written.
|
clasohm@1497
|
512 |
This behaviour can be changed by assigning a value of {\tt false} to
|
clasohm@1497
|
513 |
the boolean reference variable {\tt make_html}. Be careful when making
|
clasohm@1520
|
514 |
such databases publicly available since it means that your users will
|
clasohm@1520
|
515 |
generate HTML files though they might not intend to do so.
|
clasohm@1452
|
516 |
|
clasohm@1380
|
517 |
As some of Isabelle's logics are based on others (e.g. {\tt ZF} on
|
clasohm@1380
|
518 |
{\tt FOL}) and because the HTML files list a theory's ancestors, you
|
clasohm@1380
|
519 |
should not make HTML files for a logic if the HTML files for the base
|
clasohm@1380
|
520 |
logic do not exist. Otherwise some of the hypertext links might point
|
clasohm@1380
|
521 |
to non-existing documents.
|
clasohm@1380
|
522 |
|
clasohm@1380
|
523 |
The entry point to all logics is the {\tt index.html} file located in
|
clasohm@1380
|
524 |
Isabelle's main directory. You can also access a HTML version of the
|
clasohm@1380
|
525 |
distribution package at
|
clasohm@1369
|
526 |
|
clasohm@1369
|
527 |
\begin{ttbox}
|
clasohm@1369
|
528 |
http://www4.informatik.tu-muenchen.de/~nipkow/isabelle
|
clasohm@1369
|
529 |
\end{ttbox}
|
clasohm@1369
|
530 |
|
clasohm@1380
|
531 |
|
clasohm@1380
|
532 |
\subsection*{Manual HTML generation}
|
clasohm@1380
|
533 |
|
clasohm@1551
|
534 |
To manually control the generation of HTML files the following
|
clasohm@1551
|
535 |
commands and reference variables are used:
|
clasohm@1369
|
536 |
|
clasohm@1369
|
537 |
\begin{ttbox}
|
clasohm@1369
|
538 |
init_html : unit -> unit
|
clasohm@1369
|
539 |
make_html : bool ref
|
clasohm@1369
|
540 |
finish_html : unit -> unit
|
clasohm@1369
|
541 |
\end{ttbox}
|
clasohm@1369
|
542 |
|
clasohm@1369
|
543 |
\begin{ttdescription}
|
clasohm@1369
|
544 |
\item[\ttindexbold{init_html}]
|
clasohm@1369
|
545 |
activates the HTML facility. It stores the current working directory
|
clasohm@1380
|
546 |
as the place where the {\tt index.html} file for all theories loaded
|
clasohm@1380
|
547 |
afterwards will be stored.
|
clasohm@1369
|
548 |
|
clasohm@1369
|
549 |
\item[\ttindexbold{make_html}]
|
clasohm@1380
|
550 |
is a boolean reference variable read by {\tt use_thy} and other
|
clasohm@1380
|
551 |
functions to decide whether HTML files should be made. After you have
|
clasohm@1380
|
552 |
used {\tt init_html} you can manually change {\tt make_html}'s value
|
clasohm@1380
|
553 |
to temporarily disable HTML generation.
|
clasohm@1369
|
554 |
|
clasohm@1369
|
555 |
\item[\ttindexbold{finish_html}]
|
clasohm@1369
|
556 |
has to be called after all theories have been read that should be
|
clasohm@1380
|
557 |
listed in the current {\tt index.html} file. It reads a temporary
|
clasohm@1369
|
558 |
file with information about the theories read since the last use of
|
clasohm@1369
|
559 |
{\tt init_html} and makes the {\tt index.html} file. If {\tt
|
clasohm@1369
|
560 |
make_html} is {\tt false} nothing is done.
|
clasohm@1369
|
561 |
|
clasohm@1369
|
562 |
The indexes made by this function also contain a link to the {\tt
|
clasohm@1497
|
563 |
README} file if there exists one in the directory where the index is
|
clasohm@1380
|
564 |
stored. If there's a {\tt README.html} file it is used instead of
|
clasohm@1380
|
565 |
{\tt README}.
|
clasohm@1369
|
566 |
|
clasohm@1369
|
567 |
\end{ttdescription}
|
clasohm@1369
|
568 |
|
clasohm@1380
|
569 |
The above functions could be used in the following way:
|
clasohm@1369
|
570 |
|
clasohm@1380
|
571 |
\begin{ttbox}
|
clasohm@1380
|
572 |
init_html();
|
clasohm@1497
|
573 |
{\out Setting path for index.html to "/home/clasohm/isabelle/HOL"}
|
clasohm@1380
|
574 |
use_thy "List";
|
clasohm@1380
|
575 |
\dots
|
clasohm@1380
|
576 |
finish_html();
|
clasohm@1380
|
577 |
\end{ttbox}
|
clasohm@1380
|
578 |
|
clasohm@1380
|
579 |
Please note that HTML files are made only for those theories that are
|
clasohm@1380
|
580 |
read while {\tt make_html} is {\tt true}. These files may contain
|
clasohm@1380
|
581 |
links to theories that were read with a {\tt false} {\tt make_html}
|
clasohm@1380
|
582 |
and therefore point to non-existing files.
|
clasohm@1380
|
583 |
|
clasohm@1380
|
584 |
|
clasohm@1380
|
585 |
\subsection*{Extending or adding a logic}
|
clasohm@1380
|
586 |
|
clasohm@1380
|
587 |
If you add a new subdirectory to Isabelle's logics (or add a completly
|
clasohm@1380
|
588 |
new logic), you would have to call {\tt init_html} at the start of every
|
clasohm@1369
|
589 |
directory's {\tt ROOT.ML} file and {\tt finish_html} at the end of
|
clasohm@1369
|
590 |
it. This is automatically done if you use
|
clasohm@1369
|
591 |
|
clasohm@1380
|
592 |
\begin{ttbox}\index{use_dir}
|
clasohm@1369
|
593 |
use_dir : string -> unit
|
clasohm@1369
|
594 |
\end{ttbox}
|
clasohm@1369
|
595 |
|
clasohm@1369
|
596 |
This function takes a path as its parameter, changes the working
|
clasohm@1369
|
597 |
directory, calls {\tt init_html} if {\tt make_html} is {\tt true},
|
clasohm@1369
|
598 |
executes {\tt ROOT.ML}, and calls {\tt finish_html}. The {\tt
|
clasohm@1369
|
599 |
index.html} file written in this directory will be automatically
|
clasohm@1369
|
600 |
linked to the first index found in the (recursively searched)
|
clasohm@1369
|
601 |
superdirectories.
|
clasohm@1369
|
602 |
|
clasohm@1380
|
603 |
Instead of adding something like
|
clasohm@1380
|
604 |
|
clasohm@1380
|
605 |
\begin{ttbox}
|
clasohm@1380
|
606 |
use"ex/ROOT.ML";
|
clasohm@1380
|
607 |
\end{ttbox}
|
clasohm@1380
|
608 |
|
clasohm@1380
|
609 |
to the logic's makefile you have to use this:
|
clasohm@1380
|
610 |
|
clasohm@1380
|
611 |
\begin{ttbox}
|
clasohm@1380
|
612 |
use_dir"ex";
|
clasohm@1380
|
613 |
\end{ttbox}
|
clasohm@1380
|
614 |
|
clasohm@1380
|
615 |
Since {\tt use_dir} calls {\tt init_html} only if {\tt make_html} is
|
clasohm@1380
|
616 |
{\tt true} the generation of HTML files depends on the value this
|
clasohm@1380
|
617 |
reference variable has. It can either be inherited from the used \ML{}
|
clasohm@1380
|
618 |
database or set in the makefile before {\tt use_dir} is invoked,
|
clasohm@1380
|
619 |
e.g. to set it's value according to the environment variable {\tt
|
clasohm@1380
|
620 |
MAKE_HTML}.
|
clasohm@1380
|
621 |
|
clasohm@1380
|
622 |
The generated HTML files contain all theorems that were proved in the
|
clasohm@1380
|
623 |
theory's \ML{} file with {\tt qed}, {\tt qed_goal} and {\tt qed_goalw},
|
clasohm@1380
|
624 |
or stored with {\tt bind_thm} and {\tt store_thm}. Additionally there
|
clasohm@1380
|
625 |
is a hypertext link to the whole \ML{} file.
|
clasohm@1380
|
626 |
|
clasohm@1551
|
627 |
You can add section headings to the list of theorems by using
|
clasohm@1551
|
628 |
|
clasohm@1551
|
629 |
\begin{ttbox}\index{use_dir}
|
clasohm@1551
|
630 |
section: string -> unit
|
clasohm@1551
|
631 |
\end{ttbox}
|
clasohm@1551
|
632 |
|
clasohm@1551
|
633 |
in a theory's ML file, which converts a plain string to a HTML
|
clasohm@1551
|
634 |
heading and inserts it before the next theorem proved or stored with
|
clasohm@1551
|
635 |
one of the above functions. If {\tt make_html} is {\tt false} nothing
|
clasohm@1551
|
636 |
is done.
|
clasohm@1551
|
637 |
|
clasohm@1380
|
638 |
|
clasohm@1380
|
639 |
\subsection*{Using someone else's database}
|
clasohm@1380
|
640 |
|
clasohm@1380
|
641 |
To make them independent from their storage place, the HTML files only
|
clasohm@1380
|
642 |
contain relative paths which are derived from absolute ones like the
|
clasohm@1380
|
643 |
current working directory, {\tt gif_path} or {\tt base_path}. The
|
clasohm@1380
|
644 |
latter two are reference variables which are initialized at the time
|
clasohm@1380
|
645 |
when the {\tt Pure} database is made. Because you need write access
|
clasohm@1380
|
646 |
for the current directory to make HTML files and therefore (probably)
|
clasohm@1380
|
647 |
generate them in your home directory, the absolute {\tt base_path} is
|
clasohm@1380
|
648 |
not correct if you use someone else's database or a database derived
|
clasohm@1380
|
649 |
from it.
|
clasohm@1380
|
650 |
|
clasohm@1409
|
651 |
In that case you first should set {\tt base_path} to the value of {\em
|
clasohm@1409
|
652 |
your} Isabelle main directory, i.e. the directory that contains the
|
clasohm@1409
|
653 |
subdirectories where standard logics like {\tt FOL} and {\tt HOL} or
|
clasohm@1409
|
654 |
your own logics are stored. If you do not do this, the generated HTML
|
clasohm@1409
|
655 |
files will still be usable but may contain incomplete titles and lack
|
clasohm@1409
|
656 |
some hypertext links.
|
clasohm@1380
|
657 |
|
clasohm@1380
|
658 |
It's also a good idea to set {\tt gif_path} which points to the
|
clasohm@1380
|
659 |
directory containing two GIF images used in the HTML
|
clasohm@1380
|
660 |
documents. Normally this is the {\tt Tools} subdirectory of Isabelle's
|
clasohm@1380
|
661 |
main directory. While its value in general is still valid, your HTML
|
clasohm@1380
|
662 |
files would depend on files not owned by you. This prevents you from
|
clasohm@1380
|
663 |
changing the location of the HTML files (as they contain relative
|
clasohm@1380
|
664 |
paths) and also causes trouble if the database's maker (re)moves the
|
clasohm@1380
|
665 |
GIFs.
|
clasohm@1380
|
666 |
|
clasohm@1409
|
667 |
Here's what you should do before invoking {\tt init_html} using
|
clasohm@1380
|
668 |
someone else's \ML{} database:
|
clasohm@1380
|
669 |
|
clasohm@1380
|
670 |
\begin{ttbox}
|
clasohm@1380
|
671 |
base_path := "/home/smith/isabelle";
|
clasohm@1380
|
672 |
gif_path := "/home/smith/isabelle/Tools";
|
clasohm@1380
|
673 |
init_html();
|
clasohm@1380
|
674 |
\dots
|
clasohm@1380
|
675 |
\end{ttbox}
|
clasohm@1369
|
676 |
|
lcp@104
|
677 |
\section{Terms}
|
lcp@104
|
678 |
\index{terms|bold}
|
lcp@324
|
679 |
Terms belong to the \ML\ type \mltydx{term}, which is a concrete datatype
|
lcp@104
|
680 |
with six constructors: there are six kinds of term.
|
lcp@104
|
681 |
\begin{ttbox}
|
lcp@104
|
682 |
type indexname = string * int;
|
lcp@104
|
683 |
infix 9 $;
|
lcp@104
|
684 |
datatype term = Const of string * typ
|
lcp@104
|
685 |
| Free of string * typ
|
lcp@104
|
686 |
| Var of indexname * typ
|
lcp@104
|
687 |
| Bound of int
|
lcp@104
|
688 |
| Abs of string * typ * term
|
lcp@104
|
689 |
| op $ of term * term;
|
lcp@104
|
690 |
\end{ttbox}
|
lcp@324
|
691 |
\begin{ttdescription}
|
lcp@324
|
692 |
\item[\ttindexbold{Const}($a$, $T$)] \index{constants|bold}
|
lcp@286
|
693 |
is the {\bf constant} with name~$a$ and type~$T$. Constants include
|
lcp@286
|
694 |
connectives like $\land$ and $\forall$ as well as constants like~0
|
lcp@286
|
695 |
and~$Suc$. Other constants may be required to define a logic's concrete
|
wenzelm@864
|
696 |
syntax.
|
lcp@104
|
697 |
|
lcp@324
|
698 |
\item[\ttindexbold{Free}($a$, $T$)] \index{variables!free|bold}
|
lcp@324
|
699 |
is the {\bf free variable} with name~$a$ and type~$T$.
|
lcp@104
|
700 |
|
lcp@324
|
701 |
\item[\ttindexbold{Var}($v$, $T$)] \index{unknowns|bold}
|
lcp@324
|
702 |
is the {\bf scheme variable} with indexname~$v$ and type~$T$. An
|
lcp@324
|
703 |
\mltydx{indexname} is a string paired with a non-negative index, or
|
lcp@324
|
704 |
subscript; a term's scheme variables can be systematically renamed by
|
lcp@324
|
705 |
incrementing their subscripts. Scheme variables are essentially free
|
lcp@324
|
706 |
variables, but may be instantiated during unification.
|
lcp@104
|
707 |
|
lcp@324
|
708 |
\item[\ttindexbold{Bound} $i$] \index{variables!bound|bold}
|
lcp@324
|
709 |
is the {\bf bound variable} with de Bruijn index~$i$, which counts the
|
lcp@324
|
710 |
number of lambdas, starting from zero, between a variable's occurrence
|
lcp@324
|
711 |
and its binding. The representation prevents capture of variables. For
|
lcp@324
|
712 |
more information see de Bruijn \cite{debruijn72} or
|
lcp@324
|
713 |
Paulson~\cite[page~336]{paulson91}.
|
lcp@104
|
714 |
|
lcp@324
|
715 |
\item[\ttindexbold{Abs}($a$, $T$, $u$)]
|
lcp@324
|
716 |
\index{lambda abs@$\lambda$-abstractions|bold}
|
lcp@324
|
717 |
is the $\lambda$-{\bf abstraction} with body~$u$, and whose bound
|
lcp@324
|
718 |
variable has name~$a$ and type~$T$. The name is used only for parsing
|
lcp@324
|
719 |
and printing; it has no logical significance.
|
lcp@104
|
720 |
|
lcp@324
|
721 |
\item[$t$ \$ $u$] \index{$@{\tt\$}|bold} \index{function applications|bold}
|
wenzelm@864
|
722 |
is the {\bf application} of~$t$ to~$u$.
|
lcp@324
|
723 |
\end{ttdescription}
|
lcp@286
|
724 |
Application is written as an infix operator to aid readability.
|
lcp@332
|
725 |
Here is an \ML\ pattern to recognize \FOL{} formulae of
|
lcp@104
|
726 |
the form~$A\imp B$, binding the subformulae to~$A$ and~$B$:
|
wenzelm@864
|
727 |
\begin{ttbox}
|
lcp@104
|
728 |
Const("Trueprop",_) $ (Const("op -->",_) $ A $ B)
|
lcp@104
|
729 |
\end{ttbox}
|
lcp@104
|
730 |
|
lcp@104
|
731 |
|
lcp@324
|
732 |
\section{Variable binding}
|
lcp@286
|
733 |
\begin{ttbox}
|
lcp@286
|
734 |
loose_bnos : term -> int list
|
lcp@286
|
735 |
incr_boundvars : int -> term -> term
|
lcp@286
|
736 |
abstract_over : term*term -> term
|
lcp@286
|
737 |
variant_abs : string * typ * term -> string * term
|
lcp@286
|
738 |
aconv : term*term -> bool\hfill{\bf infix}
|
lcp@286
|
739 |
\end{ttbox}
|
lcp@286
|
740 |
These functions are all concerned with the de Bruijn representation of
|
lcp@286
|
741 |
bound variables.
|
lcp@324
|
742 |
\begin{ttdescription}
|
wenzelm@864
|
743 |
\item[\ttindexbold{loose_bnos} $t$]
|
lcp@286
|
744 |
returns the list of all dangling bound variable references. In
|
lcp@286
|
745 |
particular, {\tt Bound~0} is loose unless it is enclosed in an
|
lcp@286
|
746 |
abstraction. Similarly {\tt Bound~1} is loose unless it is enclosed in
|
lcp@286
|
747 |
at least two abstractions; if enclosed in just one, the list will contain
|
lcp@286
|
748 |
the number 0. A well-formed term does not contain any loose variables.
|
lcp@286
|
749 |
|
wenzelm@864
|
750 |
\item[\ttindexbold{incr_boundvars} $j$]
|
lcp@332
|
751 |
increases a term's dangling bound variables by the offset~$j$. This is
|
lcp@286
|
752 |
required when moving a subterm into a context where it is enclosed by a
|
lcp@286
|
753 |
different number of abstractions. Bound variables with a matching
|
lcp@286
|
754 |
abstraction are unaffected.
|
lcp@286
|
755 |
|
wenzelm@864
|
756 |
\item[\ttindexbold{abstract_over} $(v,t)$]
|
lcp@286
|
757 |
forms the abstraction of~$t$ over~$v$, which may be any well-formed term.
|
lcp@286
|
758 |
It replaces every occurrence of \(v\) by a {\tt Bound} variable with the
|
lcp@286
|
759 |
correct index.
|
lcp@286
|
760 |
|
wenzelm@864
|
761 |
\item[\ttindexbold{variant_abs} $(a,T,u)$]
|
lcp@286
|
762 |
substitutes into $u$, which should be the body of an abstraction.
|
lcp@286
|
763 |
It replaces each occurrence of the outermost bound variable by a free
|
lcp@286
|
764 |
variable. The free variable has type~$T$ and its name is a variant
|
lcp@332
|
765 |
of~$a$ chosen to be distinct from all constants and from all variables
|
lcp@286
|
766 |
free in~$u$.
|
lcp@286
|
767 |
|
wenzelm@864
|
768 |
\item[$t$ \ttindexbold{aconv} $u$]
|
lcp@286
|
769 |
tests whether terms~$t$ and~$u$ are \(\alpha\)-convertible: identical up
|
lcp@286
|
770 |
to renaming of bound variables.
|
lcp@286
|
771 |
\begin{itemize}
|
lcp@286
|
772 |
\item
|
lcp@286
|
773 |
Two constants, {\tt Free}s, or {\tt Var}s are \(\alpha\)-convertible
|
lcp@286
|
774 |
if their names and types are equal.
|
lcp@286
|
775 |
(Variables having the same name but different types are thus distinct.
|
lcp@286
|
776 |
This confusing situation should be avoided!)
|
lcp@286
|
777 |
\item
|
lcp@286
|
778 |
Two bound variables are \(\alpha\)-convertible
|
lcp@286
|
779 |
if they have the same number.
|
lcp@286
|
780 |
\item
|
lcp@286
|
781 |
Two abstractions are \(\alpha\)-convertible
|
lcp@286
|
782 |
if their bodies are, and their bound variables have the same type.
|
lcp@286
|
783 |
\item
|
lcp@286
|
784 |
Two applications are \(\alpha\)-convertible
|
lcp@286
|
785 |
if the corresponding subterms are.
|
lcp@286
|
786 |
\end{itemize}
|
lcp@286
|
787 |
|
lcp@324
|
788 |
\end{ttdescription}
|
lcp@286
|
789 |
|
wenzelm@864
|
790 |
\section{Certified terms}\index{terms!certified|bold}\index{signatures}
|
wenzelm@864
|
791 |
A term $t$ can be {\bf certified} under a signature to ensure that every type
|
wenzelm@864
|
792 |
in~$t$ is well-formed and every constant in~$t$ is a type instance of a
|
wenzelm@864
|
793 |
constant declared in the signature. The term must be well-typed and its use
|
wenzelm@864
|
794 |
of bound variables must be well-formed. Meta-rules such as {\tt forall_elim}
|
wenzelm@864
|
795 |
take certified terms as arguments.
|
lcp@104
|
796 |
|
lcp@324
|
797 |
Certified terms belong to the abstract type \mltydx{cterm}.
|
lcp@104
|
798 |
Elements of the type can only be created through the certification process.
|
lcp@104
|
799 |
In case of error, Isabelle raises exception~\ttindex{TERM}\@.
|
lcp@104
|
800 |
|
lcp@104
|
801 |
\subsection{Printing terms}
|
lcp@324
|
802 |
\index{terms!printing of}
|
wenzelm@864
|
803 |
\begin{ttbox}
|
nipkow@275
|
804 |
string_of_cterm : cterm -> string
|
lcp@104
|
805 |
Sign.string_of_term : Sign.sg -> term -> string
|
lcp@104
|
806 |
\end{ttbox}
|
lcp@324
|
807 |
\begin{ttdescription}
|
wenzelm@864
|
808 |
\item[\ttindexbold{string_of_cterm} $ct$]
|
lcp@104
|
809 |
displays $ct$ as a string.
|
lcp@104
|
810 |
|
wenzelm@864
|
811 |
\item[\ttindexbold{Sign.string_of_term} $sign$ $t$]
|
lcp@104
|
812 |
displays $t$ as a string, using the syntax of~$sign$.
|
lcp@324
|
813 |
\end{ttdescription}
|
lcp@104
|
814 |
|
lcp@104
|
815 |
\subsection{Making and inspecting certified terms}
|
wenzelm@864
|
816 |
\begin{ttbox}
|
nipkow@275
|
817 |
cterm_of : Sign.sg -> term -> cterm
|
nipkow@275
|
818 |
read_cterm : Sign.sg -> string * typ -> cterm
|
wenzelm@864
|
819 |
cert_axm : Sign.sg -> string * term -> string * term
|
wenzelm@864
|
820 |
read_axm : Sign.sg -> string * string -> string * term
|
nipkow@275
|
821 |
rep_cterm : cterm -> \{T:typ, t:term, sign:Sign.sg, maxidx:int\}
|
lcp@104
|
822 |
\end{ttbox}
|
lcp@324
|
823 |
\begin{ttdescription}
|
nipkow@275
|
824 |
\item[\ttindexbold{cterm_of} $sign$ $t$] \index{signatures}
|
lcp@104
|
825 |
certifies $t$ with respect to signature~$sign$.
|
lcp@104
|
826 |
|
wenzelm@864
|
827 |
\item[\ttindexbold{read_cterm} $sign$ ($s$, $T$)]
|
lcp@104
|
828 |
reads the string~$s$ using the syntax of~$sign$, creating a certified term.
|
lcp@104
|
829 |
The term is checked to have type~$T$; this type also tells the parser what
|
lcp@104
|
830 |
kind of phrase to parse.
|
lcp@104
|
831 |
|
wenzelm@864
|
832 |
\item[\ttindexbold{cert_axm} $sign$ ($name$, $t$)]
|
wenzelm@864
|
833 |
certifies $t$ with respect to $sign$ as a meta-proposition and converts all
|
wenzelm@864
|
834 |
exceptions to an error, including the final message
|
wenzelm@864
|
835 |
\begin{ttbox}
|
wenzelm@864
|
836 |
The error(s) above occurred in axiom "\(name\)"
|
wenzelm@864
|
837 |
\end{ttbox}
|
wenzelm@864
|
838 |
|
wenzelm@864
|
839 |
\item[\ttindexbold{read_axm} $sign$ ($name$, $s$)]
|
wenzelm@864
|
840 |
similar to {\tt cert_axm}, but first reads the string $s$ using the syntax of
|
wenzelm@864
|
841 |
$sign$.
|
wenzelm@864
|
842 |
|
wenzelm@864
|
843 |
\item[\ttindexbold{rep_cterm} $ct$]
|
lcp@104
|
844 |
decomposes $ct$ as a record containing its type, the term itself, its
|
lcp@104
|
845 |
signature, and the maximum subscript of its unknowns. The type and maximum
|
lcp@104
|
846 |
subscript are computed during certification.
|
lcp@324
|
847 |
\end{ttdescription}
|
lcp@104
|
848 |
|
lcp@104
|
849 |
|
wenzelm@864
|
850 |
\section{Types}\index{types|bold}
|
wenzelm@864
|
851 |
Types belong to the \ML\ type \mltydx{typ}, which is a concrete datatype with
|
wenzelm@864
|
852 |
three constructor functions. These correspond to type constructors, free
|
wenzelm@864
|
853 |
type variables and schematic type variables. Types are classified by sorts,
|
wenzelm@864
|
854 |
which are lists of classes (representing an intersection). A class is
|
wenzelm@864
|
855 |
represented by a string.
|
lcp@104
|
856 |
\begin{ttbox}
|
lcp@104
|
857 |
type class = string;
|
lcp@104
|
858 |
type sort = class list;
|
lcp@104
|
859 |
|
lcp@104
|
860 |
datatype typ = Type of string * typ list
|
lcp@104
|
861 |
| TFree of string * sort
|
lcp@104
|
862 |
| TVar of indexname * sort;
|
lcp@104
|
863 |
|
lcp@104
|
864 |
infixr 5 -->;
|
wenzelm@864
|
865 |
fun S --> T = Type ("fun", [S, T]);
|
lcp@104
|
866 |
\end{ttbox}
|
lcp@324
|
867 |
\begin{ttdescription}
|
lcp@324
|
868 |
\item[\ttindexbold{Type}($a$, $Ts$)] \index{type constructors|bold}
|
lcp@324
|
869 |
applies the {\bf type constructor} named~$a$ to the type operands~$Ts$.
|
lcp@324
|
870 |
Type constructors include~\tydx{fun}, the binary function space
|
lcp@324
|
871 |
constructor, as well as nullary type constructors such as~\tydx{prop}.
|
lcp@324
|
872 |
Other type constructors may be introduced. In expressions, but not in
|
lcp@324
|
873 |
patterns, \hbox{\tt$S$-->$T$} is a convenient shorthand for function
|
lcp@324
|
874 |
types.
|
lcp@104
|
875 |
|
lcp@324
|
876 |
\item[\ttindexbold{TFree}($a$, $s$)] \index{type variables|bold}
|
lcp@324
|
877 |
is the {\bf type variable} with name~$a$ and sort~$s$.
|
lcp@104
|
878 |
|
lcp@324
|
879 |
\item[\ttindexbold{TVar}($v$, $s$)] \index{type unknowns|bold}
|
lcp@324
|
880 |
is the {\bf type unknown} with indexname~$v$ and sort~$s$.
|
lcp@324
|
881 |
Type unknowns are essentially free type variables, but may be
|
lcp@324
|
882 |
instantiated during unification.
|
lcp@324
|
883 |
\end{ttdescription}
|
lcp@104
|
884 |
|
lcp@104
|
885 |
|
lcp@104
|
886 |
\section{Certified types}
|
lcp@104
|
887 |
\index{types!certified|bold}
|
wenzelm@864
|
888 |
Certified types, which are analogous to certified terms, have type
|
nipkow@275
|
889 |
\ttindexbold{ctyp}.
|
lcp@104
|
890 |
|
lcp@104
|
891 |
\subsection{Printing types}
|
lcp@324
|
892 |
\index{types!printing of}
|
wenzelm@864
|
893 |
\begin{ttbox}
|
nipkow@275
|
894 |
string_of_ctyp : ctyp -> string
|
lcp@104
|
895 |
Sign.string_of_typ : Sign.sg -> typ -> string
|
lcp@104
|
896 |
\end{ttbox}
|
lcp@324
|
897 |
\begin{ttdescription}
|
wenzelm@864
|
898 |
\item[\ttindexbold{string_of_ctyp} $cT$]
|
lcp@104
|
899 |
displays $cT$ as a string.
|
lcp@104
|
900 |
|
wenzelm@864
|
901 |
\item[\ttindexbold{Sign.string_of_typ} $sign$ $T$]
|
lcp@104
|
902 |
displays $T$ as a string, using the syntax of~$sign$.
|
lcp@324
|
903 |
\end{ttdescription}
|
lcp@104
|
904 |
|
lcp@104
|
905 |
|
lcp@104
|
906 |
\subsection{Making and inspecting certified types}
|
wenzelm@864
|
907 |
\begin{ttbox}
|
nipkow@275
|
908 |
ctyp_of : Sign.sg -> typ -> ctyp
|
nipkow@275
|
909 |
rep_ctyp : ctyp -> \{T: typ, sign: Sign.sg\}
|
lcp@104
|
910 |
\end{ttbox}
|
lcp@324
|
911 |
\begin{ttdescription}
|
nipkow@275
|
912 |
\item[\ttindexbold{ctyp_of} $sign$ $T$] \index{signatures}
|
lcp@104
|
913 |
certifies $T$ with respect to signature~$sign$.
|
lcp@104
|
914 |
|
wenzelm@864
|
915 |
\item[\ttindexbold{rep_ctyp} $cT$]
|
lcp@104
|
916 |
decomposes $cT$ as a record containing the type itself and its signature.
|
lcp@324
|
917 |
\end{ttdescription}
|
lcp@104
|
918 |
|
lcp@104
|
919 |
\index{theories|)}
|