wenzelm@26869
|
1 |
(* $Id$ *)
|
wenzelm@26869
|
2 |
|
wenzelm@26869
|
3 |
theory Spec
|
wenzelm@26869
|
4 |
imports Main
|
wenzelm@26869
|
5 |
begin
|
wenzelm@26869
|
6 |
|
wenzelm@27046
|
7 |
chapter {* Theory specifications *}
|
wenzelm@26869
|
8 |
|
wenzelm@26870
|
9 |
section {* Defining theories \label{sec:begin-thy} *}
|
wenzelm@26870
|
10 |
|
wenzelm@26870
|
11 |
text {*
|
wenzelm@26870
|
12 |
\begin{matharray}{rcl}
|
wenzelm@26870
|
13 |
@{command_def "theory"} & : & \isartrans{toplevel}{theory} \\
|
wenzelm@27040
|
14 |
@{command_def (global) "end"} & : & \isartrans{theory}{toplevel} \\
|
wenzelm@26870
|
15 |
\end{matharray}
|
wenzelm@26870
|
16 |
|
wenzelm@28745
|
17 |
Isabelle/Isar theories are defined via theory files, which may
|
wenzelm@28745
|
18 |
contain both specifications and proofs; occasionally definitional
|
wenzelm@28745
|
19 |
mechanisms also require some explicit proof. The theory body may be
|
wenzelm@28745
|
20 |
sub-structured by means of \emph{local theory targets}, such as
|
wenzelm@28745
|
21 |
@{command "locale"} and @{command "class"}.
|
wenzelm@26870
|
22 |
|
wenzelm@28745
|
23 |
The first proper command of a theory is @{command "theory"}, which
|
wenzelm@28745
|
24 |
indicates imports of previous theories and optional dependencies on
|
wenzelm@28745
|
25 |
other source files (usually in ML). Just preceding the initial
|
wenzelm@28745
|
26 |
@{command "theory"} command there may be an optional @{command
|
wenzelm@28745
|
27 |
"header"} declaration, which is only relevant to document
|
wenzelm@28745
|
28 |
preparation: see also the other section markup commands in
|
wenzelm@28745
|
29 |
\secref{sec:markup}.
|
wenzelm@28745
|
30 |
|
wenzelm@28745
|
31 |
A theory is concluded by a final @{command (global) "end"} command,
|
wenzelm@28745
|
32 |
one that does not belong to a local theory target. No further
|
wenzelm@28745
|
33 |
commands may follow such a global @{command (global) "end"},
|
wenzelm@28745
|
34 |
although some user-interfaces might pretend that trailing input is
|
wenzelm@28745
|
35 |
admissible.
|
wenzelm@26870
|
36 |
|
wenzelm@26870
|
37 |
\begin{rail}
|
wenzelm@26870
|
38 |
'theory' name 'imports' (name +) uses? 'begin'
|
wenzelm@26870
|
39 |
;
|
wenzelm@26870
|
40 |
|
wenzelm@26870
|
41 |
uses: 'uses' ((name | parname) +);
|
wenzelm@26870
|
42 |
\end{rail}
|
wenzelm@26870
|
43 |
|
wenzelm@26870
|
44 |
\begin{descr}
|
wenzelm@26870
|
45 |
|
wenzelm@26870
|
46 |
\item [@{command "theory"}~@{text "A \<IMPORTS> B\<^sub>1 \<dots>
|
wenzelm@26870
|
47 |
B\<^sub>n \<BEGIN>"}] starts a new theory @{text A} based on the
|
wenzelm@26870
|
48 |
merge of existing theories @{text "B\<^sub>1 \<dots> B\<^sub>n"}.
|
wenzelm@26870
|
49 |
|
wenzelm@28745
|
50 |
Due to the possibility to import more than one ancestor, the
|
wenzelm@28745
|
51 |
resulting theory structure of an Isabelle session forms a directed
|
wenzelm@28745
|
52 |
acyclic graph (DAG). Isabelle's theory loader ensures that the
|
wenzelm@28745
|
53 |
sources contributing to the development graph are always up-to-date:
|
wenzelm@28745
|
54 |
changed files are automatically reloaded whenever a theory header
|
wenzelm@28745
|
55 |
specification is processed.
|
wenzelm@26870
|
56 |
|
wenzelm@26870
|
57 |
The optional @{keyword_def "uses"} specification declares additional
|
wenzelm@26870
|
58 |
dependencies on extra files (usually ML sources). Files will be
|
wenzelm@28745
|
59 |
loaded immediately (as ML), unless the name is parenthesized. The
|
wenzelm@28745
|
60 |
latter case records a dependency that needs to be resolved later in
|
wenzelm@28745
|
61 |
the text, usually via explicit @{command_ref "use"} for ML files;
|
wenzelm@28745
|
62 |
other file formats require specific load commands defined by the
|
wenzelm@28745
|
63 |
corresponding tools or packages.
|
wenzelm@26870
|
64 |
|
wenzelm@27040
|
65 |
\item [@{command (global) "end"}] concludes the current theory
|
wenzelm@28745
|
66 |
definition. Note that local theory targets involve a local
|
wenzelm@28745
|
67 |
@{command (local) "end"}, which is clear from the nesting.
|
wenzelm@26870
|
68 |
|
wenzelm@26870
|
69 |
\end{descr}
|
wenzelm@26870
|
70 |
*}
|
wenzelm@26870
|
71 |
|
wenzelm@27040
|
72 |
|
wenzelm@27040
|
73 |
section {* Local theory targets \label{sec:target} *}
|
wenzelm@27040
|
74 |
|
wenzelm@27040
|
75 |
text {*
|
wenzelm@27040
|
76 |
A local theory target is a context managed separately within the
|
wenzelm@27040
|
77 |
enclosing theory. Contexts may introduce parameters (fixed
|
wenzelm@27040
|
78 |
variables) and assumptions (hypotheses). Definitions and theorems
|
wenzelm@27040
|
79 |
depending on the context may be added incrementally later on. Named
|
wenzelm@27040
|
80 |
contexts refer to locales (cf.\ \secref{sec:locale}) or type classes
|
wenzelm@27040
|
81 |
(cf.\ \secref{sec:class}); the name ``@{text "-"}'' signifies the
|
wenzelm@27040
|
82 |
global theory context.
|
wenzelm@27040
|
83 |
|
wenzelm@27040
|
84 |
\begin{matharray}{rcll}
|
wenzelm@27040
|
85 |
@{command_def "context"} & : & \isartrans{theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
86 |
@{command_def (local) "end"} & : & \isartrans{local{\dsh}theory}{theory} \\
|
wenzelm@27040
|
87 |
\end{matharray}
|
wenzelm@27040
|
88 |
|
wenzelm@27040
|
89 |
\indexouternonterm{target}
|
wenzelm@27040
|
90 |
\begin{rail}
|
wenzelm@27040
|
91 |
'context' name 'begin'
|
wenzelm@27040
|
92 |
;
|
wenzelm@27040
|
93 |
|
wenzelm@27040
|
94 |
target: '(' 'in' name ')'
|
wenzelm@27040
|
95 |
;
|
wenzelm@27040
|
96 |
\end{rail}
|
wenzelm@27040
|
97 |
|
wenzelm@27040
|
98 |
\begin{descr}
|
wenzelm@27040
|
99 |
|
wenzelm@27040
|
100 |
\item [@{command "context"}~@{text "c \<BEGIN>"}] recommences an
|
wenzelm@27040
|
101 |
existing locale or class context @{text c}. Note that locale and
|
wenzelm@27051
|
102 |
class definitions allow to include the @{keyword "begin"} keyword as
|
wenzelm@27051
|
103 |
well, in order to continue the local theory immediately after the
|
wenzelm@27051
|
104 |
initial specification.
|
wenzelm@27040
|
105 |
|
wenzelm@27040
|
106 |
\item [@{command (local) "end"}] concludes the current local theory
|
wenzelm@27040
|
107 |
and continues the enclosing global theory. Note that a global
|
wenzelm@27040
|
108 |
@{command (global) "end"} has a different meaning: it concludes the
|
wenzelm@27040
|
109 |
theory itself (\secref{sec:begin-thy}).
|
wenzelm@27040
|
110 |
|
wenzelm@27040
|
111 |
\item [@{text "(\<IN> c)"}] given after any local theory command
|
wenzelm@27040
|
112 |
specifies an immediate target, e.g.\ ``@{command
|
wenzelm@27040
|
113 |
"definition"}~@{text "(\<IN> c) \<dots>"}'' or ``@{command
|
wenzelm@27040
|
114 |
"theorem"}~@{text "(\<IN> c) \<dots>"}''. This works both in a local or
|
wenzelm@27040
|
115 |
global theory context; the current target context will be suspended
|
wenzelm@27040
|
116 |
for this command only. Note that ``@{text "(\<IN> -)"}'' will
|
wenzelm@27040
|
117 |
always produce a global result independently of the current target
|
wenzelm@27040
|
118 |
context.
|
wenzelm@27040
|
119 |
|
wenzelm@27040
|
120 |
\end{descr}
|
wenzelm@27040
|
121 |
|
wenzelm@27040
|
122 |
The exact meaning of results produced within a local theory context
|
wenzelm@27040
|
123 |
depends on the underlying target infrastructure (locale, type class
|
wenzelm@27040
|
124 |
etc.). The general idea is as follows, considering a context named
|
wenzelm@27040
|
125 |
@{text c} with parameter @{text x} and assumption @{text "A[x]"}.
|
wenzelm@27040
|
126 |
|
wenzelm@27040
|
127 |
Definitions are exported by introducing a global version with
|
wenzelm@27040
|
128 |
additional arguments; a syntactic abbreviation links the long form
|
wenzelm@27040
|
129 |
with the abstract version of the target context. For example,
|
wenzelm@27040
|
130 |
@{text "a \<equiv> t[x]"} becomes @{text "c.a ?x \<equiv> t[?x]"} at the theory
|
wenzelm@27040
|
131 |
level (for arbitrary @{text "?x"}), together with a local
|
wenzelm@27040
|
132 |
abbreviation @{text "c \<equiv> c.a x"} in the target context (for the
|
wenzelm@27040
|
133 |
fixed parameter @{text x}).
|
wenzelm@27040
|
134 |
|
wenzelm@27040
|
135 |
Theorems are exported by discharging the assumptions and
|
wenzelm@27040
|
136 |
generalizing the parameters of the context. For example, @{text "a:
|
wenzelm@27040
|
137 |
B[x]"} becomes @{text "c.a: A[?x] \<Longrightarrow> B[?x]"}, again for arbitrary
|
wenzelm@27040
|
138 |
@{text "?x"}.
|
wenzelm@27040
|
139 |
*}
|
wenzelm@27040
|
140 |
|
wenzelm@27040
|
141 |
|
wenzelm@27040
|
142 |
section {* Basic specification elements *}
|
wenzelm@27040
|
143 |
|
wenzelm@27040
|
144 |
text {*
|
wenzelm@27040
|
145 |
\begin{matharray}{rcll}
|
wenzelm@28114
|
146 |
@{command_def "axiomatization"} & : & \isarkeep{theory} & (axiomatic!)\\
|
wenzelm@27040
|
147 |
@{command_def "definition"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
148 |
@{attribute_def "defn"} & : & \isaratt \\
|
wenzelm@27040
|
149 |
@{command_def "abbreviation"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
150 |
@{command_def "print_abbrevs"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
|
wenzelm@27040
|
151 |
@{command_def "notation"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
152 |
@{command_def "no_notation"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
153 |
\end{matharray}
|
wenzelm@27040
|
154 |
|
wenzelm@27040
|
155 |
These specification mechanisms provide a slightly more abstract view
|
wenzelm@27040
|
156 |
than the underlying primitives of @{command "consts"}, @{command
|
wenzelm@27040
|
157 |
"defs"} (see \secref{sec:consts}), and @{command "axioms"} (see
|
wenzelm@27040
|
158 |
\secref{sec:axms-thms}). In particular, type-inference is commonly
|
wenzelm@27040
|
159 |
available, and result names need not be given.
|
wenzelm@27040
|
160 |
|
wenzelm@27040
|
161 |
\begin{rail}
|
wenzelm@27040
|
162 |
'axiomatization' target? fixes? ('where' specs)?
|
wenzelm@27040
|
163 |
;
|
wenzelm@27040
|
164 |
'definition' target? (decl 'where')? thmdecl? prop
|
wenzelm@27040
|
165 |
;
|
wenzelm@27040
|
166 |
'abbreviation' target? mode? (decl 'where')? prop
|
wenzelm@27040
|
167 |
;
|
wenzelm@27040
|
168 |
('notation' | 'no\_notation') target? mode? (nameref structmixfix + 'and')
|
wenzelm@27040
|
169 |
;
|
wenzelm@27040
|
170 |
|
wenzelm@27040
|
171 |
fixes: ((name ('::' type)? mixfix? | vars) + 'and')
|
wenzelm@27040
|
172 |
;
|
wenzelm@27040
|
173 |
specs: (thmdecl? props + 'and')
|
wenzelm@27040
|
174 |
;
|
wenzelm@27040
|
175 |
decl: name ('::' type)? mixfix?
|
wenzelm@27040
|
176 |
;
|
wenzelm@27040
|
177 |
\end{rail}
|
wenzelm@27040
|
178 |
|
wenzelm@27040
|
179 |
\begin{descr}
|
wenzelm@27040
|
180 |
|
wenzelm@27040
|
181 |
\item [@{command "axiomatization"}~@{text "c\<^sub>1 \<dots> c\<^sub>m
|
wenzelm@27040
|
182 |
\<WHERE> \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n"}] introduces several constants
|
wenzelm@27040
|
183 |
simultaneously and states axiomatic properties for these. The
|
wenzelm@27040
|
184 |
constants are marked as being specified once and for all, which
|
wenzelm@27040
|
185 |
prevents additional specifications being issued later on.
|
wenzelm@27040
|
186 |
|
wenzelm@27040
|
187 |
Note that axiomatic specifications are only appropriate when
|
wenzelm@28114
|
188 |
declaring a new logical system; axiomatic specifications are
|
wenzelm@28114
|
189 |
restricted to global theory contexts. Normal applications should
|
wenzelm@28114
|
190 |
only use definitional mechanisms!
|
wenzelm@27040
|
191 |
|
wenzelm@27040
|
192 |
\item [@{command "definition"}~@{text "c \<WHERE> eq"}] produces an
|
wenzelm@27040
|
193 |
internal definition @{text "c \<equiv> t"} according to the specification
|
wenzelm@27040
|
194 |
given as @{text eq}, which is then turned into a proven fact. The
|
wenzelm@27040
|
195 |
given proposition may deviate from internal meta-level equality
|
wenzelm@27040
|
196 |
according to the rewrite rules declared as @{attribute defn} by the
|
wenzelm@27040
|
197 |
object-logic. This usually covers object-level equality @{text "x =
|
wenzelm@27040
|
198 |
y"} and equivalence @{text "A \<leftrightarrow> B"}. End-users normally need not
|
wenzelm@27040
|
199 |
change the @{attribute defn} setup.
|
wenzelm@27040
|
200 |
|
wenzelm@27040
|
201 |
Definitions may be presented with explicit arguments on the LHS, as
|
wenzelm@27040
|
202 |
well as additional conditions, e.g.\ @{text "f x y = t"} instead of
|
wenzelm@27040
|
203 |
@{text "f \<equiv> \<lambda>x y. t"} and @{text "y \<noteq> 0 \<Longrightarrow> g x y = u"} instead of an
|
wenzelm@27040
|
204 |
unrestricted @{text "g \<equiv> \<lambda>x y. u"}.
|
wenzelm@27040
|
205 |
|
wenzelm@27040
|
206 |
\item [@{command "abbreviation"}~@{text "c \<WHERE> eq"}] introduces
|
wenzelm@27040
|
207 |
a syntactic constant which is associated with a certain term
|
wenzelm@27040
|
208 |
according to the meta-level equality @{text eq}.
|
wenzelm@27040
|
209 |
|
wenzelm@27040
|
210 |
Abbreviations participate in the usual type-inference process, but
|
wenzelm@27040
|
211 |
are expanded before the logic ever sees them. Pretty printing of
|
wenzelm@27040
|
212 |
terms involves higher-order rewriting with rules stemming from
|
wenzelm@27040
|
213 |
reverted abbreviations. This needs some care to avoid overlapping
|
wenzelm@27040
|
214 |
or looping syntactic replacements!
|
wenzelm@27040
|
215 |
|
wenzelm@27040
|
216 |
The optional @{text mode} specification restricts output to a
|
wenzelm@27040
|
217 |
particular print mode; using ``@{text input}'' here achieves the
|
wenzelm@27040
|
218 |
effect of one-way abbreviations. The mode may also include an
|
wenzelm@27040
|
219 |
``@{keyword "output"}'' qualifier that affects the concrete syntax
|
wenzelm@27040
|
220 |
declared for abbreviations, cf.\ @{command "syntax"} in
|
wenzelm@27040
|
221 |
\secref{sec:syn-trans}.
|
wenzelm@27040
|
222 |
|
wenzelm@27040
|
223 |
\item [@{command "print_abbrevs"}] prints all constant abbreviations
|
wenzelm@27040
|
224 |
of the current context.
|
wenzelm@27040
|
225 |
|
wenzelm@27040
|
226 |
\item [@{command "notation"}~@{text "c (mx)"}] associates mixfix
|
wenzelm@27040
|
227 |
syntax with an existing constant or fixed variable. This is a
|
wenzelm@27040
|
228 |
robust interface to the underlying @{command "syntax"} primitive
|
wenzelm@27040
|
229 |
(\secref{sec:syn-trans}). Type declaration and internal syntactic
|
wenzelm@27040
|
230 |
representation of the given entity is retrieved from the context.
|
wenzelm@27040
|
231 |
|
wenzelm@27040
|
232 |
\item [@{command "no_notation"}] is similar to @{command
|
wenzelm@27040
|
233 |
"notation"}, but removes the specified syntax annotation from the
|
wenzelm@27040
|
234 |
present context.
|
wenzelm@27040
|
235 |
|
wenzelm@27040
|
236 |
\end{descr}
|
wenzelm@27040
|
237 |
|
wenzelm@27040
|
238 |
All of these specifications support local theory targets (cf.\
|
wenzelm@27040
|
239 |
\secref{sec:target}).
|
wenzelm@27040
|
240 |
*}
|
wenzelm@27040
|
241 |
|
wenzelm@27040
|
242 |
|
wenzelm@27040
|
243 |
section {* Generic declarations *}
|
wenzelm@27040
|
244 |
|
wenzelm@27040
|
245 |
text {*
|
wenzelm@27040
|
246 |
Arbitrary operations on the background context may be wrapped-up as
|
wenzelm@27040
|
247 |
generic declaration elements. Since the underlying concept of local
|
wenzelm@27040
|
248 |
theories may be subject to later re-interpretation, there is an
|
wenzelm@27040
|
249 |
additional dependency on a morphism that tells the difference of the
|
wenzelm@27040
|
250 |
original declaration context wrt.\ the application context
|
wenzelm@27040
|
251 |
encountered later on. A fact declaration is an important special
|
wenzelm@27040
|
252 |
case: it consists of a theorem which is applied to the context by
|
wenzelm@27040
|
253 |
means of an attribute.
|
wenzelm@27040
|
254 |
|
wenzelm@27040
|
255 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
256 |
@{command_def "declaration"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
257 |
@{command_def "declare"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
258 |
\end{matharray}
|
wenzelm@27040
|
259 |
|
wenzelm@27040
|
260 |
\begin{rail}
|
wenzelm@27040
|
261 |
'declaration' target? text
|
wenzelm@27040
|
262 |
;
|
wenzelm@27040
|
263 |
'declare' target? (thmrefs + 'and')
|
wenzelm@27040
|
264 |
;
|
wenzelm@27040
|
265 |
\end{rail}
|
wenzelm@27040
|
266 |
|
wenzelm@27040
|
267 |
\begin{descr}
|
wenzelm@27040
|
268 |
|
wenzelm@27040
|
269 |
\item [@{command "declaration"}~@{text d}] adds the declaration
|
wenzelm@27040
|
270 |
function @{text d} of ML type @{ML_type declaration}, to the current
|
wenzelm@27040
|
271 |
local theory under construction. In later application contexts, the
|
wenzelm@27040
|
272 |
function is transformed according to the morphisms being involved in
|
wenzelm@27040
|
273 |
the interpretation hierarchy.
|
wenzelm@27040
|
274 |
|
wenzelm@27040
|
275 |
\item [@{command "declare"}~@{text thms}] declares theorems to the
|
wenzelm@27040
|
276 |
current local theory context. No theorem binding is involved here,
|
wenzelm@27040
|
277 |
unlike @{command "theorems"} or @{command "lemmas"} (cf.\
|
wenzelm@27040
|
278 |
\secref{sec:axms-thms}), so @{command "declare"} only has the effect
|
wenzelm@27040
|
279 |
of applying attributes as included in the theorem specification.
|
wenzelm@27040
|
280 |
|
wenzelm@27040
|
281 |
\end{descr}
|
wenzelm@27040
|
282 |
*}
|
wenzelm@27040
|
283 |
|
wenzelm@27040
|
284 |
|
wenzelm@27040
|
285 |
section {* Locales \label{sec:locale} *}
|
wenzelm@27040
|
286 |
|
wenzelm@27040
|
287 |
text {*
|
wenzelm@27040
|
288 |
Locales are named local contexts, consisting of a list of
|
wenzelm@27040
|
289 |
declaration elements that are modeled after the Isar proof context
|
wenzelm@27040
|
290 |
commands (cf.\ \secref{sec:proof-context}).
|
wenzelm@27040
|
291 |
*}
|
wenzelm@27040
|
292 |
|
wenzelm@27040
|
293 |
|
wenzelm@27040
|
294 |
subsection {* Locale specifications *}
|
wenzelm@27040
|
295 |
|
wenzelm@27040
|
296 |
text {*
|
wenzelm@27040
|
297 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
298 |
@{command_def "locale"} & : & \isartrans{theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
299 |
@{command_def "print_locale"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
|
wenzelm@27040
|
300 |
@{command_def "print_locales"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
|
wenzelm@27040
|
301 |
@{method_def intro_locales} & : & \isarmeth \\
|
wenzelm@27040
|
302 |
@{method_def unfold_locales} & : & \isarmeth \\
|
wenzelm@27040
|
303 |
\end{matharray}
|
wenzelm@27040
|
304 |
|
wenzelm@27040
|
305 |
\indexouternonterm{contextexpr}\indexouternonterm{contextelem}
|
wenzelm@27040
|
306 |
\indexisarelem{fixes}\indexisarelem{constrains}\indexisarelem{assumes}
|
wenzelm@27040
|
307 |
\indexisarelem{defines}\indexisarelem{notes}\indexisarelem{includes}
|
wenzelm@27040
|
308 |
\begin{rail}
|
haftmann@27681
|
309 |
'locale' name ('=' localeexpr)? 'begin'?
|
wenzelm@27040
|
310 |
;
|
wenzelm@27040
|
311 |
'print\_locale' '!'? localeexpr
|
wenzelm@27040
|
312 |
;
|
wenzelm@27040
|
313 |
localeexpr: ((contextexpr '+' (contextelem+)) | contextexpr | (contextelem+))
|
wenzelm@27040
|
314 |
;
|
wenzelm@27040
|
315 |
|
wenzelm@27040
|
316 |
contextexpr: nameref | '(' contextexpr ')' |
|
wenzelm@27040
|
317 |
(contextexpr (name mixfix? +)) | (contextexpr + '+')
|
wenzelm@27040
|
318 |
;
|
wenzelm@27040
|
319 |
contextelem: fixes | constrains | assumes | defines | notes
|
wenzelm@27040
|
320 |
;
|
wenzelm@27040
|
321 |
fixes: 'fixes' ((name ('::' type)? structmixfix? | vars) + 'and')
|
wenzelm@27040
|
322 |
;
|
wenzelm@27040
|
323 |
constrains: 'constrains' (name '::' type + 'and')
|
wenzelm@27040
|
324 |
;
|
wenzelm@27040
|
325 |
assumes: 'assumes' (thmdecl? props + 'and')
|
wenzelm@27040
|
326 |
;
|
wenzelm@27040
|
327 |
defines: 'defines' (thmdecl? prop proppat? + 'and')
|
wenzelm@27040
|
328 |
;
|
wenzelm@27040
|
329 |
notes: 'notes' (thmdef? thmrefs + 'and')
|
wenzelm@27040
|
330 |
;
|
wenzelm@27040
|
331 |
includes: 'includes' contextexpr
|
wenzelm@27040
|
332 |
;
|
wenzelm@27040
|
333 |
\end{rail}
|
wenzelm@27040
|
334 |
|
wenzelm@27040
|
335 |
\begin{descr}
|
wenzelm@27040
|
336 |
|
wenzelm@27040
|
337 |
\item [@{command "locale"}~@{text "loc = import + body"}] defines a
|
wenzelm@27040
|
338 |
new locale @{text loc} as a context consisting of a certain view of
|
wenzelm@27040
|
339 |
existing locales (@{text import}) plus some additional elements
|
wenzelm@27040
|
340 |
(@{text body}). Both @{text import} and @{text body} are optional;
|
wenzelm@27040
|
341 |
the degenerate form @{command "locale"}~@{text loc} defines an empty
|
wenzelm@27040
|
342 |
locale, which may still be useful to collect declarations of facts
|
wenzelm@27040
|
343 |
later on. Type-inference on locale expressions automatically takes
|
wenzelm@27040
|
344 |
care of the most general typing that the combined context elements
|
wenzelm@27040
|
345 |
may acquire.
|
wenzelm@27040
|
346 |
|
wenzelm@27040
|
347 |
The @{text import} consists of a structured context expression,
|
wenzelm@27040
|
348 |
consisting of references to existing locales, renamed contexts, or
|
wenzelm@27040
|
349 |
merged contexts. Renaming uses positional notation: @{text "c
|
wenzelm@27040
|
350 |
x\<^sub>1 \<dots> x\<^sub>n"} means that (a prefix of) the fixed
|
wenzelm@27040
|
351 |
parameters of context @{text c} are named @{text "x\<^sub>1, \<dots>,
|
wenzelm@27040
|
352 |
x\<^sub>n"}; a ``@{text _}'' (underscore) means to skip that
|
wenzelm@27040
|
353 |
position. Renaming by default deletes concrete syntax, but new
|
wenzelm@27040
|
354 |
syntax may by specified with a mixfix annotation. An exeption of
|
wenzelm@27040
|
355 |
this rule is the special syntax declared with ``@{text
|
wenzelm@27040
|
356 |
"(\<STRUCTURE>)"}'' (see below), which is neither deleted nor can it
|
wenzelm@27040
|
357 |
be changed. Merging proceeds from left-to-right, suppressing any
|
wenzelm@27040
|
358 |
duplicates stemming from different paths through the import
|
wenzelm@27040
|
359 |
hierarchy.
|
wenzelm@27040
|
360 |
|
wenzelm@27040
|
361 |
The @{text body} consists of basic context elements, further context
|
wenzelm@27040
|
362 |
expressions may be included as well.
|
wenzelm@27040
|
363 |
|
wenzelm@27040
|
364 |
\begin{descr}
|
wenzelm@27040
|
365 |
|
wenzelm@27040
|
366 |
\item [@{element "fixes"}~@{text "x :: \<tau> (mx)"}] declares a local
|
wenzelm@27040
|
367 |
parameter of type @{text \<tau>} and mixfix annotation @{text mx} (both
|
wenzelm@27040
|
368 |
are optional). The special syntax declaration ``@{text
|
wenzelm@27040
|
369 |
"(\<STRUCTURE>)"}'' means that @{text x} may be referenced
|
wenzelm@27040
|
370 |
implicitly in this context.
|
wenzelm@27040
|
371 |
|
wenzelm@27040
|
372 |
\item [@{element "constrains"}~@{text "x :: \<tau>"}] introduces a type
|
wenzelm@27040
|
373 |
constraint @{text \<tau>} on the local parameter @{text x}.
|
wenzelm@27040
|
374 |
|
wenzelm@27040
|
375 |
\item [@{element "assumes"}~@{text "a: \<phi>\<^sub>1 \<dots> \<phi>\<^sub>n"}]
|
wenzelm@27040
|
376 |
introduces local premises, similar to @{command "assume"} within a
|
wenzelm@27040
|
377 |
proof (cf.\ \secref{sec:proof-context}).
|
wenzelm@27040
|
378 |
|
wenzelm@27040
|
379 |
\item [@{element "defines"}~@{text "a: x \<equiv> t"}] defines a previously
|
wenzelm@27040
|
380 |
declared parameter. This is similar to @{command "def"} within a
|
wenzelm@27040
|
381 |
proof (cf.\ \secref{sec:proof-context}), but @{element "defines"}
|
wenzelm@27040
|
382 |
takes an equational proposition instead of variable-term pair. The
|
wenzelm@27040
|
383 |
left-hand side of the equation may have additional arguments, e.g.\
|
wenzelm@27040
|
384 |
``@{element "defines"}~@{text "f x\<^sub>1 \<dots> x\<^sub>n \<equiv> t"}''.
|
wenzelm@27040
|
385 |
|
wenzelm@27040
|
386 |
\item [@{element "notes"}~@{text "a = b\<^sub>1 \<dots> b\<^sub>n"}]
|
wenzelm@27040
|
387 |
reconsiders facts within a local context. Most notably, this may
|
wenzelm@27040
|
388 |
include arbitrary declarations in any attribute specifications
|
wenzelm@27040
|
389 |
included here, e.g.\ a local @{attribute simp} rule.
|
wenzelm@27040
|
390 |
|
ballarin@28728
|
391 |
The initial @{text import} specification of a locale
|
wenzelm@27040
|
392 |
expression maintains a dynamic relation to the locales being
|
wenzelm@27040
|
393 |
referenced (benefiting from any later fact declarations in the
|
wenzelm@27040
|
394 |
obvious manner).
|
wenzelm@27040
|
395 |
|
wenzelm@27040
|
396 |
\end{descr}
|
wenzelm@27040
|
397 |
|
wenzelm@27040
|
398 |
Note that ``@{text "(\<IS> p\<^sub>1 \<dots> p\<^sub>n)"}'' patterns given
|
wenzelm@27040
|
399 |
in the syntax of @{element "assumes"} and @{element "defines"} above
|
wenzelm@27040
|
400 |
are illegal in locale definitions. In the long goal format of
|
wenzelm@27040
|
401 |
\secref{sec:goals}, term bindings may be included as expected,
|
wenzelm@27040
|
402 |
though.
|
wenzelm@27040
|
403 |
|
wenzelm@27040
|
404 |
\medskip By default, locale specifications are ``closed up'' by
|
wenzelm@27040
|
405 |
turning the given text into a predicate definition @{text
|
wenzelm@27040
|
406 |
loc_axioms} and deriving the original assumptions as local lemmas
|
wenzelm@27040
|
407 |
(modulo local definitions). The predicate statement covers only the
|
wenzelm@27040
|
408 |
newly specified assumptions, omitting the content of included locale
|
wenzelm@27040
|
409 |
expressions. The full cumulative view is only provided on export,
|
wenzelm@27040
|
410 |
involving another predicate @{text loc} that refers to the complete
|
wenzelm@27040
|
411 |
specification text.
|
wenzelm@27040
|
412 |
|
wenzelm@27040
|
413 |
In any case, the predicate arguments are those locale parameters
|
wenzelm@27040
|
414 |
that actually occur in the respective piece of text. Also note that
|
wenzelm@27040
|
415 |
these predicates operate at the meta-level in theory, but the locale
|
wenzelm@27040
|
416 |
packages attempts to internalize statements according to the
|
wenzelm@27040
|
417 |
object-logic setup (e.g.\ replacing @{text \<And>} by @{text \<forall>}, and
|
wenzelm@27040
|
418 |
@{text "\<Longrightarrow>"} by @{text "\<longrightarrow>"} in HOL; see also
|
wenzelm@27040
|
419 |
\secref{sec:object-logic}). Separate introduction rules @{text
|
wenzelm@27040
|
420 |
loc_axioms.intro} and @{text loc.intro} are provided as well.
|
wenzelm@27040
|
421 |
|
wenzelm@27040
|
422 |
\item [@{command "print_locale"}~@{text "import + body"}] prints the
|
wenzelm@27040
|
423 |
specified locale expression in a flattened form. The notable
|
wenzelm@27040
|
424 |
special case @{command "print_locale"}~@{text loc} just prints the
|
wenzelm@27040
|
425 |
contents of the named locale, but keep in mind that type-inference
|
wenzelm@27040
|
426 |
will normalize type variables according to the usual alphabetical
|
wenzelm@27040
|
427 |
order. The command omits @{element "notes"} elements by default.
|
wenzelm@27040
|
428 |
Use @{command "print_locale"}@{text "!"} to get them included.
|
wenzelm@27040
|
429 |
|
wenzelm@27040
|
430 |
\item [@{command "print_locales"}] prints the names of all locales
|
wenzelm@27040
|
431 |
of the current theory.
|
wenzelm@27040
|
432 |
|
wenzelm@27040
|
433 |
\item [@{method intro_locales} and @{method unfold_locales}]
|
wenzelm@27040
|
434 |
repeatedly expand all introduction rules of locale predicates of the
|
wenzelm@27040
|
435 |
theory. While @{method intro_locales} only applies the @{text
|
wenzelm@27040
|
436 |
loc.intro} introduction rules and therefore does not decend to
|
wenzelm@27040
|
437 |
assumptions, @{method unfold_locales} is more aggressive and applies
|
wenzelm@27040
|
438 |
@{text loc_axioms.intro} as well. Both methods are aware of locale
|
ballarin@28728
|
439 |
specifications entailed by the context, both from target statements,
|
ballarin@28728
|
440 |
and from interpretations (see below). New goals that are entailed
|
ballarin@28728
|
441 |
by the current context are discharged automatically.
|
wenzelm@27040
|
442 |
|
wenzelm@27040
|
443 |
\end{descr}
|
wenzelm@27040
|
444 |
*}
|
wenzelm@27040
|
445 |
|
wenzelm@27040
|
446 |
|
wenzelm@27040
|
447 |
subsection {* Interpretation of locales *}
|
wenzelm@27040
|
448 |
|
wenzelm@27040
|
449 |
text {*
|
wenzelm@27040
|
450 |
Locale expressions (more precisely, \emph{context expressions}) may
|
wenzelm@27040
|
451 |
be instantiated, and the instantiated facts added to the current
|
wenzelm@27040
|
452 |
context. This requires a proof of the instantiated specification
|
wenzelm@27040
|
453 |
and is called \emph{locale interpretation}. Interpretation is
|
wenzelm@27040
|
454 |
possible in theories and locales (command @{command
|
wenzelm@27040
|
455 |
"interpretation"}) and also within a proof body (command @{command
|
wenzelm@27040
|
456 |
"interpret"}).
|
wenzelm@27040
|
457 |
|
wenzelm@27040
|
458 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
459 |
@{command_def "interpretation"} & : & \isartrans{theory}{proof(prove)} \\
|
wenzelm@27040
|
460 |
@{command_def "interpret"} & : & \isartrans{proof(state) ~|~ proof(chain)}{proof(prove)} \\
|
wenzelm@27040
|
461 |
@{command_def "print_interps"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
|
wenzelm@27040
|
462 |
\end{matharray}
|
wenzelm@27040
|
463 |
|
wenzelm@27040
|
464 |
\indexouternonterm{interp}
|
wenzelm@27040
|
465 |
\begin{rail}
|
wenzelm@27040
|
466 |
'interpretation' (interp | name ('<' | subseteq) contextexpr)
|
wenzelm@27040
|
467 |
;
|
wenzelm@27040
|
468 |
'interpret' interp
|
wenzelm@27040
|
469 |
;
|
wenzelm@27040
|
470 |
'print\_interps' '!'? name
|
wenzelm@27040
|
471 |
;
|
wenzelm@27040
|
472 |
instantiation: ('[' (inst+) ']')?
|
wenzelm@27040
|
473 |
;
|
ballarin@28085
|
474 |
interp: (name ':')? \\ (contextexpr instantiation |
|
wenzelm@27040
|
475 |
name instantiation 'where' (thmdecl? prop + 'and'))
|
wenzelm@27040
|
476 |
;
|
wenzelm@27040
|
477 |
\end{rail}
|
wenzelm@27040
|
478 |
|
wenzelm@27040
|
479 |
\begin{descr}
|
wenzelm@27040
|
480 |
|
wenzelm@27040
|
481 |
\item [@{command "interpretation"}~@{text "expr insts \<WHERE> eqns"}]
|
wenzelm@27040
|
482 |
|
wenzelm@27040
|
483 |
The first form of @{command "interpretation"} interprets @{text
|
wenzelm@27040
|
484 |
expr} in the theory. The instantiation is given as a list of terms
|
wenzelm@27040
|
485 |
@{text insts} and is positional. All parameters must receive an
|
wenzelm@27040
|
486 |
instantiation term --- with the exception of defined parameters.
|
wenzelm@27040
|
487 |
These are, if omitted, derived from the defining equation and other
|
wenzelm@27040
|
488 |
instantiations. Use ``@{text _}'' to omit an instantiation term.
|
wenzelm@27040
|
489 |
|
wenzelm@27040
|
490 |
The command generates proof obligations for the instantiated
|
wenzelm@27040
|
491 |
specifications (assumes and defines elements). Once these are
|
wenzelm@27040
|
492 |
discharged by the user, instantiated facts are added to the theory
|
wenzelm@27040
|
493 |
in a post-processing phase.
|
wenzelm@27040
|
494 |
|
wenzelm@27040
|
495 |
Additional equations, which are unfolded in facts during
|
wenzelm@27040
|
496 |
post-processing, may be given after the keyword @{keyword "where"}.
|
wenzelm@27040
|
497 |
This is useful for interpreting concepts introduced through
|
wenzelm@27040
|
498 |
definition specification elements. The equations must be proved.
|
wenzelm@27040
|
499 |
Note that if equations are present, the context expression is
|
wenzelm@27040
|
500 |
restricted to a locale name.
|
wenzelm@27040
|
501 |
|
wenzelm@27040
|
502 |
The command is aware of interpretations already active in the
|
ballarin@28085
|
503 |
theory, but does not simplify the goal automatically. In order to
|
ballarin@28085
|
504 |
simplify the proof obligations use methods @{method intro_locales}
|
ballarin@28085
|
505 |
or @{method unfold_locales}. Post-processing is not applied to
|
ballarin@28085
|
506 |
facts of interpretations that are already active. This avoids
|
ballarin@28085
|
507 |
duplication of interpreted facts, in particular. Note that, in the
|
ballarin@28085
|
508 |
case of a locale with import, parts of the interpretation may
|
ballarin@28085
|
509 |
already be active. The command will only process facts for new
|
ballarin@28085
|
510 |
parts.
|
wenzelm@27040
|
511 |
|
ballarin@28085
|
512 |
The context expression may be preceded by a name, which takes effect
|
ballarin@28085
|
513 |
in the post-processing of facts. It is used to prefix fact names,
|
ballarin@28085
|
514 |
for example to avoid accidental hiding of other facts.
|
wenzelm@27040
|
515 |
|
wenzelm@27040
|
516 |
Adding facts to locales has the effect of adding interpreted facts
|
wenzelm@27040
|
517 |
to the theory for all active interpretations also. That is,
|
wenzelm@27040
|
518 |
interpretations dynamically participate in any facts added to
|
wenzelm@27040
|
519 |
locales.
|
wenzelm@27040
|
520 |
|
wenzelm@27040
|
521 |
\item [@{command "interpretation"}~@{text "name \<subseteq> expr"}]
|
wenzelm@27040
|
522 |
|
wenzelm@27040
|
523 |
This form of the command interprets @{text expr} in the locale
|
wenzelm@27040
|
524 |
@{text name}. It requires a proof that the specification of @{text
|
wenzelm@27040
|
525 |
name} implies the specification of @{text expr}. As in the
|
wenzelm@27040
|
526 |
localized version of the theorem command, the proof is in the
|
wenzelm@27040
|
527 |
context of @{text name}. After the proof obligation has been
|
wenzelm@27040
|
528 |
dischared, the facts of @{text expr} become part of locale @{text
|
wenzelm@27040
|
529 |
name} as \emph{derived} context elements and are available when the
|
wenzelm@27040
|
530 |
context @{text name} is subsequently entered. Note that, like
|
wenzelm@27040
|
531 |
import, this is dynamic: facts added to a locale part of @{text
|
wenzelm@27040
|
532 |
expr} after interpretation become also available in @{text name}.
|
wenzelm@27040
|
533 |
Like facts of renamed context elements, facts obtained by
|
wenzelm@27040
|
534 |
interpretation may be accessed by prefixing with the parameter
|
wenzelm@27040
|
535 |
renaming (where the parameters are separated by ``@{text _}'').
|
wenzelm@27040
|
536 |
|
wenzelm@27040
|
537 |
Unlike interpretation in theories, instantiation is confined to the
|
wenzelm@27040
|
538 |
renaming of parameters, which may be specified as part of the
|
wenzelm@27040
|
539 |
context expression @{text expr}. Using defined parameters in @{text
|
wenzelm@27040
|
540 |
name} one may achieve an effect similar to instantiation, though.
|
wenzelm@27040
|
541 |
|
wenzelm@27040
|
542 |
Only specification fragments of @{text expr} that are not already
|
wenzelm@27040
|
543 |
part of @{text name} (be it imported, derived or a derived fragment
|
wenzelm@27040
|
544 |
of the import) are considered by interpretation. This enables
|
wenzelm@27040
|
545 |
circular interpretations.
|
wenzelm@27040
|
546 |
|
wenzelm@27040
|
547 |
If interpretations of @{text name} exist in the current theory, the
|
wenzelm@27040
|
548 |
command adds interpretations for @{text expr} as well, with the same
|
wenzelm@27040
|
549 |
prefix and attributes, although only for fragments of @{text expr}
|
wenzelm@27040
|
550 |
that are not interpreted in the theory already.
|
wenzelm@27040
|
551 |
|
wenzelm@27040
|
552 |
\item [@{command "interpret"}~@{text "expr insts \<WHERE> eqns"}]
|
wenzelm@27040
|
553 |
interprets @{text expr} in the proof context and is otherwise
|
wenzelm@27040
|
554 |
similar to interpretation in theories.
|
wenzelm@27040
|
555 |
|
wenzelm@27040
|
556 |
\item [@{command "print_interps"}~@{text loc}] prints the
|
wenzelm@27040
|
557 |
interpretations of a particular locale @{text loc} that are active
|
wenzelm@27040
|
558 |
in the current context, either theory or proof context. The
|
wenzelm@27040
|
559 |
exclamation point argument triggers printing of \emph{witness}
|
wenzelm@27040
|
560 |
theorems justifying interpretations. These are normally omitted
|
wenzelm@27040
|
561 |
from the output.
|
wenzelm@27040
|
562 |
|
wenzelm@27040
|
563 |
\end{descr}
|
wenzelm@27040
|
564 |
|
wenzelm@27040
|
565 |
\begin{warn}
|
wenzelm@27040
|
566 |
Since attributes are applied to interpreted theorems,
|
wenzelm@27040
|
567 |
interpretation may modify the context of common proof tools, e.g.\
|
wenzelm@27040
|
568 |
the Simplifier or Classical Reasoner. Since the behavior of such
|
wenzelm@27040
|
569 |
automated reasoning tools is \emph{not} stable under
|
wenzelm@27040
|
570 |
interpretation morphisms, manual declarations might have to be
|
wenzelm@27040
|
571 |
issued.
|
wenzelm@27040
|
572 |
\end{warn}
|
wenzelm@27040
|
573 |
|
wenzelm@27040
|
574 |
\begin{warn}
|
wenzelm@27040
|
575 |
An interpretation in a theory may subsume previous
|
wenzelm@27040
|
576 |
interpretations. This happens if the same specification fragment
|
wenzelm@27040
|
577 |
is interpreted twice and the instantiation of the second
|
wenzelm@27040
|
578 |
interpretation is more general than the interpretation of the
|
wenzelm@27040
|
579 |
first. A warning is issued, since it is likely that these could
|
wenzelm@27040
|
580 |
have been generalized in the first place. The locale package does
|
wenzelm@27040
|
581 |
not attempt to remove subsumed interpretations.
|
wenzelm@27040
|
582 |
\end{warn}
|
wenzelm@27040
|
583 |
*}
|
wenzelm@27040
|
584 |
|
wenzelm@27040
|
585 |
|
wenzelm@27040
|
586 |
section {* Classes \label{sec:class} *}
|
wenzelm@27040
|
587 |
|
wenzelm@27040
|
588 |
text {*
|
wenzelm@27040
|
589 |
A class is a particular locale with \emph{exactly one} type variable
|
wenzelm@27040
|
590 |
@{text \<alpha>}. Beyond the underlying locale, a corresponding type class
|
wenzelm@27040
|
591 |
is established which is interpreted logically as axiomatic type
|
wenzelm@27040
|
592 |
class \cite{Wenzel:1997:TPHOL} whose logical content are the
|
wenzelm@27040
|
593 |
assumptions of the locale. Thus, classes provide the full
|
wenzelm@27040
|
594 |
generality of locales combined with the commodity of type classes
|
wenzelm@27040
|
595 |
(notably type-inference). See \cite{isabelle-classes} for a short
|
wenzelm@27040
|
596 |
tutorial.
|
wenzelm@27040
|
597 |
|
wenzelm@27040
|
598 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
599 |
@{command_def "class"} & : & \isartrans{theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
600 |
@{command_def "instantiation"} & : & \isartrans{theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
601 |
@{command_def "instance"} & : & \isartrans{local{\dsh}theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
602 |
@{command_def "subclass"} & : & \isartrans{local{\dsh}theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
603 |
@{command_def "print_classes"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
|
wenzelm@27040
|
604 |
@{method_def intro_classes} & : & \isarmeth \\
|
wenzelm@27040
|
605 |
\end{matharray}
|
wenzelm@27040
|
606 |
|
wenzelm@27040
|
607 |
\begin{rail}
|
wenzelm@27040
|
608 |
'class' name '=' ((superclassexpr '+' (contextelem+)) | superclassexpr | (contextelem+)) \\
|
wenzelm@27040
|
609 |
'begin'?
|
wenzelm@27040
|
610 |
;
|
wenzelm@27040
|
611 |
'instantiation' (nameref + 'and') '::' arity 'begin'
|
wenzelm@27040
|
612 |
;
|
wenzelm@27040
|
613 |
'instance'
|
wenzelm@27040
|
614 |
;
|
wenzelm@27040
|
615 |
'subclass' target? nameref
|
wenzelm@27040
|
616 |
;
|
wenzelm@27040
|
617 |
'print\_classes'
|
wenzelm@27040
|
618 |
;
|
wenzelm@27040
|
619 |
|
wenzelm@27040
|
620 |
superclassexpr: nameref | (nameref '+' superclassexpr)
|
wenzelm@27040
|
621 |
;
|
wenzelm@27040
|
622 |
\end{rail}
|
wenzelm@27040
|
623 |
|
wenzelm@27040
|
624 |
\begin{descr}
|
wenzelm@27040
|
625 |
|
wenzelm@27040
|
626 |
\item [@{command "class"}~@{text "c = superclasses + body"}] defines
|
wenzelm@27040
|
627 |
a new class @{text c}, inheriting from @{text superclasses}. This
|
wenzelm@27040
|
628 |
introduces a locale @{text c} with import of all locales @{text
|
wenzelm@27040
|
629 |
superclasses}.
|
wenzelm@27040
|
630 |
|
wenzelm@27040
|
631 |
Any @{element "fixes"} in @{text body} are lifted to the global
|
wenzelm@27040
|
632 |
theory level (\emph{class operations} @{text "f\<^sub>1, \<dots>,
|
wenzelm@27040
|
633 |
f\<^sub>n"} of class @{text c}), mapping the local type parameter
|
wenzelm@27040
|
634 |
@{text \<alpha>} to a schematic type variable @{text "?\<alpha> :: c"}.
|
wenzelm@27040
|
635 |
|
wenzelm@27040
|
636 |
Likewise, @{element "assumes"} in @{text body} are also lifted,
|
wenzelm@27040
|
637 |
mapping each local parameter @{text "f :: \<tau>[\<alpha>]"} to its
|
wenzelm@27040
|
638 |
corresponding global constant @{text "f :: \<tau>[?\<alpha> :: c]"}. The
|
wenzelm@27040
|
639 |
corresponding introduction rule is provided as @{text
|
wenzelm@27040
|
640 |
c_class_axioms.intro}. This rule should be rarely needed directly
|
wenzelm@27040
|
641 |
--- the @{method intro_classes} method takes care of the details of
|
wenzelm@27040
|
642 |
class membership proofs.
|
wenzelm@27040
|
643 |
|
wenzelm@27040
|
644 |
\item [@{command "instantiation"}~@{text "t :: (s\<^sub>1, \<dots>,
|
wenzelm@27040
|
645 |
s\<^sub>n) s \<BEGIN>"}] opens a theory target (cf.\
|
wenzelm@27040
|
646 |
\secref{sec:target}) which allows to specify class operations @{text
|
wenzelm@27040
|
647 |
"f\<^sub>1, \<dots>, f\<^sub>n"} corresponding to sort @{text s} at the
|
wenzelm@27040
|
648 |
particular type instance @{text "(\<alpha>\<^sub>1 :: s\<^sub>1, \<dots>,
|
wenzelm@27040
|
649 |
\<alpha>\<^sub>n :: s\<^sub>n) t"}. A plain @{command "instance"} command
|
wenzelm@27040
|
650 |
in the target body poses a goal stating these type arities. The
|
wenzelm@27040
|
651 |
target is concluded by an @{command_ref (local) "end"} command.
|
wenzelm@27040
|
652 |
|
wenzelm@27040
|
653 |
Note that a list of simultaneous type constructors may be given;
|
wenzelm@27040
|
654 |
this corresponds nicely to mutual recursive type definitions, e.g.\
|
wenzelm@27040
|
655 |
in Isabelle/HOL.
|
wenzelm@27040
|
656 |
|
wenzelm@27040
|
657 |
\item [@{command "instance"}] in an instantiation target body sets
|
wenzelm@27040
|
658 |
up a goal stating the type arities claimed at the opening @{command
|
wenzelm@27040
|
659 |
"instantiation"}. The proof would usually proceed by @{method
|
wenzelm@27040
|
660 |
intro_classes}, and then establish the characteristic theorems of
|
wenzelm@27040
|
661 |
the type classes involved. After finishing the proof, the
|
wenzelm@27040
|
662 |
background theory will be augmented by the proven type arities.
|
wenzelm@27040
|
663 |
|
wenzelm@27040
|
664 |
\item [@{command "subclass"}~@{text c}] in a class context for class
|
wenzelm@27040
|
665 |
@{text d} sets up a goal stating that class @{text c} is logically
|
wenzelm@27040
|
666 |
contained in class @{text d}. After finishing the proof, class
|
wenzelm@27040
|
667 |
@{text d} is proven to be subclass @{text c} and the locale @{text
|
wenzelm@27040
|
668 |
c} is interpreted into @{text d} simultaneously.
|
wenzelm@27040
|
669 |
|
wenzelm@27040
|
670 |
\item [@{command "print_classes"}] prints all classes in the current
|
wenzelm@27040
|
671 |
theory.
|
wenzelm@27040
|
672 |
|
wenzelm@27040
|
673 |
\item [@{method intro_classes}] repeatedly expands all class
|
wenzelm@27040
|
674 |
introduction rules of this theory. Note that this method usually
|
wenzelm@27040
|
675 |
needs not be named explicitly, as it is already included in the
|
wenzelm@27040
|
676 |
default proof step (e.g.\ of @{command "proof"}). In particular,
|
wenzelm@27040
|
677 |
instantiation of trivial (syntactic) classes may be performed by a
|
wenzelm@27040
|
678 |
single ``@{command ".."}'' proof step.
|
wenzelm@27040
|
679 |
|
wenzelm@27040
|
680 |
\end{descr}
|
wenzelm@27040
|
681 |
*}
|
wenzelm@27040
|
682 |
|
wenzelm@27040
|
683 |
|
wenzelm@27040
|
684 |
subsection {* The class target *}
|
wenzelm@27040
|
685 |
|
wenzelm@27040
|
686 |
text {*
|
wenzelm@27040
|
687 |
%FIXME check
|
wenzelm@27040
|
688 |
|
wenzelm@27040
|
689 |
A named context may refer to a locale (cf.\ \secref{sec:target}).
|
wenzelm@27040
|
690 |
If this locale is also a class @{text c}, apart from the common
|
wenzelm@27040
|
691 |
locale target behaviour the following happens.
|
wenzelm@27040
|
692 |
|
wenzelm@27040
|
693 |
\begin{itemize}
|
wenzelm@27040
|
694 |
|
wenzelm@27040
|
695 |
\item Local constant declarations @{text "g[\<alpha>]"} referring to the
|
wenzelm@27040
|
696 |
local type parameter @{text \<alpha>} and local parameters @{text "f[\<alpha>]"}
|
wenzelm@27040
|
697 |
are accompanied by theory-level constants @{text "g[?\<alpha> :: c]"}
|
wenzelm@27040
|
698 |
referring to theory-level class operations @{text "f[?\<alpha> :: c]"}.
|
wenzelm@27040
|
699 |
|
wenzelm@27040
|
700 |
\item Local theorem bindings are lifted as are assumptions.
|
wenzelm@27040
|
701 |
|
wenzelm@27040
|
702 |
\item Local syntax refers to local operations @{text "g[\<alpha>]"} and
|
wenzelm@27040
|
703 |
global operations @{text "g[?\<alpha> :: c]"} uniformly. Type inference
|
wenzelm@27040
|
704 |
resolves ambiguities. In rare cases, manual type annotations are
|
wenzelm@27040
|
705 |
needed.
|
wenzelm@27040
|
706 |
|
wenzelm@27040
|
707 |
\end{itemize}
|
wenzelm@27040
|
708 |
*}
|
wenzelm@27040
|
709 |
|
wenzelm@27040
|
710 |
|
wenzelm@27053
|
711 |
subsection {* Old-style axiomatic type classes \label{sec:axclass} *}
|
wenzelm@27040
|
712 |
|
wenzelm@27040
|
713 |
text {*
|
wenzelm@27040
|
714 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
715 |
@{command_def "axclass"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
716 |
@{command_def "instance"} & : & \isartrans{theory}{proof(prove)} \\
|
wenzelm@27040
|
717 |
\end{matharray}
|
wenzelm@27040
|
718 |
|
wenzelm@27040
|
719 |
Axiomatic type classes are Isabelle/Pure's primitive
|
wenzelm@27040
|
720 |
\emph{definitional} interface to type classes. For practical
|
wenzelm@27040
|
721 |
applications, you should consider using classes
|
wenzelm@27040
|
722 |
(cf.~\secref{sec:classes}) which provide high level interface.
|
wenzelm@27040
|
723 |
|
wenzelm@27040
|
724 |
\begin{rail}
|
wenzelm@27040
|
725 |
'axclass' classdecl (axmdecl prop +)
|
wenzelm@27040
|
726 |
;
|
wenzelm@27040
|
727 |
'instance' (nameref ('<' | subseteq) nameref | nameref '::' arity)
|
wenzelm@27040
|
728 |
;
|
wenzelm@27040
|
729 |
\end{rail}
|
wenzelm@27040
|
730 |
|
wenzelm@27040
|
731 |
\begin{descr}
|
wenzelm@27040
|
732 |
|
wenzelm@27040
|
733 |
\item [@{command "axclass"}~@{text "c \<subseteq> c\<^sub>1, \<dots>, c\<^sub>n
|
wenzelm@27040
|
734 |
axms"}] defines an axiomatic type class as the intersection of
|
wenzelm@27040
|
735 |
existing classes, with additional axioms holding. Class axioms may
|
wenzelm@27040
|
736 |
not contain more than one type variable. The class axioms (with
|
wenzelm@27040
|
737 |
implicit sort constraints added) are bound to the given names.
|
wenzelm@27040
|
738 |
Furthermore a class introduction rule is generated (being bound as
|
wenzelm@27040
|
739 |
@{text c_class.intro}); this rule is employed by method @{method
|
wenzelm@27040
|
740 |
intro_classes} to support instantiation proofs of this class.
|
wenzelm@27040
|
741 |
|
wenzelm@27040
|
742 |
The ``class axioms'' are stored as theorems according to the given
|
wenzelm@27040
|
743 |
name specifications, adding @{text "c_class"} as name space prefix;
|
wenzelm@27040
|
744 |
the same facts are also stored collectively as @{text
|
wenzelm@27040
|
745 |
c_class.axioms}.
|
wenzelm@27040
|
746 |
|
wenzelm@27040
|
747 |
\item [@{command "instance"}~@{text "c\<^sub>1 \<subseteq> c\<^sub>2"} and
|
wenzelm@27040
|
748 |
@{command "instance"}~@{text "t :: (s\<^sub>1, \<dots>, s\<^sub>n) s"}]
|
wenzelm@27040
|
749 |
setup a goal stating a class relation or type arity. The proof
|
wenzelm@27040
|
750 |
would usually proceed by @{method intro_classes}, and then establish
|
wenzelm@27040
|
751 |
the characteristic theorems of the type classes involved. After
|
wenzelm@27040
|
752 |
finishing the proof, the theory will be augmented by a type
|
wenzelm@27040
|
753 |
signature declaration corresponding to the resulting theorem.
|
wenzelm@27040
|
754 |
|
wenzelm@27040
|
755 |
\end{descr}
|
wenzelm@27040
|
756 |
*}
|
wenzelm@27040
|
757 |
|
wenzelm@27040
|
758 |
|
wenzelm@27040
|
759 |
section {* Unrestricted overloading *}
|
wenzelm@27040
|
760 |
|
wenzelm@27040
|
761 |
text {*
|
wenzelm@27040
|
762 |
Isabelle/Pure's definitional schemes support certain forms of
|
wenzelm@27040
|
763 |
overloading (see \secref{sec:consts}). At most occassions
|
wenzelm@27040
|
764 |
overloading will be used in a Haskell-like fashion together with
|
wenzelm@27040
|
765 |
type classes by means of @{command "instantiation"} (see
|
wenzelm@27040
|
766 |
\secref{sec:class}). Sometimes low-level overloading is desirable.
|
wenzelm@27040
|
767 |
The @{command "overloading"} target provides a convenient view for
|
wenzelm@27040
|
768 |
end-users.
|
wenzelm@27040
|
769 |
|
wenzelm@27040
|
770 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
771 |
@{command_def "overloading"} & : & \isartrans{theory}{local{\dsh}theory} \\
|
wenzelm@27040
|
772 |
\end{matharray}
|
wenzelm@27040
|
773 |
|
wenzelm@27040
|
774 |
\begin{rail}
|
wenzelm@27040
|
775 |
'overloading' \\
|
wenzelm@27040
|
776 |
( string ( '==' | equiv ) term ( '(' 'unchecked' ')' )? + ) 'begin'
|
wenzelm@27040
|
777 |
\end{rail}
|
wenzelm@27040
|
778 |
|
wenzelm@27040
|
779 |
\begin{descr}
|
wenzelm@27040
|
780 |
|
wenzelm@27040
|
781 |
\item [@{command "overloading"}~@{text "x\<^sub>1 \<equiv> c\<^sub>1 ::
|
wenzelm@27040
|
782 |
\<tau>\<^sub>1 \<AND> \<dots> x\<^sub>n \<equiv> c\<^sub>n :: \<tau>\<^sub>n \<BEGIN>"}]
|
wenzelm@27040
|
783 |
opens a theory target (cf.\ \secref{sec:target}) which allows to
|
wenzelm@27040
|
784 |
specify constants with overloaded definitions. These are identified
|
wenzelm@27040
|
785 |
by an explicitly given mapping from variable names @{text
|
wenzelm@27040
|
786 |
"x\<^sub>i"} to constants @{text "c\<^sub>i"} at particular type
|
wenzelm@27040
|
787 |
instances. The definitions themselves are established using common
|
wenzelm@27040
|
788 |
specification tools, using the names @{text "x\<^sub>i"} as
|
wenzelm@27040
|
789 |
reference to the corresponding constants. The target is concluded
|
wenzelm@27040
|
790 |
by @{command (local) "end"}.
|
wenzelm@27040
|
791 |
|
wenzelm@27040
|
792 |
A @{text "(unchecked)"} option disables global dependency checks for
|
wenzelm@27040
|
793 |
the corresponding definition, which is occasionally useful for
|
wenzelm@27040
|
794 |
exotic overloading. It is at the discretion of the user to avoid
|
wenzelm@27040
|
795 |
malformed theory specifications!
|
wenzelm@27040
|
796 |
|
wenzelm@27040
|
797 |
\end{descr}
|
wenzelm@27040
|
798 |
*}
|
wenzelm@27040
|
799 |
|
wenzelm@27040
|
800 |
|
wenzelm@27040
|
801 |
section {* Incorporating ML code \label{sec:ML} *}
|
wenzelm@27040
|
802 |
|
wenzelm@27040
|
803 |
text {*
|
wenzelm@27040
|
804 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
805 |
@{command_def "use"} & : & \isarkeep{theory~|~local{\dsh}theory} \\
|
wenzelm@27040
|
806 |
@{command_def "ML"} & : & \isarkeep{theory~|~local{\dsh}theory} \\
|
wenzelm@28281
|
807 |
@{command_def "ML_prf"} & : & \isarkeep{proof} \\
|
wenzelm@27040
|
808 |
@{command_def "ML_val"} & : & \isartrans{\cdot}{\cdot} \\
|
wenzelm@27040
|
809 |
@{command_def "ML_command"} & : & \isartrans{\cdot}{\cdot} \\
|
wenzelm@27040
|
810 |
@{command_def "setup"} & : & \isartrans{theory}{theory} \\
|
wenzelm@28758
|
811 |
@{index_ML bind_thms: "string * thm list -> unit"} \\
|
wenzelm@28758
|
812 |
@{index_ML bind_thm: "string * thm -> unit"} \\
|
wenzelm@27040
|
813 |
\end{matharray}
|
wenzelm@27040
|
814 |
|
wenzelm@27040
|
815 |
\begin{rail}
|
wenzelm@27040
|
816 |
'use' name
|
wenzelm@27040
|
817 |
;
|
wenzelm@28757
|
818 |
('ML' | 'ML\_prf' | 'ML\_val' | 'ML\_command' | 'setup') text
|
wenzelm@27040
|
819 |
;
|
wenzelm@27040
|
820 |
\end{rail}
|
wenzelm@27040
|
821 |
|
wenzelm@27040
|
822 |
\begin{descr}
|
wenzelm@27040
|
823 |
|
wenzelm@27040
|
824 |
\item [@{command "use"}~@{text "file"}] reads and executes ML
|
wenzelm@27040
|
825 |
commands from @{text "file"}. The current theory context is passed
|
wenzelm@28757
|
826 |
down to the ML toplevel and may be modified, using @{ML [source=false]
|
wenzelm@27040
|
827 |
"Context.>>"} or derived ML commands. The file name is checked with
|
wenzelm@27040
|
828 |
the @{keyword_ref "uses"} dependency declaration given in the theory
|
wenzelm@27040
|
829 |
header (see also \secref{sec:begin-thy}).
|
wenzelm@28281
|
830 |
|
wenzelm@28281
|
831 |
Top-level ML bindings are stored within the (global or local) theory
|
wenzelm@28281
|
832 |
context.
|
wenzelm@27040
|
833 |
|
wenzelm@27040
|
834 |
\item [@{command "ML"}~@{text "text"}] is similar to @{command
|
wenzelm@27040
|
835 |
"use"}, but executes ML commands directly from the given @{text
|
wenzelm@28281
|
836 |
"text"}. Top-level ML bindings are stored within the (global or
|
wenzelm@28281
|
837 |
local) theory context.
|
wenzelm@28281
|
838 |
|
wenzelm@28281
|
839 |
\item [@{command "ML_prf"}] is analogous to @{command "ML"} but
|
wenzelm@28281
|
840 |
works within a proof context.
|
wenzelm@28281
|
841 |
|
wenzelm@28281
|
842 |
Top-level ML bindings are stored within the proof context in a
|
wenzelm@28281
|
843 |
purely sequential fashion, disregarding the nested proof structure.
|
wenzelm@28281
|
844 |
ML bindings introduced by @{command "ML_prf"} are discarded at the
|
wenzelm@28281
|
845 |
end of the proof.
|
wenzelm@27040
|
846 |
|
wenzelm@27040
|
847 |
\item [@{command "ML_val"} and @{command "ML_command"}] are
|
wenzelm@27040
|
848 |
diagnostic versions of @{command "ML"}, which means that the context
|
wenzelm@27040
|
849 |
may not be updated. @{command "ML_val"} echos the bindings produced
|
wenzelm@27040
|
850 |
at the ML toplevel, but @{command "ML_command"} is silent.
|
wenzelm@27040
|
851 |
|
wenzelm@27040
|
852 |
\item [@{command "setup"}~@{text "text"}] changes the current theory
|
wenzelm@27040
|
853 |
context by applying @{text "text"}, which refers to an ML expression
|
wenzelm@28757
|
854 |
of type @{ML_type [source=false] "theory -> theory"}. This enables
|
wenzelm@28757
|
855 |
to initialize any object-logic specific tools and packages written
|
wenzelm@28757
|
856 |
in ML, for example.
|
wenzelm@28758
|
857 |
|
wenzelm@28758
|
858 |
\item @{ML bind_thms}~@{text "(name, thms)"} stores a list of
|
wenzelm@28758
|
859 |
theorems produced in ML both in the theory context and the ML
|
wenzelm@28758
|
860 |
toplevel, associating it with the provided name. Theorems are put
|
wenzelm@28758
|
861 |
into a global ``standard'' format before being stored.
|
wenzelm@28758
|
862 |
|
wenzelm@28758
|
863 |
\item @{ML bind_thm} is similar to @{ML bind_thms} but refers to a
|
wenzelm@28758
|
864 |
singleton theorem.
|
wenzelm@27040
|
865 |
|
wenzelm@27040
|
866 |
\end{descr}
|
wenzelm@27040
|
867 |
*}
|
wenzelm@27040
|
868 |
|
wenzelm@27040
|
869 |
|
wenzelm@27040
|
870 |
section {* Primitive specification elements *}
|
wenzelm@27040
|
871 |
|
wenzelm@27040
|
872 |
subsection {* Type classes and sorts \label{sec:classes} *}
|
wenzelm@27040
|
873 |
|
wenzelm@27040
|
874 |
text {*
|
wenzelm@27040
|
875 |
\begin{matharray}{rcll}
|
wenzelm@27040
|
876 |
@{command_def "classes"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
877 |
@{command_def "classrel"} & : & \isartrans{theory}{theory} & (axiomatic!) \\
|
wenzelm@27040
|
878 |
@{command_def "defaultsort"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27059
|
879 |
@{command_def "class_deps"}@{text "\<^sup>*"} & : & \isarkeep{theory~|~proof} \\
|
wenzelm@27040
|
880 |
\end{matharray}
|
wenzelm@27040
|
881 |
|
wenzelm@27040
|
882 |
\begin{rail}
|
wenzelm@27040
|
883 |
'classes' (classdecl +)
|
wenzelm@27040
|
884 |
;
|
wenzelm@27040
|
885 |
'classrel' (nameref ('<' | subseteq) nameref + 'and')
|
wenzelm@27040
|
886 |
;
|
wenzelm@27040
|
887 |
'defaultsort' sort
|
wenzelm@27040
|
888 |
;
|
wenzelm@27040
|
889 |
\end{rail}
|
wenzelm@27040
|
890 |
|
wenzelm@27040
|
891 |
\begin{descr}
|
wenzelm@27040
|
892 |
|
wenzelm@27040
|
893 |
\item [@{command "classes"}~@{text "c \<subseteq> c\<^sub>1, \<dots>, c\<^sub>n"}]
|
wenzelm@27040
|
894 |
declares class @{text c} to be a subclass of existing classes @{text
|
wenzelm@27040
|
895 |
"c\<^sub>1, \<dots>, c\<^sub>n"}. Cyclic class structures are not permitted.
|
wenzelm@27040
|
896 |
|
wenzelm@27040
|
897 |
\item [@{command "classrel"}~@{text "c\<^sub>1 \<subseteq> c\<^sub>2"}] states
|
wenzelm@27040
|
898 |
subclass relations between existing classes @{text "c\<^sub>1"} and
|
wenzelm@27040
|
899 |
@{text "c\<^sub>2"}. This is done axiomatically! The @{command_ref
|
wenzelm@27040
|
900 |
"instance"} command (see \secref{sec:axclass}) provides a way to
|
wenzelm@27040
|
901 |
introduce proven class relations.
|
wenzelm@27040
|
902 |
|
wenzelm@27040
|
903 |
\item [@{command "defaultsort"}~@{text s}] makes sort @{text s} the
|
wenzelm@27040
|
904 |
new default sort for any type variables given without sort
|
wenzelm@27040
|
905 |
constraints. Usually, the default sort would be only changed when
|
wenzelm@27040
|
906 |
defining a new object-logic.
|
wenzelm@27040
|
907 |
|
wenzelm@27040
|
908 |
\item [@{command "class_deps"}] visualizes the subclass relation,
|
wenzelm@27040
|
909 |
using Isabelle's graph browser tool (see also \cite{isabelle-sys}).
|
wenzelm@27040
|
910 |
|
wenzelm@27040
|
911 |
\end{descr}
|
wenzelm@27040
|
912 |
*}
|
wenzelm@27040
|
913 |
|
wenzelm@27040
|
914 |
|
wenzelm@27040
|
915 |
subsection {* Types and type abbreviations \label{sec:types-pure} *}
|
wenzelm@27040
|
916 |
|
wenzelm@27040
|
917 |
text {*
|
wenzelm@27040
|
918 |
\begin{matharray}{rcll}
|
wenzelm@27040
|
919 |
@{command_def "types"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
920 |
@{command_def "typedecl"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
921 |
@{command_def "nonterminals"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
922 |
@{command_def "arities"} & : & \isartrans{theory}{theory} & (axiomatic!) \\
|
wenzelm@27040
|
923 |
\end{matharray}
|
wenzelm@27040
|
924 |
|
wenzelm@27040
|
925 |
\begin{rail}
|
wenzelm@27040
|
926 |
'types' (typespec '=' type infix? +)
|
wenzelm@27040
|
927 |
;
|
wenzelm@27040
|
928 |
'typedecl' typespec infix?
|
wenzelm@27040
|
929 |
;
|
wenzelm@27040
|
930 |
'nonterminals' (name +)
|
wenzelm@27040
|
931 |
;
|
wenzelm@27040
|
932 |
'arities' (nameref '::' arity +)
|
wenzelm@27040
|
933 |
;
|
wenzelm@27040
|
934 |
\end{rail}
|
wenzelm@27040
|
935 |
|
wenzelm@27040
|
936 |
\begin{descr}
|
wenzelm@27040
|
937 |
|
wenzelm@27040
|
938 |
\item [@{command "types"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t = \<tau>"}]
|
wenzelm@27040
|
939 |
introduces \emph{type synonym} @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t"}
|
wenzelm@27040
|
940 |
for existing type @{text "\<tau>"}. Unlike actual type definitions, as
|
wenzelm@27040
|
941 |
are available in Isabelle/HOL for example, type synonyms are just
|
wenzelm@27040
|
942 |
purely syntactic abbreviations without any logical significance.
|
wenzelm@27040
|
943 |
Internally, type synonyms are fully expanded.
|
wenzelm@27040
|
944 |
|
wenzelm@27040
|
945 |
\item [@{command "typedecl"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t"}]
|
wenzelm@27040
|
946 |
declares a new type constructor @{text t}, intended as an actual
|
wenzelm@27040
|
947 |
logical type (of the object-logic, if available).
|
wenzelm@27040
|
948 |
|
wenzelm@27040
|
949 |
\item [@{command "nonterminals"}~@{text c}] declares type
|
wenzelm@27040
|
950 |
constructors @{text c} (without arguments) to act as purely
|
wenzelm@27040
|
951 |
syntactic types, i.e.\ nonterminal symbols of Isabelle's inner
|
wenzelm@27040
|
952 |
syntax of terms or types.
|
wenzelm@27040
|
953 |
|
wenzelm@27040
|
954 |
\item [@{command "arities"}~@{text "t :: (s\<^sub>1, \<dots>, s\<^sub>n)
|
wenzelm@27040
|
955 |
s"}] augments Isabelle's order-sorted signature of types by new type
|
wenzelm@27040
|
956 |
constructor arities. This is done axiomatically! The @{command_ref
|
wenzelm@27040
|
957 |
"instance"} command (see \S\ref{sec:axclass}) provides a way to
|
wenzelm@27040
|
958 |
introduce proven type arities.
|
wenzelm@27040
|
959 |
|
wenzelm@27040
|
960 |
\end{descr}
|
wenzelm@27040
|
961 |
*}
|
wenzelm@27040
|
962 |
|
wenzelm@27040
|
963 |
|
wenzelm@27040
|
964 |
subsection {* Constants and definitions \label{sec:consts} *}
|
wenzelm@27040
|
965 |
|
wenzelm@27040
|
966 |
text {*
|
wenzelm@27040
|
967 |
Definitions essentially express abbreviations within the logic. The
|
wenzelm@27040
|
968 |
simplest form of a definition is @{text "c :: \<sigma> \<equiv> t"}, where @{text
|
wenzelm@27040
|
969 |
c} is a newly declared constant. Isabelle also allows derived forms
|
wenzelm@27040
|
970 |
where the arguments of @{text c} appear on the left, abbreviating a
|
wenzelm@27040
|
971 |
prefix of @{text \<lambda>}-abstractions, e.g.\ @{text "c \<equiv> \<lambda>x y. t"} may be
|
wenzelm@27040
|
972 |
written more conveniently as @{text "c x y \<equiv> t"}. Moreover,
|
wenzelm@27040
|
973 |
definitions may be weakened by adding arbitrary pre-conditions:
|
wenzelm@27040
|
974 |
@{text "A \<Longrightarrow> c x y \<equiv> t"}.
|
wenzelm@27040
|
975 |
|
wenzelm@27040
|
976 |
\medskip The built-in well-formedness conditions for definitional
|
wenzelm@27040
|
977 |
specifications are:
|
wenzelm@27040
|
978 |
|
wenzelm@27040
|
979 |
\begin{itemize}
|
wenzelm@27040
|
980 |
|
wenzelm@27040
|
981 |
\item Arguments (on the left-hand side) must be distinct variables.
|
wenzelm@27040
|
982 |
|
wenzelm@27040
|
983 |
\item All variables on the right-hand side must also appear on the
|
wenzelm@27040
|
984 |
left-hand side.
|
wenzelm@27040
|
985 |
|
wenzelm@27040
|
986 |
\item All type variables on the right-hand side must also appear on
|
wenzelm@27040
|
987 |
the left-hand side; this prohibits @{text "0 :: nat \<equiv> length ([] ::
|
wenzelm@27040
|
988 |
\<alpha> list)"} for example.
|
wenzelm@27040
|
989 |
|
wenzelm@27040
|
990 |
\item The definition must not be recursive. Most object-logics
|
wenzelm@27040
|
991 |
provide definitional principles that can be used to express
|
wenzelm@27040
|
992 |
recursion safely.
|
wenzelm@27040
|
993 |
|
wenzelm@27040
|
994 |
\end{itemize}
|
wenzelm@27040
|
995 |
|
wenzelm@27040
|
996 |
Overloading means that a constant being declared as @{text "c :: \<alpha>
|
wenzelm@27040
|
997 |
decl"} may be defined separately on type instances @{text "c ::
|
wenzelm@27040
|
998 |
(\<beta>\<^sub>1, \<dots>, \<beta>\<^sub>n) t decl"} for each type constructor @{text
|
wenzelm@27040
|
999 |
t}. The right-hand side may mention overloaded constants
|
wenzelm@27040
|
1000 |
recursively at type instances corresponding to the immediate
|
wenzelm@27040
|
1001 |
argument types @{text "\<beta>\<^sub>1, \<dots>, \<beta>\<^sub>n"}. Incomplete
|
wenzelm@27040
|
1002 |
specification patterns impose global constraints on all occurrences,
|
wenzelm@27040
|
1003 |
e.g.\ @{text "d :: \<alpha> \<times> \<alpha>"} on the left-hand side means that all
|
wenzelm@27040
|
1004 |
corresponding occurrences on some right-hand side need to be an
|
wenzelm@27040
|
1005 |
instance of this, general @{text "d :: \<alpha> \<times> \<beta>"} will be disallowed.
|
wenzelm@27040
|
1006 |
|
wenzelm@27040
|
1007 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
1008 |
@{command_def "consts"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1009 |
@{command_def "defs"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1010 |
@{command_def "constdefs"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1011 |
\end{matharray}
|
wenzelm@27040
|
1012 |
|
wenzelm@27040
|
1013 |
\begin{rail}
|
wenzelm@27040
|
1014 |
'consts' ((name '::' type mixfix?) +)
|
wenzelm@27040
|
1015 |
;
|
wenzelm@27040
|
1016 |
'defs' ('(' 'unchecked'? 'overloaded'? ')')? \\ (axmdecl prop +)
|
wenzelm@27040
|
1017 |
;
|
wenzelm@27040
|
1018 |
\end{rail}
|
wenzelm@27040
|
1019 |
|
wenzelm@27040
|
1020 |
\begin{rail}
|
wenzelm@27040
|
1021 |
'constdefs' structs? (constdecl? constdef +)
|
wenzelm@27040
|
1022 |
;
|
wenzelm@27040
|
1023 |
|
wenzelm@27040
|
1024 |
structs: '(' 'structure' (vars + 'and') ')'
|
wenzelm@27040
|
1025 |
;
|
wenzelm@27040
|
1026 |
constdecl: ((name '::' type mixfix | name '::' type | name mixfix) 'where'?) | name 'where'
|
wenzelm@27040
|
1027 |
;
|
wenzelm@27040
|
1028 |
constdef: thmdecl? prop
|
wenzelm@27040
|
1029 |
;
|
wenzelm@27040
|
1030 |
\end{rail}
|
wenzelm@27040
|
1031 |
|
wenzelm@27040
|
1032 |
\begin{descr}
|
wenzelm@27040
|
1033 |
|
wenzelm@27040
|
1034 |
\item [@{command "consts"}~@{text "c :: \<sigma>"}] declares constant
|
wenzelm@27040
|
1035 |
@{text c} to have any instance of type scheme @{text \<sigma>}. The
|
wenzelm@27040
|
1036 |
optional mixfix annotations may attach concrete syntax to the
|
wenzelm@27040
|
1037 |
constants declared.
|
wenzelm@27040
|
1038 |
|
wenzelm@27040
|
1039 |
\item [@{command "defs"}~@{text "name: eqn"}] introduces @{text eqn}
|
wenzelm@27040
|
1040 |
as a definitional axiom for some existing constant.
|
wenzelm@27040
|
1041 |
|
wenzelm@27040
|
1042 |
The @{text "(unchecked)"} option disables global dependency checks
|
wenzelm@27040
|
1043 |
for this definition, which is occasionally useful for exotic
|
wenzelm@27040
|
1044 |
overloading. It is at the discretion of the user to avoid malformed
|
wenzelm@27040
|
1045 |
theory specifications!
|
wenzelm@27040
|
1046 |
|
wenzelm@27040
|
1047 |
The @{text "(overloaded)"} option declares definitions to be
|
wenzelm@27040
|
1048 |
potentially overloaded. Unless this option is given, a warning
|
wenzelm@27040
|
1049 |
message would be issued for any definitional equation with a more
|
wenzelm@27040
|
1050 |
special type than that of the corresponding constant declaration.
|
wenzelm@27040
|
1051 |
|
wenzelm@27040
|
1052 |
\item [@{command "constdefs"}] provides a streamlined combination of
|
wenzelm@27040
|
1053 |
constants declarations and definitions: type-inference takes care of
|
wenzelm@27040
|
1054 |
the most general typing of the given specification (the optional
|
wenzelm@27040
|
1055 |
type constraint may refer to type-inference dummies ``@{text
|
wenzelm@27040
|
1056 |
_}'' as usual). The resulting type declaration needs to agree with
|
wenzelm@27040
|
1057 |
that of the specification; overloading is \emph{not} supported here!
|
wenzelm@27040
|
1058 |
|
wenzelm@27040
|
1059 |
The constant name may be omitted altogether, if neither type nor
|
wenzelm@27040
|
1060 |
syntax declarations are given. The canonical name of the
|
wenzelm@27040
|
1061 |
definitional axiom for constant @{text c} will be @{text c_def},
|
wenzelm@27040
|
1062 |
unless specified otherwise. Also note that the given list of
|
wenzelm@27040
|
1063 |
specifications is processed in a strictly sequential manner, with
|
wenzelm@27040
|
1064 |
type-checking being performed independently.
|
wenzelm@27040
|
1065 |
|
wenzelm@27040
|
1066 |
An optional initial context of @{text "(structure)"} declarations
|
wenzelm@27040
|
1067 |
admits use of indexed syntax, using the special symbol @{verbatim
|
wenzelm@27040
|
1068 |
"\<index>"} (printed as ``@{text "\<index>"}''). The latter concept is
|
wenzelm@27040
|
1069 |
particularly useful with locales (see also \S\ref{sec:locale}).
|
wenzelm@27040
|
1070 |
|
wenzelm@27040
|
1071 |
\end{descr}
|
wenzelm@27040
|
1072 |
*}
|
wenzelm@27040
|
1073 |
|
wenzelm@27040
|
1074 |
|
wenzelm@27040
|
1075 |
section {* Axioms and theorems \label{sec:axms-thms} *}
|
wenzelm@27040
|
1076 |
|
wenzelm@27040
|
1077 |
text {*
|
wenzelm@27040
|
1078 |
\begin{matharray}{rcll}
|
wenzelm@27040
|
1079 |
@{command_def "axioms"} & : & \isartrans{theory}{theory} & (axiomatic!) \\
|
wenzelm@27040
|
1080 |
@{command_def "lemmas"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27046
|
1081 |
@{command_def "theorems"} & : & \isarkeep{local{\dsh}theory} \\
|
wenzelm@27040
|
1082 |
\end{matharray}
|
wenzelm@27040
|
1083 |
|
wenzelm@27040
|
1084 |
\begin{rail}
|
wenzelm@27040
|
1085 |
'axioms' (axmdecl prop +)
|
wenzelm@27040
|
1086 |
;
|
wenzelm@27040
|
1087 |
('lemmas' | 'theorems') target? (thmdef? thmrefs + 'and')
|
wenzelm@27040
|
1088 |
;
|
wenzelm@27040
|
1089 |
\end{rail}
|
wenzelm@27040
|
1090 |
|
wenzelm@27040
|
1091 |
\begin{descr}
|
wenzelm@27040
|
1092 |
|
wenzelm@27040
|
1093 |
\item [@{command "axioms"}~@{text "a: \<phi>"}] introduces arbitrary
|
wenzelm@27040
|
1094 |
statements as axioms of the meta-logic. In fact, axioms are
|
wenzelm@27040
|
1095 |
``axiomatic theorems'', and may be referred later just as any other
|
wenzelm@27040
|
1096 |
theorem.
|
wenzelm@27040
|
1097 |
|
wenzelm@27040
|
1098 |
Axioms are usually only introduced when declaring new logical
|
wenzelm@27040
|
1099 |
systems. Everyday work is typically done the hard way, with proper
|
wenzelm@27040
|
1100 |
definitions and proven theorems.
|
wenzelm@27040
|
1101 |
|
wenzelm@27040
|
1102 |
\item [@{command "lemmas"}~@{text "a = b\<^sub>1 \<dots> b\<^sub>n"}]
|
wenzelm@27040
|
1103 |
retrieves and stores existing facts in the theory context, or the
|
wenzelm@27040
|
1104 |
specified target context (see also \secref{sec:target}). Typical
|
wenzelm@27040
|
1105 |
applications would also involve attributes, to declare Simplifier
|
wenzelm@27040
|
1106 |
rules, for example.
|
wenzelm@27040
|
1107 |
|
wenzelm@27040
|
1108 |
\item [@{command "theorems"}] is essentially the same as @{command
|
wenzelm@27040
|
1109 |
"lemmas"}, but marks the result as a different kind of facts.
|
wenzelm@27040
|
1110 |
|
wenzelm@27040
|
1111 |
\end{descr}
|
wenzelm@27040
|
1112 |
*}
|
wenzelm@27040
|
1113 |
|
wenzelm@27040
|
1114 |
|
wenzelm@27040
|
1115 |
section {* Oracles *}
|
wenzelm@27040
|
1116 |
|
wenzelm@28756
|
1117 |
text {* Oracles allow Isabelle to take advantage of external reasoners
|
wenzelm@28756
|
1118 |
such as arithmetic decision procedures, model checkers, fast
|
wenzelm@28756
|
1119 |
tautology checkers or computer algebra systems. Invoked as an
|
wenzelm@28756
|
1120 |
oracle, an external reasoner can create arbitrary Isabelle theorems.
|
wenzelm@28756
|
1121 |
|
wenzelm@28756
|
1122 |
It is the responsibility of the user to ensure that the external
|
wenzelm@28756
|
1123 |
reasoner is as trustworthy as the application requires. Another
|
wenzelm@28756
|
1124 |
typical source of errors is the linkup between Isabelle and the
|
wenzelm@28756
|
1125 |
external tool, not just its concrete implementation, but also the
|
wenzelm@28756
|
1126 |
required translation between two different logical environments.
|
wenzelm@28756
|
1127 |
|
wenzelm@28756
|
1128 |
Isabelle merely guarantees well-formedness of the propositions being
|
wenzelm@28756
|
1129 |
asserted, and records within the internal derivation object how
|
wenzelm@28756
|
1130 |
presumed theorems depend on unproven suppositions.
|
wenzelm@28756
|
1131 |
|
wenzelm@27040
|
1132 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
1133 |
@{command_def "oracle"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1134 |
\end{matharray}
|
wenzelm@27040
|
1135 |
|
wenzelm@27040
|
1136 |
\begin{rail}
|
wenzelm@28290
|
1137 |
'oracle' name '=' text
|
wenzelm@27040
|
1138 |
;
|
wenzelm@27040
|
1139 |
\end{rail}
|
wenzelm@27040
|
1140 |
|
wenzelm@27040
|
1141 |
\begin{descr}
|
wenzelm@27040
|
1142 |
|
wenzelm@28290
|
1143 |
\item [@{command "oracle"}~@{text "name = text"}] turns the given ML
|
wenzelm@28290
|
1144 |
expression @{text "text"} of type @{ML_text "'a -> cterm"} into an
|
wenzelm@28290
|
1145 |
ML function of type @{ML_text "'a -> thm"}, which is bound to the
|
wenzelm@28756
|
1146 |
global identifier @{ML_text name}. This acts like an infinitary
|
wenzelm@28756
|
1147 |
specification of axioms! Invoking the oracle only works within the
|
wenzelm@28756
|
1148 |
scope of the resulting theory.
|
wenzelm@27040
|
1149 |
|
wenzelm@27040
|
1150 |
\end{descr}
|
wenzelm@28756
|
1151 |
|
wenzelm@28756
|
1152 |
See @{"file" "~~/src/FOL/ex/IffOracle.thy"} for a worked example of
|
wenzelm@28756
|
1153 |
defining a new primitive rule as oracle, and turning it into a proof
|
wenzelm@28756
|
1154 |
method.
|
wenzelm@27040
|
1155 |
*}
|
wenzelm@27040
|
1156 |
|
wenzelm@27040
|
1157 |
|
wenzelm@27040
|
1158 |
section {* Name spaces *}
|
wenzelm@27040
|
1159 |
|
wenzelm@27040
|
1160 |
text {*
|
wenzelm@27040
|
1161 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
1162 |
@{command_def "global"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1163 |
@{command_def "local"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1164 |
@{command_def "hide"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1165 |
\end{matharray}
|
wenzelm@27040
|
1166 |
|
wenzelm@27040
|
1167 |
\begin{rail}
|
wenzelm@27040
|
1168 |
'hide' ('(open)')? name (nameref + )
|
wenzelm@27040
|
1169 |
;
|
wenzelm@27040
|
1170 |
\end{rail}
|
wenzelm@27040
|
1171 |
|
wenzelm@27040
|
1172 |
Isabelle organizes any kind of name declarations (of types,
|
wenzelm@27040
|
1173 |
constants, theorems etc.) by separate hierarchically structured name
|
wenzelm@27040
|
1174 |
spaces. Normally the user does not have to control the behavior of
|
wenzelm@27040
|
1175 |
name spaces by hand, yet the following commands provide some way to
|
wenzelm@27040
|
1176 |
do so.
|
wenzelm@27040
|
1177 |
|
wenzelm@27040
|
1178 |
\begin{descr}
|
wenzelm@27040
|
1179 |
|
wenzelm@27040
|
1180 |
\item [@{command "global"} and @{command "local"}] change the
|
wenzelm@27040
|
1181 |
current name declaration mode. Initially, theories start in
|
wenzelm@27040
|
1182 |
@{command "local"} mode, causing all names to be automatically
|
wenzelm@27040
|
1183 |
qualified by the theory name. Changing this to @{command "global"}
|
wenzelm@27040
|
1184 |
causes all names to be declared without the theory prefix, until
|
wenzelm@27040
|
1185 |
@{command "local"} is declared again.
|
wenzelm@27040
|
1186 |
|
wenzelm@27040
|
1187 |
Note that global names are prone to get hidden accidently later,
|
wenzelm@27040
|
1188 |
when qualified names of the same base name are introduced.
|
wenzelm@27040
|
1189 |
|
wenzelm@27040
|
1190 |
\item [@{command "hide"}~@{text "space names"}] fully removes
|
wenzelm@27040
|
1191 |
declarations from a given name space (which may be @{text "class"},
|
wenzelm@27040
|
1192 |
@{text "type"}, @{text "const"}, or @{text "fact"}); with the @{text
|
wenzelm@27040
|
1193 |
"(open)"} option, only the base name is hidden. Global
|
wenzelm@27040
|
1194 |
(unqualified) names may never be hidden.
|
wenzelm@27040
|
1195 |
|
wenzelm@27040
|
1196 |
Note that hiding name space accesses has no impact on logical
|
wenzelm@28756
|
1197 |
declarations --- they remain valid internally. Entities that are no
|
wenzelm@27040
|
1198 |
longer accessible to the user are printed with the special qualifier
|
wenzelm@27040
|
1199 |
``@{text "??"}'' prefixed to the full internal name.
|
wenzelm@27040
|
1200 |
|
wenzelm@27040
|
1201 |
\end{descr}
|
wenzelm@27040
|
1202 |
*}
|
wenzelm@27040
|
1203 |
|
wenzelm@27040
|
1204 |
|
wenzelm@27040
|
1205 |
section {* Syntax and translations \label{sec:syn-trans} *}
|
wenzelm@27040
|
1206 |
|
wenzelm@27040
|
1207 |
text {*
|
wenzelm@27040
|
1208 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
1209 |
@{command_def "syntax"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1210 |
@{command_def "no_syntax"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1211 |
@{command_def "translations"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1212 |
@{command_def "no_translations"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1213 |
\end{matharray}
|
wenzelm@27040
|
1214 |
|
wenzelm@27040
|
1215 |
\begin{rail}
|
wenzelm@27040
|
1216 |
('syntax' | 'no\_syntax') mode? (constdecl +)
|
wenzelm@27040
|
1217 |
;
|
wenzelm@27040
|
1218 |
('translations' | 'no\_translations') (transpat ('==' | '=>' | '<=' | rightleftharpoons | rightharpoonup | leftharpoondown) transpat +)
|
wenzelm@27040
|
1219 |
;
|
wenzelm@27040
|
1220 |
|
wenzelm@27040
|
1221 |
mode: ('(' ( name | 'output' | name 'output' ) ')')
|
wenzelm@27040
|
1222 |
;
|
wenzelm@27040
|
1223 |
transpat: ('(' nameref ')')? string
|
wenzelm@27040
|
1224 |
;
|
wenzelm@27040
|
1225 |
\end{rail}
|
wenzelm@27040
|
1226 |
|
wenzelm@27040
|
1227 |
\begin{descr}
|
wenzelm@27040
|
1228 |
|
wenzelm@27040
|
1229 |
\item [@{command "syntax"}~@{text "(mode) decls"}] is similar to
|
wenzelm@27040
|
1230 |
@{command "consts"}~@{text decls}, except that the actual logical
|
wenzelm@27040
|
1231 |
signature extension is omitted. Thus the context free grammar of
|
wenzelm@27040
|
1232 |
Isabelle's inner syntax may be augmented in arbitrary ways,
|
wenzelm@27040
|
1233 |
independently of the logic. The @{text mode} argument refers to the
|
wenzelm@27040
|
1234 |
print mode that the grammar rules belong; unless the @{keyword_ref
|
wenzelm@27040
|
1235 |
"output"} indicator is given, all productions are added both to the
|
wenzelm@27040
|
1236 |
input and output grammar.
|
wenzelm@27040
|
1237 |
|
wenzelm@27040
|
1238 |
\item [@{command "no_syntax"}~@{text "(mode) decls"}] removes
|
wenzelm@27040
|
1239 |
grammar declarations (and translations) resulting from @{text
|
wenzelm@27040
|
1240 |
decls}, which are interpreted in the same manner as for @{command
|
wenzelm@27040
|
1241 |
"syntax"} above.
|
wenzelm@27040
|
1242 |
|
wenzelm@27040
|
1243 |
\item [@{command "translations"}~@{text rules}] specifies syntactic
|
wenzelm@27040
|
1244 |
translation rules (i.e.\ macros): parse~/ print rules (@{text "\<rightleftharpoons>"}),
|
wenzelm@27040
|
1245 |
parse rules (@{text "\<rightharpoonup>"}), or print rules (@{text "\<leftharpoondown>"}).
|
wenzelm@27040
|
1246 |
Translation patterns may be prefixed by the syntactic category to be
|
wenzelm@27040
|
1247 |
used for parsing; the default is @{text logic}.
|
wenzelm@27040
|
1248 |
|
wenzelm@27040
|
1249 |
\item [@{command "no_translations"}~@{text rules}] removes syntactic
|
wenzelm@27040
|
1250 |
translation rules, which are interpreted in the same manner as for
|
wenzelm@27040
|
1251 |
@{command "translations"} above.
|
wenzelm@27040
|
1252 |
|
wenzelm@27040
|
1253 |
\end{descr}
|
wenzelm@27040
|
1254 |
*}
|
wenzelm@27040
|
1255 |
|
wenzelm@27040
|
1256 |
|
wenzelm@27040
|
1257 |
section {* Syntax translation functions *}
|
wenzelm@27040
|
1258 |
|
wenzelm@27040
|
1259 |
text {*
|
wenzelm@27040
|
1260 |
\begin{matharray}{rcl}
|
wenzelm@27040
|
1261 |
@{command_def "parse_ast_translation"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1262 |
@{command_def "parse_translation"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1263 |
@{command_def "print_translation"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1264 |
@{command_def "typed_print_translation"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1265 |
@{command_def "print_ast_translation"} & : & \isartrans{theory}{theory} \\
|
wenzelm@27040
|
1266 |
\end{matharray}
|
wenzelm@27040
|
1267 |
|
wenzelm@27040
|
1268 |
\begin{rail}
|
wenzelm@27040
|
1269 |
( 'parse\_ast\_translation' | 'parse\_translation' | 'print\_translation' |
|
wenzelm@27040
|
1270 |
'typed\_print\_translation' | 'print\_ast\_translation' ) ('(advanced)')? text
|
wenzelm@27040
|
1271 |
;
|
wenzelm@27040
|
1272 |
\end{rail}
|
wenzelm@27040
|
1273 |
|
wenzelm@27040
|
1274 |
Syntax translation functions written in ML admit almost arbitrary
|
wenzelm@27040
|
1275 |
manipulations of Isabelle's inner syntax. Any of the above commands
|
wenzelm@27040
|
1276 |
have a single \railqtok{text} argument that refers to an ML
|
wenzelm@27040
|
1277 |
expression of appropriate type, which are as follows by default:
|
wenzelm@27040
|
1278 |
|
wenzelm@27040
|
1279 |
%FIXME proper antiquotations
|
wenzelm@27040
|
1280 |
\begin{ttbox}
|
wenzelm@27040
|
1281 |
val parse_ast_translation : (string * (ast list -> ast)) list
|
wenzelm@27040
|
1282 |
val parse_translation : (string * (term list -> term)) list
|
wenzelm@27040
|
1283 |
val print_translation : (string * (term list -> term)) list
|
wenzelm@27040
|
1284 |
val typed_print_translation :
|
wenzelm@27040
|
1285 |
(string * (bool -> typ -> term list -> term)) list
|
wenzelm@27040
|
1286 |
val print_ast_translation : (string * (ast list -> ast)) list
|
wenzelm@27040
|
1287 |
\end{ttbox}
|
wenzelm@27040
|
1288 |
|
wenzelm@27040
|
1289 |
If the @{text "(advanced)"} option is given, the corresponding
|
wenzelm@27040
|
1290 |
translation functions may depend on the current theory or proof
|
wenzelm@27040
|
1291 |
context. This allows to implement advanced syntax mechanisms, as
|
wenzelm@27040
|
1292 |
translations functions may refer to specific theory declarations or
|
wenzelm@27040
|
1293 |
auxiliary proof data.
|
wenzelm@27040
|
1294 |
|
wenzelm@27040
|
1295 |
See also \cite[\S8]{isabelle-ref} for more information on the
|
wenzelm@27040
|
1296 |
general concept of syntax transformations in Isabelle.
|
wenzelm@27040
|
1297 |
|
wenzelm@27040
|
1298 |
%FIXME proper antiquotations
|
wenzelm@27040
|
1299 |
\begin{ttbox}
|
wenzelm@27040
|
1300 |
val parse_ast_translation:
|
wenzelm@27046
|
1301 |
(string * (Proof.context -> ast list -> ast)) list
|
wenzelm@27040
|
1302 |
val parse_translation:
|
wenzelm@27046
|
1303 |
(string * (Proof.context -> term list -> term)) list
|
wenzelm@27040
|
1304 |
val print_translation:
|
wenzelm@27046
|
1305 |
(string * (Proof.context -> term list -> term)) list
|
wenzelm@27040
|
1306 |
val typed_print_translation:
|
wenzelm@27046
|
1307 |
(string * (Proof.context -> bool -> typ -> term list -> term)) list
|
wenzelm@27040
|
1308 |
val print_ast_translation:
|
wenzelm@27046
|
1309 |
(string * (Proof.context -> ast list -> ast)) list
|
wenzelm@27040
|
1310 |
\end{ttbox}
|
wenzelm@27040
|
1311 |
*}
|
wenzelm@27040
|
1312 |
|
wenzelm@26869
|
1313 |
end
|