28213
|
1 |
theory Further
|
|
2 |
imports Setup
|
|
3 |
begin
|
|
4 |
|
28447
|
5 |
section {* Further issues \label{sec:further} *}
|
28419
|
6 |
|
38437
|
7 |
subsection {* Modules namespace *}
|
28419
|
8 |
|
|
9 |
text {*
|
38437
|
10 |
When invoking the @{command export_code} command it is possible to leave
|
|
11 |
out the @{keyword "module_name"} part; then code is distributed over
|
|
12 |
different modules, where the module name space roughly is induced
|
|
13 |
by the Isabelle theory name space.
|
|
14 |
|
|
15 |
Then sometimes the awkward situation occurs that dependencies between
|
|
16 |
definitions introduce cyclic dependencies between modules, which in the
|
|
17 |
@{text Haskell} world leaves you to the mercy of the @{text Haskell} implementation
|
|
18 |
you are using, while for @{text SML}/@{text OCaml} code generation is not possible.
|
|
19 |
|
|
20 |
A solution is to declare module names explicitly.
|
|
21 |
Let use assume the three cyclically dependent
|
|
22 |
modules are named \emph{A}, \emph{B} and \emph{C}.
|
|
23 |
Then, by stating
|
|
24 |
*}
|
|
25 |
|
|
26 |
code_modulename %quote SML
|
|
27 |
A ABC
|
|
28 |
B ABC
|
|
29 |
C ABC
|
|
30 |
|
|
31 |
text {*\noindent
|
|
32 |
we explicitly map all those modules on \emph{ABC},
|
|
33 |
resulting in an ad-hoc merge of this three modules
|
|
34 |
at serialisation time.
|
28419
|
35 |
*}
|
|
36 |
|
37426
|
37 |
subsection {* Locales and interpretation *}
|
|
38 |
|
|
39 |
text {*
|
|
40 |
A technical issue comes to surface when generating code from
|
|
41 |
specifications stemming from locale interpretation.
|
|
42 |
|
|
43 |
Let us assume a locale specifying a power operation
|
|
44 |
on arbitrary types:
|
|
45 |
*}
|
|
46 |
|
|
47 |
locale %quote power =
|
|
48 |
fixes power :: "'a \<Rightarrow> 'b \<Rightarrow> 'b"
|
|
49 |
assumes power_commute: "power x \<circ> power y = power y \<circ> power x"
|
|
50 |
begin
|
|
51 |
|
|
52 |
text {*
|
|
53 |
\noindent Inside that locale we can lift @{text power} to exponent lists
|
|
54 |
by means of specification relative to that locale:
|
|
55 |
*}
|
|
56 |
|
|
57 |
primrec %quote powers :: "'a list \<Rightarrow> 'b \<Rightarrow> 'b" where
|
|
58 |
"powers [] = id"
|
|
59 |
| "powers (x # xs) = power x \<circ> powers xs"
|
|
60 |
|
|
61 |
lemma %quote powers_append:
|
|
62 |
"powers (xs @ ys) = powers xs \<circ> powers ys"
|
|
63 |
by (induct xs) simp_all
|
|
64 |
|
|
65 |
lemma %quote powers_power:
|
|
66 |
"powers xs \<circ> power x = power x \<circ> powers xs"
|
|
67 |
by (induct xs)
|
|
68 |
(simp_all del: o_apply id_apply add: o_assoc [symmetric],
|
|
69 |
simp del: o_apply add: o_assoc power_commute)
|
|
70 |
|
|
71 |
lemma %quote powers_rev:
|
|
72 |
"powers (rev xs) = powers xs"
|
|
73 |
by (induct xs) (simp_all add: powers_append powers_power)
|
|
74 |
|
|
75 |
end %quote
|
|
76 |
|
|
77 |
text {*
|
38505
|
78 |
After an interpretation of this locale (say, @{command_def
|
37426
|
79 |
interpretation} @{text "fun_power:"} @{term [source] "power (\<lambda>n (f ::
|
|
80 |
'a \<Rightarrow> 'a). f ^^ n)"}), one would expect to have a constant @{text
|
|
81 |
"fun_power.powers :: nat list \<Rightarrow> ('a \<Rightarrow> 'a) \<Rightarrow> 'a \<Rightarrow> 'a"} for which code
|
|
82 |
can be generated. But this not the case: internally, the term
|
|
83 |
@{text "fun_power.powers"} is an abbreviation for the foundational
|
|
84 |
term @{term [source] "power.powers (\<lambda>n (f :: 'a \<Rightarrow> 'a). f ^^ n)"}
|
|
85 |
(see \cite{isabelle-locale} for the details behind).
|
|
86 |
|
37836
|
87 |
Fortunately, with minor effort the desired behaviour can be achieved.
|
37426
|
88 |
First, a dedicated definition of the constant on which the local @{text "powers"}
|
|
89 |
after interpretation is supposed to be mapped on:
|
|
90 |
*}
|
|
91 |
|
|
92 |
definition %quote funpows :: "nat list \<Rightarrow> ('a \<Rightarrow> 'a) \<Rightarrow> 'a \<Rightarrow> 'a" where
|
|
93 |
[code del]: "funpows = power.powers (\<lambda>n f. f ^^ n)"
|
|
94 |
|
|
95 |
text {*
|
|
96 |
\noindent In general, the pattern is @{text "c = t"} where @{text c} is
|
|
97 |
the name of the future constant and @{text t} the foundational term
|
|
98 |
corresponding to the local constant after interpretation.
|
|
99 |
|
|
100 |
The interpretation itself is enriched with an equation @{text "t = c"}:
|
|
101 |
*}
|
|
102 |
|
|
103 |
interpretation %quote fun_power: power "\<lambda>n (f :: 'a \<Rightarrow> 'a). f ^^ n" where
|
|
104 |
"power.powers (\<lambda>n f. f ^^ n) = funpows"
|
|
105 |
by unfold_locales
|
37432
|
106 |
(simp_all add: expand_fun_eq funpow_mult mult_commute funpows_def)
|
37426
|
107 |
|
|
108 |
text {*
|
|
109 |
\noindent This additional equation is trivially proved by the definition
|
|
110 |
itself.
|
|
111 |
|
|
112 |
After this setup procedure, code generation can continue as usual:
|
|
113 |
*}
|
|
114 |
|
|
115 |
text %quote {*@{code_stmts funpows (consts) Nat.funpow funpows (Haskell)}*}
|
|
116 |
|
|
117 |
|
38437
|
118 |
subsection {* Imperative data structures *}
|
28419
|
119 |
|
|
120 |
text {*
|
38437
|
121 |
If you consider imperative data structures as inevitable for a
|
|
122 |
specific application, you should consider \emph{Imperative
|
|
123 |
Functional Programming with Isabelle/HOL}
|
|
124 |
\cite{bulwahn-et-al:2008:imperative}; the framework described there
|
|
125 |
is available in session @{theory Imperative_HOL}.
|
28419
|
126 |
*}
|
|
127 |
|
28213
|
128 |
|
|
129 |
subsection {* Evaluation oracle *}
|
|
130 |
|
28593
|
131 |
text {*
|
|
132 |
Code generation may also be used to \emph{evaluate} expressions
|
|
133 |
(using @{text SML} as target language of course).
|
38505
|
134 |
For instance, the @{command_def value} reduces an expression to a
|
28593
|
135 |
normal form with respect to the underlying code equations:
|
|
136 |
*}
|
|
137 |
|
|
138 |
value %quote "42 / (12 :: rat)"
|
|
139 |
|
|
140 |
text {*
|
|
141 |
\noindent will display @{term "7 / (2 :: rat)"}.
|
|
142 |
|
|
143 |
The @{method eval} method tries to reduce a goal by code generation to @{term True}
|
|
144 |
and solves it in that case, but fails otherwise:
|
|
145 |
*}
|
|
146 |
|
|
147 |
lemma %quote "42 / (12 :: rat) = 7 / 2"
|
|
148 |
by %quote eval
|
|
149 |
|
|
150 |
text {*
|
|
151 |
\noindent The soundness of the @{method eval} method depends crucially
|
|
152 |
on the correctness of the code generator; this is one of the reasons
|
31050
|
153 |
why you should not use adaptation (see \secref{sec:adaptation}) frivolously.
|
28593
|
154 |
*}
|
|
155 |
|
38437
|
156 |
|
|
157 |
subsection {* Building evaluators *}
|
|
158 |
|
|
159 |
text {*
|
|
160 |
FIXME
|
|
161 |
*}
|
|
162 |
|
|
163 |
subsubsection {* Code antiquotation *}
|
28213
|
164 |
|
28593
|
165 |
text {*
|
|
166 |
In scenarios involving techniques like reflection it is quite common
|
|
167 |
that code generated from a theory forms the basis for implementing
|
|
168 |
a proof procedure in @{text SML}. To facilitate interfacing of generated code
|
|
169 |
with system code, the code generator provides a @{text code} antiquotation:
|
|
170 |
*}
|
|
171 |
|
30880
|
172 |
datatype %quote form = T | F | And form form | Or form form (*<*)
|
|
173 |
|
|
174 |
(*>*) ML %quotett {*
|
28593
|
175 |
fun eval_form @{code T} = true
|
|
176 |
| eval_form @{code F} = false
|
|
177 |
| eval_form (@{code And} (p, q)) =
|
|
178 |
eval_form p andalso eval_form q
|
|
179 |
| eval_form (@{code Or} (p, q)) =
|
|
180 |
eval_form p orelse eval_form q;
|
|
181 |
*}
|
|
182 |
|
|
183 |
text {*
|
|
184 |
\noindent @{text code} takes as argument the name of a constant; after the
|
|
185 |
whole @{text SML} is read, the necessary code is generated transparently
|
|
186 |
and the corresponding constant names are inserted. This technique also
|
|
187 |
allows to use pattern matching on constructors stemming from compiled
|
37210
|
188 |
@{text "datatypes"}.
|
28593
|
189 |
|
29796
|
190 |
For a less simplistic example, theory @{theory Ferrack} is
|
28593
|
191 |
a good reference.
|
|
192 |
*}
|
28213
|
193 |
|
38405
|
194 |
|
|
195 |
subsection {* ML system interfaces \label{sec:ml} *}
|
|
196 |
|
|
197 |
text {*
|
|
198 |
Since the code generator framework not only aims to provide
|
|
199 |
a nice Isar interface but also to form a base for
|
|
200 |
code-generation-based applications, here a short
|
|
201 |
description of the most important ML interfaces.
|
|
202 |
*}
|
|
203 |
|
|
204 |
subsubsection {* Managing executable content *}
|
|
205 |
|
|
206 |
text %mlref {*
|
|
207 |
\begin{mldecls}
|
|
208 |
@{index_ML Code.add_eqn: "thm -> theory -> theory"} \\
|
|
209 |
@{index_ML Code.del_eqn: "thm -> theory -> theory"} \\
|
|
210 |
@{index_ML Code_Preproc.map_pre: "(simpset -> simpset) -> theory -> theory"} \\
|
|
211 |
@{index_ML Code_Preproc.map_post: "(simpset -> simpset) -> theory -> theory"} \\
|
|
212 |
@{index_ML Code_Preproc.add_functrans: "string * (theory -> (thm * bool) list -> (thm * bool) list option)
|
|
213 |
-> theory -> theory"} \\
|
|
214 |
@{index_ML Code_Preproc.del_functrans: "string -> theory -> theory"} \\
|
|
215 |
@{index_ML Code.add_datatype: "(string * typ) list -> theory -> theory"} \\
|
|
216 |
@{index_ML Code.get_type: "theory -> string
|
|
217 |
-> (string * sort) list * ((string * string list) * typ list) list"} \\
|
|
218 |
@{index_ML Code.get_type_of_constr_or_abstr: "theory -> string -> (string * bool) option"}
|
|
219 |
\end{mldecls}
|
|
220 |
|
|
221 |
\begin{description}
|
|
222 |
|
|
223 |
\item @{ML Code.add_eqn}~@{text "thm"}~@{text "thy"} adds function
|
|
224 |
theorem @{text "thm"} to executable content.
|
|
225 |
|
|
226 |
\item @{ML Code.del_eqn}~@{text "thm"}~@{text "thy"} removes function
|
|
227 |
theorem @{text "thm"} from executable content, if present.
|
|
228 |
|
|
229 |
\item @{ML Code_Preproc.map_pre}~@{text "f"}~@{text "thy"} changes
|
|
230 |
the preprocessor simpset.
|
|
231 |
|
|
232 |
\item @{ML Code_Preproc.add_functrans}~@{text "(name, f)"}~@{text "thy"} adds
|
|
233 |
function transformer @{text f} (named @{text name}) to executable content;
|
|
234 |
@{text f} is a transformer of the code equations belonging
|
|
235 |
to a certain function definition, depending on the
|
|
236 |
current theory context. Returning @{text NONE} indicates that no
|
|
237 |
transformation took place; otherwise, the whole process will be iterated
|
|
238 |
with the new code equations.
|
|
239 |
|
|
240 |
\item @{ML Code_Preproc.del_functrans}~@{text "name"}~@{text "thy"} removes
|
|
241 |
function transformer named @{text name} from executable content.
|
|
242 |
|
|
243 |
\item @{ML Code.add_datatype}~@{text cs}~@{text thy} adds
|
|
244 |
a datatype to executable content, with generation
|
|
245 |
set @{text cs}.
|
|
246 |
|
|
247 |
\item @{ML Code.get_type_of_constr_or_abstr}~@{text "thy"}~@{text "const"}
|
|
248 |
returns type constructor corresponding to
|
|
249 |
constructor @{text const}; returns @{text NONE}
|
|
250 |
if @{text const} is no constructor.
|
|
251 |
|
|
252 |
\end{description}
|
|
253 |
*}
|
|
254 |
|
|
255 |
subsubsection {* Auxiliary *}
|
|
256 |
|
|
257 |
text %mlref {*
|
|
258 |
\begin{mldecls}
|
|
259 |
@{index_ML Code.read_const: "theory -> string -> string"}
|
|
260 |
\end{mldecls}
|
|
261 |
|
|
262 |
\begin{description}
|
|
263 |
|
|
264 |
\item @{ML Code.read_const}~@{text thy}~@{text s}
|
|
265 |
reads a constant as a concrete term expression @{text s}.
|
|
266 |
|
|
267 |
\end{description}
|
|
268 |
|
|
269 |
*}
|
|
270 |
|
|
271 |
subsubsection {* Data depending on the theory's executable content *}
|
|
272 |
|
|
273 |
text {*
|
|
274 |
Implementing code generator applications on top
|
|
275 |
of the framework set out so far usually not only
|
|
276 |
involves using those primitive interfaces
|
|
277 |
but also storing code-dependent data and various
|
|
278 |
other things.
|
|
279 |
|
|
280 |
Due to incrementality of code generation, changes in the
|
|
281 |
theory's executable content have to be propagated in a
|
|
282 |
certain fashion. Additionally, such changes may occur
|
|
283 |
not only during theory extension but also during theory
|
|
284 |
merge, which is a little bit nasty from an implementation
|
|
285 |
point of view. The framework provides a solution
|
|
286 |
to this technical challenge by providing a functorial
|
|
287 |
data slot @{ML_functor Code_Data}; on instantiation
|
|
288 |
of this functor, the following types and operations
|
|
289 |
are required:
|
|
290 |
|
|
291 |
\medskip
|
|
292 |
\begin{tabular}{l}
|
|
293 |
@{text "type T"} \\
|
|
294 |
@{text "val empty: T"} \\
|
|
295 |
\end{tabular}
|
|
296 |
|
|
297 |
\begin{description}
|
|
298 |
|
|
299 |
\item @{text T} the type of data to store.
|
|
300 |
|
|
301 |
\item @{text empty} initial (empty) data.
|
|
302 |
|
|
303 |
\end{description}
|
|
304 |
|
|
305 |
\noindent An instance of @{ML_functor Code_Data} provides the following
|
|
306 |
interface:
|
|
307 |
|
|
308 |
\medskip
|
|
309 |
\begin{tabular}{l}
|
|
310 |
@{text "change: theory \<rightarrow> (T \<rightarrow> T) \<rightarrow> T"} \\
|
|
311 |
@{text "change_yield: theory \<rightarrow> (T \<rightarrow> 'a * T) \<rightarrow> 'a * T"}
|
|
312 |
\end{tabular}
|
|
313 |
|
|
314 |
\begin{description}
|
|
315 |
|
|
316 |
\item @{text change} update of current data (cached!)
|
|
317 |
by giving a continuation.
|
|
318 |
|
|
319 |
\item @{text change_yield} update with side result.
|
|
320 |
|
|
321 |
\end{description}
|
|
322 |
*}
|
|
323 |
|
28213
|
324 |
end
|