12621
|
1 |
|
|
2 |
\chapter{Object-logic specific elements}\label{ch:logics}
|
|
3 |
|
|
4 |
\section{General logic setup}\label{sec:object-logic}
|
|
5 |
|
|
6 |
\indexisarcmd{judgment}
|
|
7 |
\indexisarmeth{atomize}\indexisaratt{atomize}
|
|
8 |
\indexisaratt{rule-format}\indexisaratt{rulify}
|
|
9 |
|
|
10 |
\begin{matharray}{rcl}
|
|
11 |
\isarcmd{judgment} & : & \isartrans{theory}{theory} \\
|
|
12 |
atomize & : & \isarmeth \\
|
|
13 |
atomize & : & \isaratt \\
|
|
14 |
rule_format & : & \isaratt \\
|
|
15 |
rulify & : & \isaratt \\
|
|
16 |
\end{matharray}
|
|
17 |
|
|
18 |
The very starting point for any Isabelle object-logic is a ``truth judgment''
|
|
19 |
that links object-level statements to the meta-logic (with its minimal
|
|
20 |
language of $prop$ that covers universal quantification $\Forall$ and
|
|
21 |
implication $\Imp$). Common object-logics are sufficiently expressive to
|
|
22 |
\emph{internalize} rule statements over $\Forall$ and $\Imp$ within their own
|
|
23 |
language. This is useful in certain situations where a rule needs to be
|
|
24 |
viewed as an atomic statement from the meta-level perspective (e.g.\ $\All x x
|
|
25 |
\in A \Imp P(x)$ versus $\forall x \in A. P(x)$).
|
|
26 |
|
|
27 |
From the following language elements, only the $atomize$ method and
|
|
28 |
$rule_format$ attribute are occasionally required by end-users, the rest is
|
|
29 |
for those who need to setup their own object-logic. In the latter case
|
|
30 |
existing formulations of Isabelle/FOL or Isabelle/HOL may be taken as
|
|
31 |
realistic examples.
|
|
32 |
|
|
33 |
Generic tools may refer to the information provided by object-logic
|
|
34 |
declarations internally (e.g.\ locales \S\ref{sec:locale}, or the Classical
|
|
35 |
Reasoner \S\ref{sec:classical}).
|
|
36 |
|
|
37 |
\railalias{ruleformat}{rule\_format}
|
|
38 |
\railterm{ruleformat}
|
|
39 |
|
|
40 |
\begin{rail}
|
|
41 |
'judgment' constdecl
|
|
42 |
;
|
|
43 |
ruleformat ('(' noasm ')')?
|
|
44 |
;
|
|
45 |
\end{rail}
|
|
46 |
|
|
47 |
\begin{descr}
|
|
48 |
|
|
49 |
\item [$\isarkeyword{judgment}~c::\sigma~~syn$] declares constant $c$ as the
|
|
50 |
truth judgment of the current object-logic. Its type $\sigma$ should
|
|
51 |
specify a coercion of the category of object-level propositions to $prop$ of
|
|
52 |
the Pure meta-logic; the mixfix annotation $syn$ would typically just link
|
|
53 |
the object language (internally of syntactic category $logic$) with that of
|
|
54 |
$prop$. Only one $\isarkeyword{judgment}$ declaration may be given in any
|
|
55 |
theory development.
|
|
56 |
|
|
57 |
\item [$atomize$] (as a method) rewrites any non-atomic premises of a
|
|
58 |
sub-goal, using the meta-level equations declared via $atomize$ (as an
|
|
59 |
attribute) beforehand. As a result, heavily nested goals become amenable to
|
|
60 |
fundamental operations such as resolution (cf.\ the $rule$ method) and
|
|
61 |
proof-by-assumption (cf.\ $assumption$).
|
|
62 |
|
|
63 |
A typical collection of $atomize$ rules for a particular object-logic would
|
|
64 |
provide an internalization for each of the connectives of $\Forall$, $\Imp$,
|
|
65 |
and $\equiv$. Meta-level conjunction expressed in the manner of minimal
|
|
66 |
higher-order logic as $\All{\PROP\,C} (A \Imp B \Imp \PROP\,C) \Imp PROP\,C$
|
|
67 |
should be covered as well (this is particularly important for locales, see
|
|
68 |
\S\ref{sec:locale}).
|
|
69 |
|
|
70 |
\item [$rule_format$] rewrites a theorem by the equalities declared as
|
|
71 |
$rulify$ rules in the current object-logic. By default, the result is fully
|
|
72 |
normalized, including assumptions and conclusions at any depth. The
|
|
73 |
$no_asm$ option restricts the transformation to the conclusion of a rule.
|
|
74 |
|
|
75 |
In common object-logics (HOL, FOL, ZF), the effect of $rule_format$ is to
|
|
76 |
replace (bounded) universal quantification ($\forall$) and implication
|
|
77 |
($\imp$) by the corresponding rule statements over $\Forall$ and $\Imp$.
|
|
78 |
|
|
79 |
\end{descr}
|
|
80 |
|
|
81 |
|
|
82 |
\section{HOL}
|
|
83 |
|
|
84 |
\subsection{Primitive types}\label{sec:typedef}
|
|
85 |
|
|
86 |
\indexisarcmdof{HOL}{typedecl}\indexisarcmdof{HOL}{typedef}
|
|
87 |
\begin{matharray}{rcl}
|
|
88 |
\isarcmd{typedecl} & : & \isartrans{theory}{theory} \\
|
|
89 |
\isarcmd{typedef} & : & \isartrans{theory}{proof(prove)} \\
|
|
90 |
\end{matharray}
|
|
91 |
|
|
92 |
\begin{rail}
|
12879
|
93 |
'typedecl' typespec infix?
|
12621
|
94 |
;
|
12879
|
95 |
'typedef' parname? typespec infix? '=' term
|
12621
|
96 |
;
|
|
97 |
\end{rail}
|
|
98 |
|
|
99 |
\begin{descr}
|
|
100 |
\item [$\isarkeyword{typedecl}~(\vec\alpha)t$] is similar to the original
|
|
101 |
$\isarkeyword{typedecl}$ of Isabelle/Pure (see \S\ref{sec:types-pure}), but
|
|
102 |
also declares type arity $t :: (term, \dots, term) term$, making $t$ an
|
|
103 |
actual HOL type constructor.
|
|
104 |
\item [$\isarkeyword{typedef}~(\vec\alpha)t = A$] sets up a goal stating
|
|
105 |
non-emptiness of the set $A$. After finishing the proof, the theory will be
|
|
106 |
augmented by a Gordon/HOL-style type definition. See \cite{isabelle-HOL}
|
|
107 |
for more information. Note that user-level theories usually do not directly
|
|
108 |
refer to the HOL $\isarkeyword{typedef}$ primitive, but use more advanced
|
|
109 |
packages such as $\isarkeyword{record}$ (see \S\ref{sec:hol-record}) and
|
|
110 |
$\isarkeyword{datatype}$ (see \S\ref{sec:hol-datatype}).
|
|
111 |
\end{descr}
|
|
112 |
|
|
113 |
|
|
114 |
\subsection{Low-level tuples}
|
|
115 |
|
|
116 |
\indexisarattof{HOL}{split-format}
|
|
117 |
\begin{matharray}{rcl}
|
|
118 |
split_format^* & : & \isaratt \\
|
|
119 |
\end{matharray}
|
|
120 |
|
|
121 |
\railalias{splitformat}{split\_format}
|
|
122 |
\railterm{splitformat}
|
|
123 |
\railterm{complete}
|
|
124 |
|
|
125 |
\begin{rail}
|
|
126 |
splitformat (((name * ) + 'and') | ('(' complete ')'))
|
|
127 |
;
|
|
128 |
\end{rail}
|
|
129 |
|
|
130 |
\begin{descr}
|
|
131 |
|
|
132 |
\item [$split_format~\vec p@1 \dots \vec p@n$] puts expressions of low-level
|
|
133 |
tuple types into canonical form as specified by the arguments given; $\vec
|
|
134 |
p@i$ refers to occurrences in premise $i$ of the rule. The
|
|
135 |
$split_format~(complete)$ form causes \emph{all} arguments in function
|
|
136 |
applications to be represented canonically according to their tuple type
|
|
137 |
structure.
|
|
138 |
|
|
139 |
Note that these operations tend to invent funny names for new local
|
|
140 |
parameters to be introduced.
|
|
141 |
|
|
142 |
\end{descr}
|
|
143 |
|
|
144 |
|
|
145 |
\subsection{Records}\label{sec:hol-record}
|
|
146 |
|
|
147 |
FIXME proof tools (simp, cases/induct; no split!?);
|
|
148 |
|
|
149 |
FIXME mixfix syntax;
|
|
150 |
|
|
151 |
\indexisarcmdof{HOL}{record}
|
|
152 |
\begin{matharray}{rcl}
|
|
153 |
\isarcmd{record} & : & \isartrans{theory}{theory} \\
|
|
154 |
\end{matharray}
|
|
155 |
|
|
156 |
\begin{rail}
|
|
157 |
'record' typespec '=' (type '+')? (constdecl +)
|
|
158 |
;
|
|
159 |
\end{rail}
|
|
160 |
|
|
161 |
\begin{descr}
|
|
162 |
\item [$\isarkeyword{record}~(\vec\alpha)t = \tau + \vec c :: \vec\sigma$]
|
|
163 |
defines extensible record type $(\vec\alpha)t$, derived from the optional
|
|
164 |
parent record $\tau$ by adding new field components $\vec c :: \vec\sigma$.
|
|
165 |
See \cite{isabelle-HOL,NaraschewskiW-TPHOLs98} for more information on
|
|
166 |
simply-typed extensible records.
|
|
167 |
\end{descr}
|
|
168 |
|
|
169 |
|
|
170 |
\subsection{Datatypes}\label{sec:hol-datatype}
|
|
171 |
|
|
172 |
\indexisarcmdof{HOL}{datatype}\indexisarcmdof{HOL}{rep-datatype}
|
|
173 |
\begin{matharray}{rcl}
|
|
174 |
\isarcmd{datatype} & : & \isartrans{theory}{theory} \\
|
|
175 |
\isarcmd{rep_datatype} & : & \isartrans{theory}{theory} \\
|
|
176 |
\end{matharray}
|
|
177 |
|
|
178 |
\railalias{repdatatype}{rep\_datatype}
|
|
179 |
\railterm{repdatatype}
|
|
180 |
|
|
181 |
\begin{rail}
|
|
182 |
'datatype' (dtspec + 'and')
|
|
183 |
;
|
|
184 |
repdatatype (name * ) dtrules
|
|
185 |
;
|
|
186 |
|
|
187 |
dtspec: parname? typespec infix? '=' (cons + '|')
|
|
188 |
;
|
12879
|
189 |
cons: name (type * ) mixfix?
|
12621
|
190 |
;
|
|
191 |
dtrules: 'distinct' thmrefs 'inject' thmrefs 'induction' thmrefs
|
|
192 |
\end{rail}
|
|
193 |
|
|
194 |
\begin{descr}
|
|
195 |
\item [$\isarkeyword{datatype}$] defines inductive datatypes in HOL.
|
|
196 |
\item [$\isarkeyword{rep_datatype}$] represents existing types as inductive
|
|
197 |
ones, generating the standard infrastructure of derived concepts (primitive
|
|
198 |
recursion etc.).
|
|
199 |
\end{descr}
|
|
200 |
|
|
201 |
The induction and exhaustion theorems generated provide case names according
|
|
202 |
to the constructors involved, while parameters are named after the types (see
|
|
203 |
also \S\ref{sec:cases-induct}).
|
|
204 |
|
|
205 |
See \cite{isabelle-HOL} for more details on datatypes. Note that the theory
|
|
206 |
syntax above has been slightly simplified over the old version, usually
|
|
207 |
requiring more quotes and less parentheses. Apart from proper proof methods
|
|
208 |
for case-analysis and induction, there are also emulations of ML tactics
|
|
209 |
\texttt{case_tac} and \texttt{induct_tac} available, see
|
|
210 |
\S\ref{sec:induct_tac}.
|
|
211 |
|
|
212 |
|
|
213 |
\subsection{Recursive functions}\label{sec:recursion}
|
|
214 |
|
|
215 |
\indexisarcmdof{HOL}{primrec}\indexisarcmdof{HOL}{recdef}\indexisarcmdof{HOL}{recdef-tc}
|
|
216 |
\begin{matharray}{rcl}
|
|
217 |
\isarcmd{primrec} & : & \isartrans{theory}{theory} \\
|
|
218 |
\isarcmd{recdef} & : & \isartrans{theory}{theory} \\
|
|
219 |
\isarcmd{recdef_tc}^* & : & \isartrans{theory}{proof(prove)} \\
|
|
220 |
%FIXME
|
|
221 |
% \isarcmd{defer_recdef} & : & \isartrans{theory}{theory} \\
|
|
222 |
\end{matharray}
|
|
223 |
|
|
224 |
\railalias{recdefsimp}{recdef\_simp}
|
|
225 |
\railterm{recdefsimp}
|
|
226 |
|
|
227 |
\railalias{recdefcong}{recdef\_cong}
|
|
228 |
\railterm{recdefcong}
|
|
229 |
|
|
230 |
\railalias{recdefwf}{recdef\_wf}
|
|
231 |
\railterm{recdefwf}
|
|
232 |
|
|
233 |
\railalias{recdeftc}{recdef\_tc}
|
|
234 |
\railterm{recdeftc}
|
|
235 |
|
|
236 |
\begin{rail}
|
|
237 |
'primrec' parname? (equation + )
|
|
238 |
;
|
12879
|
239 |
'recdef' ('(' 'permissive' ')')? \\ name term (prop + ) hints?
|
12621
|
240 |
;
|
12879
|
241 |
recdeftc thmdecl? tc
|
12621
|
242 |
;
|
|
243 |
|
12879
|
244 |
equation: thmdecl? prop
|
12621
|
245 |
;
|
|
246 |
hints: '(' 'hints' (recdefmod * ) ')'
|
|
247 |
;
|
|
248 |
recdefmod: ((recdefsimp | recdefcong | recdefwf) (() | 'add' | 'del') ':' thmrefs) | clasimpmod
|
|
249 |
;
|
|
250 |
tc: nameref ('(' nat ')')?
|
|
251 |
;
|
|
252 |
\end{rail}
|
|
253 |
|
|
254 |
\begin{descr}
|
|
255 |
\item [$\isarkeyword{primrec}$] defines primitive recursive functions over
|
|
256 |
datatypes, see also \cite{isabelle-HOL}.
|
|
257 |
\item [$\isarkeyword{recdef}$] defines general well-founded recursive
|
|
258 |
functions (using the TFL package), see also \cite{isabelle-HOL}. The
|
|
259 |
$(permissive)$ option tells TFL to recover from failed proof attempts,
|
|
260 |
returning unfinished results. The $recdef_simp$, $recdef_cong$, and
|
|
261 |
$recdef_wf$ hints refer to auxiliary rules to be used in the internal
|
|
262 |
automated proof process of TFL. Additional $clasimpmod$ declarations (cf.\
|
|
263 |
\S\ref{sec:clasimp}) may be given to tune the context of the Simplifier
|
|
264 |
(cf.\ \S\ref{sec:simplifier}) and Classical reasoner (cf.\
|
|
265 |
\S\ref{sec:classical}).
|
|
266 |
\item [$\isarkeyword{recdef_tc}~c~(i)$] recommences the proof for leftover
|
|
267 |
termination condition number $i$ (default $1$) as generated by a
|
|
268 |
$\isarkeyword{recdef}$ definition of constant $c$.
|
|
269 |
|
|
270 |
Note that in most cases, $\isarkeyword{recdef}$ is able to finish its
|
|
271 |
internal proofs without manual intervention.
|
|
272 |
\end{descr}
|
|
273 |
|
|
274 |
Both kinds of recursive definitions accommodate reasoning by induction (cf.\
|
|
275 |
\S\ref{sec:cases-induct}): rule $c\mathord{.}induct$ (where $c$ is the name of
|
|
276 |
the function definition) refers to a specific induction rule, with parameters
|
|
277 |
named according to the user-specified equations. Case names of
|
|
278 |
$\isarkeyword{primrec}$ are that of the datatypes involved, while those of
|
|
279 |
$\isarkeyword{recdef}$ are numbered (starting from $1$).
|
|
280 |
|
|
281 |
The equations provided by these packages may be referred later as theorem list
|
|
282 |
$f\mathord.simps$, where $f$ is the (collective) name of the functions
|
|
283 |
defined. Individual equations may be named explicitly as well; note that for
|
|
284 |
$\isarkeyword{recdef}$ each specification given by the user may result in
|
|
285 |
several theorems.
|
|
286 |
|
|
287 |
\medskip Hints for $\isarkeyword{recdef}$ may be also declared globally, using
|
|
288 |
the following attributes.
|
|
289 |
|
|
290 |
\indexisarattof{HOL}{recdef-simp}\indexisarattof{HOL}{recdef-cong}\indexisarattof{HOL}{recdef-wf}
|
|
291 |
\begin{matharray}{rcl}
|
|
292 |
recdef_simp & : & \isaratt \\
|
|
293 |
recdef_cong & : & \isaratt \\
|
|
294 |
recdef_wf & : & \isaratt \\
|
|
295 |
\end{matharray}
|
|
296 |
|
|
297 |
\railalias{recdefsimp}{recdef\_simp}
|
|
298 |
\railterm{recdefsimp}
|
|
299 |
|
|
300 |
\railalias{recdefcong}{recdef\_cong}
|
|
301 |
\railterm{recdefcong}
|
|
302 |
|
|
303 |
\railalias{recdefwf}{recdef\_wf}
|
|
304 |
\railterm{recdefwf}
|
|
305 |
|
|
306 |
\begin{rail}
|
|
307 |
(recdefsimp | recdefcong | recdefwf) (() | 'add' | 'del')
|
|
308 |
;
|
|
309 |
\end{rail}
|
|
310 |
|
|
311 |
|
|
312 |
\subsection{(Co)Inductive sets}\label{sec:hol-inductive}
|
|
313 |
|
|
314 |
\indexisarcmdof{HOL}{inductive}\indexisarcmdof{HOL}{coinductive}\indexisarattof{HOL}{mono}
|
|
315 |
\begin{matharray}{rcl}
|
|
316 |
\isarcmd{inductive} & : & \isartrans{theory}{theory} \\
|
|
317 |
\isarcmd{coinductive} & : & \isartrans{theory}{theory} \\
|
|
318 |
mono & : & \isaratt \\
|
|
319 |
\end{matharray}
|
|
320 |
|
|
321 |
\railalias{condefs}{con\_defs}
|
|
322 |
\railterm{condefs}
|
|
323 |
|
|
324 |
\begin{rail}
|
|
325 |
('inductive' | 'coinductive') sets intros monos?
|
|
326 |
;
|
|
327 |
'mono' (() | 'add' | 'del')
|
|
328 |
;
|
|
329 |
|
12879
|
330 |
sets: (term +)
|
12621
|
331 |
;
|
12879
|
332 |
intros: 'intros' (thmdecl? prop +)
|
12621
|
333 |
;
|
12879
|
334 |
monos: 'monos' thmrefs
|
12621
|
335 |
;
|
|
336 |
\end{rail}
|
|
337 |
|
|
338 |
\begin{descr}
|
|
339 |
\item [$\isarkeyword{inductive}$ and $\isarkeyword{coinductive}$] define
|
|
340 |
(co)inductive sets from the given introduction rules.
|
|
341 |
\item [$mono$] declares monotonicity rules. These rule are involved in the
|
|
342 |
automated monotonicity proof of $\isarkeyword{inductive}$.
|
|
343 |
\end{descr}
|
|
344 |
|
|
345 |
See \cite{isabelle-HOL} for further information on inductive definitions in
|
|
346 |
HOL.
|
|
347 |
|
|
348 |
|
|
349 |
\subsection{Arithmetic proof support}
|
|
350 |
|
|
351 |
\indexisarmethof{HOL}{arith}\indexisarattof{HOL}{arith-split}
|
|
352 |
\begin{matharray}{rcl}
|
|
353 |
arith & : & \isarmeth \\
|
|
354 |
arith_split & : & \isaratt \\
|
|
355 |
\end{matharray}
|
|
356 |
|
|
357 |
\begin{rail}
|
|
358 |
'arith' '!'?
|
|
359 |
;
|
|
360 |
\end{rail}
|
|
361 |
|
|
362 |
The $arith$ method decides linear arithmetic problems (on types $nat$, $int$,
|
|
363 |
$real$). Any current facts are inserted into the goal before running the
|
|
364 |
procedure. The ``!''~argument causes the full context of assumptions to be
|
|
365 |
included. The $arith_split$ attribute declares case split rules to be
|
|
366 |
expanded before the arithmetic procedure is invoked.
|
|
367 |
|
|
368 |
Note that a simpler (but faster) version of arithmetic reasoning is already
|
|
369 |
performed by the Simplifier.
|
|
370 |
|
|
371 |
|
|
372 |
\subsection{Cases and induction: emulating tactic scripts}\label{sec:induct_tac}
|
|
373 |
|
|
374 |
The following important tactical tools of Isabelle/HOL have been ported to
|
|
375 |
Isar. These should be never used in proper proof texts!
|
|
376 |
|
|
377 |
\indexisarmethof{HOL}{case-tac}\indexisarmethof{HOL}{induct-tac}
|
|
378 |
\indexisarmethof{HOL}{ind-cases}\indexisarcmdof{HOL}{inductive-cases}
|
|
379 |
\begin{matharray}{rcl}
|
|
380 |
case_tac^* & : & \isarmeth \\
|
|
381 |
induct_tac^* & : & \isarmeth \\
|
|
382 |
ind_cases^* & : & \isarmeth \\
|
|
383 |
\isarcmd{inductive_cases} & : & \isartrans{theory}{theory} \\
|
|
384 |
\end{matharray}
|
|
385 |
|
|
386 |
\railalias{casetac}{case\_tac}
|
|
387 |
\railterm{casetac}
|
|
388 |
|
|
389 |
\railalias{inducttac}{induct\_tac}
|
|
390 |
\railterm{inducttac}
|
|
391 |
|
|
392 |
\railalias{indcases}{ind\_cases}
|
|
393 |
\railterm{indcases}
|
|
394 |
|
|
395 |
\railalias{inductivecases}{inductive\_cases}
|
|
396 |
\railterm{inductivecases}
|
|
397 |
|
|
398 |
\begin{rail}
|
|
399 |
casetac goalspec? term rule?
|
|
400 |
;
|
|
401 |
inducttac goalspec? (insts * 'and') rule?
|
|
402 |
;
|
|
403 |
indcases (prop +)
|
|
404 |
;
|
12879
|
405 |
inductivecases thmdecl? (prop +)
|
12621
|
406 |
;
|
|
407 |
|
|
408 |
rule: ('rule' ':' thmref)
|
|
409 |
;
|
|
410 |
\end{rail}
|
|
411 |
|
|
412 |
\begin{descr}
|
|
413 |
\item [$case_tac$ and $induct_tac$] admit to reason about inductive datatypes
|
|
414 |
only (unless an alternative rule is given explicitly). Furthermore,
|
|
415 |
$case_tac$ does a classical case split on booleans; $induct_tac$ allows only
|
|
416 |
variables to be given as instantiation. These tactic emulations feature
|
|
417 |
both goal addressing and dynamic instantiation. Note that named rule cases
|
|
418 |
are \emph{not} provided as would be by the proper $induct$ and $cases$ proof
|
|
419 |
methods (see \S\ref{sec:cases-induct}).
|
|
420 |
|
|
421 |
\item [$ind_cases$ and $\isarkeyword{inductive_cases}$] provide an interface
|
|
422 |
to the \texttt{mk_cases} operation. Rules are simplified in an unrestricted
|
|
423 |
forward manner.
|
|
424 |
|
|
425 |
While $ind_cases$ is a proof method to apply the result immediately as
|
|
426 |
elimination rules, $\isarkeyword{inductive_cases}$ provides case split
|
|
427 |
theorems at the theory level for later use,
|
|
428 |
\end{descr}
|
|
429 |
|
|
430 |
|
|
431 |
\section{HOLCF}
|
|
432 |
|
|
433 |
\subsection{Mixfix syntax for continuous operations}
|
|
434 |
|
|
435 |
\indexisarcmdof{HOLCF}{consts}\indexisarcmdof{HOLCF}{constdefs}
|
|
436 |
|
|
437 |
\begin{matharray}{rcl}
|
|
438 |
\isarcmd{consts} & : & \isartrans{theory}{theory} \\
|
|
439 |
\isarcmd{constdefs} & : & \isartrans{theory}{theory} \\
|
|
440 |
\end{matharray}
|
|
441 |
|
|
442 |
HOLCF provides a separate type for continuous functions $\alpha \rightarrow
|
|
443 |
\beta$, with an explicit application operator $f \cdot x$. Isabelle mixfix
|
|
444 |
syntax normally refers directly to the pure meta-level function type $\alpha
|
|
445 |
\To \beta$, with application $f\,x$.
|
|
446 |
|
|
447 |
The HOLCF variants of $\CONSTS$ and $\CONSTDEFS$ have the same outer syntax as
|
|
448 |
the pure versions (cf.\ \S\ref{sec:consts}). Internally, declarations
|
|
449 |
involving continuous function types are treated specifically, transforming the
|
|
450 |
syntax template accordingly and generating syntax translation rules for the
|
|
451 |
abstract and concrete representation of application.
|
|
452 |
|
|
453 |
The behavior for plain meta-level function types is unchanged. Mixed
|
|
454 |
continuous and meta-level application is \emph{not} supported.
|
|
455 |
|
|
456 |
\subsection{Recursive domains}
|
|
457 |
|
|
458 |
\indexisarcmdof{HOLCF}{domain}
|
|
459 |
\begin{matharray}{rcl}
|
|
460 |
\isarcmd{domain} & : & \isartrans{theory}{theory} \\
|
|
461 |
\end{matharray}
|
|
462 |
|
|
463 |
\begin{rail}
|
|
464 |
'domain' parname? (dmspec + 'and')
|
|
465 |
;
|
|
466 |
|
|
467 |
dmspec: typespec '=' (cons + '|')
|
|
468 |
;
|
12879
|
469 |
cons: name (type * ) mixfix?
|
12621
|
470 |
;
|
|
471 |
dtrules: 'distinct' thmrefs 'inject' thmrefs 'induction' thmrefs
|
|
472 |
\end{rail}
|
|
473 |
|
|
474 |
Recursive domains in HOLCF are analogous to datatypes in classical HOL (cf.\
|
|
475 |
\S\ref{sec:hol-datatype}). Mutual recursive is supported, but no nesting nor
|
|
476 |
arbitrary branching. Domain constructors may be strict (default) or lazy, the
|
|
477 |
latter admits to introduce infinitary objects in the typical LCF manner (lazy
|
|
478 |
lists etc.).
|
|
479 |
|
|
480 |
See also \cite{MuellerNvOS99} for further information HOLCF domains in
|
|
481 |
general.
|
|
482 |
|
|
483 |
|
|
484 |
\section{ZF}
|
|
485 |
|
|
486 |
\subsection{Type checking}
|
|
487 |
|
|
488 |
FIXME
|
|
489 |
|
|
490 |
\subsection{Inductive sets and datatypes}
|
|
491 |
|
|
492 |
FIXME
|
|
493 |
|
|
494 |
|
|
495 |
%%% Local Variables:
|
|
496 |
%%% mode: latex
|
|
497 |
%%% TeX-master: "isar-ref"
|
|
498 |
%%% End:
|