Browse Source

Rename .topscript files into .mlt

Also fix a few rawtopscript/rawscript naming mismatches.
Thomas Gazagnaire 4 years ago
100 changed files with 742 additions and 743 deletions
  1. 2 3
  2. 1 1
  3. 4 4
  4. 1 1
  5. 1 1
  6. 1 1
  7. 1 1
  8. 2 2
  9. 2 2
  10. 6 6
  11. 1 1
  12. 65 65
  13. 67 67
  14. 58 58
  15. 7 7
  16. 43 43
  17. 45 45
  18. 40 40
  19. 65 65
  20. 30 30
  21. 36 36
  22. 29 29
  23. 19 19
  24. 31 31
  25. 4 4
  26. 11 11
  27. 28 28
  28. 50 50
  29. 14 14
  30. 8 8
  31. 4 4
  32. 2 2
  33. 2 2
  34. 1 1
  35. 0 0
  36. 0 0
  37. 0 0
  38. 0 0
  39. 0 0
  40. 5 5
  41. 0 0
  42. 0 0
  43. 0 0
  44. 0 0
  45. 4 4
  46. 0 0
  47. 1 1
  48. 0 0
  49. 2 2
  50. 0 0
  51. 0 0
  52. 2 2
  53. 0 0
  54. 0 0
  55. 0 0
  56. 2 2
  57. 0 0
  58. 0 0
  59. 8 8
  60. 1 1
  61. 0 0
  62. 0 0
  63. 1 1
  64. 0 0
  65. 1 1
  66. 0 0
  67. 2 2
  68. 0 0
  69. 0 0
  70. 0 0
  71. 0 0
  72. 0 0
  73. 0 0
  74. 0 0
  75. 13 13
  76. 0 0
  77. 0 0
  78. 0 0
  79. 0 0
  80. 0 0
  81. 0 0
  82. 0 0
  83. 0 0
  84. 0 0
  85. 0 0
  86. 8 8
  87. 0 0
  88. 2 2
  89. 0 0
  90. 0 0
  91. 0 0
  92. 2 2
  93. 0 0
  94. 2 2
  95. 0 0
  96. 0 0
  97. 0 0
  98. 5 5
  99. 0 0
  100. 0 0

+ 2 - 3

@@ -41,7 +41,7 @@ Toc
 Useful & reusable tools, not specific to this book.
 :   Collection of scripts.
@@ -111,7 +111,7 @@ Lang
     - "mly": OCaml file, which will be parsed by Oloop.
     - "mlpack"
-    - "topscript": OCaml toplevel commands that will be auto-evaluated
+    - "mlt": OCaml toplevel commands that will be auto-evaluated
       via Oloop.
     - "rawscript": OCaml toplevel script, which should not be
@@ -149,4 +149,3 @@ Lang
     - "S" or "s": GNU assembly code.
     - "scm"
     - "txt"

+ 1 - 1

@@ -47,7 +47,7 @@ module Params = struct
   let run_nondeterministic =
     flag "-run-nondeterministic" no_arg
-      ~doc:" In topscripts, run code marked [%%expect.nondeterministic ...]. \
+      ~doc:" In .mlt files, run code marked [%%expect.nondeterministic ...]. \
             By default, they are skipped."

+ 4 - 4

@@ -45,9 +45,9 @@ let emit_sexp file s =
       close_out fout
 let book_extensions =
-  [ ".ml"; ".mli"; ".mly"; ".mll"; ".rawtopscript";
+  [ ".ml"; ".mli"; ".mly"; ".mll";
     ".syntax"; ".scm"; ".rawscript"; ".java"; ".cpp";
-    ".topscript"; ".sh"; ".errsh"; ".rawsh"; "jbuild";
+    ".mlt"; ".sh"; ".errsh"; ".rawsh"; "jbuild";
     ".json"; ".atd"; ".rawsh"; ".c"; ".h"; ".cmd"; ".S" ]
 let static_extensions =
@@ -119,7 +119,7 @@ let process_chapters book_dir output_dir =
 (** Handle examples *)
-let topscript_rule ~dep f =
+let mlt_rule ~dep f =
   sprintf {|
  ((name    code)
@@ -155,7 +155,7 @@ let process_examples dir = (fun f ->
     let dep = List.assoc_opt f deps |> function None -> "" | Some v -> String.concat " " v in
     match f with
-    | f when Filename.extension f = ".topscript" -> topscript_rule ~dep f
+    | f when Filename.extension f = ".mlt" -> mlt_rule ~dep f
     | f when Filename.extension f = ".sh" -> sh_rule ~dep f
     | f when Filename.extension f = ".errsh" -> sh_rule ~dep f
     | _ -> printf "skipping %s/%s\n%!" dir f; ""

+ 1 - 1

@@ -40,7 +40,7 @@ end
 module Chunk = Ocaml_topexpect.Chunk
 module Part = Ocaml_topexpect.Part
-module Document = struct
+module Mlt = struct
   include Ocaml_topexpect.Document

+ 1 - 1

@@ -15,7 +15,7 @@ end
 module Chunk = Ocaml_topexpect.Chunk
 module Part = Ocaml_topexpect.Part
-module Document : sig
+module Mlt : sig
   include (module type of Ocaml_topexpect.Document)
   val of_file: filename:string -> t Deferred.Or_error.t

+ 1 - 1

@@ -28,7 +28,7 @@ let of_string x = match x with
   | "scm"
   | "sh"
   | "syntax"
-  | "topscript"
+  | "mlt"
   | "sexp"
   | "txt" -> Ok x
   | _ -> error "invalid extension" x sexp_of_string

+ 1 - 1

@@ -10,7 +10,7 @@
     - "mly": OCaml file, which will be parsed by Oloop.
     - "mlpack"
-    - "topscript": OCaml toplevel commands that will be auto-evaluated
+    - "mlt": OCaml toplevel commands that will be auto-evaluated
       via Oloop.
     - "rawscript": OCaml toplevel script, which should not be

+ 2 - 2

@@ -327,7 +327,7 @@ let extract_code_from_1e_exn chapter =
     let part = match part with
       | None | Some "" -> ""
       | Some part -> (match (lang :> string) with
-        | "topscript" -> sprintf "\n[@@@part %S]\n" part
+        | "mlt" -> sprintf "\n[@@@part %S]\n" part
         | "ml" -> sprintf "\n\n[@@@part %S]\n" part
         | _ ->
           ok_exn (error "unexpected part number with this language"
@@ -338,7 +338,7 @@ let extract_code_from_1e_exn chapter =
     let f = function
       | `Output x | `Prompt x -> (match (lang :> string) with
-        | "topscript" -> ""
+        | "mlt" -> ""
         | _ -> x
       | `Input x | `Data x -> x

+ 2 - 2

@@ -26,8 +26,8 @@ let of_lang (x:Lang.t) = match (x :> string) with
   | "json"         -> Ok `Json
   | "ml"
   | "mli"
-  | "topscript"
-  | "rawtopscript" -> Ok `OCaml
+  | "mlt"
+  | "rawscript"    -> Ok `OCaml
   | "scm"          -> Ok `Scheme
   | "sexp"         -> Ok `Sexp
   | _ ->

+ 6 - 6

@@ -11,7 +11,7 @@ type part = string
 type script = [
   | `OCaml of Expect.Raw_script.t
-  | `OCaml_toplevel of Expect.Document.t
+  | `OCaml_toplevel of Expect.Mlt.t
   | `OCaml_rawtoplevel of Expect.Raw_script.t
   | `Shell of Expect.Cram.t
   | `Other of string
@@ -53,7 +53,7 @@ let find_exn t ?part:(name="") ~filename =
       | Some x -> `OCaml x
   | Some (`OCaml_toplevel doc) -> (
-      match List.find ~f:(is_part ~name) ( doc) with
+      match List.find ~f:(is_part ~name) ( doc) with
       | None -> no_part_err()
       | Some x -> `OCaml_toplevel (Expect.Part.chunks x)
@@ -164,7 +164,7 @@ let exn_of_filename filename content =
   | Some ext -> (match ext with
     | "ml" | "mli" | "mly" | "mll" ->
       `OCaml Rwo_expect.Raw_script.{ name = ""; content }
-    | "rawtopscript" ->
+    | "rawscript" ->
       `OCaml_rawtoplevel Rwo_expect.Raw_script.{ name = ""; content }
     | _ -> `Other content)
   | None -> `Other content
@@ -175,8 +175,8 @@ let exn_of_filename filename content =
 let script lang ~filename =
   let open Deferred.Or_error.Let_syntax in
   match (lang : Lang.t :> string) with
-  | "topscript" ->
-    let%map script = Expect.Document.of_file ~filename in
+  | "mlt" ->
+    let%map script = Expect.Mlt.of_file ~filename in
     `OCaml_toplevel script
   | "ml" | "mli" | "mly" | "mll" -> (
       (* Hack: Oloop.Script.of_file intended only for ml files but
@@ -184,7 +184,7 @@ let script lang ~filename =
       let%map script = Expect.Raw_script.of_file ~filename in
       `OCaml script
-  | "rawtopscript" -> (
+  | "rawscript" -> (
       let%map script = Expect.Raw_script.of_file ~filename in
       `OCaml_rawtoplevel script

+ 1 - 1

@@ -7,7 +7,7 @@ type part = string
 type script = [
   | `OCaml of Rwo_expect.Raw_script.t
-  | `OCaml_toplevel of Rwo_expect.Document.t
+  | `OCaml_toplevel of Rwo_expect.Mlt.t
   | `OCaml_rawtoplevel of Rwo_expect.Raw_script.t
   | `Shell of Rwo_expect.Cram.t
   | `Other of string

+ 65 - 65

@@ -89,7 +89,7 @@
 	<idx>Core standard library/opening</idx> 
-      <link rel="import" href="code/guided-tour/main.topscript" part="0.5"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="0.5"/>
       <p>By opening <code>Base</code>, we make the
       definitions it contains available without having to reference
@@ -98,7 +98,7 @@
       <p>Now let's try a few simple numerical calculations:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="1"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="1"/>
       <p>By and large, this is pretty similar to what you'd find in
       any programming language, but a few things jump right out at
@@ -156,7 +156,7 @@
       <p>We can also create a variable to name the value of a given
       expression, using the <code>let</code> keyword. This is known
       as a <em>let binding</em>:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="2"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="2"/>
       <p>After a new variable is created, the toplevel tells us the
       name of the variable (<code>x</code> or <code>y</code>), in
@@ -168,10 +168,10 @@
       except for <code>_</code> and <code>'</code>, and variables
       must start with a lowercase letter or an underscore. Thus,
       these are legal:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="3"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="3"/>
       <p>The following examples, however, are not legal:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="4"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="4"/>
       <p>This highlights that variables can't be capitalized, can't
       begin with numbers, and can't contain dashes.</p>
@@ -183,7 +183,7 @@
       <p>The <code>let</code> syntax can also be used to define a
       function:<idx>let syntax/function definition
-      <link rel="import" href="code/guided-tour/main.topscript" part="5"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="5"/>
       <p>Functions in OCaml are values like any other, which is why
       we use the <code>let</code> keyword to bind a function to a
@@ -207,7 +207,7 @@
       <idx>functions/with multiple arguments</idx>
-      <link rel="import" href="code/guided-tour/main.topscript" part="6"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="6"/>
 	The preceding example also happens to be our first use of
@@ -234,7 +234,7 @@
 	be shadowed locally.
-      <link rel="import" href="code/guided-tour/main.topscript" part="6.1"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="6.1"/>
 	Note that we used a slightly different syntax for opening the
@@ -243,7 +243,7 @@
 	more concise syntax for local opens, as you can see here.
-      <link rel="import" href="code/guided-tour/main.topscript" part="6.2"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="6.2"/>
       <p>The notation for the type-signature of a multiargument
       function may be a little surprising at first, but we'll
@@ -261,14 +261,14 @@
       arguments: a test function and two integer arguments. The
       function returns the sum of the integers that pass the
-      <link rel="import" href="code/guided-tour/main.topscript" part="7"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="7"/>
       <p>If we look at the inferred type signature in detail, we
       see that the first argument is a function that takes an
       integer and returns a boolean, and that the remaining two
       arguments are integers. Here's an example of this function in
-      <link rel="import" href="code/guided-tour/main.topscript" part="8"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="8"/>
       <p>Note that in the definition of <code>even</code>, we used
       <code>=</code> in two different ways: once as part of the
@@ -349,7 +349,7 @@
         <p>Here's an annotated version of
-        <link rel="import" href="code/guided-tour/main.topscript" part="9"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="9"/>
         <p>In the above, we've marked every argument to the
         function with its type, with the final annotation
@@ -364,7 +364,7 @@
         <p>Sometimes, there isn't enough information to fully
         determine the concrete type of a given value. Consider this
         function..<idx>type inference/generic types</idx></p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="10"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="10"/>
         <p><code>first_if_true</code> takes as its arguments a
         function <code>test</code>, and two values, <code>x</code>
@@ -397,10 +397,10 @@
         <p>Because the type of <code>first_if_true</code> is generic,
         we can write this:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="11"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="11"/>
         <p>As well as this:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="12"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="12"/>
         <p>Both <code>long_string</code> and
         <code>big_number</code> are functions, and each is passed
@@ -409,7 +409,7 @@
         integers in the second). But we can't mix and match two
         different concrete types for <code>'a</code> in the same
         use of <code>first_if_true</code>:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="13"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="13"/>
         <p>In this example, <code>big_number</code> requires that
         <code>'a</code> be instantiated as <code>int</code>,
@@ -435,14 +435,14 @@
           difference between runtime and compile-time errors, but
           that difference is still there. Generally, type errors
           like this one:</p>
-          <link rel="import" href="code/guided-tour/main.topscript" part="14"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="14"/>
           <p>are compile-time errors (because <code>+</code>
           requires that both its arguments be of type
           <code>int</code>), whereas errors that can't be caught by
           the type system, like division by zero, lead to runtime
-          <link rel="import" href="code/guided-tour/main.topscript" part="15"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="15"/>
           <p>The distinction here is that type errors will stop you
           whether or not the offending code is ever actually
@@ -474,7 +474,7 @@
 	<idx>data structures/tuples</idx>
-        <link rel="import" href="code/guided-tour/main.topscript" part="16"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="16"/>
         <p>(For the mathematically inclined, <code>*</code>
           is used in the type <code>t * s</code> because that type
@@ -486,14 +486,14 @@
         <p>You can extract the components of a tuple using OCaml's
         pattern-matching syntax, as shown below:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="17"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="17"/>
         <p>Here, the <code>(x,y)</code> on the left-hand side of
         the <code>let</code> binding is the pattern. This pattern lets
         us mint the new variables <code>x</code> and <code>y</code>,
         each bound to different components of the value being
         matched. These can now be used in subsequent expressions:</p>
-        <link rel="import" href="code/guided-tour/main.topscript"
+        <link rel="import" href="code/guided-tour/main.mlt"
         <p>Note that the same syntax is used both for constructing
@@ -505,7 +505,7 @@
         pair of <code>float</code>s. The pattern-matching syntax
         lets us get at the values we need with a minimum of
-        <link rel="import" href="code/guided-tour/main.topscript" part="19"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="19"/>
         <p>The <code>**.</code> operator used above is for raising a
         floating-point number to a power.</p>
@@ -522,11 +522,11 @@
         potentially of different types, lists let you hold any
         number of items of the same type. Consider the following
         example:<idx id="DSlists">data structures/lists</idx></p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="20"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="20"/>
         <p>Note that you can't mix elements of different types in
         the same list, unlike tuples:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="21"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="21"/>
         <section id="the-list-module" data-type="sect3">
           <h3>The List module</h3>
@@ -536,12 +536,12 @@
           functions for working with lists. We can access values
           from within a module by using dot notation. For example,
           this is how we compute the length of a list:</p>
-          <link rel="import" href="code/guided-tour/main.topscript" part="22"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="22"/>
           <p>Here's something a little more complicated. We can
           compute the list of the lengths of each language as
-          <link rel="import" href="code/guided-tour/main.topscript" part="23"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="23"/>
           <p><code></code> takes two arguments: a list and
           a function for transforming the elements of that list. It
@@ -556,7 +556,7 @@
           without changing its behavior, as you can see
           here:<idx>arguments/labeled arguments</idx><idx>labeled
-          <link rel="import" href="code/guided-tour/main.topscript" part="24"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="24"/>
           <p>We'll learn more about labeled arguments and why
           they're important in <a href="02-variables-and-functions.html#variables-and-functions" data-type="xref">Variables And Functions</a>.</p>
@@ -569,13 +569,13 @@
           use the list constructor <code>::</code> for adding elements
           to the front of a list:<idx>operators/: :
           operator</idx><idx>lists/operator : :</idx></p>
-          <link rel="import" href="code/guided-tour/main.topscript"
+          <link rel="import" href="code/guided-tour/main.mlt"
           <p>Here, we're creating a new and extended list, not
           changing the list we started with, as you can see
-          <link rel="import" href="code/guided-tour/main.topscript" part="26"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="26"/>
           <div data-type="note">
             <h1>Semicolons Versus Commas</h1>
@@ -587,7 +587,7 @@
             that your code compiles but doesn't do quite what you
             might expect:<idx>commas vs.
             semicolons</idx><idx>semicolons vs. commas</idx></p>
-            <link rel="import" href="code/guided-tour/main.topscript" part="27"/>
+            <link rel="import" href="code/guided-tour/main.mlt" part="27"/>
             <p>In particular, rather than a list of three strings,
             what we have is a singleton list containing a
@@ -596,7 +596,7 @@
             <p>This example uncovers the fact that commas create a
             tuple, even if there are no surrounding parens. So, we
             can write:</p>
-            <link rel="import" href="code/guided-tour/main.topscript" part="28"/>
+            <link rel="import" href="code/guided-tour/main.mlt" part="28"/>
             <p>to allocate a tuple of integers. This is generally
             considered poor style and should be avoided.</p>
@@ -607,14 +607,14 @@
           declarations are all equivalent. Note that
           <code>[]</code> is used to represent the empty list and
           that <code>::</code> is right-associative:</p>
-          <link rel="import" href="code/guided-tour/main.topscript" part="29"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="29"/>
           <p>The <code>::</code> constructor can only be used for
           adding one element to the front of the list, with the
           list terminating at <code>[]</code>, the empty list.
           There's also a list concatenation operator,
           <code>@</code>, which can concatenate two lists:</p>
-          <link rel="import" href="code/guided-tour/main.topscript" part="30"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="30"/>
           <p>It's important to remember that, unlike
           <code>::</code>, this is not a constant-time operation.
@@ -630,7 +630,7 @@
           constructors, <code>[]</code> and <code>::</code>. Here's
           a simple example:<idx>pattern matching/in
           lists</idx><idx>lists/pattern matching</idx></p>
-          <link rel="import" href="code/guided-tour/main.topscript" part="31"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="31"/>
           <p>By pattern matching using <code>::</code>, we've
           isolated and named the first element of the list
@@ -650,7 +650,7 @@
           particular, <code>[]</code>, the empty list. If we try to
           run <code>my_favorite_language</code>, we'll see that it
           works on nonempty lists and fails on empty ones:</p>
-          <link rel="import" href="code/guided-tour/main.topscript"
+          <link rel="import" href="code/guided-tour/main.mlt"
           <p>You can avoid these warnings, and more importantly
@@ -671,7 +671,7 @@
           <code>my_favorite_language</code> that uses
           <code>match</code> and doesn't trigger a compiler
-          <link rel="import" href="code/guided-tour/main.topscript" part="33"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="33"/>
           <p>The preceding code also includes our first comment.
           OCaml comments are bounded by <code>(*</code> and
@@ -707,7 +707,7 @@
           between the base cases and the inductive cases is often
           done using pattern matching. Here's a simple example of a
           function that sums the elements of a list:</p>
-          <link rel="import" href="code/guided-tour/main.topscript" part="34"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="34"/>
           <p>Following the common OCaml idiom, we use
           <code>hd</code> to refer to the head of the list and
@@ -729,14 +729,14 @@
           <p>We can introduce more complicated list patterns as
           well. Here's a function for removing sequential
-          <link rel="import" href="code/guided-tour/main.topscript" part="35"/>
+          <link rel="import" href="code/guided-tour/main.mlt" part="35"/>
           <p>Again, the first arm of the match is the base case, and
           the second is the inductive case. Unfortunately, this code
           has a problem, as indicated by the warning message. In
           particular, it doesn't handle one-element lists. We can fix
           this warning by adding another case to the match:</p>
-          <link rel="import" href="code/guided-tour/main.topscript"
+          <link rel="import" href="code/guided-tour/main.mlt"
           <p>Note that this code used another variant of the list
@@ -767,7 +767,7 @@
         might or might not be present. For
         structures/options</idx></p> <link rel="import"
-        href="code/guided-tour/main.topscript" part="37"/>
+        href="code/guided-tour/main.mlt" part="37"/>
         <p>The function <code>divide</code> either returns
         <code>None</code> if the divisor is zero, or
@@ -789,7 +789,7 @@
         <code>String.rsplit2</code> has return type <code>(string *
         string) option</code>, returning <code>None</code> when no
         character was found to split on.</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="38"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="38"/>
         <p>Note that we used the <code>^</code> operator for
         concatenating strings. The concatenation operator is
@@ -808,19 +808,19 @@
           which the new variable can be used. Thus, we could
           write:<idx>let syntax/nested let binding</idx></p>
-          <link rel="import" href="code/guided-tour/local_let.topscript" part="0.5"/>
+          <link rel="import" href="code/guided-tour/local_let.mlt" part="0.5"/>
           <p>Note that the scope of the <code>let</code> binding is
           terminated by the double-semicolon, so the value of
           <code>x</code> is no longer available:</p>
-          <link rel="import" href="code/guided-tour/local_let.topscript" part="1"/>
+          <link rel="import" href="code/guided-tour/local_let.mlt" part="1"/>
           <p>We can also have multiple <code>let</code> statements
           in a row, each one adding a new variable binding to what
           came before:</p>
-          <link rel="import" href="code/guided-tour/local_let.topscript" part="2"/>
+          <link rel="import" href="code/guided-tour/local_let.mlt" part="2"/>
           <p>This kind of nested <code>let</code> binding is a
           common way of building up a complex expression, with each
@@ -858,18 +858,18 @@
       also allows us to define new data types. Here's a toy example
       of a data type representing a point in two-dimensional
       space:<idx>datatypes/defining new</idx></p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="41"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="41"/>
       <p><code>point2d</code> is a <em>record</em> type, which you
       can think of as a tuple where the individual fields are
       named, rather than being defined positionally. Record types
       are easy enough to construct:<idx>records/record
       types</idx><idx>datatypes/record types</idx></p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="42"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="42"/>
       <p>And we can get access to the contents of these types using
       pattern matching:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="43"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="43"/>
       <p>The pattern match here binds the variable
       <code>x_pos</code> to the value contained in the
@@ -882,17 +882,17 @@
       we don't have to write them both down. Using this, our
       magnitude function can be rewritten as
       follows:<idx>fields/field punning</idx></p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="44"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="44"/>
       <p>Alternatively, we can use dot notation for accessing
       record fields:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="45"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="45"/>
       <p>And we can of course include our newly defined types as
       components in larger types. Here, for example, are some types
       for modeling different geometric objects that contain values
       of type <code>point2d</code>:</p>
-      <link rel="import" href="code/guided-tour/main.topscript" part="46"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="46"/>
       <p>Now, imagine that you want to combine multiple objects of
       these types together as a description of a multi-object scene.
@@ -901,7 +901,7 @@
       <em>variant</em> type:<idx>datatypes/variant
       types</idx><idx>variant types/combining multiple object types
-      <link rel="import" href="code/guided-tour/main.topscript" part="47"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="47"/>
       <p>The <code>|</code> character separates the different cases
       of the variant (the first <code>|</code> is optional), and
@@ -913,7 +913,7 @@
       point is in the interior of some element of a list of
-      <link rel="import" href="code/guided-tour/main.topscript" part="48"/>
+      <link rel="import" href="code/guided-tour/main.mlt" part="48"/>
       <p>You might at this point notice that the use
       of <code>match</code> here is reminiscent of how we
@@ -998,7 +998,7 @@
         Here's an example:<idx>data
         structures/arrays</idx><idx>arrays/imperative programming
         and</idx><idx>imperative programming/arrays</idx></p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="49"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="49"/>
         <p>The <code>.(i)</code> syntax is used to refer to an
         element of an array, and the <code>&lt;-</code> syntax is
@@ -1029,7 +1029,7 @@
         storing a running statistical summary of a collection of
         numbers.<idx>imperative programming/mutable record
         fields</idx><idx>mutable record fields</idx><idx>data
-        structures/mutable record fields</idx></p> <link rel="import" href="code/guided-tour/main.topscript" part="50"/>
+        structures/mutable record fields</idx></p> <link rel="import" href="code/guided-tour/main.mlt" part="50"/>
         <p>The fields in <code>running_sum</code> are designed to
         be easy to extend incrementally, and sufficient to compute
@@ -1040,7 +1040,7 @@
         <em>utop</em> to process the input, not to separate two
-        <link rel="import" href="code/guided-tour/main.topscript" part="51"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="51"/>
         <p>We use the function <code>float</code> above, which is a
         convenient equivalent of <code>Float.of_int</code> provided
@@ -1048,7 +1048,7 @@
         <p>We also need functions to create and update
-        <link rel="import" href="code/guided-tour/main.topscript" part="52"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="52"/>
         <p><code>create</code> returns a <code>running_sum</code>
         corresponding to the empty set, and <code>update rsum
@@ -1065,7 +1065,7 @@
         <code>update</code> in action. Note that this code uses
         <code>List.iter</code>, which calls the function
         <code>~f</code> on each element of the provided list:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="53"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="53"/>
         <p>It's worth noting that the preceding algorithm is
         numerically naive and has poor precision in the presence of
@@ -1085,17 +1085,17 @@
         single mutable field called
         types</idx><idx>imperative programming/ref type</idx></p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="54"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="54"/>
         <p>There are a handful of useful functions and operators
         defined for <code>ref</code>s to make them more convenient
         to work with:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="55"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="55"/>
         <p>There's nothing magical with these operators either. You
         can completely reimplement the <code>ref</code> type and
         all of these operators in just a few lines of code:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="56"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="56"/>
         <p>The <code>'a</code> before the <code>ref</code>
         indicates that the <code>ref</code> type is polymorphic, in
@@ -1112,7 +1112,7 @@
         of a list imperatively by calling <code>List.iter</code> to
         call a simple function on every element of a list, using a
         <code>ref</code> to accumulate the results:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="57"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="57"/>
         <p>This isn't the most idiomatic way to sum up a list, but
         it shows how you can use a <code>ref</code> in place of a
@@ -1132,7 +1132,7 @@
         random:<idx>Random module</idx><idx>while
         loops</idx><idx>for loops</idx><idx>imperative
         programming/for and while loops</idx></p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="58"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="58"/>
         <p>From a syntactic perspective, you should note the
         keywords that distinguish a <code>for</code> loop:
@@ -1140,14 +1140,14 @@
         <p>Here's an example run of this code:</p>
-        <link rel="import" href="code/guided-tour/main.topscript" part="59"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="59"/>
         <p>OCaml also supports <code>while</code> loops, as shown
         in the following function for finding the position of the
         first negative entry in an array. Note that
         <code>while</code> (like <code>for</code>) is also a
-        <link rel="import" href="code/guided-tour/main.topscript" part="60"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="60"/>
         <p>As a side note, the preceding code takes advantage of
         the fact that <code>&amp;&amp;</code>, OCaml's And
@@ -1160,7 +1160,7 @@
         out-of-bounds error. Indeed, we can trigger that
         out-of-bounds error by rewriting the function to avoid the
-        <link rel="import" href="code/guided-tour/main.topscript" part="61"/>
+        <link rel="import" href="code/guided-tour/main.mlt" part="61"/>
         <p>The or operator, <code>||</code>, short-circuits in a
         similar way to <code>&amp;&amp;</code>.</p>

+ 67 - 67

@@ -54,7 +54,7 @@
       of</idx><idx>bindings/scope of</idx><idx>scope</idx></p>
       <p>Here's a simple example.</p>
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="0.5"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="0.5"/>
       <p><code>let</code> can also be used to create a variable
       binding whose scope is limited to a particular expression,
@@ -66,13 +66,13 @@
       with <em><code>variable</code></em> bound to whatever value was
       produced by the evaluation of <em><code>expr1</code></em>.
       Here's how it looks in practice.</p>
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="1"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="1"/>
       <p>Note that the scope of <code>language_list</code> is just
       the expression <code>String.concat ~sep:"-"
       language_list</code> and is not available at the toplevel, as
       we can see if we try to access it now.</p>
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="2"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="2"/>
       <p>A <code>let</code> binding in an inner scope can
       <em>shadow</em>, or hide, the definition from an outer scope.
@@ -80,7 +80,7 @@
       <code>dashed_languages</code> example as
       follows. <idx>variables/shadowing
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="3"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="3"/>
       <p>This time, in the inner scope we called the list of
       strings <code>languages</code> instead of
@@ -89,21 +89,21 @@
       of <code>dashed_languages</code> is complete, the inner scope
       has closed and the original definition of languages
       is still available.</p>
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="4"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="4"/>
       <p>One common idiom is to use a series of nested
       <code>let</code>/<code>in</code> expressions to build up the
       components of a larger computation. Thus, we might
       write. <idx>let syntax/nested bindings</idx><idx>nested let
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="5"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="5"/>
       <p>It's important not to confuse a sequence of
       <code>let</code> bindings with the modification of a mutable
       variable. For example, consider how <code>area_of_ring</code>
       would work if we had instead written this purposefully
       confusing bit of code:</p>
-      <link rel="import" href="code/variables-and-functions/main.topscript" part="6"/>
+      <link rel="import" href="code/variables-and-functions/main.mlt" part="6"/>
       <p>Here, we redefined <code>pi</code> to be zero after the
       definition of <code>area_of_circle</code>. You might think that
@@ -159,7 +159,7 @@
         let</idx><idx>let syntax/pattern
         matching</idx><idx>variables/pattern matching in</idx></p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="7"/>
+        href="code/variables-and-functions/main.mlt" part="7"/>
         <p>Here, <code>(ints,strings)</code> is a pattern, and
         the <code>let</code> binding assigns values to both of the
@@ -180,20 +180,20 @@
         following code that implements a function for upper casing
         the first element of a comma-separated
         list.<idx>irrefutable patterns</idx></p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="8"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="8"/>
         <p>This case can't really come up in practice,
         because <code>String.split</code> always returns a list with
         at least one element, even when given the empty string.
         <link rel="import"
-        href="code/variables-and-functions/main.topscript"
+        href="code/variables-and-functions/main.mlt"
 	But the compiler doesn't know this, and so it emits the
         warning. It's generally better to use a <code>match</code>
         statement to handle such cases explicitly.</p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="9"/>
+        href="code/variables-and-functions/main.mlt" part="9"/>
         <p>Note that this is our first use of <code>assert</code>,
         which is useful for marking cases that should be
@@ -223,24 +223,24 @@
         the <code>fun</code> keyword, as shown here. <idx>fun
         keyword/anonymous functions</idx><idx>anonymous
         functions</idx><idx>functions/anonymous functions</idx></p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="10"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="10"/>
         <p>Anonymous functions operate in much the same way as
         named functions. For example, we can apply an anonymous
         function to an argument. </p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="11"/> 
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="11"/> 
         <p>Or pass it to another function. Passing functions to
         iteration functions like <code></code> is probably
         the most common use case for anonymous functions.</p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="12"/> 
+        href="code/variables-and-functions/main.mlt" part="12"/> 
         <p>You can even stuff a function into a data structure, like a
         <link rel="import" 
-	      href="code/variables-and-functions/main.topscript"
+	      href="code/variables-and-functions/main.mlt"
 	      part="13" />
@@ -262,13 +262,13 @@
         storing them in data structures. We even name functions in
         the same way that we name other values, by using a
         <code>let</code> binding.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="14"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="14"/>
         <p>Defining named functions is so common that there is some
         syntactic sugar for it. Thus, the following definition of
         <code>plusone</code> is equivalent to the previous
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="15"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="15"/>
         <p>This is the most common and convenient way to declare a
         function, but syntactic niceties aside, the two styles of
@@ -283,7 +283,7 @@
           value passed by the caller. Indeed, the following two
           expressions are nearly equivalent. <idx>let
           syntax/functions and</idx></p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="16"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="16"/>
           <p>This connection is important, and will come up more
           when programming in a monadic style, as we'll see in
@@ -300,14 +300,14 @@
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="17"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="17"/>
         <p>You may find the type signature of <code>abs_diff</code>
         with all of its arrows a little hard to parse. To
         understand what's going on, let's rewrite
         <code>abs_diff</code> in an equivalent form, using the
         <code>fun</code> keyword.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="18"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="18"/>
         <p>This rewrite makes it explicit that
         <code>abs_diff</code> is actually a function of one
@@ -344,7 +344,7 @@
           the distance of a given number from <code>3</code>.</p>
         <link rel="import" 
-	      href="code/variables-and-functions/main.topscript"
+	      href="code/variables-and-functions/main.mlt"
 	      part="19" /> 
         <p>The practice of applying some of the arguments of a curried
@@ -356,7 +356,7 @@
         of <code>abs_diff</code> is equivalent to the previous
         one.<idx>fun keyword/currying syntax</idx></p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="20"/>
+        href="code/variables-and-functions/main.mlt" part="20"/>
         <p>You might worry that curried functions are terribly
         expensive, but this is not the case. In OCaml, there is no
@@ -368,7 +368,7 @@
         function in OCaml. It's also possible to use the different
         parts of a tuple as different arguments. So, we could
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="21"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="21"/>
         <p>OCaml handles this calling convention efficiently as
         well. In particular it does not generally have to allocate
@@ -401,7 +401,7 @@
         <code>rec</code> keyword, as shown in this function for
         finding the first sequentially repeated element in a
         list.<idx>rec keyword</idx></p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="22"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="22"/>
 	  The pattern <code>[] | [_]</code> is itself a disjunction of
@@ -419,7 +419,7 @@
           the <code>and</code> keyword. Here's a (gratuitously
           inefficient) example.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="23" />
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="23" />
 	  OCaml distinguishes between nonrecursive definitions
@@ -454,7 +454,7 @@
         operators</idx><idx>infix operators</idx><idx>prefix
         operators</idx><idx id="FNCprf">functions/prefix and infix
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="24"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="24"/>
         <p>You might not have thought of the second example as an
         ordinary function, but it very much is. Infix operators
@@ -462,7 +462,7 @@
         other functions. In fact, if we put parentheses around an
         infix operator, you can use it as an ordinary prefix
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="25"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="25"/>
         <p>In the second expression, we've partially applied
         <code>(+)</code> to create a function that increments its
@@ -483,18 +483,18 @@
         <p>We can define (or redefine) the meaning of an operator.
         Here's an example of a simple vector-addition operator on
         <code>int</code> pairs.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="26"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="26"/>
         <p>Note that you have to be careful when dealing with
         operators containing <code>*</code>. Consider the following
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="27"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="27"/>
         <p>What's going on is that <code>(***)</code> isn't
         interpreted as an operator at all; it's read as a comment!
         To get this to work properly, we need to put spaces around
         any operator that begins or ends with <code>*</code>.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="28"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="28"/>
         <p>The syntactic role of an operator is typically
         determined by its first character or two, though there are
@@ -638,18 +638,18 @@
         operators</idx><idx>negation operators</idx></p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="29"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="29"/>
         <p>Here, OCaml is interpreting the second expression as
         equivalent to.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="30"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="30"/>
         <p>which obviously doesn't make sense.</p>
         <p>Here's an example of a very useful operator from the
         standard library whose behavior depends critically on the
         precedence rules described previously.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="31"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="31"/>
         <p>It's not quite obvious at first what the purpose of this
         operator is: it just takes a value and a function and
@@ -664,12 +664,12 @@
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="32"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="32"/>
         <p>We can do this without <code>|&gt;</code> by naming the
         intermediate values, but the result is a bit more verbose.</p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="33"/>
+        href="code/variables-and-functions/main.mlt" part="33"/>
         <p>An important part of what's happening here is partial
         application. For example, <code>List.iter</code> takes two
@@ -678,11 +678,11 @@
         call <code>List.iter</code> with all its
         arguments.  <idx>partial application</idx></p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="34"/>
+        href="code/variables-and-functions/main.mlt" part="34"/>
         <p>Or, we can pass it just the function argument, leaving
         us with a function for printing out a list of strings.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="35"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="35"/>
         <p>It is this later form that we're using in the preceding
         <code>|&gt;</code> pipeline.</p>
@@ -691,7 +691,7 @@
         because it is left-associative. Let's see what happens if
         we try using a right-associative operator, like
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="36"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="36"/>
         <p>The type error is a little bewildering at first glance.
         What's going on is that, because <code>^&gt;</code> is
@@ -716,17 +716,17 @@
         an example.<idx>functions/defining</idx><idx>function
         keyword</idx><idx>functions/declaring with function
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="37"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="37"/>
         <p>This is equivalent to combining an ordinary function
         definition with a <code>match</code>.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="38"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="38"/>
         <p>We can also combine the different styles of function
         declaration together, as in the following example, where we
         declare a two-argument (curried) function with a pattern
         match on the second argument.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="39"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="39"/>
         <p>Also, note the use of partial application to generate
         the function passed to <code></code>. In other
@@ -750,12 +750,12 @@
         arguments</idx><idx>functions/labeled arguments</idx></p>
         <link rel="import"
-        href="code/variables-and-functions/main.topscript" part="40"/>
+        href="code/variables-and-functions/main.mlt" part="40"/>
         <p>We can then provide a labeled argument using a similar
         convention. As you can see, the arguments can be provided
         in any order.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="41"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="41"/>
         <p>OCaml also supports <em>label punning</em>, meaning that
         you get to drop the text after the <code>:</code> if the
@@ -764,7 +764,7 @@
         when defining <code>ratio</code>. The following shows how
         punning can be used when invoking a
         function.<idx>punning</idx><idx>label punning</idx></p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="42"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="42"/>
         <p>Labeled arguments are useful in a few different
@@ -830,7 +830,7 @@
             <code>List.iter</code> by giving it just the function,
             as in the following example from earlier in the
-            <link rel="import" href="code/variables-and-functions/main.topscript" part="43"/>
+            <link rel="import" href="code/variables-and-functions/main.mlt" part="43"/>
             <p>This requires that we put the function argument
             first. In other cases, you want to put the function
@@ -852,7 +852,7 @@
           example.<idx>higher-order functions, and
           labels</idx><idx>functions/higher-order and
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="44"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="44"/>
           <p>Here, the definition of <code>apply_to_tuple</code>
           sets up the expectation that its first argument is a
@@ -861,19 +861,19 @@
           have defined <code>apply_to_tuple</code> differently to
           change the order in which the labeled arguments were
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="45"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="45"/>
           <p>It turns out this order matters. In particular, if we
           define a function that has a different order</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="46"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="46"/>
           <p>we'll find that it can't be passed in to
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="47"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="47"/>
           <p>But, it works smoothly with the original
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="48"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="48"/>
           <p>As a result, when passing labeled functions as
           arguments, you need to take care to be consistent in your
@@ -896,7 +896,7 @@
         with an optional separator. This function uses the
         <code>^</code> operator for pairwise string
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="49"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="49"/>
         <p>Here, <code>?</code> is used in the definition of the
         function to mark <code>sep</code> as optional. And while
@@ -911,7 +911,7 @@
         a common enough pattern that there's an explicit syntax for
         providing a default value, which allows us to write
         <code>concat</code> more concisely.</p>
-        <link rel="import" href="code/variables-and-functions/main.topscript" part="50"/>
+        <link rel="import" href="code/variables-and-functions/main.mlt" part="50"/>
         <p>Optional arguments are very useful, but they're also
         easy to abuse. The key advantage of optional arguments is
@@ -952,12 +952,12 @@
           <code>sep</code> argument to
           <code>concat</code>.<idx>optional arguments/explicit
           passing of</idx></p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="51"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="51"/>
           <p>And the following two lines are equivalent ways of
           calling <code>concat</code> without specifying
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="52"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="52"/>
           <p>One use case for this is when you want to define a
           wrapper function that mimics the optional arguments of
@@ -967,7 +967,7 @@
           <code>concat</code> except that it converts the first
           string that it's passed to uppercase. We could write the
           function as follows.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="53"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="53"/>
           <p>In the way we've written it, we've been forced to
           separately make the decision as to what the default
@@ -979,7 +979,7 @@
           <p>Instead, we can have <code>uppercase_concat</code>
           simply pass through the optional argument to
           <code>concat</code> using the <code>?</code> syntax.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="54"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="54"/>
           <p>Now, if someone calls <code>uppercase_concat</code>
           without an argument, an explicit <code>None</code> will
@@ -1008,7 +1008,7 @@
           of</idx><idx>optional arguments/inference of</idx></p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="55"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="55"/>
           <p>In principle, it's not obvious how the order of the
           arguments to <code>f</code> should be chosen. Since
@@ -1034,7 +1034,7 @@
           of <code>numeric_deriv</code> where different invocations
           of <code>f</code> list the arguments in different
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="56"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="56"/>
           <p>As suggested by the error message, we can get OCaml to
           accept the fact that <code>f</code> is used with
@@ -1042,7 +1042,7 @@
           information. Thus, the following code compiles without
           error, due to the type annotation on
           <code>f</code>.<idx>type annotations</idx></p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="57"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="57"/>
         <section id="optional-arguments-and-partial-application" data-type="sect3">
@@ -1051,17 +1051,17 @@
           <p>Optional arguments can be tricky to think about in the
           presence of partial application. We can of course
           partially apply the optional argument itself.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="58"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="58"/>
           <p>But what happens if we partially apply just the first
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="59"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="59"/>
           <p>The optional argument <code>?sep</code> has now
           disappeared, or been <em>erased</em>. Indeed, if we try
           to pass in that optional argument now, it will be
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="60"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="60"/>
           <p>So when does OCaml decide to erase an optional
@@ -1073,29 +1073,29 @@
           <code>prepend_pound</code>. But if we had instead defined
           <code>concat</code> with the optional argument in the
           second position.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="61"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="61"/>
           <p>then application of the first argument would not cause
           the optional argument to be erased.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="62"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="62"/>
           <p>However, if all arguments to a function are presented
           at once, then erasure of optional arguments isn't applied
           until all of the arguments are passed in. This preserves
           our ability to pass in optional arguments anywhere on the
           argument list. Thus, we can write.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="63"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="63"/>
           <p>An optional argument that doesn't have any following
           positional arguments can't be erased at all, which leads
           to a compiler warning.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="64"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="64"/>
           <p>And indeed, when we provide the two positional
           arguments, the <code>sep</code> argument is not erased,
           instead returning a function that expects the
           <code>sep</code> argument to be provided.</p>
-          <link rel="import" href="code/variables-and-functions/main.topscript" part="65"/>
+          <link rel="import" href="code/variables-and-functions/main.mlt" part="65"/>
           <p>As you can see, OCaml's support for labeled and
           optional arguments is not without its complexities. But

+ 58 - 58

@@ -25,12 +25,12 @@
       using a bracket-and-semicolon notation:<idx>lists/generation
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="0.5"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="0.5"/>
       <p>And they can also be generated using the equivalent
       <code>::</code> notation:<idx>operators/: :
       operator</idx><idx>lists/operator : :</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="1"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="1"/>
       <p>As you can see, the <code>::</code> operator is
       right-associative, which means that we can build up lists
@@ -38,7 +38,7 @@
       to terminate a list. Note that the empty list is polymorphic,
       meaning it can be used with elements of any type, as you can
       see here:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="2"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="2"/>
       <p>The way in which the <code>::</code> operator attaches
       elements to the front of a list reflects the fact that
@@ -60,7 +60,7 @@
       extend a list without modifying it; extension allocates a new
       list element but does not change any of the existing ones, as you can
       see:<idx>lists/extension of</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="3"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="3"/>
     <section id="using-patterns-to-extract-data-from-a-list" data-type="sect1">
@@ -71,7 +71,7 @@
       that computes the sum of all elements of a list:<idx>match
       statements</idx><idx id="PATMAT">pattern matching/extracting
       data with</idx><idx>lists/extracting data from</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="4"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="4"/>
       <p>This code follows the convention of using <code>hd</code>
       to represent the first element (or head) of the list, and
@@ -95,12 +95,12 @@
       tempted to write that code as follows, but when you do, the
       compiler will immediately warn you that something is
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="5"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="5"/>
       <p>Moreover, the function clearly does the wrong thing,
       filtering out all elements of the list rather than just those
       equal to the provided value, as you can see here:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="6"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="6"/>
       <p>So, what's going on?</p>
@@ -119,7 +119,7 @@
       matching for determining whether the first element is equal
       to <code>to_drop</code>, but to instead use an ordinary
       <code>if</code> statement:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="7"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="7"/>
 	If we wanted to drop a particular literal value, rather than a
@@ -127,7 +127,7 @@
 	like our original implementation
 	of <code>drop_value</code>:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="8"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="8"/>
@@ -168,7 +168,7 @@
         functions for incrementing an integer by one. The first is
         implemented with a <code>match</code> statement, and the
         second with a sequence of <code>if</code> statements:</p>
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="9"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="9"/>
         <p>Note the use of <code>_</code> in the above match. This
         is a wildcard pattern that matches any value, but without
@@ -181,7 +181,7 @@
         these functions using the <code>core_bench</code> library,
         which can be installed by running <code>opam install
         core_bench</code> from the command line.</p>
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="10"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="10"/>
         <p>Here's another, less artificial example. We can rewrite
         the <code>sum</code> function we described earlier in the
@@ -191,10 +191,10 @@
         <code>List</code> module to deconstruct the list, allowing
         us to implement the entire function without pattern
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="11"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="11"/>
         <p>Again, we can benchmark these to see the difference:</p>
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="12"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="12"/>
         <p>In this case, the <code>match</code>-based
         implementation is many times faster than the
@@ -231,7 +231,7 @@
         the cases. As you can see, the compiler will produce a
         warning that we've missed a case, along with an example of
         an unmatched pattern:</p>
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="13"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="13"/>
         <p>Even for simple examples like this, exhaustiveness
         checks are pretty useful. But as we'll see in <a href="06-variants.html#variants" data-type="xref">Variants</a>,
@@ -260,7 +260,7 @@
       function <code>render_table</code> that, given a list of column
       headers and a list of rows, prints them out in a well-formatted
       text table, as follows:</p> <link rel="import"
-      href="code/lists-and-patterns/main.topscript" part="69"/>
+      href="code/lists-and-patterns/main.mlt" part="69"/>
       <p>The first step is to write a function to compute the
       maximum width of each column of data. We can do this by
@@ -276,17 +276,17 @@
       a list and a function for transforming elements of that list,
       and returns a new list with the transformed elements. Thus,
       we can write:<idx>List module/</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="14"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="14"/>
       <p><code>List.map2_exn</code> is similar to
       <code></code>, except that it takes two lists and a
       function for combining them. Thus, we might write:<idx>List
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="15"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="15"/>
       <p>The <code>_exn</code> is there because the function throws
       an exception if the lists are of mismatched length:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="16"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="16"/>
       <p><code>List.fold</code> is the most complicated of the
       three, taking three arguments: a list to process, an initial
@@ -296,22 +296,22 @@
       returning the final value of the accumulator when it's done.
       You can see some of this by looking at the type-signature for
       <code>fold</code>:<idx>List module/List.fold</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="17"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="17"/>
       <p>We can use <code>List.fold</code> for something as simple
       as summing up a list:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="18"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="18"/>
       <p>This example is particularly simple because the
       accumulator and the list elements are of the same type. But
       <code>fold</code> is not limited to such cases. We can for
       example use <code>fold</code> to reverse a list, in which
       case the accumulator is itself a list:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="19"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="19"/>
       <p>Let's bring our three functions together to compute the
       maximum column widths:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="20"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="20"/>
       <p>Using <code></code> we define the function
       <code>lengths</code>, which converts a list of strings to a
@@ -331,7 +331,7 @@
       of strings with an optional separator string, and
       <code>^</code>, which is a pairwise string concatenation
       function, to add the delimiters on the outside:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="21"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="21"/>
       <p>Note that we make the line of dashes two larger than the
       provided width to provide some whitespace around each entry
@@ -348,11 +348,11 @@
         pairwise operator. You should avoid <code>^</code> for
         joining long numbers of strings, since it allocates a new
         string every time it runs. Thus, the following code</p>
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="22"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="22"/>
         <p>will allocate strings of length 2, 3, 4, 5, 6 and 7,
         whereas this code</p>
-        <link rel="import" href="code/lists-and-patterns/main.topscript" part="23"/>
+        <link rel="import" href="code/lists-and-patterns/main.mlt" part="23"/>
         <p>allocates one string of size 7, as well as a list of
         length 7. At these small sizes, the differences don't
@@ -364,17 +364,17 @@
       We'll first write a function called <code>pad</code>, for
       padding out a string to a specified length plus one blank
       space on both sides:<idx>strings/padding of</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="24"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="24"/>
       <p>We can render a row of data by merging together the padded
       strings. Again, we'll use <code>List.map2_exn</code> for
       combining the list of data in the row with the list of
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="25"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="25"/>
       <p>Now we can bring this all together in a single function
       that renders the table:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="26"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="26"/>
       <section id="more-useful-list-functions" data-type="sect2">
         <h2>More Useful List Functions</h2>
@@ -403,14 +403,14 @@
           <p>Here's the type signature:</p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" part="27"/>
+          <link rel="import" href="code/lists-and-patterns/main.mlt" part="27"/>
           <p><code>reduce</code> returns an optional result,
           returning <code>None</code> when the input list is
           <p>Now we can see <code>reduce</code> in action:</p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" part="28"/>
+          <link rel="import" href="code/lists-and-patterns/main.mlt" part="28"/>
         <section id="filtering-with-list.filter-and-list.filter_map" data-type="sect3">
@@ -422,7 +422,7 @@
           doing that:<idx>lists/filtering values
           in</idx><idx>values/filtering with
           List.filter</idx><idx>List module/List.filter</idx></p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" part="29"/>
+          <link rel="import" href="code/lists-and-patterns/main.mlt" part="29"/>
           <p>Note that the <code>mod</code> used above is an infix
           operator, as described in <a href="02-variables-and-functions.html#variables-and-functions" data-type="xref">Variables And Functions</a>.</p>
@@ -442,7 +442,7 @@
             split a string on the rightmost appearance of a given
               removal</idx><idx>duplicates, removing</idx></p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" part="30"/>
+          <link rel="import" href="code/lists-and-patterns/main.mlt" part="30"/>
           <p>The preceding code is also an example of an Or
           pattern, which allows you to have multiple subpatterns
@@ -467,7 +467,7 @@
           List.partition_tf</idx><idx>lists/partitioning elements
           in</idx><idx>List module/List.partition_tf</idx></p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" 
+          <link rel="import" href="code/lists-and-patterns/main.mlt" 
@@ -485,26 +485,26 @@
 	    <idx>List module/List.append</idx></p> 
 	  <link rel="import" 
-		href="code/lists-and-patterns/main.topscript" part="32"/>
+		href="code/lists-and-patterns/main.mlt" part="32"/>
 	    There's also <code>@</code>, an operator equivalent
             of <code>List.append</code>.</p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" 
+          <link rel="import" href="code/lists-and-patterns/main.mlt" 
 	    In addition, there is <code>List.concat</code>, for
             concatenating a list of lists:</p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" 
+          <link rel="import" href="code/lists-and-patterns/main.mlt" 
           <p>Here's an example of using <code>List.concat</code> along
             with <code></code> to compute a recursive listing of
             a directory tree. </p> 
-	  <link rel="import" href="code/lists-and-patterns/main.topscript" 
+	  <link rel="import" href="code/lists-and-patterns/main.mlt" 
@@ -518,7 +518,7 @@
             <code>List.concat</code> is common enough that there is a
             function <code>List.concat_map</code> that combines these
             into one, more efficient operation:</p>
-          <link rel="import" href="code/lists-and-patterns/main.topscript" 
+          <link rel="import" href="code/lists-and-patterns/main.mlt" 
@@ -534,12 +534,12 @@
       module/List.init</idx><idx>lists/computing length
       of</idx><idx>tail recursion</idx> <idx>recursion/tail
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="37"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="37"/>
       <p>This looks simple enough, but you'll discover that this
       implementation runs into problems on very large lists, as
       we'll show in the following code:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="38"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="38"/>
       <p>The preceding example creates lists using
       <code>List.init</code>, which takes an integer <code>n</code>
@@ -564,7 +564,7 @@
       frames, which exhausted the available stack space. Happily,
       there's a way around this problem. Consider the following
       alternative implementation:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="39"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="39"/>
       <p>This implementation depends on a helper function,
       <code>length_plus_n</code>, that computes the length of a
@@ -586,7 +586,7 @@
       <code>length_plus_n</code> is indeed tail recursive, and as a
       result, <code>length</code> can take a long list as input
       without blowing the stack:<idx>tail calls</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="40"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="40"/>
       <p>So when is a call a tail call? Let's think about the
       situation where one function (the <em>caller</em>) invokes
@@ -618,7 +618,7 @@
       earlier:<idx>destutter function</idx><idx id="PTTRNMAT">pattern matching/terser and faster
       removal</idx><idx>duplicates, removing</idx></p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="41"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="41"/>
       <p>We'll consider some ways of making this code more concise
       and more efficient.</p>
@@ -635,13 +635,13 @@
       at it, we'll use the <code>function</code> keyword to
       eliminate the need for an explicit match:<idx>function
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="42"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="42"/>
 	We can further collapse this by combining the first two cases
 	into one, using an <em>or pattern</em>:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="43"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="43"/>
       <p>We can make the code slightly terser now by using a
       <code>when</code> clause. A <code>when</code> clause allows
@@ -649,7 +649,7 @@
       an arbitrary OCaml expression. In this case, we can use it to
       include the check on whether the first two elements are
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="44"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="44"/>
       <aside data-type="sidebar">
         <h5>Polymorphic Compare</h5>
@@ -661,7 +661,7 @@
           specialized to integers, as you can see if you try to apply
           it to values of a different type.</p>
-        <link rel="import" href="code/lists-and-patterns/poly.topscript" 
+        <link rel="import" href="code/lists-and-patterns/poly.mlt" 
@@ -669,14 +669,14 @@
 	  comparison operators, which we can make available by opening
 	  the module <code>Base.Poly</code>.</p>
-        <link rel="import" href="code/lists-and-patterns/poly.topscript" 
+        <link rel="import" href="code/lists-and-patterns/poly.mlt" 
 	  Indeed, if we look at the type of the equality operator,
           we'll see that it is polymorphic.</p>
-        <link rel="import" href="code/lists-and-patterns/poly.topscript" 
+        <link rel="import" href="code/lists-and-patterns/poly.mlt" 
@@ -685,7 +685,7 @@
 	  polymorphic type, and can now be used on inputs of different
-        <link rel="import" href="code/lists-and-patterns/poly.topscript" 
+        <link rel="import" href="code/lists-and-patterns/poly.mlt" 
@@ -716,7 +716,7 @@
           it will fail at runtime if it encounters a function
-        <link rel="import" href="code/lists-and-patterns/poly.topscript" 
+        <link rel="import" href="code/lists-and-patterns/poly.mlt" 
@@ -751,7 +751,7 @@
 	  of <code>Base</code> by opening the module again.
-        <link rel="import" href="code/lists-and-patterns/poly.topscript" 
+        <link rel="import" href="code/lists-and-patterns/poly.mlt" 
@@ -770,25 +770,25 @@
       are <code>Some</code>. Because this implementation uses
       <code>when</code> clauses, the compiler can't tell that the
       code is exhaustive:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="48"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="48"/>
       <p>Despite the warning, the function does work fine:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="49"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="49"/>
       <p>If we add another redundant case without a
       <code>when</code> clause, the compiler will stop complaining
       about exhaustiveness and won't produce a warning about the
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="50"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="50"/>
       <p>Probably a better approach is to simply drop the second
       <code>when</code> clause:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="51"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="51"/>
       <p>This is a little less clear, however, than the direct
       pattern-matching solution, where the meaning of each pattern
       is clearer on its own:</p>
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="52"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="52"/>
       <p>The takeaway from all of this is although
       <code>when</code> clauses can be useful, we should prefer
@@ -799,7 +799,7 @@
       it is not tail recursive. In real life, you would probably
       just use the <code>List.count</code> function from
-      <link rel="import" href="code/lists-and-patterns/main.topscript" part="53"/>
+      <link rel="import" href="code/lists-and-patterns/main.mlt" part="53"/>

+ 7 - 7

@@ -49,7 +49,7 @@
       <idx>lists/adding new bindings in</idx>
       <idx>lists/finding key associations in</idx></p>
-      <link rel="import" part="1" href="code/files-modules-and-programs/intro.topscript"/>
+      <link rel="import" part="1" href="code/files-modules-and-programs/intro.mlt"/>
       <p>Note that <code>List.Assoc.add</code> doesn't modify the
       original list, but instead allocates a new list with the
@@ -575,7 +575,7 @@
       that the compiler looks at to find the definition of various
       identifiers. Here's an example:</p>
-      <link rel="import" href="code/files-modules-and-programs/main.topscript" part="0.5"/>
+      <link rel="import" href="code/files-modules-and-programs/main.mlt" part="0.5"/>
       <p><code>open</code> is essential when you want to modify
       your environment for a standard library like
@@ -606,7 +606,7 @@
             opens. For example, you can write:</p>
 	  <link rel="import" 
-		href="code/files-modules-and-programs/main.topscript" 
+		href="code/files-modules-and-programs/main.mlt" 
 	  <p>Here, <code>of_int</code> and the infix operators are the
@@ -617,7 +617,7 @@
 	  <link rel="import" 
-		href="code/files-modules-and-programs/main.topscript" 
+		href="code/files-modules-and-programs/main.mlt" 
@@ -663,13 +663,13 @@
 	<idx>identifiers/adding to modules</idx></p>
-      <link rel="import" href="code/files-modules-and-programs/main.topscript" part="3"/>
+      <link rel="import" href="code/files-modules-and-programs/main.mlt" part="3"/>
       <p>We can use the <code>include</code> directive to create a
       new, extended version of the <code>Interval</code>
-      <link rel="import" href="code/files-modules-and-programs/main.topscript" part="4"/>
+      <link rel="import" href="code/files-modules-and-programs/main.mlt" part="4"/>
       <p>The difference between <code>include</code> and
       <code>open</code> is that we've done more than change how
@@ -677,7 +677,7 @@
       module. If we'd used <code>open</code>, we'd have gotten a
       quite different result:</p>
-      <link rel="import" href="code/files-modules-and-programs/main.topscript" part="5"/>
+      <link rel="import" href="code/files-modules-and-programs/main.mlt" part="5"/>
 	To consider a more realistic example, imagine you wanted to

+ 43 - 43

@@ -43,7 +43,7 @@
       Unix API, which you need <code>Core</code> for.
-    <link rel="import" part="0.5" href="code/records/main.topscript"/>
+    <link rel="import" part="0.5" href="code/records/main.mlt"/>
     <p>We can construct a <code>service_info</code> just as easily
     as we declared its type. The following function tries to
@@ -53,11 +53,11 @@
     don't know how regular expressions work, you can just think of
     them as a simple pattern language you can use for parsing a
-    <link rel="import" href="code/records/main.topscript" part="1"/>
+    <link rel="import" href="code/records/main.mlt" part="1"/>
     <p>We can construct a concrete record by calling the function
     on a line from the file.</p>
-    <link rel="import" href="code/records/main.topscript" part="1.1"/>
+    <link rel="import" href="code/records/main.mlt" part="1.1"/>
     <p>You might wonder how the compiler inferred that our function
     returns a value of type <code>service_info</code>. In this
@@ -69,28 +69,28 @@
     <p>Once we have a record value in hand, we can extract elements
     from the record field using dot notation:</p>
-    <link rel="import" href="code/records/main.topscript" part="2"/>
+    <link rel="import" href="code/records/main.mlt" part="2"/>
     <p>When declaring an OCaml type, you always have the option of
     parameterizing it by a polymorphic type. Records are no
     different in this regard. As an example, here's a type that
     represents an arbitrary item tagged with a line number.</p>
-    <link rel="import" href="code/records/main.topscript" part="3"/>
+    <link rel="import" href="code/records/main.mlt" part="3"/>
     <p>We can then write polymorphic functions that operate over
     this parameterized type. For example, this function takes a
     file and parses it as a series of lines, using the provided
     function for parsing each individual line.</p>
-    <link rel="import" href="code/records/main.topscript" part="4"/>
+    <link rel="import" href="code/records/main.mlt" part="4"/>
     <p>We can then use this function for parsing a snippet of a
     real <code>/etc/services</code> file.</p>
-    <link rel="import" href="code/records/main.topscript" part="4.1"/>
+    <link rel="import" href="code/records/main.mlt" part="4.1"/>
     <p>The polymorphism lets us use the same function when parsing
     a different format, like this function for parsing a file
     containing an integer on every line.</p>
-    <link rel="import" href="code/records/main.topscript" part="4.2"/>
+    <link rel="import" href="code/records/main.mlt" part="4.2"/>
     <section id="patterns-and-exhaustiveness" data-type="sect1">
       <h1>Patterns and Exhaustiveness</h1>
@@ -100,7 +100,7 @@
       function.<idx>pattern matching/and
       exhaustiveness</idx><idx>records/patterns and exhaustiveness
-      <link rel="import" href="code/records/main.topscript" part="5"/>
+      <link rel="import" href="code/records/main.mlt" part="5"/>
       <p>Note that the pattern we used had only a single case,
       rather than using several cases separated by
@@ -128,7 +128,7 @@
       of <code>service_info</code> that includes
       a <code>comment</code> field:</p>
-      <link rel="import" href="code/records/main.topscript" part="6"/>
+      <link rel="import" href="code/records/main.mlt" part="6"/>
       <p>The code for <code>service_info_to_string</code> would
       continue to compile without change. But in this case, we
@@ -145,12 +145,12 @@
       compilers/warning enable/disable</idx><idx>errors/missing
       field warnings</idx><idx>records/missing field
-      <link rel="import" href="code/records/main.topscript" part="7"/>
+      <link rel="import" href="code/records/main.mlt" part="7"/>
       <p>We can disable the warning for a given pattern by
       explicitly acknowledging that we are ignoring extra fields.
       This is done by adding an underscore to the pattern:</p>
-      <link rel="import" href="code/records/main.topscript" part="8"/>
+      <link rel="import" href="code/records/main.mlt" part="8"/>
       <p>It's a good idea to enable the warning for incomplete
       record matches and to explicitly disable it with an
@@ -201,13 +201,13 @@
       of the fields in question to variables of the same name. This
       is called <em>field punning</em>:<idx>fields/field
       punning</idx><idx>records/field punning in</idx></p>
-      <link rel="import" href="code/records/main.topscript" part="9"/>
+      <link rel="import" href="code/records/main.mlt" part="9"/>
       <p>Field punning can also be used to construct a record.
       Consider the following updated version of
-      <link rel="import" href="code/records/main.topscript" part="10"/>
+      <link rel="import" href="code/records/main.mlt" part="10"/>
       <p>In the preceding code, we defined variables corresponding
       to the record fields first, and then the record declaration
@@ -216,11 +216,11 @@
       punning when writing a function for constructing a record
       from labeled arguments:<idx>label
       punning</idx><idx>records/label punning in</idx></p>
-      <link rel="import" href="code/records/main.topscript" part="11"/>
+      <link rel="import" href="code/records/main.mlt" part="11"/>
       <p>This is considerably more concise than what you would get
       without punning:</p>
-      <link rel="import" href="code/records/main.topscript" part="12"/>
+      <link rel="import" href="code/records/main.mlt" part="12"/>
       <p>Together, field and label punning encourage a style where
       you propagate the same names throughout your codebase. This
@@ -250,25 +250,25 @@
       connected. All of these messages include a session ID and the
       time the message was generated.</p>
-      <link rel="import" href="code/records/main.topscript" part="13"/>
+      <link rel="import" href="code/records/main.mlt" part="13"/>
       <p>Reusing field names can lead to some ambiguity. For
       example, if we want to write a function to grab the
       <code>session_id</code> from a record, what type will it
-      <link rel="import" href="code/records/main.topscript" part="14"/>
+      <link rel="import" href="code/records/main.mlt" part="14"/>
       <p>In this case, OCaml just picks the most recent definition
       of that record field. We can force OCaml to assume we're
       dealing with a different type (say, a <code>heartbeat</code>)
       using a type annotation:</p>
-      <link rel="import" href="code/records/main.topscript" part="15"/>
+      <link rel="import" href="code/records/main.mlt" part="15"/>
       <p>While it's possible to resolve ambiguous field names using
       type annotations, the ambiguity can be a bit confusing.
       Consider the following functions for grabbing the session ID
       and status from a heartbeat:</p>
-      <link rel="import" href="code/records/main.topscript" part="16"/>
+      <link rel="import" href="code/records/main.mlt" part="16"/>
       <p>Why did the first definition succeed without a type
       annotation and the second one fail? The difference is that in
@@ -289,11 +289,11 @@
       style, it is standard practice to name the type associated
       with the module <code>t</code>. Using this style we would
-      <link rel="import" href="code/records/main2.topscript" part="17"/>
+      <link rel="import" href="code/records/main2.mlt" part="17"/>
       <p>Now, our log-entry-creation function can be rendered as
-      <link rel="import" href="code/records/main2.topscript" part="18"/>
+      <link rel="import" href="code/records/main2.mlt" part="18"/>
       <p>The module name <code>Log_entry</code> is required to
       qualify the fields, because this function is outside of the
@@ -302,27 +302,27 @@
       field, however, so we can write this more concisely. Note
       that we are allowed to insert whitespace between the module
       path and the field name:</p>
-      <link rel="import" href="code/records/main2.topscript" part="19"/>
+      <link rel="import" href="code/records/main2.mlt" part="19"/>
       <p>Earlier, we saw that you could help OCaml understand which
       record field was intended by adding a type annotation. Let's see
       what happens if we try that here.</p>
-      <link rel="import" href="code/records/main2.topscript"
+      <link rel="import" href="code/records/main2.mlt"
       <p>This triggers warning 40, showing that a type annotation
       causes the selection of an identifier in a different module. If
       we disable warning 40, this definition goes through without
-      <link rel="import" href="code/records/main2.topscript" part="19.2"/>
+      <link rel="import" href="code/records/main2.mlt" part="19.2"/>
       <p>This is not restricted to constructing a record; we can
       use the same trick when pattern matching:</p>
-      <link rel="import" href="code/records/main2.topscript" part="20"/>
+      <link rel="import" href="code/records/main2.mlt" part="20"/>
       <p>When using dot notation for accessing record fields, we
       can qualify the field by the module as well.</p>
-      <link rel="import" href="code/records/main2.topscript" part="21"/>
+      <link rel="import" href="code/records/main2.mlt" part="21"/>
       <p>The syntax here is a little surprising when you first
       encounter it. The thing to keep in mind is that the dot is
@@ -342,7 +342,7 @@
       by adding type annotations and removing the module
-      <link rel="import" href="code/records/main2.topscript" part="21.1"/>
+      <link rel="import" href="code/records/main2.mlt" part="21.1"/>
       <p>This feature of the language, known by the somewhat imposing
       name of <em>type-directed constructor disambiguation</em>,
@@ -371,7 +371,7 @@
       client information when a new heartbeat
       arrives:<idx>functional updates</idx><idx>records/functional
       updates to</idx></p>
-      <link rel="import" href="code/records/main2.topscript" part="22"/>
+      <link rel="import" href="code/records/main2.mlt" part="22"/>
       <p>This is fairly verbose, given that there's only one field
       that we actually want to change, and all the others are just
@@ -386,7 +386,7 @@
       <p>Given this, we can rewrite <code>register_heartbeat</code>
       more concisely:</p>
-      <link rel="import" href="code/records/main2.topscript" part="23"/>
+      <link rel="import" href="code/records/main2.mlt" part="23"/>
       <p>Functional updates make your code independent of the
       identity of the fields in the record that are not changing.
@@ -397,7 +397,7 @@
       the new fields. Consider what happens if we decided to add a
       field for the status message received on the last
-      <link rel="import" href="code/records/main2.topscript" part="24"/>
+      <link rel="import" href="code/records/main2.mlt" part="24"/>
       <p>The original implementation of
       <code>register_heartbeat</code> would now be invalid, and
@@ -406,7 +406,7 @@
       functional update continues to compile as is, even though it
       incorrectly ignores the new field. The correct thing to do
       would be to update the code as follows:</p>
-      <link rel="import" href="code/records/main2.topscript" part="25"/>
+      <link rel="import" href="code/records/main2.mlt" part="25"/>
     <section id="mutable-fields" data-type="sect1">
@@ -417,13 +417,13 @@
       mutable. In the following code, we've made the last two
       fields of <code>client_info</code> mutable:<idx>mutable
       record fields</idx><idx>records/mutable fields in</idx></p>
-      <link rel="import" href="code/records/main2.topscript" part="26"/>
+      <link rel="import" href="code/records/main2.mlt" part="26"/>
       <p>The <code>&lt;-</code> operator is used for setting a
       mutable field. The side-effecting version of
       <code>register_heartbeat</code> would be written as
-      <link rel="import" href="code/records/main2.topscript" part="27"/>
+      <link rel="import" href="code/records/main2.mlt" part="27"/>
       <p>Note that mutable assignment, and thus the
       <code>&lt;-</code> operator, is not needed for initialization
@@ -441,7 +441,7 @@
       <p>Consider the following function for extracting the
       usernames from a list of <code>Logon</code> messages:<idx id="Ffc">fields/first-class fields</idx><idx id="firstclass">first-class fields</idx><idx id="RECfirstclass">records/first-class fields in</idx></p>
-      <link rel="import" href="code/records/main2.topscript" part="28"/>
+      <link rel="import" href="code/records/main2.mlt" part="28"/>
       <p>Here, we wrote a small function <code>(fun x -&gt;
       x.Logon.user)</code> to access the <code>user</code> field.
@@ -455,7 +455,7 @@
       the declaration of a record type will cause the extension to be
       applied to a given type declaration. So, for example, we could
       have defined <code>Logon</code> as follows:</p>
-      <link rel="import" href="code/records/main2.topscript"
+      <link rel="import" href="code/records/main2.mlt"
       <p>Note that this will generate <em>a lot</em> of output
@@ -468,7 +468,7 @@
       <p>One of the functions we obtain is <code>Logon.user</code>,
       which we can use to extract the user field from a logon
-      <link rel="import" href="code/records/main2.topscript" part="30"/>
+      <link rel="import" href="code/records/main2.mlt" part="30"/>
       <p>In addition to generating field accessor functions,
       <code>fieldslib</code> also creates a submodule called
@@ -519,7 +519,7 @@
       <code>Logon.Fields.user</code>, you'll get a function for
       extracting the <code>user</code> field from a
-      <link rel="import" href="code/records/main2.topscript" part="31"/>
+      <link rel="import" href="code/records/main2.mlt" part="31"/>
       <p>Thus, the first parameter of the <code>Field.t</code>
       corresponds to the record you pass to <code>get</code>, and
@@ -530,7 +530,7 @@
       <p>The type of <code>Field.get</code> is a little more
       complicated than you might naively expect from the preceding
-      <link rel="import" href="code/records/main2.topscript" part="32"/>
+      <link rel="import" href="code/records/main2.mlt" part="32"/>
       <p>The type is <code>Field.t_with_perm</code> rather than
       <code>Field.t</code> because fields have a notion of access
@@ -541,7 +541,7 @@
       <p>We can use first-class fields to do things like write a
       generic function for displaying a record field:</p>
-      <link rel="import" href="code/records/main2.topscript" part="33"/>
+      <link rel="import" href="code/records/main2.mlt" part="33"/>
       <p>This takes three arguments: the <code>Field.t</code>, a
       function for converting the contents of the field in question
@@ -550,7 +550,7 @@
       <p>Here's an example of <code>show_field</code> in
-      <link rel="import" href="code/records/main2.topscript" part="34"/>
+      <link rel="import" href="code/records/main2.mlt" part="34"/>
       <p>As a side note, the preceding example is our first use of
       the <code>Fn</code> module (short for "function"), which
@@ -563,7 +563,7 @@
       of a record. So, for example, in the case of
       <code>Logon.t</code>, the field iterator has the following
-      <link rel="import" href="code/records/main2.topscript" part="35"/>
+      <link rel="import" href="code/records/main2.mlt" part="35"/>
       <p>This is a bit daunting to look at, largely because of the
       access control markers, but the structure is actually pretty
@@ -578,7 +578,7 @@
       <p>Now, let's use <code>Logon.Fields.iter</code> and
       <code>show_field</code> to print out all the fields of a
       <code>Logon</code> record:</p>
-      <link rel="import" href="code/records/main2.topscript" part="36"/>
+      <link rel="import" href="code/records/main2.mlt" part="36"/>
       <p>One nice side effect of this approach is that it helps you
       adapt your code when the fields of a record change. If you

+ 45 - 45

@@ -43,7 +43,7 @@
       the different cases. Note that variant tags must be
-    <link rel="import" href="code/variants/main.topscript" part="0.5"/>
+    <link rel="import" href="code/variants/main.mlt" part="0.5"/>
       The following function uses pattern matching to convert
@@ -51,13 +51,13 @@
       exhaustiveness checking on pattern matches means that the
       compiler will warn us if we miss a color:</p>
-    <link rel="import" href="code/variants/main.topscript" part="1"/>
+    <link rel="import" href="code/variants/main.mlt" part="1"/>
       Using the preceding function, we can generate escape codes to
       change the color of a given string displayed in a terminal:</p>
-    <link rel="import" href="code/variants/main.topscript" part="2"/>
+    <link rel="import" href="code/variants/main.mlt" part="2"/>
       On most terminals, that word "Blue" will be rendered in
@@ -90,7 +90,7 @@
       variants can have multiple arguments, which are separated
       by <code>*</code>s:</p>
-    <link rel="import" href="code/variants/main.topscript" part="3"/>
+    <link rel="import" href="code/variants/main.mlt" part="3"/>
       Once again, we'll use pattern matching to convert a color to a
@@ -98,11 +98,11 @@
       does more than separate out the different cases; it also allows
       us to extract the data associated with each tag:</p>
-    <link rel="import" href="code/variants/main.topscript" part="4"/>
+    <link rel="import" href="code/variants/main.mlt" part="4"/>
     <p>Now, we can print text using the full set of available
-    <link rel="import" href="code/variants/main.topscript" part="5"/>
+    <link rel="import" href="code/variants/main.mlt" part="5"/>
     <section id="catch-all-cases-and-refactoring" data-type="sect1">
       <h1>Catch-All Cases and Refactoring</h1>
@@ -122,7 +122,7 @@
       <p>Consider what would happen if we were to change the
       definition of <code>color</code> to the following:</p>
-      <link rel="import" href="code/variants/catch_all.topscript" part="1"/>
+      <link rel="import" href="code/variants/catch_all.mlt" part="1"/>
       <p>We've essentially broken out the <code>Basic</code> case
       into two cases, <code>Basic</code> and <code>Bold</code>, and
@@ -132,19 +132,19 @@
       that same code again, the compiler will notice the
-      <link rel="import" href="code/variants/catch_all.topscript" part="2"/>
+      <link rel="import" href="code/variants/catch_all.mlt" part="2"/>
       <p>Here, the compiler is complaining that the <code>Basic</code>
       tag is used with the wrong number of arguments. If we fix that,
       however, the compiler will flag a second problem, which is that
       we haven't handled the new <code>Bold</code> tag:</p>
-      <link rel="import" href="code/variants/catch_all.topscript" part="3"/>
+      <link rel="import" href="code/variants/catch_all.mlt" part="3"/>
       <p>Fixing this now leads us to the correct
-      <link rel="import" href="code/variants/catch_all.topscript" part="4"/>
+      <link rel="import" href="code/variants/catch_all.mlt" part="4"/>
       <p>As we've seen, the type errors identified the things that
       needed to be fixed to complete the refactoring of the code.
@@ -164,12 +164,12 @@
       <idx>exhaustion checks</idx></p>
-      <link rel="import" href="code/variants/catch_all.topscript" part="5"/>
+      <link rel="import" href="code/variants/catch_all.mlt" part="5"/>
       <p>If we then applied the same fix we did above, we would have
       ended up with this.</p>
-      <link rel="import" href="code/variants/catch_all.topscript" part="6"/>
+      <link rel="import" href="code/variants/catch_all.mlt" part="6"/>
 	Because of the catch-all case, we'll no longer be warned about
@@ -202,7 +202,7 @@
       <a href="05-records.html#records" data-type="xref">Records</a>. We'll start by reminding ourselves of the
       definition of <code>Log_entry.t</code>:</p>
-      <link rel="import" href="code/variants/logger.topscript" part="1"/>
+      <link rel="import" href="code/variants/logger.mlt" part="1"/>
       <p>This record type combines multiple pieces of data into one
       value. In particular, a single <code>Log_entry.t</code> has a
@@ -212,7 +212,7 @@
       types as conjunctions. Variants, on the other hand, are
       disjunctions, letting you represent multiple possibilities,
       as in the following example:</p>
-      <link rel="import" href="code/variants/logger.topscript" part="2"/>
+      <link rel="import" href="code/variants/logger.mlt" part="2"/>
       <p>A <code>client_message</code> is a <code>Logon</code>
       <em>or</em> a <code>Heartbeat</code> <em>or</em> a
@@ -245,7 +245,7 @@
       <p>Here's the concrete code:</p>
-      <link rel="import" href="code/variants/logger.topscript" part="3"/>
+      <link rel="import" href="code/variants/logger.mlt" part="3"/>
       <p>Note that we take advantage of the fact that the type of the
       record <code>m</code> is known in the above code, so we don't
@@ -266,15 +266,15 @@
       different messages. The first step is to cut down the
       definitions of each per-message record to contain just the
       information unique to that record:</p>
-      <link rel="import" href="code/variants/logger.topscript" part="4"/>
+      <link rel="import" href="code/variants/logger.mlt" part="4"/>
       <p>We can then define a variant type that combines these
-      <link rel="import" href="code/variants/logger.topscript" part="5"/>
+      <link rel="import" href="code/variants/logger.mlt" part="5"/>
       <p>Separately, we need a record that contains the fields that
       are common across all messages:</p>
-      <link rel="import" href="code/variants/logger.topscript" part="6"/>
+      <link rel="import" href="code/variants/logger.mlt" part="6"/>
       <p>A full message can then be represented as a pair of
       a <code>Common.t</code> and a <code>details</code>. Using this,
@@ -283,7 +283,7 @@
       fields correctly. Otherwise, we'd need to qualify them
-      <link rel="import" href="code/variants/logger.topscript"
+      <link rel="import" href="code/variants/logger.mlt"
       <p>As you can see, the code for extracting the session ID has
@@ -298,7 +298,7 @@
       message.  Thus, if we had functions for handling individual
       message types, we could write a dispatch function as
       follows:</p> <link rel="import"
-      href="code/variants/logger.topscript" part="8"/>
+      href="code/variants/logger.mlt" part="8"/>
 	And it's explicit at the type level that
@@ -316,14 +316,14 @@
 	  separately from the variant, then OCaml allows us to embed
 	  the records directly into the variant.</p>
-	<link rel="import" href="code/variants/logger.topscript"
+	<link rel="import" href="code/variants/logger.mlt"
 	<p>Even though the type is different, we can
 	  write <code>messages_for_user</code> in essentially the same
 	  way we did before.</p>
-	<link rel="import" href="code/variants/logger.topscript"
+	<link rel="import" href="code/variants/logger.mlt"
 	<p>Variants with inline records are both more concise and more
@@ -337,7 +337,7 @@
 	  object. And, as you can see below, OCaml will reject code
 	  that tries to do so.</p>
-	<link rel="import" href="code/variants/logger.topscript"
+	<link rel="import" href="code/variants/logger.mlt"