src/Doc/Codegen/Further.thy
author haftmann
Fri Jul 04 20:18:47 2014 +0200 (2014-07-04)
changeset 57512 cc97b347b301
parent 55757 9fc71814b8c1
child 58620 7435b6a3f72e
permissions -rw-r--r--
reduced name variants for assoc and commute on plus and mult
haftmann@28213
     1
theory Further
haftmann@28213
     2
imports Setup
haftmann@28213
     3
begin
haftmann@28213
     4
haftmann@28447
     5
section {* Further issues \label{sec:further} *}
haftmann@28419
     6
haftmann@42096
     7
subsection {* Specialities of the @{text Scala} target language \label{sec:scala} *}
haftmann@42096
     8
haftmann@42096
     9
text {*
haftmann@42096
    10
  @{text Scala} deviates from languages of the ML family in a couple
haftmann@42096
    11
  of aspects; those which affect code generation mainly have to do with
haftmann@42096
    12
  @{text Scala}'s type system:
haftmann@42096
    13
haftmann@42096
    14
  \begin{itemize}
haftmann@42096
    15
haftmann@42096
    16
    \item @{text Scala} prefers tupled syntax over curried syntax.
haftmann@42096
    17
haftmann@42096
    18
    \item @{text Scala} sacrifices Hindely-Milner type inference for a
haftmann@42096
    19
      much more rich type system with subtyping etc.  For this reason
haftmann@42096
    20
      type arguments sometimes have to be given explicitly in square
haftmann@46520
    21
      brackets (mimicking System F syntax).
haftmann@42096
    22
haftmann@42096
    23
    \item In contrast to @{text Haskell} where most specialities of
haftmann@42096
    24
      the type system are implemented using \emph{type classes},
haftmann@42096
    25
      @{text Scala} provides a sophisticated system of \emph{implicit
haftmann@42096
    26
      arguments}.
haftmann@42096
    27
haftmann@42096
    28
  \end{itemize}
haftmann@42096
    29
haftmann@42096
    30
  \noindent Concerning currying, the @{text Scala} serializer counts
haftmann@42096
    31
  arguments in code equations to determine how many arguments
haftmann@42096
    32
  shall be tupled; remaining arguments and abstractions in terms
haftmann@42096
    33
  rather than function definitions are always curried.
haftmann@42096
    34
haftmann@42096
    35
  The second aspect affects user-defined adaptations with @{command
haftmann@55372
    36
  code_printing}.  For regular terms, the @{text Scala} serializer prints
haftmann@42096
    37
  all type arguments explicitly.  For user-defined term adaptations
haftmann@42096
    38
  this is only possible for adaptations which take no arguments: here
haftmann@42096
    39
  the type arguments are just appended.  Otherwise they are ignored;
haftmann@42096
    40
  hence user-defined adaptations for polymorphic constants have to be
haftmann@42096
    41
  designed very carefully to avoid ambiguity.
haftmann@42096
    42
haftmann@42096
    43
  Isabelle's type classes are mapped onto @{text Scala} implicits; in
haftmann@42096
    44
  cases with diamonds in the subclass hierarchy this can lead to
haftmann@42096
    45
  ambiguities in the generated code:
haftmann@42096
    46
*}
haftmann@42096
    47
haftmann@42096
    48
class %quote class1 =
haftmann@42096
    49
  fixes foo :: "'a \<Rightarrow> 'a"
haftmann@42096
    50
haftmann@42096
    51
class %quote class2 = class1
haftmann@42096
    52
haftmann@42096
    53
class %quote class3 = class1
haftmann@42096
    54
haftmann@42096
    55
text {*
haftmann@42096
    56
  \noindent Here both @{class class2} and @{class class3} inherit from @{class class1},
haftmann@42096
    57
  forming the upper part of a diamond.
haftmann@42096
    58
*}
haftmann@42096
    59
haftmann@42096
    60
definition %quote bar :: "'a :: {class2, class3} \<Rightarrow> 'a" where
haftmann@42096
    61
  "bar = foo"
haftmann@42096
    62
haftmann@42096
    63
text {*
haftmann@42096
    64
  \noindent This yields the following code:
haftmann@42096
    65
*}
haftmann@42096
    66
haftmann@42096
    67
text %quotetypewriter {*
haftmann@42096
    68
  @{code_stmts bar (Scala)}
haftmann@42096
    69
*}
haftmann@42096
    70
haftmann@42096
    71
text {*
haftmann@42096
    72
  \noindent This code is rejected by the @{text Scala} compiler: in
haftmann@42096
    73
  the definition of @{text bar}, it is not clear from where to derive
haftmann@42096
    74
  the implicit argument for @{text foo}.
haftmann@42096
    75
haftmann@42096
    76
  The solution to the problem is to close the diamond by a further
haftmann@42096
    77
  class with inherits from both @{class class2} and @{class class3}:
haftmann@42096
    78
*}
haftmann@42096
    79
haftmann@42096
    80
class %quote class4 = class2 + class3
haftmann@42096
    81
haftmann@42096
    82
text {*
haftmann@42096
    83
  \noindent Then the offending code equation can be restricted to
haftmann@42096
    84
  @{class class4}:
haftmann@42096
    85
*}
haftmann@42096
    86
haftmann@42096
    87
lemma %quote [code]:
haftmann@42096
    88
  "(bar :: 'a::class4 \<Rightarrow> 'a) = foo"
haftmann@42096
    89
  by (simp only: bar_def)
haftmann@42096
    90
haftmann@42096
    91
text {*
haftmann@42096
    92
  \noindent with the following code:
haftmann@42096
    93
*}
haftmann@42096
    94
haftmann@42096
    95
text %quotetypewriter {*
haftmann@42096
    96
  @{code_stmts bar (Scala)}
haftmann@42096
    97
*}
haftmann@42096
    98
haftmann@42096
    99
text {*
haftmann@42096
   100
  \noindent which exposes no ambiguity.
haftmann@42096
   101
haftmann@42096
   102
  Since the preprocessor (cf.~\secref{sec:preproc}) propagates sort
haftmann@42096
   103
  constraints through a system of code equations, it is usually not
haftmann@42096
   104
  very difficult to identify the set of code equations which actually
haftmann@42096
   105
  needs more restricted sort constraints.
haftmann@42096
   106
*}
haftmann@42096
   107
haftmann@38437
   108
subsection {* Modules namespace *}
haftmann@28419
   109
haftmann@28419
   110
text {*
haftmann@40752
   111
  When invoking the @{command export_code} command it is possible to
haftmann@40752
   112
  leave out the @{keyword "module_name"} part; then code is
haftmann@40752
   113
  distributed over different modules, where the module name space
haftmann@40752
   114
  roughly is induced by the Isabelle theory name space.
haftmann@38437
   115
haftmann@40752
   116
  Then sometimes the awkward situation occurs that dependencies
haftmann@40752
   117
  between definitions introduce cyclic dependencies between modules,
haftmann@40752
   118
  which in the @{text Haskell} world leaves you to the mercy of the
haftmann@40752
   119
  @{text Haskell} implementation you are using, while for @{text
haftmann@40752
   120
  SML}/@{text OCaml} code generation is not possible.
haftmann@38437
   121
haftmann@40752
   122
  A solution is to declare module names explicitly.  Let use assume
haftmann@40752
   123
  the three cyclically dependent modules are named \emph{A}, \emph{B}
haftmann@40752
   124
  and \emph{C}.  Then, by stating
haftmann@38437
   125
*}
haftmann@38437
   126
haftmann@52378
   127
code_identifier %quote
haftmann@52378
   128
  code_module A \<rightharpoonup> (SML) ABC
haftmann@52378
   129
| code_module B \<rightharpoonup> (SML) ABC
haftmann@52378
   130
| code_module C \<rightharpoonup> (SML) ABC
haftmann@38437
   131
haftmann@40752
   132
text {*
haftmann@40752
   133
  \noindent we explicitly map all those modules on \emph{ABC},
haftmann@40752
   134
  resulting in an ad-hoc merge of this three modules at serialisation
haftmann@40752
   135
  time.
haftmann@28419
   136
*}
haftmann@28419
   137
haftmann@37426
   138
subsection {* Locales and interpretation *}
haftmann@37426
   139
haftmann@37426
   140
text {*
haftmann@37426
   141
  A technical issue comes to surface when generating code from
haftmann@37426
   142
  specifications stemming from locale interpretation.
haftmann@37426
   143
haftmann@40752
   144
  Let us assume a locale specifying a power operation on arbitrary
haftmann@40752
   145
  types:
haftmann@37426
   146
*}
haftmann@37426
   147
haftmann@37426
   148
locale %quote power =
haftmann@37426
   149
  fixes power :: "'a \<Rightarrow> 'b \<Rightarrow> 'b"
haftmann@37426
   150
  assumes power_commute: "power x \<circ> power y = power y \<circ> power x"
haftmann@37426
   151
begin
haftmann@37426
   152
haftmann@37426
   153
text {*
haftmann@40752
   154
  \noindent Inside that locale we can lift @{text power} to exponent
haftmann@40752
   155
  lists by means of specification relative to that locale:
haftmann@37426
   156
*}
haftmann@37426
   157
haftmann@37426
   158
primrec %quote powers :: "'a list \<Rightarrow> 'b \<Rightarrow> 'b" where
haftmann@37426
   159
  "powers [] = id"
haftmann@37426
   160
| "powers (x # xs) = power x \<circ> powers xs"
haftmann@37426
   161
haftmann@37426
   162
lemma %quote powers_append:
haftmann@37426
   163
  "powers (xs @ ys) = powers xs \<circ> powers ys"
haftmann@37426
   164
  by (induct xs) simp_all
haftmann@37426
   165
haftmann@37426
   166
lemma %quote powers_power:
haftmann@37426
   167
  "powers xs \<circ> power x = power x \<circ> powers xs"
haftmann@37426
   168
  by (induct xs)
haftmann@49739
   169
    (simp_all del: o_apply id_apply add: comp_assoc,
haftmann@37426
   170
      simp del: o_apply add: o_assoc power_commute)
haftmann@37426
   171
haftmann@37426
   172
lemma %quote powers_rev:
haftmann@37426
   173
  "powers (rev xs) = powers xs"
haftmann@37426
   174
    by (induct xs) (simp_all add: powers_append powers_power)
haftmann@37426
   175
haftmann@37426
   176
end %quote
haftmann@37426
   177
haftmann@37426
   178
text {*
haftmann@38505
   179
  After an interpretation of this locale (say, @{command_def
haftmann@40752
   180
  interpretation} @{text "fun_power:"} @{term [source] "power (\<lambda>n (f
haftmann@40752
   181
  :: 'a \<Rightarrow> 'a). f ^^ n)"}), one would expect to have a constant @{text
haftmann@37426
   182
  "fun_power.powers :: nat list \<Rightarrow> ('a \<Rightarrow> 'a) \<Rightarrow> 'a \<Rightarrow> 'a"} for which code
haftmann@37426
   183
  can be generated.  But this not the case: internally, the term
haftmann@37426
   184
  @{text "fun_power.powers"} is an abbreviation for the foundational
haftmann@37426
   185
  term @{term [source] "power.powers (\<lambda>n (f :: 'a \<Rightarrow> 'a). f ^^ n)"}
haftmann@37426
   186
  (see \cite{isabelle-locale} for the details behind).
haftmann@37426
   187
haftmann@40752
   188
  Fortunately, with minor effort the desired behaviour can be
haftmann@40752
   189
  achieved.  First, a dedicated definition of the constant on which
haftmann@40752
   190
  the local @{text "powers"} after interpretation is supposed to be
haftmann@40752
   191
  mapped on:
haftmann@37426
   192
*}
haftmann@37426
   193
haftmann@37426
   194
definition %quote funpows :: "nat list \<Rightarrow> ('a \<Rightarrow> 'a) \<Rightarrow> 'a \<Rightarrow> 'a" where
haftmann@37426
   195
  [code del]: "funpows = power.powers (\<lambda>n f. f ^^ n)"
haftmann@37426
   196
haftmann@37426
   197
text {*
haftmann@40752
   198
  \noindent In general, the pattern is @{text "c = t"} where @{text c}
haftmann@40752
   199
  is the name of the future constant and @{text t} the foundational
haftmann@40752
   200
  term corresponding to the local constant after interpretation.
haftmann@37426
   201
haftmann@37426
   202
  The interpretation itself is enriched with an equation @{text "t = c"}:
haftmann@37426
   203
*}
haftmann@37426
   204
haftmann@37426
   205
interpretation %quote fun_power: power "\<lambda>n (f :: 'a \<Rightarrow> 'a). f ^^ n" where
haftmann@37426
   206
  "power.powers (\<lambda>n f. f ^^ n) = funpows"
haftmann@37426
   207
  by unfold_locales
haftmann@57512
   208
    (simp_all add: fun_eq_iff funpow_mult mult.commute funpows_def)
haftmann@37426
   209
haftmann@37426
   210
text {*
haftmann@40752
   211
  \noindent This additional equation is trivially proved by the
haftmann@40752
   212
  definition itself.
haftmann@37426
   213
haftmann@37426
   214
  After this setup procedure, code generation can continue as usual:
haftmann@37426
   215
*}
haftmann@37426
   216
haftmann@39745
   217
text %quotetypewriter {*
haftmann@39683
   218
  @{code_stmts funpows (consts) Nat.funpow funpows (Haskell)}
haftmann@39664
   219
*}
haftmann@37426
   220
haftmann@37426
   221
haftmann@51172
   222
subsection {* Parallel computation *}
haftmann@51172
   223
haftmann@51172
   224
text {*
wenzelm@52665
   225
  Theory @{text Parallel} in @{file "~~/src/HOL/Library"} contains
haftmann@51172
   226
  operations to exploit parallelism inside the Isabelle/ML
haftmann@51172
   227
  runtime engine.
haftmann@51172
   228
*}
haftmann@51172
   229
haftmann@38437
   230
subsection {* Imperative data structures *}
haftmann@28419
   231
haftmann@28419
   232
text {*
haftmann@38437
   233
  If you consider imperative data structures as inevitable for a
haftmann@38437
   234
  specific application, you should consider \emph{Imperative
haftmann@38437
   235
  Functional Programming with Isabelle/HOL}
haftmann@38437
   236
  \cite{bulwahn-et-al:2008:imperative}; the framework described there
haftmann@40752
   237
  is available in session @{text Imperative_HOL}, together with a
haftmann@40752
   238
  short primer document.
haftmann@28419
   239
*}
haftmann@28419
   240
haftmann@28213
   241
haftmann@38405
   242
subsection {* ML system interfaces \label{sec:ml} *}
haftmann@38405
   243
haftmann@38405
   244
text {*
haftmann@38510
   245
  Since the code generator framework not only aims to provide a nice
haftmann@38510
   246
  Isar interface but also to form a base for code-generation-based
haftmann@38510
   247
  applications, here a short description of the most fundamental ML
haftmann@38510
   248
  interfaces.
haftmann@38405
   249
*}
haftmann@38405
   250
haftmann@38405
   251
subsubsection {* Managing executable content *}
haftmann@38405
   252
haftmann@38405
   253
text %mlref {*
haftmann@38405
   254
  \begin{mldecls}
haftmann@38510
   255
  @{index_ML Code.read_const: "theory -> string -> string"} \\
haftmann@38405
   256
  @{index_ML Code.add_eqn: "thm -> theory -> theory"} \\
haftmann@38405
   257
  @{index_ML Code.del_eqn: "thm -> theory -> theory"} \\
wenzelm@51717
   258
  @{index_ML Code_Preproc.map_pre: "(Proof.context -> Proof.context) -> theory -> theory"} \\
wenzelm@51717
   259
  @{index_ML Code_Preproc.map_post: "(Proof.context -> Proof.context) -> theory -> theory"} \\
haftmann@38507
   260
  @{index_ML Code_Preproc.add_functrans: "
haftmann@55757
   261
    string * (Proof.context -> (thm * bool) list -> (thm * bool) list option)
haftmann@38507
   262
      -> theory -> theory"} \\
haftmann@38405
   263
  @{index_ML Code_Preproc.del_functrans: "string -> theory -> theory"} \\
haftmann@38405
   264
  @{index_ML Code.add_datatype: "(string * typ) list -> theory -> theory"} \\
haftmann@38405
   265
  @{index_ML Code.get_type: "theory -> string
haftmann@40752
   266
    -> ((string * sort) list * (string * ((string * sort) list * typ list)) list) * bool"} \\
haftmann@38405
   267
  @{index_ML Code.get_type_of_constr_or_abstr: "theory -> string -> (string * bool) option"}
haftmann@38405
   268
  \end{mldecls}
haftmann@38405
   269
haftmann@38405
   270
  \begin{description}
haftmann@38405
   271
haftmann@38510
   272
  \item @{ML Code.read_const}~@{text thy}~@{text s}
haftmann@38510
   273
     reads a constant as a concrete term expression @{text s}.
haftmann@38510
   274
haftmann@38405
   275
  \item @{ML Code.add_eqn}~@{text "thm"}~@{text "thy"} adds function
haftmann@38405
   276
     theorem @{text "thm"} to executable content.
haftmann@38405
   277
haftmann@38405
   278
  \item @{ML Code.del_eqn}~@{text "thm"}~@{text "thy"} removes function
haftmann@38405
   279
     theorem @{text "thm"} from executable content, if present.
haftmann@38405
   280
haftmann@38405
   281
  \item @{ML Code_Preproc.map_pre}~@{text "f"}~@{text "thy"} changes
haftmann@38405
   282
     the preprocessor simpset.
haftmann@38405
   283
haftmann@38405
   284
  \item @{ML Code_Preproc.add_functrans}~@{text "(name, f)"}~@{text "thy"} adds
haftmann@38405
   285
     function transformer @{text f} (named @{text name}) to executable content;
haftmann@38405
   286
     @{text f} is a transformer of the code equations belonging
haftmann@38405
   287
     to a certain function definition, depending on the
haftmann@38405
   288
     current theory context.  Returning @{text NONE} indicates that no
haftmann@38405
   289
     transformation took place;  otherwise, the whole process will be iterated
haftmann@38405
   290
     with the new code equations.
haftmann@38405
   291
haftmann@38405
   292
  \item @{ML Code_Preproc.del_functrans}~@{text "name"}~@{text "thy"} removes
haftmann@38405
   293
     function transformer named @{text name} from executable content.
haftmann@38405
   294
haftmann@38405
   295
  \item @{ML Code.add_datatype}~@{text cs}~@{text thy} adds
haftmann@38405
   296
     a datatype to executable content, with generation
haftmann@38405
   297
     set @{text cs}.
haftmann@38405
   298
haftmann@38405
   299
  \item @{ML Code.get_type_of_constr_or_abstr}~@{text "thy"}~@{text "const"}
haftmann@38405
   300
     returns type constructor corresponding to
haftmann@38405
   301
     constructor @{text const}; returns @{text NONE}
haftmann@38405
   302
     if @{text const} is no constructor.
haftmann@38405
   303
haftmann@38405
   304
  \end{description}
haftmann@38405
   305
*}
haftmann@38405
   306
haftmann@38405
   307
haftmann@38405
   308
subsubsection {* Data depending on the theory's executable content *}
haftmann@38405
   309
haftmann@38405
   310
text {*
haftmann@40752
   311
  Implementing code generator applications on top of the framework set
haftmann@40752
   312
  out so far usually not only involves using those primitive
haftmann@40752
   313
  interfaces but also storing code-dependent data and various other
haftmann@40752
   314
  things.
haftmann@38405
   315
haftmann@40752
   316
  Due to incrementality of code generation, changes in the theory's
haftmann@40752
   317
  executable content have to be propagated in a certain fashion.
haftmann@40752
   318
  Additionally, such changes may occur not only during theory
haftmann@40752
   319
  extension but also during theory merge, which is a little bit nasty
haftmann@40752
   320
  from an implementation point of view.  The framework provides a
haftmann@40752
   321
  solution to this technical challenge by providing a functorial data
haftmann@40752
   322
  slot @{ML_functor Code_Data}; on instantiation of this functor, the
haftmann@40752
   323
  following types and operations are required:
haftmann@38405
   324
haftmann@38405
   325
  \medskip
haftmann@38405
   326
  \begin{tabular}{l}
haftmann@38405
   327
  @{text "type T"} \\
haftmann@38405
   328
  @{text "val empty: T"} \\
haftmann@38405
   329
  \end{tabular}
haftmann@38405
   330
haftmann@38405
   331
  \begin{description}
haftmann@38405
   332
haftmann@38405
   333
  \item @{text T} the type of data to store.
haftmann@38405
   334
haftmann@38405
   335
  \item @{text empty} initial (empty) data.
haftmann@38405
   336
haftmann@38405
   337
  \end{description}
haftmann@38405
   338
haftmann@40752
   339
  \noindent An instance of @{ML_functor Code_Data} provides the
haftmann@40752
   340
  following interface:
haftmann@38405
   341
haftmann@38405
   342
  \medskip
haftmann@38405
   343
  \begin{tabular}{l}
haftmann@38405
   344
  @{text "change: theory \<rightarrow> (T \<rightarrow> T) \<rightarrow> T"} \\
haftmann@38405
   345
  @{text "change_yield: theory \<rightarrow> (T \<rightarrow> 'a * T) \<rightarrow> 'a * T"}
haftmann@38405
   346
  \end{tabular}
haftmann@38405
   347
haftmann@38405
   348
  \begin{description}
haftmann@38405
   349
haftmann@40752
   350
  \item @{text change} update of current data (cached!) by giving a
haftmann@40752
   351
    continuation.
haftmann@38405
   352
haftmann@38405
   353
  \item @{text change_yield} update with side result.
haftmann@38405
   354
haftmann@38405
   355
  \end{description}
haftmann@38405
   356
*}
haftmann@38405
   357
haftmann@28213
   358
end
haftmann@46514
   359