--- a/CookBook/Recipes/Antiquotes.thy Tue Nov 25 05:19:27 2008 +0000
+++ b/CookBook/Recipes/Antiquotes.thy Fri Nov 28 05:19:55 2008 +0100
@@ -8,31 +8,32 @@
text {*
{\bf Problem:}
- How to keep ML-code included in a document in sync with the actual code.\smallskip
+ How to keep your ML-code inside a document synchronised with the actual code?\smallskip
{\bf Solution:} This can be achieved using document antiquotations.\smallskip
- Document antiquotations are a convenient method for type-setting consitently
- a group of items in a document. They can also be used for sophisticated
- \LaTeX hacking.
+ Document antiquotations can be used for ensuring consistent type-setting of
+ various entities in a document. They can also be used for sophisticated
+ \LaTeX-hacking.
- Below we give the code for two such
- antiquotations that can be used to typeset ML-code and also to check whether
- the code is actually compiles. In this way one can relatively easily
- keep documents in sync with code.
+ Below we give the code for two antiquotations that can be used to typeset
+ ML-code and also to check whether the given code actually compiles. This
+ provides a sanity check for the code and also allows one to keep documents
+ in sync with other code, for example Isabelle.
- We first describe the antiquotation @{text "@{ML_checked \"\<dots>\"}"} which
- takes a piece of code as argument. This code is checked by sending
- the ML-expression @{text "val _ = \<dots>"} containing the given code to the
- ML-compiler (i.e.~the function @{ML "ML_Context.eval_in"}). The code
- for this antiquotation is as follows:
+ We first describe the antiquotation @{text "@{ML_checked \"\<dots>\"}"}. This
+ antiquotation takes a piece of code as argument; this code is then checked
+ by sending the ML-expression @{text [quotes] "val _ = \<dots>"} containing the
+ given code to the ML-compiler (i.e.~the function @{ML "ML_Context.eval_in"}
+ in the snippet below). The code for @{text "@{ML_checked \"\<dots>\"}"} is as
+ follows:
+
*}
-ML {*
-fun ml_val txt = "val _ = " ^ txt
+ML %linenumbers {*fun ml_val txt = "val _ = " ^ txt
fun output_ml ml src ctxt txt =
- (ML_Context.eval_in (SOME ctxt) false Position.none (ml txt);
+ (ML_Context.eval_in (SOME ctxt) false Position.none (ml txt);
ThyOutput.output_list (fn _ => fn s => Pretty.str s) src ctxt
(space_explode "\n" txt))
@@ -41,22 +42,25 @@
*}
text {*
-
- Note that the parser @{ML "(Scan.lift Args.name)"} parses a string. If the
- code is approved by the compiler, the output function
- @{ML "ThyOutput.output_list (fn _ => fn s => Pretty.str s)"}
- pretty prints the code. This function expects that the code is a list of strings
- according to the line breaks (therefore the
- @{ML_open "(space_explode \"\\n\" txt)" for txt} which produces this list).
- There are a number of options that are observed by @{ML ThyOutput.output_list}
- when printing the code (for example @{text "[display]"} and @{text "[source]"};
- for more information about these options see \rsccite{sec:antiq}).
+
+ Note that the parser @{ML "(Scan.lift Args.name)"} in line 9 parses a string,
+ in this case the code. This code is send to the ML-compiler in the line 4.
+ If the code is ``approved'' by the compiler, then the output function @{ML
+ "ThyOutput.output_list (fn _ => fn s => Pretty.str s)"} in the next line pretty prints the
+ code. This function expects that the code is a list of strings where each
+ string correspond to a line (therefore the @{ML_open "(space_explode \"\\n\" txt)" for txt}
+ which produces this list). There are a number of options for antiquotations
+ that are observed by @{ML ThyOutput.output_list} when printing the code (for
+ example @{text "[display]"}, @{text "[quotes]"} and @{text "[source]"}).
+
+ \begin{readmore}
+ For more information about options of antiquotations see \rsccite{sec:antiq}).
+ \end{readmore}
Since we used the argument @{ML "Position.none"}, the compiler cannot give specific
information about the line number where an error might have occurred. We
can improve this code slightly by writing
- The second
*}
ML {*
@@ -72,55 +76,80 @@
text {*
(FIXME: say something about OuterParse.position)
+
+ We can now write in a document @{text "@{ML_checked \"2 + 3\"}"} in order to
+ obtain @{ML_checked "2 + 3"} and be sure that this code compiles until
+ somebody changes the definition of @{ML "(op +)"}.
+
+
+ The second antiquotation extends the first by allowing to also give
+ hints what the result of the ML-code is and check consistency of these
+ hints. For this we use the antiquotation @{text "@{ML_response \"\<dots>\" \"\<dots>\"}"}
+ whose first argument is the ML-code and the second is the result.
+
+ In the antiquotation @{text "@{ML_checked \"\<dots>\"}"} we send the expresion
+ @{text [quotes] "val _ = \<dots>"} to the compiler. Now we will use the hints
+ to construct a pattern for the @{text "_"}. To add some convenince we allow
+ the user to give partial hints using @{text "\<dots>"}, which however need to
+ be replaced by @{text "_"} before sending the code to the compiler. The
+ function
+
*}
ML {*
fun ml_pat (rhs, pat) =
- let val pat' = implode (map (fn "\<dots>" => "_" | s => s) (Symbol.explode pat))
- in
- "val " ^ pat' ^ " = " ^ rhs
- end;
+let val pat' = implode (map (fn "\<dots>" => "_" | s => s) (Symbol.explode pat))
+in "val " ^ pat' ^ " = " ^ rhs end;
+*}
+text {*
+ will do this. Next we like to add a response indicator to the result using:
+*}
+
+
+ML {*
fun add_response_indicator txt =
map (fn s => "> " ^ s) (space_explode "\n" txt)
+*}
+text {*
+ The rest of the code of the antiquotation is
+ *}
+
+ML {*
fun output_ml_response ml src ctxt ((lhs,pat),pos) =
(ML_Context.eval_in (SOME ctxt) false pos (ml (lhs,pat));
let val txt = (space_explode "\n" lhs) @ (add_response_indicator pat)
in ThyOutput.output_list (fn _ => fn s => Pretty.str s) src ctxt txt end)
-*}
-
-(*
val _ = ThyOutput.add_commands
[("ML_response",
- ThyOutput.args (Scan.lift (OuterParse.position (Args.name -- Args.name)))
- (output_ml_response ml_pat)]
-*)
-
-
-ML {*
-
-let
- val i = 1 + 2
-in
- i * i
-end
-
+ ThyOutput.args
+ (Scan.lift (OuterParse.position (Args.name -- Args.name)))
+ (output_ml_response ml_pat))]
*}
-(*
-A test:
+text {*
+ This extended antiquotation allows us to write
+ @{text [display] "@{ML_response [display] \"true andalso false\" \"false\"}"}
+ to obtain
@{ML_response [display] "true andalso false" "false"}
-@{ML_response [display]
-"let
- val i = 1 + 2
-in
- i * i
-end" "9"}
-*)
+ or
+
+@{text [display] "@{ML_response [display] \"let val i = 3 in (i * i,\"foo\") end\" \"(9,\<dots>)\"}"}
+
+ to obtain
+
+@{ML_response [display] "let val i = 3 in (i * i,\"foo\") end" "(9,\<dots>)"}
+
+ In both cases, the check by the compiler ensures that code and result match. A limitation
+ of this antiquotation is that the hints can only be given for results that can actually
+ be constructed as a pattern. This excludes values that are abstract types, like
+ theorems or cterms.
+
+*}