author | haftmann |
Thu, 23 Sep 2010 15:46:17 +0200 | |
changeset 39664 | 0afaf89ab591 |
parent 39559 | e7d4923b9b1c |
child 39683 | f75a01ee6c41 |
permissions | -rw-r--r-- |
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 |
|
39559 | 106 |
(simp_all add: fun_eq_iff 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 |
||
39664
0afaf89ab591
more canonical type setting of type writer code examples
haftmann
parents:
39559
diff
changeset
|
115 |
text %quote {* |
0afaf89ab591
more canonical type setting of type writer code examples
haftmann
parents:
39559
diff
changeset
|
116 |
\begin{typewriter} |
0afaf89ab591
more canonical type setting of type writer code examples
haftmann
parents:
39559
diff
changeset
|
117 |
@{code_stmts funpows (consts) Nat.funpow funpows (Haskell)} |
0afaf89ab591
more canonical type setting of type writer code examples
haftmann
parents:
39559
diff
changeset
|
118 |
\end{typewriter} |
0afaf89ab591
more canonical type setting of type writer code examples
haftmann
parents:
39559
diff
changeset
|
119 |
*} |
37426 | 120 |
|
121 |
||
38437 | 122 |
subsection {* Imperative data structures *} |
28419 | 123 |
|
124 |
text {* |
|
38437 | 125 |
If you consider imperative data structures as inevitable for a |
126 |
specific application, you should consider \emph{Imperative |
|
127 |
Functional Programming with Isabelle/HOL} |
|
128 |
\cite{bulwahn-et-al:2008:imperative}; the framework described there |
|
39064 | 129 |
is available in session @{text Imperative_HOL}. |
28419 | 130 |
*} |
131 |
||
28213 | 132 |
|
38405 | 133 |
subsection {* ML system interfaces \label{sec:ml} *} |
134 |
||
135 |
text {* |
|
38510 | 136 |
Since the code generator framework not only aims to provide a nice |
137 |
Isar interface but also to form a base for code-generation-based |
|
138 |
applications, here a short description of the most fundamental ML |
|
139 |
interfaces. |
|
38405 | 140 |
*} |
141 |
||
142 |
subsubsection {* Managing executable content *} |
|
143 |
||
144 |
text %mlref {* |
|
145 |
\begin{mldecls} |
|
38510 | 146 |
@{index_ML Code.read_const: "theory -> string -> string"} \\ |
38405 | 147 |
@{index_ML Code.add_eqn: "thm -> theory -> theory"} \\ |
148 |
@{index_ML Code.del_eqn: "thm -> theory -> theory"} \\ |
|
149 |
@{index_ML Code_Preproc.map_pre: "(simpset -> simpset) -> theory -> theory"} \\ |
|
150 |
@{index_ML Code_Preproc.map_post: "(simpset -> simpset) -> theory -> theory"} \\ |
|
38507 | 151 |
@{index_ML Code_Preproc.add_functrans: " |
152 |
string * (theory -> (thm * bool) list -> (thm * bool) list option) |
|
153 |
-> theory -> theory"} \\ |
|
38405 | 154 |
@{index_ML Code_Preproc.del_functrans: "string -> theory -> theory"} \\ |
155 |
@{index_ML Code.add_datatype: "(string * typ) list -> theory -> theory"} \\ |
|
156 |
@{index_ML Code.get_type: "theory -> string |
|
157 |
-> (string * sort) list * ((string * string list) * typ list) list"} \\ |
|
158 |
@{index_ML Code.get_type_of_constr_or_abstr: "theory -> string -> (string * bool) option"} |
|
159 |
\end{mldecls} |
|
160 |
||
161 |
\begin{description} |
|
162 |
||
38510 | 163 |
\item @{ML Code.read_const}~@{text thy}~@{text s} |
164 |
reads a constant as a concrete term expression @{text s}. |
|
165 |
||
38405 | 166 |
\item @{ML Code.add_eqn}~@{text "thm"}~@{text "thy"} adds function |
167 |
theorem @{text "thm"} to executable content. |
|
168 |
||
169 |
\item @{ML Code.del_eqn}~@{text "thm"}~@{text "thy"} removes function |
|
170 |
theorem @{text "thm"} from executable content, if present. |
|
171 |
||
172 |
\item @{ML Code_Preproc.map_pre}~@{text "f"}~@{text "thy"} changes |
|
173 |
the preprocessor simpset. |
|
174 |
||
175 |
\item @{ML Code_Preproc.add_functrans}~@{text "(name, f)"}~@{text "thy"} adds |
|
176 |
function transformer @{text f} (named @{text name}) to executable content; |
|
177 |
@{text f} is a transformer of the code equations belonging |
|
178 |
to a certain function definition, depending on the |
|
179 |
current theory context. Returning @{text NONE} indicates that no |
|
180 |
transformation took place; otherwise, the whole process will be iterated |
|
181 |
with the new code equations. |
|
182 |
||
183 |
\item @{ML Code_Preproc.del_functrans}~@{text "name"}~@{text "thy"} removes |
|
184 |
function transformer named @{text name} from executable content. |
|
185 |
||
186 |
\item @{ML Code.add_datatype}~@{text cs}~@{text thy} adds |
|
187 |
a datatype to executable content, with generation |
|
188 |
set @{text cs}. |
|
189 |
||
190 |
\item @{ML Code.get_type_of_constr_or_abstr}~@{text "thy"}~@{text "const"} |
|
191 |
returns type constructor corresponding to |
|
192 |
constructor @{text const}; returns @{text NONE} |
|
193 |
if @{text const} is no constructor. |
|
194 |
||
195 |
\end{description} |
|
196 |
*} |
|
197 |
||
198 |
||
199 |
subsubsection {* Data depending on the theory's executable content *} |
|
200 |
||
201 |
text {* |
|
202 |
Implementing code generator applications on top |
|
203 |
of the framework set out so far usually not only |
|
204 |
involves using those primitive interfaces |
|
205 |
but also storing code-dependent data and various |
|
206 |
other things. |
|
207 |
||
208 |
Due to incrementality of code generation, changes in the |
|
209 |
theory's executable content have to be propagated in a |
|
210 |
certain fashion. Additionally, such changes may occur |
|
211 |
not only during theory extension but also during theory |
|
212 |
merge, which is a little bit nasty from an implementation |
|
213 |
point of view. The framework provides a solution |
|
214 |
to this technical challenge by providing a functorial |
|
215 |
data slot @{ML_functor Code_Data}; on instantiation |
|
216 |
of this functor, the following types and operations |
|
217 |
are required: |
|
218 |
||
219 |
\medskip |
|
220 |
\begin{tabular}{l} |
|
221 |
@{text "type T"} \\ |
|
222 |
@{text "val empty: T"} \\ |
|
223 |
\end{tabular} |
|
224 |
||
225 |
\begin{description} |
|
226 |
||
227 |
\item @{text T} the type of data to store. |
|
228 |
||
229 |
\item @{text empty} initial (empty) data. |
|
230 |
||
231 |
\end{description} |
|
232 |
||
233 |
\noindent An instance of @{ML_functor Code_Data} provides the following |
|
234 |
interface: |
|
235 |
||
236 |
\medskip |
|
237 |
\begin{tabular}{l} |
|
238 |
@{text "change: theory \<rightarrow> (T \<rightarrow> T) \<rightarrow> T"} \\ |
|
239 |
@{text "change_yield: theory \<rightarrow> (T \<rightarrow> 'a * T) \<rightarrow> 'a * T"} |
|
240 |
\end{tabular} |
|
241 |
||
242 |
\begin{description} |
|
243 |
||
244 |
\item @{text change} update of current data (cached!) |
|
245 |
by giving a continuation. |
|
246 |
||
247 |
\item @{text change_yield} update with side result. |
|
248 |
||
249 |
\end{description} |
|
250 |
*} |
|
251 |
||
28213 | 252 |
end |