wenzelm@26840
|
1 |
theory HOL_Specific
|
wenzelm@43522
|
2 |
imports Base Main
|
wenzelm@26840
|
3 |
begin
|
wenzelm@26840
|
4 |
|
wenzelm@26852
|
5 |
chapter {* Isabelle/HOL \label{ch:hol} *}
|
wenzelm@26849
|
6 |
|
wenzelm@44118
|
7 |
section {* Higher-Order Logic *}
|
wenzelm@44118
|
8 |
|
wenzelm@44118
|
9 |
text {* Isabelle/HOL is based on Higher-Order Logic, a polymorphic
|
wenzelm@44118
|
10 |
version of Church's Simple Theory of Types. HOL can be best
|
wenzelm@44118
|
11 |
understood as a simply-typed version of classical set theory. The
|
wenzelm@44118
|
12 |
logic was first implemented in Gordon's HOL system
|
wenzelm@44118
|
13 |
\cite{mgordon-hol}. It extends Church's original logic
|
wenzelm@44118
|
14 |
\cite{church40} by explicit type variables (naive polymorphism) and
|
wenzelm@44118
|
15 |
a sound axiomatization scheme for new types based on subsets of
|
wenzelm@44118
|
16 |
existing types.
|
wenzelm@44118
|
17 |
|
wenzelm@44118
|
18 |
Andrews's book \cite{andrews86} is a full description of the
|
wenzelm@44118
|
19 |
original Church-style higher-order logic, with proofs of correctness
|
wenzelm@44118
|
20 |
and completeness wrt.\ certain set-theoretic interpretations. The
|
wenzelm@44118
|
21 |
particular extensions of Gordon-style HOL are explained semantically
|
wenzelm@44118
|
22 |
in two chapters of the 1993 HOL book \cite{pitts93}.
|
wenzelm@44118
|
23 |
|
wenzelm@44118
|
24 |
Experience with HOL over decades has demonstrated that higher-order
|
wenzelm@44118
|
25 |
logic is widely applicable in many areas of mathematics and computer
|
wenzelm@44118
|
26 |
science. In a sense, Higher-Order Logic is simpler than First-Order
|
wenzelm@44118
|
27 |
Logic, because there are fewer restrictions and special cases. Note
|
wenzelm@44118
|
28 |
that HOL is \emph{weaker} than FOL with axioms for ZF set theory,
|
wenzelm@44118
|
29 |
which is traditionally considered the standard foundation of regular
|
wenzelm@44118
|
30 |
mathematics, but for most applications this does not matter. If you
|
wenzelm@44118
|
31 |
prefer ML to Lisp, you will probably prefer HOL to ZF.
|
wenzelm@44118
|
32 |
|
wenzelm@44118
|
33 |
\medskip The syntax of HOL follows @{text "\<lambda>"}-calculus and
|
wenzelm@44118
|
34 |
functional programming. Function application is curried. To apply
|
wenzelm@44118
|
35 |
the function @{text f} of type @{text "\<tau>\<^sub>1 \<Rightarrow> \<tau>\<^sub>2 \<Rightarrow> \<tau>\<^sub>3"} to the
|
wenzelm@44118
|
36 |
arguments @{text a} and @{text b} in HOL, you simply write @{text "f
|
wenzelm@44118
|
37 |
a b"} (as in ML or Haskell). There is no ``apply'' operator; the
|
wenzelm@44118
|
38 |
existing application of the Pure @{text "\<lambda>"}-calculus is re-used.
|
wenzelm@44118
|
39 |
Note that in HOL @{text "f (a, b)"} means ``@{text "f"} applied to
|
wenzelm@44118
|
40 |
the pair @{text "(a, b)"} (which is notation for @{text "Pair a
|
wenzelm@44118
|
41 |
b"}). The latter typically introduces extra formal efforts that can
|
wenzelm@44118
|
42 |
be avoided by currying functions by default. Explicit tuples are as
|
wenzelm@44118
|
43 |
infrequent in HOL formalizations as in good ML or Haskell programs.
|
wenzelm@44118
|
44 |
|
wenzelm@44118
|
45 |
\medskip Isabelle/HOL has a distinct feel, compared to other
|
wenzelm@44118
|
46 |
object-logics like Isabelle/ZF. It identifies object-level types
|
wenzelm@44118
|
47 |
with meta-level types, taking advantage of the default
|
wenzelm@44118
|
48 |
type-inference mechanism of Isabelle/Pure. HOL fully identifies
|
wenzelm@44118
|
49 |
object-level functions with meta-level functions, with native
|
wenzelm@44118
|
50 |
abstraction and application.
|
wenzelm@44118
|
51 |
|
wenzelm@44118
|
52 |
These identifications allow Isabelle to support HOL particularly
|
wenzelm@44118
|
53 |
nicely, but they also mean that HOL requires some sophistication
|
wenzelm@44118
|
54 |
from the user. In particular, an understanding of Hindley-Milner
|
wenzelm@44118
|
55 |
type-inference with type-classes, which are both used extensively in
|
wenzelm@44118
|
56 |
the standard libraries and applications. Beginners can set
|
wenzelm@44118
|
57 |
@{attribute show_types} or even @{attribute show_sorts} to get more
|
wenzelm@44118
|
58 |
explicit information about the result of type-inference. *}
|
wenzelm@44118
|
59 |
|
wenzelm@44118
|
60 |
|
wenzelm@44112
|
61 |
section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
|
wenzelm@44112
|
62 |
|
wenzelm@44117
|
63 |
text {* An \emph{inductive definition} specifies the least predicate
|
wenzelm@44117
|
64 |
or set @{text R} closed under given rules: applying a rule to
|
wenzelm@44117
|
65 |
elements of @{text R} yields a result within @{text R}. For
|
wenzelm@44117
|
66 |
example, a structural operational semantics is an inductive
|
wenzelm@44117
|
67 |
definition of an evaluation relation.
|
wenzelm@44112
|
68 |
|
wenzelm@44117
|
69 |
Dually, a \emph{coinductive definition} specifies the greatest
|
wenzelm@44117
|
70 |
predicate or set @{text R} that is consistent with given rules:
|
wenzelm@44117
|
71 |
every element of @{text R} can be seen as arising by applying a rule
|
wenzelm@44117
|
72 |
to elements of @{text R}. An important example is using
|
wenzelm@44117
|
73 |
bisimulation relations to formalise equivalence of processes and
|
wenzelm@44117
|
74 |
infinite data structures.
|
wenzelm@44117
|
75 |
|
wenzelm@44117
|
76 |
Both inductive and coinductive definitions are based on the
|
wenzelm@44117
|
77 |
Knaster-Tarski fixed-point theorem for complete lattices. The
|
wenzelm@44117
|
78 |
collection of introduction rules given by the user determines a
|
wenzelm@44117
|
79 |
functor on subsets of set-theoretic relations. The required
|
wenzelm@44117
|
80 |
monotonicity of the recursion scheme is proven as a prerequisite to
|
wenzelm@44117
|
81 |
the fixed-point definition and the resulting consequences. This
|
wenzelm@44117
|
82 |
works by pushing inclusion through logical connectives and any other
|
wenzelm@44117
|
83 |
operator that might be wrapped around recursive occurrences of the
|
wenzelm@44117
|
84 |
defined relation: there must be a monotonicity theorem of the form
|
wenzelm@44117
|
85 |
@{text "A \<le> B \<Longrightarrow> \<M> A \<le> \<M> B"}, for each premise @{text "\<M> R t"} in an
|
wenzelm@44117
|
86 |
introduction rule. The default rule declarations of Isabelle/HOL
|
wenzelm@44117
|
87 |
already take care of most common situations.
|
wenzelm@44112
|
88 |
|
wenzelm@44112
|
89 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
90 |
@{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
91 |
@{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
92 |
@{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
93 |
@{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
94 |
@{attribute_def (HOL) mono} & : & @{text attribute} \\
|
wenzelm@44112
|
95 |
\end{matharray}
|
wenzelm@44112
|
96 |
|
wenzelm@44112
|
97 |
@{rail "
|
wenzelm@44112
|
98 |
(@@{command (HOL) inductive} | @@{command (HOL) inductive_set} |
|
wenzelm@44112
|
99 |
@@{command (HOL) coinductive} | @@{command (HOL) coinductive_set})
|
wenzelm@44117
|
100 |
@{syntax target}? \\
|
wenzelm@44117
|
101 |
@{syntax \"fixes\"} (@'for' @{syntax \"fixes\"})? (@'where' clauses)? \\
|
wenzelm@44117
|
102 |
(@'monos' @{syntax thmrefs})?
|
wenzelm@44112
|
103 |
;
|
wenzelm@44112
|
104 |
clauses: (@{syntax thmdecl}? @{syntax prop} + '|')
|
wenzelm@44112
|
105 |
;
|
wenzelm@44112
|
106 |
@@{attribute (HOL) mono} (() | 'add' | 'del')
|
wenzelm@44112
|
107 |
"}
|
wenzelm@44112
|
108 |
|
wenzelm@44112
|
109 |
\begin{description}
|
wenzelm@44112
|
110 |
|
wenzelm@44112
|
111 |
\item @{command (HOL) "inductive"} and @{command (HOL)
|
wenzelm@44117
|
112 |
"coinductive"} define (co)inductive predicates from the introduction
|
wenzelm@44117
|
113 |
rules.
|
wenzelm@44117
|
114 |
|
wenzelm@44117
|
115 |
The propositions given as @{text "clauses"} in the @{keyword
|
wenzelm@44117
|
116 |
"where"} part are either rules of the usual @{text "\<And>/\<Longrightarrow>"} format
|
wenzelm@44117
|
117 |
(with arbitrary nesting), or equalities using @{text "\<equiv>"}. The
|
wenzelm@44117
|
118 |
latter specifies extra-logical abbreviations in the sense of
|
wenzelm@44117
|
119 |
@{command_ref abbreviation}. Introducing abstract syntax
|
wenzelm@44117
|
120 |
simultaneously with the actual introduction rules is occasionally
|
wenzelm@44117
|
121 |
useful for complex specifications.
|
wenzelm@44117
|
122 |
|
wenzelm@44117
|
123 |
The optional @{keyword "for"} part contains a list of parameters of
|
wenzelm@44117
|
124 |
the (co)inductive predicates that remain fixed throughout the
|
wenzelm@44117
|
125 |
definition, in contrast to arguments of the relation that may vary
|
wenzelm@44117
|
126 |
in each occurrence within the given @{text "clauses"}.
|
wenzelm@44117
|
127 |
|
wenzelm@44117
|
128 |
The optional @{keyword "monos"} declaration contains additional
|
wenzelm@44112
|
129 |
\emph{monotonicity theorems}, which are required for each operator
|
wenzelm@44117
|
130 |
applied to a recursive set in the introduction rules.
|
wenzelm@44112
|
131 |
|
wenzelm@44112
|
132 |
\item @{command (HOL) "inductive_set"} and @{command (HOL)
|
wenzelm@44117
|
133 |
"coinductive_set"} are wrappers for to the previous commands for
|
wenzelm@44117
|
134 |
native HOL predicates. This allows to define (co)inductive sets,
|
wenzelm@44117
|
135 |
where multiple arguments are simulated via tuples.
|
wenzelm@44112
|
136 |
|
wenzelm@44117
|
137 |
\item @{attribute (HOL) mono} declares monotonicity rules in the
|
wenzelm@44117
|
138 |
context. These rule are involved in the automated monotonicity
|
wenzelm@44117
|
139 |
proof of the above inductive and coinductive definitions.
|
wenzelm@44112
|
140 |
|
wenzelm@44112
|
141 |
\end{description}
|
wenzelm@44112
|
142 |
*}
|
wenzelm@44112
|
143 |
|
wenzelm@44112
|
144 |
|
wenzelm@44112
|
145 |
subsection {* Derived rules *}
|
wenzelm@44112
|
146 |
|
wenzelm@44117
|
147 |
text {* A (co)inductive definition of @{text R} provides the following
|
wenzelm@44117
|
148 |
main theorems:
|
wenzelm@44112
|
149 |
|
wenzelm@44112
|
150 |
\begin{description}
|
wenzelm@44112
|
151 |
|
wenzelm@44112
|
152 |
\item @{text R.intros} is the list of introduction rules as proven
|
wenzelm@44112
|
153 |
theorems, for the recursive predicates (or sets). The rules are
|
wenzelm@44112
|
154 |
also available individually, using the names given them in the
|
wenzelm@44112
|
155 |
theory file;
|
wenzelm@44112
|
156 |
|
wenzelm@44112
|
157 |
\item @{text R.cases} is the case analysis (or elimination) rule;
|
wenzelm@44112
|
158 |
|
wenzelm@44112
|
159 |
\item @{text R.induct} or @{text R.coinduct} is the (co)induction
|
wenzelm@44112
|
160 |
rule.
|
wenzelm@44112
|
161 |
|
wenzelm@44112
|
162 |
\end{description}
|
wenzelm@44112
|
163 |
|
wenzelm@44112
|
164 |
When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
|
wenzelm@44112
|
165 |
defined simultaneously, the list of introduction rules is called
|
wenzelm@44112
|
166 |
@{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
|
wenzelm@44112
|
167 |
called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
|
wenzelm@44112
|
168 |
of mutual induction rules is called @{text
|
wenzelm@44112
|
169 |
"R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
|
wenzelm@44112
|
170 |
*}
|
wenzelm@44112
|
171 |
|
wenzelm@44112
|
172 |
|
wenzelm@44112
|
173 |
subsection {* Monotonicity theorems *}
|
wenzelm@44112
|
174 |
|
wenzelm@44117
|
175 |
text {* The context maintains a default set of theorems that are used
|
wenzelm@44117
|
176 |
in monotonicity proofs. New rules can be declared via the
|
wenzelm@44117
|
177 |
@{attribute (HOL) mono} attribute. See the main Isabelle/HOL
|
wenzelm@44117
|
178 |
sources for some examples. The general format of such monotonicity
|
wenzelm@44117
|
179 |
theorems is as follows:
|
wenzelm@44112
|
180 |
|
wenzelm@44112
|
181 |
\begin{itemize}
|
wenzelm@44112
|
182 |
|
wenzelm@44117
|
183 |
\item Theorems of the form @{text "A \<le> B \<Longrightarrow> \<M> A \<le> \<M> B"}, for proving
|
wenzelm@44112
|
184 |
monotonicity of inductive definitions whose introduction rules have
|
wenzelm@44117
|
185 |
premises involving terms such as @{text "\<M> R t"}.
|
wenzelm@44112
|
186 |
|
wenzelm@44112
|
187 |
\item Monotonicity theorems for logical operators, which are of the
|
wenzelm@44112
|
188 |
general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}. For example, in
|
wenzelm@44112
|
189 |
the case of the operator @{text "\<or>"}, the corresponding theorem is
|
wenzelm@44112
|
190 |
\[
|
wenzelm@44112
|
191 |
\infer{@{text "P\<^sub>1 \<or> P\<^sub>2 \<longrightarrow> Q\<^sub>1 \<or> Q\<^sub>2"}}{@{text "P\<^sub>1 \<longrightarrow> Q\<^sub>1"} & @{text "P\<^sub>2 \<longrightarrow> Q\<^sub>2"}}
|
wenzelm@44112
|
192 |
\]
|
wenzelm@44112
|
193 |
|
wenzelm@44112
|
194 |
\item De Morgan style equations for reasoning about the ``polarity''
|
wenzelm@44112
|
195 |
of expressions, e.g.
|
wenzelm@44112
|
196 |
\[
|
wenzelm@44112
|
197 |
@{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
|
wenzelm@44112
|
198 |
@{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
|
wenzelm@44112
|
199 |
\]
|
wenzelm@44112
|
200 |
|
wenzelm@44112
|
201 |
\item Equations for reducing complex operators to more primitive
|
wenzelm@44112
|
202 |
ones whose monotonicity can easily be proved, e.g.
|
wenzelm@44112
|
203 |
\[
|
wenzelm@44112
|
204 |
@{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
|
wenzelm@44112
|
205 |
@{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
|
wenzelm@44112
|
206 |
\]
|
wenzelm@44112
|
207 |
|
wenzelm@44112
|
208 |
\end{itemize}
|
wenzelm@44117
|
209 |
*}
|
wenzelm@44112
|
210 |
|
wenzelm@44117
|
211 |
subsubsection {* Examples *}
|
wenzelm@44117
|
212 |
|
wenzelm@44117
|
213 |
text {* The finite powerset operator can be defined inductively like this: *}
|
wenzelm@44117
|
214 |
|
wenzelm@44117
|
215 |
inductive_set Fin :: "'a set \<Rightarrow> 'a set set" for A :: "'a set"
|
wenzelm@44117
|
216 |
where
|
wenzelm@44117
|
217 |
empty: "{} \<in> Fin A"
|
wenzelm@44117
|
218 |
| insert: "a \<in> A \<Longrightarrow> B \<in> Fin A \<Longrightarrow> insert a B \<in> Fin A"
|
wenzelm@44117
|
219 |
|
wenzelm@44117
|
220 |
text {* The accessible part of a relation is defined as follows: *}
|
wenzelm@44117
|
221 |
|
wenzelm@44117
|
222 |
inductive acc :: "('a \<Rightarrow> 'a \<Rightarrow> bool) \<Rightarrow> 'a \<Rightarrow> bool"
|
wenzelm@44117
|
223 |
for r :: "'a \<Rightarrow> 'a \<Rightarrow> bool" (infix "\<prec>" 50)
|
wenzelm@44117
|
224 |
where acc: "(\<And>y. y \<prec> x \<Longrightarrow> acc r y) \<Longrightarrow> acc r x"
|
wenzelm@44117
|
225 |
|
wenzelm@44117
|
226 |
text {* Common logical connectives can be easily characterized as
|
wenzelm@44117
|
227 |
non-recursive inductive definitions with parameters, but without
|
wenzelm@44117
|
228 |
arguments. *}
|
wenzelm@44117
|
229 |
|
wenzelm@44117
|
230 |
inductive AND for A B :: bool
|
wenzelm@44117
|
231 |
where "A \<Longrightarrow> B \<Longrightarrow> AND A B"
|
wenzelm@44117
|
232 |
|
wenzelm@44117
|
233 |
inductive OR for A B :: bool
|
wenzelm@44117
|
234 |
where "A \<Longrightarrow> OR A B"
|
wenzelm@44117
|
235 |
| "B \<Longrightarrow> OR A B"
|
wenzelm@44117
|
236 |
|
wenzelm@44117
|
237 |
inductive EXISTS for B :: "'a \<Rightarrow> bool"
|
wenzelm@44117
|
238 |
where "B a \<Longrightarrow> EXISTS B"
|
wenzelm@44117
|
239 |
|
wenzelm@44117
|
240 |
text {* Here the @{text "cases"} or @{text "induct"} rules produced by
|
wenzelm@44117
|
241 |
the @{command inductive} package coincide with the expected
|
wenzelm@44117
|
242 |
elimination rules for Natural Deduction. Already in the original
|
wenzelm@44117
|
243 |
article by Gerhard Gentzen \cite{Gentzen:1935} there is a hint that
|
wenzelm@44117
|
244 |
each connective can be characterized by its introductions, and the
|
wenzelm@44117
|
245 |
elimination can be constructed systematically. *}
|
wenzelm@44112
|
246 |
|
wenzelm@44112
|
247 |
|
wenzelm@44112
|
248 |
section {* Recursive functions \label{sec:recursion} *}
|
wenzelm@44112
|
249 |
|
wenzelm@44112
|
250 |
text {*
|
wenzelm@44112
|
251 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
252 |
@{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
253 |
@{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
254 |
@{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
|
wenzelm@44112
|
255 |
@{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
|
wenzelm@44112
|
256 |
\end{matharray}
|
wenzelm@44112
|
257 |
|
wenzelm@44112
|
258 |
@{rail "
|
wenzelm@44112
|
259 |
@@{command (HOL) primrec} @{syntax target}? @{syntax \"fixes\"} @'where' equations
|
wenzelm@44112
|
260 |
;
|
wenzelm@44112
|
261 |
(@@{command (HOL) fun} | @@{command (HOL) function}) @{syntax target}? functionopts?
|
wenzelm@44112
|
262 |
@{syntax \"fixes\"} \\ @'where' equations
|
wenzelm@44112
|
263 |
;
|
wenzelm@44112
|
264 |
|
wenzelm@44112
|
265 |
equations: (@{syntax thmdecl}? @{syntax prop} + '|')
|
wenzelm@44112
|
266 |
;
|
wenzelm@44112
|
267 |
functionopts: '(' (('sequential' | 'domintros') + ',') ')'
|
wenzelm@44112
|
268 |
;
|
wenzelm@44112
|
269 |
@@{command (HOL) termination} @{syntax term}?
|
wenzelm@44112
|
270 |
"}
|
wenzelm@44112
|
271 |
|
wenzelm@44112
|
272 |
\begin{description}
|
wenzelm@44112
|
273 |
|
wenzelm@44112
|
274 |
\item @{command (HOL) "primrec"} defines primitive recursive
|
wenzelm@44116
|
275 |
functions over datatypes (see also @{command_ref (HOL) datatype} and
|
wenzelm@44116
|
276 |
@{command_ref (HOL) rep_datatype}). The given @{text equations}
|
wenzelm@44116
|
277 |
specify reduction rules that are produced by instantiating the
|
wenzelm@44116
|
278 |
generic combinator for primitive recursion that is available for
|
wenzelm@44116
|
279 |
each datatype.
|
wenzelm@44116
|
280 |
|
wenzelm@44116
|
281 |
Each equation needs to be of the form:
|
wenzelm@44116
|
282 |
|
wenzelm@44116
|
283 |
@{text [display] "f x\<^sub>1 \<dots> x\<^sub>m (C y\<^sub>1 \<dots> y\<^sub>k) z\<^sub>1 \<dots> z\<^sub>n = rhs"}
|
wenzelm@44116
|
284 |
|
wenzelm@44116
|
285 |
such that @{text C} is a datatype constructor, @{text rhs} contains
|
wenzelm@44116
|
286 |
only the free variables on the left-hand side (or from the context),
|
wenzelm@44116
|
287 |
and all recursive occurrences of @{text "f"} in @{text "rhs"} are of
|
wenzelm@44116
|
288 |
the form @{text "f \<dots> y\<^sub>i \<dots>"} for some @{text i}. At most one
|
wenzelm@44116
|
289 |
reduction rule for each constructor can be given. The order does
|
wenzelm@44116
|
290 |
not matter. For missing constructors, the function is defined to
|
wenzelm@44116
|
291 |
return a default value, but this equation is made difficult to
|
wenzelm@44116
|
292 |
access for users.
|
wenzelm@44116
|
293 |
|
wenzelm@44116
|
294 |
The reduction rules are declared as @{attribute simp} by default,
|
wenzelm@44116
|
295 |
which enables standard proof methods like @{method simp} and
|
wenzelm@44116
|
296 |
@{method auto} to normalize expressions of @{text "f"} applied to
|
wenzelm@44116
|
297 |
datatype constructions, by simulating symbolic computation via
|
wenzelm@44116
|
298 |
rewriting.
|
wenzelm@44112
|
299 |
|
wenzelm@44112
|
300 |
\item @{command (HOL) "function"} defines functions by general
|
wenzelm@44112
|
301 |
wellfounded recursion. A detailed description with examples can be
|
wenzelm@44112
|
302 |
found in \cite{isabelle-function}. The function is specified by a
|
wenzelm@44112
|
303 |
set of (possibly conditional) recursive equations with arbitrary
|
wenzelm@44112
|
304 |
pattern matching. The command generates proof obligations for the
|
wenzelm@44112
|
305 |
completeness and the compatibility of patterns.
|
wenzelm@44112
|
306 |
|
wenzelm@44112
|
307 |
The defined function is considered partial, and the resulting
|
wenzelm@44112
|
308 |
simplification rules (named @{text "f.psimps"}) and induction rule
|
wenzelm@44112
|
309 |
(named @{text "f.pinduct"}) are guarded by a generated domain
|
wenzelm@44112
|
310 |
predicate @{text "f_dom"}. The @{command (HOL) "termination"}
|
wenzelm@44112
|
311 |
command can then be used to establish that the function is total.
|
wenzelm@44112
|
312 |
|
wenzelm@44112
|
313 |
\item @{command (HOL) "fun"} is a shorthand notation for ``@{command
|
wenzelm@44112
|
314 |
(HOL) "function"}~@{text "(sequential)"}, followed by automated
|
wenzelm@44112
|
315 |
proof attempts regarding pattern matching and termination. See
|
wenzelm@44112
|
316 |
\cite{isabelle-function} for further details.
|
wenzelm@44112
|
317 |
|
wenzelm@44112
|
318 |
\item @{command (HOL) "termination"}~@{text f} commences a
|
wenzelm@44112
|
319 |
termination proof for the previously defined function @{text f}. If
|
wenzelm@44112
|
320 |
this is omitted, the command refers to the most recent function
|
wenzelm@44112
|
321 |
definition. After the proof is closed, the recursive equations and
|
wenzelm@44112
|
322 |
the induction principle is established.
|
wenzelm@44112
|
323 |
|
wenzelm@44112
|
324 |
\end{description}
|
wenzelm@44112
|
325 |
|
wenzelm@44112
|
326 |
Recursive definitions introduced by the @{command (HOL) "function"}
|
wenzelm@44116
|
327 |
command accommodate reasoning by induction (cf.\ @{method induct}):
|
wenzelm@44116
|
328 |
rule @{text "f.induct"} refers to a specific induction rule, with
|
wenzelm@44116
|
329 |
parameters named according to the user-specified equations. Cases
|
wenzelm@44116
|
330 |
are numbered starting from 1. For @{command (HOL) "primrec"}, the
|
wenzelm@44116
|
331 |
induction principle coincides with structural recursion on the
|
wenzelm@44116
|
332 |
datatype where the recursion is carried out.
|
wenzelm@44112
|
333 |
|
wenzelm@44112
|
334 |
The equations provided by these packages may be referred later as
|
wenzelm@44112
|
335 |
theorem list @{text "f.simps"}, where @{text f} is the (collective)
|
wenzelm@44112
|
336 |
name of the functions defined. Individual equations may be named
|
wenzelm@44112
|
337 |
explicitly as well.
|
wenzelm@44112
|
338 |
|
wenzelm@44112
|
339 |
The @{command (HOL) "function"} command accepts the following
|
wenzelm@44112
|
340 |
options.
|
wenzelm@44112
|
341 |
|
wenzelm@44112
|
342 |
\begin{description}
|
wenzelm@44112
|
343 |
|
wenzelm@44112
|
344 |
\item @{text sequential} enables a preprocessor which disambiguates
|
wenzelm@44112
|
345 |
overlapping patterns by making them mutually disjoint. Earlier
|
wenzelm@44112
|
346 |
equations take precedence over later ones. This allows to give the
|
wenzelm@44112
|
347 |
specification in a format very similar to functional programming.
|
wenzelm@44112
|
348 |
Note that the resulting simplification and induction rules
|
wenzelm@44112
|
349 |
correspond to the transformed specification, not the one given
|
wenzelm@44112
|
350 |
originally. This usually means that each equation given by the user
|
wenzelm@44112
|
351 |
may result in several theorems. Also note that this automatic
|
wenzelm@44112
|
352 |
transformation only works for ML-style datatype patterns.
|
wenzelm@44112
|
353 |
|
wenzelm@44112
|
354 |
\item @{text domintros} enables the automated generation of
|
wenzelm@44112
|
355 |
introduction rules for the domain predicate. While mostly not
|
wenzelm@44112
|
356 |
needed, they can be helpful in some proofs about partial functions.
|
wenzelm@44112
|
357 |
|
wenzelm@44112
|
358 |
\end{description}
|
wenzelm@44112
|
359 |
*}
|
wenzelm@44112
|
360 |
|
wenzelm@44116
|
361 |
subsubsection {* Example: evaluation of expressions *}
|
wenzelm@44116
|
362 |
|
wenzelm@44116
|
363 |
text {* Subsequently, we define mutual datatypes for arithmetic and
|
wenzelm@44116
|
364 |
boolean expressions, and use @{command primrec} for evaluation
|
wenzelm@44116
|
365 |
functions that follow the same recursive structure. *}
|
wenzelm@44116
|
366 |
|
wenzelm@44116
|
367 |
datatype 'a aexp =
|
wenzelm@44116
|
368 |
IF "'a bexp" "'a aexp" "'a aexp"
|
wenzelm@44116
|
369 |
| Sum "'a aexp" "'a aexp"
|
wenzelm@44116
|
370 |
| Diff "'a aexp" "'a aexp"
|
wenzelm@44116
|
371 |
| Var 'a
|
wenzelm@44116
|
372 |
| Num nat
|
wenzelm@44116
|
373 |
and 'a bexp =
|
wenzelm@44116
|
374 |
Less "'a aexp" "'a aexp"
|
wenzelm@44116
|
375 |
| And "'a bexp" "'a bexp"
|
wenzelm@44116
|
376 |
| Neg "'a bexp"
|
wenzelm@44116
|
377 |
|
wenzelm@44116
|
378 |
|
wenzelm@44116
|
379 |
text {* \medskip Evaluation of arithmetic and boolean expressions *}
|
wenzelm@44116
|
380 |
|
wenzelm@44116
|
381 |
primrec evala :: "('a \<Rightarrow> nat) \<Rightarrow> 'a aexp \<Rightarrow> nat"
|
wenzelm@44116
|
382 |
and evalb :: "('a \<Rightarrow> nat) \<Rightarrow> 'a bexp \<Rightarrow> bool"
|
wenzelm@44116
|
383 |
where
|
wenzelm@44116
|
384 |
"evala env (IF b a1 a2) = (if evalb env b then evala env a1 else evala env a2)"
|
wenzelm@44116
|
385 |
| "evala env (Sum a1 a2) = evala env a1 + evala env a2"
|
wenzelm@44116
|
386 |
| "evala env (Diff a1 a2) = evala env a1 - evala env a2"
|
wenzelm@44116
|
387 |
| "evala env (Var v) = env v"
|
wenzelm@44116
|
388 |
| "evala env (Num n) = n"
|
wenzelm@44116
|
389 |
| "evalb env (Less a1 a2) = (evala env a1 < evala env a2)"
|
wenzelm@44116
|
390 |
| "evalb env (And b1 b2) = (evalb env b1 \<and> evalb env b2)"
|
wenzelm@44116
|
391 |
| "evalb env (Neg b) = (\<not> evalb env b)"
|
wenzelm@44116
|
392 |
|
wenzelm@44116
|
393 |
text {* Since the value of an expression depends on the value of its
|
wenzelm@44116
|
394 |
variables, the functions @{const evala} and @{const evalb} take an
|
wenzelm@44116
|
395 |
additional parameter, an \emph{environment} that maps variables to
|
wenzelm@44116
|
396 |
their values.
|
wenzelm@44116
|
397 |
|
wenzelm@44116
|
398 |
\medskip Substitution on expressions can be defined similarly. The
|
wenzelm@44116
|
399 |
mapping @{text f} of type @{typ "'a \<Rightarrow> 'a aexp"} given as a
|
wenzelm@44116
|
400 |
parameter is lifted canonically on the types @{typ "'a aexp"} and
|
wenzelm@44116
|
401 |
@{typ "'a bexp"}, respectively.
|
wenzelm@44116
|
402 |
*}
|
wenzelm@44116
|
403 |
|
wenzelm@44116
|
404 |
primrec substa :: "('a \<Rightarrow> 'b aexp) \<Rightarrow> 'a aexp \<Rightarrow> 'b aexp"
|
wenzelm@44116
|
405 |
and substb :: "('a \<Rightarrow> 'b aexp) \<Rightarrow> 'a bexp \<Rightarrow> 'b bexp"
|
wenzelm@44116
|
406 |
where
|
wenzelm@44116
|
407 |
"substa f (IF b a1 a2) = IF (substb f b) (substa f a1) (substa f a2)"
|
wenzelm@44116
|
408 |
| "substa f (Sum a1 a2) = Sum (substa f a1) (substa f a2)"
|
wenzelm@44116
|
409 |
| "substa f (Diff a1 a2) = Diff (substa f a1) (substa f a2)"
|
wenzelm@44116
|
410 |
| "substa f (Var v) = f v"
|
wenzelm@44116
|
411 |
| "substa f (Num n) = Num n"
|
wenzelm@44116
|
412 |
| "substb f (Less a1 a2) = Less (substa f a1) (substa f a2)"
|
wenzelm@44116
|
413 |
| "substb f (And b1 b2) = And (substb f b1) (substb f b2)"
|
wenzelm@44116
|
414 |
| "substb f (Neg b) = Neg (substb f b)"
|
wenzelm@44116
|
415 |
|
wenzelm@44116
|
416 |
text {* In textbooks about semantics one often finds substitution
|
wenzelm@44116
|
417 |
theorems, which express the relationship between substitution and
|
wenzelm@44116
|
418 |
evaluation. For @{typ "'a aexp"} and @{typ "'a bexp"}, we can prove
|
wenzelm@44116
|
419 |
such a theorem by mutual induction, followed by simplification.
|
wenzelm@44116
|
420 |
*}
|
wenzelm@44116
|
421 |
|
wenzelm@44116
|
422 |
lemma subst_one:
|
wenzelm@44116
|
423 |
"evala env (substa (Var (v := a')) a) = evala (env (v := evala env a')) a"
|
wenzelm@44116
|
424 |
"evalb env (substb (Var (v := a')) b) = evalb (env (v := evala env a')) b"
|
wenzelm@44116
|
425 |
by (induct a and b) simp_all
|
wenzelm@44116
|
426 |
|
wenzelm@44116
|
427 |
lemma subst_all:
|
wenzelm@44116
|
428 |
"evala env (substa s a) = evala (\<lambda>x. evala env (s x)) a"
|
wenzelm@44116
|
429 |
"evalb env (substb s b) = evalb (\<lambda>x. evala env (s x)) b"
|
wenzelm@44116
|
430 |
by (induct a and b) simp_all
|
wenzelm@44116
|
431 |
|
wenzelm@44116
|
432 |
|
wenzelm@44116
|
433 |
subsubsection {* Example: a substitution function for terms *}
|
wenzelm@44116
|
434 |
|
wenzelm@44116
|
435 |
text {* Functions on datatypes with nested recursion are also defined
|
wenzelm@44116
|
436 |
by mutual primitive recursion. *}
|
wenzelm@44116
|
437 |
|
wenzelm@44116
|
438 |
datatype ('a, 'b) "term" = Var 'a | App 'b "('a, 'b) term list"
|
wenzelm@44116
|
439 |
|
wenzelm@44116
|
440 |
text {* A substitution function on type @{typ "('a, 'b) term"} can be
|
wenzelm@44116
|
441 |
defined as follows, by working simultaneously on @{typ "('a, 'b)
|
wenzelm@44116
|
442 |
term list"}: *}
|
wenzelm@44116
|
443 |
|
wenzelm@44116
|
444 |
primrec subst_term :: "('a \<Rightarrow> ('a, 'b) term) \<Rightarrow> ('a, 'b) term \<Rightarrow> ('a, 'b) term" and
|
wenzelm@44116
|
445 |
subst_term_list :: "('a \<Rightarrow> ('a, 'b) term) \<Rightarrow> ('a, 'b) term list \<Rightarrow> ('a, 'b) term list"
|
wenzelm@44116
|
446 |
where
|
wenzelm@44116
|
447 |
"subst_term f (Var a) = f a"
|
wenzelm@44116
|
448 |
| "subst_term f (App b ts) = App b (subst_term_list f ts)"
|
wenzelm@44116
|
449 |
| "subst_term_list f [] = []"
|
wenzelm@44116
|
450 |
| "subst_term_list f (t # ts) = subst_term f t # subst_term_list f ts"
|
wenzelm@44116
|
451 |
|
wenzelm@44116
|
452 |
text {* The recursion scheme follows the structure of the unfolded
|
wenzelm@44116
|
453 |
definition of type @{typ "('a, 'b) term"}. To prove properties of this
|
wenzelm@44116
|
454 |
substitution function, mutual induction is needed:
|
wenzelm@44116
|
455 |
*}
|
wenzelm@44116
|
456 |
|
wenzelm@44116
|
457 |
lemma "subst_term (subst_term f1 \<circ> f2) t = subst_term f1 (subst_term f2 t)" and
|
wenzelm@44116
|
458 |
"subst_term_list (subst_term f1 \<circ> f2) ts = subst_term_list f1 (subst_term_list f2 ts)"
|
wenzelm@44116
|
459 |
by (induct t and ts) simp_all
|
wenzelm@44116
|
460 |
|
wenzelm@44116
|
461 |
|
wenzelm@44116
|
462 |
subsubsection {* Example: a map function for infinitely branching trees *}
|
wenzelm@44116
|
463 |
|
wenzelm@44116
|
464 |
text {* Defining functions on infinitely branching datatypes by
|
wenzelm@44116
|
465 |
primitive recursion is just as easy.
|
wenzelm@44116
|
466 |
*}
|
wenzelm@44116
|
467 |
|
wenzelm@44116
|
468 |
datatype 'a tree = Atom 'a | Branch "nat \<Rightarrow> 'a tree"
|
wenzelm@44116
|
469 |
|
wenzelm@44116
|
470 |
primrec map_tree :: "('a \<Rightarrow> 'b) \<Rightarrow> 'a tree \<Rightarrow> 'b tree"
|
wenzelm@44116
|
471 |
where
|
wenzelm@44116
|
472 |
"map_tree f (Atom a) = Atom (f a)"
|
wenzelm@44116
|
473 |
| "map_tree f (Branch ts) = Branch (\<lambda>x. map_tree f (ts x))"
|
wenzelm@44116
|
474 |
|
wenzelm@44116
|
475 |
text {* Note that all occurrences of functions such as @{text ts}
|
wenzelm@44116
|
476 |
above must be applied to an argument. In particular, @{term
|
wenzelm@44116
|
477 |
"map_tree f \<circ> ts"} is not allowed here. *}
|
wenzelm@44116
|
478 |
|
wenzelm@44116
|
479 |
text {* Here is a simple composition lemma for @{term map_tree}: *}
|
wenzelm@44116
|
480 |
|
wenzelm@44116
|
481 |
lemma "map_tree g (map_tree f t) = map_tree (g \<circ> f) t"
|
wenzelm@44116
|
482 |
by (induct t) simp_all
|
wenzelm@44116
|
483 |
|
wenzelm@44112
|
484 |
|
wenzelm@44112
|
485 |
subsection {* Proof methods related to recursive definitions *}
|
wenzelm@44112
|
486 |
|
wenzelm@44112
|
487 |
text {*
|
wenzelm@44112
|
488 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
489 |
@{method_def (HOL) pat_completeness} & : & @{text method} \\
|
wenzelm@44112
|
490 |
@{method_def (HOL) relation} & : & @{text method} \\
|
wenzelm@44112
|
491 |
@{method_def (HOL) lexicographic_order} & : & @{text method} \\
|
wenzelm@44112
|
492 |
@{method_def (HOL) size_change} & : & @{text method} \\
|
wenzelm@44112
|
493 |
\end{matharray}
|
wenzelm@44112
|
494 |
|
wenzelm@44112
|
495 |
@{rail "
|
wenzelm@44112
|
496 |
@@{method (HOL) relation} @{syntax term}
|
wenzelm@44112
|
497 |
;
|
wenzelm@44112
|
498 |
@@{method (HOL) lexicographic_order} (@{syntax clasimpmod} * )
|
wenzelm@44112
|
499 |
;
|
wenzelm@44112
|
500 |
@@{method (HOL) size_change} ( orders (@{syntax clasimpmod} * ) )
|
wenzelm@44112
|
501 |
;
|
wenzelm@44112
|
502 |
orders: ( 'max' | 'min' | 'ms' ) *
|
wenzelm@44112
|
503 |
"}
|
wenzelm@44112
|
504 |
|
wenzelm@44112
|
505 |
\begin{description}
|
wenzelm@44112
|
506 |
|
wenzelm@44112
|
507 |
\item @{method (HOL) pat_completeness} is a specialized method to
|
wenzelm@44112
|
508 |
solve goals regarding the completeness of pattern matching, as
|
wenzelm@44112
|
509 |
required by the @{command (HOL) "function"} package (cf.\
|
wenzelm@44112
|
510 |
\cite{isabelle-function}).
|
wenzelm@44112
|
511 |
|
wenzelm@44112
|
512 |
\item @{method (HOL) relation}~@{text R} introduces a termination
|
wenzelm@44112
|
513 |
proof using the relation @{text R}. The resulting proof state will
|
wenzelm@44112
|
514 |
contain goals expressing that @{text R} is wellfounded, and that the
|
wenzelm@44112
|
515 |
arguments of recursive calls decrease with respect to @{text R}.
|
wenzelm@44112
|
516 |
Usually, this method is used as the initial proof step of manual
|
wenzelm@44112
|
517 |
termination proofs.
|
wenzelm@44112
|
518 |
|
wenzelm@44112
|
519 |
\item @{method (HOL) "lexicographic_order"} attempts a fully
|
wenzelm@44112
|
520 |
automated termination proof by searching for a lexicographic
|
wenzelm@44112
|
521 |
combination of size measures on the arguments of the function. The
|
wenzelm@44112
|
522 |
method accepts the same arguments as the @{method auto} method,
|
wenzelm@44134
|
523 |
which it uses internally to prove local descents. The @{syntax
|
wenzelm@44134
|
524 |
clasimpmod} modifiers are accepted (as for @{method auto}).
|
wenzelm@44112
|
525 |
|
wenzelm@44112
|
526 |
In case of failure, extensive information is printed, which can help
|
wenzelm@44112
|
527 |
to analyse the situation (cf.\ \cite{isabelle-function}).
|
wenzelm@44112
|
528 |
|
wenzelm@44112
|
529 |
\item @{method (HOL) "size_change"} also works on termination goals,
|
wenzelm@44112
|
530 |
using a variation of the size-change principle, together with a
|
wenzelm@44112
|
531 |
graph decomposition technique (see \cite{krauss_phd} for details).
|
wenzelm@44112
|
532 |
Three kinds of orders are used internally: @{text max}, @{text min},
|
wenzelm@44112
|
533 |
and @{text ms} (multiset), which is only available when the theory
|
wenzelm@44112
|
534 |
@{text Multiset} is loaded. When no order kinds are given, they are
|
wenzelm@44112
|
535 |
tried in order. The search for a termination proof uses SAT solving
|
wenzelm@44112
|
536 |
internally.
|
wenzelm@44112
|
537 |
|
wenzelm@44134
|
538 |
For local descent proofs, the @{syntax clasimpmod} modifiers are
|
wenzelm@44134
|
539 |
accepted (as for @{method auto}).
|
wenzelm@44112
|
540 |
|
wenzelm@44112
|
541 |
\end{description}
|
wenzelm@44112
|
542 |
*}
|
wenzelm@44112
|
543 |
|
wenzelm@44112
|
544 |
|
wenzelm@44112
|
545 |
subsection {* Functions with explicit partiality *}
|
wenzelm@44112
|
546 |
|
wenzelm@44112
|
547 |
text {*
|
wenzelm@44112
|
548 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
549 |
@{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@44112
|
550 |
@{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
|
wenzelm@44112
|
551 |
\end{matharray}
|
wenzelm@44112
|
552 |
|
wenzelm@44112
|
553 |
@{rail "
|
wenzelm@44112
|
554 |
@@{command (HOL) partial_function} @{syntax target}?
|
wenzelm@44112
|
555 |
'(' @{syntax nameref} ')' @{syntax \"fixes\"} \\
|
wenzelm@44112
|
556 |
@'where' @{syntax thmdecl}? @{syntax prop}
|
wenzelm@44112
|
557 |
"}
|
wenzelm@44112
|
558 |
|
wenzelm@44112
|
559 |
\begin{description}
|
wenzelm@44112
|
560 |
|
wenzelm@44112
|
561 |
\item @{command (HOL) "partial_function"}~@{text "(mode)"} defines
|
wenzelm@44112
|
562 |
recursive functions based on fixpoints in complete partial
|
wenzelm@44112
|
563 |
orders. No termination proof is required from the user or
|
wenzelm@44112
|
564 |
constructed internally. Instead, the possibility of non-termination
|
wenzelm@44112
|
565 |
is modelled explicitly in the result type, which contains an
|
wenzelm@44112
|
566 |
explicit bottom element.
|
wenzelm@44112
|
567 |
|
wenzelm@44112
|
568 |
Pattern matching and mutual recursion are currently not supported.
|
wenzelm@44112
|
569 |
Thus, the specification consists of a single function described by a
|
wenzelm@44112
|
570 |
single recursive equation.
|
wenzelm@44112
|
571 |
|
wenzelm@44112
|
572 |
There are no fixed syntactic restrictions on the body of the
|
wenzelm@44112
|
573 |
function, but the induced functional must be provably monotonic
|
wenzelm@44112
|
574 |
wrt.\ the underlying order. The monotonicitity proof is performed
|
wenzelm@44112
|
575 |
internally, and the definition is rejected when it fails. The proof
|
wenzelm@44112
|
576 |
can be influenced by declaring hints using the
|
wenzelm@44112
|
577 |
@{attribute (HOL) partial_function_mono} attribute.
|
wenzelm@44112
|
578 |
|
wenzelm@44112
|
579 |
The mandatory @{text mode} argument specifies the mode of operation
|
wenzelm@44112
|
580 |
of the command, which directly corresponds to a complete partial
|
wenzelm@44112
|
581 |
order on the result type. By default, the following modes are
|
wenzelm@44112
|
582 |
defined:
|
wenzelm@44112
|
583 |
|
wenzelm@44112
|
584 |
\begin{description}
|
wenzelm@44112
|
585 |
\item @{text option} defines functions that map into the @{type
|
wenzelm@44112
|
586 |
option} type. Here, the value @{term None} is used to model a
|
wenzelm@44112
|
587 |
non-terminating computation. Monotonicity requires that if @{term
|
wenzelm@44112
|
588 |
None} is returned by a recursive call, then the overall result
|
wenzelm@44112
|
589 |
must also be @{term None}. This is best achieved through the use of
|
wenzelm@44112
|
590 |
the monadic operator @{const "Option.bind"}.
|
wenzelm@44112
|
591 |
|
wenzelm@44112
|
592 |
\item @{text tailrec} defines functions with an arbitrary result
|
wenzelm@44112
|
593 |
type and uses the slightly degenerated partial order where @{term
|
wenzelm@44112
|
594 |
"undefined"} is the bottom element. Now, monotonicity requires that
|
wenzelm@44112
|
595 |
if @{term undefined} is returned by a recursive call, then the
|
wenzelm@44112
|
596 |
overall result must also be @{term undefined}. In practice, this is
|
wenzelm@44112
|
597 |
only satisfied when each recursive call is a tail call, whose result
|
wenzelm@44112
|
598 |
is directly returned. Thus, this mode of operation allows the
|
wenzelm@44112
|
599 |
definition of arbitrary tail-recursive functions.
|
wenzelm@44112
|
600 |
\end{description}
|
wenzelm@44112
|
601 |
|
wenzelm@44112
|
602 |
Experienced users may define new modes by instantiating the locale
|
wenzelm@44112
|
603 |
@{const "partial_function_definitions"} appropriately.
|
wenzelm@44112
|
604 |
|
wenzelm@44112
|
605 |
\item @{attribute (HOL) partial_function_mono} declares rules for
|
wenzelm@44112
|
606 |
use in the internal monononicity proofs of partial function
|
wenzelm@44112
|
607 |
definitions.
|
wenzelm@44112
|
608 |
|
wenzelm@44112
|
609 |
\end{description}
|
wenzelm@44112
|
610 |
|
wenzelm@44112
|
611 |
*}
|
wenzelm@44112
|
612 |
|
wenzelm@44112
|
613 |
|
wenzelm@44112
|
614 |
subsection {* Old-style recursive function definitions (TFL) *}
|
wenzelm@44112
|
615 |
|
wenzelm@44112
|
616 |
text {*
|
wenzelm@44112
|
617 |
The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
|
wenzelm@44112
|
618 |
"recdef_tc"} for defining recursive are mostly obsolete; @{command
|
wenzelm@44112
|
619 |
(HOL) "function"} or @{command (HOL) "fun"} should be used instead.
|
wenzelm@44112
|
620 |
|
wenzelm@44112
|
621 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
622 |
@{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
|
wenzelm@44112
|
623 |
@{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@44112
|
624 |
\end{matharray}
|
wenzelm@44112
|
625 |
|
wenzelm@44112
|
626 |
@{rail "
|
wenzelm@44112
|
627 |
@@{command (HOL) recdef} ('(' @'permissive' ')')? \\
|
wenzelm@44112
|
628 |
@{syntax name} @{syntax term} (@{syntax prop} +) hints?
|
wenzelm@44112
|
629 |
;
|
wenzelm@44112
|
630 |
recdeftc @{syntax thmdecl}? tc
|
wenzelm@44112
|
631 |
;
|
wenzelm@44112
|
632 |
hints: '(' @'hints' ( recdefmod * ) ')'
|
wenzelm@44112
|
633 |
;
|
wenzelm@44112
|
634 |
recdefmod: (('recdef_simp' | 'recdef_cong' | 'recdef_wf')
|
wenzelm@44112
|
635 |
(() | 'add' | 'del') ':' @{syntax thmrefs}) | @{syntax clasimpmod}
|
wenzelm@44112
|
636 |
;
|
wenzelm@44112
|
637 |
tc: @{syntax nameref} ('(' @{syntax nat} ')')?
|
wenzelm@44112
|
638 |
"}
|
wenzelm@44112
|
639 |
|
wenzelm@44112
|
640 |
\begin{description}
|
wenzelm@44112
|
641 |
|
wenzelm@44112
|
642 |
\item @{command (HOL) "recdef"} defines general well-founded
|
wenzelm@44112
|
643 |
recursive functions (using the TFL package), see also
|
wenzelm@44112
|
644 |
\cite{isabelle-HOL}. The ``@{text "(permissive)"}'' option tells
|
wenzelm@44112
|
645 |
TFL to recover from failed proof attempts, returning unfinished
|
wenzelm@44112
|
646 |
results. The @{text recdef_simp}, @{text recdef_cong}, and @{text
|
wenzelm@44112
|
647 |
recdef_wf} hints refer to auxiliary rules to be used in the internal
|
wenzelm@44112
|
648 |
automated proof process of TFL. Additional @{syntax clasimpmod}
|
wenzelm@44134
|
649 |
declarations may be given to tune the context of the Simplifier
|
wenzelm@44134
|
650 |
(cf.\ \secref{sec:simplifier}) and Classical reasoner (cf.\
|
wenzelm@44134
|
651 |
\secref{sec:classical}).
|
wenzelm@44112
|
652 |
|
wenzelm@44112
|
653 |
\item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
|
wenzelm@44112
|
654 |
proof for leftover termination condition number @{text i} (default
|
wenzelm@44112
|
655 |
1) as generated by a @{command (HOL) "recdef"} definition of
|
wenzelm@44112
|
656 |
constant @{text c}.
|
wenzelm@44112
|
657 |
|
wenzelm@44112
|
658 |
Note that in most cases, @{command (HOL) "recdef"} is able to finish
|
wenzelm@44112
|
659 |
its internal proofs without manual intervention.
|
wenzelm@44112
|
660 |
|
wenzelm@44112
|
661 |
\end{description}
|
wenzelm@44112
|
662 |
|
wenzelm@44112
|
663 |
\medskip Hints for @{command (HOL) "recdef"} may be also declared
|
wenzelm@44112
|
664 |
globally, using the following attributes.
|
wenzelm@44112
|
665 |
|
wenzelm@44112
|
666 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
667 |
@{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
|
wenzelm@44112
|
668 |
@{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
|
wenzelm@44112
|
669 |
@{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
|
wenzelm@44112
|
670 |
\end{matharray}
|
wenzelm@44112
|
671 |
|
wenzelm@44112
|
672 |
@{rail "
|
wenzelm@44112
|
673 |
(@@{attribute (HOL) recdef_simp} | @@{attribute (HOL) recdef_cong} |
|
wenzelm@44112
|
674 |
@@{attribute (HOL) recdef_wf}) (() | 'add' | 'del')
|
wenzelm@44112
|
675 |
"}
|
wenzelm@44112
|
676 |
*}
|
wenzelm@44112
|
677 |
|
wenzelm@44112
|
678 |
|
wenzelm@44112
|
679 |
section {* Datatypes \label{sec:hol-datatype} *}
|
wenzelm@44112
|
680 |
|
wenzelm@44112
|
681 |
text {*
|
wenzelm@44112
|
682 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
683 |
@{command_def (HOL) "datatype"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@44112
|
684 |
@{command_def (HOL) "rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@44112
|
685 |
\end{matharray}
|
wenzelm@44112
|
686 |
|
wenzelm@44112
|
687 |
@{rail "
|
wenzelm@44112
|
688 |
@@{command (HOL) datatype} (spec + @'and')
|
wenzelm@44112
|
689 |
;
|
wenzelm@44112
|
690 |
@@{command (HOL) rep_datatype} ('(' (@{syntax name} +) ')')? (@{syntax term} +)
|
wenzelm@44112
|
691 |
;
|
wenzelm@44112
|
692 |
|
wenzelm@44112
|
693 |
spec: @{syntax parname}? @{syntax typespec} @{syntax mixfix}? '=' (cons + '|')
|
wenzelm@44112
|
694 |
;
|
wenzelm@44112
|
695 |
cons: @{syntax name} (@{syntax type} * ) @{syntax mixfix}?
|
wenzelm@44112
|
696 |
"}
|
wenzelm@44112
|
697 |
|
wenzelm@44112
|
698 |
\begin{description}
|
wenzelm@44112
|
699 |
|
wenzelm@44112
|
700 |
\item @{command (HOL) "datatype"} defines inductive datatypes in
|
wenzelm@44112
|
701 |
HOL.
|
wenzelm@44112
|
702 |
|
wenzelm@44112
|
703 |
\item @{command (HOL) "rep_datatype"} represents existing types as
|
wenzelm@44113
|
704 |
datatypes.
|
wenzelm@44113
|
705 |
|
wenzelm@44113
|
706 |
For foundational reasons, some basic types such as @{typ nat}, @{typ
|
wenzelm@44113
|
707 |
"'a \<times> 'b"}, @{typ "'a + 'b"}, @{typ bool} and @{typ unit} are
|
wenzelm@44113
|
708 |
introduced by more primitive means using @{command_ref typedef}. To
|
wenzelm@44113
|
709 |
recover the rich infrastructure of @{command datatype} (e.g.\ rules
|
wenzelm@44113
|
710 |
for @{method cases} and @{method induct} and the primitive recursion
|
wenzelm@44113
|
711 |
combinators), such types may be represented as actual datatypes
|
wenzelm@44113
|
712 |
later. This is done by specifying the constructors of the desired
|
wenzelm@44113
|
713 |
type, and giving a proof of the induction rule, distinctness and
|
wenzelm@44113
|
714 |
injectivity of constructors.
|
wenzelm@44113
|
715 |
|
wenzelm@44113
|
716 |
For example, see @{file "~~/src/HOL/Sum_Type.thy"} for the
|
wenzelm@44113
|
717 |
representation of the primitive sum type as fully-featured datatype.
|
wenzelm@44112
|
718 |
|
wenzelm@44112
|
719 |
\end{description}
|
wenzelm@44112
|
720 |
|
wenzelm@44113
|
721 |
The generated rules for @{method induct} and @{method cases} provide
|
wenzelm@44113
|
722 |
case names according to the given constructors, while parameters are
|
wenzelm@44113
|
723 |
named after the types (see also \secref{sec:cases-induct}).
|
wenzelm@44112
|
724 |
|
wenzelm@44112
|
725 |
See \cite{isabelle-HOL} for more details on datatypes, but beware of
|
wenzelm@44112
|
726 |
the old-style theory syntax being used there! Apart from proper
|
wenzelm@44112
|
727 |
proof methods for case-analysis and induction, there are also
|
wenzelm@44112
|
728 |
emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
|
wenzelm@44112
|
729 |
induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
|
wenzelm@44112
|
730 |
to refer directly to the internal structure of subgoals (including
|
wenzelm@44112
|
731 |
internally bound parameters).
|
wenzelm@44112
|
732 |
*}
|
wenzelm@44112
|
733 |
|
wenzelm@44112
|
734 |
|
wenzelm@44114
|
735 |
subsubsection {* Examples *}
|
wenzelm@44114
|
736 |
|
wenzelm@44114
|
737 |
text {* We define a type of finite sequences, with slightly different
|
wenzelm@44114
|
738 |
names than the existing @{typ "'a list"} that is already in @{theory
|
wenzelm@44114
|
739 |
Main}: *}
|
wenzelm@44114
|
740 |
|
wenzelm@44114
|
741 |
datatype 'a seq = Empty | Seq 'a "'a seq"
|
wenzelm@44114
|
742 |
|
wenzelm@44114
|
743 |
text {* We can now prove some simple lemma by structural induction: *}
|
wenzelm@44114
|
744 |
|
wenzelm@44114
|
745 |
lemma "Seq x xs \<noteq> xs"
|
wenzelm@44114
|
746 |
proof (induct xs arbitrary: x)
|
wenzelm@44114
|
747 |
case Empty
|
wenzelm@44114
|
748 |
txt {* This case can be proved using the simplifier: the freeness
|
wenzelm@44114
|
749 |
properties of the datatype are already declared as @{attribute
|
wenzelm@44114
|
750 |
simp} rules. *}
|
wenzelm@44114
|
751 |
show "Seq x Empty \<noteq> Empty"
|
wenzelm@44114
|
752 |
by simp
|
wenzelm@44114
|
753 |
next
|
wenzelm@44114
|
754 |
case (Seq y ys)
|
wenzelm@44114
|
755 |
txt {* The step case is proved similarly. *}
|
wenzelm@44114
|
756 |
show "Seq x (Seq y ys) \<noteq> Seq y ys"
|
wenzelm@44114
|
757 |
using `Seq y ys \<noteq> ys` by simp
|
wenzelm@44114
|
758 |
qed
|
wenzelm@44114
|
759 |
|
wenzelm@44114
|
760 |
text {* Here is a more succinct version of the same proof: *}
|
wenzelm@44114
|
761 |
|
wenzelm@44114
|
762 |
lemma "Seq x xs \<noteq> xs"
|
wenzelm@44114
|
763 |
by (induct xs arbitrary: x) simp_all
|
wenzelm@44114
|
764 |
|
wenzelm@44114
|
765 |
|
wenzelm@44112
|
766 |
section {* Records \label{sec:hol-record} *}
|
wenzelm@44112
|
767 |
|
wenzelm@44112
|
768 |
text {*
|
wenzelm@44112
|
769 |
In principle, records merely generalize the concept of tuples, where
|
wenzelm@44112
|
770 |
components may be addressed by labels instead of just position. The
|
wenzelm@44112
|
771 |
logical infrastructure of records in Isabelle/HOL is slightly more
|
wenzelm@44112
|
772 |
advanced, though, supporting truly extensible record schemes. This
|
wenzelm@44112
|
773 |
admits operations that are polymorphic with respect to record
|
wenzelm@44112
|
774 |
extension, yielding ``object-oriented'' effects like (single)
|
wenzelm@44112
|
775 |
inheritance. See also \cite{NaraschewskiW-TPHOLs98} for more
|
wenzelm@44112
|
776 |
details on object-oriented verification and record subtyping in HOL.
|
wenzelm@44112
|
777 |
*}
|
wenzelm@44112
|
778 |
|
wenzelm@44112
|
779 |
|
wenzelm@44112
|
780 |
subsection {* Basic concepts *}
|
wenzelm@44112
|
781 |
|
wenzelm@44112
|
782 |
text {*
|
wenzelm@44112
|
783 |
Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
|
wenzelm@44112
|
784 |
at the level of terms and types. The notation is as follows:
|
wenzelm@44112
|
785 |
|
wenzelm@44112
|
786 |
\begin{center}
|
wenzelm@44112
|
787 |
\begin{tabular}{l|l|l}
|
wenzelm@44112
|
788 |
& record terms & record types \\ \hline
|
wenzelm@44112
|
789 |
fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
|
wenzelm@44112
|
790 |
schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
|
wenzelm@44112
|
791 |
@{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
|
wenzelm@44112
|
792 |
\end{tabular}
|
wenzelm@44112
|
793 |
\end{center}
|
wenzelm@44112
|
794 |
|
wenzelm@44112
|
795 |
\noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
|
wenzelm@44112
|
796 |
"(| x = a |)"}.
|
wenzelm@44112
|
797 |
|
wenzelm@44112
|
798 |
A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
|
wenzelm@44112
|
799 |
@{text a} and field @{text y} of value @{text b}. The corresponding
|
wenzelm@44112
|
800 |
type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
|
wenzelm@44112
|
801 |
and @{text "b :: B"}.
|
wenzelm@44112
|
802 |
|
wenzelm@44112
|
803 |
A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
|
wenzelm@44112
|
804 |
@{text x} and @{text y} as before, but also possibly further fields
|
wenzelm@44112
|
805 |
as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
|
wenzelm@44112
|
806 |
of the syntax). The improper field ``@{text "\<dots>"}'' of a record
|
wenzelm@44112
|
807 |
scheme is called the \emph{more part}. Logically it is just a free
|
wenzelm@44112
|
808 |
variable, which is occasionally referred to as ``row variable'' in
|
wenzelm@44112
|
809 |
the literature. The more part of a record scheme may be
|
wenzelm@44112
|
810 |
instantiated by zero or more further components. For example, the
|
wenzelm@44112
|
811 |
previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
|
wenzelm@44112
|
812 |
c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
|
wenzelm@44112
|
813 |
Fixed records are special instances of record schemes, where
|
wenzelm@44112
|
814 |
``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
|
wenzelm@44112
|
815 |
element. In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
|
wenzelm@44112
|
816 |
for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
|
wenzelm@44112
|
817 |
|
wenzelm@44112
|
818 |
\medskip Two key observations make extensible records in a simply
|
wenzelm@44112
|
819 |
typed language like HOL work out:
|
wenzelm@44112
|
820 |
|
wenzelm@44112
|
821 |
\begin{enumerate}
|
wenzelm@44112
|
822 |
|
wenzelm@44112
|
823 |
\item the more part is internalized, as a free term or type
|
wenzelm@44112
|
824 |
variable,
|
wenzelm@44112
|
825 |
|
wenzelm@44112
|
826 |
\item field names are externalized, they cannot be accessed within
|
wenzelm@44112
|
827 |
the logic as first-class values.
|
wenzelm@44112
|
828 |
|
wenzelm@44112
|
829 |
\end{enumerate}
|
wenzelm@44112
|
830 |
|
wenzelm@44112
|
831 |
\medskip In Isabelle/HOL record types have to be defined explicitly,
|
wenzelm@44112
|
832 |
fixing their field names and types, and their (optional) parent
|
wenzelm@44112
|
833 |
record. Afterwards, records may be formed using above syntax, while
|
wenzelm@44112
|
834 |
obeying the canonical order of fields as given by their declaration.
|
wenzelm@44112
|
835 |
The record package provides several standard operations like
|
wenzelm@44112
|
836 |
selectors and updates. The common setup for various generic proof
|
wenzelm@44112
|
837 |
tools enable succinct reasoning patterns. See also the Isabelle/HOL
|
wenzelm@44112
|
838 |
tutorial \cite{isabelle-hol-book} for further instructions on using
|
wenzelm@44112
|
839 |
records in practice.
|
wenzelm@44112
|
840 |
*}
|
wenzelm@44112
|
841 |
|
wenzelm@44112
|
842 |
|
wenzelm@44112
|
843 |
subsection {* Record specifications *}
|
wenzelm@44112
|
844 |
|
wenzelm@44112
|
845 |
text {*
|
wenzelm@44112
|
846 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
847 |
@{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@44112
|
848 |
\end{matharray}
|
wenzelm@44112
|
849 |
|
wenzelm@44112
|
850 |
@{rail "
|
wenzelm@44112
|
851 |
@@{command (HOL) record} @{syntax typespec_sorts} '=' \\
|
wenzelm@44112
|
852 |
(@{syntax type} '+')? (@{syntax constdecl} +)
|
wenzelm@44112
|
853 |
"}
|
wenzelm@44112
|
854 |
|
wenzelm@44112
|
855 |
\begin{description}
|
wenzelm@44112
|
856 |
|
wenzelm@44112
|
857 |
\item @{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1
|
wenzelm@44112
|
858 |
\<dots> c\<^sub>n :: \<sigma>\<^sub>n"} defines extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
|
wenzelm@44112
|
859 |
derived from the optional parent record @{text "\<tau>"} by adding new
|
wenzelm@44112
|
860 |
field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
|
wenzelm@44112
|
861 |
|
wenzelm@44112
|
862 |
The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
|
wenzelm@44112
|
863 |
covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
|
wenzelm@44112
|
864 |
\<alpha>\<^sub>m"}. Type constructor @{text t} has to be new, while @{text
|
wenzelm@44112
|
865 |
\<tau>} needs to specify an instance of an existing record type. At
|
wenzelm@44112
|
866 |
least one new field @{text "c\<^sub>i"} has to be specified.
|
wenzelm@44112
|
867 |
Basically, field names need to belong to a unique record. This is
|
wenzelm@44112
|
868 |
not a real restriction in practice, since fields are qualified by
|
wenzelm@44112
|
869 |
the record name internally.
|
wenzelm@44112
|
870 |
|
wenzelm@44112
|
871 |
The parent record specification @{text \<tau>} is optional; if omitted
|
wenzelm@44112
|
872 |
@{text t} becomes a root record. The hierarchy of all records
|
wenzelm@44112
|
873 |
declared within a theory context forms a forest structure, i.e.\ a
|
wenzelm@44112
|
874 |
set of trees starting with a root record each. There is no way to
|
wenzelm@44112
|
875 |
merge multiple parent records!
|
wenzelm@44112
|
876 |
|
wenzelm@44112
|
877 |
For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
|
wenzelm@44112
|
878 |
type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
|
wenzelm@44112
|
879 |
\<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
|
wenzelm@44112
|
880 |
"(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
|
wenzelm@44112
|
881 |
@{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
|
wenzelm@44112
|
882 |
\<zeta>\<rparr>"}.
|
wenzelm@44112
|
883 |
|
wenzelm@44112
|
884 |
\end{description}
|
wenzelm@44112
|
885 |
*}
|
wenzelm@44112
|
886 |
|
wenzelm@44112
|
887 |
|
wenzelm@44112
|
888 |
subsection {* Record operations *}
|
wenzelm@44112
|
889 |
|
wenzelm@44112
|
890 |
text {*
|
wenzelm@44112
|
891 |
Any record definition of the form presented above produces certain
|
wenzelm@44112
|
892 |
standard operations. Selectors and updates are provided for any
|
wenzelm@44112
|
893 |
field, including the improper one ``@{text more}''. There are also
|
wenzelm@44112
|
894 |
cumulative record constructor functions. To simplify the
|
wenzelm@44112
|
895 |
presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
|
wenzelm@44112
|
896 |
\<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
|
wenzelm@44112
|
897 |
\<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
|
wenzelm@44112
|
898 |
|
wenzelm@44112
|
899 |
\medskip \textbf{Selectors} and \textbf{updates} are available for
|
wenzelm@44112
|
900 |
any field (including ``@{text more}''):
|
wenzelm@44112
|
901 |
|
wenzelm@44112
|
902 |
\begin{matharray}{lll}
|
wenzelm@44112
|
903 |
@{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
|
wenzelm@44112
|
904 |
@{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
|
wenzelm@44112
|
905 |
\end{matharray}
|
wenzelm@44112
|
906 |
|
wenzelm@44112
|
907 |
There is special syntax for application of updates: @{text "r\<lparr>x :=
|
wenzelm@44112
|
908 |
a\<rparr>"} abbreviates term @{text "x_update a r"}. Further notation for
|
wenzelm@44112
|
909 |
repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
|
wenzelm@44112
|
910 |
c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}. Note that
|
wenzelm@44112
|
911 |
because of postfix notation the order of fields shown here is
|
wenzelm@44112
|
912 |
reverse than in the actual term. Since repeated updates are just
|
wenzelm@44112
|
913 |
function applications, fields may be freely permuted in @{text "\<lparr>x
|
wenzelm@44112
|
914 |
:= a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
|
wenzelm@44112
|
915 |
Thus commutativity of independent updates can be proven within the
|
wenzelm@44112
|
916 |
logic for any two fields, but not as a general theorem.
|
wenzelm@44112
|
917 |
|
wenzelm@44112
|
918 |
\medskip The \textbf{make} operation provides a cumulative record
|
wenzelm@44112
|
919 |
constructor function:
|
wenzelm@44112
|
920 |
|
wenzelm@44112
|
921 |
\begin{matharray}{lll}
|
wenzelm@44112
|
922 |
@{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@44112
|
923 |
\end{matharray}
|
wenzelm@44112
|
924 |
|
wenzelm@44112
|
925 |
\medskip We now reconsider the case of non-root records, which are
|
wenzelm@44112
|
926 |
derived of some parent. In general, the latter may depend on
|
wenzelm@44112
|
927 |
another parent as well, resulting in a list of \emph{ancestor
|
wenzelm@44112
|
928 |
records}. Appending the lists of fields of all ancestors results in
|
wenzelm@44112
|
929 |
a certain field prefix. The record package automatically takes care
|
wenzelm@44112
|
930 |
of this by lifting operations over this context of ancestor fields.
|
wenzelm@44112
|
931 |
Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
|
wenzelm@44112
|
932 |
fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
|
wenzelm@44112
|
933 |
the above record operations will get the following types:
|
wenzelm@44112
|
934 |
|
wenzelm@44112
|
935 |
\medskip
|
wenzelm@44112
|
936 |
\begin{tabular}{lll}
|
wenzelm@44112
|
937 |
@{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
|
wenzelm@44112
|
938 |
@{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow>
|
wenzelm@44112
|
939 |
\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
|
wenzelm@44112
|
940 |
\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
|
wenzelm@44112
|
941 |
@{text "t.make"} & @{text "::"} & @{text "\<rho>\<^sub>1 \<Rightarrow> \<dots> \<rho>\<^sub>k \<Rightarrow> \<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow>
|
wenzelm@44112
|
942 |
\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@44112
|
943 |
\end{tabular}
|
wenzelm@44112
|
944 |
\medskip
|
wenzelm@44112
|
945 |
|
wenzelm@44112
|
946 |
\noindent Some further operations address the extension aspect of a
|
wenzelm@44112
|
947 |
derived record scheme specifically: @{text "t.fields"} produces a
|
wenzelm@44112
|
948 |
record fragment consisting of exactly the new fields introduced here
|
wenzelm@44112
|
949 |
(the result may serve as a more part elsewhere); @{text "t.extend"}
|
wenzelm@44112
|
950 |
takes a fixed record and adds a given more part; @{text
|
wenzelm@44112
|
951 |
"t.truncate"} restricts a record scheme to a fixed record.
|
wenzelm@44112
|
952 |
|
wenzelm@44112
|
953 |
\medskip
|
wenzelm@44112
|
954 |
\begin{tabular}{lll}
|
wenzelm@44112
|
955 |
@{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@44112
|
956 |
@{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
|
wenzelm@44112
|
957 |
\<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
|
wenzelm@44112
|
958 |
@{text "t.truncate"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@44112
|
959 |
\end{tabular}
|
wenzelm@44112
|
960 |
\medskip
|
wenzelm@44112
|
961 |
|
wenzelm@44112
|
962 |
\noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
|
wenzelm@44112
|
963 |
for root records.
|
wenzelm@44112
|
964 |
*}
|
wenzelm@44112
|
965 |
|
wenzelm@44112
|
966 |
|
wenzelm@44112
|
967 |
subsection {* Derived rules and proof tools *}
|
wenzelm@44112
|
968 |
|
wenzelm@44112
|
969 |
text {*
|
wenzelm@44112
|
970 |
The record package proves several results internally, declaring
|
wenzelm@44112
|
971 |
these facts to appropriate proof tools. This enables users to
|
wenzelm@44112
|
972 |
reason about record structures quite conveniently. Assume that
|
wenzelm@44112
|
973 |
@{text t} is a record type as specified above.
|
wenzelm@44112
|
974 |
|
wenzelm@44112
|
975 |
\begin{enumerate}
|
wenzelm@44112
|
976 |
|
wenzelm@44112
|
977 |
\item Standard conversions for selectors or updates applied to
|
wenzelm@44112
|
978 |
record constructor terms are made part of the default Simplifier
|
wenzelm@44112
|
979 |
context; thus proofs by reduction of basic operations merely require
|
wenzelm@44112
|
980 |
the @{method simp} method without further arguments. These rules
|
wenzelm@44112
|
981 |
are available as @{text "t.simps"}, too.
|
wenzelm@44112
|
982 |
|
wenzelm@44112
|
983 |
\item Selectors applied to updated records are automatically reduced
|
wenzelm@44112
|
984 |
by an internal simplification procedure, which is also part of the
|
wenzelm@44112
|
985 |
standard Simplifier setup.
|
wenzelm@44112
|
986 |
|
wenzelm@44112
|
987 |
\item Inject equations of a form analogous to @{prop "(x, y) = (x',
|
wenzelm@44112
|
988 |
y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
|
wenzelm@44112
|
989 |
Reasoner as @{attribute iff} rules. These rules are available as
|
wenzelm@44112
|
990 |
@{text "t.iffs"}.
|
wenzelm@44112
|
991 |
|
wenzelm@44112
|
992 |
\item The introduction rule for record equality analogous to @{text
|
wenzelm@44112
|
993 |
"x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
|
wenzelm@44112
|
994 |
and as the basic rule context as ``@{attribute intro}@{text "?"}''.
|
wenzelm@44112
|
995 |
The rule is called @{text "t.equality"}.
|
wenzelm@44112
|
996 |
|
wenzelm@44112
|
997 |
\item Representations of arbitrary record expressions as canonical
|
wenzelm@44112
|
998 |
constructor terms are provided both in @{method cases} and @{method
|
wenzelm@44112
|
999 |
induct} format (cf.\ the generic proof methods of the same name,
|
wenzelm@44112
|
1000 |
\secref{sec:cases-induct}). Several variations are available, for
|
wenzelm@44112
|
1001 |
fixed records, record schemes, more parts etc.
|
wenzelm@44112
|
1002 |
|
wenzelm@44112
|
1003 |
The generic proof methods are sufficiently smart to pick the most
|
wenzelm@44112
|
1004 |
sensible rule according to the type of the indicated record
|
wenzelm@44112
|
1005 |
expression: users just need to apply something like ``@{text "(cases
|
wenzelm@44112
|
1006 |
r)"}'' to a certain proof problem.
|
wenzelm@44112
|
1007 |
|
wenzelm@44112
|
1008 |
\item The derived record operations @{text "t.make"}, @{text
|
wenzelm@44112
|
1009 |
"t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
|
wenzelm@44112
|
1010 |
treated automatically, but usually need to be expanded by hand,
|
wenzelm@44112
|
1011 |
using the collective fact @{text "t.defs"}.
|
wenzelm@44112
|
1012 |
|
wenzelm@44112
|
1013 |
\end{enumerate}
|
wenzelm@44112
|
1014 |
*}
|
wenzelm@44112
|
1015 |
|
wenzelm@44112
|
1016 |
|
wenzelm@44115
|
1017 |
subsubsection {* Examples *}
|
wenzelm@44115
|
1018 |
|
wenzelm@44115
|
1019 |
text {* See @{file "~~/src/HOL/ex/Records.thy"}, for example. *}
|
wenzelm@44115
|
1020 |
|
wenzelm@44115
|
1021 |
|
wenzelm@44112
|
1022 |
section {* Adhoc tuples *}
|
wenzelm@44112
|
1023 |
|
wenzelm@44112
|
1024 |
text {*
|
wenzelm@44112
|
1025 |
\begin{matharray}{rcl}
|
wenzelm@44112
|
1026 |
@{attribute_def (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
|
wenzelm@44112
|
1027 |
\end{matharray}
|
wenzelm@44112
|
1028 |
|
wenzelm@44112
|
1029 |
@{rail "
|
wenzelm@44112
|
1030 |
@@{attribute (HOL) split_format} ('(' 'complete' ')')?
|
wenzelm@44112
|
1031 |
"}
|
wenzelm@44112
|
1032 |
|
wenzelm@44112
|
1033 |
\begin{description}
|
wenzelm@44112
|
1034 |
|
wenzelm@44112
|
1035 |
\item @{attribute (HOL) split_format}\ @{text "(complete)"} causes
|
wenzelm@44112
|
1036 |
arguments in function applications to be represented canonically
|
wenzelm@44112
|
1037 |
according to their tuple type structure.
|
wenzelm@44112
|
1038 |
|
wenzelm@44112
|
1039 |
Note that this operation tends to invent funny names for new local
|
wenzelm@44112
|
1040 |
parameters introduced.
|
wenzelm@44112
|
1041 |
|
wenzelm@44112
|
1042 |
\end{description}
|
wenzelm@44112
|
1043 |
*}
|
wenzelm@44112
|
1044 |
|
wenzelm@44112
|
1045 |
|
wenzelm@35757
|
1046 |
section {* Typedef axiomatization \label{sec:hol-typedef} *}
|
wenzelm@26849
|
1047 |
|
wenzelm@44111
|
1048 |
text {* A Gordon/HOL-style type definition is a certain axiom scheme
|
wenzelm@44111
|
1049 |
that identifies a new type with a subset of an existing type. More
|
wenzelm@44111
|
1050 |
precisely, the new type is defined by exhibiting an existing type
|
wenzelm@44111
|
1051 |
@{text \<tau>}, a set @{text "A :: \<tau> set"}, and a theorem that proves
|
wenzelm@44111
|
1052 |
@{prop "\<exists>x. x \<in> A"}. Thus @{text A} is a non-empty subset of @{text
|
wenzelm@44111
|
1053 |
\<tau>}, and the new type denotes this subset. New functions are
|
wenzelm@44111
|
1054 |
postulated that establish an isomorphism between the new type and
|
wenzelm@44111
|
1055 |
the subset. In general, the type @{text \<tau>} may involve type
|
wenzelm@44111
|
1056 |
variables @{text "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} which means that the type definition
|
wenzelm@44111
|
1057 |
produces a type constructor @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t"} depending on
|
wenzelm@44111
|
1058 |
those type arguments.
|
wenzelm@44111
|
1059 |
|
wenzelm@44111
|
1060 |
The axiomatization can be considered a ``definition'' in the sense
|
wenzelm@44111
|
1061 |
of the particular set-theoretic interpretation of HOL
|
wenzelm@44111
|
1062 |
\cite{pitts93}, where the universe of types is required to be
|
wenzelm@44111
|
1063 |
downwards-closed wrt.\ arbitrary non-empty subsets. Thus genuinely
|
wenzelm@44111
|
1064 |
new types introduced by @{command "typedef"} stay within the range
|
wenzelm@44111
|
1065 |
of HOL models by construction. Note that @{command_ref
|
wenzelm@44111
|
1066 |
type_synonym} from Isabelle/Pure merely introduces syntactic
|
wenzelm@44111
|
1067 |
abbreviations, without any logical significance.
|
wenzelm@44111
|
1068 |
|
wenzelm@26849
|
1069 |
\begin{matharray}{rcl}
|
wenzelm@35757
|
1070 |
@{command_def (HOL) "typedef"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
|
wenzelm@26849
|
1071 |
\end{matharray}
|
wenzelm@26849
|
1072 |
|
wenzelm@43467
|
1073 |
@{rail "
|
wenzelm@44111
|
1074 |
@@{command (HOL) typedef} alt_name? abs_type '=' rep_set
|
wenzelm@26849
|
1075 |
;
|
wenzelm@26849
|
1076 |
|
wenzelm@44111
|
1077 |
alt_name: '(' (@{syntax name} | @'open' | @'open' @{syntax name}) ')'
|
wenzelm@26849
|
1078 |
;
|
wenzelm@44111
|
1079 |
abs_type: @{syntax typespec_sorts} @{syntax mixfix}?
|
wenzelm@26849
|
1080 |
;
|
wenzelm@44111
|
1081 |
rep_set: @{syntax term} (@'morphisms' @{syntax name} @{syntax name})?
|
wenzelm@43467
|
1082 |
"}
|
wenzelm@26849
|
1083 |
|
wenzelm@28760
|
1084 |
\begin{description}
|
wenzelm@42994
|
1085 |
|
wenzelm@35757
|
1086 |
\item @{command (HOL) "typedef"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t = A"}
|
wenzelm@44111
|
1087 |
axiomatizes a type definition in the background theory of the
|
wenzelm@44111
|
1088 |
current context, depending on a non-emptiness result of the set
|
wenzelm@44111
|
1089 |
@{text A} that needs to be proven here. The set @{text A} may
|
wenzelm@44111
|
1090 |
contain type variables @{text "\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n"} as specified on the LHS,
|
wenzelm@44111
|
1091 |
but no term variables.
|
wenzelm@35757
|
1092 |
|
wenzelm@44111
|
1093 |
Even though a local theory specification, the newly introduced type
|
wenzelm@44111
|
1094 |
constructor cannot depend on parameters or assumptions of the
|
wenzelm@44111
|
1095 |
context: this is structurally impossible in HOL. In contrast, the
|
wenzelm@44111
|
1096 |
non-emptiness proof may use local assumptions in unusual situations,
|
wenzelm@44111
|
1097 |
which could result in different interpretations in target contexts:
|
wenzelm@44111
|
1098 |
the meaning of the bijection between the representing set @{text A}
|
wenzelm@44111
|
1099 |
and the new type @{text t} may then change in different application
|
wenzelm@44111
|
1100 |
contexts.
|
wenzelm@42994
|
1101 |
|
wenzelm@44111
|
1102 |
By default, @{command (HOL) "typedef"} defines both a type
|
wenzelm@44111
|
1103 |
constructor @{text t} for the new type, and a term constant @{text
|
wenzelm@44111
|
1104 |
t} for the representing set within the old type. Use the ``@{text
|
wenzelm@44111
|
1105 |
"(open)"}'' option to suppress a separate constant definition
|
wenzelm@35757
|
1106 |
altogether. The injection from type to set is called @{text Rep_t},
|
wenzelm@44111
|
1107 |
its inverse @{text Abs_t}, unless explicit @{keyword (HOL)
|
wenzelm@44111
|
1108 |
"morphisms"} specification provides alternative names.
|
wenzelm@42994
|
1109 |
|
wenzelm@44111
|
1110 |
The core axiomatization uses the locale predicate @{const
|
wenzelm@44111
|
1111 |
type_definition} as defined in Isabelle/HOL. Various basic
|
wenzelm@44111
|
1112 |
consequences of that are instantiated accordingly, re-using the
|
wenzelm@44111
|
1113 |
locale facts with names derived from the new type constructor. Thus
|
wenzelm@44111
|
1114 |
the generic @{thm type_definition.Rep} is turned into the specific
|
wenzelm@44111
|
1115 |
@{text "Rep_t"}, for example.
|
wenzelm@44111
|
1116 |
|
wenzelm@44111
|
1117 |
Theorems @{thm type_definition.Rep}, @{thm
|
wenzelm@44111
|
1118 |
type_definition.Rep_inverse}, and @{thm type_definition.Abs_inverse}
|
wenzelm@44111
|
1119 |
provide the most basic characterization as a corresponding
|
wenzelm@44111
|
1120 |
injection/surjection pair (in both directions). The derived rules
|
wenzelm@44111
|
1121 |
@{thm type_definition.Rep_inject} and @{thm
|
wenzelm@44111
|
1122 |
type_definition.Abs_inject} provide a more convenient version of
|
wenzelm@44111
|
1123 |
injectivity, suitable for automated proof tools (e.g.\ in
|
wenzelm@44111
|
1124 |
declarations involving @{attribute simp} or @{attribute iff}).
|
wenzelm@44111
|
1125 |
Furthermore, the rules @{thm type_definition.Rep_cases}~/ @{thm
|
wenzelm@44111
|
1126 |
type_definition.Rep_induct}, and @{thm type_definition.Abs_cases}~/
|
wenzelm@44111
|
1127 |
@{thm type_definition.Abs_induct} provide alternative views on
|
wenzelm@44111
|
1128 |
surjectivity. These rules are already declared as set or type rules
|
wenzelm@44111
|
1129 |
for the generic @{method cases} and @{method induct} methods,
|
wenzelm@44111
|
1130 |
respectively.
|
wenzelm@42994
|
1131 |
|
wenzelm@35757
|
1132 |
An alternative name for the set definition (and other derived
|
wenzelm@35757
|
1133 |
entities) may be specified in parentheses; the default is to use
|
wenzelm@44111
|
1134 |
@{text t} directly.
|
wenzelm@26849
|
1135 |
|
wenzelm@28760
|
1136 |
\end{description}
|
wenzelm@44111
|
1137 |
|
wenzelm@44111
|
1138 |
\begin{warn}
|
wenzelm@44111
|
1139 |
If you introduce a new type axiomatically, i.e.\ via @{command_ref
|
wenzelm@44111
|
1140 |
typedecl} and @{command_ref axiomatization}, the minimum requirement
|
wenzelm@44111
|
1141 |
is that it has a non-empty model, to avoid immediate collapse of the
|
wenzelm@44111
|
1142 |
HOL logic. Moreover, one needs to demonstrate that the
|
wenzelm@44111
|
1143 |
interpretation of such free-form axiomatizations can coexist with
|
wenzelm@44111
|
1144 |
that of the regular @{command_def typedef} scheme, and any extension
|
wenzelm@44111
|
1145 |
that other people might have introduced elsewhere (e.g.\ in HOLCF
|
wenzelm@44111
|
1146 |
\cite{MuellerNvOS99}).
|
wenzelm@44111
|
1147 |
\end{warn}
|
wenzelm@26849
|
1148 |
*}
|
wenzelm@26849
|
1149 |
|
wenzelm@44111
|
1150 |
subsubsection {* Examples *}
|
wenzelm@44111
|
1151 |
|
wenzelm@44111
|
1152 |
text {* Type definitions permit the introduction of abstract data
|
wenzelm@44111
|
1153 |
types in a safe way, namely by providing models based on already
|
wenzelm@44111
|
1154 |
existing types. Given some abstract axiomatic description @{text P}
|
wenzelm@44111
|
1155 |
of a type, this involves two steps:
|
wenzelm@44111
|
1156 |
|
wenzelm@44111
|
1157 |
\begin{enumerate}
|
wenzelm@44111
|
1158 |
|
wenzelm@44111
|
1159 |
\item Find an appropriate type @{text \<tau>} and subset @{text A} which
|
wenzelm@44111
|
1160 |
has the desired properties @{text P}, and make a type definition
|
wenzelm@44111
|
1161 |
based on this representation.
|
wenzelm@44111
|
1162 |
|
wenzelm@44111
|
1163 |
\item Prove that @{text P} holds for @{text \<tau>} by lifting @{text P}
|
wenzelm@44111
|
1164 |
from the representation.
|
wenzelm@44111
|
1165 |
|
wenzelm@44111
|
1166 |
\end{enumerate}
|
wenzelm@44111
|
1167 |
|
wenzelm@44111
|
1168 |
You can later forget about the representation and work solely in
|
wenzelm@44111
|
1169 |
terms of the abstract properties @{text P}.
|
wenzelm@44111
|
1170 |
|
wenzelm@44111
|
1171 |
\medskip The following trivial example pulls a three-element type
|
wenzelm@44111
|
1172 |
into existence within the formal logical environment of HOL. *}
|
wenzelm@44111
|
1173 |
|
wenzelm@44111
|
1174 |
typedef three = "{(True, True), (True, False), (False, True)}"
|
wenzelm@44111
|
1175 |
by blast
|
wenzelm@44111
|
1176 |
|
wenzelm@44111
|
1177 |
definition "One = Abs_three (True, True)"
|
wenzelm@44111
|
1178 |
definition "Two = Abs_three (True, False)"
|
wenzelm@44111
|
1179 |
definition "Three = Abs_three (False, True)"
|
wenzelm@44111
|
1180 |
|
wenzelm@44111
|
1181 |
lemma three_distinct: "One \<noteq> Two" "One \<noteq> Three" "Two \<noteq> Three"
|
wenzelm@44111
|
1182 |
by (simp_all add: One_def Two_def Three_def Abs_three_inject three_def)
|
wenzelm@44111
|
1183 |
|
wenzelm@44111
|
1184 |
lemma three_cases:
|
wenzelm@44111
|
1185 |
fixes x :: three obtains "x = One" | "x = Two" | "x = Three"
|
wenzelm@44111
|
1186 |
by (cases x) (auto simp: One_def Two_def Three_def Abs_three_inject three_def)
|
wenzelm@44111
|
1187 |
|
wenzelm@44111
|
1188 |
text {* Note that such trivial constructions are better done with
|
wenzelm@44111
|
1189 |
derived specification mechanisms such as @{command datatype}: *}
|
wenzelm@44111
|
1190 |
|
wenzelm@44111
|
1191 |
datatype three' = One' | Two' | Three'
|
wenzelm@44111
|
1192 |
|
wenzelm@44111
|
1193 |
text {* This avoids re-doing basic definitions and proofs from the
|
wenzelm@44111
|
1194 |
primitive @{command typedef} above. *}
|
wenzelm@44111
|
1195 |
|
wenzelm@26849
|
1196 |
|
haftmann@41644
|
1197 |
section {* Functorial structure of types *}
|
haftmann@41644
|
1198 |
|
haftmann@41644
|
1199 |
text {*
|
haftmann@41644
|
1200 |
\begin{matharray}{rcl}
|
haftmann@41752
|
1201 |
@{command_def (HOL) "enriched_type"} & : & @{text "local_theory \<rightarrow> proof(prove)"}
|
haftmann@41644
|
1202 |
\end{matharray}
|
haftmann@41644
|
1203 |
|
wenzelm@43467
|
1204 |
@{rail "
|
wenzelm@43488
|
1205 |
@@{command (HOL) enriched_type} (@{syntax name} ':')? @{syntax term}
|
haftmann@41644
|
1206 |
;
|
wenzelm@43488
|
1207 |
"}
|
haftmann@41644
|
1208 |
|
haftmann@41644
|
1209 |
\begin{description}
|
haftmann@41644
|
1210 |
|
wenzelm@43488
|
1211 |
\item @{command (HOL) "enriched_type"}~@{text "prefix: m"} allows to
|
wenzelm@43488
|
1212 |
prove and register properties about the functorial structure of type
|
wenzelm@43488
|
1213 |
constructors. These properties then can be used by other packages
|
wenzelm@43488
|
1214 |
to deal with those type constructors in certain type constructions.
|
wenzelm@43488
|
1215 |
Characteristic theorems are noted in the current local theory. By
|
wenzelm@43488
|
1216 |
default, they are prefixed with the base name of the type
|
wenzelm@43488
|
1217 |
constructor, an explicit prefix can be given alternatively.
|
haftmann@41644
|
1218 |
|
haftmann@41644
|
1219 |
The given term @{text "m"} is considered as \emph{mapper} for the
|
haftmann@41644
|
1220 |
corresponding type constructor and must conform to the following
|
haftmann@41644
|
1221 |
type pattern:
|
haftmann@41644
|
1222 |
|
haftmann@41644
|
1223 |
\begin{matharray}{lll}
|
haftmann@41644
|
1224 |
@{text "m"} & @{text "::"} &
|
haftmann@41644
|
1225 |
@{text "\<sigma>\<^isub>1 \<Rightarrow> \<dots> \<sigma>\<^isub>k \<Rightarrow> (\<^vec>\<alpha>\<^isub>n) t \<Rightarrow> (\<^vec>\<beta>\<^isub>n) t"} \\
|
haftmann@41644
|
1226 |
\end{matharray}
|
haftmann@41644
|
1227 |
|
haftmann@41644
|
1228 |
\noindent where @{text t} is the type constructor, @{text
|
haftmann@41644
|
1229 |
"\<^vec>\<alpha>\<^isub>n"} and @{text "\<^vec>\<beta>\<^isub>n"} are distinct
|
haftmann@41644
|
1230 |
type variables free in the local theory and @{text "\<sigma>\<^isub>1"},
|
haftmann@41644
|
1231 |
\ldots, @{text "\<sigma>\<^isub>k"} is a subsequence of @{text "\<alpha>\<^isub>1 \<Rightarrow>
|
haftmann@41644
|
1232 |
\<beta>\<^isub>1"}, @{text "\<beta>\<^isub>1 \<Rightarrow> \<alpha>\<^isub>1"}, \ldots,
|
haftmann@41644
|
1233 |
@{text "\<alpha>\<^isub>n \<Rightarrow> \<beta>\<^isub>n"}, @{text "\<beta>\<^isub>n \<Rightarrow>
|
haftmann@41644
|
1234 |
\<alpha>\<^isub>n"}.
|
haftmann@41644
|
1235 |
|
haftmann@41644
|
1236 |
\end{description}
|
haftmann@41644
|
1237 |
*}
|
haftmann@41644
|
1238 |
|
bulwahn@44864
|
1239 |
section {* Quotient types *}
|
bulwahn@44864
|
1240 |
|
bulwahn@44864
|
1241 |
text {*
|
bulwahn@44864
|
1242 |
The quotient package defines a new quotient type given a raw type
|
bulwahn@44864
|
1243 |
and a partial equivalence relation.
|
bulwahn@44864
|
1244 |
It also includes automation for transporting definitions and theorems.
|
bulwahn@44864
|
1245 |
It can automatically produce definitions and theorems on the quotient type,
|
bulwahn@44864
|
1246 |
given the corresponding constants and facts on the raw type.
|
bulwahn@44864
|
1247 |
|
bulwahn@44864
|
1248 |
\begin{matharray}{rcl}
|
bulwahn@44864
|
1249 |
@{command_def (HOL) "quotient_type"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
|
bulwahn@44864
|
1250 |
@{command_def (HOL) "quotient_definition"} & : & @{text "local_theory \<rightarrow> proof(prove)"}\\
|
bulwahn@44864
|
1251 |
@{command_def (HOL) "print_quotmaps"} & : & @{text "context \<rightarrow>"}\\
|
bulwahn@44864
|
1252 |
@{command_def (HOL) "print_quotients"} & : & @{text "context \<rightarrow>"}\\
|
bulwahn@44864
|
1253 |
@{command_def (HOL) "print_quotconsts"} & : & @{text "context \<rightarrow>"}\\
|
bulwahn@44864
|
1254 |
\end{matharray}
|
bulwahn@44864
|
1255 |
|
bulwahn@44864
|
1256 |
@{rail "
|
bulwahn@44864
|
1257 |
@@{command (HOL) quotient_type} (spec + @'and');
|
bulwahn@44864
|
1258 |
|
bulwahn@44864
|
1259 |
spec: @{syntax typespec} @{syntax mixfix}? '=' \\
|
bulwahn@44864
|
1260 |
@{syntax type} '/' ('partial' ':')? @{syntax term};
|
bulwahn@44864
|
1261 |
"}
|
bulwahn@44864
|
1262 |
|
bulwahn@44864
|
1263 |
@{rail "
|
bulwahn@44864
|
1264 |
@@{command (HOL) quotient_definition} constdecl? @{syntax thmdecl}? \\
|
bulwahn@44864
|
1265 |
@{syntax term} 'is' @{syntax term};
|
bulwahn@44864
|
1266 |
|
bulwahn@44864
|
1267 |
constdecl: @{syntax name} ('::' @{syntax type})? @{syntax mixfix}?
|
bulwahn@44864
|
1268 |
"}
|
bulwahn@44864
|
1269 |
|
bulwahn@44864
|
1270 |
\begin{description}
|
bulwahn@44864
|
1271 |
|
bulwahn@44864
|
1272 |
\item @{command (HOL) "quotient_type"} defines quotient types.
|
bulwahn@44864
|
1273 |
|
bulwahn@44864
|
1274 |
\item @{command (HOL) "quotient_definition"} defines a constant on the quotient type.
|
bulwahn@44864
|
1275 |
|
bulwahn@44864
|
1276 |
\item @{command (HOL) "print_quotmaps"} prints quotient map functions.
|
bulwahn@44864
|
1277 |
|
bulwahn@44864
|
1278 |
\item @{command (HOL) "print_quotients"} prints quotients.
|
bulwahn@44864
|
1279 |
|
bulwahn@44864
|
1280 |
\item @{command (HOL) "print_quotconsts"} prints quotient constants.
|
bulwahn@44864
|
1281 |
|
bulwahn@44864
|
1282 |
\end{description}
|
bulwahn@44864
|
1283 |
|
bulwahn@44864
|
1284 |
*}
|
haftmann@41644
|
1285 |
|
wenzelm@26849
|
1286 |
section {* Arithmetic proof support *}
|
wenzelm@26849
|
1287 |
|
wenzelm@26849
|
1288 |
text {*
|
wenzelm@26849
|
1289 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
1290 |
@{method_def (HOL) arith} & : & @{text method} \\
|
nipkow@30863
|
1291 |
@{attribute_def (HOL) arith} & : & @{text attribute} \\
|
wenzelm@28761
|
1292 |
@{attribute_def (HOL) arith_split} & : & @{text attribute} \\
|
wenzelm@26849
|
1293 |
\end{matharray}
|
wenzelm@26849
|
1294 |
|
wenzelm@26849
|
1295 |
The @{method (HOL) arith} method decides linear arithmetic problems
|
wenzelm@26849
|
1296 |
(on types @{text nat}, @{text int}, @{text real}). Any current
|
wenzelm@26849
|
1297 |
facts are inserted into the goal before running the procedure.
|
wenzelm@26849
|
1298 |
|
nipkow@30863
|
1299 |
The @{attribute (HOL) arith} attribute declares facts that are
|
nipkow@30863
|
1300 |
always supplied to the arithmetic provers implicitly.
|
nipkow@30863
|
1301 |
|
wenzelm@26894
|
1302 |
The @{attribute (HOL) arith_split} attribute declares case split
|
wenzelm@30865
|
1303 |
rules to be expanded before @{method (HOL) arith} is invoked.
|
wenzelm@26849
|
1304 |
|
nipkow@30863
|
1305 |
Note that a simpler (but faster) arithmetic prover is
|
nipkow@30863
|
1306 |
already invoked by the Simplifier.
|
wenzelm@26849
|
1307 |
*}
|
wenzelm@26849
|
1308 |
|
wenzelm@26849
|
1309 |
|
wenzelm@30169
|
1310 |
section {* Intuitionistic proof search *}
|
wenzelm@30169
|
1311 |
|
wenzelm@30169
|
1312 |
text {*
|
wenzelm@30169
|
1313 |
\begin{matharray}{rcl}
|
wenzelm@30171
|
1314 |
@{method_def (HOL) iprover} & : & @{text method} \\
|
wenzelm@30169
|
1315 |
\end{matharray}
|
wenzelm@30169
|
1316 |
|
wenzelm@43467
|
1317 |
@{rail "
|
wenzelm@43467
|
1318 |
@@{method (HOL) iprover} ( @{syntax rulemod} * )
|
wenzelm@43467
|
1319 |
"}
|
wenzelm@30169
|
1320 |
|
wenzelm@30171
|
1321 |
The @{method (HOL) iprover} method performs intuitionistic proof
|
wenzelm@30171
|
1322 |
search, depending on specifically declared rules from the context,
|
wenzelm@30171
|
1323 |
or given as explicit arguments. Chained facts are inserted into the
|
wenzelm@35613
|
1324 |
goal before commencing proof search.
|
wenzelm@35613
|
1325 |
|
wenzelm@30169
|
1326 |
Rules need to be classified as @{attribute (Pure) intro},
|
wenzelm@30169
|
1327 |
@{attribute (Pure) elim}, or @{attribute (Pure) dest}; here the
|
wenzelm@30169
|
1328 |
``@{text "!"}'' indicator refers to ``safe'' rules, which may be
|
wenzelm@30169
|
1329 |
applied aggressively (without considering back-tracking later).
|
wenzelm@30169
|
1330 |
Rules declared with ``@{text "?"}'' are ignored in proof search (the
|
wenzelm@43497
|
1331 |
single-step @{method (Pure) rule} method still observes these). An
|
wenzelm@30169
|
1332 |
explicit weight annotation may be given as well; otherwise the
|
wenzelm@30169
|
1333 |
number of rule premises will be taken into account here.
|
wenzelm@30169
|
1334 |
*}
|
wenzelm@30169
|
1335 |
|
blanchet@44440
|
1336 |
section {* Model Elimination and Resolution *}
|
blanchet@44440
|
1337 |
|
blanchet@44440
|
1338 |
text {*
|
blanchet@44440
|
1339 |
\begin{matharray}{rcl}
|
blanchet@44440
|
1340 |
@{method_def (HOL) "meson"} & : & @{text method} \\
|
blanchet@44440
|
1341 |
@{method_def (HOL) "metis"} & : & @{text method} \\
|
blanchet@44440
|
1342 |
\end{matharray}
|
blanchet@44440
|
1343 |
|
blanchet@44440
|
1344 |
@{rail "
|
blanchet@44440
|
1345 |
@@{method (HOL) meson} @{syntax thmrefs}?
|
blanchet@44440
|
1346 |
;
|
blanchet@44440
|
1347 |
|
blanchet@44440
|
1348 |
@@{method (HOL) metis} ( '(' ('partial_types' | 'full_types' | 'no_types'
|
blanchet@44440
|
1349 |
| @{syntax name}) ')' )? @{syntax thmrefs}?
|
blanchet@44440
|
1350 |
"}
|
blanchet@44440
|
1351 |
|
blanchet@44440
|
1352 |
The @{method (HOL) meson} method implements Loveland's model elimination
|
blanchet@44440
|
1353 |
procedure \cite{loveland-78}. See @{file "~~/src/HOL/ex/Meson_Test.thy"} for
|
blanchet@44440
|
1354 |
examples.
|
blanchet@44440
|
1355 |
|
blanchet@44440
|
1356 |
The @{method (HOL) metis} method combines ordered resolution and ordered
|
blanchet@44440
|
1357 |
paramodulation to find first-order (or mildly higher-order) proofs. The first
|
blanchet@44440
|
1358 |
optional argument specifies a type encoding; see the Sledgehammer manual
|
blanchet@44440
|
1359 |
\cite{isabelle-sledgehammer} for details. The @{file
|
blanchet@44440
|
1360 |
"~~/src/HOL/Metis_Examples"} directory contains several small theories
|
blanchet@44440
|
1361 |
developed to a large extent using Metis.
|
blanchet@44440
|
1362 |
*}
|
wenzelm@30169
|
1363 |
|
wenzelm@30171
|
1364 |
section {* Coherent Logic *}
|
wenzelm@30171
|
1365 |
|
wenzelm@30171
|
1366 |
text {*
|
wenzelm@30171
|
1367 |
\begin{matharray}{rcl}
|
wenzelm@30171
|
1368 |
@{method_def (HOL) "coherent"} & : & @{text method} \\
|
wenzelm@30171
|
1369 |
\end{matharray}
|
wenzelm@30171
|
1370 |
|
wenzelm@43467
|
1371 |
@{rail "
|
wenzelm@43467
|
1372 |
@@{method (HOL) coherent} @{syntax thmrefs}?
|
wenzelm@43467
|
1373 |
"}
|
wenzelm@30171
|
1374 |
|
wenzelm@30171
|
1375 |
The @{method (HOL) coherent} method solves problems of
|
wenzelm@30171
|
1376 |
\emph{Coherent Logic} \cite{Bezem-Coquand:2005}, which covers
|
wenzelm@30171
|
1377 |
applications in confluence theory, lattice theory and projective
|
wenzelm@41048
|
1378 |
geometry. See @{file "~~/src/HOL/ex/Coherent.thy"} for some
|
wenzelm@30171
|
1379 |
examples.
|
wenzelm@30171
|
1380 |
*}
|
wenzelm@30171
|
1381 |
|
wenzelm@30171
|
1382 |
|
blanchet@43082
|
1383 |
section {* Proving propositions *}
|
blanchet@43082
|
1384 |
|
blanchet@43082
|
1385 |
text {*
|
blanchet@43082
|
1386 |
In addition to the standard proof methods, a number of diagnosis
|
blanchet@43082
|
1387 |
tools search for proofs and provide an Isar proof snippet on success.
|
blanchet@43082
|
1388 |
These tools are available via the following commands.
|
blanchet@43082
|
1389 |
|
blanchet@43082
|
1390 |
\begin{matharray}{rcl}
|
blanchet@43082
|
1391 |
@{command_def (HOL) "solve_direct"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43082
|
1392 |
@{command_def (HOL) "try"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43857
|
1393 |
@{command_def (HOL) "try_methods"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43082
|
1394 |
@{command_def (HOL) "sledgehammer"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43082
|
1395 |
@{command_def (HOL) "sledgehammer_params"} & : & @{text "theory \<rightarrow> theory"}
|
blanchet@43082
|
1396 |
\end{matharray}
|
blanchet@43082
|
1397 |
|
wenzelm@43467
|
1398 |
@{rail "
|
blanchet@43881
|
1399 |
@@{command (HOL) try}
|
blanchet@43881
|
1400 |
;
|
blanchet@43881
|
1401 |
|
blanchet@43857
|
1402 |
@@{command (HOL) try_methods} ( ( ( 'simp' | 'intro' | 'elim' | 'dest' ) ':' @{syntax thmrefs} ) + ) ?
|
wenzelm@43467
|
1403 |
@{syntax nat}?
|
wenzelm@43467
|
1404 |
;
|
blanchet@43881
|
1405 |
|
wenzelm@43467
|
1406 |
@@{command (HOL) sledgehammer} ( '[' args ']' )? facts? @{syntax nat}?
|
blanchet@43082
|
1407 |
;
|
blanchet@43082
|
1408 |
|
wenzelm@43467
|
1409 |
@@{command (HOL) sledgehammer_params} ( ( '[' args ']' ) ? )
|
blanchet@43082
|
1410 |
;
|
blanchet@43082
|
1411 |
|
wenzelm@43467
|
1412 |
args: ( @{syntax name} '=' value + ',' )
|
blanchet@43082
|
1413 |
;
|
blanchet@43082
|
1414 |
|
wenzelm@43467
|
1415 |
facts: '(' ( ( ( ( 'add' | 'del' ) ':' ) ? @{syntax thmrefs} ) + ) ? ')'
|
blanchet@43082
|
1416 |
;
|
blanchet@43860
|
1417 |
"} % FIXME check args "value"
|
blanchet@43082
|
1418 |
|
blanchet@43082
|
1419 |
\begin{description}
|
blanchet@43082
|
1420 |
|
blanchet@43082
|
1421 |
\item @{command (HOL) "solve_direct"} checks whether the current subgoals can
|
blanchet@43082
|
1422 |
be solved directly by an existing theorem. Duplicate lemmas can be detected
|
blanchet@43082
|
1423 |
in this way.
|
blanchet@43082
|
1424 |
|
blanchet@43857
|
1425 |
\item @{command (HOL) "try_methods"} attempts to prove a subgoal using a combination
|
blanchet@43082
|
1426 |
of standard proof methods (@{text auto}, @{text simp}, @{text blast}, etc.).
|
blanchet@43082
|
1427 |
Additional facts supplied via @{text "simp:"}, @{text "intro:"},
|
blanchet@43082
|
1428 |
@{text "elim:"}, and @{text "dest:"} are passed to the appropriate proof
|
blanchet@43082
|
1429 |
methods.
|
blanchet@43082
|
1430 |
|
bulwahn@44785
|
1431 |
\item @{command (HOL) "try"} attempts to prove or disprove a subgoal
|
bulwahn@44785
|
1432 |
using a combination of provers and disprovers (@{text "solve_direct"},
|
bulwahn@44785
|
1433 |
@{text "quickcheck"}, @{text "try_methods"}, @{text "sledgehammer"},
|
bulwahn@44785
|
1434 |
@{text "nitpick"}).
|
bulwahn@44785
|
1435 |
|
blanchet@43082
|
1436 |
\item @{command (HOL) "sledgehammer"} attempts to prove a subgoal using external
|
blanchet@43082
|
1437 |
automatic provers (resolution provers and SMT solvers). See the Sledgehammer
|
blanchet@43082
|
1438 |
manual \cite{isabelle-sledgehammer} for details.
|
blanchet@43082
|
1439 |
|
blanchet@43082
|
1440 |
\item @{command (HOL) "sledgehammer_params"} changes
|
blanchet@43082
|
1441 |
@{command (HOL) "sledgehammer"} configuration options persistently.
|
blanchet@43082
|
1442 |
|
blanchet@43082
|
1443 |
\end{description}
|
blanchet@43082
|
1444 |
*}
|
blanchet@43082
|
1445 |
|
blanchet@43082
|
1446 |
|
haftmann@31906
|
1447 |
section {* Checking and refuting propositions *}
|
haftmann@31906
|
1448 |
|
haftmann@31906
|
1449 |
text {*
|
haftmann@31906
|
1450 |
Identifying incorrect propositions usually involves evaluation of
|
blanchet@43082
|
1451 |
particular assignments and systematic counterexample search. This
|
haftmann@31906
|
1452 |
is supported by the following commands.
|
haftmann@31906
|
1453 |
|
haftmann@31906
|
1454 |
\begin{matharray}{rcl}
|
haftmann@31906
|
1455 |
@{command_def (HOL) "value"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@31906
|
1456 |
@{command_def (HOL) "quickcheck"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43082
|
1457 |
@{command_def (HOL) "refute"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43082
|
1458 |
@{command_def (HOL) "nitpick"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
blanchet@43082
|
1459 |
@{command_def (HOL) "quickcheck_params"} & : & @{text "theory \<rightarrow> theory"} \\
|
blanchet@43082
|
1460 |
@{command_def (HOL) "refute_params"} & : & @{text "theory \<rightarrow> theory"} \\
|
blanchet@43082
|
1461 |
@{command_def (HOL) "nitpick_params"} & : & @{text "theory \<rightarrow> theory"}
|
haftmann@31906
|
1462 |
\end{matharray}
|
haftmann@31906
|
1463 |
|
wenzelm@43467
|
1464 |
@{rail "
|
wenzelm@43467
|
1465 |
@@{command (HOL) value} ( '[' name ']' )? modes? @{syntax term}
|
haftmann@31906
|
1466 |
;
|
haftmann@31906
|
1467 |
|
wenzelm@43467
|
1468 |
(@@{command (HOL) quickcheck} | @@{command (HOL) refute} | @@{command (HOL) nitpick})
|
wenzelm@43467
|
1469 |
( '[' args ']' )? @{syntax nat}?
|
haftmann@31906
|
1470 |
;
|
haftmann@31906
|
1471 |
|
wenzelm@43467
|
1472 |
(@@{command (HOL) quickcheck_params} | @@{command (HOL) refute_params} |
|
wenzelm@43467
|
1473 |
@@{command (HOL) nitpick_params}) ( '[' args ']' )?
|
haftmann@31906
|
1474 |
;
|
haftmann@31906
|
1475 |
|
wenzelm@43467
|
1476 |
modes: '(' (@{syntax name} +) ')'
|
haftmann@31906
|
1477 |
;
|
haftmann@31906
|
1478 |
|
wenzelm@43467
|
1479 |
args: ( @{syntax name} '=' value + ',' )
|
haftmann@31906
|
1480 |
;
|
wenzelm@43467
|
1481 |
"} % FIXME check "value"
|
haftmann@31906
|
1482 |
|
haftmann@31906
|
1483 |
\begin{description}
|
haftmann@31906
|
1484 |
|
haftmann@31906
|
1485 |
\item @{command (HOL) "value"}~@{text t} evaluates and prints a
|
haftmann@31906
|
1486 |
term; optionally @{text modes} can be specified, which are
|
wenzelm@44130
|
1487 |
appended to the current print mode; see \secref{sec:print-modes}.
|
haftmann@31906
|
1488 |
Internally, the evaluation is performed by registered evaluators,
|
haftmann@31906
|
1489 |
which are invoked sequentially until a result is returned.
|
haftmann@31906
|
1490 |
Alternatively a specific evaluator can be selected using square
|
haftmann@37419
|
1491 |
brackets; typical evaluators use the current set of code equations
|
wenzelm@44130
|
1492 |
to normalize and include @{text simp} for fully symbolic
|
wenzelm@44130
|
1493 |
evaluation using the simplifier, @{text nbe} for
|
wenzelm@44130
|
1494 |
\emph{normalization by evaluation} and \emph{code} for code
|
wenzelm@44130
|
1495 |
generation in SML.
|
haftmann@31906
|
1496 |
|
haftmann@31906
|
1497 |
\item @{command (HOL) "quickcheck"} tests the current goal for
|
blanchet@43082
|
1498 |
counterexamples using a series of assignments for its
|
haftmann@31906
|
1499 |
free variables; by default the first subgoal is tested, an other
|
haftmann@31906
|
1500 |
can be selected explicitly using an optional goal index.
|
bulwahn@41162
|
1501 |
Assignments can be chosen exhausting the search space upto a given
|
bulwahn@44785
|
1502 |
size, or using a fixed number of random assignments in the search space,
|
bulwahn@44785
|
1503 |
or exploring the search space symbolically using narrowing.
|
bulwahn@41162
|
1504 |
By default, quickcheck uses exhaustive testing.
|
haftmann@31906
|
1505 |
A number of configuration options are supported for
|
haftmann@31906
|
1506 |
@{command (HOL) "quickcheck"}, notably:
|
haftmann@31906
|
1507 |
|
haftmann@31906
|
1508 |
\begin{description}
|
haftmann@31906
|
1509 |
|
bulwahn@44785
|
1510 |
\item[@{text tester}] specifies which testing approach to apply.
|
bulwahn@44785
|
1511 |
There are three testers, @{text exhaustive},
|
bulwahn@44785
|
1512 |
@{text random}, and @{text narrowing}.
|
bulwahn@41162
|
1513 |
An unknown configuration option is treated as an argument to tester,
|
bulwahn@41162
|
1514 |
making @{text "tester ="} optional.
|
bulwahn@44785
|
1515 |
When multiple testers are given, these are applied in parallel.
|
bulwahn@44785
|
1516 |
If no tester is specified, quickcheck uses the testers that are
|
bulwahn@44785
|
1517 |
set active, i.e., configurations
|
bulwahn@44785
|
1518 |
@{text quickcheck_exhaustive_active}, @{text quickcheck_random_active},
|
bulwahn@44785
|
1519 |
@{text quickcheck_narrowing_active} are set to true.
|
wenzelm@40515
|
1520 |
\item[@{text size}] specifies the maximum size of the search space
|
wenzelm@40515
|
1521 |
for assignment values.
|
haftmann@31906
|
1522 |
|
bulwahn@42956
|
1523 |
\item[@{text eval}] takes a term or a list of terms and evaluates
|
bulwahn@42956
|
1524 |
these terms under the variable assignment found by quickcheck.
|
wenzelm@42994
|
1525 |
|
wenzelm@40515
|
1526 |
\item[@{text iterations}] sets how many sets of assignments are
|
wenzelm@40515
|
1527 |
generated for each particular size.
|
haftmann@31906
|
1528 |
|
wenzelm@40515
|
1529 |
\item[@{text no_assms}] specifies whether assumptions in
|
wenzelm@40515
|
1530 |
structured proofs should be ignored.
|
blanchet@35331
|
1531 |
|
wenzelm@40515
|
1532 |
\item[@{text timeout}] sets the time limit in seconds.
|
bulwahn@40480
|
1533 |
|
wenzelm@40515
|
1534 |
\item[@{text default_type}] sets the type(s) generally used to
|
wenzelm@40515
|
1535 |
instantiate type variables.
|
bulwahn@40480
|
1536 |
|
wenzelm@40515
|
1537 |
\item[@{text report}] if set quickcheck reports how many tests
|
wenzelm@40515
|
1538 |
fulfilled the preconditions.
|
bulwahn@40480
|
1539 |
|
wenzelm@40515
|
1540 |
\item[@{text quiet}] if not set quickcheck informs about the
|
wenzelm@40515
|
1541 |
current size for assignment values.
|
bulwahn@40480
|
1542 |
|
wenzelm@40515
|
1543 |
\item[@{text expect}] can be used to check if the user's
|
wenzelm@40515
|
1544 |
expectation was met (@{text no_expectation}, @{text
|
wenzelm@40515
|
1545 |
no_counterexample}, or @{text counterexample}).
|
bulwahn@40480
|
1546 |
|
haftmann@31906
|
1547 |
\end{description}
|
haftmann@31906
|
1548 |
|
haftmann@31906
|
1549 |
These option can be given within square brackets.
|
haftmann@31906
|
1550 |
|
blanchet@43082
|
1551 |
\item @{command (HOL) "quickcheck_params"} changes
|
blanchet@43082
|
1552 |
@{command (HOL) "quickcheck"} configuration options persistently.
|
blanchet@43082
|
1553 |
|
blanchet@43082
|
1554 |
\item @{command (HOL) "refute"} tests the current goal for
|
blanchet@43082
|
1555 |
counterexamples using a reduction to SAT. The following configuration
|
blanchet@43082
|
1556 |
options are supported:
|
blanchet@43082
|
1557 |
|
blanchet@43082
|
1558 |
\begin{description}
|
blanchet@43082
|
1559 |
|
blanchet@43082
|
1560 |
\item[@{text minsize}] specifies the minimum size (cardinality) of the
|
blanchet@43082
|
1561 |
models to search for.
|
blanchet@43082
|
1562 |
|
blanchet@43082
|
1563 |
\item[@{text maxsize}] specifies the maximum size (cardinality) of the
|
blanchet@43082
|
1564 |
models to search for. Nonpositive values mean $\infty$.
|
blanchet@43082
|
1565 |
|
blanchet@43082
|
1566 |
\item[@{text maxvars}] specifies the maximum number of Boolean variables
|
blanchet@43082
|
1567 |
to use when transforming the term into a propositional formula.
|
blanchet@43082
|
1568 |
Nonpositive values mean $\infty$.
|
blanchet@43082
|
1569 |
|
blanchet@43082
|
1570 |
\item[@{text satsolver}] specifies the SAT solver to use.
|
blanchet@43082
|
1571 |
|
blanchet@43082
|
1572 |
\item[@{text no_assms}] specifies whether assumptions in
|
blanchet@43082
|
1573 |
structured proofs should be ignored.
|
blanchet@43082
|
1574 |
|
blanchet@43082
|
1575 |
\item[@{text maxtime}] sets the time limit in seconds.
|
blanchet@43082
|
1576 |
|
blanchet@43082
|
1577 |
\item[@{text expect}] can be used to check if the user's
|
blanchet@43082
|
1578 |
expectation was met (@{text genuine}, @{text potential},
|
blanchet@43082
|
1579 |
@{text none}, or @{text unknown}).
|
blanchet@43082
|
1580 |
|
blanchet@43082
|
1581 |
\end{description}
|
blanchet@43082
|
1582 |
|
blanchet@43082
|
1583 |
These option can be given within square brackets.
|
blanchet@43082
|
1584 |
|
blanchet@43082
|
1585 |
\item @{command (HOL) "refute_params"} changes
|
blanchet@43082
|
1586 |
@{command (HOL) "refute"} configuration options persistently.
|
blanchet@43082
|
1587 |
|
blanchet@43082
|
1588 |
\item @{command (HOL) "nitpick"} tests the current goal for counterexamples
|
blanchet@43082
|
1589 |
using a reduction to first-order relational logic. See the Nitpick manual
|
blanchet@43082
|
1590 |
\cite{isabelle-nitpick} for details.
|
blanchet@43082
|
1591 |
|
blanchet@43082
|
1592 |
\item @{command (HOL) "nitpick_params"} changes
|
blanchet@43082
|
1593 |
@{command (HOL) "nitpick"} configuration options persistently.
|
haftmann@31906
|
1594 |
|
haftmann@31906
|
1595 |
\end{description}
|
haftmann@31906
|
1596 |
*}
|
haftmann@31906
|
1597 |
|
haftmann@31906
|
1598 |
|
wenzelm@28752
|
1599 |
section {* Unstructured case analysis and induction \label{sec:hol-induct-tac} *}
|
wenzelm@26849
|
1600 |
|
wenzelm@26849
|
1601 |
text {*
|
wenzelm@27123
|
1602 |
The following tools of Isabelle/HOL support cases analysis and
|
wenzelm@27123
|
1603 |
induction in unstructured tactic scripts; see also
|
wenzelm@27123
|
1604 |
\secref{sec:cases-induct} for proper Isar versions of similar ideas.
|
wenzelm@26849
|
1605 |
|
wenzelm@26849
|
1606 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
1607 |
@{method_def (HOL) case_tac}@{text "\<^sup>*"} & : & @{text method} \\
|
wenzelm@28761
|
1608 |
@{method_def (HOL) induct_tac}@{text "\<^sup>*"} & : & @{text method} \\
|
wenzelm@28761
|
1609 |
@{method_def (HOL) ind_cases}@{text "\<^sup>*"} & : & @{text method} \\
|
wenzelm@28761
|
1610 |
@{command_def (HOL) "inductive_cases"}@{text "\<^sup>*"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@26849
|
1611 |
\end{matharray}
|
wenzelm@26849
|
1612 |
|
wenzelm@43467
|
1613 |
@{rail "
|
wenzelm@43576
|
1614 |
@@{method (HOL) case_tac} @{syntax goal_spec}? @{syntax term} rule?
|
wenzelm@26849
|
1615 |
;
|
wenzelm@43576
|
1616 |
@@{method (HOL) induct_tac} @{syntax goal_spec}? (@{syntax insts} * @'and') rule?
|
wenzelm@26849
|
1617 |
;
|
wenzelm@43467
|
1618 |
@@{method (HOL) ind_cases} (@{syntax prop}+) (@'for' (@{syntax name}+))?
|
wenzelm@26849
|
1619 |
;
|
wenzelm@43467
|
1620 |
@@{command (HOL) inductive_cases} (@{syntax thmdecl}? (@{syntax prop}+) + @'and')
|
wenzelm@26849
|
1621 |
;
|
wenzelm@26849
|
1622 |
|
wenzelm@43467
|
1623 |
rule: 'rule' ':' @{syntax thmref}
|
wenzelm@43467
|
1624 |
"}
|
wenzelm@26849
|
1625 |
|
wenzelm@28760
|
1626 |
\begin{description}
|
wenzelm@26849
|
1627 |
|
wenzelm@28760
|
1628 |
\item @{method (HOL) case_tac} and @{method (HOL) induct_tac} admit
|
wenzelm@28760
|
1629 |
to reason about inductive types. Rules are selected according to
|
wenzelm@28760
|
1630 |
the declarations by the @{attribute cases} and @{attribute induct}
|
wenzelm@28760
|
1631 |
attributes, cf.\ \secref{sec:cases-induct}. The @{command (HOL)
|
wenzelm@28760
|
1632 |
datatype} package already takes care of this.
|
wenzelm@27123
|
1633 |
|
wenzelm@27123
|
1634 |
These unstructured tactics feature both goal addressing and dynamic
|
wenzelm@26849
|
1635 |
instantiation. Note that named rule cases are \emph{not} provided
|
wenzelm@27123
|
1636 |
as would be by the proper @{method cases} and @{method induct} proof
|
wenzelm@27123
|
1637 |
methods (see \secref{sec:cases-induct}). Unlike the @{method
|
wenzelm@27123
|
1638 |
induct} method, @{method induct_tac} does not handle structured rule
|
wenzelm@27123
|
1639 |
statements, only the compact object-logic conclusion of the subgoal
|
wenzelm@27123
|
1640 |
being addressed.
|
wenzelm@42994
|
1641 |
|
wenzelm@28760
|
1642 |
\item @{method (HOL) ind_cases} and @{command (HOL)
|
wenzelm@28760
|
1643 |
"inductive_cases"} provide an interface to the internal @{ML_text
|
wenzelm@26860
|
1644 |
mk_cases} operation. Rules are simplified in an unrestricted
|
wenzelm@26860
|
1645 |
forward manner.
|
wenzelm@26849
|
1646 |
|
wenzelm@26849
|
1647 |
While @{method (HOL) ind_cases} is a proof method to apply the
|
wenzelm@26849
|
1648 |
result immediately as elimination rules, @{command (HOL)
|
wenzelm@26849
|
1649 |
"inductive_cases"} provides case split theorems at the theory level
|
wenzelm@26849
|
1650 |
for later use. The @{keyword "for"} argument of the @{method (HOL)
|
wenzelm@26849
|
1651 |
ind_cases} method allows to specify a list of variables that should
|
wenzelm@26849
|
1652 |
be generalized before applying the resulting rule.
|
wenzelm@26849
|
1653 |
|
wenzelm@28760
|
1654 |
\end{description}
|
wenzelm@26849
|
1655 |
*}
|
wenzelm@26849
|
1656 |
|
wenzelm@26849
|
1657 |
|
wenzelm@26849
|
1658 |
section {* Executable code *}
|
wenzelm@26849
|
1659 |
|
wenzelm@43498
|
1660 |
text {* For validation purposes, it is often useful to \emph{execute}
|
wenzelm@43498
|
1661 |
specifications. In principle, execution could be simulated by
|
wenzelm@43498
|
1662 |
Isabelle's inference kernel, i.e. by a combination of resolution and
|
wenzelm@43498
|
1663 |
simplification. Unfortunately, this approach is rather inefficient.
|
wenzelm@43498
|
1664 |
A more efficient way of executing specifications is to translate
|
wenzelm@43498
|
1665 |
them into a functional programming language such as ML.
|
wenzelm@26849
|
1666 |
|
wenzelm@43498
|
1667 |
Isabelle provides two generic frameworks to support code generation
|
wenzelm@43498
|
1668 |
from executable specifications. Isabelle/HOL instantiates these
|
wenzelm@43498
|
1669 |
mechanisms in a way that is amenable to end-user applications.
|
wenzelm@43498
|
1670 |
*}
|
wenzelm@43498
|
1671 |
|
wenzelm@43498
|
1672 |
|
wenzelm@43498
|
1673 |
subsection {* The new code generator (F. Haftmann) *}
|
wenzelm@43498
|
1674 |
|
wenzelm@43498
|
1675 |
text {* This framework generates code from functional programs
|
haftmann@37397
|
1676 |
(including overloading using type classes) to SML \cite{SML}, OCaml
|
haftmann@39049
|
1677 |
\cite{OCaml}, Haskell \cite{haskell-revised-report} and Scala
|
wenzelm@43498
|
1678 |
\cite{scala-overview-tech-report}. Conceptually, code generation is
|
wenzelm@43498
|
1679 |
split up in three steps: \emph{selection} of code theorems,
|
wenzelm@43498
|
1680 |
\emph{translation} into an abstract executable view and
|
wenzelm@43498
|
1681 |
\emph{serialization} to a specific \emph{target language}.
|
wenzelm@43498
|
1682 |
Inductive specifications can be executed using the predicate
|
wenzelm@43498
|
1683 |
compiler which operates within HOL. See \cite{isabelle-codegen} for
|
wenzelm@43498
|
1684 |
an introduction.
|
haftmann@37397
|
1685 |
|
haftmann@37397
|
1686 |
\begin{matharray}{rcl}
|
haftmann@37397
|
1687 |
@{command_def (HOL) "export_code"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1688 |
@{attribute_def (HOL) code} & : & @{text attribute} \\
|
haftmann@37397
|
1689 |
@{command_def (HOL) "code_abort"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1690 |
@{command_def (HOL) "code_datatype"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1691 |
@{command_def (HOL) "print_codesetup"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1692 |
@{attribute_def (HOL) code_inline} & : & @{text attribute} \\
|
haftmann@37397
|
1693 |
@{attribute_def (HOL) code_post} & : & @{text attribute} \\
|
haftmann@37397
|
1694 |
@{command_def (HOL) "print_codeproc"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1695 |
@{command_def (HOL) "code_thms"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1696 |
@{command_def (HOL) "code_deps"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1697 |
@{command_def (HOL) "code_const"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1698 |
@{command_def (HOL) "code_type"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1699 |
@{command_def (HOL) "code_class"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1700 |
@{command_def (HOL) "code_instance"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1701 |
@{command_def (HOL) "code_reserved"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1702 |
@{command_def (HOL) "code_monad"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1703 |
@{command_def (HOL) "code_include"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1704 |
@{command_def (HOL) "code_modulename"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@39832
|
1705 |
@{command_def (HOL) "code_reflect"} & : & @{text "theory \<rightarrow> theory"}
|
haftmann@37397
|
1706 |
\end{matharray}
|
haftmann@37397
|
1707 |
|
wenzelm@43467
|
1708 |
@{rail "
|
wenzelm@43467
|
1709 |
@@{command (HOL) export_code} ( constexpr + ) \\
|
wenzelm@43467
|
1710 |
( ( @'in' target ( @'module_name' @{syntax string} ) ? \\
|
wenzelm@43467
|
1711 |
( @'file' ( @{syntax string} | '-' ) ) ? ( '(' args ')' ) ?) + ) ?
|
haftmann@37397
|
1712 |
;
|
haftmann@37397
|
1713 |
|
wenzelm@43467
|
1714 |
const: @{syntax term}
|
haftmann@37397
|
1715 |
;
|
haftmann@37397
|
1716 |
|
haftmann@40959
|
1717 |
constexpr: ( const | 'name._' | '_' )
|
haftmann@37397
|
1718 |
;
|
haftmann@37397
|
1719 |
|
wenzelm@43467
|
1720 |
typeconstructor: @{syntax nameref}
|
haftmann@37397
|
1721 |
;
|
haftmann@37397
|
1722 |
|
wenzelm@43467
|
1723 |
class: @{syntax nameref}
|
haftmann@37397
|
1724 |
;
|
haftmann@37397
|
1725 |
|
haftmann@39049
|
1726 |
target: 'SML' | 'OCaml' | 'Haskell' | 'Scala'
|
haftmann@37397
|
1727 |
;
|
haftmann@37397
|
1728 |
|
wenzelm@43467
|
1729 |
@@{attribute (HOL) code} ( 'del' | 'abstype' | 'abstract' )?
|
haftmann@37397
|
1730 |
;
|
haftmann@37397
|
1731 |
|
wenzelm@43467
|
1732 |
@@{command (HOL) code_abort} ( const + )
|
haftmann@37397
|
1733 |
;
|
haftmann@37397
|
1734 |
|
wenzelm@43467
|
1735 |
@@{command (HOL) code_datatype} ( const + )
|
haftmann@37397
|
1736 |
;
|
haftmann@37397
|
1737 |
|
wenzelm@43467
|
1738 |
@@{attribute (HOL) code_inline} ( 'del' ) ?
|
haftmann@37397
|
1739 |
;
|
haftmann@37397
|
1740 |
|
wenzelm@43467
|
1741 |
@@{attribute (HOL) code_post} ( 'del' ) ?
|
haftmann@37397
|
1742 |
;
|
haftmann@37397
|
1743 |
|
wenzelm@43467
|
1744 |
@@{command (HOL) code_thms} ( constexpr + ) ?
|
haftmann@37397
|
1745 |
;
|
haftmann@37397
|
1746 |
|
wenzelm@43467
|
1747 |
@@{command (HOL) code_deps} ( constexpr + ) ?
|
haftmann@37397
|
1748 |
;
|
haftmann@37397
|
1749 |
|
wenzelm@43467
|
1750 |
@@{command (HOL) code_const} (const + @'and') \\
|
wenzelm@43467
|
1751 |
( ( '(' target ( syntax ? + @'and' ) ')' ) + )
|
haftmann@37397
|
1752 |
;
|
haftmann@37397
|
1753 |
|
wenzelm@43467
|
1754 |
@@{command (HOL) code_type} (typeconstructor + @'and') \\
|
wenzelm@43467
|
1755 |
( ( '(' target ( syntax ? + @'and' ) ')' ) + )
|
haftmann@37397
|
1756 |
;
|
haftmann@37397
|
1757 |
|
wenzelm@43467
|
1758 |
@@{command (HOL) code_class} (class + @'and') \\
|
wenzelm@43467
|
1759 |
( ( '(' target \\ ( @{syntax string} ? + @'and' ) ')' ) + )
|
haftmann@37397
|
1760 |
;
|
haftmann@37397
|
1761 |
|
wenzelm@43467
|
1762 |
@@{command (HOL) code_instance} (( typeconstructor '::' class ) + @'and') \\
|
wenzelm@43467
|
1763 |
( ( '(' target ( '-' ? + @'and' ) ')' ) + )
|
haftmann@37397
|
1764 |
;
|
haftmann@37397
|
1765 |
|
wenzelm@43467
|
1766 |
@@{command (HOL) code_reserved} target ( @{syntax string} + )
|
haftmann@37397
|
1767 |
;
|
haftmann@37397
|
1768 |
|
wenzelm@43467
|
1769 |
@@{command (HOL) code_monad} const const target
|
haftmann@37397
|
1770 |
;
|
haftmann@37397
|
1771 |
|
wenzelm@43467
|
1772 |
@@{command (HOL) code_include} target ( @{syntax string} ( @{syntax string} | '-') )
|
haftmann@37397
|
1773 |
;
|
haftmann@37397
|
1774 |
|
wenzelm@43467
|
1775 |
@@{command (HOL) code_modulename} target ( ( @{syntax string} @{syntax string} ) + )
|
haftmann@37397
|
1776 |
;
|
haftmann@37397
|
1777 |
|
wenzelm@43467
|
1778 |
@@{command (HOL) code_reflect} @{syntax string} \\
|
wenzelm@43467
|
1779 |
( @'datatypes' ( @{syntax string} '=' ( '_' | ( @{syntax string} + '|' ) + @'and' ) ) ) ? \\
|
wenzelm@43467
|
1780 |
( @'functions' ( @{syntax string} + ) ) ? ( @'file' @{syntax string} ) ?
|
haftmann@39832
|
1781 |
;
|
haftmann@39832
|
1782 |
|
wenzelm@43467
|
1783 |
syntax: @{syntax string} | ( @'infix' | @'infixl' | @'infixr' ) @{syntax nat} @{syntax string}
|
wenzelm@43467
|
1784 |
"}
|
haftmann@37397
|
1785 |
|
haftmann@37397
|
1786 |
\begin{description}
|
haftmann@37397
|
1787 |
|
haftmann@37397
|
1788 |
\item @{command (HOL) "export_code"} generates code for a given list
|
haftmann@39832
|
1789 |
of constants in the specified target language(s). If no
|
haftmann@39832
|
1790 |
serialization instruction is given, only abstract code is generated
|
haftmann@39832
|
1791 |
internally.
|
haftmann@37397
|
1792 |
|
haftmann@37397
|
1793 |
Constants may be specified by giving them literally, referring to
|
haftmann@37397
|
1794 |
all executable contants within a certain theory by giving @{text
|
haftmann@37397
|
1795 |
"name.*"}, or referring to \emph{all} executable constants currently
|
haftmann@37397
|
1796 |
available by giving @{text "*"}.
|
haftmann@37397
|
1797 |
|
haftmann@37397
|
1798 |
By default, for each involved theory one corresponding name space
|
haftmann@37397
|
1799 |
module is generated. Alternativly, a module name may be specified
|
haftmann@37397
|
1800 |
after the @{keyword "module_name"} keyword; then \emph{all} code is
|
haftmann@37397
|
1801 |
placed in this module.
|
haftmann@37397
|
1802 |
|
haftmann@39832
|
1803 |
For \emph{SML}, \emph{OCaml} and \emph{Scala} the file specification
|
haftmann@39832
|
1804 |
refers to a single file; for \emph{Haskell}, it refers to a whole
|
haftmann@39832
|
1805 |
directory, where code is generated in multiple files reflecting the
|
haftmann@39832
|
1806 |
module hierarchy. Omitting the file specification denotes standard
|
haftmann@37748
|
1807 |
output.
|
haftmann@37397
|
1808 |
|
haftmann@37397
|
1809 |
Serializers take an optional list of arguments in parentheses. For
|
haftmann@37397
|
1810 |
\emph{SML} and \emph{OCaml}, ``@{text no_signatures}`` omits
|
haftmann@37397
|
1811 |
explicit module signatures.
|
wenzelm@42994
|
1812 |
|
haftmann@39832
|
1813 |
For \emph{Haskell} a module name prefix may be given using the
|
haftmann@39832
|
1814 |
``@{text "root:"}'' argument; ``@{text string_classes}'' adds a
|
haftmann@39832
|
1815 |
``@{verbatim "deriving (Read, Show)"}'' clause to each appropriate
|
haftmann@39832
|
1816 |
datatype declaration.
|
haftmann@37397
|
1817 |
|
haftmann@37397
|
1818 |
\item @{attribute (HOL) code} explicitly selects (or with option
|
haftmann@38706
|
1819 |
``@{text "del"}'' deselects) a code equation for code generation.
|
haftmann@38706
|
1820 |
Usually packages introducing code equations provide a reasonable
|
haftmann@38706
|
1821 |
default setup for selection. Variants @{text "code abstype"} and
|
haftmann@38706
|
1822 |
@{text "code abstract"} declare abstract datatype certificates or
|
haftmann@38706
|
1823 |
code equations on abstract datatype representations respectively.
|
haftmann@37397
|
1824 |
|
haftmann@37397
|
1825 |
\item @{command (HOL) "code_abort"} declares constants which are not
|
haftmann@39832
|
1826 |
required to have a definition by means of code equations; if needed
|
haftmann@39832
|
1827 |
these are implemented by program abort instead.
|
haftmann@37397
|
1828 |
|
haftmann@37397
|
1829 |
\item @{command (HOL) "code_datatype"} specifies a constructor set
|
haftmann@37397
|
1830 |
for a logical type.
|
haftmann@37397
|
1831 |
|
haftmann@37397
|
1832 |
\item @{command (HOL) "print_codesetup"} gives an overview on
|
haftmann@37397
|
1833 |
selected code equations and code generator datatypes.
|
haftmann@37397
|
1834 |
|
haftmann@39832
|
1835 |
\item @{attribute (HOL) code_inline} declares (or with option
|
haftmann@39832
|
1836 |
``@{text "del"}'' removes) inlining theorems which are applied as
|
haftmann@39832
|
1837 |
rewrite rules to any code equation during preprocessing.
|
haftmann@37397
|
1838 |
|
haftmann@39832
|
1839 |
\item @{attribute (HOL) code_post} declares (or with option ``@{text
|
haftmann@39832
|
1840 |
"del"}'' removes) theorems which are applied as rewrite rules to any
|
haftmann@39832
|
1841 |
result of an evaluation.
|
haftmann@37397
|
1842 |
|
haftmann@39832
|
1843 |
\item @{command (HOL) "print_codeproc"} prints the setup of the code
|
haftmann@39832
|
1844 |
generator preprocessor.
|
haftmann@37397
|
1845 |
|
haftmann@37397
|
1846 |
\item @{command (HOL) "code_thms"} prints a list of theorems
|
haftmann@37397
|
1847 |
representing the corresponding program containing all given
|
haftmann@37397
|
1848 |
constants after preprocessing.
|
haftmann@37397
|
1849 |
|
haftmann@37397
|
1850 |
\item @{command (HOL) "code_deps"} visualizes dependencies of
|
haftmann@37397
|
1851 |
theorems representing the corresponding program containing all given
|
haftmann@37397
|
1852 |
constants after preprocessing.
|
haftmann@37397
|
1853 |
|
haftmann@37397
|
1854 |
\item @{command (HOL) "code_const"} associates a list of constants
|
haftmann@37397
|
1855 |
with target-specific serializations; omitting a serialization
|
haftmann@37397
|
1856 |
deletes an existing serialization.
|
haftmann@37397
|
1857 |
|
haftmann@37397
|
1858 |
\item @{command (HOL) "code_type"} associates a list of type
|
haftmann@37397
|
1859 |
constructors with target-specific serializations; omitting a
|
haftmann@37397
|
1860 |
serialization deletes an existing serialization.
|
haftmann@37397
|
1861 |
|
haftmann@37397
|
1862 |
\item @{command (HOL) "code_class"} associates a list of classes
|
haftmann@37397
|
1863 |
with target-specific class names; omitting a serialization deletes
|
haftmann@37397
|
1864 |
an existing serialization. This applies only to \emph{Haskell}.
|
haftmann@37397
|
1865 |
|
haftmann@37397
|
1866 |
\item @{command (HOL) "code_instance"} declares a list of type
|
haftmann@37397
|
1867 |
constructor / class instance relations as ``already present'' for a
|
haftmann@37397
|
1868 |
given target. Omitting a ``@{text "-"}'' deletes an existing
|
haftmann@37397
|
1869 |
``already present'' declaration. This applies only to
|
haftmann@37397
|
1870 |
\emph{Haskell}.
|
haftmann@37397
|
1871 |
|
haftmann@37397
|
1872 |
\item @{command (HOL) "code_reserved"} declares a list of names as
|
haftmann@37397
|
1873 |
reserved for a given target, preventing it to be shadowed by any
|
haftmann@37397
|
1874 |
generated code.
|
haftmann@37397
|
1875 |
|
haftmann@37397
|
1876 |
\item @{command (HOL) "code_monad"} provides an auxiliary mechanism
|
haftmann@37397
|
1877 |
to generate monadic code for Haskell.
|
haftmann@37397
|
1878 |
|
haftmann@37397
|
1879 |
\item @{command (HOL) "code_include"} adds arbitrary named content
|
haftmann@37397
|
1880 |
(``include'') to generated code. A ``@{text "-"}'' as last argument
|
haftmann@37397
|
1881 |
will remove an already added ``include''.
|
haftmann@37397
|
1882 |
|
haftmann@37397
|
1883 |
\item @{command (HOL) "code_modulename"} declares aliasings from one
|
haftmann@37397
|
1884 |
module name onto another.
|
haftmann@37397
|
1885 |
|
haftmann@39832
|
1886 |
\item @{command (HOL) "code_reflect"} without a ``@{text "file"}''
|
haftmann@39832
|
1887 |
argument compiles code into the system runtime environment and
|
haftmann@39832
|
1888 |
modifies the code generator setup that future invocations of system
|
haftmann@39832
|
1889 |
runtime code generation referring to one of the ``@{text
|
haftmann@39832
|
1890 |
"datatypes"}'' or ``@{text "functions"}'' entities use these precompiled
|
haftmann@39832
|
1891 |
entities. With a ``@{text "file"}'' argument, the corresponding code
|
haftmann@39832
|
1892 |
is generated into that specified file without modifying the code
|
haftmann@39832
|
1893 |
generator setup.
|
haftmann@39832
|
1894 |
|
haftmann@37397
|
1895 |
\end{description}
|
wenzelm@43498
|
1896 |
*}
|
haftmann@37397
|
1897 |
|
wenzelm@43498
|
1898 |
|
wenzelm@43498
|
1899 |
subsection {* The old code generator (S. Berghofer) *}
|
wenzelm@43498
|
1900 |
|
wenzelm@43498
|
1901 |
text {* This framework generates code from both functional and
|
wenzelm@43498
|
1902 |
relational programs to SML, as explained below.
|
wenzelm@26849
|
1903 |
|
wenzelm@26849
|
1904 |
\begin{matharray}{rcl}
|
wenzelm@43498
|
1905 |
@{command_def "code_module"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@43498
|
1906 |
@{command_def "code_library"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@43498
|
1907 |
@{command_def "consts_code"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@43498
|
1908 |
@{command_def "types_code"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@43497
|
1909 |
@{attribute_def code} & : & @{text attribute} \\
|
wenzelm@26849
|
1910 |
\end{matharray}
|
wenzelm@26849
|
1911 |
|
wenzelm@43467
|
1912 |
@{rail "
|
wenzelm@43498
|
1913 |
( @@{command code_module} | @@{command code_library} ) modespec? @{syntax name}? \\
|
wenzelm@43467
|
1914 |
( @'file' name ) ? ( @'imports' ( @{syntax name} + ) ) ? \\
|
wenzelm@43467
|
1915 |
@'contains' ( ( @{syntax name} '=' @{syntax term} ) + | @{syntax term} + )
|
wenzelm@26849
|
1916 |
;
|
wenzelm@26849
|
1917 |
|
wenzelm@43467
|
1918 |
modespec: '(' ( @{syntax name} * ) ')'
|
wenzelm@26849
|
1919 |
;
|
wenzelm@26849
|
1920 |
|
wenzelm@43467
|
1921 |
@@{command (HOL) consts_code} (codespec +)
|
wenzelm@26849
|
1922 |
;
|
wenzelm@26849
|
1923 |
|
wenzelm@26849
|
1924 |
codespec: const template attachment ?
|
wenzelm@26849
|
1925 |
;
|
wenzelm@26849
|
1926 |
|
wenzelm@43467
|
1927 |
@@{command (HOL) types_code} (tycodespec +)
|
wenzelm@26849
|
1928 |
;
|
wenzelm@26849
|
1929 |
|
wenzelm@43467
|
1930 |
tycodespec: @{syntax name} template attachment ?
|
wenzelm@26849
|
1931 |
;
|
wenzelm@26849
|
1932 |
|
wenzelm@43467
|
1933 |
const: @{syntax term}
|
wenzelm@26849
|
1934 |
;
|
wenzelm@26849
|
1935 |
|
wenzelm@43467
|
1936 |
template: '(' @{syntax string} ')'
|
wenzelm@26849
|
1937 |
;
|
wenzelm@26849
|
1938 |
|
wenzelm@43467
|
1939 |
attachment: 'attach' modespec? '{' @{syntax text} '}'
|
wenzelm@26849
|
1940 |
;
|
wenzelm@26849
|
1941 |
|
wenzelm@43497
|
1942 |
@@{attribute code} name?
|
wenzelm@43467
|
1943 |
"}
|
wenzelm@26849
|
1944 |
*}
|
wenzelm@26849
|
1945 |
|
wenzelm@27045
|
1946 |
|
wenzelm@43498
|
1947 |
subsubsection {* Invoking the code generator *}
|
wenzelm@43498
|
1948 |
|
wenzelm@43498
|
1949 |
text {* The code generator is invoked via the @{command code_module}
|
wenzelm@43498
|
1950 |
and @{command code_library} commands, which correspond to
|
wenzelm@43498
|
1951 |
\emph{incremental} and \emph{modular} code generation, respectively.
|
wenzelm@43498
|
1952 |
|
wenzelm@43498
|
1953 |
\begin{description}
|
wenzelm@43498
|
1954 |
|
wenzelm@43498
|
1955 |
\item [Modular] For each theory, an ML structure is generated,
|
wenzelm@43498
|
1956 |
containing the code generated from the constants defined in this
|
wenzelm@43498
|
1957 |
theory.
|
wenzelm@43498
|
1958 |
|
wenzelm@43498
|
1959 |
\item [Incremental] All the generated code is emitted into the same
|
wenzelm@43498
|
1960 |
structure. This structure may import code from previously generated
|
wenzelm@43498
|
1961 |
structures, which can be specified via @{keyword "imports"}.
|
wenzelm@43498
|
1962 |
Moreover, the generated structure may also be referred to in later
|
wenzelm@43498
|
1963 |
invocations of the code generator.
|
wenzelm@43498
|
1964 |
|
wenzelm@43498
|
1965 |
\end{description}
|
wenzelm@43498
|
1966 |
|
wenzelm@43498
|
1967 |
After the @{command code_module} and @{command code_library}
|
wenzelm@43498
|
1968 |
keywords, the user may specify an optional list of ``modes'' in
|
wenzelm@43498
|
1969 |
parentheses. These can be used to instruct the code generator to
|
wenzelm@43498
|
1970 |
emit additional code for special purposes, e.g.\ functions for
|
wenzelm@43498
|
1971 |
converting elements of generated datatypes to Isabelle terms, or
|
wenzelm@43498
|
1972 |
test data generators. The list of modes is followed by a module
|
wenzelm@43498
|
1973 |
name. The module name is optional for modular code generation, but
|
wenzelm@43498
|
1974 |
must be specified for incremental code generation.
|
wenzelm@43498
|
1975 |
|
wenzelm@43498
|
1976 |
The code can either be written to a file, in which case a file name
|
wenzelm@43498
|
1977 |
has to be specified after the @{keyword "file"} keyword, or be loaded
|
wenzelm@43498
|
1978 |
directly into Isabelle's ML environment. In the latter case, the
|
wenzelm@43498
|
1979 |
@{command ML} theory command can be used to inspect the results
|
wenzelm@43498
|
1980 |
interactively, for example.
|
wenzelm@43498
|
1981 |
|
wenzelm@43498
|
1982 |
The terms from which to generate code can be specified after the
|
wenzelm@43498
|
1983 |
@{keyword "contains"} keyword, either as a list of bindings, or just
|
wenzelm@43498
|
1984 |
as a list of terms. In the latter case, the code generator just
|
wenzelm@43498
|
1985 |
produces code for all constants and types occuring in the term, but
|
wenzelm@43498
|
1986 |
does not bind the compiled terms to ML identifiers.
|
wenzelm@43498
|
1987 |
|
wenzelm@43498
|
1988 |
Here is an example:
|
wenzelm@43498
|
1989 |
*}
|
wenzelm@43498
|
1990 |
|
wenzelm@43498
|
1991 |
code_module Test
|
wenzelm@43523
|
1992 |
contains test = "foldl op + (0 :: int) [1, 2, 3, 4, 5]"
|
wenzelm@43498
|
1993 |
|
wenzelm@43498
|
1994 |
text {* \noindent This binds the result of compiling the given term to
|
wenzelm@43498
|
1995 |
the ML identifier @{ML Test.test}. *}
|
wenzelm@43498
|
1996 |
|
wenzelm@43498
|
1997 |
ML {* @{assert} (Test.test = 15) *}
|
wenzelm@43498
|
1998 |
|
wenzelm@43498
|
1999 |
|
wenzelm@43498
|
2000 |
subsubsection {* Configuring the code generator *}
|
wenzelm@43498
|
2001 |
|
wenzelm@43498
|
2002 |
text {* When generating code for a complex term, the code generator
|
wenzelm@43498
|
2003 |
recursively calls itself for all subterms. When it arrives at a
|
wenzelm@43498
|
2004 |
constant, the default strategy of the code generator is to look up
|
wenzelm@43498
|
2005 |
its definition and try to generate code for it. Constants which
|
wenzelm@43498
|
2006 |
have no definitions that are immediately executable, may be
|
wenzelm@43498
|
2007 |
associated with a piece of ML code manually using the @{command_ref
|
wenzelm@43498
|
2008 |
consts_code} command. It takes a list whose elements consist of a
|
wenzelm@43498
|
2009 |
constant (given in usual term syntax -- an explicit type constraint
|
wenzelm@43498
|
2010 |
accounts for overloading), and a mixfix template describing the ML
|
wenzelm@43498
|
2011 |
code. The latter is very much the same as the mixfix templates used
|
wenzelm@43498
|
2012 |
when declaring new constants. The most notable difference is that
|
wenzelm@43498
|
2013 |
terms may be included in the ML template using antiquotation
|
wenzelm@43498
|
2014 |
brackets @{verbatim "{"}@{verbatim "*"}~@{text "..."}~@{verbatim
|
wenzelm@43498
|
2015 |
"*"}@{verbatim "}"}.
|
wenzelm@43498
|
2016 |
|
wenzelm@43498
|
2017 |
A similar mechanism is available for types: @{command_ref
|
wenzelm@43498
|
2018 |
types_code} associates type constructors with specific ML code.
|
wenzelm@43498
|
2019 |
|
wenzelm@43498
|
2020 |
For example, the following declarations copied from @{file
|
wenzelm@43498
|
2021 |
"~~/src/HOL/Product_Type.thy"} describe how the product type of
|
wenzelm@43498
|
2022 |
Isabelle/HOL should be compiled to ML. *}
|
wenzelm@43498
|
2023 |
|
wenzelm@43498
|
2024 |
typedecl ('a, 'b) prod
|
wenzelm@43498
|
2025 |
consts Pair :: "'a \<Rightarrow> 'b \<Rightarrow> ('a, 'b) prod"
|
wenzelm@43498
|
2026 |
|
wenzelm@43498
|
2027 |
types_code prod ("(_ */ _)")
|
wenzelm@43498
|
2028 |
consts_code Pair ("(_,/ _)")
|
wenzelm@43498
|
2029 |
|
wenzelm@43498
|
2030 |
text {* Sometimes, the code associated with a constant or type may
|
wenzelm@43498
|
2031 |
need to refer to auxiliary functions, which have to be emitted when
|
wenzelm@43498
|
2032 |
the constant is used. Code for such auxiliary functions can be
|
wenzelm@43498
|
2033 |
declared using @{keyword "attach"}. For example, the @{const wfrec}
|
wenzelm@43498
|
2034 |
function can be implemented as follows:
|
wenzelm@43498
|
2035 |
*}
|
wenzelm@43498
|
2036 |
|
wenzelm@43498
|
2037 |
consts_code wfrec ("\<module>wfrec?") (* FIXME !? *)
|
wenzelm@43523
|
2038 |
attach {* fun wfrec f x = f (wfrec f) x *}
|
wenzelm@43498
|
2039 |
|
wenzelm@43498
|
2040 |
text {* If the code containing a call to @{const wfrec} resides in an
|
wenzelm@43498
|
2041 |
ML structure different from the one containing the function
|
wenzelm@43498
|
2042 |
definition attached to @{const wfrec}, the name of the ML structure
|
wenzelm@43498
|
2043 |
(followed by a ``@{text "."}'') is inserted in place of ``@{text
|
wenzelm@43498
|
2044 |
"\<module>"}'' in the above template. The ``@{text "?"}'' means that
|
wenzelm@43498
|
2045 |
the code generator should ignore the first argument of @{const
|
wenzelm@43498
|
2046 |
wfrec}, i.e.\ the termination relation, which is usually not
|
wenzelm@43498
|
2047 |
executable.
|
wenzelm@43498
|
2048 |
|
wenzelm@43498
|
2049 |
\medskip Another possibility of configuring the code generator is to
|
wenzelm@43498
|
2050 |
register theorems to be used for code generation. Theorems can be
|
wenzelm@43498
|
2051 |
registered via the @{attribute code} attribute. It takes an optional
|
wenzelm@43498
|
2052 |
name as an argument, which indicates the format of the
|
wenzelm@43498
|
2053 |
theorem. Currently supported formats are equations (this is the
|
wenzelm@43498
|
2054 |
default when no name is specified) and horn clauses (this is
|
wenzelm@43498
|
2055 |
indicated by the name \texttt{ind}). The left-hand sides of
|
wenzelm@43498
|
2056 |
equations may only contain constructors and distinct variables,
|
wenzelm@43498
|
2057 |
whereas horn clauses must have the same format as introduction rules
|
wenzelm@43498
|
2058 |
of inductive definitions.
|
wenzelm@43498
|
2059 |
|
wenzelm@43498
|
2060 |
The following example specifies three equations from which to
|
wenzelm@43498
|
2061 |
generate code for @{term "op <"} on natural numbers (see also
|
wenzelm@43498
|
2062 |
@{"file" "~~/src/HOL/Nat.thy"}). *}
|
wenzelm@43498
|
2063 |
|
wenzelm@43498
|
2064 |
lemma [code]: "(Suc m < Suc n) = (m < n)"
|
wenzelm@43498
|
2065 |
and [code]: "((n::nat) < 0) = False"
|
wenzelm@43498
|
2066 |
and [code]: "(0 < Suc n) = True" by simp_all
|
wenzelm@43498
|
2067 |
|
wenzelm@43498
|
2068 |
|
wenzelm@43498
|
2069 |
subsubsection {* Specific HOL code generators *}
|
wenzelm@43498
|
2070 |
|
wenzelm@43498
|
2071 |
text {* The basic code generator framework offered by Isabelle/Pure
|
wenzelm@43498
|
2072 |
has already been extended with additional code generators for
|
wenzelm@43498
|
2073 |
specific HOL constructs. These include datatypes, recursive
|
wenzelm@43498
|
2074 |
functions and inductive relations. The code generator for inductive
|
wenzelm@43498
|
2075 |
relations can handle expressions of the form @{text "(t\<^sub>1, \<dots>, t\<^sub>n) \<in>
|
wenzelm@43498
|
2076 |
r"}, where @{text "r"} is an inductively defined relation. If at
|
wenzelm@43498
|
2077 |
least one of the @{text "t\<^sub>i"} is a dummy pattern ``@{text "_"}'',
|
wenzelm@43498
|
2078 |
the above expression evaluates to a sequence of possible answers. If
|
wenzelm@43498
|
2079 |
all of the @{text "t\<^sub>i"} are proper terms, the expression evaluates
|
wenzelm@43498
|
2080 |
to a boolean value.
|
wenzelm@43498
|
2081 |
|
wenzelm@43523
|
2082 |
The following example demonstrates this for beta-reduction on lambda
|
wenzelm@43523
|
2083 |
terms (see also @{"file" "~~/src/HOL/Proofs/Lambda/Lambda.thy"}).
|
wenzelm@43523
|
2084 |
*}
|
wenzelm@43498
|
2085 |
|
wenzelm@43523
|
2086 |
datatype dB =
|
wenzelm@43523
|
2087 |
Var nat
|
wenzelm@43523
|
2088 |
| App dB dB (infixl "\<degree>" 200)
|
wenzelm@43523
|
2089 |
| Abs dB
|
wenzelm@43523
|
2090 |
|
wenzelm@43523
|
2091 |
primrec lift :: "dB \<Rightarrow> nat \<Rightarrow> dB"
|
wenzelm@43523
|
2092 |
where
|
wenzelm@43523
|
2093 |
"lift (Var i) k = (if i < k then Var i else Var (i + 1))"
|
wenzelm@43523
|
2094 |
| "lift (s \<degree> t) k = lift s k \<degree> lift t k"
|
wenzelm@43523
|
2095 |
| "lift (Abs s) k = Abs (lift s (k + 1))"
|
wenzelm@43523
|
2096 |
|
wenzelm@43523
|
2097 |
primrec subst :: "dB \<Rightarrow> dB \<Rightarrow> nat \<Rightarrow> dB" ("_[_'/_]" [300, 0, 0] 300)
|
wenzelm@43523
|
2098 |
where
|
wenzelm@43523
|
2099 |
"(Var i)[s/k] =
|
wenzelm@43523
|
2100 |
(if k < i then Var (i - 1) else if i = k then s else Var i)"
|
wenzelm@43523
|
2101 |
| "(t \<degree> u)[s/k] = t[s/k] \<degree> u[s/k]"
|
wenzelm@43523
|
2102 |
| "(Abs t)[s/k] = Abs (t[lift s 0 / k+1])"
|
wenzelm@43523
|
2103 |
|
wenzelm@43523
|
2104 |
inductive beta :: "dB \<Rightarrow> dB \<Rightarrow> bool" (infixl "\<rightarrow>\<^sub>\<beta>" 50)
|
wenzelm@43523
|
2105 |
where
|
wenzelm@43523
|
2106 |
beta: "Abs s \<degree> t \<rightarrow>\<^sub>\<beta> s[t/0]"
|
wenzelm@43523
|
2107 |
| appL: "s \<rightarrow>\<^sub>\<beta> t \<Longrightarrow> s \<degree> u \<rightarrow>\<^sub>\<beta> t \<degree> u"
|
wenzelm@43523
|
2108 |
| appR: "s \<rightarrow>\<^sub>\<beta> t \<Longrightarrow> u \<degree> s \<rightarrow>\<^sub>\<beta> u \<degree> t"
|
wenzelm@43523
|
2109 |
| abs: "s \<rightarrow>\<^sub>\<beta> t \<Longrightarrow> Abs s \<rightarrow>\<^sub>\<beta> Abs t"
|
wenzelm@43523
|
2110 |
|
wenzelm@43523
|
2111 |
code_module Test
|
wenzelm@43523
|
2112 |
contains
|
wenzelm@43523
|
2113 |
test1 = "Abs (Var 0) \<degree> Var 0 \<rightarrow>\<^sub>\<beta> Var 0"
|
wenzelm@43523
|
2114 |
test2 = "Abs (Abs (Var 0 \<degree> Var 0) \<degree> (Abs (Var 0) \<degree> Var 0)) \<rightarrow>\<^sub>\<beta> _"
|
wenzelm@43523
|
2115 |
|
wenzelm@43523
|
2116 |
text {*
|
wenzelm@43523
|
2117 |
In the above example, @{ML Test.test1} evaluates to a boolean,
|
wenzelm@43523
|
2118 |
whereas @{ML Test.test2} is a lazy sequence whose elements can be
|
wenzelm@43523
|
2119 |
inspected separately.
|
wenzelm@43523
|
2120 |
*}
|
wenzelm@43523
|
2121 |
|
wenzelm@43523
|
2122 |
ML {* @{assert} Test.test1 *}
|
wenzelm@43523
|
2123 |
ML {* val results = DSeq.list_of Test.test2 *}
|
wenzelm@43523
|
2124 |
ML {* @{assert} (length results = 2) *}
|
wenzelm@43523
|
2125 |
|
wenzelm@43523
|
2126 |
text {*
|
wenzelm@43498
|
2127 |
\medskip The theory underlying the HOL code generator is described
|
wenzelm@43498
|
2128 |
more detailed in \cite{Berghofer-Nipkow:2002}. More examples that
|
wenzelm@43498
|
2129 |
illustrate the usage of the code generator can be found e.g.\ in
|
wenzelm@43498
|
2130 |
@{"file" "~~/src/HOL/MicroJava/J/JListExample.thy"} and @{"file"
|
wenzelm@43498
|
2131 |
"~~/src/HOL/MicroJava/JVM/JVMListExample.thy"}.
|
wenzelm@43498
|
2132 |
*}
|
wenzelm@43498
|
2133 |
|
wenzelm@43498
|
2134 |
|
wenzelm@27045
|
2135 |
section {* Definition by specification \label{sec:hol-specification} *}
|
wenzelm@27045
|
2136 |
|
wenzelm@27045
|
2137 |
text {*
|
wenzelm@27045
|
2138 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
2139 |
@{command_def (HOL) "specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@28761
|
2140 |
@{command_def (HOL) "ax_specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@27045
|
2141 |
\end{matharray}
|
wenzelm@27045
|
2142 |
|
wenzelm@43467
|
2143 |
@{rail "
|
wenzelm@43467
|
2144 |
(@@{command (HOL) specification} | @@{command (HOL) ax_specification})
|
wenzelm@43467
|
2145 |
'(' (decl +) ')' \\ (@{syntax thmdecl}? @{syntax prop} +)
|
wenzelm@27045
|
2146 |
;
|
wenzelm@43467
|
2147 |
decl: ((@{syntax name} ':')? @{syntax term} '(' @'overloaded' ')'?)
|
wenzelm@43467
|
2148 |
"}
|
wenzelm@27045
|
2149 |
|
wenzelm@28760
|
2150 |
\begin{description}
|
wenzelm@27045
|
2151 |
|
wenzelm@28760
|
2152 |
\item @{command (HOL) "specification"}~@{text "decls \<phi>"} sets up a
|
wenzelm@27045
|
2153 |
goal stating the existence of terms with the properties specified to
|
wenzelm@27045
|
2154 |
hold for the constants given in @{text decls}. After finishing the
|
wenzelm@27045
|
2155 |
proof, the theory will be augmented with definitions for the given
|
wenzelm@27045
|
2156 |
constants, as well as with theorems stating the properties for these
|
wenzelm@27045
|
2157 |
constants.
|
wenzelm@27045
|
2158 |
|
wenzelm@28760
|
2159 |
\item @{command (HOL) "ax_specification"}~@{text "decls \<phi>"} sets up
|
wenzelm@28760
|
2160 |
a goal stating the existence of terms with the properties specified
|
wenzelm@28760
|
2161 |
to hold for the constants given in @{text decls}. After finishing
|
wenzelm@28760
|
2162 |
the proof, the theory will be augmented with axioms expressing the
|
wenzelm@28760
|
2163 |
properties given in the first place.
|
wenzelm@27045
|
2164 |
|
wenzelm@28760
|
2165 |
\item @{text decl} declares a constant to be defined by the
|
wenzelm@27045
|
2166 |
specification given. The definition for the constant @{text c} is
|
wenzelm@27045
|
2167 |
bound to the name @{text c_def} unless a theorem name is given in
|
wenzelm@27045
|
2168 |
the declaration. Overloaded constants should be declared as such.
|
wenzelm@27045
|
2169 |
|
wenzelm@28760
|
2170 |
\end{description}
|
wenzelm@27045
|
2171 |
|
wenzelm@27045
|
2172 |
Whether to use @{command (HOL) "specification"} or @{command (HOL)
|
wenzelm@27045
|
2173 |
"ax_specification"} is to some extent a matter of style. @{command
|
wenzelm@27045
|
2174 |
(HOL) "specification"} introduces no new axioms, and so by
|
wenzelm@27045
|
2175 |
construction cannot introduce inconsistencies, whereas @{command
|
wenzelm@27045
|
2176 |
(HOL) "ax_specification"} does introduce axioms, but only after the
|
wenzelm@27045
|
2177 |
user has explicitly proven it to be safe. A practical issue must be
|
wenzelm@27045
|
2178 |
considered, though: After introducing two constants with the same
|
wenzelm@27045
|
2179 |
properties using @{command (HOL) "specification"}, one can prove
|
wenzelm@27045
|
2180 |
that the two constants are, in fact, equal. If this might be a
|
wenzelm@27045
|
2181 |
problem, one should use @{command (HOL) "ax_specification"}.
|
wenzelm@27045
|
2182 |
*}
|
wenzelm@27045
|
2183 |
|
wenzelm@26840
|
2184 |
end
|