wenzelm@26840
|
1 |
theory HOL_Specific
|
wenzelm@26849
|
2 |
imports Main
|
wenzelm@26840
|
3 |
begin
|
wenzelm@26840
|
4 |
|
wenzelm@26852
|
5 |
chapter {* Isabelle/HOL \label{ch:hol} *}
|
wenzelm@26849
|
6 |
|
wenzelm@35757
|
7 |
section {* Typedef axiomatization \label{sec:hol-typedef} *}
|
wenzelm@26849
|
8 |
|
wenzelm@26849
|
9 |
text {*
|
wenzelm@26849
|
10 |
\begin{matharray}{rcl}
|
wenzelm@35757
|
11 |
@{command_def (HOL) "typedef"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
|
wenzelm@26849
|
12 |
\end{matharray}
|
wenzelm@26849
|
13 |
|
wenzelm@26849
|
14 |
\begin{rail}
|
wenzelm@26849
|
15 |
'typedef' altname? abstype '=' repset
|
wenzelm@26849
|
16 |
;
|
wenzelm@26849
|
17 |
|
wenzelm@26849
|
18 |
altname: '(' (name | 'open' | 'open' name) ')'
|
wenzelm@26849
|
19 |
;
|
wenzelm@35841
|
20 |
abstype: typespecsorts mixfix?
|
wenzelm@26849
|
21 |
;
|
wenzelm@26849
|
22 |
repset: term ('morphisms' name name)?
|
wenzelm@26849
|
23 |
;
|
wenzelm@26849
|
24 |
\end{rail}
|
wenzelm@26849
|
25 |
|
wenzelm@28760
|
26 |
\begin{description}
|
wenzelm@26849
|
27 |
|
wenzelm@35757
|
28 |
\item @{command (HOL) "typedef"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>n) t = A"}
|
wenzelm@35757
|
29 |
axiomatizes a Gordon/HOL-style type definition in the background
|
wenzelm@35757
|
30 |
theory of the current context, depending on a non-emptiness result
|
wenzelm@35757
|
31 |
of the set @{text A} (which needs to be proven interactively).
|
wenzelm@35757
|
32 |
|
wenzelm@35757
|
33 |
The raw type may not depend on parameters or assumptions of the
|
wenzelm@35757
|
34 |
context --- this is logically impossible in Isabelle/HOL --- but the
|
wenzelm@35757
|
35 |
non-emptiness property can be local, potentially resulting in
|
wenzelm@35757
|
36 |
multiple interpretations in target contexts. Thus the established
|
wenzelm@35757
|
37 |
bijection between the representing set @{text A} and the new type
|
wenzelm@35757
|
38 |
@{text t} may semantically depend on local assumptions.
|
wenzelm@26849
|
39 |
|
wenzelm@35757
|
40 |
By default, @{command (HOL) "typedef"} defines both a type @{text t}
|
wenzelm@35757
|
41 |
and a set (term constant) of the same name, unless an alternative
|
wenzelm@35757
|
42 |
base name is given in parentheses, or the ``@{text "(open)"}''
|
wenzelm@35757
|
43 |
declaration is used to suppress a separate constant definition
|
wenzelm@35757
|
44 |
altogether. The injection from type to set is called @{text Rep_t},
|
wenzelm@35757
|
45 |
its inverse @{text Abs_t} --- this may be changed via an explicit
|
wenzelm@35757
|
46 |
@{keyword (HOL) "morphisms"} declaration.
|
wenzelm@26849
|
47 |
|
wenzelm@26849
|
48 |
Theorems @{text Rep_t}, @{text Rep_t_inverse}, and @{text
|
wenzelm@26849
|
49 |
Abs_t_inverse} provide the most basic characterization as a
|
wenzelm@26849
|
50 |
corresponding injection/surjection pair (in both directions). Rules
|
wenzelm@26849
|
51 |
@{text Rep_t_inject} and @{text Abs_t_inject} provide a slightly
|
wenzelm@26849
|
52 |
more convenient view on the injectivity part, suitable for automated
|
wenzelm@26894
|
53 |
proof tools (e.g.\ in @{attribute simp} or @{attribute iff}
|
wenzelm@26894
|
54 |
declarations). Rules @{text Rep_t_cases}/@{text Rep_t_induct}, and
|
wenzelm@26894
|
55 |
@{text Abs_t_cases}/@{text Abs_t_induct} provide alternative views
|
wenzelm@26894
|
56 |
on surjectivity; these are already declared as set or type rules for
|
wenzelm@26849
|
57 |
the generic @{method cases} and @{method induct} methods.
|
wenzelm@26849
|
58 |
|
wenzelm@35757
|
59 |
An alternative name for the set definition (and other derived
|
wenzelm@35757
|
60 |
entities) may be specified in parentheses; the default is to use
|
wenzelm@35757
|
61 |
@{text t} as indicated before.
|
wenzelm@26849
|
62 |
|
wenzelm@28760
|
63 |
\end{description}
|
wenzelm@26849
|
64 |
*}
|
wenzelm@26849
|
65 |
|
wenzelm@26849
|
66 |
|
wenzelm@26849
|
67 |
section {* Adhoc tuples *}
|
wenzelm@26849
|
68 |
|
wenzelm@26849
|
69 |
text {*
|
wenzelm@26849
|
70 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
71 |
@{attribute (HOL) split_format}@{text "\<^sup>*"} & : & @{text attribute} \\
|
wenzelm@26849
|
72 |
\end{matharray}
|
wenzelm@26849
|
73 |
|
wenzelm@26849
|
74 |
\begin{rail}
|
haftmann@31906
|
75 |
'split\_format' ((( name * ) + 'and') | ('(' 'complete' ')'))
|
wenzelm@26849
|
76 |
;
|
wenzelm@26849
|
77 |
\end{rail}
|
wenzelm@26849
|
78 |
|
wenzelm@28760
|
79 |
\begin{description}
|
wenzelm@26849
|
80 |
|
wenzelm@28760
|
81 |
\item @{attribute (HOL) split_format}~@{text "p\<^sub>1 \<dots> p\<^sub>m \<AND> \<dots>
|
wenzelm@28760
|
82 |
\<AND> q\<^sub>1 \<dots> q\<^sub>n"} puts expressions of low-level tuple types into
|
wenzelm@28760
|
83 |
canonical form as specified by the arguments given; the @{text i}-th
|
wenzelm@28760
|
84 |
collection of arguments refers to occurrences in premise @{text i}
|
wenzelm@28760
|
85 |
of the rule. The ``@{text "(complete)"}'' option causes \emph{all}
|
wenzelm@28760
|
86 |
arguments in function applications to be represented canonically
|
wenzelm@28760
|
87 |
according to their tuple type structure.
|
wenzelm@26849
|
88 |
|
wenzelm@26849
|
89 |
Note that these operations tend to invent funny names for new local
|
wenzelm@26849
|
90 |
parameters to be introduced.
|
wenzelm@26849
|
91 |
|
wenzelm@28760
|
92 |
\end{description}
|
wenzelm@26849
|
93 |
*}
|
wenzelm@26849
|
94 |
|
wenzelm@26849
|
95 |
|
wenzelm@26849
|
96 |
section {* Records \label{sec:hol-record} *}
|
wenzelm@26849
|
97 |
|
wenzelm@26849
|
98 |
text {*
|
wenzelm@26849
|
99 |
In principle, records merely generalize the concept of tuples, where
|
wenzelm@26849
|
100 |
components may be addressed by labels instead of just position. The
|
wenzelm@26849
|
101 |
logical infrastructure of records in Isabelle/HOL is slightly more
|
wenzelm@26849
|
102 |
advanced, though, supporting truly extensible record schemes. This
|
wenzelm@26849
|
103 |
admits operations that are polymorphic with respect to record
|
wenzelm@26849
|
104 |
extension, yielding ``object-oriented'' effects like (single)
|
wenzelm@26849
|
105 |
inheritance. See also \cite{NaraschewskiW-TPHOLs98} for more
|
wenzelm@26849
|
106 |
details on object-oriented verification and record subtyping in HOL.
|
wenzelm@26849
|
107 |
*}
|
wenzelm@26849
|
108 |
|
wenzelm@26849
|
109 |
|
wenzelm@26849
|
110 |
subsection {* Basic concepts *}
|
wenzelm@26849
|
111 |
|
wenzelm@26849
|
112 |
text {*
|
wenzelm@26849
|
113 |
Isabelle/HOL supports both \emph{fixed} and \emph{schematic} records
|
wenzelm@26849
|
114 |
at the level of terms and types. The notation is as follows:
|
wenzelm@26849
|
115 |
|
wenzelm@26849
|
116 |
\begin{center}
|
wenzelm@26849
|
117 |
\begin{tabular}{l|l|l}
|
wenzelm@26849
|
118 |
& record terms & record types \\ \hline
|
wenzelm@26849
|
119 |
fixed & @{text "\<lparr>x = a, y = b\<rparr>"} & @{text "\<lparr>x :: A, y :: B\<rparr>"} \\
|
wenzelm@26849
|
120 |
schematic & @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} &
|
wenzelm@26849
|
121 |
@{text "\<lparr>x :: A, y :: B, \<dots> :: M\<rparr>"} \\
|
wenzelm@26849
|
122 |
\end{tabular}
|
wenzelm@26849
|
123 |
\end{center}
|
wenzelm@26849
|
124 |
|
wenzelm@26849
|
125 |
\noindent The ASCII representation of @{text "\<lparr>x = a\<rparr>"} is @{text
|
wenzelm@26849
|
126 |
"(| x = a |)"}.
|
wenzelm@26849
|
127 |
|
wenzelm@26849
|
128 |
A fixed record @{text "\<lparr>x = a, y = b\<rparr>"} has field @{text x} of value
|
wenzelm@26849
|
129 |
@{text a} and field @{text y} of value @{text b}. The corresponding
|
wenzelm@26849
|
130 |
type is @{text "\<lparr>x :: A, y :: B\<rparr>"}, assuming that @{text "a :: A"}
|
wenzelm@26849
|
131 |
and @{text "b :: B"}.
|
wenzelm@26849
|
132 |
|
wenzelm@26849
|
133 |
A record scheme like @{text "\<lparr>x = a, y = b, \<dots> = m\<rparr>"} contains fields
|
wenzelm@26849
|
134 |
@{text x} and @{text y} as before, but also possibly further fields
|
wenzelm@26849
|
135 |
as indicated by the ``@{text "\<dots>"}'' notation (which is actually part
|
wenzelm@26849
|
136 |
of the syntax). The improper field ``@{text "\<dots>"}'' of a record
|
wenzelm@26849
|
137 |
scheme is called the \emph{more part}. Logically it is just a free
|
wenzelm@26849
|
138 |
variable, which is occasionally referred to as ``row variable'' in
|
wenzelm@26849
|
139 |
the literature. The more part of a record scheme may be
|
wenzelm@26849
|
140 |
instantiated by zero or more further components. For example, the
|
wenzelm@26849
|
141 |
previous scheme may get instantiated to @{text "\<lparr>x = a, y = b, z =
|
wenzelm@26852
|
142 |
c, \<dots> = m'\<rparr>"}, where @{text m'} refers to a different more part.
|
wenzelm@26849
|
143 |
Fixed records are special instances of record schemes, where
|
wenzelm@26849
|
144 |
``@{text "\<dots>"}'' is properly terminated by the @{text "() :: unit"}
|
wenzelm@26849
|
145 |
element. In fact, @{text "\<lparr>x = a, y = b\<rparr>"} is just an abbreviation
|
wenzelm@26849
|
146 |
for @{text "\<lparr>x = a, y = b, \<dots> = ()\<rparr>"}.
|
wenzelm@26849
|
147 |
|
wenzelm@26849
|
148 |
\medskip Two key observations make extensible records in a simply
|
wenzelm@26849
|
149 |
typed language like HOL work out:
|
wenzelm@26849
|
150 |
|
wenzelm@26849
|
151 |
\begin{enumerate}
|
wenzelm@26849
|
152 |
|
wenzelm@26849
|
153 |
\item the more part is internalized, as a free term or type
|
wenzelm@26849
|
154 |
variable,
|
wenzelm@26849
|
155 |
|
wenzelm@26852
|
156 |
\item field names are externalized, they cannot be accessed within
|
wenzelm@26852
|
157 |
the logic as first-class values.
|
wenzelm@26849
|
158 |
|
wenzelm@26849
|
159 |
\end{enumerate}
|
wenzelm@26849
|
160 |
|
wenzelm@26849
|
161 |
\medskip In Isabelle/HOL record types have to be defined explicitly,
|
wenzelm@26849
|
162 |
fixing their field names and types, and their (optional) parent
|
wenzelm@26849
|
163 |
record. Afterwards, records may be formed using above syntax, while
|
wenzelm@26849
|
164 |
obeying the canonical order of fields as given by their declaration.
|
wenzelm@26849
|
165 |
The record package provides several standard operations like
|
wenzelm@26849
|
166 |
selectors and updates. The common setup for various generic proof
|
wenzelm@26849
|
167 |
tools enable succinct reasoning patterns. See also the Isabelle/HOL
|
wenzelm@26849
|
168 |
tutorial \cite{isabelle-hol-book} for further instructions on using
|
wenzelm@26849
|
169 |
records in practice.
|
wenzelm@26849
|
170 |
*}
|
wenzelm@26849
|
171 |
|
wenzelm@26849
|
172 |
|
wenzelm@26849
|
173 |
subsection {* Record specifications *}
|
wenzelm@26849
|
174 |
|
wenzelm@26849
|
175 |
text {*
|
wenzelm@26849
|
176 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
177 |
@{command_def (HOL) "record"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@26849
|
178 |
\end{matharray}
|
wenzelm@26849
|
179 |
|
wenzelm@26849
|
180 |
\begin{rail}
|
wenzelm@36158
|
181 |
'record' typespecsorts '=' (type '+')? (constdecl +)
|
wenzelm@26849
|
182 |
;
|
wenzelm@26849
|
183 |
\end{rail}
|
wenzelm@26849
|
184 |
|
wenzelm@28760
|
185 |
\begin{description}
|
wenzelm@26849
|
186 |
|
wenzelm@28760
|
187 |
\item @{command (HOL) "record"}~@{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t = \<tau> + c\<^sub>1 :: \<sigma>\<^sub>1
|
wenzelm@28760
|
188 |
\<dots> c\<^sub>n :: \<sigma>\<^sub>n"} defines extensible record type @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"},
|
wenzelm@26849
|
189 |
derived from the optional parent record @{text "\<tau>"} by adding new
|
wenzelm@26849
|
190 |
field components @{text "c\<^sub>i :: \<sigma>\<^sub>i"} etc.
|
wenzelm@26849
|
191 |
|
wenzelm@26849
|
192 |
The type variables of @{text "\<tau>"} and @{text "\<sigma>\<^sub>i"} need to be
|
wenzelm@26849
|
193 |
covered by the (distinct) parameters @{text "\<alpha>\<^sub>1, \<dots>,
|
wenzelm@26849
|
194 |
\<alpha>\<^sub>m"}. Type constructor @{text t} has to be new, while @{text
|
wenzelm@26849
|
195 |
\<tau>} needs to specify an instance of an existing record type. At
|
wenzelm@26849
|
196 |
least one new field @{text "c\<^sub>i"} has to be specified.
|
wenzelm@26849
|
197 |
Basically, field names need to belong to a unique record. This is
|
wenzelm@26849
|
198 |
not a real restriction in practice, since fields are qualified by
|
wenzelm@26849
|
199 |
the record name internally.
|
wenzelm@26849
|
200 |
|
wenzelm@26849
|
201 |
The parent record specification @{text \<tau>} is optional; if omitted
|
wenzelm@26849
|
202 |
@{text t} becomes a root record. The hierarchy of all records
|
wenzelm@26849
|
203 |
declared within a theory context forms a forest structure, i.e.\ a
|
wenzelm@26849
|
204 |
set of trees starting with a root record each. There is no way to
|
wenzelm@26849
|
205 |
merge multiple parent records!
|
wenzelm@26849
|
206 |
|
wenzelm@26849
|
207 |
For convenience, @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} is made a
|
wenzelm@26849
|
208 |
type abbreviation for the fixed record type @{text "\<lparr>c\<^sub>1 ::
|
wenzelm@26849
|
209 |
\<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n\<rparr>"}, likewise is @{text
|
wenzelm@26849
|
210 |
"(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m, \<zeta>) t_scheme"} made an abbreviation for
|
wenzelm@26849
|
211 |
@{text "\<lparr>c\<^sub>1 :: \<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n, \<dots> ::
|
wenzelm@26849
|
212 |
\<zeta>\<rparr>"}.
|
wenzelm@26849
|
213 |
|
wenzelm@28760
|
214 |
\end{description}
|
wenzelm@26849
|
215 |
*}
|
wenzelm@26849
|
216 |
|
wenzelm@26849
|
217 |
|
wenzelm@26849
|
218 |
subsection {* Record operations *}
|
wenzelm@26849
|
219 |
|
wenzelm@26849
|
220 |
text {*
|
wenzelm@26849
|
221 |
Any record definition of the form presented above produces certain
|
wenzelm@26849
|
222 |
standard operations. Selectors and updates are provided for any
|
wenzelm@26849
|
223 |
field, including the improper one ``@{text more}''. There are also
|
wenzelm@26849
|
224 |
cumulative record constructor functions. To simplify the
|
wenzelm@26849
|
225 |
presentation below, we assume for now that @{text "(\<alpha>\<^sub>1, \<dots>,
|
wenzelm@26849
|
226 |
\<alpha>\<^sub>m) t"} is a root record with fields @{text "c\<^sub>1 ::
|
wenzelm@26849
|
227 |
\<sigma>\<^sub>1, \<dots>, c\<^sub>n :: \<sigma>\<^sub>n"}.
|
wenzelm@26849
|
228 |
|
wenzelm@26849
|
229 |
\medskip \textbf{Selectors} and \textbf{updates} are available for
|
wenzelm@26849
|
230 |
any field (including ``@{text more}''):
|
wenzelm@26849
|
231 |
|
wenzelm@26849
|
232 |
\begin{matharray}{lll}
|
wenzelm@26852
|
233 |
@{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
|
wenzelm@26852
|
234 |
@{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@26849
|
235 |
\end{matharray}
|
wenzelm@26849
|
236 |
|
wenzelm@26849
|
237 |
There is special syntax for application of updates: @{text "r\<lparr>x :=
|
wenzelm@26849
|
238 |
a\<rparr>"} abbreviates term @{text "x_update a r"}. Further notation for
|
wenzelm@26849
|
239 |
repeated updates is also available: @{text "r\<lparr>x := a\<rparr>\<lparr>y := b\<rparr>\<lparr>z :=
|
wenzelm@26849
|
240 |
c\<rparr>"} may be written @{text "r\<lparr>x := a, y := b, z := c\<rparr>"}. Note that
|
wenzelm@26849
|
241 |
because of postfix notation the order of fields shown here is
|
wenzelm@26849
|
242 |
reverse than in the actual term. Since repeated updates are just
|
wenzelm@26849
|
243 |
function applications, fields may be freely permuted in @{text "\<lparr>x
|
wenzelm@26849
|
244 |
:= a, y := b, z := c\<rparr>"}, as far as logical equality is concerned.
|
wenzelm@26849
|
245 |
Thus commutativity of independent updates can be proven within the
|
wenzelm@26849
|
246 |
logic for any two fields, but not as a general theorem.
|
wenzelm@26849
|
247 |
|
wenzelm@26849
|
248 |
\medskip The \textbf{make} operation provides a cumulative record
|
wenzelm@26849
|
249 |
constructor function:
|
wenzelm@26849
|
250 |
|
wenzelm@26849
|
251 |
\begin{matharray}{lll}
|
wenzelm@26852
|
252 |
@{text "t.make"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@26849
|
253 |
\end{matharray}
|
wenzelm@26849
|
254 |
|
wenzelm@26849
|
255 |
\medskip We now reconsider the case of non-root records, which are
|
wenzelm@26849
|
256 |
derived of some parent. In general, the latter may depend on
|
wenzelm@26849
|
257 |
another parent as well, resulting in a list of \emph{ancestor
|
wenzelm@26849
|
258 |
records}. Appending the lists of fields of all ancestors results in
|
wenzelm@26849
|
259 |
a certain field prefix. The record package automatically takes care
|
wenzelm@26849
|
260 |
of this by lifting operations over this context of ancestor fields.
|
wenzelm@26849
|
261 |
Assuming that @{text "(\<alpha>\<^sub>1, \<dots>, \<alpha>\<^sub>m) t"} has ancestor
|
wenzelm@26849
|
262 |
fields @{text "b\<^sub>1 :: \<rho>\<^sub>1, \<dots>, b\<^sub>k :: \<rho>\<^sub>k"},
|
wenzelm@26849
|
263 |
the above record operations will get the following types:
|
wenzelm@26849
|
264 |
|
wenzelm@26852
|
265 |
\medskip
|
wenzelm@26852
|
266 |
\begin{tabular}{lll}
|
wenzelm@26852
|
267 |
@{text "c\<^sub>i"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow> \<sigma>\<^sub>i"} \\
|
wenzelm@26849
|
268 |
@{text "c\<^sub>i_update"} & @{text "::"} & @{text "\<sigma>\<^sub>i \<Rightarrow>
|
wenzelm@26852
|
269 |
\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr> \<Rightarrow>
|
wenzelm@26852
|
270 |
\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
|
wenzelm@26852
|
271 |
@{text "t.make"} & @{text "::"} & @{text "\<rho>\<^sub>1 \<Rightarrow> \<dots> \<rho>\<^sub>k \<Rightarrow> \<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow>
|
wenzelm@26852
|
272 |
\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@26852
|
273 |
\end{tabular}
|
wenzelm@26852
|
274 |
\medskip
|
wenzelm@26849
|
275 |
|
wenzelm@26852
|
276 |
\noindent Some further operations address the extension aspect of a
|
wenzelm@26849
|
277 |
derived record scheme specifically: @{text "t.fields"} produces a
|
wenzelm@26849
|
278 |
record fragment consisting of exactly the new fields introduced here
|
wenzelm@26849
|
279 |
(the result may serve as a more part elsewhere); @{text "t.extend"}
|
wenzelm@26849
|
280 |
takes a fixed record and adds a given more part; @{text
|
wenzelm@26849
|
281 |
"t.truncate"} restricts a record scheme to a fixed record.
|
wenzelm@26849
|
282 |
|
wenzelm@26852
|
283 |
\medskip
|
wenzelm@26852
|
284 |
\begin{tabular}{lll}
|
wenzelm@26852
|
285 |
@{text "t.fields"} & @{text "::"} & @{text "\<sigma>\<^sub>1 \<Rightarrow> \<dots> \<sigma>\<^sub>n \<Rightarrow> \<lparr>\<^vec>c :: \<^vec>\<sigma>\<rparr>"} \\
|
wenzelm@26852
|
286 |
@{text "t.extend"} & @{text "::"} & @{text "\<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>\<rparr> \<Rightarrow>
|
wenzelm@26852
|
287 |
\<zeta> \<Rightarrow> \<lparr>\<^vec>b :: \<^vec>\<rho>, \<^vec>c :: \<^vec>\<sigma>, \<dots> :: \<zeta>\<rparr>"} \\
|
wenzelm@26852
|
288 |
@{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@26852
|
289 |
\end{tabular}
|
wenzelm@26852
|
290 |
\medskip
|
wenzelm@26849
|
291 |
|
wenzelm@26849
|
292 |
\noindent Note that @{text "t.make"} and @{text "t.fields"} coincide
|
wenzelm@26849
|
293 |
for root records.
|
wenzelm@26849
|
294 |
*}
|
wenzelm@26849
|
295 |
|
wenzelm@26849
|
296 |
|
wenzelm@26849
|
297 |
subsection {* Derived rules and proof tools *}
|
wenzelm@26849
|
298 |
|
wenzelm@26849
|
299 |
text {*
|
wenzelm@26849
|
300 |
The record package proves several results internally, declaring
|
wenzelm@26849
|
301 |
these facts to appropriate proof tools. This enables users to
|
wenzelm@26849
|
302 |
reason about record structures quite conveniently. Assume that
|
wenzelm@26849
|
303 |
@{text t} is a record type as specified above.
|
wenzelm@26849
|
304 |
|
wenzelm@26849
|
305 |
\begin{enumerate}
|
wenzelm@26849
|
306 |
|
wenzelm@26849
|
307 |
\item Standard conversions for selectors or updates applied to
|
wenzelm@26849
|
308 |
record constructor terms are made part of the default Simplifier
|
wenzelm@26849
|
309 |
context; thus proofs by reduction of basic operations merely require
|
wenzelm@26849
|
310 |
the @{method simp} method without further arguments. These rules
|
wenzelm@26849
|
311 |
are available as @{text "t.simps"}, too.
|
wenzelm@26849
|
312 |
|
wenzelm@26849
|
313 |
\item Selectors applied to updated records are automatically reduced
|
wenzelm@26849
|
314 |
by an internal simplification procedure, which is also part of the
|
wenzelm@26849
|
315 |
standard Simplifier setup.
|
wenzelm@26849
|
316 |
|
wenzelm@26849
|
317 |
\item Inject equations of a form analogous to @{prop "(x, y) = (x',
|
wenzelm@26849
|
318 |
y') \<equiv> x = x' \<and> y = y'"} are declared to the Simplifier and Classical
|
wenzelm@26849
|
319 |
Reasoner as @{attribute iff} rules. These rules are available as
|
wenzelm@26849
|
320 |
@{text "t.iffs"}.
|
wenzelm@26849
|
321 |
|
wenzelm@26849
|
322 |
\item The introduction rule for record equality analogous to @{text
|
wenzelm@26849
|
323 |
"x r = x r' \<Longrightarrow> y r = y r' \<dots> \<Longrightarrow> r = r'"} is declared to the Simplifier,
|
wenzelm@26849
|
324 |
and as the basic rule context as ``@{attribute intro}@{text "?"}''.
|
wenzelm@26849
|
325 |
The rule is called @{text "t.equality"}.
|
wenzelm@26849
|
326 |
|
wenzelm@26849
|
327 |
\item Representations of arbitrary record expressions as canonical
|
wenzelm@26849
|
328 |
constructor terms are provided both in @{method cases} and @{method
|
wenzelm@26849
|
329 |
induct} format (cf.\ the generic proof methods of the same name,
|
wenzelm@26849
|
330 |
\secref{sec:cases-induct}). Several variations are available, for
|
wenzelm@26849
|
331 |
fixed records, record schemes, more parts etc.
|
wenzelm@26849
|
332 |
|
wenzelm@26849
|
333 |
The generic proof methods are sufficiently smart to pick the most
|
wenzelm@26849
|
334 |
sensible rule according to the type of the indicated record
|
wenzelm@26849
|
335 |
expression: users just need to apply something like ``@{text "(cases
|
wenzelm@26849
|
336 |
r)"}'' to a certain proof problem.
|
wenzelm@26849
|
337 |
|
wenzelm@26849
|
338 |
\item The derived record operations @{text "t.make"}, @{text
|
wenzelm@26849
|
339 |
"t.fields"}, @{text "t.extend"}, @{text "t.truncate"} are \emph{not}
|
wenzelm@26849
|
340 |
treated automatically, but usually need to be expanded by hand,
|
wenzelm@26849
|
341 |
using the collective fact @{text "t.defs"}.
|
wenzelm@26849
|
342 |
|
wenzelm@26849
|
343 |
\end{enumerate}
|
wenzelm@26849
|
344 |
*}
|
wenzelm@26849
|
345 |
|
wenzelm@26849
|
346 |
|
wenzelm@26849
|
347 |
section {* Datatypes \label{sec:hol-datatype} *}
|
wenzelm@26849
|
348 |
|
wenzelm@26849
|
349 |
text {*
|
wenzelm@26849
|
350 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
351 |
@{command_def (HOL) "datatype"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@28761
|
352 |
@{command_def (HOL) "rep_datatype"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@26849
|
353 |
\end{matharray}
|
wenzelm@26849
|
354 |
|
wenzelm@26849
|
355 |
\begin{rail}
|
wenzelm@26849
|
356 |
'datatype' (dtspec + 'and')
|
wenzelm@26849
|
357 |
;
|
haftmann@27452
|
358 |
'rep\_datatype' ('(' (name +) ')')? (term +)
|
wenzelm@26849
|
359 |
;
|
wenzelm@26849
|
360 |
|
wenzelm@35352
|
361 |
dtspec: parname? typespec mixfix? '=' (cons + '|')
|
wenzelm@26849
|
362 |
;
|
haftmann@31906
|
363 |
cons: name ( type * ) mixfix?
|
wenzelm@26849
|
364 |
\end{rail}
|
wenzelm@26849
|
365 |
|
wenzelm@28760
|
366 |
\begin{description}
|
wenzelm@26849
|
367 |
|
wenzelm@28760
|
368 |
\item @{command (HOL) "datatype"} defines inductive datatypes in
|
wenzelm@26849
|
369 |
HOL.
|
wenzelm@26849
|
370 |
|
wenzelm@28760
|
371 |
\item @{command (HOL) "rep_datatype"} represents existing types as
|
wenzelm@26849
|
372 |
inductive ones, generating the standard infrastructure of derived
|
wenzelm@26849
|
373 |
concepts (primitive recursion etc.).
|
wenzelm@26849
|
374 |
|
wenzelm@28760
|
375 |
\end{description}
|
wenzelm@26849
|
376 |
|
wenzelm@26849
|
377 |
The induction and exhaustion theorems generated provide case names
|
wenzelm@26849
|
378 |
according to the constructors involved, while parameters are named
|
wenzelm@26849
|
379 |
after the types (see also \secref{sec:cases-induct}).
|
wenzelm@26849
|
380 |
|
wenzelm@26849
|
381 |
See \cite{isabelle-HOL} for more details on datatypes, but beware of
|
wenzelm@26849
|
382 |
the old-style theory syntax being used there! Apart from proper
|
wenzelm@26849
|
383 |
proof methods for case-analysis and induction, there are also
|
wenzelm@26849
|
384 |
emulations of ML tactics @{method (HOL) case_tac} and @{method (HOL)
|
wenzelm@26849
|
385 |
induct_tac} available, see \secref{sec:hol-induct-tac}; these admit
|
wenzelm@26849
|
386 |
to refer directly to the internal structure of subgoals (including
|
wenzelm@26849
|
387 |
internally bound parameters).
|
wenzelm@26849
|
388 |
*}
|
wenzelm@26849
|
389 |
|
wenzelm@26849
|
390 |
|
wenzelm@26849
|
391 |
section {* Recursive functions \label{sec:recursion} *}
|
wenzelm@26849
|
392 |
|
wenzelm@26849
|
393 |
text {*
|
wenzelm@26849
|
394 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
395 |
@{command_def (HOL) "primrec"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@28761
|
396 |
@{command_def (HOL) "fun"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@28761
|
397 |
@{command_def (HOL) "function"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
|
wenzelm@28761
|
398 |
@{command_def (HOL) "termination"} & : & @{text "local_theory \<rightarrow> proof(prove)"} \\
|
wenzelm@26849
|
399 |
\end{matharray}
|
wenzelm@26849
|
400 |
|
wenzelm@26849
|
401 |
\begin{rail}
|
wenzelm@26849
|
402 |
'primrec' target? fixes 'where' equations
|
wenzelm@26849
|
403 |
;
|
krauss@40411
|
404 |
('fun' | 'function') target? functionopts? fixes \\ 'where' equations
|
krauss@40411
|
405 |
;
|
wenzelm@26849
|
406 |
equations: (thmdecl? prop + '|')
|
wenzelm@26849
|
407 |
;
|
wenzelm@26985
|
408 |
functionopts: '(' (('sequential' | 'domintros' | 'tailrec' | 'default' term) + ',') ')'
|
wenzelm@26849
|
409 |
;
|
wenzelm@26849
|
410 |
'termination' ( term )?
|
wenzelm@26849
|
411 |
\end{rail}
|
wenzelm@26849
|
412 |
|
wenzelm@28760
|
413 |
\begin{description}
|
wenzelm@26849
|
414 |
|
wenzelm@28760
|
415 |
\item @{command (HOL) "primrec"} defines primitive recursive
|
wenzelm@26849
|
416 |
functions over datatypes, see also \cite{isabelle-HOL}.
|
wenzelm@26849
|
417 |
|
wenzelm@28760
|
418 |
\item @{command (HOL) "function"} defines functions by general
|
wenzelm@26849
|
419 |
wellfounded recursion. A detailed description with examples can be
|
wenzelm@26849
|
420 |
found in \cite{isabelle-function}. The function is specified by a
|
wenzelm@26849
|
421 |
set of (possibly conditional) recursive equations with arbitrary
|
wenzelm@26849
|
422 |
pattern matching. The command generates proof obligations for the
|
wenzelm@26849
|
423 |
completeness and the compatibility of patterns.
|
wenzelm@26849
|
424 |
|
wenzelm@26849
|
425 |
The defined function is considered partial, and the resulting
|
wenzelm@26849
|
426 |
simplification rules (named @{text "f.psimps"}) and induction rule
|
wenzelm@26849
|
427 |
(named @{text "f.pinduct"}) are guarded by a generated domain
|
wenzelm@26849
|
428 |
predicate @{text "f_dom"}. The @{command (HOL) "termination"}
|
wenzelm@26849
|
429 |
command can then be used to establish that the function is total.
|
wenzelm@26849
|
430 |
|
wenzelm@28760
|
431 |
\item @{command (HOL) "fun"} is a shorthand notation for ``@{command
|
wenzelm@28760
|
432 |
(HOL) "function"}~@{text "(sequential)"}, followed by automated
|
wenzelm@28760
|
433 |
proof attempts regarding pattern matching and termination. See
|
wenzelm@28760
|
434 |
\cite{isabelle-function} for further details.
|
wenzelm@26849
|
435 |
|
wenzelm@28760
|
436 |
\item @{command (HOL) "termination"}~@{text f} commences a
|
wenzelm@26849
|
437 |
termination proof for the previously defined function @{text f}. If
|
wenzelm@26849
|
438 |
this is omitted, the command refers to the most recent function
|
wenzelm@26849
|
439 |
definition. After the proof is closed, the recursive equations and
|
wenzelm@26849
|
440 |
the induction principle is established.
|
wenzelm@26849
|
441 |
|
wenzelm@28760
|
442 |
\end{description}
|
wenzelm@26849
|
443 |
|
haftmann@27452
|
444 |
Recursive definitions introduced by the @{command (HOL) "function"}
|
haftmann@27452
|
445 |
command accommodate
|
wenzelm@26849
|
446 |
reasoning by induction (cf.\ \secref{sec:cases-induct}): rule @{text
|
wenzelm@26849
|
447 |
"c.induct"} (where @{text c} is the name of the function definition)
|
wenzelm@26849
|
448 |
refers to a specific induction rule, with parameters named according
|
krauss@33857
|
449 |
to the user-specified equations. Cases are numbered (starting from 1).
|
krauss@33857
|
450 |
|
krauss@33857
|
451 |
For @{command (HOL) "primrec"}, the induction principle coincides
|
haftmann@27452
|
452 |
with structural recursion on the datatype the recursion is carried
|
haftmann@27452
|
453 |
out.
|
wenzelm@26849
|
454 |
|
wenzelm@26849
|
455 |
The equations provided by these packages may be referred later as
|
wenzelm@26849
|
456 |
theorem list @{text "f.simps"}, where @{text f} is the (collective)
|
wenzelm@26849
|
457 |
name of the functions defined. Individual equations may be named
|
wenzelm@26849
|
458 |
explicitly as well.
|
wenzelm@26849
|
459 |
|
wenzelm@26849
|
460 |
The @{command (HOL) "function"} command accepts the following
|
wenzelm@26849
|
461 |
options.
|
wenzelm@26849
|
462 |
|
wenzelm@28760
|
463 |
\begin{description}
|
wenzelm@26849
|
464 |
|
wenzelm@28760
|
465 |
\item @{text sequential} enables a preprocessor which disambiguates
|
wenzelm@28760
|
466 |
overlapping patterns by making them mutually disjoint. Earlier
|
wenzelm@28760
|
467 |
equations take precedence over later ones. This allows to give the
|
wenzelm@28760
|
468 |
specification in a format very similar to functional programming.
|
wenzelm@28760
|
469 |
Note that the resulting simplification and induction rules
|
wenzelm@28760
|
470 |
correspond to the transformed specification, not the one given
|
wenzelm@26849
|
471 |
originally. This usually means that each equation given by the user
|
hoelzl@36137
|
472 |
may result in several theorems. Also note that this automatic
|
wenzelm@26849
|
473 |
transformation only works for ML-style datatype patterns.
|
wenzelm@26849
|
474 |
|
wenzelm@28760
|
475 |
\item @{text domintros} enables the automated generation of
|
wenzelm@26849
|
476 |
introduction rules for the domain predicate. While mostly not
|
wenzelm@26849
|
477 |
needed, they can be helpful in some proofs about partial functions.
|
wenzelm@26849
|
478 |
|
wenzelm@28760
|
479 |
\item @{text tailrec} generates the unconstrained recursive
|
wenzelm@26849
|
480 |
equations even without a termination proof, provided that the
|
wenzelm@26849
|
481 |
function is tail-recursive. This currently only works
|
wenzelm@26849
|
482 |
|
wenzelm@28760
|
483 |
\item @{text "default d"} allows to specify a default value for a
|
wenzelm@26849
|
484 |
(partial) function, which will ensure that @{text "f x = d x"}
|
wenzelm@26849
|
485 |
whenever @{text "x \<notin> f_dom"}.
|
wenzelm@26849
|
486 |
|
wenzelm@28760
|
487 |
\end{description}
|
wenzelm@26849
|
488 |
*}
|
wenzelm@26849
|
489 |
|
wenzelm@26849
|
490 |
|
wenzelm@26849
|
491 |
subsection {* Proof methods related to recursive definitions *}
|
wenzelm@26849
|
492 |
|
wenzelm@26849
|
493 |
text {*
|
wenzelm@26849
|
494 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
495 |
@{method_def (HOL) pat_completeness} & : & @{text method} \\
|
wenzelm@28761
|
496 |
@{method_def (HOL) relation} & : & @{text method} \\
|
wenzelm@28761
|
497 |
@{method_def (HOL) lexicographic_order} & : & @{text method} \\
|
krauss@33858
|
498 |
@{method_def (HOL) size_change} & : & @{text method} \\
|
wenzelm@26849
|
499 |
\end{matharray}
|
wenzelm@26849
|
500 |
|
wenzelm@26849
|
501 |
\begin{rail}
|
wenzelm@26849
|
502 |
'relation' term
|
wenzelm@26849
|
503 |
;
|
haftmann@31906
|
504 |
'lexicographic\_order' ( clasimpmod * )
|
wenzelm@26849
|
505 |
;
|
krauss@33858
|
506 |
'size\_change' ( orders ( clasimpmod * ) )
|
krauss@33858
|
507 |
;
|
krauss@33858
|
508 |
orders: ( 'max' | 'min' | 'ms' ) *
|
wenzelm@26849
|
509 |
\end{rail}
|
wenzelm@26849
|
510 |
|
wenzelm@28760
|
511 |
\begin{description}
|
wenzelm@26849
|
512 |
|
wenzelm@28760
|
513 |
\item @{method (HOL) pat_completeness} is a specialized method to
|
wenzelm@26849
|
514 |
solve goals regarding the completeness of pattern matching, as
|
wenzelm@26849
|
515 |
required by the @{command (HOL) "function"} package (cf.\
|
wenzelm@26849
|
516 |
\cite{isabelle-function}).
|
wenzelm@26849
|
517 |
|
wenzelm@28760
|
518 |
\item @{method (HOL) relation}~@{text R} introduces a termination
|
wenzelm@26849
|
519 |
proof using the relation @{text R}. The resulting proof state will
|
wenzelm@26849
|
520 |
contain goals expressing that @{text R} is wellfounded, and that the
|
wenzelm@26849
|
521 |
arguments of recursive calls decrease with respect to @{text R}.
|
wenzelm@26849
|
522 |
Usually, this method is used as the initial proof step of manual
|
wenzelm@26849
|
523 |
termination proofs.
|
wenzelm@26849
|
524 |
|
wenzelm@28760
|
525 |
\item @{method (HOL) "lexicographic_order"} attempts a fully
|
wenzelm@26849
|
526 |
automated termination proof by searching for a lexicographic
|
wenzelm@26849
|
527 |
combination of size measures on the arguments of the function. The
|
wenzelm@26849
|
528 |
method accepts the same arguments as the @{method auto} method,
|
wenzelm@26849
|
529 |
which it uses internally to prove local descents. The same context
|
wenzelm@26849
|
530 |
modifiers as for @{method auto} are accepted, see
|
wenzelm@26849
|
531 |
\secref{sec:clasimp}.
|
wenzelm@26849
|
532 |
|
wenzelm@26849
|
533 |
In case of failure, extensive information is printed, which can help
|
wenzelm@26849
|
534 |
to analyse the situation (cf.\ \cite{isabelle-function}).
|
wenzelm@26849
|
535 |
|
krauss@33858
|
536 |
\item @{method (HOL) "size_change"} also works on termination goals,
|
krauss@33858
|
537 |
using a variation of the size-change principle, together with a
|
krauss@33858
|
538 |
graph decomposition technique (see \cite{krauss_phd} for details).
|
krauss@33858
|
539 |
Three kinds of orders are used internally: @{text max}, @{text min},
|
krauss@33858
|
540 |
and @{text ms} (multiset), which is only available when the theory
|
krauss@33858
|
541 |
@{text Multiset} is loaded. When no order kinds are given, they are
|
krauss@33858
|
542 |
tried in order. The search for a termination proof uses SAT solving
|
krauss@33858
|
543 |
internally.
|
krauss@33858
|
544 |
|
krauss@33858
|
545 |
For local descent proofs, the same context modifiers as for @{method
|
krauss@33858
|
546 |
auto} are accepted, see \secref{sec:clasimp}.
|
krauss@33858
|
547 |
|
wenzelm@28760
|
548 |
\end{description}
|
wenzelm@26849
|
549 |
*}
|
wenzelm@26849
|
550 |
|
krauss@40412
|
551 |
subsection {* Functions with explicit partiality *}
|
krauss@40412
|
552 |
|
krauss@40412
|
553 |
text {*
|
krauss@40412
|
554 |
\begin{matharray}{rcl}
|
krauss@40412
|
555 |
@{command_def (HOL) "partial_function"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
krauss@40412
|
556 |
@{attribute_def (HOL) "partial_function_mono"} & : & @{text attribute} \\
|
krauss@40412
|
557 |
\end{matharray}
|
krauss@40412
|
558 |
|
krauss@40412
|
559 |
\begin{rail}
|
krauss@40412
|
560 |
'partial_function' target? '(' mode ')' fixes \\ 'where' thmdecl? prop
|
krauss@40412
|
561 |
\end{rail}
|
krauss@40412
|
562 |
|
krauss@40412
|
563 |
\begin{description}
|
krauss@40412
|
564 |
|
krauss@40412
|
565 |
\item @{command (HOL) "partial_function"} defines recursive
|
krauss@40412
|
566 |
functions based on fixpoints in complete partial orders. No
|
krauss@40412
|
567 |
termination proof is required from the user or constructed
|
krauss@40412
|
568 |
internally. Instead, the possibility of non-termination is modelled
|
krauss@40412
|
569 |
explicitly in the result type, which contains an explicit bottom
|
krauss@40412
|
570 |
element.
|
krauss@40412
|
571 |
|
krauss@40412
|
572 |
Pattern matching and mutual recursion are currently not supported.
|
krauss@40412
|
573 |
Thus, the specification consists of a single function described by a
|
krauss@40412
|
574 |
single recursive equation.
|
krauss@40412
|
575 |
|
krauss@40412
|
576 |
There are no fixed syntactic restrictions on the body of the
|
krauss@40412
|
577 |
function, but the induced functional must be provably monotonic
|
krauss@40412
|
578 |
wrt.\ the underlying order. The monotonicitity proof is performed
|
krauss@40412
|
579 |
internally, and the definition is rejected when it fails. The proof
|
krauss@40412
|
580 |
can be influenced by declaring hints using the
|
krauss@40412
|
581 |
@{attribute (HOL) partial_function_mono} attribute.
|
krauss@40412
|
582 |
|
krauss@40412
|
583 |
The mandatory @{text mode} argument specifies the mode of operation
|
krauss@40412
|
584 |
of the command, which directly corresponds to a complete partial
|
krauss@40412
|
585 |
order on the result type. By default, the following modes are
|
krauss@40412
|
586 |
defined:
|
krauss@40412
|
587 |
|
krauss@40412
|
588 |
\begin{description}
|
krauss@40412
|
589 |
\item @{text option} defines functions that map into the @{type
|
krauss@40412
|
590 |
option} type. Here, the value @{term None} is used to model a
|
krauss@40412
|
591 |
non-terminating computation. Monotonicity requires that if @{term
|
krauss@40412
|
592 |
None} is returned by a recursive call, then the overall result
|
krauss@40412
|
593 |
must also be @{term None}. This is best achieved through the use of
|
krauss@40412
|
594 |
the monadic operator @{const "Option.bind"}.
|
krauss@40412
|
595 |
|
krauss@40412
|
596 |
\item @{text tailrec} defines functions with an arbitrary result
|
krauss@40412
|
597 |
type and uses the slightly degenerated partial order where @{term
|
krauss@40412
|
598 |
"undefined"} is the bottom element. Now, monotonicity requires that
|
krauss@40412
|
599 |
if @{term undefined} is returned by a recursive call, then the
|
krauss@40412
|
600 |
overall result must also be @{term undefined}. In practice, this is
|
krauss@40412
|
601 |
only satisfied when each recursive call is a tail call, whose result
|
krauss@40412
|
602 |
is directly returned. Thus, this mode of operation allows the
|
krauss@40412
|
603 |
definition of arbitrary tail-recursive functions.
|
krauss@40412
|
604 |
\end{description}
|
krauss@40412
|
605 |
|
krauss@40412
|
606 |
Experienced users may define new modes by instantiating the locale
|
krauss@40412
|
607 |
@{const "partial_function_definitions"} appropriately.
|
krauss@40412
|
608 |
|
krauss@40412
|
609 |
\item @{attribute (HOL) partial_function_mono} declares rules for
|
krauss@40412
|
610 |
use in the internal monononicity proofs of partial function
|
krauss@40412
|
611 |
definitions.
|
krauss@40412
|
612 |
|
krauss@40412
|
613 |
\end{description}
|
krauss@40412
|
614 |
|
krauss@40412
|
615 |
*}
|
wenzelm@26849
|
616 |
|
wenzelm@26849
|
617 |
subsection {* Old-style recursive function definitions (TFL) *}
|
wenzelm@26849
|
618 |
|
wenzelm@26849
|
619 |
text {*
|
wenzelm@26849
|
620 |
The old TFL commands @{command (HOL) "recdef"} and @{command (HOL)
|
wenzelm@26849
|
621 |
"recdef_tc"} for defining recursive are mostly obsolete; @{command
|
wenzelm@26849
|
622 |
(HOL) "function"} or @{command (HOL) "fun"} should be used instead.
|
wenzelm@26849
|
623 |
|
wenzelm@26849
|
624 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
625 |
@{command_def (HOL) "recdef"} & : & @{text "theory \<rightarrow> theory)"} \\
|
wenzelm@28761
|
626 |
@{command_def (HOL) "recdef_tc"}@{text "\<^sup>*"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@26849
|
627 |
\end{matharray}
|
wenzelm@26849
|
628 |
|
wenzelm@26849
|
629 |
\begin{rail}
|
wenzelm@26849
|
630 |
'recdef' ('(' 'permissive' ')')? \\ name term (prop +) hints?
|
wenzelm@26849
|
631 |
;
|
wenzelm@26849
|
632 |
recdeftc thmdecl? tc
|
wenzelm@26849
|
633 |
;
|
haftmann@31906
|
634 |
hints: '(' 'hints' ( recdefmod * ) ')'
|
wenzelm@26849
|
635 |
;
|
wenzelm@26849
|
636 |
recdefmod: (('recdef\_simp' | 'recdef\_cong' | 'recdef\_wf') (() | 'add' | 'del') ':' thmrefs) | clasimpmod
|
wenzelm@26849
|
637 |
;
|
wenzelm@26849
|
638 |
tc: nameref ('(' nat ')')?
|
wenzelm@26849
|
639 |
;
|
wenzelm@26849
|
640 |
\end{rail}
|
wenzelm@26849
|
641 |
|
wenzelm@28760
|
642 |
\begin{description}
|
wenzelm@26849
|
643 |
|
wenzelm@28760
|
644 |
\item @{command (HOL) "recdef"} defines general well-founded
|
wenzelm@26849
|
645 |
recursive functions (using the TFL package), see also
|
wenzelm@26849
|
646 |
\cite{isabelle-HOL}. The ``@{text "(permissive)"}'' option tells
|
wenzelm@26849
|
647 |
TFL to recover from failed proof attempts, returning unfinished
|
wenzelm@26849
|
648 |
results. The @{text recdef_simp}, @{text recdef_cong}, and @{text
|
wenzelm@26849
|
649 |
recdef_wf} hints refer to auxiliary rules to be used in the internal
|
wenzelm@26849
|
650 |
automated proof process of TFL. Additional @{syntax clasimpmod}
|
wenzelm@26849
|
651 |
declarations (cf.\ \secref{sec:clasimp}) may be given to tune the
|
wenzelm@26849
|
652 |
context of the Simplifier (cf.\ \secref{sec:simplifier}) and
|
wenzelm@26849
|
653 |
Classical reasoner (cf.\ \secref{sec:classical}).
|
wenzelm@26849
|
654 |
|
wenzelm@28760
|
655 |
\item @{command (HOL) "recdef_tc"}~@{text "c (i)"} recommences the
|
wenzelm@26849
|
656 |
proof for leftover termination condition number @{text i} (default
|
wenzelm@26849
|
657 |
1) as generated by a @{command (HOL) "recdef"} definition of
|
wenzelm@26849
|
658 |
constant @{text c}.
|
wenzelm@26849
|
659 |
|
wenzelm@26849
|
660 |
Note that in most cases, @{command (HOL) "recdef"} is able to finish
|
wenzelm@26849
|
661 |
its internal proofs without manual intervention.
|
wenzelm@26849
|
662 |
|
wenzelm@28760
|
663 |
\end{description}
|
wenzelm@26849
|
664 |
|
wenzelm@26849
|
665 |
\medskip Hints for @{command (HOL) "recdef"} may be also declared
|
wenzelm@26849
|
666 |
globally, using the following attributes.
|
wenzelm@26849
|
667 |
|
wenzelm@26849
|
668 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
669 |
@{attribute_def (HOL) recdef_simp} & : & @{text attribute} \\
|
wenzelm@28761
|
670 |
@{attribute_def (HOL) recdef_cong} & : & @{text attribute} \\
|
wenzelm@28761
|
671 |
@{attribute_def (HOL) recdef_wf} & : & @{text attribute} \\
|
wenzelm@26849
|
672 |
\end{matharray}
|
wenzelm@26849
|
673 |
|
wenzelm@26849
|
674 |
\begin{rail}
|
wenzelm@26849
|
675 |
('recdef\_simp' | 'recdef\_cong' | 'recdef\_wf') (() | 'add' | 'del')
|
wenzelm@26849
|
676 |
;
|
wenzelm@26849
|
677 |
\end{rail}
|
wenzelm@26849
|
678 |
*}
|
wenzelm@26849
|
679 |
|
wenzelm@26849
|
680 |
|
wenzelm@26849
|
681 |
section {* Inductive and coinductive definitions \label{sec:hol-inductive} *}
|
wenzelm@26849
|
682 |
|
wenzelm@26849
|
683 |
text {*
|
wenzelm@26849
|
684 |
An \textbf{inductive definition} specifies the least predicate (or
|
wenzelm@26849
|
685 |
set) @{text R} closed under given rules: applying a rule to elements
|
wenzelm@26849
|
686 |
of @{text R} yields a result within @{text R}. For example, a
|
wenzelm@26849
|
687 |
structural operational semantics is an inductive definition of an
|
wenzelm@26849
|
688 |
evaluation relation.
|
wenzelm@26849
|
689 |
|
wenzelm@26849
|
690 |
Dually, a \textbf{coinductive definition} specifies the greatest
|
wenzelm@26849
|
691 |
predicate~/ set @{text R} that is consistent with given rules: every
|
wenzelm@26849
|
692 |
element of @{text R} can be seen as arising by applying a rule to
|
wenzelm@26849
|
693 |
elements of @{text R}. An important example is using bisimulation
|
wenzelm@26849
|
694 |
relations to formalise equivalence of processes and infinite data
|
wenzelm@26849
|
695 |
structures.
|
wenzelm@26849
|
696 |
|
wenzelm@26849
|
697 |
\medskip The HOL package is related to the ZF one, which is
|
wenzelm@26849
|
698 |
described in a separate paper,\footnote{It appeared in CADE
|
wenzelm@26849
|
699 |
\cite{paulson-CADE}; a longer version is distributed with Isabelle.}
|
wenzelm@26849
|
700 |
which you should refer to in case of difficulties. The package is
|
wenzelm@26849
|
701 |
simpler than that of ZF thanks to implicit type-checking in HOL.
|
wenzelm@26849
|
702 |
The types of the (co)inductive predicates (or sets) determine the
|
wenzelm@26849
|
703 |
domain of the fixedpoint definition, and the package does not have
|
wenzelm@26849
|
704 |
to use inference rules for type-checking.
|
wenzelm@26849
|
705 |
|
wenzelm@26849
|
706 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
707 |
@{command_def (HOL) "inductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@28761
|
708 |
@{command_def (HOL) "inductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@28761
|
709 |
@{command_def (HOL) "coinductive"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@28761
|
710 |
@{command_def (HOL) "coinductive_set"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@28761
|
711 |
@{attribute_def (HOL) mono} & : & @{text attribute} \\
|
wenzelm@26849
|
712 |
\end{matharray}
|
wenzelm@26849
|
713 |
|
wenzelm@26849
|
714 |
\begin{rail}
|
wenzelm@26849
|
715 |
('inductive' | 'inductive\_set' | 'coinductive' | 'coinductive\_set') target? fixes ('for' fixes)? \\
|
wenzelm@26849
|
716 |
('where' clauses)? ('monos' thmrefs)?
|
wenzelm@26849
|
717 |
;
|
wenzelm@26849
|
718 |
clauses: (thmdecl? prop + '|')
|
wenzelm@26849
|
719 |
;
|
wenzelm@26849
|
720 |
'mono' (() | 'add' | 'del')
|
wenzelm@26849
|
721 |
;
|
wenzelm@26849
|
722 |
\end{rail}
|
wenzelm@26849
|
723 |
|
wenzelm@28760
|
724 |
\begin{description}
|
wenzelm@26849
|
725 |
|
wenzelm@28760
|
726 |
\item @{command (HOL) "inductive"} and @{command (HOL)
|
wenzelm@28760
|
727 |
"coinductive"} define (co)inductive predicates from the
|
wenzelm@26849
|
728 |
introduction rules given in the @{keyword "where"} part. The
|
wenzelm@26849
|
729 |
optional @{keyword "for"} part contains a list of parameters of the
|
wenzelm@26849
|
730 |
(co)inductive predicates that remain fixed throughout the
|
wenzelm@26849
|
731 |
definition. The optional @{keyword "monos"} section contains
|
wenzelm@26849
|
732 |
\emph{monotonicity theorems}, which are required for each operator
|
wenzelm@26849
|
733 |
applied to a recursive set in the introduction rules. There
|
wenzelm@26849
|
734 |
\emph{must} be a theorem of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"},
|
wenzelm@26849
|
735 |
for each premise @{text "M R\<^sub>i t"} in an introduction rule!
|
wenzelm@26849
|
736 |
|
wenzelm@28760
|
737 |
\item @{command (HOL) "inductive_set"} and @{command (HOL)
|
wenzelm@28760
|
738 |
"coinductive_set"} are wrappers for to the previous commands,
|
wenzelm@26849
|
739 |
allowing the definition of (co)inductive sets.
|
wenzelm@26849
|
740 |
|
wenzelm@28760
|
741 |
\item @{attribute (HOL) mono} declares monotonicity rules. These
|
wenzelm@26849
|
742 |
rule are involved in the automated monotonicity proof of @{command
|
wenzelm@26849
|
743 |
(HOL) "inductive"}.
|
wenzelm@26849
|
744 |
|
wenzelm@28760
|
745 |
\end{description}
|
wenzelm@26849
|
746 |
*}
|
wenzelm@26849
|
747 |
|
wenzelm@26849
|
748 |
|
wenzelm@26849
|
749 |
subsection {* Derived rules *}
|
wenzelm@26849
|
750 |
|
wenzelm@26849
|
751 |
text {*
|
wenzelm@26849
|
752 |
Each (co)inductive definition @{text R} adds definitions to the
|
wenzelm@26849
|
753 |
theory and also proves some theorems:
|
wenzelm@26849
|
754 |
|
wenzelm@26849
|
755 |
\begin{description}
|
wenzelm@26849
|
756 |
|
wenzelm@28760
|
757 |
\item @{text R.intros} is the list of introduction rules as proven
|
wenzelm@26849
|
758 |
theorems, for the recursive predicates (or sets). The rules are
|
wenzelm@26849
|
759 |
also available individually, using the names given them in the
|
wenzelm@26849
|
760 |
theory file;
|
wenzelm@26849
|
761 |
|
wenzelm@28760
|
762 |
\item @{text R.cases} is the case analysis (or elimination) rule;
|
wenzelm@26849
|
763 |
|
wenzelm@28760
|
764 |
\item @{text R.induct} or @{text R.coinduct} is the (co)induction
|
wenzelm@26849
|
765 |
rule.
|
wenzelm@26849
|
766 |
|
wenzelm@26849
|
767 |
\end{description}
|
wenzelm@26849
|
768 |
|
wenzelm@26849
|
769 |
When several predicates @{text "R\<^sub>1, \<dots>, R\<^sub>n"} are
|
wenzelm@26849
|
770 |
defined simultaneously, the list of introduction rules is called
|
wenzelm@26849
|
771 |
@{text "R\<^sub>1_\<dots>_R\<^sub>n.intros"}, the case analysis rules are
|
wenzelm@26849
|
772 |
called @{text "R\<^sub>1.cases, \<dots>, R\<^sub>n.cases"}, and the list
|
wenzelm@26849
|
773 |
of mutual induction rules is called @{text
|
wenzelm@26849
|
774 |
"R\<^sub>1_\<dots>_R\<^sub>n.inducts"}.
|
wenzelm@26849
|
775 |
*}
|
wenzelm@26849
|
776 |
|
wenzelm@26849
|
777 |
|
wenzelm@26849
|
778 |
subsection {* Monotonicity theorems *}
|
wenzelm@26849
|
779 |
|
wenzelm@26849
|
780 |
text {*
|
wenzelm@26849
|
781 |
Each theory contains a default set of theorems that are used in
|
wenzelm@26849
|
782 |
monotonicity proofs. New rules can be added to this set via the
|
wenzelm@26849
|
783 |
@{attribute (HOL) mono} attribute. The HOL theory @{text Inductive}
|
wenzelm@26849
|
784 |
shows how this is done. In general, the following monotonicity
|
wenzelm@26849
|
785 |
theorems may be added:
|
wenzelm@26849
|
786 |
|
wenzelm@26849
|
787 |
\begin{itemize}
|
wenzelm@26849
|
788 |
|
wenzelm@26849
|
789 |
\item Theorems of the form @{text "A \<le> B \<Longrightarrow> M A \<le> M B"}, for proving
|
wenzelm@26849
|
790 |
monotonicity of inductive definitions whose introduction rules have
|
wenzelm@26849
|
791 |
premises involving terms such as @{text "M R\<^sub>i t"}.
|
wenzelm@26849
|
792 |
|
wenzelm@26849
|
793 |
\item Monotonicity theorems for logical operators, which are of the
|
wenzelm@26849
|
794 |
general form @{text "(\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> (\<dots> \<longrightarrow> \<dots>) \<Longrightarrow> \<dots> \<longrightarrow> \<dots>"}. For example, in
|
wenzelm@26849
|
795 |
the case of the operator @{text "\<or>"}, the corresponding theorem is
|
wenzelm@26849
|
796 |
\[
|
wenzelm@26849
|
797 |
\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@26849
|
798 |
\]
|
wenzelm@26849
|
799 |
|
wenzelm@26849
|
800 |
\item De Morgan style equations for reasoning about the ``polarity''
|
wenzelm@26849
|
801 |
of expressions, e.g.
|
wenzelm@26849
|
802 |
\[
|
wenzelm@26849
|
803 |
@{prop "\<not> \<not> P \<longleftrightarrow> P"} \qquad\qquad
|
wenzelm@26849
|
804 |
@{prop "\<not> (P \<and> Q) \<longleftrightarrow> \<not> P \<or> \<not> Q"}
|
wenzelm@26849
|
805 |
\]
|
wenzelm@26849
|
806 |
|
wenzelm@26849
|
807 |
\item Equations for reducing complex operators to more primitive
|
wenzelm@26849
|
808 |
ones whose monotonicity can easily be proved, e.g.
|
wenzelm@26849
|
809 |
\[
|
wenzelm@26849
|
810 |
@{prop "(P \<longrightarrow> Q) \<longleftrightarrow> \<not> P \<or> Q"} \qquad\qquad
|
wenzelm@26849
|
811 |
@{prop "Ball A P \<equiv> \<forall>x. x \<in> A \<longrightarrow> P x"}
|
wenzelm@26849
|
812 |
\]
|
wenzelm@26849
|
813 |
|
wenzelm@26849
|
814 |
\end{itemize}
|
wenzelm@26849
|
815 |
|
wenzelm@26849
|
816 |
%FIXME: Example of an inductive definition
|
wenzelm@26849
|
817 |
*}
|
wenzelm@26849
|
818 |
|
wenzelm@26849
|
819 |
|
wenzelm@26849
|
820 |
section {* Arithmetic proof support *}
|
wenzelm@26849
|
821 |
|
wenzelm@26849
|
822 |
text {*
|
wenzelm@26849
|
823 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
824 |
@{method_def (HOL) arith} & : & @{text method} \\
|
nipkow@30863
|
825 |
@{attribute_def (HOL) arith} & : & @{text attribute} \\
|
wenzelm@28761
|
826 |
@{attribute_def (HOL) arith_split} & : & @{text attribute} \\
|
wenzelm@26849
|
827 |
\end{matharray}
|
wenzelm@26849
|
828 |
|
wenzelm@26849
|
829 |
The @{method (HOL) arith} method decides linear arithmetic problems
|
wenzelm@26849
|
830 |
(on types @{text nat}, @{text int}, @{text real}). Any current
|
wenzelm@26849
|
831 |
facts are inserted into the goal before running the procedure.
|
wenzelm@26849
|
832 |
|
nipkow@30863
|
833 |
The @{attribute (HOL) arith} attribute declares facts that are
|
nipkow@30863
|
834 |
always supplied to the arithmetic provers implicitly.
|
nipkow@30863
|
835 |
|
wenzelm@26894
|
836 |
The @{attribute (HOL) arith_split} attribute declares case split
|
wenzelm@30865
|
837 |
rules to be expanded before @{method (HOL) arith} is invoked.
|
wenzelm@26849
|
838 |
|
nipkow@30863
|
839 |
Note that a simpler (but faster) arithmetic prover is
|
nipkow@30863
|
840 |
already invoked by the Simplifier.
|
wenzelm@26849
|
841 |
*}
|
wenzelm@26849
|
842 |
|
wenzelm@26849
|
843 |
|
wenzelm@30169
|
844 |
section {* Intuitionistic proof search *}
|
wenzelm@30169
|
845 |
|
wenzelm@30169
|
846 |
text {*
|
wenzelm@30169
|
847 |
\begin{matharray}{rcl}
|
wenzelm@30171
|
848 |
@{method_def (HOL) iprover} & : & @{text method} \\
|
wenzelm@30169
|
849 |
\end{matharray}
|
wenzelm@30169
|
850 |
|
wenzelm@30169
|
851 |
\begin{rail}
|
wenzelm@35613
|
852 |
'iprover' ( rulemod * )
|
wenzelm@30169
|
853 |
;
|
wenzelm@30169
|
854 |
\end{rail}
|
wenzelm@30169
|
855 |
|
wenzelm@30171
|
856 |
The @{method (HOL) iprover} method performs intuitionistic proof
|
wenzelm@30171
|
857 |
search, depending on specifically declared rules from the context,
|
wenzelm@30171
|
858 |
or given as explicit arguments. Chained facts are inserted into the
|
wenzelm@35613
|
859 |
goal before commencing proof search.
|
wenzelm@35613
|
860 |
|
wenzelm@30169
|
861 |
Rules need to be classified as @{attribute (Pure) intro},
|
wenzelm@30169
|
862 |
@{attribute (Pure) elim}, or @{attribute (Pure) dest}; here the
|
wenzelm@30169
|
863 |
``@{text "!"}'' indicator refers to ``safe'' rules, which may be
|
wenzelm@30169
|
864 |
applied aggressively (without considering back-tracking later).
|
wenzelm@30169
|
865 |
Rules declared with ``@{text "?"}'' are ignored in proof search (the
|
wenzelm@30169
|
866 |
single-step @{method rule} method still observes these). An
|
wenzelm@30169
|
867 |
explicit weight annotation may be given as well; otherwise the
|
wenzelm@30169
|
868 |
number of rule premises will be taken into account here.
|
wenzelm@30169
|
869 |
*}
|
wenzelm@30169
|
870 |
|
wenzelm@30169
|
871 |
|
wenzelm@30171
|
872 |
section {* Coherent Logic *}
|
wenzelm@30171
|
873 |
|
wenzelm@30171
|
874 |
text {*
|
wenzelm@30171
|
875 |
\begin{matharray}{rcl}
|
wenzelm@30171
|
876 |
@{method_def (HOL) "coherent"} & : & @{text method} \\
|
wenzelm@30171
|
877 |
\end{matharray}
|
wenzelm@30171
|
878 |
|
wenzelm@30171
|
879 |
\begin{rail}
|
wenzelm@30171
|
880 |
'coherent' thmrefs?
|
wenzelm@30171
|
881 |
;
|
wenzelm@30171
|
882 |
\end{rail}
|
wenzelm@30171
|
883 |
|
wenzelm@30171
|
884 |
The @{method (HOL) coherent} method solves problems of
|
wenzelm@30171
|
885 |
\emph{Coherent Logic} \cite{Bezem-Coquand:2005}, which covers
|
wenzelm@30171
|
886 |
applications in confluence theory, lattice theory and projective
|
wenzelm@30171
|
887 |
geometry. See @{"file" "~~/src/HOL/ex/Coherent.thy"} for some
|
wenzelm@30171
|
888 |
examples.
|
wenzelm@30171
|
889 |
*}
|
wenzelm@30171
|
890 |
|
wenzelm@30171
|
891 |
|
haftmann@31906
|
892 |
section {* Checking and refuting propositions *}
|
haftmann@31906
|
893 |
|
haftmann@31906
|
894 |
text {*
|
haftmann@31906
|
895 |
Identifying incorrect propositions usually involves evaluation of
|
haftmann@31906
|
896 |
particular assignments and systematic counter example search. This
|
haftmann@31906
|
897 |
is supported by the following commands.
|
haftmann@31906
|
898 |
|
haftmann@31906
|
899 |
\begin{matharray}{rcl}
|
haftmann@31906
|
900 |
@{command_def (HOL) "value"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@31906
|
901 |
@{command_def (HOL) "quickcheck"}@{text "\<^sup>*"} & : & @{text "proof \<rightarrow>"} \\
|
haftmann@31906
|
902 |
@{command_def (HOL) "quickcheck_params"} & : & @{text "theory \<rightarrow> theory"}
|
haftmann@31906
|
903 |
\end{matharray}
|
haftmann@31906
|
904 |
|
haftmann@31906
|
905 |
\begin{rail}
|
haftmann@31906
|
906 |
'value' ( ( '[' name ']' ) ? ) modes? term
|
haftmann@31906
|
907 |
;
|
haftmann@31906
|
908 |
|
haftmann@31906
|
909 |
'quickcheck' ( ( '[' args ']' ) ? ) nat?
|
haftmann@31906
|
910 |
;
|
haftmann@31906
|
911 |
|
haftmann@31906
|
912 |
'quickcheck_params' ( ( '[' args ']' ) ? )
|
haftmann@31906
|
913 |
;
|
haftmann@31906
|
914 |
|
haftmann@31906
|
915 |
modes: '(' (name + ) ')'
|
haftmann@31906
|
916 |
;
|
haftmann@31906
|
917 |
|
haftmann@31906
|
918 |
args: ( name '=' value + ',' )
|
haftmann@31906
|
919 |
;
|
haftmann@31906
|
920 |
\end{rail}
|
haftmann@31906
|
921 |
|
haftmann@31906
|
922 |
\begin{description}
|
haftmann@31906
|
923 |
|
haftmann@31906
|
924 |
\item @{command (HOL) "value"}~@{text t} evaluates and prints a
|
haftmann@31906
|
925 |
term; optionally @{text modes} can be specified, which are
|
haftmann@31906
|
926 |
appended to the current print mode (see also \cite{isabelle-ref}).
|
haftmann@31906
|
927 |
Internally, the evaluation is performed by registered evaluators,
|
haftmann@31906
|
928 |
which are invoked sequentially until a result is returned.
|
haftmann@31906
|
929 |
Alternatively a specific evaluator can be selected using square
|
haftmann@37419
|
930 |
brackets; typical evaluators use the current set of code equations
|
haftmann@37419
|
931 |
to normalize and include @{text simp} for fully symbolic evaluation
|
haftmann@37419
|
932 |
using the simplifier, @{text nbe} for \emph{normalization by evaluation}
|
haftmann@37419
|
933 |
and \emph{code} for code generation in SML.
|
haftmann@31906
|
934 |
|
haftmann@31906
|
935 |
\item @{command (HOL) "quickcheck"} tests the current goal for
|
haftmann@31906
|
936 |
counter examples using a series of arbitrary assignments for its
|
haftmann@31906
|
937 |
free variables; by default the first subgoal is tested, an other
|
haftmann@31906
|
938 |
can be selected explicitly using an optional goal index.
|
haftmann@31906
|
939 |
A number of configuration options are supported for
|
haftmann@31906
|
940 |
@{command (HOL) "quickcheck"}, notably:
|
haftmann@31906
|
941 |
|
haftmann@31906
|
942 |
\begin{description}
|
haftmann@31906
|
943 |
|
wenzelm@40515
|
944 |
\item[@{text size}] specifies the maximum size of the search space
|
wenzelm@40515
|
945 |
for assignment values.
|
haftmann@31906
|
946 |
|
wenzelm@40515
|
947 |
\item[@{text iterations}] sets how many sets of assignments are
|
wenzelm@40515
|
948 |
generated for each particular size.
|
haftmann@31906
|
949 |
|
wenzelm@40515
|
950 |
\item[@{text no_assms}] specifies whether assumptions in
|
wenzelm@40515
|
951 |
structured proofs should be ignored.
|
blanchet@35331
|
952 |
|
wenzelm@40515
|
953 |
\item[@{text timeout}] sets the time limit in seconds.
|
bulwahn@40480
|
954 |
|
wenzelm@40515
|
955 |
\item[@{text default_type}] sets the type(s) generally used to
|
wenzelm@40515
|
956 |
instantiate type variables.
|
bulwahn@40480
|
957 |
|
wenzelm@40515
|
958 |
\item[@{text report}] if set quickcheck reports how many tests
|
wenzelm@40515
|
959 |
fulfilled the preconditions.
|
bulwahn@40480
|
960 |
|
wenzelm@40515
|
961 |
\item[@{text quiet}] if not set quickcheck informs about the
|
wenzelm@40515
|
962 |
current size for assignment values.
|
bulwahn@40480
|
963 |
|
wenzelm@40515
|
964 |
\item[@{text expect}] can be used to check if the user's
|
wenzelm@40515
|
965 |
expectation was met (@{text no_expectation}, @{text
|
wenzelm@40515
|
966 |
no_counterexample}, or @{text counterexample}).
|
bulwahn@40480
|
967 |
|
haftmann@31906
|
968 |
\end{description}
|
haftmann@31906
|
969 |
|
haftmann@31906
|
970 |
These option can be given within square brackets.
|
haftmann@31906
|
971 |
|
haftmann@31906
|
972 |
\item @{command (HOL) "quickcheck_params"} changes quickcheck
|
haftmann@31906
|
973 |
configuration options persitently.
|
haftmann@31906
|
974 |
|
haftmann@31906
|
975 |
\end{description}
|
haftmann@31906
|
976 |
*}
|
haftmann@31906
|
977 |
|
haftmann@31906
|
978 |
|
wenzelm@28752
|
979 |
section {* Unstructured case analysis and induction \label{sec:hol-induct-tac} *}
|
wenzelm@26849
|
980 |
|
wenzelm@26849
|
981 |
text {*
|
wenzelm@27123
|
982 |
The following tools of Isabelle/HOL support cases analysis and
|
wenzelm@27123
|
983 |
induction in unstructured tactic scripts; see also
|
wenzelm@27123
|
984 |
\secref{sec:cases-induct} for proper Isar versions of similar ideas.
|
wenzelm@26849
|
985 |
|
wenzelm@26849
|
986 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
987 |
@{method_def (HOL) case_tac}@{text "\<^sup>*"} & : & @{text method} \\
|
wenzelm@28761
|
988 |
@{method_def (HOL) induct_tac}@{text "\<^sup>*"} & : & @{text method} \\
|
wenzelm@28761
|
989 |
@{method_def (HOL) ind_cases}@{text "\<^sup>*"} & : & @{text method} \\
|
wenzelm@28761
|
990 |
@{command_def (HOL) "inductive_cases"}@{text "\<^sup>*"} & : & @{text "local_theory \<rightarrow> local_theory"} \\
|
wenzelm@26849
|
991 |
\end{matharray}
|
wenzelm@26849
|
992 |
|
wenzelm@26849
|
993 |
\begin{rail}
|
wenzelm@26849
|
994 |
'case\_tac' goalspec? term rule?
|
wenzelm@26849
|
995 |
;
|
wenzelm@26849
|
996 |
'induct\_tac' goalspec? (insts * 'and') rule?
|
wenzelm@26849
|
997 |
;
|
wenzelm@26849
|
998 |
'ind\_cases' (prop +) ('for' (name +)) ?
|
wenzelm@26849
|
999 |
;
|
wenzelm@26849
|
1000 |
'inductive\_cases' (thmdecl? (prop +) + 'and')
|
wenzelm@26849
|
1001 |
;
|
wenzelm@26849
|
1002 |
|
wenzelm@26849
|
1003 |
rule: ('rule' ':' thmref)
|
wenzelm@26849
|
1004 |
;
|
wenzelm@26849
|
1005 |
\end{rail}
|
wenzelm@26849
|
1006 |
|
wenzelm@28760
|
1007 |
\begin{description}
|
wenzelm@26849
|
1008 |
|
wenzelm@28760
|
1009 |
\item @{method (HOL) case_tac} and @{method (HOL) induct_tac} admit
|
wenzelm@28760
|
1010 |
to reason about inductive types. Rules are selected according to
|
wenzelm@28760
|
1011 |
the declarations by the @{attribute cases} and @{attribute induct}
|
wenzelm@28760
|
1012 |
attributes, cf.\ \secref{sec:cases-induct}. The @{command (HOL)
|
wenzelm@28760
|
1013 |
datatype} package already takes care of this.
|
wenzelm@27123
|
1014 |
|
wenzelm@27123
|
1015 |
These unstructured tactics feature both goal addressing and dynamic
|
wenzelm@26849
|
1016 |
instantiation. Note that named rule cases are \emph{not} provided
|
wenzelm@27123
|
1017 |
as would be by the proper @{method cases} and @{method induct} proof
|
wenzelm@27123
|
1018 |
methods (see \secref{sec:cases-induct}). Unlike the @{method
|
wenzelm@27123
|
1019 |
induct} method, @{method induct_tac} does not handle structured rule
|
wenzelm@27123
|
1020 |
statements, only the compact object-logic conclusion of the subgoal
|
wenzelm@27123
|
1021 |
being addressed.
|
wenzelm@26849
|
1022 |
|
wenzelm@28760
|
1023 |
\item @{method (HOL) ind_cases} and @{command (HOL)
|
wenzelm@28760
|
1024 |
"inductive_cases"} provide an interface to the internal @{ML_text
|
wenzelm@26860
|
1025 |
mk_cases} operation. Rules are simplified in an unrestricted
|
wenzelm@26860
|
1026 |
forward manner.
|
wenzelm@26849
|
1027 |
|
wenzelm@26849
|
1028 |
While @{method (HOL) ind_cases} is a proof method to apply the
|
wenzelm@26849
|
1029 |
result immediately as elimination rules, @{command (HOL)
|
wenzelm@26849
|
1030 |
"inductive_cases"} provides case split theorems at the theory level
|
wenzelm@26849
|
1031 |
for later use. The @{keyword "for"} argument of the @{method (HOL)
|
wenzelm@26849
|
1032 |
ind_cases} method allows to specify a list of variables that should
|
wenzelm@26849
|
1033 |
be generalized before applying the resulting rule.
|
wenzelm@26849
|
1034 |
|
wenzelm@28760
|
1035 |
\end{description}
|
wenzelm@26849
|
1036 |
*}
|
wenzelm@26849
|
1037 |
|
wenzelm@26849
|
1038 |
|
wenzelm@26849
|
1039 |
section {* Executable code *}
|
wenzelm@26849
|
1040 |
|
wenzelm@26849
|
1041 |
text {*
|
wenzelm@26849
|
1042 |
Isabelle/Pure provides two generic frameworks to support code
|
wenzelm@26849
|
1043 |
generation from executable specifications. Isabelle/HOL
|
wenzelm@26849
|
1044 |
instantiates these mechanisms in a way that is amenable to end-user
|
wenzelm@26849
|
1045 |
applications.
|
wenzelm@26849
|
1046 |
|
haftmann@37397
|
1047 |
\medskip One framework generates code from functional programs
|
haftmann@37397
|
1048 |
(including overloading using type classes) to SML \cite{SML}, OCaml
|
haftmann@39049
|
1049 |
\cite{OCaml}, Haskell \cite{haskell-revised-report} and Scala
|
haftmann@39049
|
1050 |
\cite{scala-overview-tech-report}.
|
haftmann@37397
|
1051 |
Conceptually, code generation is split up in three steps:
|
haftmann@37397
|
1052 |
\emph{selection} of code theorems, \emph{translation} into an
|
haftmann@37397
|
1053 |
abstract executable view and \emph{serialization} to a specific
|
haftmann@37397
|
1054 |
\emph{target language}. Inductive specifications can be executed
|
haftmann@37397
|
1055 |
using the predicate compiler which operates within HOL.
|
haftmann@37397
|
1056 |
See \cite{isabelle-codegen} for an introduction.
|
haftmann@37397
|
1057 |
|
haftmann@37397
|
1058 |
\begin{matharray}{rcl}
|
haftmann@37397
|
1059 |
@{command_def (HOL) "export_code"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1060 |
@{attribute_def (HOL) code} & : & @{text attribute} \\
|
haftmann@37397
|
1061 |
@{command_def (HOL) "code_abort"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1062 |
@{command_def (HOL) "code_datatype"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1063 |
@{command_def (HOL) "print_codesetup"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1064 |
@{attribute_def (HOL) code_inline} & : & @{text attribute} \\
|
haftmann@37397
|
1065 |
@{attribute_def (HOL) code_post} & : & @{text attribute} \\
|
haftmann@37397
|
1066 |
@{command_def (HOL) "print_codeproc"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1067 |
@{command_def (HOL) "code_thms"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1068 |
@{command_def (HOL) "code_deps"}@{text "\<^sup>*"} & : & @{text "context \<rightarrow>"} \\
|
haftmann@37397
|
1069 |
@{command_def (HOL) "code_const"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1070 |
@{command_def (HOL) "code_type"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1071 |
@{command_def (HOL) "code_class"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1072 |
@{command_def (HOL) "code_instance"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1073 |
@{command_def (HOL) "code_reserved"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1074 |
@{command_def (HOL) "code_monad"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1075 |
@{command_def (HOL) "code_include"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@37397
|
1076 |
@{command_def (HOL) "code_modulename"} & : & @{text "theory \<rightarrow> theory"} \\
|
haftmann@39832
|
1077 |
@{command_def (HOL) "code_reflect"} & : & @{text "theory \<rightarrow> theory"}
|
haftmann@37397
|
1078 |
\end{matharray}
|
haftmann@37397
|
1079 |
|
haftmann@37397
|
1080 |
\begin{rail}
|
haftmann@37820
|
1081 |
'export\_code' ( constexpr + ) \\
|
haftmann@37820
|
1082 |
( ( 'in' target ( 'module\_name' string ) ? \\
|
haftmann@37820
|
1083 |
( 'file' ( string | '-' ) ) ? ( '(' args ')' ) ?) + ) ?
|
haftmann@37397
|
1084 |
;
|
haftmann@37397
|
1085 |
|
haftmann@37397
|
1086 |
const: term
|
haftmann@37397
|
1087 |
;
|
haftmann@37397
|
1088 |
|
haftmann@37397
|
1089 |
constexpr: ( const | 'name.*' | '*' )
|
haftmann@37397
|
1090 |
;
|
haftmann@37397
|
1091 |
|
haftmann@37397
|
1092 |
typeconstructor: nameref
|
haftmann@37397
|
1093 |
;
|
haftmann@37397
|
1094 |
|
haftmann@37397
|
1095 |
class: nameref
|
haftmann@37397
|
1096 |
;
|
haftmann@37397
|
1097 |
|
haftmann@39049
|
1098 |
target: 'SML' | 'OCaml' | 'Haskell' | 'Scala'
|
haftmann@37397
|
1099 |
;
|
haftmann@37397
|
1100 |
|
haftmann@38706
|
1101 |
'code' ( 'del' | 'abstype' | 'abstract' ) ?
|
haftmann@37397
|
1102 |
;
|
haftmann@37397
|
1103 |
|
haftmann@37397
|
1104 |
'code\_abort' ( const + )
|
haftmann@37397
|
1105 |
;
|
haftmann@37397
|
1106 |
|
haftmann@37397
|
1107 |
'code\_datatype' ( const + )
|
haftmann@37397
|
1108 |
;
|
haftmann@37397
|
1109 |
|
haftmann@37397
|
1110 |
'code_inline' ( 'del' ) ?
|
haftmann@37397
|
1111 |
;
|
haftmann@37397
|
1112 |
|
haftmann@37397
|
1113 |
'code_post' ( 'del' ) ?
|
haftmann@37397
|
1114 |
;
|
haftmann@37397
|
1115 |
|
haftmann@37397
|
1116 |
'code\_thms' ( constexpr + ) ?
|
haftmann@37397
|
1117 |
;
|
haftmann@37397
|
1118 |
|
haftmann@37397
|
1119 |
'code\_deps' ( constexpr + ) ?
|
haftmann@37397
|
1120 |
;
|
haftmann@37397
|
1121 |
|
haftmann@37397
|
1122 |
'code\_const' (const + 'and') \\
|
haftmann@37397
|
1123 |
( ( '(' target ( syntax ? + 'and' ) ')' ) + )
|
haftmann@37397
|
1124 |
;
|
haftmann@37397
|
1125 |
|
haftmann@37397
|
1126 |
'code\_type' (typeconstructor + 'and') \\
|
haftmann@37397
|
1127 |
( ( '(' target ( syntax ? + 'and' ) ')' ) + )
|
haftmann@37397
|
1128 |
;
|
haftmann@37397
|
1129 |
|
haftmann@37397
|
1130 |
'code\_class' (class + 'and') \\
|
haftmann@37397
|
1131 |
( ( '(' target \\ ( string ? + 'and' ) ')' ) + )
|
haftmann@37397
|
1132 |
;
|
haftmann@37397
|
1133 |
|
haftmann@37397
|
1134 |
'code\_instance' (( typeconstructor '::' class ) + 'and') \\
|
haftmann@37397
|
1135 |
( ( '(' target ( '-' ? + 'and' ) ')' ) + )
|
haftmann@37397
|
1136 |
;
|
haftmann@37397
|
1137 |
|
haftmann@37397
|
1138 |
'code\_reserved' target ( string + )
|
haftmann@37397
|
1139 |
;
|
haftmann@37397
|
1140 |
|
haftmann@37397
|
1141 |
'code\_monad' const const target
|
haftmann@37397
|
1142 |
;
|
haftmann@37397
|
1143 |
|
haftmann@37397
|
1144 |
'code\_include' target ( string ( string | '-') )
|
haftmann@37397
|
1145 |
;
|
haftmann@37397
|
1146 |
|
haftmann@37397
|
1147 |
'code\_modulename' target ( ( string string ) + )
|
haftmann@37397
|
1148 |
;
|
haftmann@37397
|
1149 |
|
haftmann@39832
|
1150 |
'code\_reflect' string ( 'datatypes' ( string '=' ( string + '|' ) + 'and' ) ) ? \\
|
haftmann@39832
|
1151 |
( 'functions' ( string + ) ) ? ( 'file' string ) ?
|
haftmann@39832
|
1152 |
;
|
haftmann@39832
|
1153 |
|
haftmann@37397
|
1154 |
syntax: string | ( 'infix' | 'infixl' | 'infixr' ) nat string
|
haftmann@37397
|
1155 |
;
|
haftmann@37397
|
1156 |
|
haftmann@37397
|
1157 |
\end{rail}
|
haftmann@37397
|
1158 |
|
haftmann@37397
|
1159 |
\begin{description}
|
haftmann@37397
|
1160 |
|
haftmann@37397
|
1161 |
\item @{command (HOL) "export_code"} generates code for a given list
|
haftmann@39832
|
1162 |
of constants in the specified target language(s). If no
|
haftmann@39832
|
1163 |
serialization instruction is given, only abstract code is generated
|
haftmann@39832
|
1164 |
internally.
|
haftmann@37397
|
1165 |
|
haftmann@37397
|
1166 |
Constants may be specified by giving them literally, referring to
|
haftmann@37397
|
1167 |
all executable contants within a certain theory by giving @{text
|
haftmann@37397
|
1168 |
"name.*"}, or referring to \emph{all} executable constants currently
|
haftmann@37397
|
1169 |
available by giving @{text "*"}.
|
haftmann@37397
|
1170 |
|
haftmann@37397
|
1171 |
By default, for each involved theory one corresponding name space
|
haftmann@37397
|
1172 |
module is generated. Alternativly, a module name may be specified
|
haftmann@37397
|
1173 |
after the @{keyword "module_name"} keyword; then \emph{all} code is
|
haftmann@37397
|
1174 |
placed in this module.
|
haftmann@37397
|
1175 |
|
haftmann@39832
|
1176 |
For \emph{SML}, \emph{OCaml} and \emph{Scala} the file specification
|
haftmann@39832
|
1177 |
refers to a single file; for \emph{Haskell}, it refers to a whole
|
haftmann@39832
|
1178 |
directory, where code is generated in multiple files reflecting the
|
haftmann@39832
|
1179 |
module hierarchy. Omitting the file specification denotes standard
|
haftmann@37748
|
1180 |
output.
|
haftmann@37397
|
1181 |
|
haftmann@37397
|
1182 |
Serializers take an optional list of arguments in parentheses. For
|
haftmann@37397
|
1183 |
\emph{SML} and \emph{OCaml}, ``@{text no_signatures}`` omits
|
haftmann@37397
|
1184 |
explicit module signatures.
|
haftmann@37397
|
1185 |
|
haftmann@39832
|
1186 |
For \emph{Haskell} a module name prefix may be given using the
|
haftmann@39832
|
1187 |
``@{text "root:"}'' argument; ``@{text string_classes}'' adds a
|
haftmann@39832
|
1188 |
``@{verbatim "deriving (Read, Show)"}'' clause to each appropriate
|
haftmann@39832
|
1189 |
datatype declaration.
|
haftmann@37397
|
1190 |
|
haftmann@37397
|
1191 |
\item @{attribute (HOL) code} explicitly selects (or with option
|
haftmann@38706
|
1192 |
``@{text "del"}'' deselects) a code equation for code generation.
|
haftmann@38706
|
1193 |
Usually packages introducing code equations provide a reasonable
|
haftmann@38706
|
1194 |
default setup for selection. Variants @{text "code abstype"} and
|
haftmann@38706
|
1195 |
@{text "code abstract"} declare abstract datatype certificates or
|
haftmann@38706
|
1196 |
code equations on abstract datatype representations respectively.
|
haftmann@37397
|
1197 |
|
haftmann@37397
|
1198 |
\item @{command (HOL) "code_abort"} declares constants which are not
|
haftmann@39832
|
1199 |
required to have a definition by means of code equations; if needed
|
haftmann@39832
|
1200 |
these are implemented by program abort instead.
|
haftmann@37397
|
1201 |
|
haftmann@37397
|
1202 |
\item @{command (HOL) "code_datatype"} specifies a constructor set
|
haftmann@37397
|
1203 |
for a logical type.
|
haftmann@37397
|
1204 |
|
haftmann@37397
|
1205 |
\item @{command (HOL) "print_codesetup"} gives an overview on
|
haftmann@37397
|
1206 |
selected code equations and code generator datatypes.
|
haftmann@37397
|
1207 |
|
haftmann@39832
|
1208 |
\item @{attribute (HOL) code_inline} declares (or with option
|
haftmann@39832
|
1209 |
``@{text "del"}'' removes) inlining theorems which are applied as
|
haftmann@39832
|
1210 |
rewrite rules to any code equation during preprocessing.
|
haftmann@37397
|
1211 |
|
haftmann@39832
|
1212 |
\item @{attribute (HOL) code_post} declares (or with option ``@{text
|
haftmann@39832
|
1213 |
"del"}'' removes) theorems which are applied as rewrite rules to any
|
haftmann@39832
|
1214 |
result of an evaluation.
|
haftmann@37397
|
1215 |
|
haftmann@39832
|
1216 |
\item @{command (HOL) "print_codeproc"} prints the setup of the code
|
haftmann@39832
|
1217 |
generator preprocessor.
|
haftmann@37397
|
1218 |
|
haftmann@37397
|
1219 |
\item @{command (HOL) "code_thms"} prints a list of theorems
|
haftmann@37397
|
1220 |
representing the corresponding program containing all given
|
haftmann@37397
|
1221 |
constants after preprocessing.
|
haftmann@37397
|
1222 |
|
haftmann@37397
|
1223 |
\item @{command (HOL) "code_deps"} visualizes dependencies of
|
haftmann@37397
|
1224 |
theorems representing the corresponding program containing all given
|
haftmann@37397
|
1225 |
constants after preprocessing.
|
haftmann@37397
|
1226 |
|
haftmann@37397
|
1227 |
\item @{command (HOL) "code_const"} associates a list of constants
|
haftmann@37397
|
1228 |
with target-specific serializations; omitting a serialization
|
haftmann@37397
|
1229 |
deletes an existing serialization.
|
haftmann@37397
|
1230 |
|
haftmann@37397
|
1231 |
\item @{command (HOL) "code_type"} associates a list of type
|
haftmann@37397
|
1232 |
constructors with target-specific serializations; omitting a
|
haftmann@37397
|
1233 |
serialization deletes an existing serialization.
|
haftmann@37397
|
1234 |
|
haftmann@37397
|
1235 |
\item @{command (HOL) "code_class"} associates a list of classes
|
haftmann@37397
|
1236 |
with target-specific class names; omitting a serialization deletes
|
haftmann@37397
|
1237 |
an existing serialization. This applies only to \emph{Haskell}.
|
haftmann@37397
|
1238 |
|
haftmann@37397
|
1239 |
\item @{command (HOL) "code_instance"} declares a list of type
|
haftmann@37397
|
1240 |
constructor / class instance relations as ``already present'' for a
|
haftmann@37397
|
1241 |
given target. Omitting a ``@{text "-"}'' deletes an existing
|
haftmann@37397
|
1242 |
``already present'' declaration. This applies only to
|
haftmann@37397
|
1243 |
\emph{Haskell}.
|
haftmann@37397
|
1244 |
|
haftmann@37397
|
1245 |
\item @{command (HOL) "code_reserved"} declares a list of names as
|
haftmann@37397
|
1246 |
reserved for a given target, preventing it to be shadowed by any
|
haftmann@37397
|
1247 |
generated code.
|
haftmann@37397
|
1248 |
|
haftmann@37397
|
1249 |
\item @{command (HOL) "code_monad"} provides an auxiliary mechanism
|
haftmann@37397
|
1250 |
to generate monadic code for Haskell.
|
haftmann@37397
|
1251 |
|
haftmann@37397
|
1252 |
\item @{command (HOL) "code_include"} adds arbitrary named content
|
haftmann@37397
|
1253 |
(``include'') to generated code. A ``@{text "-"}'' as last argument
|
haftmann@37397
|
1254 |
will remove an already added ``include''.
|
haftmann@37397
|
1255 |
|
haftmann@37397
|
1256 |
\item @{command (HOL) "code_modulename"} declares aliasings from one
|
haftmann@37397
|
1257 |
module name onto another.
|
haftmann@37397
|
1258 |
|
haftmann@39832
|
1259 |
\item @{command (HOL) "code_reflect"} without a ``@{text "file"}''
|
haftmann@39832
|
1260 |
argument compiles code into the system runtime environment and
|
haftmann@39832
|
1261 |
modifies the code generator setup that future invocations of system
|
haftmann@39832
|
1262 |
runtime code generation referring to one of the ``@{text
|
haftmann@39832
|
1263 |
"datatypes"}'' or ``@{text "functions"}'' entities use these precompiled
|
haftmann@39832
|
1264 |
entities. With a ``@{text "file"}'' argument, the corresponding code
|
haftmann@39832
|
1265 |
is generated into that specified file without modifying the code
|
haftmann@39832
|
1266 |
generator setup.
|
haftmann@39832
|
1267 |
|
haftmann@37397
|
1268 |
\end{description}
|
haftmann@37397
|
1269 |
|
haftmann@39832
|
1270 |
The other framework generates code from both functional and
|
haftmann@39832
|
1271 |
relational programs to SML. See \cite{isabelle-HOL} for further
|
haftmann@39832
|
1272 |
information (this actually covers the new-style theory format as
|
haftmann@39832
|
1273 |
well).
|
wenzelm@26849
|
1274 |
|
wenzelm@26849
|
1275 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
1276 |
@{command_def (HOL) "code_module"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@28761
|
1277 |
@{command_def (HOL) "code_library"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@28761
|
1278 |
@{command_def (HOL) "consts_code"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@28761
|
1279 |
@{command_def (HOL) "types_code"} & : & @{text "theory \<rightarrow> theory"} \\
|
wenzelm@28761
|
1280 |
@{attribute_def (HOL) code} & : & @{text attribute} \\
|
wenzelm@26849
|
1281 |
\end{matharray}
|
wenzelm@26849
|
1282 |
|
wenzelm@26849
|
1283 |
\begin{rail}
|
wenzelm@26849
|
1284 |
( 'code\_module' | 'code\_library' ) modespec ? name ? \\
|
wenzelm@26849
|
1285 |
( 'file' name ) ? ( 'imports' ( name + ) ) ? \\
|
wenzelm@26849
|
1286 |
'contains' ( ( name '=' term ) + | term + )
|
wenzelm@26849
|
1287 |
;
|
wenzelm@26849
|
1288 |
|
wenzelm@26849
|
1289 |
modespec: '(' ( name * ) ')'
|
wenzelm@26849
|
1290 |
;
|
wenzelm@26849
|
1291 |
|
wenzelm@26849
|
1292 |
'consts\_code' (codespec +)
|
wenzelm@26849
|
1293 |
;
|
wenzelm@26849
|
1294 |
|
wenzelm@26849
|
1295 |
codespec: const template attachment ?
|
wenzelm@26849
|
1296 |
;
|
wenzelm@26849
|
1297 |
|
wenzelm@26849
|
1298 |
'types\_code' (tycodespec +)
|
wenzelm@26849
|
1299 |
;
|
wenzelm@26849
|
1300 |
|
wenzelm@26849
|
1301 |
tycodespec: name template attachment ?
|
wenzelm@26849
|
1302 |
;
|
wenzelm@26849
|
1303 |
|
wenzelm@26849
|
1304 |
const: term
|
wenzelm@26849
|
1305 |
;
|
wenzelm@26849
|
1306 |
|
wenzelm@26849
|
1307 |
template: '(' string ')'
|
wenzelm@26849
|
1308 |
;
|
wenzelm@26849
|
1309 |
|
wenzelm@26849
|
1310 |
attachment: 'attach' modespec ? verblbrace text verbrbrace
|
wenzelm@26849
|
1311 |
;
|
wenzelm@26849
|
1312 |
|
wenzelm@26849
|
1313 |
'code' (name)?
|
wenzelm@26849
|
1314 |
;
|
wenzelm@26849
|
1315 |
\end{rail}
|
wenzelm@26849
|
1316 |
|
wenzelm@26849
|
1317 |
*}
|
wenzelm@26849
|
1318 |
|
wenzelm@27045
|
1319 |
|
wenzelm@27045
|
1320 |
section {* Definition by specification \label{sec:hol-specification} *}
|
wenzelm@27045
|
1321 |
|
wenzelm@27045
|
1322 |
text {*
|
wenzelm@27045
|
1323 |
\begin{matharray}{rcl}
|
wenzelm@28761
|
1324 |
@{command_def (HOL) "specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@28761
|
1325 |
@{command_def (HOL) "ax_specification"} & : & @{text "theory \<rightarrow> proof(prove)"} \\
|
wenzelm@27045
|
1326 |
\end{matharray}
|
wenzelm@27045
|
1327 |
|
wenzelm@27045
|
1328 |
\begin{rail}
|
wenzelm@27045
|
1329 |
('specification' | 'ax\_specification') '(' (decl +) ')' \\ (thmdecl? prop +)
|
wenzelm@27045
|
1330 |
;
|
wenzelm@27045
|
1331 |
decl: ((name ':')? term '(' 'overloaded' ')'?)
|
wenzelm@27045
|
1332 |
\end{rail}
|
wenzelm@27045
|
1333 |
|
wenzelm@28760
|
1334 |
\begin{description}
|
wenzelm@27045
|
1335 |
|
wenzelm@28760
|
1336 |
\item @{command (HOL) "specification"}~@{text "decls \<phi>"} sets up a
|
wenzelm@27045
|
1337 |
goal stating the existence of terms with the properties specified to
|
wenzelm@27045
|
1338 |
hold for the constants given in @{text decls}. After finishing the
|
wenzelm@27045
|
1339 |
proof, the theory will be augmented with definitions for the given
|
wenzelm@27045
|
1340 |
constants, as well as with theorems stating the properties for these
|
wenzelm@27045
|
1341 |
constants.
|
wenzelm@27045
|
1342 |
|
wenzelm@28760
|
1343 |
\item @{command (HOL) "ax_specification"}~@{text "decls \<phi>"} sets up
|
wenzelm@28760
|
1344 |
a goal stating the existence of terms with the properties specified
|
wenzelm@28760
|
1345 |
to hold for the constants given in @{text decls}. After finishing
|
wenzelm@28760
|
1346 |
the proof, the theory will be augmented with axioms expressing the
|
wenzelm@28760
|
1347 |
properties given in the first place.
|
wenzelm@27045
|
1348 |
|
wenzelm@28760
|
1349 |
\item @{text decl} declares a constant to be defined by the
|
wenzelm@27045
|
1350 |
specification given. The definition for the constant @{text c} is
|
wenzelm@27045
|
1351 |
bound to the name @{text c_def} unless a theorem name is given in
|
wenzelm@27045
|
1352 |
the declaration. Overloaded constants should be declared as such.
|
wenzelm@27045
|
1353 |
|
wenzelm@28760
|
1354 |
\end{description}
|
wenzelm@27045
|
1355 |
|
wenzelm@27045
|
1356 |
Whether to use @{command (HOL) "specification"} or @{command (HOL)
|
wenzelm@27045
|
1357 |
"ax_specification"} is to some extent a matter of style. @{command
|
wenzelm@27045
|
1358 |
(HOL) "specification"} introduces no new axioms, and so by
|
wenzelm@27045
|
1359 |
construction cannot introduce inconsistencies, whereas @{command
|
wenzelm@27045
|
1360 |
(HOL) "ax_specification"} does introduce axioms, but only after the
|
wenzelm@27045
|
1361 |
user has explicitly proven it to be safe. A practical issue must be
|
wenzelm@27045
|
1362 |
considered, though: After introducing two constants with the same
|
wenzelm@27045
|
1363 |
properties using @{command (HOL) "specification"}, one can prove
|
wenzelm@27045
|
1364 |
that the two constants are, in fact, equal. If this might be a
|
wenzelm@27045
|
1365 |
problem, one should use @{command (HOL) "ax_specification"}.
|
wenzelm@27045
|
1366 |
*}
|
wenzelm@27045
|
1367 |
|
wenzelm@26840
|
1368 |
end
|