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