Import Upstream version 20180207

[hcoop/debian/mlton.git] / doc / guide / src / mlton-guide.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<?asciidoc-toc?>
<?asciidoc-numbered?>

<article lang="en">
<articleinfo>
    <title>MLton Guide (20180207)</title>
</articleinfo>
<abstract>
<simpara>This is the guide for MLton, an open-source, whole-program, optimizing Standard ML compiler.</simpara>
<simpara>This guide was generated automatically from the MLton website, available online at <ulink url="http://mlton.org">http://mlton.org</ulink>. It is up to date for MLton 20180207.</simpara>
</abstract>
<section id="Home">
<title>MLton</title>
<section id="_what_is_mlton">
<title>What is MLton?</title>
<simpara>MLton is an open-source, whole-program, optimizing
<link linkend="StandardML">Standard ML</link> compiler.</simpara>
</section>
<section id="_what_8217_s_new">
<title>What&#8217;s new?</title>
<itemizedlist>
<listitem>
<simpara>
20180207: Please try out our latest release, <link linkend="Release20180207">MLton 20180207</link>.
</simpara>
</listitem>
<listitem>
<simpara>
20140730: <ulink url="http://www.cs.rit.edu/%7emtf">Matthew Fluet</ulink> and
  <ulink url="http://www.cse.buffalo.edu/%7elziarek">Lukasz Ziarek</ulink> have been
  awarded an <ulink url="http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=12810">NSF
  CISE Research Infrastructure (CRI)</ulink> grant titled "Positioning MLton
  for Next-Generation Programming Languages Research;" read the award
  abstracts
  (<ulink url="http://www.nsf.gov/awardsearch/showAward?AWD_ID=1405770">Award&#160;#1405770</ulink>
  and
  <ulink url="http://www.nsf.gov/awardsearch/showAward?AWD_ID=1405614">Award&#160;#1405614</ulink>)
  for more details.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_next_steps">
<title>Next steps</title>
<itemizedlist>
<listitem>
<simpara>
Read about MLton&#8217;s <link linkend="Features">Features</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Look at <link linkend="Documentation">Documentation</link>.
</simpara>
</listitem>
<listitem>
<simpara>
See some <link linkend="Users">Users</link> of MLton.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://sourceforge.net/projects/mlton/files/mlton/20180207">Download</ulink> MLton.
</simpara>
</listitem>
<listitem>
<simpara>
Meet the MLton <link linkend="Developers">Developers</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Get involved with MLton <link linkend="Development">Development</link>.
</simpara>
</listitem>
<listitem>
<simpara>
User-maintained <link linkend="FAQ">FAQ</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Contact">Contact</link> us.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="AdamGoode">
<title>AdamGoode</title>
<itemizedlist>
<listitem>
<simpara>
I maintain the Fedora package of MLton, in <ulink url="https://admin.fedoraproject.org/pkgdb/packages/name/mlton">Fedora</ulink>.
</simpara>
</listitem>
<listitem>
<simpara>
I have contributed some patches for Makefiles and PDF documentation building.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="AdmitsEquality">
<title>AdmitsEquality</title>
<simpara>A <link linkend="TypeConstructor">TypeConstructor</link> admits equality if whenever it is applied to
equality types, the result is an <link linkend="EqualityType">EqualityType</link>.  This notion enables
one to determine whether a type constructor application yields an
equality type solely from the application, without looking at the
definition of the type constructor.  It helps to ensure that
<link linkend="PolymorphicEquality">PolymorphicEquality</link> is only applied to sensible values.</simpara>
<simpara>The definition of admits equality depends on whether the type
constructor was declared by a <literal>type</literal> definition or a
<literal>datatype</literal> declaration.</simpara>
<section id="_type_definitions">
<title>Type definitions</title>
<simpara>For type definition</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a1, ..., 'an) t = ...</programlisting>
<simpara>type constructor <literal>t</literal> admits equality if the right-hand side of the
definition is an equality type after replacing <literal>'a1</literal>, &#8230;,
<literal>'an</literal> by equality types (it doesn&#8217;t matter which equality types
are chosen).</simpara>
<simpara>For a nullary type definition, this amounts to the right-hand side
being an equality type.  For example, after the definition</simpara>
<programlisting language="sml" linenumbering="unnumbered">type t = bool * int</programlisting>
<simpara>type constructor <literal>t</literal> admits equality because <literal>bool * int</literal> is
an equality type.   On the other hand, after the definition</simpara>
<programlisting language="sml" linenumbering="unnumbered">type t = bool * int * real</programlisting>
<simpara>type constructor <literal>t</literal> does not admit equality, because <literal>real</literal>
is not an equality type.</simpara>
<simpara>For another example, after the definition</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a t = bool * 'a</programlisting>
<simpara>type constructor <literal>t</literal> admits equality because <literal>bool * int</literal>
is an equality type (we could have chosen any equality type other than
<literal>int</literal>).</simpara>
<simpara>On the other hand, after the definition</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a t = real * 'a</programlisting>
<simpara>type constructor <literal>t</literal> does not admit equality because
<literal>real * int</literal> is not equality type.</simpara>
<simpara>We can check that a type constructor admits equality using an
<literal>eqtype</literal> specification.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Ok: sig eqtype 'a t end =
   struct
      type 'a t = bool * 'a
   end</programlisting>
<programlisting language="sml" linenumbering="unnumbered">structure Bad: sig eqtype 'a t end =
   struct
      type 'a t = real * int * 'a
   end</programlisting>
<simpara>On <literal>structure Bad</literal>, MLton reports the following error.</simpara>
<screen>Error: z.sml 1.16-1.34.
  Type in structure disagrees with signature (admits equality): t.
    structure: type 'a t = [real] * _ * _
    defn at: z.sml 3.15-3.15
    signature: [eqtype] 'a t
    spec at: z.sml 1.30-1.30</screen>
<simpara>The <literal>structure:</literal> section provides an explanation of why the type
did not admit equality, highlighting the problematic component
(<literal>real</literal>).</simpara>
</section>
<section id="_datatype_declarations">
<title>Datatype declarations</title>
<simpara>For a type constructor declared by a datatype declaration to admit
equality, every <link linkend="Variant">variant</link> of the datatype must admit equality.  For
example, the following datatype admits equality because <literal>bool</literal> and
<literal>char * int</literal> are equality types.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A of bool | B of char * int</programlisting>
<simpara>Nullary constructors trivially admit equality, so that the following
datatype admits equality.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B | C</programlisting>
<simpara>For a parameterized datatype constructor to admit equality, we
consider each <link linkend="Variant">variant</link> as a type definition, and require that the
definition admit equality.  For example, for the datatype</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of bool * 'a | B of 'a</programlisting>
<simpara>the type definitions</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a tA = bool * 'a
type 'a tB = 'a</programlisting>
<simpara>both admit equality.  Thus, type constructor <literal>t</literal> admits equality.</simpara>
<simpara>On the other hand, the following datatype does not admit equality.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of bool * 'a | B of real * 'a</programlisting>
<simpara>As with type definitions, we can check using an <literal>eqtype</literal>
specification.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Bad: sig eqtype 'a t end =
   struct
      datatype 'a t = A of bool * 'a | B of real * 'a
   end</programlisting>
<simpara>MLton reports the following error.</simpara>
<screen>Error: z.sml 1.16-1.34.
  Type in structure disagrees with signature (admits equality): t.
    structure: datatype 'a t = B of [real] * _ | ...
    defn at: z.sml 3.19-3.19
    signature: [eqtype] 'a t
    spec at: z.sml 1.30-1.30</screen>
<simpara>MLton indicates the problematic constructor (<literal>B</literal>), as well as
the problematic component of the constructor&#8217;s argument.</simpara>
<section id="_recursive_datatypes">
<title>Recursive datatypes</title>
<simpara>A recursive datatype like</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of int * t</programlisting>
<simpara>introduces a new problem, since in order to decide whether <literal>t</literal>
admits equality, we need to know for the <literal>B</literal> <link linkend="Variant">variant</link> whether
<literal>t</literal> admits equality.  The <link linkend="DefinitionOfStandardML">Definition</link>
answers this question by requiring a type constructor to admit
equality if it is consistent to do so.  So, in our above example, if
we assume that <literal>t</literal> admits equality, then the <link linkend="Variant">variant</link>
<literal>B of int * t</literal> admits equality.  Then, since the <literal>A</literal> <link linkend="Variant">variant</link>
trivially admits equality, so does the type constructor <literal>t</literal>.
Thus, it was consistent to assume that <literal>t</literal> admits equality, and
so, <literal>t</literal> does admit equality.</simpara>
<simpara>On the other hand, in the following declaration</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of real * t</programlisting>
<simpara>if we assume that <literal>t</literal> admits equality, then the <literal>B</literal> <link linkend="Variant">variant</link>
does not admit equality.  Hence, the type constructor <literal>t</literal> does not
admit equality, and our assumption was inconsistent.  Hence, <literal>t</literal>
does not admit equality.</simpara>
<simpara>The same kind of reasoning applies to mutually recursive datatypes as
well.  For example, the following defines both <literal>t</literal> and <literal>u</literal> to
admit equality.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of u
and u = C | D of t</programlisting>
<simpara>But the following defines neither <literal>t</literal> nor <literal>u</literal> to admit
equality.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of u * real
and u = C | D of t</programlisting>
<simpara>As always, we can check whether a type admits equality using an
<literal>eqtype</literal> specification.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Bad: sig eqtype t eqtype u end =
   struct
      datatype t = A | B of u * real
      and u = C | D of t
   end</programlisting>
<simpara>MLton reports the following error.</simpara>
<screen>Error: z.sml 1.16-1.40.
  Type in structure disagrees with signature (admits equality): t.
    structure: datatype t = B of [_str.u] * [real] | ...
    defn at: z.sml 3.16-3.16
    signature: [eqtype] t
    spec at: z.sml 1.27-1.27
Error: z.sml 1.16-1.40.
  Type in structure disagrees with signature (admits equality): u.
    structure: datatype u = D of [_str.t] | ...
    defn at: z.sml 4.11-4.11
    signature: [eqtype] u
    spec at: z.sml 1.36-1.36</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="Alice">
<title>Alice</title>
<simpara><ulink url="http://www.ps.uni-saarland.de/alice">Alice ML</ulink> is an extension of SML with
concurrency, dynamic typing, components, distribution, and constraint
solving.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="AllocateRegisters">
<title>AllocateRegisters</title>
<simpara><link linkend="AllocateRegisters">AllocateRegisters</link> is an analysis pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ToMachine">ToMachine</link>.</simpara>
<section id="_description">
<title>Description</title>
<simpara>Computes an allocation of <link linkend="RSSA">RSSA</link> variables as <link linkend="Machine">Machine</link> register
or stack operands.</simpara>
</section>
<section id="_implementation">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/allocate-registers.sig"><literal>allocate-registers.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/allocate-registers.fun"><literal>allocate-registers.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="AndreiFormiga">
<title>AndreiFormiga</title>
<simpara>I&#8217;m a graduate student just back in academia. I study concurrent and parallel systems, with a great deal of interest in programming languages (theory, design, implementation). I happen to like functional languages.</simpara>
<simpara>I use the nickname tautologico on #sml and my email is andrei DOT formiga AT gmail DOT com.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ArrayLiteral">
<title>ArrayLiteral</title>
<simpara><link linkend="StandardML">Standard ML</link> does not have a syntax for array literals or
vector literals.  The only way to write down an array is like</simpara>
<programlisting language="sml" linenumbering="unnumbered">Array.fromList [w, x, y, z]</programlisting>
<simpara>No SML compiler produces efficient code for the above expression.  The
generated code allocates a list and then converts it to an array.  To
alleviate this, one could write down the same array using
<literal>Array.tabulate</literal>, or even using <literal>Array.array</literal> and <literal>Array.update</literal>, but
that is syntactically unwieldy.</simpara>
<simpara>Fortunately, using <link linkend="Fold">Fold</link>, it is possible to define constants <literal>A</literal>,
and <literal>&grave;</literal> so that one can write down an array like:</simpara>
<programlisting language="sml" linenumbering="unnumbered">A `w `x `y `z $</programlisting>
<simpara>This is as syntactically concise as the <literal>fromList</literal> expression.
Furthermore, MLton, at least, will generate the efficient code as if
one had written down a use of <literal>Array.array</literal> followed by four uses of
<literal>Array.update</literal>.</simpara>
<simpara>Along with <literal>A</literal> and <literal>&grave;</literal>, one can define a constant <literal>V</literal> that makes
it possible to define vector literals with the same syntax, e.g.,</simpara>
<programlisting language="sml" linenumbering="unnumbered">V `w `x `y `z $</programlisting>
<simpara>Note that the same element indicator, <literal>&grave;</literal>, serves for both array
and vector literals.  Of course, the <literal>$</literal> is the end-of-arguments
marker always used with <link linkend="Fold">Fold</link>.  The only difference between an
array literal and vector literal is the <literal>A</literal> or <literal>V</literal> at the beginning.</simpara>
<simpara>Here is the implementation of <literal>A</literal>, <literal>V</literal>, and <literal>&grave;</literal>.  We place them
in a structure and use signature abstraction to hide the type of the
accumulator.  See <link linkend="Fold">Fold</link> for more on this technique.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Literal:&gt;
   sig
      type 'a z
      val A: ('a z, 'a z, 'a array, 'd) Fold.t
      val V: ('a z, 'a z, 'a vector, 'd) Fold.t
      val ` : ('a, 'a z, 'a z, 'b, 'c, 'd) Fold.step1
   end =
   struct
      type 'a z = int * 'a option * ('a array -&gt; unit)

      val A =
         fn z =&gt;
         Fold.fold
         ((0, NONE, ignore),
          fn (n, opt, fill) =&gt;
          case opt of
             NONE =&gt;
                Array.tabulate (0, fn _ =&gt; raise Fail "array0")
           | SOME x =&gt;
                let
                   val a = Array.array (n, x)
                   val () = fill a
                in
                   a
                end)
         z

      val V = fn z =&gt; Fold.post (A, Array.vector) z

      val ` =
         fn z =&gt;
         Fold.step1
         (fn (x, (i, opt, fill)) =&gt;
          (i + 1,
           SOME x,
           fn a =&gt; (Array.update (a, i, x); fill a)))
         z
   end</programlisting>
<simpara>The idea of the code is for the fold to accumulate a count of the
number of elements, a sample element, and a function that fills in all
the elements.  When the fold is complete, the finishing function
allocates the array, applies the fill function, and returns the array.
The only difference between <literal>A</literal> and <literal>V</literal> is at the very end; <literal>A</literal> just
returns the array, while <literal>V</literal> converts it to a vector using
post-composition, which is further described on the <link linkend="Fold">Fold</link> page.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="AST">
<title>AST</title>
<simpara><link linkend="AST">AST</link> is the <link linkend="IntermediateLanguage">IntermediateLanguage</link> produced by the <link linkend="FrontEnd">FrontEnd</link>
and translated by <link linkend="Elaborate">Elaborate</link> to <link linkend="CoreML">CoreML</link>.</simpara>
<section id="_description_2">
<title>Description</title>
<simpara>The abstract syntax tree produced by the <link linkend="FrontEnd">FrontEnd</link>.</simpara>
</section>
<section id="_implementation_2">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ast/ast-programs.sig"><literal>ast-programs.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ast/ast-programs.fun"><literal>ast-programs.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ast/ast-modules.sig"><literal>ast-modules.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ast/ast-modules.fun"><literal>ast-modules.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ast/ast-core.sig"><literal>ast-core.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ast/ast-core.fun"><literal>ast-core.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/tree/master/mlton/ast"><literal>ast</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking">
<title>Type Checking</title>
<simpara>The <link linkend="AST">AST</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> has no independent type
checker. Type inference is performed on an AST program as part of
<link linkend="Elaborate">Elaborate</link>.</simpara>
</section>
<section id="_details_and_notes_2">
<title>Details and Notes</title>
<section id="_source_locations">
<title>Source locations</title>
<simpara>MLton makes use of a relatively clean method for annotating the
abstract syntax tree with source location information.  Every source
program phrase is "wrapped" with the <literal>WRAPPED</literal> interface:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature WRAPPED =
   sig
      type node'
      type obj

      val dest: obj -&gt; node' * Region.t
      val makeRegion': node' * SourcePos.t * SourcePos.t -&gt; obj
      val makeRegion: node' * Region.t -&gt; obj
      val node: obj -&gt; node'
      val region: obj -&gt; Region.t
   end</programlisting>
<simpara>The key idea is that <literal>node'</literal> is the type of an unannotated syntax
phrase and <literal>obj</literal> is the type of its annotated counterpart. In the
implementation, every <literal>node'</literal> is annotated with a <literal>Region.t</literal>
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/control/region.sig"><literal>region.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/control/region.sml"><literal>region.sml</literal></ulink>), which describes the
syntax phrase&#8217;s left source position and right source position, where
<literal>SourcePos.t</literal> (<ulink url="https://github.com/MLton/mlton/blob/master/mlton/control/source-pos.sig"><literal>source-pos.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/control/source-pos.sml"><literal>source-pos.sml</literal></ulink>) denotes a
particular file, line, and column.  A typical use of the <literal>WRAPPED</literal>
interface is illustrated by the following code:</simpara>
<programlisting language="sml" linenumbering="unnumbered">            datatype node =
               App of Longcon.t * t
             | Const of Const.t
             | Constraint of t * Type.t
             | FlatApp of t vector
             | Layered of {constraint: Type.t option,
                           fixop: Fixop.t,
                           pat: t,
                           var: Var.t}
             | List of t vector
             | Paren of t
             | Or of t vector
             | Record of {flexible: bool,
                          items: (Record.Field.t * Region.t * Item.t) vector}
             | Tuple of t vector
             | Var of {fixop: Fixop.t,
                       name: Longvid.t}
             | Vector of t vector
             | Wild</programlisting>
<simpara>Thus, AST nodes are cleanly separated from source locations.  By way
of contrast, consider the approach taken by <link linkend="SMLNJ">SML/NJ</link> (and also
by the <link linkend="CKitLibrary">CKit Library</link>).  Each datatype denoting a syntax
phrase dedicates a special constructor for annotating source
locations:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype pat = WildPat                             (* empty pattern *)
             | AppPat of {constr:pat,argument:pat} (* application *)
             | MarkPat of pat * region             (* mark a pattern *)</programlisting>
<simpara>The main drawback of this approach is that static type checking is not
sufficient to guarantee that the AST emitted from the front-end is
properly annotated.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="BasisLibrary">
<title>BasisLibrary</title>
<simpara>The <link linkend="StandardML">Standard ML</link> Basis Library is a collection of modules
dealing with basic types, input/output, OS interfaces, and simple
datatypes.  It is intended as a portable library usable across all
implementations of SML.  For the official online version of the Basis
Library specification, see <ulink url="http://www.standardml.org/Basis">http://www.standardml.org/Basis</ulink>.
<link linkend="References_GansnerReppy04">The Standard ML Basis Library</link> is a book
version that includes all of the online version and more.  For a
reverse chronological list of changes to the specification, see
<ulink url="http://www.standardml.org/Basis/history.html">http://www.standardml.org/Basis/history.html</ulink>.</simpara>
<simpara>MLton implements all of the required portions of the Basis Library.
MLton also implements many of the optional structures.  You can obtain
a complete and current list of what&#8217;s available using
<literal>mlton -show-basis</literal> (see <link linkend="ShowBasis">ShowBasis</link>).  By default, MLton makes the
Basis Library available to user programs.  You can also
<link linkend="MLBasisAvailableLibraries">access the Basis Library</link> from
<link linkend="MLBasis">ML Basis</link> files.</simpara>
<simpara>Below is a complete list of what MLton implements.</simpara>
<section id="_top_level_types_and_constructors">
<title>Top-level types and constructors</title>
<simpara><literal>eqtype 'a array</literal></simpara>
<simpara><literal>datatype bool = false | true</literal></simpara>
<simpara><literal>eqtype char</literal></simpara>
<simpara><literal>type exn</literal></simpara>
<simpara><literal>eqtype int</literal></simpara>
<simpara><literal>datatype 'a list = nil | :: of ('a * 'a list)</literal></simpara>
<simpara><literal>datatype 'a option = NONE | SOME of 'a</literal></simpara>
<simpara><literal>datatype order = EQUAL | GREATER | LESS</literal></simpara>
<simpara><literal>type real</literal></simpara>
<simpara><literal>datatype 'a ref = ref of 'a</literal></simpara>
<simpara><literal>eqtype string</literal></simpara>
<simpara><literal>type substring</literal></simpara>
<simpara><literal>eqtype unit</literal></simpara>
<simpara><literal>eqtype 'a vector</literal></simpara>
<simpara><literal>eqtype word</literal></simpara>
</section>
<section id="_top_level_exception_constructors">
<title>Top-level exception constructors</title>
<simpara><literal>Bind</literal></simpara>
<simpara><literal>Chr</literal></simpara>
<simpara><literal>Div</literal></simpara>
<simpara><literal>Domain</literal></simpara>
<simpara><literal>Empty</literal></simpara>
<simpara><literal>Fail of string</literal></simpara>
<simpara><literal>Match</literal></simpara>
<simpara><literal>Option</literal></simpara>
<simpara><literal>Overflow</literal></simpara>
<simpara><literal>Size</literal></simpara>
<simpara><literal>Span</literal></simpara>
<simpara><literal>Subscript</literal></simpara>
</section>
<section id="_top_level_values">
<title>Top-level values</title>
<simpara>MLton does not implement the optional top-level value
<literal>use: string -&gt; unit</literal>, which conflicts with whole-program
compilation because it allows new code to be loaded dynamically.</simpara>
<simpara>MLton implements all other top-level values:</simpara>
<simpara><literal>!</literal>,
<literal>:=</literal>,
<literal>&lt;&gt;</literal>,
<literal>=</literal>,
<literal>@</literal>,
<literal>^</literal>,
<literal>app</literal>,
<literal>before</literal>,
<literal>ceil</literal>,
<literal>chr</literal>,
<literal>concat</literal>,
<literal>exnMessage</literal>,
<literal>exnName</literal>,
<literal>explode</literal>,
<literal>floor</literal>,
<literal>foldl</literal>,
<literal>foldr</literal>,
<literal>getOpt</literal>,
<literal>hd</literal>,
<literal>ignore</literal>,
<literal>implode</literal>,
<literal>isSome</literal>,
<literal>length</literal>,
<literal>map</literal>,
<literal>not</literal>,
<literal>null</literal>,
<literal>o</literal>,
<literal>ord</literal>,
<literal>print</literal>,
<literal>real</literal>,
<literal>rev</literal>,
<literal>round</literal>,
<literal>size</literal>,
<literal>str</literal>,
<literal>substring</literal>,
<literal>tl</literal>,
<literal>trunc</literal>,
<literal>valOf</literal>,
<literal>vector</literal></simpara>
</section>
<section id="_overloaded_identifiers">
<title>Overloaded identifiers</title>
<simpara><literal>*</literal>,
<literal>+</literal>,
<literal>-</literal>,
<literal>/</literal>,
<literal>&lt;</literal>,
<literal>&lt;=</literal>,
<literal>&gt;</literal>,
<literal>&gt;=</literal>,
<literal>~</literal>,
<literal>abs</literal>,
<literal>div</literal>,
<literal>mod</literal></simpara>
</section>
<section id="_top_level_signatures">
<title>Top-level signatures</title>
<simpara><literal>ARRAY</literal></simpara>
<simpara><literal>ARRAY2</literal></simpara>
<simpara><literal>ARRAY_SLICE</literal></simpara>
<simpara><literal>BIN_IO</literal></simpara>
<simpara><literal>BIT_FLAGS</literal></simpara>
<simpara><literal>BOOL</literal></simpara>
<simpara><literal>BYTE</literal></simpara>
<simpara><literal>CHAR</literal></simpara>
<simpara><literal>COMMAND_LINE</literal></simpara>
<simpara><literal>DATE</literal></simpara>
<simpara><literal>GENERAL</literal></simpara>
<simpara><literal>GENERIC_SOCK</literal></simpara>
<simpara><literal>IEEE_REAL</literal></simpara>
<simpara><literal>IMPERATIVE_IO</literal></simpara>
<simpara><literal>INET_SOCK</literal></simpara>
<simpara><literal>INTEGER</literal></simpara>
<simpara><literal>INT_INF</literal></simpara>
<simpara><literal>IO</literal></simpara>
<simpara><literal>LIST</literal></simpara>
<simpara><literal>LIST_PAIR</literal></simpara>
<simpara><literal>MATH</literal></simpara>
<simpara><literal>MONO_ARRAY</literal></simpara>
<simpara><literal>MONO_ARRAY2</literal></simpara>
<simpara><literal>MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>MONO_VECTOR</literal></simpara>
<simpara><literal>MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>NET_HOST_DB</literal></simpara>
<simpara><literal>NET_PROT_DB</literal></simpara>
<simpara><literal>NET_SERV_DB</literal></simpara>
<simpara><literal>OPTION</literal></simpara>
<simpara><literal>OS</literal></simpara>
<simpara><literal>OS_FILE_SYS</literal></simpara>
<simpara><literal>OS_IO</literal></simpara>
<simpara><literal>OS_PATH</literal></simpara>
<simpara><literal>OS_PROCESS</literal></simpara>
<simpara><literal>PACK_REAL</literal></simpara>
<simpara><literal>PACK_WORD</literal></simpara>
<simpara><literal>POSIX</literal></simpara>
<simpara><literal>POSIX_ERROR</literal></simpara>
<simpara><literal>POSIX_FILE_SYS</literal></simpara>
<simpara><literal>POSIX_IO</literal></simpara>
<simpara><literal>POSIX_PROCESS</literal></simpara>
<simpara><literal>POSIX_PROC_ENV</literal></simpara>
<simpara><literal>POSIX_SIGNAL</literal></simpara>
<simpara><literal>POSIX_SYS_DB</literal></simpara>
<simpara><literal>POSIX_TTY</literal></simpara>
<simpara><literal>PRIM_IO</literal></simpara>
<simpara><literal>REAL</literal></simpara>
<simpara><literal>SOCKET</literal></simpara>
<simpara><literal>STREAM_IO</literal></simpara>
<simpara><literal>STRING</literal></simpara>
<simpara><literal>STRING_CVT</literal></simpara>
<simpara><literal>SUBSTRING</literal></simpara>
<simpara><literal>TEXT</literal></simpara>
<simpara><literal>TEXT_IO</literal></simpara>
<simpara><literal>TEXT_STREAM_IO</literal></simpara>
<simpara><literal>TIME</literal></simpara>
<simpara><literal>TIMER</literal></simpara>
<simpara><literal>UNIX</literal></simpara>
<simpara><literal>UNIX_SOCK</literal></simpara>
<simpara><literal>VECTOR</literal></simpara>
<simpara><literal>VECTOR_SLICE</literal></simpara>
<simpara><literal>WORD</literal></simpara>
</section>
<section id="_top_level_structures">
<title>Top-level structures</title>
<simpara><literal>structure Array: ARRAY</literal></simpara>
<simpara><literal>structure Array2: ARRAY2</literal></simpara>
<simpara><literal>structure ArraySlice: ARRAY_SLICE</literal></simpara>
<simpara><literal>structure BinIO: BIN_IO</literal></simpara>
<simpara><literal>structure BinPrimIO: PRIM_IO</literal></simpara>
<simpara><literal>structure Bool: BOOL</literal></simpara>
<simpara><literal>structure BoolArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure BoolArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure BoolArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure BoolVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure BoolVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Byte: BYTE</literal></simpara>
<simpara><literal>structure Char: CHAR</literal></simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>Char</literal> characters correspond to ISO-8859-1.  The <literal>Char</literal> functions do not depend on locale.
</simpara>
</listitem>
</itemizedlist>
<simpara><literal>structure CharArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure CharArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure CharArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure CharVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure CharVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure CommandLine: COMMAND_LINE</literal></simpara>
<simpara><literal>structure Date: DATE</literal></simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>Date.fromString</literal> and <literal>Date.scan</literal> accept a space in addition to a zero for the first character of the day of the month.  The Basis Library specification only allows a zero.
</simpara>
</listitem>
</itemizedlist>
<simpara><literal>structure FixedInt: INTEGER</literal></simpara>
<simpara><literal>structure General: GENERAL</literal></simpara>
<simpara><literal>structure GenericSock: GENERIC_SOCK</literal></simpara>
<simpara><literal>structure IEEEReal: IEEE_REAL</literal></simpara>
<simpara><literal>structure INetSock: INET_SOCK</literal></simpara>
<simpara><literal>structure IO: IO</literal></simpara>
<simpara><literal>structure Int: INTEGER</literal></simpara>
<simpara><literal>structure Int1: INTEGER</literal></simpara>
<simpara><literal>structure Int2: INTEGER</literal></simpara>
<simpara><literal>structure Int3: INTEGER</literal></simpara>
<simpara><literal>structure Int4: INTEGER</literal></simpara>
<simpara>&#8230;</simpara>
<simpara><literal>structure Int31: INTEGER</literal></simpara>
<simpara><literal>structure Int32: INTEGER</literal></simpara>
<simpara><literal>structure Int64: INTEGER</literal></simpara>
<simpara><literal>structure IntArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure IntArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure IntArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure IntVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure IntVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Int8: INTEGER</literal></simpara>
<simpara><literal>structure Int8Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Int8Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Int8ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Int8Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Int8VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Int16: INTEGER</literal></simpara>
<simpara><literal>structure Int16Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Int16Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Int16ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Int16Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Int16VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Int32: INTEGER</literal></simpara>
<simpara><literal>structure Int32Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Int32Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Int32ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Int32Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Int32VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Int64Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Int64Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Int64ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Int64Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Int64VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure IntInf: INT_INF</literal></simpara>
<simpara><literal>structure LargeInt: INTEGER</literal></simpara>
<simpara><literal>structure LargeIntArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure LargeIntArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure LargeIntArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure LargeIntVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure LargeIntVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure LargeReal: REAL</literal></simpara>
<simpara><literal>structure LargeRealArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure LargeRealArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure LargeRealArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure LargeRealVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure LargeRealVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure LargeWord: WORD</literal></simpara>
<simpara><literal>structure LargeWordArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure LargeWordArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure LargeWordArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure LargeWordVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure LargeWordVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure List: LIST</literal></simpara>
<simpara><literal>structure ListPair: LIST_PAIR</literal></simpara>
<simpara><literal>structure Math: MATH</literal></simpara>
<simpara><literal>structure NetHostDB: NET_HOST_DB</literal></simpara>
<simpara><literal>structure NetProtDB: NET_PROT_DB</literal></simpara>
<simpara><literal>structure NetServDB: NET_SERV_DB</literal></simpara>
<simpara><literal>structure OS: OS</literal></simpara>
<simpara><literal>structure Option: OPTION</literal></simpara>
<simpara><literal>structure PackReal32Big: PACK_REAL</literal></simpara>
<simpara><literal>structure PackReal32Little: PACK_REAL</literal></simpara>
<simpara><literal>structure PackReal64Big: PACK_REAL</literal></simpara>
<simpara><literal>structure PackReal64Little: PACK_REAL</literal></simpara>
<simpara><literal>structure PackRealBig: PACK_REAL</literal></simpara>
<simpara><literal>structure PackRealLittle: PACK_REAL</literal></simpara>
<simpara><literal>structure PackWord16Big: PACK_WORD</literal></simpara>
<simpara><literal>structure PackWord16Little: PACK_WORD</literal></simpara>
<simpara><literal>structure PackWord32Big: PACK_WORD</literal></simpara>
<simpara><literal>structure PackWord32Little: PACK_WORD</literal></simpara>
<simpara><literal>structure PackWord64Big: PACK_WORD</literal></simpara>
<simpara><literal>structure PackWord64Little: PACK_WORD</literal></simpara>
<simpara><literal>structure Position: INTEGER</literal></simpara>
<simpara><literal>structure Posix: POSIX</literal></simpara>
<simpara><literal>structure Real: REAL</literal></simpara>
<simpara><literal>structure RealArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure RealArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure RealArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure RealVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure RealVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Real32: REAL</literal></simpara>
<simpara><literal>structure Real32Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Real32Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Real32ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Real32Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Real32VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Real64: REAL</literal></simpara>
<simpara><literal>structure Real64Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Real64Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Real64ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Real64Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Real64VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Socket: SOCKET</literal></simpara>
<itemizedlist>
<listitem>
<simpara>
The Basis Library specification requires functions like
<literal>Socket.sendVec</literal> to raise an exception if they fail.  However, on some
platforms, sending to a socket that hasn&#8217;t yet been connected causes a
<literal>SIGPIPE</literal> signal, which invokes the default signal handler for
<literal>SIGPIPE</literal> and causes the program to terminate.  If you want the
exception to be raised, you can ignore <literal>SIGPIPE</literal> by adding the
following to your program.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">let
   open MLton.Signal
in
   setHandler (Posix.Signal.pipe, Handler.ignore)
end</programlisting>
</listitem>
</itemizedlist>
<simpara><literal>structure String: STRING</literal></simpara>
<itemizedlist>
<listitem>
<simpara>
The <literal>String</literal> functions do not depend on locale.
</simpara>
</listitem>
</itemizedlist>
<simpara><literal>structure StringCvt: STRING_CVT</literal></simpara>
<simpara><literal>structure Substring: SUBSTRING</literal></simpara>
<simpara><literal>structure SysWord: WORD</literal></simpara>
<simpara><literal>structure Text: TEXT</literal></simpara>
<simpara><literal>structure TextIO: TEXT_IO</literal></simpara>
<simpara><literal>structure TextPrimIO: PRIM_IO</literal></simpara>
<simpara><literal>structure Time: TIME</literal></simpara>
<simpara><literal>structure Timer: TIMER</literal></simpara>
<simpara><literal>structure Unix: UNIX</literal></simpara>
<simpara><literal>structure UnixSock: UNIX_SOCK</literal></simpara>
<simpara><literal>structure Vector: VECTOR</literal></simpara>
<simpara><literal>structure VectorSlice: VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Word: WORD</literal></simpara>
<simpara><literal>structure Word1: WORD</literal></simpara>
<simpara><literal>structure Word2: WORD</literal></simpara>
<simpara><literal>structure Word3: WORD</literal></simpara>
<simpara><literal>structure Word4: WORD</literal></simpara>
<simpara>&#8230;</simpara>
<simpara><literal>structure Word31: WORD</literal></simpara>
<simpara><literal>structure Word32: WORD</literal></simpara>
<simpara><literal>structure Word64: WORD</literal></simpara>
<simpara><literal>structure WordArray: MONO_ARRAY</literal></simpara>
<simpara><literal>structure WordArray2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure WordArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure WordVectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure WordVector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Word8Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Word8Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Word8ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Word8Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Word8VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Word16Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Word16Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Word16ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Word16Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Word16VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Word32Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Word32Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Word32ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Word32Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Word32VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
<simpara><literal>structure Word64Array: MONO_ARRAY</literal></simpara>
<simpara><literal>structure Word64Array2: MONO_ARRAY2</literal></simpara>
<simpara><literal>structure Word64ArraySlice: MONO_ARRAY_SLICE</literal></simpara>
<simpara><literal>structure Word64Vector: MONO_VECTOR</literal></simpara>
<simpara><literal>structure Word64VectorSlice: MONO_VECTOR_SLICE</literal></simpara>
</section>
<section id="_top_level_functors">
<title>Top-level functors</title>
<simpara><literal>ImperativeIO</literal></simpara>
<simpara><literal>PrimIO</literal></simpara>
<simpara><literal>StreamIO</literal></simpara>
<itemizedlist>
<listitem>
<simpara>
MLton&#8217;s <literal>StreamIO</literal> functor takes structures <literal>ArraySlice</literal> and
<literal>VectorSlice</literal> in addition to the arguments specified in the Basis
Library specification.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_equivalences">
<title>Type equivalences</title>
<simpara>The following types are equivalent.</simpara>
<screen>FixedInt = Int64.int
LargeInt = IntInf.int
LargeReal.real = Real64.real
LargeWord = Word64.word</screen>
<simpara>The default <literal>int</literal>, <literal>real</literal>, and <literal>word</literal> types may be set by the
<literal>-default-type <emphasis>type</emphasis></literal> <link linkend="CompileTimeOptions">compile-time option</link>.
By default, the following types are equivalent:</simpara>
<screen>int = Int.int = Int32.int
real = Real.real = Real64.real
word = Word.word = Word32.word</screen>
</section>
<section id="_real_and_math_functions">
<title>Real and Math functions</title>
<simpara>The <literal>Real</literal>, <literal>Real32</literal>, and <literal>Real64</literal> modules are implemented
using the <literal>C</literal> math library, so the SML functions will reflect the
behavior of the underlying library function.  We have made some effort
to unify the differences between the math libraries on different
platforms, and in particular to handle exceptional cases according to
the Basis Library specification.  However, there will be differences
due to different numerical algorithms and cases we may have missed.
Please submit a <link linkend="Bug">bug report</link> if you encounter an error in
the handling of an exceptional case.</simpara>
<simpara>On x86, real arithmetic is implemented internally using 80 bits of
precision.  Using higher precision for intermediate results in
computations can lead to different results than if all the computation
is done at 32 or 64 bits.  If you require strict IEEE compliance, you
can compile with <literal>-ieee-fp true</literal>, which will cause intermediate
results to be stored after each operation.  This may cause a
substantial performance penalty.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Bug">
<title>Bug</title>
<simpara>To report a bug, please send mail to
<ulink url="mailto:mlton-devel@mlton.org"><literal>mlton-devel@mlton.org</literal></ulink>.  Please include
the complete SML program that caused the problem and a log of a
compile of the program with <literal>-verbose 2</literal>.  For large programs (over
256K), please send an email containing the discussion text and a link
to any large files.</simpara>
<simpara>There are some <link linkend="UnresolvedBugs">UnresolvedBugs</link> that we don&#8217;t plan to fix.</simpara>
<simpara>We also maintain a list of bugs found with each release.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20130715">Bugs20130715</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Bugs20100608">Bugs20100608</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Bugs20070826">Bugs20070826</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Bugs20051202">Bugs20051202</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Bugs20041109">Bugs20041109</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Bugs20041109">
<title>Bugs20041109</title>
<simpara>Here are the known bugs in <link linkend="Release20041109">MLton 20041109</link>, listed
in reverse chronological order of date reported.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug17" xreflabel="[Bugs20041109_bug17]"/>
 <literal>MLton.Finalizable.touch</literal> doesn&#8217;t necessarily keep values alive
 long enough.  Our SVN has a patch to the compiler.  You must rebuild
 the compiler in order for the patch to take effect.
</simpara>
<simpara>Thanks to Florian Weimer for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug16" xreflabel="[Bugs20041109_bug16]"/>
 A bug in an optimization pass may incorrectly transform a program
 to flatten ref cells into their containing data structure, yielding a
 type-error in the transformed program.  Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/mlton/ssa/ref-flatten.fun.diff?r1=1.35&amp;r2=1.37">patch</ulink>
 to the compiler.  You must rebuild the compiler in order for the
 patch to take effect.
</simpara>
<simpara>Thanks to <link linkend="VesaKarvonen">VesaKarvonen</link> for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug15" xreflabel="[Bugs20041109_bug15]"/>
 A bug in the front end mistakenly allows unary constructors to be
 used without an argument in patterns.  For example, the following
 program is accepted, and triggers a large internal error.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f x = case x of SOME =&gt; true | _ =&gt; false</programlisting>
<simpara>We have fixed the problem in our CVS.</simpara>
<simpara>Thanks to William Lovas for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug14" xreflabel="[Bugs20041109_bug14]"/>
 A bug in <literal>Posix.IO.{getlk,setlk,setlkw}</literal> causes a link-time error:
 <literal>undefined reference to Posix_IO_FLock_typ</literal>
 Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/basis-library/posix/primitive.sml.diff?r1=1.34&amp;r2=1.35">patch</ulink>
 to the Basis Library implementation.
</simpara>
<simpara>Thanks to Adam Chlipala for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug13" xreflabel="[Bugs20041109_bug13]"/>
 A bug can cause programs compiled with <literal>-profile alloc</literal> to
 segfault.  Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/mlton/backend/ssa-to-rssa.fun.diff?r1=1.106&amp;r2=1.107">patch</ulink>
 to the compiler.  You must rebuild the compiler in order for the
 patch to take effect.
</simpara>
<simpara>Thanks to John Reppy for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug12" xreflabel="[Bugs20041109_bug12]"/>
 A bug in an optimization pass may incorrectly flatten ref cells
 into their containing data structure, breaking the sharing between
 the cells.  Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/mlton/ssa/ref-flatten.fun.diff?r1=1.32&amp;r2=1.33">patch</ulink>
 to the compiler.  You must rebuild the compiler in order for the
 patch to take effect.
</simpara>
<simpara>Thanks to Paul Govereau for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug11" xreflabel="[Bugs20041109_bug11]"/>
 Some arrays or vectors, such as <literal>(char * char) vector</literal>, are
 incorrectly implemented, and will conflate the first and second
 components of each element.  Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/mlton/backend/packed-representation.fun.diff?r1=1.32&amp;r2=1.33">patch</ulink>
 to the compiler.  You must rebuild the compiler in order for the
 patch to take effect.
</simpara>
<simpara>Thanks to Scott Cruzen for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug10" xreflabel="[Bugs20041109_bug10]"/>
 <literal>Socket.Ctl.getLINGER</literal> and <literal>Socket.Ctl.setLINGER</literal>
 mistakenly raise <literal>Subscript</literal>.
 Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/basis-library/net/socket.sml.diff?r1=1.14&amp;r2=1.15">patch</ulink>
 to the Basis Library implementation.
</simpara>
<simpara>Thanks to Ray Racine for reporting the bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug09" xreflabel="[Bugs20041109_bug09]"/>
 <link linkend="ConcurrentML">CML</link> <literal>Mailbox.send</literal> makes a call in the wrong atomic context.
 Our CVS has a <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/lib/cml/core-cml/mailbox.sml.diff?r1=1.3&amp;r2=1.4">patch</ulink>
 to the CML implementation.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug08" xreflabel="[Bugs20041109_bug08]"/>
 <literal>OS.Path.joinDirFile</literal> and <literal>OS.Path.toString</literal> did not
 raise <literal>InvalidArc</literal> when they were supposed to.  They now do.
 Our CVS has a <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/basis-library/system/path.sml.diff?r1=1.8&amp;r2=1.11">patch</ulink>
 to the Basis Library implementation.
</simpara>
<simpara>Thanks to Andreas Rossberg for reporting the bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug07" xreflabel="[Bugs20041109_bug07]"/>
 The front end incorrectly disallows sequences of expressions
 (separated by semicolons) after a topdec has already been processed.
 For example, the following is incorrectly rejected.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x = 0;
ignore x;
ignore x;</programlisting>
<simpara>We have fixed the problem in our CVS.</simpara>
<simpara>Thanks to Andreas Rossberg for reporting the bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug06" xreflabel="[Bugs20041109_bug06]"/>
 The front end incorrectly disallows expansive <literal>val</literal>
 declarations that bind a type variable that doesn&#8217;t occur in the
 type of the value being bound.   For example, the following is
 incorrectly rejected.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a x = let exception E of 'a in () end</programlisting>
<simpara>We have fixed the problem in our CVS.</simpara>
<simpara>Thanks to Andreas Rossberg for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug05" xreflabel="[Bugs20041109_bug05]"/>
 The x86 codegen fails to account for the possibility that a 64-bit
 move could interfere with itself (as simulated by 32-bit moves).  We
 have fixed the problem in our CVS.
</simpara>
<simpara>Thanks to Scott Cruzen for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug04" xreflabel="[Bugs20041109_bug04]"/>
 <literal>NetHostDB.scan</literal> and <literal>NetHostDB.fromString</literal> incorrectly
 raise an exception on internet addresses whose last component is a
 zero, e.g <literal>0.0.0.0</literal>.  Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/basis-library/net/net-host-db.sml.diff?r1=1.12&amp;r2=1.13">patch</ulink> to the Basis Library implementation.
</simpara>
<simpara>Thanks to Scott Cruzen for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug03" xreflabel="[Bugs20041109_bug03]"/>
 <literal>StreamIO.inputLine</literal> has an off-by-one error causing it to drop
 the first character after a newline in some situations.  Our CVS has a
 <ulink url="http://mlton.org/cgi-bin/viewcvs.cgi/mlton/mlton/basis-library/io/stream-io.fun.diff?r1=text&amp;tr1=1.29&amp;r2=text&amp;tr2=1.30&amp;diff_format=h">patch</ulink>.
 to the Basis Library implementation.
</simpara>
<simpara>Thanks to Scott Cruzen for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug02" xreflabel="[Bugs20041109_bug02]"/>
 <literal>BinIO.getInstream</literal> and <literal>TextIO.getInstream</literal> are
 implemented incorrectly.  This also impacts the behavior of
 <literal>BinIO.scanStream</literal> and <literal>TextIO.scanStream</literal>.  If you (directly
 or indirectly) realize a <literal>TextIO.StreamIO.instream</literal> and do not
 (directly or indirectly) call <literal>TextIO.setInstream</literal> with a derived
 stream, you may lose input data.  We have fixed the problem in our
 CVS.
</simpara>
<simpara>Thanks to <link linkend="WesleyTerpstra">WesleyTerpstra</link> for reporting this bug.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20041109_bug01" xreflabel="[Bugs20041109_bug01]"/>
 <literal>Posix.ProcEnv.setpgid</literal> doesn&#8217;t work.  If you compile a program
 that uses it, you will get a link time error
</simpara>
<screen>undefined reference to `Posix_ProcEnv_setpgid'</screen>
<simpara>The bug is due to <literal>Posix_ProcEnv_setpgid</literal> being omitted from the
 MLton runtime.  We fixed the problem in our CVS by adding the
 following definition to <literal>runtime/Posix/ProcEnv/ProcEnv.c</literal></simpara>
<programlisting language="c" linenumbering="unnumbered">Int Posix_ProcEnv_setpgid (Pid p, Gid g) {
        return setpgid (p, g);
}</programlisting>
<simpara>Thanks to Tom Murphy for reporting this bug.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Bugs20051202">
<title>Bugs20051202</title>
<simpara>Here are the known bugs in <link linkend="Release20051202">MLton 20051202</link>, listed
in reverse chronological order of date reported.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug16" xreflabel="[Bugs20051202_bug16]"/>
Bug in the <ulink url="http://www.standardml.org/Basis/real.html#SIG:REAL.fmt:VAL"><literal>Real<emphasis>&lt;N&gt;</emphasis>.fmt</literal></ulink>, <ulink url="http://www.standardml.org/Basis/real.html#SIG:REAL.fromString:VAL"><literal>Real<emphasis>&lt;N&gt;</emphasis>.fromString</literal></ulink>, <ulink url="http://www.standardml.org/Basis/real.html#SIG:REAL.scan:VAL"><literal>Real<emphasis>&lt;N&gt;</emphasis>.scan</literal></ulink>, and <ulink url="http://www.standardml.org/Basis/real.html#SIG:REAL.toString:VAL"><literal>Real<emphasis>&lt;N&gt;</emphasis>.toString</literal></ulink> functions of the <link linkend="BasisLibrary">Basis Library</link> implementation.  These functions were using <literal>TO_NEAREST</literal> semantics, but should obey the current rounding mode.  (Only <literal>Real<emphasis>&lt;N&gt;</emphasis>.fmt StringCvt.EXACT</literal>, <literal>Real<emphasis>&lt;N&gt;</emphasis>.fromDecimal</literal>, and <literal>Real<emphasis>&lt;N&gt;</emphasis>.toDecimal</literal> are specified to override the current rounding mode with <literal>TO_NEAREST</literal> semantics.)
</simpara>
<simpara>Thanks to Sean McLaughlin for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5827"><literal>r5827</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug15" xreflabel="[Bugs20051202_bug15]"/>
Bug in the treatment of floating-point operations.  Floating-point operations depend on the current rounding mode, but were being treated as pure.
</simpara>
<simpara>Thanks to Sean McLaughlin for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5794"><literal>r5794</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug14" xreflabel="[Bugs20051202_bug14]"/>
Bug in the <ulink url="http://www.standardml.org/Basis/real.html#SIG:REAL.toInt:VAL"><literal>Real32.toInt</literal></ulink> function of the <link linkend="BasisLibrary">Basis Library</link> implementation could lead incorrect results when applied to a <literal>Real32.real</literal> value numerically close to <literal>valOf(Int.maxInt)</literal>.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5764"><literal>r5764</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug13" xreflabel="[Bugs20051202_bug13]"/>
The <ulink url="http://www.standardml.org/Basis/socket.html"><literal>Socket</literal></ulink> structure of the <link linkend="BasisLibrary">Basis Library</link> implementation used <literal>andb</literal> rather than <literal>orb</literal> to unmarshal socket options (for <literal>Socket.Ctl.get<emphasis>&lt;OPT&gt;</emphasis></literal> functions).
</simpara>
<simpara>Thanks to Anders Petersson for the bug report and patch.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5735"><literal>r5735</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug12" xreflabel="[Bugs20051202_bug12]"/>
Bug in the <ulink url="http://www.standardml.org/Basis/date.html"><literal>Date</literal></ulink> structure of the <link linkend="BasisLibrary">Basis Library</link> implementation yielded some functions that would erroneously raise <literal>Date</literal> when applied to a year before 1900.
</simpara>
<simpara>Thanks to Joe Hurd for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5732"><literal>r5732</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug11" xreflabel="[Bugs20051202_bug11]"/>
Bug in monomorphisation pass could exhibit the error <literal>Type error: type mismatch</literal>.
</simpara>
<simpara>Thanks to Vesa Karvonen for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5731"><literal>r5731</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug10" xreflabel="[Bugs20051202_bug10]"/>
The <ulink url="http://www.standardml.org/Basis/pack-float.html#SIG:PACK_REAL.toBytes:VAL"><literal>PackReal<emphasis>&lt;N&gt;</emphasis>.toBytes</literal></ulink> function in the <link linkend="BasisLibrary">Basis Library</link> implementation incorrectly shared (and mutated) the result vector.
</simpara>
<simpara>Thanks to Eric McCorkle for the bug report and patch.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5281"><literal>r5281</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug09" xreflabel="[Bugs20051202_bug09]"/>
Bug in elaboration of FFI forms.  Using a unary FFI types (e.g., <literal>array</literal>, <literal>ref</literal>, <literal>vector</literal>) in places where <literal>MLton.Pointer.t</literal> was required would lead to an internal error <literal>TypeError</literal>.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4890"><literal>r4890</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug08" xreflabel="[Bugs20051202_bug08]"/>
The <ulink url="http://www.standardml.org/Basis/mono-vector.html"><literal>MONO_VECTOR</literal></ulink> signature of the <link linkend="BasisLibrary">Basis Library</link> implementation incorrectly omits the specification of <literal>find</literal>.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4707"><literal>r4707</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug07" xreflabel="[Bugs20051202_bug07]"/>
The optimizer reports an internal error (<literal>TypeError</literal>) when an imported C function is called but not used.
</simpara>
<simpara>Thanks to "jq" for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4690"><literal>r4690</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug06" xreflabel="[Bugs20051202_bug06]"/>
Bug in pass to flatten data structures.
</simpara>
<simpara>Thanks to Joe Hurd for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4662"><literal>r4662</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug05" xreflabel="[Bugs20051202_bug05]"/>
The native codegen&#8217;s implementation of the C-calling convention failed to widen 16-bit arguments to 32-bits.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4631"><literal>r4631</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug04" xreflabel="[Bugs20051202_bug04]"/>
The <ulink url="http://www.standardml.org/Basis/pack-float.html"><literal>PACK_REAL</literal></ulink> structures of the <link linkend="BasisLibrary">Basis Library</link> implementation used byte, rather than element, indexing.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4411"><literal>r4411</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug03" xreflabel="[Bugs20051202_bug03]"/>
<literal>MLton.share</literal> could cause a segmentation fault.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4400"><literal>r4400</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug02" xreflabel="[Bugs20051202_bug02]"/>
The SSA simplifier could eliminate an irredundant test.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4370"><literal>r4370</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20051202_bug01" xreflabel="[Bugs20051202_bug01]"/>
A program with a very large number of functors could exhibit the error <literal>ElaborateEnv.functorClosure: firstTycons</literal>.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r4344"><literal>r4344</literal></ulink>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Bugs20070826">
<title>Bugs20070826</title>
<simpara>Here are the known bugs in <link linkend="Release20070826">MLton 20070826</link>, listed
in reverse chronological order of date reported.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug25" xreflabel="[Bugs20070826_bug25]"/>
Bug in the mark-compact garbage collector where the C library&#8217;s <literal>memcpy</literal> was used to move objects during the compaction phase; this could lead to heap corruption and segmentation faults with newer versions of gcc and/or glibc, which assume that src and dst in a <literal>memcpy</literal> do not overlap.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7461"><literal>r7461</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug24" xreflabel="[Bugs20070826_bug24]"/>
Bug in elaboration of <literal>datatype</literal> declarations with <literal>withtype</literal> bindings.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7434"><literal>r7434</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug23" xreflabel="[Bugs20070826_bug23]"/>
Performance bug in <link linkend="RefFlatten">RefFlatten</link> optimization pass.
</simpara>
<simpara>Thanks to Reactive Systems for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7379"><literal>r7379</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug22" xreflabel="[Bugs20070826_bug22]"/>
Performance bug in <link linkend="SimplifyTypes">SimplifyTypes</link> optimization pass.
</simpara>
<simpara>Thanks to Reactive Systems for the bug report.</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7377"><literal>r7377</literal></ulink> and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7378"><literal>r7378</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug21" xreflabel="[Bugs20070826_bug21]"/>
Bug in amd64 codegen register allocation of indirect C calls.
</simpara>
<simpara>Thanks to David Hansel for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7368"><literal>r7368</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug20" xreflabel="[Bugs20070826_bug20]"/>
Bug in <literal>IntInf.scan</literal> and <literal>IntInf.fromString</literal> where leading spaces were only accepted if the stream had an explicit sign character.
</simpara>
<simpara>Thanks to David Hansel for the bug report.</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7227"><literal>r7227</literal></ulink> and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7230"><literal>r7230</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug19" xreflabel="[Bugs20070826_bug19]"/>
Bug in <literal>IntInf.~&gt;&gt;</literal> that could cause a <literal>glibc</literal> assertion.
</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7083"><literal>r7083</literal></ulink>, <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7084"><literal>r7084</literal></ulink>, and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7085"><literal>r7085</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug18" xreflabel="[Bugs20070826_bug18]"/>
Bug in the return type of <literal>MLton.Process.reap</literal>.
</simpara>
<simpara>Thanks to Risto Saarelma for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7029"><literal>r7029</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug17" xreflabel="[Bugs20070826_bug17]"/>
Bug in <literal>MLton.size</literal> and <literal>MLton.share</literal> when tracing the current stack.
</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6978"><literal>r6978</literal></ulink>, <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6981"><literal>r6981</literal></ulink>, <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6988"><literal>r6988</literal></ulink>, <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6989"><literal>r6989</literal></ulink>, and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6990"><literal>r6990</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug16" xreflabel="[Bugs20070826_bug16]"/>
Bug in nested <literal>_export</literal>/<literal>_import</literal> functions.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6919"><literal>r6919</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug15" xreflabel="[Bugs20070826_bug15]"/>
Bug in the name mangling of <literal>_import</literal>-ed functions with the <literal>stdcall</literal> convention.
</simpara>
<simpara>Thanks to Lars Bergstrom for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6672"><literal>r6672</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug14" xreflabel="[Bugs20070826_bug14]"/>
Bug in Windows code to page the heap to disk when unable to grow the heap to a desired size.
</simpara>
<simpara>Thanks to Sami Evangelista for the bug report.</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6600"><literal>r6600</literal></ulink> and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6624"><literal>r6624</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug13" xreflabel="[Bugs20070826_bug13]"/>
Bug in \*NIX code to page the heap to disk when unable to grow the heap to a desired size.
</simpara>
<simpara>Thanks to Nicolas Bertolotti for the bug report and patch.</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6596"><literal>r6596</literal></ulink> and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6600"><literal>r6600</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug12" xreflabel="[Bugs20070826_bug12]"/>
Space-safety bug in pass to <link linkend="RefFlatten">flatten refs</link> into containing data structure.
</simpara>
<simpara>Thanks to Daniel Spoonhower for the bug report and initial diagnosis and patch.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6395"><literal>r6395</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug11" xreflabel="[Bugs20070826_bug11]"/>
Bug in the frontend that rejected <literal>op longvid</literal> patterns and expressions.
</simpara>
<simpara>Thanks to Florian Weimer for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6347"><literal>r6347</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug10" xreflabel="[Bugs20070826_bug10]"/>
Bug in the <ulink url="http://www.standardml.org/Basis/imperative-io.html#SIG:IMPERATIVE_IO.canInput:VAL"><literal>IMPERATIVE_IO.canInput</literal></ulink> function of the <link linkend="BasisLibrary">Basis Library</link> implementation.
</simpara>
<simpara>Thanks to Ville Laurikari for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6261"><literal>r6261</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug09" xreflabel="[Bugs20070826_bug09]"/>
Bug in algebraic simplification of real primitives.  <ulink url="http://www.standardml.org/Basis/real.html#SIG:REAL.\|@LTE\|:VAL"><literal>REAL<emphasis>&lt;N&gt;</emphasis>.&lt;=(x, x)</literal></ulink> is <literal>false</literal> when <literal>x</literal> is NaN.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6242"><literal>r6242</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug08" xreflabel="[Bugs20070826_bug08]"/>
Bug in the FFI visible representation of <literal>Int16.int ref</literal> (and references of other primitive types smaller than 32-bits) on big-endian platforms.
</simpara>
<simpara>Thanks to Dave Herman for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6267"><literal>r6267</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug07" xreflabel="[Bugs20070826_bug07]"/>
Bug in type inference of flexible records.  This would later cause the compiler to raise the <literal>TypeError</literal> exception.
</simpara>
<simpara>Thanks to Wesley Terpstra for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6229"><literal>r6229</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug06" xreflabel="[Bugs20070826_bug06]"/>
Bug in cross-compilation of <literal>gdtoa</literal> library.
</simpara>
<simpara>Thanks to Wesley Terpstra for the bug report and patch.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6620"><literal>r6620</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug05" xreflabel="[Bugs20070826_bug05]"/>
Bug in pass to <link linkend="RefFlatten">flatten refs</link> into containing data structure.
</simpara>
<simpara>Thanks to Ruy Ley-Wild for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6191"><literal>r6191</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug04" xreflabel="[Bugs20070826_bug04]"/>
Bug in the handling of weak pointers by the mark-compact garbage collector.
</simpara>
<simpara>Thanks to Sean McLaughlin for the bug report and Florian Weimer for the initial diagnosis.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6183"><literal>r6183</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug03" xreflabel="[Bugs20070826_bug03]"/>
Bug in the elaboration of structures with signature constraints.  This would later cause the compiler to raise the <literal>TypeError</literal> exception.
</simpara>
<simpara>Thanks to Vesa Karvonen for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6046"><literal>r6046</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug02" xreflabel="[Bugs20070826_bug02]"/>
Bug in the interaction of <literal>_export</literal>-ed functions and signal handlers.
</simpara>
<simpara>Thanks to Sean McLaughlin for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6013"><literal>r6013</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20070826_bug01" xreflabel="[Bugs20070826_bug01]"/>
Bug in the implementation of <literal>_export</literal>-ed functions using the <literal>char</literal> type, leading to a linker error.
</simpara>
<simpara>Thanks to Katsuhiro Ueno for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r5999"><literal>r5999</literal></ulink>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Bugs20100608">
<title>Bugs20100608</title>
<simpara>Here are the known bugs in <link linkend="Release20100608">MLton 20100608</link>, listed
in reverse chronological order of date reported.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug11" xreflabel="[Bugs20100608_bug11]"/>
Bugs in <literal>REAL.signBit</literal>, <literal>REAL.copySign</literal>, and <literal>REAL.toDecimal</literal>/<literal>REAL.fromDecimal</literal>.
</simpara>
<simpara>Thanks to Phil Clayton for the bug report and examples.</simpara>
<simpara>Fixed by revisions <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7571"><literal>r7571</literal></ulink>, <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7572"><literal>r7572</literal></ulink>, and <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7573"><literal>r7573</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug10" xreflabel="[Bugs20100608_bug10]"/>
Bug in elaboration of type variables with and without equality status.
</simpara>
<simpara>Thanks to Rob Simmons for the bug report and examples.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7565"><literal>r7565</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug09" xreflabel="[Bugs20100608_bug09]"/>
Bug in <link linkend="Redundant">redundant</link> <link linkend="SSA">SSA</link> optimization.
</simpara>
<simpara>Thanks to Lars Magnusson for the bug report and example.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7561"><literal>r7561</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug08" xreflabel="[Bugs20100608_bug08]"/>
Bug in <link linkend="SSA">SSA</link>/<link linkend="SSA2">SSA2</link> <link linkend="Shrink">shrinker</link> that could erroneously turn a non-tail function call with a <literal>Bug</literal> transfer as its continuation into a tail function call.
</simpara>
<simpara>Thanks to Lars Bergstrom for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7546"><literal>r7546</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug07" xreflabel="[Bugs20100608_bug07]"/>
Bug in translation from <link linkend="SSA2">SSA2</link> to <link linkend="RSSA">RSSA</link> with <literal>case</literal> expressions over non-primitive-sized words.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7544"><literal>r7544</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug06" xreflabel="[Bugs20100608_bug06]"/>
Bug with <link linkend="SSA">SSA</link>/<link linkend="SSA2">SSA2</link> type checking of case expressions over words.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7542"><literal>r7542</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug05" xreflabel="[Bugs20100608_bug05]"/>
Bug with treatment of <literal>as</literal>-patterns, which should not allow the redefinition of constructor status.
</simpara>
<simpara>Thanks to Michael Norrish for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7530"><literal>r7530</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug04" xreflabel="[Bugs20100608_bug04]"/>
Bug with treatment of <literal>nan</literal> in <link linkend="CommonSubexp">common subexpression elimination</link> <link linkend="SSA">SSA</link> optimization.
</simpara>
<simpara>Thanks to Alexandre Hamez for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7503"><literal>r7503</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug03" xreflabel="[Bugs20100608_bug03]"/>
Bug in translation from <link linkend="SSA2">SSA2</link> to <link linkend="RSSA">RSSA</link> with weak pointers.
</simpara>
<simpara>Thanks to Alexandre Hamez for the bug report.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7502"><literal>r7502</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug02" xreflabel="[Bugs20100608_bug02]"/>
Bug in amd64 codegen calling convention for varargs C calls.
</simpara>
<simpara>Thanks to <link linkend="HenryCejtin">HenryCejtin</link> for the bug report and <link linkend="WesleyTerpstra">WesleyTerpstra</link> for the initial diagnosis.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7501"><literal>r7501</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug01" xreflabel="[Bugs20100608_bug01]"/>
Bug in comment-handling in lexer for <link linkend="MLYacc">MLYacc</link>'s input language.
</simpara>
<simpara>Thanks to Michael Norrish for the bug report and patch.</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r7500"><literal>r7500</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20100608_bug00" xreflabel="[Bugs20100608_bug00]"/>
Bug in elaboration of function clauses with different numbers of arguments that would raise an uncaught <literal>Subscript</literal> exception.
</simpara>
<simpara>Fixed by revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r75497"><literal>r75497</literal></ulink>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Bugs20130715">
<title>Bugs20130715</title>
<simpara>Here are the known bugs in <link linkend="Release20130715">MLton 20130715</link>, listed
in reverse chronological order of date reported.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug06" xreflabel="[Bugs20130715_bug06]"/>
Bug with simultaneous <literal>sharing</literal> of multiple structures.
</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/9cb5164f6"><literal>9cb5164f6</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug05" xreflabel="[Bugs20130715_bug05]"/>
Minor bug with exception replication.
</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/1c89c42f6"><literal>1c89c42f6</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug04" xreflabel="[Bugs20130715_bug04]"/>
Minor bug erroneously accepting symbolic identifiers for strid, sigid, and fctid
and erroneously accepting symbolic identifiers before <literal>.</literal> in long identifiers.
</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/9a56be647"><literal>9a56be647</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug03" xreflabel="[Bugs20130715_bug03]"/>
Minor bug in precedence parsing of function clauses.
</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/1a6d25ec9"><literal>1a6d25ec9</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug02" xreflabel="[Bugs20130715_bug02]"/>
Performance bug in creation of worker threads to service calls of <literal>_export</literal>-ed
functions.
</simpara>
<simpara>Thanks to Bernard Berthomieu for the bug report.</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/97c2bdf1d"><literal>97c2bdf1d</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug01" xreflabel="[Bugs20130715_bug01]"/>
Bug in <literal>MLton.IntInf.fromRep</literal> that could yield values that violate the <literal>IntInf</literal>
representation invariants.
</simpara>
<simpara>Thanks to Rob Simmons for the bug report.</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/3add91eda"><literal>3add91eda</literal></ulink>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="Bugs20130715_bug00" xreflabel="[Bugs20130715_bug00]"/>
Bug in equality status of some arrays, vectors, and slices in Basis Library
implementation.
</simpara>
<simpara>Fixed by commit <ulink url="https://github.com/MLton/mlton/commit/a7ed9cbf1"><literal>a7ed9cbf1</literal></ulink>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Bugs20180207">
<title>Bugs20180207</title>
<simpara>Here are the known bugs in <link linkend="Release20180207">MLton 20180207</link>, listed
in reverse chronological order of date reported.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="CallGraph">
<title>CallGraph</title>
<simpara>For easier visualization of <link linkend="Profiling">profiling</link> data, <literal>mlprof</literal> can
create a call graph of the program in dot format, from which you can
use the <ulink url="http://www.research.att.com/sw/tools/graphviz/">graphviz</ulink>
software package to create a PostScript or PNG graph.  For example,</simpara>
<screen>mlprof -call-graph foo.dot foo mlmon.out</screen>
<simpara>will create <literal>foo.dot</literal> with a complete call graph.  For each source
function, there will be one node in the graph that contains the
function name (and source position with <literal>-show-line true</literal>), as
well as the percentage of ticks.  If you want to create a call graph
for your program without any profiling data, you can simply call
<literal>mlprof</literal> without any <literal>mlmon.out</literal> files, as in</simpara>
<screen>mlprof -call-graph foo.dot foo</screen>
<simpara>Because SML has higher-order functions, the call graph is is dependent
on MLton&#8217;s analysis of which functions call each other.  This analysis
depends on many implementation details and might display spurious
edges that a human could conclude are impossible.  However, in
practice, the call graphs tend to be very accurate.</simpara>
<simpara>Because call graphs can get big, <literal>mlprof</literal> provides the <literal>-keep</literal> option
to specify the nodes that you would like to see.  This option also
controls which functions appear in the table that <literal>mlprof</literal> prints.
The argument to <literal>-keep</literal> is an expression describing a set of source
functions (i.e. graph nodes).  The expression <emphasis>e</emphasis> should be of the
following form.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>all</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>"<emphasis>s</emphasis>"</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(and <emphasis>e &#8230;</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(from <emphasis>e</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(not <emphasis>e</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(or <emphasis>e</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(pred <emphasis>e</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(succ <emphasis>e</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(thresh <emphasis>x</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(thresh-gc <emphasis>x</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(thresh-stack <emphasis>x</emphasis>)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>(to <emphasis>e</emphasis>)</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>In the grammar, <literal>all</literal> denotes the set of all nodes.  <literal>"<emphasis>s</emphasis>"</literal> is
a regular expression denoting the set of functions whose name
(followed by a space and the source position) has a prefix matching
the regexp.  The <literal>and</literal>, <literal>not</literal>, and <literal>or</literal> expressions denote
intersection, complement, and union, respectively.  The <literal>pred</literal> and
<literal>succ</literal> expressions add the set of immediate predecessors or successors
to their argument, respectively.  The <literal>from</literal> and <literal>to</literal> expressions
denote the set of nodes that have paths from or to the set of nodes
denoted by their arguments, respectively.  Finally, <literal>thresh</literal>,
<literal>thresh-gc</literal>, and <literal>thresh-stack</literal> denote the set of nodes whose
percentage of ticks, gc ticks, or stack ticks, respectively, is
greater than or equal to the real number <emphasis>x</emphasis>.</simpara>
<simpara>For example, if you want to see the entire call graph for a program,
you can use <literal>-keep all</literal> (this is the default).  If you want to see
all nodes reachable from function <literal>foo</literal> in your program, you would
use <literal>-keep '(from "foo")'</literal>.  Or, if you want to see all the
functions defined in subdirectory <literal>bar</literal> of your project that used
at least 1% of the ticks, you would use</simpara>
<screen>-keep '(and ".*/bar/" (thresh 1.0))'</screen>
<simpara>To see all functions with ticks above a threshold, you can also use
<literal>-thresh x</literal>, which is an abbreviation for <literal>-keep '(thresh x)'</literal>.  You
can not use multiple <literal>-keep</literal> arguments or both <literal>-keep</literal> and <literal>-thresh</literal>.
When you use <literal>-keep</literal> to display a subset of the functions, <literal>mlprof</literal>
will add dashed edges to the call graph to indicate a path in the
original call graph from one function to another.</simpara>
<simpara>When compiling with <literal>-profile-stack true</literal>, you can use <literal>mlprof -gray
true</literal> to make the nodes darker or lighter depending on whether their
stack percentage is higher or lower.</simpara>
<simpara>MLton&#8217;s optimizer may duplicate source functions for any of a number
of reasons (functor duplication, monomorphisation, polyvariance,
inlining).  By default, all duplicates of a function are treated as
one.  If you would like to treat the duplicates separately, you can
use <literal>mlprof -split <emphasis>regexp</emphasis></literal>, which will cause all duplicates of
functions whose name has a prefix matching the regular expression to
be treated separately.  This can be especially useful for higher-order
utility functions like <literal>General.o</literal>.</simpara>
<section id="_caveats">
<title>Caveats</title>
<simpara>Technically speaking, <literal>mlprof</literal> produces a call-stack graph rather than
a call graph, because it describes the set of possible call stacks.
The difference is in how tail calls are displayed.  For example if <literal>f</literal>
nontail calls <literal>g</literal> and <literal>g</literal> tail calls <literal>h</literal>, then the call-stack graph
has edges from <literal>f</literal> to <literal>g</literal> and <literal>f</literal> to <literal>h</literal>, while the call graph has
edges from <literal>f</literal> to <literal>g</literal> and <literal>g</literal> to <literal>h</literal>.  That is, a tail call from <literal>g</literal>
to <literal>h</literal> removes <literal>g</literal> from the call stack and replaces it with <literal>h</literal>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CallingFromCToSML">
<title>CallingFromCToSML</title>
<simpara>MLton&#8217;s <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> allows programs to <emphasis>export</emphasis> SML
functions to be called from C.  Suppose you would like export from SML
a function of type <literal>real * char -&gt; int</literal> as the C function <literal>foo</literal>.
MLton extends the syntax of SML to allow expressions like the
following:</simpara>
<screen>_export "foo": (real * char -&gt; int) -&gt; unit;</screen>
<simpara>The above expression exports a C function named <literal>foo</literal>, with
prototype</simpara>
<programlisting language="c" linenumbering="unnumbered">Int32 foo (Real64 x0, Char x1);</programlisting>
<simpara>The <literal>_export</literal> expression denotes a function of type
<literal>(real * char -&gt; int) -&gt; unit</literal> that when called with a function
<literal>f</literal>, arranges for the exported <literal>foo</literal> function to call <literal>f</literal>
when <literal>foo</literal> is called.  So, for example, the following exports and
defines <literal>foo</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val e = _export "foo": (real * char -&gt; int) -&gt; unit;
val _ = e (fn (x, c) =&gt; 13 + Real.floor x + Char.ord c)</programlisting>
<simpara>The general form of an <literal>_export</literal> expression is</simpara>
<screen>_export "C function name" attr... : cFuncTy -&gt; unit;</screen>
<simpara>The type and the semicolon are not optional.  As with <literal>_import</literal>, a
sequence of attributes may follow the function name.</simpara>
<simpara>MLton&#8217;s <literal>-export-header</literal> option generates a C header file with
prototypes for all of the functions exported from SML.  Include this
header file in your C files to type check calls to functions exported
from SML.  This header file includes <literal>typedef</literal>s for the
<link linkend="ForeignFunctionInterfaceTypes">types that can be passed between SML and C</link>.</simpara>
<section id="_example">
<title>Example</title>
<simpara>Suppose that <literal>export.sml</literal> is</simpara>
<programlisting language="sml" linenumbering="unnumbered">val e = _export "f": (int * real * char -&gt; char) -&gt; unit;
val _ = e (fn (i, r, _) =&gt;
           (print (concat ["i = ", Int.toString i,
                           "  r = ", Real.toString r, "\n"])
            ; #"g"))
val g = _import "g" public reentrant: unit -&gt; unit;
val _ = g ()
val _ = g ()

val e = _export "f2": (Word8.word -&gt; word array) -&gt; unit;
val _ = e (fn w =&gt;
           Array.tabulate (10, fn _ =&gt; Word.fromLargeWord (Word8.toLargeWord w)))
val g2 = _import "g2" public reentrant: unit -&gt; word array;
val a = g2 ()
val _ = print (concat ["0wx", Word.toString (Array.sub (a, 0)), "\n"])

val e = _export "f3": (unit -&gt; unit) -&gt; unit;
val _ = e (fn () =&gt; print "hello\n");
val g3 = _import "g3" public reentrant: unit -&gt; unit;
val _ = g3 ()

(* This example demonstrates mutual recursion between C and SML. *)
val e = _export "f4": (int -&gt; unit) -&gt; unit;
val g4 = _import "g4" public reentrant: int -&gt; unit;
val _ = e (fn i =&gt; if i = 0 then () else g4 (i - 1))
val _ = g4 13

val (_, zzzSet) = _symbol "zzz" alloc: (unit -&gt; int) * (int -&gt; unit);
val () = zzzSet 42
val g5 = _import "g5" public: unit -&gt; unit;
val _ = g5 ()

val _ = print "success\n"</programlisting>
<simpara>Note that the the <literal>reentrant</literal> attribute is used for <literal>_import</literal>-ing the
C functions that will call the <literal>_export</literal>-ed SML functions.</simpara>
<simpara>Create the header file with <literal>-export-header</literal>.</simpara>
<screen>% mlton -default-ann 'allowFFI true'    \
        -export-header export.h         \
        -stop tc                        \
        export.sml</screen>
<simpara><literal>export.h</literal> now contains the following C prototypes.</simpara>
<screen>Int8 f (Int32 x0, Real64 x1, Int8 x2);
Pointer f2 (Word8 x0);
void f3 ();
void f4 (Int32 x0);
extern Int32 zzz;</screen>
<simpara>Use <literal>export.h</literal> in a C program, <literal>ffi-export.c</literal>, as follows.</simpara>
<programlisting language="c" linenumbering="unnumbered">#include &lt;stdio.h&gt;
#include "export.h"

/* Functions in C are by default PUBLIC symbols */
void g () {
        Char8 c;

        fprintf (stderr, "g starting\n");
        c = f (13, 17.15, 'a');
        fprintf (stderr, "g done  char = %c\n", c);
}

Pointer g2 () {
        Pointer res;
        fprintf (stderr, "g2 starting\n");
        res = f2 (0xFF);
        fprintf (stderr, "g2 done\n");
        return res;
}

void g3 () {
        fprintf (stderr, "g3 starting\n");
        f3 ();
        fprintf (stderr, "g3 done\n");
}

void g4 (Int32 i) {
        fprintf (stderr, "g4 (%d)\n", i);
        f4 (i);
}

void g5 () {
        fprintf (stderr, "g5 ()\n");
        fprintf (stderr, "zzz = %i\n", zzz);
        fprintf (stderr, "g5 done\n");
}</programlisting>
<simpara>Compile <literal>ffi-export.c</literal> and <literal>export.sml</literal>.</simpara>
<screen>% gcc -c ffi-export.c
% mlton -default-ann 'allowFFI true' \
         export.sml ffi-export.o</screen>
<simpara>Finally, run <literal>export</literal>.</simpara>
<screen>% ./export
g starting
...
g4 (0)
success</screen>
</section>
<section id="_download">
<title>Download</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/doc/examples/ffi/export.sml"><literal>export.sml</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/doc/examples/ffi/ffi-export.c"><literal>ffi-export.c</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CallingFromSMLToC">
<title>CallingFromSMLToC</title>
<simpara>MLton&#8217;s <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> allows an SML program to <emphasis>import</emphasis>
C functions.  Suppose you would like to import from C a function with
the following prototype:</simpara>
<programlisting language="c" linenumbering="unnumbered">int foo (double d, char c);</programlisting>
<simpara>MLton extends the syntax of SML to allow expressions like the following:</simpara>
<screen>_import "foo": real * char -&gt; int;</screen>
<simpara>This expression denotes a function of type <literal>real * char -&gt; int</literal> whose
behavior is implemented by calling the C function whose name is <literal>foo</literal>.
Thinking in terms of C, imagine that there are C variables <literal>d</literal> of type
<literal>double</literal>, <literal>c</literal> of type <literal>unsigned char</literal>, and <literal>i</literal> of type <literal>int</literal>.  Then,
the C statement <literal>i = foo (d, c)</literal> is executed and <literal>i</literal> is returned.</simpara>
<simpara>The general form of an <literal>_import</literal> expression is:</simpara>
<screen>_import "C function name" attr... : cFuncTy;</screen>
<simpara>The type and the semicolon are not optional.</simpara>
<simpara>The function name is followed by a (possibly empty) sequence of
attributes, analogous to C <literal>__attribute__</literal> specifiers.</simpara>
<section id="_example_2">
<title>Example</title>
<simpara><literal>import.sml</literal> imports the C function <literal>ffi</literal> and the C variable <literal>FFI_INT</literal>
as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">(* main.sml *)

(* Declare ffi to be implemented by calling the C function ffi. *)
val ffi = _import "ffi" public: real array * int * int ref * char ref * int -&gt; char;
open Array

val size = 10
val a = tabulate (size, fn i =&gt; real i)
val ri = ref 0
val rc = ref #"0"
val n = 17

(* Call the C function *)
val c = ffi (a, Array.length a, ri, rc, n)

(* FFI_INT is declared as public in ffi-import.c *)
val (nGet, nSet) = _symbol "FFI_INT" public: (unit -&gt; int) * (int -&gt; unit);

val _ = print (concat [Int.toString (nGet ()), "\n"])

val _ =
   print (if c = #"c" andalso !ri = 45 andalso !rc = c
             then "success\n"
          else "fail\n")</programlisting>
<simpara><literal>ffi-import.c</literal> is</simpara>
<programlisting language="c" linenumbering="unnumbered">#include "export.h"

Int32 FFI_INT = 13;
Word32 FFI_WORD = 0xFF;
Bool FFI_BOOL = 1;
Real64 FFI_REAL = 3.14159;

Char8 ffi (Pointer a1, Int32 a1len, Pointer a2, Pointer a3, Int32 n) {
        double *ds = (double*)a1;
        int *pi = (int*)a2;
        char *pc = (char*)a3;
        int i;
        double sum;

        sum = 0.0;
        for (i = 0; i &lt; a1len; ++i) {
                sum += ds[i];
                ds[i] += n;
        }
        *pi = (int)sum;
        *pc = 'c';
        return 'c';
}</programlisting>
<simpara>Compile and run the program.</simpara>
<screen>% mlton -default-ann 'allowFFI true' -export-header export.h  import.sml ffi-import.c
% ./import
13
success</screen>
</section>
<section id="_download_2">
<title>Download</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/doc/examples/ffi/import.sml"><literal>import.sml</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/doc/examples/ffi/ffi-import.c"><literal>ffi-import.c</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_next_steps_2">
<title>Next Steps</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CallingFromSMLToCFunctionPointer">CallingFromSMLToCFunctionPointer</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CallingFromSMLToCFunctionPointer">
<title>CallingFromSMLToCFunctionPointer</title>
<simpara>Just as MLton can <link linkend="CallingFromSMLToC">directly call C functions</link>, it
is possible to make indirect function calls; that is, function calls
through a function pointer.  MLton extends the syntax of SML to allow
expressions like the following:</simpara>
<screen>_import * : MLton.Pointer.t -&gt; real * char -&gt; int;</screen>
<simpara>This expression denotes a function of type</simpara>
<programlisting language="sml" linenumbering="unnumbered">MLton.Pointer.t -&gt; real * char -&gt; int</programlisting>
<simpara>whose behavior is implemented by calling the C function at the address
denoted by the <literal>MLton.Pointer.t</literal> argument, and supplying the C
function two arguments, a <literal>double</literal> and an <literal>int</literal>.  The C function
pointer may be obtained, for example, by the dynamic linking loader
(<literal>dlopen</literal>, <literal>dlsym</literal>, &#8230;).</simpara>
<simpara>The general form of an indirect <literal>_import</literal> expression is:</simpara>
<screen>_import * attr... : cPtrTy -&gt; cFuncTy;</screen>
<simpara>The type and the semicolon are not optional.</simpara>
<section id="_example_3">
<title>Example</title>
<simpara>This example uses <literal>dlopen</literal> and friends (imported using normal
<literal>_import</literal>) to dynamically load the math library (<literal>libm</literal>) and call the
<literal>cos</literal> function. Suppose <literal>iimport.sml</literal> contains the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature DYN_LINK =
   sig
      type hndl
      type mode
      type fptr

      val dlopen : string * mode -&gt; hndl
      val dlsym : hndl * string -&gt; fptr
      val dlclose : hndl -&gt; unit

      val RTLD_LAZY : mode
      val RTLD_NOW : mode
   end

structure DynLink :&gt; DYN_LINK =
   struct
      type hndl = MLton.Pointer.t
      type mode = Word32.word
      type fptr = MLton.Pointer.t

      (* These symbols come from a system libray, so the default import scope
       * of external is correct.
       *)
      val dlopen =
         _import "dlopen" : string * mode -&gt; hndl;
      val dlerror =
         _import "dlerror": unit -&gt; MLton.Pointer.t;
      val dlsym =
         _import "dlsym" : hndl * string -&gt; fptr;
      val dlclose =
         _import "dlclose" : hndl -&gt; Int32.int;

      val RTLD_LAZY = 0wx00001 (* Lazy function call binding.  *)
      val RTLD_NOW  = 0wx00002 (* Immediate function call binding.  *)

      val dlerror = fn () =&gt;
         let
            val addr = dlerror ()
         in
            if addr = MLton.Pointer.null
               then NONE
               else let
                       fun loop (index, cs) =
                          let
                             val w = MLton.Pointer.getWord8 (addr, index)
                             val c = Byte.byteToChar w
                          in
                             if c = #"\000"
                                then SOME (implode (rev cs))
                                else loop (index + 1, c::cs)
                          end
                    in
                       loop (0, [])
                    end
         end

      val dlopen = fn (filename, mode) =&gt;
         let
            val filename = filename ^ "\000"
            val hndl = dlopen (filename, mode)
         in
            if hndl = MLton.Pointer.null
               then raise Fail (case dlerror () of
                                   NONE =&gt; "???"
                                 | SOME s =&gt; s)
               else hndl
         end

      val dlsym = fn (hndl, symbol) =&gt;
         let
            val symbol = symbol ^ "\000"
            val fptr = dlsym (hndl, symbol)
         in
            case dlerror () of
               NONE =&gt; fptr
             | SOME s =&gt; raise Fail s
         end

      val dlclose = fn hndl =&gt;
         if MLton.Platform.OS.host = MLton.Platform.OS.Darwin
            then ()  (* Darwin reports the following error message if you
                      * try to close a dynamic library.
                      *   "dynamic libraries cannot be closed"
                      * So, we disable dlclose on Darwin.
                      *)
         else
            let
               val res = dlclose hndl
            in
               if res = 0
                  then ()
               else raise Fail (case dlerror () of
                                   NONE =&gt; "???"
                                 | SOME s =&gt; s)
            end
   end

val dll =
   let
      open MLton.Platform.OS
   in
      case host of
         Cygwin =&gt; "cygwin1.dll"
       | Darwin =&gt; "libm.dylib"
       | _ =&gt; "libm.so"
   end

val hndl = DynLink.dlopen (dll, DynLink.RTLD_LAZY)

local
   val double_to_double =
      _import * : DynLink.fptr -&gt; real -&gt; real;
   val cos_fptr = DynLink.dlsym (hndl, "cos")
in
   val cos = double_to_double cos_fptr
end

val _ = print (concat ["    Math.cos(2.0) = ", Real.toString (Math.cos 2.0), "\n",
                       "libm.so::cos(2.0) = ", Real.toString (cos 2.0), "\n"])

val _ = DynLink.dlclose hndl</programlisting>
<simpara>Compile and run <literal>iimport.sml</literal>.</simpara>
<screen>% mlton -default-ann 'allowFFI true'    \
        -target-link-opt linux -ldl     \
        -target-link-opt solaris -ldl   \
         iimport.sml
% iimport
    Math.cos(2.0) = ~0.416146836547
libm.so::cos(2.0) = ~0.416146836547</screen>
<simpara>This example also shows the <literal>-target-link-opt</literal> option, which uses the
switch when linking only when on the specified platform.  Compile with
<literal>-verbose 1</literal> to see in more detail what&#8217;s being passed to <literal>gcc</literal>.</simpara>
</section>
<section id="_download_3">
<title>Download</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/doc/examples/ffi/iimport.sml"><literal>iimport.sml</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CCodegen">
<title>CCodegen</title>
<simpara>The <link linkend="CCodegen">CCodegen</link> is a <link linkend="Codegen">code generator</link> that translates the
<link linkend="Machine">Machine</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> to C, which is further optimized
and compiled to native object code by <literal>gcc</literal> (or another C compiler).</simpara>
<section id="_implementation_3">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/codegen/c-codegen/c-codegen.sig"><literal>c-codegen.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/codegen/c-codegen/c-codegen.fun"><literal>c-codegen.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_3">
<title>Details and Notes</title>
<simpara>The <link linkend="CCodegen">CCodegen</link> is the original <link linkend="Codegen">code generator</link> for MLton.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Changelog">
<title>Changelog</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/CHANGELOG.adoc"><literal>CHANGELOG.adoc</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<screen>= CHANGELOG

== Version 20180206

Here are the changes from version 20130715 to version 20180206.

=== Summary

* Compiler.
  ** Added an experimental LLVM codegen (`-codegen llvm`); requires LLVM tools
  (`llvm-as`, `opt`, `llc`) version &amp;ge; 3.7.
  ** Made many substantial cosmetic improvements to front-end diagnostic
  messages, especially with respect to source location regions, type inference
  for `fun` and `val rec` declarations, signature constraints applied to a
  structure, `sharing type` specifications and `where type` signature
  expressions, type constructor or type variable escaping scope, and
  nonexhaustive pattern matching.
  ** Fixed minor bugs with exception replication, precedence parsing of function
  clauses, and simultaneous `sharing` of multiple structures.
  ** Made compilation deterministic (eliminate output executable name from
  compile-time specified `@MLton` runtime arguments; deterministically generate
  magic constant for executable).
  ** Updated `-show-basis` (recursively expand structures in environments,
  displaying components with long identifiers; append `(* @ region *)`
  annotations to items shown in environment).
  ** Forced amd64 codegen to generate PIC on amd64-linux targets.
* Runtime.
  ** Added `gc-summary-file file` runtime option.
  ** Reorganized runtime support for `IntInf` operations so that programs that
  do not use `IntInf` compile to executables with no residual dependency on GMP.
  ** Changed heap representation to store forwarding pointer for an object in
  the object header (rather than in the object data and setting the header to a
  sentinel value).
* Language.
  ** Added support for selected SuccessorML features; see
  http://mlton.org/SuccessorML for details.
  ** Added `(*#showBasis "file" *)` directive; see
  http://mlton.org/ShowBasisDirective for details.
  ** FFI:
    *** Added `pure`, `impure`, and `reentrant` attributes to `_import`.  An
    unattributed `_import` is treated as `impure`.  A `pure` `_import` may be
    subject to more aggressive optimizations (common subexpression elimination,
    dead-code elimination).  An `_import`-ed C function that (directly or
    indirectly) calls an `_export`-ed SML function should be attributed
    `reentrant`.
  ** ML Basis annotations.
    *** Added `allowSuccessorML {false|true}` to enable all SuccessorML features
    and other annotations to enable specific SuccessorML features; see
    http://mlton.org/SuccessorML for details.
    *** Split `nonexhaustiveMatch {warn|error|igore}` and `redundantMatch
    {warn|error|ignore}` into `nonexhaustiveMatch` and `redundantMatch`
    (controls diagnostics for `case` expressions, `fn` expressions, and `fun`
    declarations (which may raise `Match` on failure)) and `nonexhaustiveBind`
    and `redundantBind` (controls diagnostics for `val` declarations (which may
    raise `Bind` on failure)).
    *** Added `valrecConstr {warn|error|ignore}` to report when a `val rec` (or
    `fun`) declaration redefines an identifier that previously had constructor
    status.
* Libraries.
  ** Basis Library.
    *** Improved performance of `Array.copy`, `Array.copyVec`, `Vector.append`,
    `String.^`, `String.concat`, `String.concatWith`, and other related
    functions by using `memmove` rather than element-by-element constructions.
  ** `Unsafe` structure.
    *** Added unsafe operations for array uninitialization and raw arrays; see
    https://github.com/MLton/mlton/pull/207 for details.
  ** Other libraries.
    *** Updated: ckit library, MLLPT library, MLRISC library, SML/NJ library
* Tools.
  ** mlnlffigen
    *** Updated to warn and skip (rather than abort) when encountering functions
    with `struct`/`union` argument or return type.

=== Details

* 2018-02-6
  ** Remove ancient and unused `cmcat` tool.

* 2018-02-03
  ** Upgrade `gdtoa.tgz`.

* 2018-02-02
  ** Remove docs from `all` target of `./Makefile`; this eliminates the
  `all-no-docs` target (which was frequently used in favor of `all`).

* 2018-01-31
  ** Use C compiler with `-std=gnu11` (rather than `-std=gnu99`).
  ** Revert rudimentary support for `./configure`; the support was so minimal
  that it seems unhelpful to pretend that there are exhaustive compatibility
  checks being performed.  All of the basic configuration can be accomplished
  with simple `make` variable definitions.

* 2018-01-25
  ** Remove (expert, undocumented) `-debug-format` option; the same effect can
  be achieved with `-as-opt` and `-cc-opt`.
  ** Propagate C compiler from `./configure` to `mlton` script.

* 2018-01-24
  ** Extend `-target-*-opt` options to support `arch-os` pairs.
  ** Remove `./package/rpm/*` and corresponding targets in `./Makefile`;
  upstream MLton has not produced RPMs for years.

* 2018-01-24
  ** Slightly improve performance of `Vector.concat` and
  `String.{concat,concatWith,tokens,fields}` by avoiding `List.map`-s.

* 2018-01-23
  ** Restore, but deprecate, `-drop-pass` compile-time expert option.

* 2018-01-19
  ** Update SML/NJ libraries to SML/NJ 110.82.

* 2017-12-29
  ** Add support for `(*#showBasis "file" *)` directives.  This feature is
  meant to facilitate auto-completion via
  https://github.com/MatthewFluet/company-mlton[`company-mlton`] and similar
  tools.

* 2017-12-20
  ** Update performance comparison on website.  Thanks to Curtis Dunham for the
  pull request.

* 2017-12-17
  ** Updates to `-show-basis`:
    *** `-show-basis-flat`: Recursively expand structures in environments,
    displaying components with long identifiers.
    *** `-show-basis-def`: Appends `(* @ region *)` annotations to items shown
    in environment.
    *** `-show-basis-compact`: Tries to optimize vertical space (at the expense
    of long lines).

* 2017-12-11
  ** Drop `_BSD_SOURCE` and `_POSIX_C_SOURCE` feature macros in
  `./runtime/cenv.h`.

* 2017-12-10
  ** Add a `Dockerfile` to build/test MLton.  Thanks to Richard Laughlin for the
  pull request.

* 2017-12-06
  ** Remove `$PREFIX` and `$prefix` from top-level `Makefile.in`; use
  `./configure --prefix path`.  Thanks to Richard Laughlin for the pull
  request.

* 2017-12-03
  ** Fix heap invariant predicates.

* 2017-11-15
  ** Eliminate the use of (some) global mutable state for signal handling.

* 2017-11-14
  ** Store forwarding pointer for an object in the object header (rather than in
  the object data and setting the header to a sentinel value).

* 2017-11-02
  ** Updates to stack management in backend:
    *** Improve `Allocation.Stack.get`.
    *** Do not force `Cont` block arguments to stack.

* 2017-10-30
  ** In `signature SSA_TO_RSSA_STRUCTS` share by `Rssa.Atoms = Ssa.Atoms`.  This
  is the idiom used elsewhere in the compiler, rather than sharing individual
  sub-structures of `Atoms`.
  ** Minor updates to `DirectedGraph` and `Tree` in MLton library.

* 2017-10-23
  ** Add `-seed-rand w` compile-time option, to seed the pseudo-random number
  generator.
  ** Add a new MachineShuffle pass (disabled by default) that shuffles the
  collection of chunks within the program and shuffles the collection of blocks
  within a chunk.  With the `-seed-rand w` compile-time option, can be used to
  generate executables with distinct code placements.

* 2017-10-23
  ** Use a relative path in the `mlton` script, rather than an absolute path.
  The absolute path needed to be set to the intended installation directory,
  which made it difficult to install a binary release in a local directory.
  Undertaken by Maksim Yegorov at RIT supported by NSF CISE Research
  Infrastructure (CRI) award.

* 2017-10-21
  ** Add unsafe operations for array uninitialization and raw arrays.
    *** Rename `Array_uninit: SeqIndex.int -&gt; 'a array` primitive to
    `Array_alloc: SeqIndex.int -&gt; 'a array`.
    *** Add `Array_uninit: 'a array * SeqIndex.int -&gt; unit` primitive to set all
    objptrs in the element at the given index to a bogus non-objptr value
    (`0wx1`).  One motivation for this primitive is to support space-efficient
    polymorphic resizeable arrays.  When shrinking a resizeable array, we would
    like to "`NULL`" out the elements that are no longer part of the logical
    array, in order to avoid a (logical) space leak.
    *** Add `Array_uninitIsNop: 'a array -&gt; bool` primitive to answer if the
    `Array_uninit` primitive applied to the same array would be a nop (i.e., if
    the array has no objptrs in the elements).  This can be used to skip a
    bulk-`Array_uninit` loop when it is known that the `Array_uninit` operations
    would be nops.
    *** Add `Array_allocRaw: SeqIndex.int -&gt; 'a array` primitive to allocate an
    array, but with a header that indicates that the array has no objptrs.  Add
    `Array_toArray: 'a array -&gt; 'a array` primitive to update the header of an
    `Array_allocRaw` allocated array to reveal the objptrs.  One motiviation for
    this primitive is that, in a parallel setting, the uninitialization of an
    array can be a sequential bottleneck.  The `Array_allocRaw` is a constant
    time operation and the subsequent `Array_uninit` operations can be performed
    in parallel.
    *** Extend `structure Unsafe.Array` with additional operations.  See
    `./basis-library/sml-nj/unsafe.sig`.

* 2017-10-20
  ** Introduce ShareZeroVec SSA optimization to share zero-length vectors after
  coercion-based optimizations.  Undertaken by Maksim Yegorov at RIT supported
  by NSF CISE Research Infrastructure (CRI) award.

* 2017-10-18
  ** New canonicalization strategy for CommonSubexp SSA optimization.
  Previously, the canonicalization of commutative arithmetic primitives was
  sensitive to variable hashes (created by an unseeded pseudo-random number
  generator); now, the canonicalization of commutative arithmetic primitives is
  sensitive to relative definition order of variables.

* 2017-10-12
  ** Fix bug in runtime argument option parsing.

* 2017-10-05
  ** Many updates and improvements to diagnostic messages.  See
  https://github.com/MLton/mlton/pull/195 for details.

* 2017-09-27
  ** Add rudimentary support for `./configure`; in particular, support
  `--with-gmp-lib` and `--with-gmp-include` to set location of GMP and
  `--prefix` to specify an install prefix.  Undertaken by Maksim Yegorov at RIT
  supported by NSF CISE Research Infrastructure (CRI) award.

* 2017-08-21
  ** Introduce `Array_copyArray: 'a array * SeqIndex.int * 'a array *
  SeqIndex.int * SeqIndex.int -&gt; unit` and `Array_copyVector: 'a array *
  SeqIndex.int * 'a vector * SeqIndex.int * SeqIndex.int -&gt; unit` primitives
  which are used to implement a number of array and vector construction
  functions, particularly `append`, `concat`, and `concatWith`.  The primitives
  compile to `memmove` operations, which (significantly) outperforms MLton's
  element-by-element construction for large sequences.  Undertaken by Bryan Camp
  at RIT supported by NSF CISE Research Infrastructure (CRI) award.

* 2017-07-25
  ** Force PIC generation on amd64-linux targets.  Thanks to Kuen-Bang Hou
  (Favonia) for the pull request.

* 2017-07-11
  ** Generalize the `subWord` primitives to
+
----
      | WordArray_subWord of {seqSize:WordSize.t, eleSize: WordSize.t}
      | WordArray_updateWord of {seqSize: WordSize.t, eleSize: WordSize.t}
      | WordVector_subWord of {seqSize: WordSize.t, eleSize: WordSize.t}
----
+
Undertaken by Bryan Camp at RIT supported by NSF CISE Research Infrastructure
(CRI) award.

* 2017-07-11
  ** Add a parser combinator library (`structure StreamParser`) to the MLton
  Library.  Undertaken by Jason Carr at RIT supported by NSF CISE Research
  Infrastructure (CRI) award.
  ** Add a parser for the SXML IR (`structure ParseSxml`).  Undertaken by Jason
  Carr at RIT supported by NSF CISE Research Infrastructure (CRI) award.
  ** Allow compilation to start with a `.sxml` file.  Undertaken by Jason Carr
  at RIT supported by NSF CISE Research Infrastructure (CRI) award.

* 2017-06-29
  ** Replace `-drop-pass regex` compile-time option with `-disable-pass regex`
  compile option and add `-enable-pass regex` compile option.  Various XML,
  SXML, SSA, SSA2, RSSA, and Machine IR optimization passes are initialized with
  a default status, which can be overriden by `-{disable,enable}-pass`.  In
  particular, it is now easy to add a work-in-progress (and potentially buggy)
  pass to the simplification pipeline with `execute = false` default status, to
  be selectively executed with `-enable-pass`.  Undertaken by Bryan Camp at RIT
  supported by NSF CISE Research Infrastructure (CRI) award.
  ** Add LoopUnswitch and LoopUnroll SSA optimizations (undertaken by Matthew
  Surawski as an RIT CS MS Capstone Project).  Initial evaluation demonstrates
  some non-trivial performance gains, no non-trivial performance losses, and
  only minor code size increases, but currently disabled pending a more thorough
  evaluation.

* 2017-05-23
  ** Expand the set of MLB annotations:
    *** `nonexhaustiveBind`, `nonexhaustiveExnBind`, `redundantBind`: controls
    diagnostics for `val` declarations (which may raise `Bind` on failure).
    *** `nonexhaustiveMatch`, `nonexhaustiveExnMatch`, `redundantMatch`:
    controls diagnostics for `case` expressions, `fn` expressions, and `fun`
    declarations (which may raise `Match` on failure).
    *** `nonexhaustiveRaise`, `nonexhaustiveExnRaise`, `redundantRaise`:
    controls diagnostics for `handle` expressions (which implicitly re-raise on
    failure).  Note that `nonexhaustiveRaise` and `nonexhaustiveExnRaise`
    default to `ignore`.  The combination of `nonexhaustiveRaise warn` and
    `nonexhaustiveExnRaise ignore` can be useful for finding handlers that
    handle some, but not all, values of an exception variant.
  ** Make a number of improvements to diagnostic messages:
    *** Display nonexhaustive exception patterns as `_ : exn`, rather than
    `e`.
    *** Normalize nonexhaustive patterns by sorting (e.g., by `ConApp` name).
    *** Report complete enumeration of unhandled constants, rather than a single
    example.
    *** Report nonexhaustive patterns of record type as records, rather than as
    tuples.

* 2017-04-20
  ** Updates to SSA, SSA2, and RSSA IR support infrastructure
    *** Display more context when reporting SSA and SSA2 IR type errors.
    *** Add `-layout-width n` compile expert option to control the target width
    for the pretty printer.
    *** Make cosmetic improvments to SSA and SSA2 IR display (uses of global
    variables bound to small constants and conapps are commented with the
    corresponding value; include loop forest for functions with `-keep dot`).
    *** Improve RSSA constant folding and copy propagation.
    *** Limit Machine IR `Globals` to variables used outside of the `main`
    function.

* 2017-04-15
  ** Add `gc-summary-file file` runtime option.

* 2017-04-15
  ** Rename and add `smlnj-mlton-x{2,4,8,16}` top-level `Makefile` targets.
  ** Update SML/NJ librarys to SML/NJ 110.80 (making use of supported
  SuccessorML features).
  ** Not support for SML/NJ extensions via SuccessorML MLB annotations on
  website.

* 2017-04-14
  ** Add support for vector expressions (`#[e1, e2, ..., en]`) and vector
  patterns (`#[p1, p2, ..., pn]`) and add `Vector_vector` n-ary primitive.
  Initial support for vector expressions and the `Vector_vector` primitive were
  undertaken by Krishna Ravikumar as an RIT CS MS Capstone Project.

* 2017-03-29
  ** Update DOS eol handling and tweak error messages in lexer.

* 2017-03-27
  ** Correct off-by-one error in column numbers.  Thanks to Jacob Zimmerman for
  the error report and pull request.

* 2017-03-15
  ** Updates to SuccessorML support:
    *** Add an `allowSuccessorML {false|true}` MLB annotation to enable all
    Successor ML features with a single annotation.
    *** Fix parsing of numeric labels to only accept an INT token that does not
    begin with 0, is not an extended literal, is not negative, and is decimal.
    *** Drop the alternate word prefixes (`0xw` and `0bw`).
    *** Unconditionally allow line comments in MLB files.
    *** Allow UTF-8 byte sequences in text constants.
    *** Refactor `ml.lex` and `mlb.lex` to be more maintainable.
    *** Rename `allowRecPunning` annotation to `allowRecordPunExps`.

* 2017-02-27
  ** Update ML-Yacc examples (`calc`, `fol`, `pascal`) to comply with MLton
  build process.  Thanks to Hai Nguyen Van for the pull request.

* 2017-01-25
  ** Update PortingMLton documentation and `./bin/add-cross` script.  Thanks to
  Daniel Moerner for the pull request.

* 2016-09-29
  ** Constant fold `CPointer_equal(NULL, NULL)` to `true`.

* 2016-09-29
  ** Introduce `NEEDS_SIGALTSTACK_EXEC` config in runtime system.

* 2016-09-27
  ** Construct a devel build version string from last commit time and last
  commit hash.
  ** Omit build date and build node from version banner; makes self-compiles
  deterministic.
  ** Remove `upgrade-basis.sml` from build.  The generated `upgrade-basis.sml`
  was introduced to handle incompatibilities in the Basis Library provided by an
  old version of MLton and the Basis Library assumed by the current sources.
  However, there are no incompatibilities with MLton 20130715, MLton 20100608,
  or MLton 20070826.  Nonetheless, the feature testing performed by
  `./bin/upgrade-basis` to generate `upgrade-basis.sml` is time consuming,
  especially when trying to simply type check the compiler sources.

* 2016-06-20
  ** Do not `gzip` man pages on OpenBSD.  Thanks to Alexander Abushkevich for
  the pull request.

* 2016-06-20
  ** Generate position independent code for OpenBSD.  Thanks to Alexander
  Abushkevich for the pull request.

* 2016-06-20
  ** Fix profiling for amd64-openbsd and x86-openbsd.  Thanks to Alexander
  Abushkevich for the pull request.

* 2016-04-06
  ** Update SML/NJ librarys to SML/NJ 110.79.

* 2016-03-22
  ** Update LLVM codegen to support (and require) &gt;= llvm-3.7.  Thanks to Eugene
  Akentyev for the pull request.

* 2016-02-26
  ** Configure GMP location via `Makefile`.

* 2016-01-10
  ** Fix typo in `mlb-formal.tex`.  Thanks to Jon Sterling for the pull request.

* 2015-11-10
  ** Update SML/NJ librarys to SML/NJ 110.78.  Use `allowOrPats` and
  `allowSigWithtype` to minimize diffs.

* 2015-10-20
  ** Fix elaboration of `withtype` in signature.

* 2015-10-06
  ** Add support for setting CM anchor bindings in `cm2mlb` tool.

* 2015-10-06
  ** Fix non-exhaustive match warnings with or-patterns.  Thanks to Rob Simmons
  for the bug report.
  ** Distinguish between partial and fully redundant matches.
  ** Report partial redundancy in `val` declarations.
  ** Lower precedence of or-patterns in parser.
  ** Make a variety of cosmetic improvements to non-exhaustive and redundant
  error/warning messages, primarily to be consistent in formatting between
  quoted AST and generated messages.

* 2015-07-10
  ** Extend support for arm64 (aarch64).  Thanks to Edmund Evans for the patch.

* 2015-06-22
  ** Introduce `valrecConstr {warn|error|ignore}` MLB annotation to report when
  a `val rec` (or `fun`) declaration redefines an identifier that previously had
  constructor status.

* 2015-06-19
  ** Add support for selected SuccessorML features (undertaken by Kevin Bradley
  as an RIT CS MS Capstone Project).
    *** `do`-declarations (`allowDoDecls`)
    *** extended literals (`allowExtendedLiterals`)
    *** line comments (`allowLineComments`)
    *** optional leading bar in matches, fun decls, and datatype decls
    (`allowOptBar`)
    *** optional trailing semicolon in sequence expressions (`allowOptSemicolon`)
    *** or patterns (`allowOrPats`)
    *** record expression punning (`allowRecPunning`)
    *** withtype in signatures (`allowSigWithtype`)

* 2015-06-10
  ** Hide equality status of poly (and mono) vector and array slices.
  ** Hide type equality of mono and poly `Word8.word` arrays and vectors.

* 2015-06-08
  ** Added `reentrant` attribute to `_import`.  An `_import`-ed C function that
  (directly or indirectly) calls an `_export`-ed SML function should be
  attributed `reentrant`.

* 2015-06-08
  ** Make compilation deterministic:
    *** Eliminate output executable name from compile-time specified `@MLton`
    arguments.
    *** Deterministically generate magic constant for executable.

* 2015-06-08
  ** Add `-keep ast` compile option.  Undertaken by Ross Bayer at RIT supported
  by NSF CISE Research Infrastructure (CRI) award.

* 2015-06-02
  ** Updates to Debian packaging.  Thanks to Christopher Cramer for the pull
  request.

* 2015-03-30
  ** Use `LANG=en_us` when computing version and build date.  Thanks to Eugene
  Akentyev for the pull request.

* 2015-02-17
  ** Update `mlnlffigen` to warn and skip functions with `struct`/`union`
  arguments.  Thanks to Armando Doval for the pull request.

* 2014-12-22
  ** Move pervasive constructs from `./mlton/ast` to `./mlton/atoms`, so that
  `./mlton/ast/sources.mlb` depends on `./mlton/atoms/sources.mlb` (and not the
  other way around).  Undertaken by Vedant Raiththa at RIT supported by NSF CISE
  Research Infrastructure (CRI) award.

* 2014-12-17
  ** Cache a worker thread to service calls of `_export`-ed functions.  Thanks
  to Bernard Berthomieu for the bug report.

* 2014-12-02
  ** Post-process generated front-end files for compatibility with SML/NJ's
  recent `ml-lex` and `ml-yacc` tools that generate log identifiers rather than
  unqualified (top-level environment) identifiers.
  ** Corrected documentation for SML/NJ `Makefile` target and fixed
  `bootstrap-nj` target.  Thanks to Daniel Rosenwasser for the pull request.

* 2014-11-21
  ** Reorganized runtime support for `IntInf` operations so that programs that
  do not use `IntInf` compile to executables with no residual dependency on GMP.
  ** Fixed bug in `MLton.IntInf.fromRep` that could yield values that violate
  the `IntInf` representation invariants. Thanks to Rob Simmons for the bug
  report.

* 2014-10-24
  ** Added `pure` and `impure` attributes to `_import`.  An unattributed
  `_import` is treated as `impure`.  A `pure` `_import` may be subject to more
  aggressive optimizations (common subexpression elimination, dead-code
  elimination).  Undertaken by Vedant Raiththa at RIT supported by NSF CISE
  Research Infrastructure (CRI) award.

* 2014-10-22
  ** Various updates to treatment of `IntInf` constants in the compiler.
    *** Recognize both `Big` and `Small` representations of `IntInf`-s.
    *** Translate `IntInf` consts to `Big` and `Small` representations in
    conversion from SSA to RSSA. This is consistent with the treatment of other
    `IntInf` operations in the conversion. After the conversion, `IntInf` is no
    longer treated as a primitive.
    *** Remove `initIntInfs` from program initialization.
    *** Constant fold `IntInf_toVector` and `WordVector_toIntInf` primitives.

* 2014-10-20
  ** Various updates to `structure WordXVector` in compiler proper.
    *** Update the `WordXVector.layout` function. If the `elementSize` is
   `WordX.word8` and more than 90% of the characters satisfy `Char.isGraph
   orelse Char.isSpace`, then display as an SML string constant (with
   non-printable characters SML-escaped). Otherwise, display as an SML/NJ-style
   `#[0x0, 0xF]` vector literal.
    *** Update initialization of `static struct GC_vectorInit vectorInits[]`
   constants in runtime. If the `WordXVector`'s (primitive) `elementSize` is
   `WordSize.W8`, then emit a C-escaped string constant. Otherwise, emit a
   C-array initialization.

* 2014-08-15
  ** More updates to benchmark infrastructure.
    *** Make `update-counts.sh` script more robust.
    *** Update `hamlet.sml` benchmark program to close input file after each
    loop.
    *** Update `fft.sml` benchmark program to only invoke `test` function with
    power-of-2 arguments.
    *** Update `model-elimination.sml` benchmark program to iterate `main ()`
    according to `doit` size parameter.

* 2014-08-11
  ** Include `winsock2.h` before `windows.h` in MinGW port.  Thanks to Shu-Hung
  You for the pull request.

* 2014-07-31
  ** Refactor array and vector implementation in Basis Library into a primitive
  implementation (using `SeqInt.int` for indexing) and a wrapper implementation
  (using the default `Int.int` for indexing).  Thanks to Rob Simmons for the
  pull request.
  ** Correct description of `MLton.{Vector,Array}.unfoldi` on website.  Thanks
  to Rob Simmons for the pull request.

* 2014-07-14
  ** Updates to benchmark infrastructure.
    *** Add `even-odd.sml` benchmark that exercises mutual tail recursion.
    *** Add `update-counts.sh` script to calculate appropriate benchmark
    iteration counts and update benchmark iteration counts so that all
    benchmarks run for at least 30 seconds.
    *** Updates to benchmark driver program.

* 2014-07-07
  ** Change `./basis-library/integer/int-inf.sml` to reduce dependency on
  GMP-specific details of `./basis-library/integer/int-inf0.sml`.  Thanks to Rob
  Simmons for the pull request.
  ** Correct type and description of `MLton.IntInf.fromRep` on website.  Thanks
  to Rob Simmons for the pull request.

* 2014-07-01
  ** Add experimental LLVM codegen (undertaken by Brian Leibig as an RIT CS MS
  Project).

* 2014-06-09
  ** Update `CallingFromSMLToC` page on website.  Thanks to Bikal Gurung for the
  pull request.

* 2014-03-18
  ** Updates for MinGW port.

* 2014-02-07
  ** Update AsciiDoc sources for website.

* 2013-10-31
  ** Various updates to website.  Thanks to Mauricio C Antunes for the pull
  request.
    *** Add Tofte's tutorial and Rossberg's grammar.
    *** Fix links to implementations.

* 2013-10-10
  ** Update links from `References` page on website.  Thanks to Mauricio C
  Antunes for the pull request.

* 2013-09-02
  ** Fix example for `Lazy` page on website.  Thanks to Daniel Rosenwasser for
  the pull request.

== Version 20130715

Here are the changes from version 20100608 to version 20130715.

=== Summary

* Compiler.
  ** Cosmetic improvements to type-error messages.
  ** Removed features:
    *** Bytecode codegen: The bytecode codegen had not seen significant use and
    it was not well understood by any of the active developers.
    *** Support for `.cm` files as input: The ML Basis system provides much
    better infrastructure for "programming in the very large" than the (very)
    limited support for CM.  The `cm2mlb` tool (available in the source
    distribution) can be used to convert CM projects to MLB projects, preserving
    the CM scoping of module identifiers.
  ** Bug fixes: see changelog
* Runtime.
  ** Bug fixes: see changelog
* Language.
  ** Interpret `(*#line line:col "file" *)` directives as relative
  file names.
  ** ML Basis annotations.
    *** Added: `resolveScope`
* Libraries.
  ** Basis Library.
    *** Improved performance of `String.concatWith`.
    *** Use bit operations for `REAL.class` and other low-level operations.
    *** Support additional variables with `Posix.ProcEnv.sysconf`.
    *** Bug fixes: see changelog
  ** `MLton` structure.
    *** Removed: `MLton.Socket`
  ** Other libraries.
    *** Updated: ckit library, MLRISC library, SML/NJ library
    *** Added: MLLPT library
* Tools.
  ** mllex
    *** Generate `(*#line line:col "file.lex" *)` directives with simple
    (relative) file names, rather than absolute paths.
  ** mlyacc
    *** Generate `(*#line line:col "file.grm" *)` directives with simple
    (relative) file names, rather than absolute paths.
    *** Fixed bug in comment-handling in lexer.

=== Details

* 2013-07-06
  ** Update SML/NJ libraries to SML/NJ 110.76.

* 2013-06-19
  ** Upgrade `gdtoa.tgz`; fixed bug in `Real32.{fmt,toDecimal,toString}`, which
  in some cases produced too many digits

* 2013-06-18
  ** Removed `MLton.Socket` structure (deprecated in last release).

* 2013-06-10
  ** Improved performance of `String.concatWith`.

* 2013-05-22
  ** Update SML/NJ libraries to SML/NJ 110.75.

* 2013-04-30
  ** Detect PowerPC 64 architecture.

* 2012-10-09
  ** Fixed bug in elaboration that erroneously accepted the following:

      signature S = sig structure A : sig type t end
                              and B : sig type t end where type t = A.t end

* 2012-09-04
  ** Introduce an MLB annotation to control overload and flex record resolution
  scope: `resolveScope {strdec|dec|topdec|program}`.

* 2012-07-04
  ** Simplify use of `getsockopt` and `setsockopt` in Basis Library.
  ** Direct implementation of `Socket.Ctl.{getATMARK,getNREAD}` in runtime
  system, rather than indirect implementation in Basis Library via `ioctl`.
  ** Replace use of casting through a union with `memcpy` in runtime.

* 2012-06-11
  ** Use bit operations for `REAL.class` and other low-level operations.
  ** Fixed bugs in `REAL.copySign`, `REAL.signBit`, and `REAL.{to,from}Decimal`.

* 2012-06-01
  ** Cosmetic improvements to type-error messages.
  ** Fixed bug in elaboration that erroneously rejected the following:

      datatype ('a, ''a) t = T
      type ('a, ''a) u = unit

  and erroneously accepted the following:

      fun f (x: 'a) : ''a = x
      fun g (x: 'a) : ''a = if x = x then x else x

* 2012-02-24
  ** Fixed bug in redundant SSA optimization.

* 2011-06-20
  ** Support additional variables with `Posix.ProcEnv.sysconf`.

* 2011-06-17
  ** Change `mllex` and `mlyacc` to generate `#line` directives with simple file
  names, rather than absolute paths.
  ** Interpret `#line` directives as relative file names.

* 2011-06-14
  ** Fixed bug in SSA/SSA2 shrinker that could erroneously turn a non-tail
  function call with a `Bug` transfer as its continuation into a tail function
  call.

* 2011-06-11
  ** Update SML/NJ libraries to SML/NJ 110.73 and add ML-LPT library.

* 2011-06-10
  ** Fixed bug in translation from SSA2 to RSSA with case expressions over
  non-primitive-sized words.
  ** Fixed bug in SSA/SSA2 type checking of case expressions over words.

* 2011-06-04
  ** Upgrade `gdtoa.tgz`.
  ** Remove bytecode codegen.
  ** Remove support for `.cm` files as input.

* 2011-05-03
  ** Fixed a bug with the treatment of `as`-patterns, which should not allow the
  redefinition of constructor status.

* 2011-02-18
  ** Fixed bug with treatment of nan in common subexpression elimination SSA
  optimization.

* 2011-02-18
  ** Fixed bug in translation from SSA2 to RSSA with weak pointers.

* 2011-02-05
  ** Fixed bug in amd64 codegen calling convention for varargs C calls.

* 2011-01-17
  ** Fixed bug in comment-handling in lexer for `mlyacc`'s input language.

* 2010-06-22
  ** Fixed bug in elaboration of function clauses with different numbers of
  arguments that would raise an uncaught `Subscript` exception.


== Version 20100608

Here are the changes from version 20070826 to version 20100608.

=== Summary

* New platforms.
  ** ia64-hpux
  ** powerpc64-aix
* Compiler.
  ** Command-line switches.
    *** Added: `-mlb-path-var '&lt;name&gt; &lt;value&gt;'`
    *** Removed: `-keep sml`, `-stop sml`
  ** Improved constant folding of floating-point operations.
  ** Experimental: Support for compiling to a C library; see wiki documentation.
  ** Extended `-show-def-use` output to include types of variable definitions.
  ** Deprecated features (to be removed in a future release)
    *** Bytecode codegen: The bytecode codegen has not seen significant use and
    it is not well understood by any of the active developers.
    *** Support for `.cm` files as input: The ML Basis system provides much
    better infrastructure for "programming in the very large" than the (very)
    limited support for CM.  The `cm2mlb` tool (available in the source
    distribution) can be used to convert CM projects to MLB projects, preserving
    the CM scoping of module identifiers.
  ** Bug fixes: see changelog
* Runtime.
  ** `@MLton` switches.
    *** Added: `may-page-heap {false|true}`
  ** `may-page-heap`: By default, MLton will not page the heap to disk when
  unable to grow the heap to accomodate an allocation.  (Previously, this
  behavior was the default, with no means to disable, with security an
  least-surprise issues.)
  ** Bug fixes: see changelog
* Language.
  ** Allow numeric characters in ML Basis path variables.
* Libraries.
  ** Basis Library.
    *** Bug fixes: see changelog.
  ** `MLton` structure.
    *** Added: `MLton.equal`, `MLton.hash`, `MLton.Cont.isolate`,
    `MLton.GC.Statistics, `MLton.Pointer.sizeofPointer`,
    `MLton.Socket.Address.toVector`
    *** Changed:
    *** Deprecated: `MLton.Socket`
  ** `Unsafe` structure.
    *** Added versions of all of the monomorphic array and vector structures.
  ** Other libraries.
    *** Updated: ckit library, MLRISC library, SML/NJ library.
* Tools.
  ** `mllex`
    *** Eliminated top-level `type int = Int.int` in output.
    *** Include `(*#line line:col "file.lex" *)` directives in output.
    *** Added `%posint` command, to set the `yypos` type and allow the lexing of
    multi-gigabyte files.
   ** `mlnlffigen`
    *** Added command-line switches `-linkage archive` and `-linkage shared`.
    *** Deprecated command-line switch `-linkage static`.
    *** Added support for ia64 and hppa targets.
   ** `mlyacc`
    *** Eliminated top-level `type int = Int.int` in output.
    *** Include `(*#line line:col "file.grm" *)` directives in output.

=== Details

* 2010-05-12
  ** Fixed bug in the mark-compact garbage collector where the C library's
  `memcpy` was used to move objects during the compaction phase; this could lead
  to heap corruption and segmentation faults with newer versions of `gcc` and/or
  `glibc`, which assume that src and dst in a `memcpy` do not overlap.

* 2010-03-12
  ** Fixed bug in elaboration of `datatype` declarations with `withtype`
  bindings.

* 2009-12-11
  ** Fixed performance bug in RefFlatten SSA2 optimization.

* 2009-12-09
  ** Fixed performance bug in SimplifyTypes SSA optimization.

* 2009-12-02
  ** Fixed bug in amd64 codegen register allocation of indirect C calls.

* 2009-09-17
  ** Fixed bug in `IntInf.scan` and `IntInf.fromString` where leading spaces
  were only accepted if the stream had an explicit sign character.

* 2009-07-10
  ** Added CombineConversions SSA optimization.

* 2009-06-09
  ** Removed deprecated command line switch `-show-anns {false, true}`.

* 2009-04-18
  ** Removed command line switches `-keep sml` and `-stop sml`.  Their meaning
  was unclear with `.mlb` files; their effect with `.cm` files can be achieved
  with `-stop f`.

* 2009-04-16
  ** Fixed bug in `IntInf.~&gt;&gt;` that could cause a `glibc` assertion failure.

* 2009-04-01
  ** Fixed exported type of `MLton.Process.reap`.

* 2009-01-27
  ** Added `MLton.Socket.Address.toVector` to get the network-byte-order
  representation of an IP address.

* 2008-11-10
  ** Fixed bug in `MLton.size` and `MLton.share` when tracing the current stack.

* 2008-10-27
  ** Fixed phantom typing of sockets by hiding the representation of socket
  types.  Previously the representation of sockets was revealed rendering the
  phantom types useless.

* 2008-10-10
  ** Fixed bug in nested `_export`/`_import` functions.

* 2008-09-12
  ** Improved constant folding of floating point operations.

* 2008-08-20
  ** Store the card/cross map at the end of the allocated ML heap; avoids
  possible out of memory errors when resizing the ML heap cannot be followed by
  a card/cross map allocation.

* 2008-07-24
  ** Added support for compiling to a C library. The relevant new compiler
  options are `-ar` and `-format`. Libraries are named based on the name of the
  `-export-header` file. Libraries have two extra methods:
    *** `NAME_open(argc, argv)` initializes the library and runs the SML code
    until it reaches the end of the program. If the SML code exits or raises an
    uncaught exception, the entire program will terminate.
    *** `NAME_close()` will execute any registered atExit functions, any
    outstanding finalizers, and frees the ML heap.

* 2008-07-16
  ** Fixed bug in the name mangling of `_import`-ed functions with the `stdcall`
  convention.

* 2008-06-12
  ** Added `MLton.Pointer.sizeofPointer`.

* 2008-06-06
  ** Added expert command line switch `-emit-main {true|false}`.

* 2008-05-17
  ** Fixed bug in Windows code to page the heap to disk when unable to grow the
  heap to a desired size. Thanks to Sami Evangelista for the bug report.

* 2008-05-10
  ** Implemented `MLton.Cont.isolate`.

* 2008-04-20
  ** Fixed bug in *NIX code to page the heap to disk when unable to grow the
  heap to a desired size. Thanks to Nicolas Bertolotti for the bug report and
  patch.

* 2008-04-07
  ** More flexible active/paused stack resizing policy. +
  Removed `thread-shrink-ratio` runtime option. + Added
  `stack-current-grow-ratio`, `stack-current-max-reserved-ratio`,
  `stack-current-permit-ratio`, `stack-current-shrink-ratio`,
  `stack-max-reserved-ratio`, and `stack-shrink-ratio` runtime options.

* 2008-04-07
  ** Fixed bugs in Basis Library where the representations of `OS.IO.iodesc`,
  `Posix.IO.file_desc`, `Posix.Signal.signal`, `Socket.sock`,
  `Socket.SOGK.sock_type` as integers were exposed.

* 2008-03-14
  ** Added unsafe versions of all of the monomorphic array and vector
  structures.

* 2008-03-02
  ** Fixed bug in Basis Library where the representation of `OS.Process.status`
  as an integer was exposed.

* 2008-02-13
  ** Fixed space-safety bug in RefFlatten optimization (to flatten refs into
  containing data structure). Thanks to Daniel Spoonhower for the bug report and
  initial diagnosis and patch.

* 2008-01-25
  ** Various updates to GC statistics gathering.  Some basic GC statistics can
  be accessed from SML by `MLton.GC.Statistics.*` functions.

* 2008-01-24
  ** Added primitive (structural) polymorphic hash.

* 2008-01-21
  ** Fixed frontend to accept `op _longvid_` patterns and expressions. Thanks to
     Florian Weimer for the bug report.

* 2008-01-17
  ** Extended `-show-def-use` output to include types of variable definitions.

* 2008-01-09
  ** Extended `MLton_equal` to be a structural equality on all types, including
  `real` and `-&gt;` types.

* 2007-12-18
  ** Changed ML-Yacc and ML-Lex to output line directives so that MLton's
  def-use information points to the source files (`.grm` and `.lex`) instead of
  the generated implementations (`.grm.sml` and `.lex.sml`).

* 2007-12-14
  ** Added runtime option `may-page-heap {false|true}`.  By default, MLton will
  not page the heap to disk when unable to grow the heap to a desired size.
  (Previously, this behavior was the default, with no means to disable, with
  security and least-surprise concerns.) Thanks to Wesley Terpstra for the
  patch.
  ** Fixed bug the FFI visible representation of `Int16.int ref` (and references
  of other primitive types smaller than 32-bits) on big-endian platforms. Thanks
  to Dave Herman for the bug report.

* 2007-12-13
  ** Fixed bug in `ImperativeIOExtra.canInput` (`TextIO.canInput`). Thanks to
     Ville Laurikari for the bug report.

* 2007-12-09
  ** Better constant folding of `IntInf` operations.

* 2007-12-07
  ** Fixed bug in algebraic simplification of `RealX` primitives.  `Real.&lt;= (x,
  x)` is `false` when `x` is `NaN`.

* 2007-11-29
  ** Fixed bug in type inference of flexible records.  This would later cause
  the compiler to raise the `TypeError` exception. Thanks to Wesley Terpstra for
  the bug report.

* 2007-11-28
  ** Fixed bug in cross-compilation of `gdtoa` library. Thanks to Wesley
  Terpstra for the bug report and patch.

* 2007-11-20
  ** Fixed bug in RefFlatten optimization (pass to flatten refs into containing
  data structure). Thanks to Ruy LeyWild for the bug report.

* 2007-11-19
  ** Fixed bug in the handling of weak pointers by the mark-compact garbage
  collector. Thanks to Sean McLaughlin for the bug report and Florian Weimer for
  the initial diagnosis.

* 2007-11-07
  ** Added `%posint` command to `ml-lex`, to set the `yypos` type and allow the
  lexing of multi-gigabyte input files. Thanks to Florian Weimer for the feature
  concept and original patch.

* 2007-11-07
  ** Added command-line switch `-mlb-path-var '&lt;name&gt; &lt;value&gt;'` for specifying
  MLB path variables.

* 2007-11-06
  ** Allow numeric characters in MLB path variables.

* 2007-09-20
  ** Fixed bug in elaboration of structures with signature constraints.  This
  would later cause the compiler to raise the `TypeError` exception. Thanks to
  Vesa Karvonen for the bug report.

* 2007-09-11
  ** Fixed bug in interaction of `_export`-ed functions and signal
  handlers. Thanks to Sean McLaughlin for the bug report.

* 2007-09-03
  ** Fixed bug in implementation of `_export`-ed functions using `char`
  type. Thanks to Katsuhiro Ueno for the bug report.


== Version 20070826

Here are the changes from version 20051202 to version 20070826.

=== Summary

* New platforms:
  ** amd64-linux, amd64-freebsd
  ** hppa-hpux
  ** powerpc-aix
  ** x86-darwin (Mac OS X)
* Compiler.
  ** Support for 64-bit platforms.
    *** Native amd64 codegen.
  ** Command-line switches.
    *** Added: `-codegen amd64`, `-codegen x86`, `-default-type &lt;type&gt;`,
    `-profile-val {false|true}`.
    *** Changed: `-stop f` (file listing now includes `.mlb` files)
  ** Bytecode codegen.
    *** Support for profiling.
    *** Support for exception history.
* Language.
  ** ML Basis annotations.
    *** Removed: `allowExport`, `allowImport`, `sequenceUnit`, `warnMatch`.
* Libraries.
  ** Basis Library.
    *** Added: `PackWord16Big, `PackWord16Little`, `PackWord64Big`,
    `PackWord64Little`.
    *** Bug Fixes: see changelog.
  ** `MLton` structure.
    *** Added: `MLTON_MONO_ARRAY`, `MLTON_MONO_VECTOR`, `MLTON_REAL`,
    `MLton.BinIO.tempPrefix`, `MLton.CharArray`, `MLton.CharVector`,
    `MLton.IntInf.BigWord`, `MLton.IntInf.SmallInt`,
    `MLton.Exn.defaultTopLevelHandler`, `MLton.Exn.getTopLevelHandler`,
    `MLton.Exn.setTopLevelHandler`, `MLton.LargeReal`, `MLton.LargeWord`,
    `MLton.Real`, `MLton.Real32`, `MLton.Real64`, `MLton.Rlimit.Rlim`,
    `MLton.TextIO.tempPrefix`, `MLton.Vector.create`, `MLton.Word.bswap`,
    `MLton.Word8.bswap`, `MLton.Word16`, `MLton.Word32`, `MLton.Word64`,
    `MLton.Word8Array`, `MLton.Word8Vector`.
    *** Changed: `MLton.Array.unfoldi`, `MLton.IntInf.rep`, `MLton.Rlimit`,
    `MLton.Vector.unfoldi`.
    *** Deprecated: `MLton.Socket`
  ** Other libraries.
    *** Added: MLRISC libary.
    *** Updated: ckit library, SML/NJ library.
* Tools.

=== Details

* 2007-08-12
  ** Removed deprecated ML Basis annotations.

* 2007-08-06
  ** Fixed bug in treatment of `Real&lt;N&gt;.{scan,fromString}` operations.
  `Real&lt;N&gt;.{scan,fromString}` were using `TO_NEAREST` semantics, but should obey
  current rounding mode.  (Only `Real&lt;N&gt;.fromDecimal` is specified to always
  have `TO_NEAREST` semantics.)  Thanks to Sean McLaughlin for the bug report.

* 2007-07-27
  ** Fixed bugs in constant-folding of floating-point operations with C codegen.

* 2007-07-26
  ** Fixed bug in treatment of floating-point operations.  Floating-point
  operations depend on the current rounding mode, but were being treated as
  pure. Thanks to Sean McLaughlin for the bug report.

* 2007-07-13
  ** Added `MLton.Exn.{default,get,set}TopLevelHandler`.

* 2007-07-12
  ** Restored `native` option to `-codegen` flag.

* 2007-07-11
  ** Fixed bug in `Real32.toInt`: conversion of real values close to
  `Int.maxInt` could be incorrect.

* 2007-07-07
  ** Updates to bytecode code generator: support for amd64-* targets, support
  for profiling (including exception history).
  ** Fixed bug in `Socket` module of Basis Library; unmarshalling of socket
  options (for `get*` functions) used `andb` rather than `orb`. Thanks to Anders
  Petersson for the bug report (and patch).

* 2007-07-06
  ** Fixed bug in `Date` module of Basis Library; some functions would
  erroneously raise `Date` when given a year &lt;= 1900. Thanks to Joe Hurd for the
  bug report.
  ** Fixed a long-standing bug in monomorphisation pass. Thanks to Vesa Karvonen
  for the bug report.

* 2007-05-18
  ** Native amd64 code generator for amd64-* targets.
  ** Eliminate `native` option from `-codegen` flag.
  ** Add `x86` and `amd64` options to `-codegen` flag.

* 2007-04-29
  ** Improved type checking of RSSA and Machine ILs.

* 2007-04-14
  ** Fixed aliasing issues with `basis/Real/*.c` files.
  ** Added real/word casts in `MLton` structure.

* 2007-04-12
  ** Added primitives for bit cast of word to/from real.
  ** Implement `PackReal&lt;N&gt;{Big,Little}` using `PackWord&lt;N&gt;{Big,Little}` and bit
  casts.

* 2007-04-11
  ** Move all system header `#include`-s to `platform/` os headers.
  ** Use C99 `&lt;assert.h&gt;`, rather than custom `"assert.{h,c}"`.

* 2007-03-13
  ** Implement `PackWord&lt;N&gt;{Big,Little}` entirely in ML, using an ML byte swap
  function.

* 2007-02-25
  ** Change amd64-* target platforms from 32-bit compatibility mode (i.e.,
  `-m32`) to 64-bit mode (i.e., `-m64`).  Currently, only the C codegen is able
  to generate 64-bit executables.

* 2007-02-23
  ** Removed expert command line switch `-coalesce &lt;n&gt;`.
  ** Added expert command line switch `-chunkify {coalesce&lt;n&gt;|func|one}`.

* 2007-02-20
  ** Fixed bug in `PackReal&lt;N&gt;.toBytes`. Thanks to Eric McCorkle for the bug
  report (and patch).

* 2007-02-18
  ** Added command line switch `-profile-val`, to profile the evaluation of
  `val` bindings; this is particularly useful with exception history for
  debugging uncaught exceptions at the top-level.

* 2006-12-29
  ** Added command line switch `-show {anns|path-map}` and deprecated command
  line switch `-show-anns {false|true}`.  Use `-show path-map` to see the
  complete MLB path map as seen by the compiler.

* 2006-12-20
  ** Changed the output of command line switch `-stop f` to include `.mlb`
  files.  This is useful for generating Makefile dependencies.  The old output
  is easy to recover if necessary (e.g. `grep -v '\.mlb$'`).

* 2006-12-08
  ** Added command line switches `-{,target}-{as,cc,link}-opt-quote`, which pass
  their argument as a single argument to `gcc` (i.e., without tokenization at
  spaces).  These options support using headers and libraries (including the
  MLton runtime headers and libraries) from a path with spaces.

* 2006-12-02
  ** Extensive reorganization of garbage collector, runtime system, and Basis
  Library implementation. (This is in preparation for future 64bit support.)
  They should be more C standards compliant and easier to port to new systems.
  ** FFI revisions
    *** Disallow nested indirect types (e.g., `int array array`).

* 2006-11-30
  ** Fixed a bug in elaboration of FFI forms; unary FFI types (e.g., `array`,
  `ref`, `vector`) could be used in places where `MLton.Pointer.t` was required.
  This would later cause the compiler to raise the `TypeError` exception, along
  with a lot of XML IL.

* 2006-11-19
  ** On *-darwin, work with GnuMP installed via Fink or MacPorts.

* 2006-10-30
  ** Ported to x86-darwin.

* 2006-09-23
  ** Added missing specification of `find` to the `MONO_VECTOR` signature.

* 2006-08-03
  ** Fixed a bug in Useless SSA optimization, caused by calling an imported C
  function and then ignoring the result.

* 2006-06-24
  ** Fixed a bug in pass to flatten data structures. Thanks to Joe Hurd for the
  bug report.

* 2006-06-08
  ** Fixed a bug in the native codegen's implementation of the C-calling
  convention.

* 2006-05-11
  ** Ported to PowerPC-AIX.
  ** Fixed a bug in the runtime for the cases where nonblocking IO with sockets
  was implemented using `MSG_DONTWAIT`.  This flag does not exist on AIX,
  Cygwin, HPUX, and MinGW and was previously just ignored.  Now the runtime
  simulates the flag for these platforms (except MinGW, yet, where it's still
  ignored).

* 2006-05-06
  ** Added `-default-type '&lt;ty&gt;&lt;N&gt;'` for specifying the binding of default types
  in the Basis Library (e.g., `Int.int`).

* 2006-04-25
  ** Ported to HPPA-HPUX.
  ** Fixed `PackReal{,32,64}{Big,Little}` to follow the Basis Library
  specification.

* 2006-04-19
  ** Fixed a bug in `MLton.share` that could cause a segfault.

* 2006-03-30
  ** Changed `MLton.Vector.unfoldi` to return the state in addition to the
  result vector.

* 2006-03-30
  ** Added `MLton.Vector.create`, a more powerful vector-creation function than
  is available in the basis library.

* 2006-03-04
  ** Added MLRISC from SML/NJ 110.57 to standard distribution.

* 2006-03-03
  ** Fixed bug in SSA simplifier that could eliminate an irredundant test.

* 2006-03-02
  ** Ported a bugfix from SML/NJ for a bug with the combination of `withNack`
  and `never` in CML.

* 2006-02-09
  ** Support compiler specific annotations in ML Basis files.  If an annotation
  contains `:`, then the text preceding the `:` is meant to denote a compiler.
  For MLton, if the text preceding the `:` is equal to `mlton`, then the
  remaining annotation is scanned as a normal annotation.  If the text preceding
  the `:` is not-equal to `mlton`, then the annotation is ignored, and no
  warning is issued.

* 2006-02-04
  ** Fixed bug in elaboration of functors; a program with a very large number of
  functors could exhibit the error `ElaborateEnv.functorClosure: firstTycons`.


== Version 20051202

Here are the changes from version 20041109 to version 20051202.

=== Summary

* New license: BSD-style instead of GPL.
* New platforms:
  ** hppa: Debian Linux.
  ** x86: MinGW.
* Compiler.
  ** improved exception history.
  ** Command-line switches.
    *** Added: `-as-opt`, `-mlb-path-map`, `-target-as-opt`, `-target-cc-opt`.
    *** Deprecated: none.
    *** Removed: `-native`, `-sequence-unit`, `-warn-match`, `-warn-unused`.
* Language.
  ** FFI syntax changes and extensions.
    *** Added: `_symbol`.
    *** Changed: `_export`, `_import`.
    *** Removed: `_ffi`.
  ** ML Basis annotations.
    *** Added: `allowFFI`, `nonexhaustiveExnMatch`, `nonexhaustiveMatch`,
    `redundantMatch`, `sequenceNonUnit`.
    *** Deprecated: `allowExport`, `allowImport`, `sequenceUnit`, `warnMatch`.
* Libraries.
  ** Basis Library.
    *** Added: `Int1`, `Word1`.
  ** `MLton` structure.
    *** Added: `Process.create`, `ProcEnv.setgroups`, `Rusage.measureGC`,
        `Socket.fdToSock`, `Socket.Ctl.getError`.
    *** Changed: `MLton.Platform.Arch`.
  ** Other libraries.
    *** Added: ckit library, ML-NLFFI library, SML/NJ library.
* Tools.
  ** updates of `mllex` and `mlyacc` from SML/NJ.
  ** added `mlnlffigen`.
  ** profiling supports better inclusion/exclusion of code.

=== Details

* 2005-11-19
  ** Updated SML/NJ Library and CKit Library from SML/NJ 110.57.

* 2005-11-15
  ** Fixed a bug in `MLton.ProcEnv.setgroups`.

* 2005-11-11
  ** Fixed a bug in the interleaving of lexing/parsing and elaborating of ML
  Basis files, which would raise an unhandled `Force` exception on cyclic basis
  references. Thanks to John Dias for the bug report.

* 2005-11-10
  ** Fixed two bugs in `Time.scan`.  One would raise `Time` on a string with a
  large fractional component.  Thanks to Carsten Varming for the bug report.
  The other failed to scan strings with an explicit sign followed by a decimal
  point.

* 2005-11-03
  ** Removed `MLton.GC.setRusage`.
  ** Added `MLton.Rusage.measureGC`.

* 2005-09-11
  ** Fixed bug in display of types with large numbers of type variables, which
  could cause unhandled exception `Chr`.

* 2005-09-08
  ** Fixed bug in type inference of flexible records that would show up as
  `"Type error: variable applied to wrong number of type args"`.

* 2005-09-06
  ** Fixed bug in `Real.signBit`, which had assumed that the underlying C
  signbit returned 0 or 1, when in fact any nonzero value is allowed to indicate
  the signbit is set.

* 2005-09-05
  ** Added `-mlb-path-map` switch.

* 2005-08-25
  ** Fixed bug in `MLton.Finalizable.touch`, which was not keeping alive
  finalizable values in all cases.

* 2005-08-18
  ** Added SML/NJ Library and CKit Library from SML/NJ 110.55 to standard
  distribution.
  ** Fixed bug in `Socket.Ctl.*`, which got the endianness wrong on big-endian
  machines. Thanks to Wesley Terpstra for the bug report and fix.
  ** Added `MLton.GC.setRusage`.
  ** Fixed bug in `mllex`, which had file positions starting at 2.  They now
  start at zero.

* 2005-08-15
  ** Fixed bug in `LargeInt.scan`, which should skip leading `"0x"` and `"0X"`.
  Thanks to Wesley Terpstra for the bug report and fix.

* 2005-08-06
  ** Additional revisions of FFI:
    *** Deprecated `_export` with incomplete annotation.
    *** Added `_address` for address of C objects.
    *** Eliminated address component of `_symbol`.
    *** Changed the type of the `_symbol*` expression.
    *** See documentation for more detail.

* 2005-08-06
  ** Annotation changes:
    *** Deprecated: `sequenceUnit`
    *** Added: `sequenceNonUnit`

* 2005-08-03
  ** Annotation changes:
    *** Deprecated: `allowExport`, `allowImport`, `warnMatch`
    *** Added: `allowFFI`, `nonexhaustiveExnMatch`, `nonexhaustiveMatch`,
    `redundantMatch`

* 2005-08-01
  ** Update `mllex` and `mlyacc` with SML/NJ 110.55+ versions.  This
  incorporates a small number of minor bug fixes.

* 2005-07-23
  ** Fixed bug in pass to flatten refs into containing data structure.

* 2005-07-23
  ** Overhaul of FFI:
    *** Deprecated `_import` of C base types.
    *** Added `_symbol` for address, getter, and setter of C base types.
    *** See documentation for more detail.

* 2005-07-21
  ** Update `mllex` and `mlyacc` with SML/NJ 110.55 versions.  This incorporates
  a small number of minor bug fixes.

* 2005-07-20
  ** Fixed bug in front end that allowed unary constructors to be used without
  an argument in patterns.

* 2005-07-19
  ** Eliminated `_ffi`, which has been deprecated for some time.

* 2005-07-14
  ** Fixed bug in runtime that caused getrusage to be called on every GC, even
  if timing info isn't needed.

* 2005-07-13
  ** Fixed bug in closure conversion tickled by making a weak pointer to a
  closure.

* 2005-07-12
  ** Changed `{OS,Posix}.Process.sleep` to call `nanosleep()` instead of
  `sleep()`.
  ** Added `MLton.ProcEnv.setgroups`.

* 2005-07-11
  ** `InetSock.{any,toAddr}` raise `SysErr` if port is not in [0, 2^16^).

* 2005-07-02
  ** Fixed bug in `Socket.recvVecFrom{,',NB,NB'}`.  The type was too polymorphic
  and allowed the creation of a bogus `sock_addr`.

* 2005-06-28
  ** The front end now reports errors on encountering undefined or cyclicly
  defined MLB path variables.

* 2005-05-22
  ** Fixed bug in `Posix.IO.{getlk,setlk,setlkw}` that caused a link-time error:
  undefined reference to `Posix_IO_FLock_typ`.
  ** Improved exception history so that the first entry in the history is the
  source position of the raise, and the rest is the call stack.

* 2005-05-19
  ** Improved exception history for `Overflow` exceptions.

* 2005-04-20
  ** Fixed a bug in pass to flatten refs into containing data structure.

* 2005-04-14
  ** Fixed a front-end bug that could cause an internal bug message of the form
  `"missing flexInst"`.

* 2005-04-13
  ** Fixed a bug in the representation of flat arrays/vectors that caused
  incorrect behavior when the element size was 2 or 4 bytes and there were
  multiple components to the element (e.g. `(char * char) vector`).

* 2005-04-01
  ** Fixed a bug in `GC_arrayAllocate` that could cause a segfault.

* 2005-03-22
  ** Added structures `Int1`, `Word1`.

* 2005-03-19
  ** Fixed a bug that caused `Socket.Ctl.{get,set}LINGER` to raise `Subscript`.
  The problem was in the use of `PackWord32Little.update`, which scales the
  supplied index by `bytesPerElem`.

* 2005-03-13
  ** Fixed a bug in CML mailboxes.

* 2005-02-26
  ** Fixed an off-by-one error in `mkstemp` defined in `mingw.c`.

* 2005-02-13
  ** Added `mlnlffigen` tool (heavily adapted from SML/NJ).

* 2005-02-12
  ** Added MLNLFFI Library (heavily adapted from SML/NJ) to standard
  distribution.

* 2005-02-04
  ** Fixed a bug in `OS.path.toString`, which did not raise `InvalidArc` when
  needed.

* 2005-02-03
  ** Fixed a bug in `OS.Path.joinDirFile`, which did not raise `InvalidArc` when
  passed a file that was not an arc.

* 2005-01-26
  ** Fixed a front end bug that incorrectly rejected expansive __valbind__s with
  useless bound type variables.

* 2005-01-22
  ** Fixed x86 codegen bug which failed to account for the possibility that a
  64-bit move could interfere with itself (as simulated by 32-bit moves).

* 2004-12-22
  ** Fixed `Real32.fmt StringCvt.EXACT`, which had been producing too many
  digits of precision because it was converting to a `Real64.real`.

* 2004-12-15
  ** Replaced MLB path variable `MLTON_ROOT` with `SML_LIB`, to use a more
  compiler-independent name.  We will keep `MLTON_ROOT` aliased to `SML_LIB`
  until after the next release.

* 2004-12-02
  ** `Unix.create` now works on all platforms (including Cygwin and MinGW).

* 2004-11-24
  ** Added support for `MLton.Process.create`, which works on all platforms
  (including Windows-based ones like Cygwin and MinGW) and allows better control
  over `std{in,out,err}` for child process.


== Version 20041109

Here are the changes from version 20040227 to 20041109.

=== Summary

* New platforms:
  ** x86: FreeBSD 5.x, OpenBSD
  ** PowerPC: Darwin (MacOSX)
* Support for MLBasis files.
* Support for dynamic libraries.
* Support for Concurrent ML (CML).
* New structures: `Int2`, `Int3`, ..., `Int31` and `Word2`, `Word3`, ..., `Word31`.
* A new form of profiling: `-profile count`.
* A bytecode generator.
* Data representation improvements.
* `MLton` structure changes.
   ** Added: `share`, `shareAll`
   ** Changed: `Exn`, `IntInf`, `Signal`, `Thread`.
* Command-line switch changes.
   ** Deprecated:
     *** `-native` (use `-codegen`)
     *** `-sequence-unit` (use `-default-ann`)
     *** `-warn-match` (use `-default-ann`)
     *** `-warn-unused` (use `-default-ann`)
   ** Removed:
     *** `-detect-overflow`
     *** `-exn-history` (use `-const`)
     *** `-safe`
     *** `-show-basis-used`
   ** Added:
     *** `-codegen`
     *** `-const`
     *** `-default-ann`
     *** `-disable-ann`
     *** `-profile-branch`
     *** `-target-link-opt`

=== Details

* 2004-09-22
  ** Extended `_import` to support indirect function calls.

* 2004-09-13
  ** Made `Date.{fromString,scan}` accept a space (treated as zero) in the first
  character of the day of the month.

* 2004-09-12
  ** Fixed bug in `IntInf` that could cause a segfault.
  ** Remove `MLton.IntInf.size`.

* 2004-09-05
  ** Made `-detect-overflow` and `-safe` expert options.

* 2004-08-30
  ** Added `val MLton.share: 'a -&gt; unit`, which maximizes sharing in a heap
  object.

* 2004-08-27
  ** Fixed bug in `Real.toLargeInt`.  It would incorrectly raise `Option`
  instead of `Overflow` in the case when the real was not an `INF`, but rounding
  produced an `INF`.
  ** Fixed bugs in `Date.{fmt,fromString,scan,toString}`.  They incorrectly
  allowed a space for the first character in the day of the month.

* 2004-08-18
  ** Changed `MLton.{Thread,Signal,World}` to distinguish between implicitly and
  explicitly paused threads.

* 2004-07-28
  ** Added support for programming in the large using the ML Basis system.

* 2004-07-11
  ** Fixed bugs in `ListPair.*Eq` functions, which incorrectly raised the
  `UnequalLengths` exception.

* 2004-07-01
  ** Added `val MLton.Exn.addExnMessager: (exn -&gt; string option) -&gt; unit`.

* 2004-06-23
  ** Runtime system options that take memory sizes now accept a "`g`" suffix
  indicating gigabytes.  They also now take a real instead of an integer,
  e.g. `fixed-heap 0.5g`.  They also now accept uppercase, e.g. `150M`.

* 2004-06-12
  ** Added support for OpenBSD.

* 2004-06-10
  ** Added support for FreeBSD 5.x.

* 2004-05-28
  ** Deprecated the `-native` flag.  Instead, use the new flag `-codegen
  {native|bytecode|C}`.  This is in anticipation of adding a bytecode compiler.

* 2004-05-26
  ** Fixed a front-end bug that could cause cascading error to print a very
  large and unreadable internal bug message of the form `"datatype ... realized
  with scheme Unknown"`.

* 2004-05-17
  ** Automatically restart functions in the Basis Library that correspond
  directly to interruptable system calls.

* 2004-05-13
  ** Added `-profile count`, for dynamic counts of function calls and branches.
  ** Equate the types `Posix.Signal.signal` and `Unix.signal`.

* 2004-05-11
  ** Fixed a bug with `-basis 1997` that would cause type errors due to
  differences between types in the MLton structure and types in the rest of the
  basis library.

* 2004-05-01
  ** Fixed a bug with sharing constraints in signatures that would sometimes
  mistakenly treat two structures as identical when they shouldn't have been.
  This would cause some programs to be mistakenly rejected.

* 2004-04-30
  ** Added `MLton.Signal.{handled,restart}`.

* 2004-04-23
  ** Added `Timer.checkCPUTimes`, and updated the `Timer` structure to match the
    latest basis spec.  Also fixed `totalCPUTimer` and `totalRealTimer`, which
    were wrong.

* 2004-04-13
  ** Added `MLton.Signal.Mask.{getBlocked,isMember}`.

* 2004-04-12
  ** Fix bug that mistakenly generalized variable types containing unknown types
  when matching against a signature.
  ** Reasonable front-end error message when unification causes recursive
  (circular) type.

* 2004-04-03
  ** Fixed bug in sharing constraints so that `sharing A = B = C` means that all
  pairs `A = B`, `A = C`, `B = C` are shared, not just `A = B` and `B = C`.
  This matters in some situations.

* 2004-03-20
  ** Fixed `Time.now` which was treating microseconds as nanoseconds.

* 2004-03-14
  ** Fixed SSA optimizer bug that could cause the error `"&lt;type&gt; has no
  tyconInfo property"`.

* 2004-03-11
  ** Fixed `Time.fromReal` to raise `Time`, not `Overflow`, on unrepresentable
  times.

* 2004-03-04
  ** Added structures `Word2`, `Word3`, ..., `Word31`.

* 2004-03-03
  ** Added structures `Int2`, `Int3`, ..., `Int31`.
  ** Fixed bug in elaboration of `and` with signatures, structures, and functors
  so that it now evaluates all right-hand sides before binding any left-hand
  sides.


== Version 20040227

Here are the changes from version 20030716 to 20040227.

=== Summary

* The front end now follows the Definition of SML and produces readable error
messages.
* Added support for NetBSD.
* Basis library changes tracking revisions to the specification.
* Added structures: `Int64`, `Real32`, `Word64`.
* File positions use `Int64`.
* Major improvements to `-show-basis`, which now displays the basis in a very
readable way with full type information.
* Command-line switch changes.
   ** Deprecated: `-basis`.
   ** Removed: `-lib-search`, `-link`, `-may-load-world`, `-static`.
   ** Added: `-link-opt`, `-runtime`, `-sequence-unit`, `-show-def-use`,
   `-stop tc`, `-warn-match`, `-warn-unused`.
   ** Changed: `-export-header`, `-show-basis`, `-show-basis-used`.
   ** Renamed: `-host` to `-target`.
* FFI changes.
   ** Renamed `_ffi` as `_import`.
   ** Added `cdecl` and `stdcall` attributes to `_import` and `_export`
   expressions.
* MLton structure changes.
   ** Added: Pointer.
   ** Removed: Ptrace.
   ** Changed: `Finalizable`, `IntInf`, `Platform`, `Random`, `Signal`, `Word`.

=== Details

* 2004-02-16
  ** Changed `-export-header`, `-show-basis`, `-show-basis-used` to take a file
  name argument, and they no longer force compilation to halt.
  ** Added `-show-def-use` and `-warn-unused`, which deal with def-use
  information.

* 2004-02-13
  ** Added flag `-sequence-unit`, which imposes the constraint that in the
  sequence expression `(e1; e2)`, `e1` must be of type `unit`.

* 2004-02-10
  ** Lots of changes to `MLton.Signal`: name changes, removal of superfluous
  functions, additional functions.

* 2004-02-09
  ** Extended `-show-basis` so that when used with an input program, it shows
  the basis defined by the input program.
  ** Added `stop` runtime argument.
  ** Made `-call-graph {false|true}` an option to `mlprof` that determines
  whether or not a call graph file is written.

* 2004-01-20
  ** Fixed a bug in `IEEEReal.{fromString,scan}`, which would improperly return
  `INF` instead of `ZERO` for things like `"0.0000e123456789012345"`.
  ** Fixed a bug in `Real.{fromDecimal,fromString,scan}`, which didn't return an
  appropriately signed zero for `~0.0`.
  ** Fixed a bug in `Real.{toDecimal,fmt}`, which didn't correctly handle
  `~0.0`.
  ** Report a compile-time error on unrepresentable real constants.

* 2004-01-05
  ** Removed option `-may-load-world`.  You can now use `-runtime no-load-world`
  instead.
  ** Removed option `-static`.  You can now use `-link-opt -static` instead.
  ** Changed `MLton.IntInf.size` to return 0 instead of 1 on small ints.

* 2003-12-28
  ** Fixed horrible bug in `MLton.Random.alphaNumString` that caused it to
  return 0 for all characters beyond position 11.

* 2003-12-17
  ** Removed `-basis` as a normal flag.  It is still available as an expert
  flag, but its use is deprecated.  It will almost certainly disappear after the
  next release.

* 2003-12-10
  ** Allow multiple `@MLton --` runtime args in sequnce.  This makes it easier
  for scripts to prefix `@MLton` args without having to splice them with other
  ones.

* 2003-12-04
  ** Added support for files larger than 2G.  This included changing
  `Position` from `Int32` to `Int64`.

* 2003-12-01
  ** Added `structure MLton.Pointer`, which includes a `type t` for pointers
  (memory addresses, not SML heap pointers) and operations for loading from and
  storing to memory.

* 2003-11-03
  ** Fixed `Timer.checkGCTime` so that only the GC user time is included, not GC
  system time.

* 2003-10-13
  ** Added `-warn-match` to control display nonexhaustive and redundant
  match warnings.
  ** Fixed space leak in `StreamIO` causing the entire stream to be retained.
  Thanks to Jared Showalter for the bug report and fix.

* 2003-10-10
  ** Added `-stop tc` switch to stop after type checking.

* 2003-09-25
  ** Fixed `Posix.IO.getfl`, which had mistakenly called `fcntl` with `F_GETFD`
  instead of `F_GETFL`.
  ** Tracking basis library changes:
    *** `Socket` module datagram functions no longer return amount written,
    since they always write the entire amount or fail.  So,
    `send{Arr,Vec}To{,'}` now return `unit` instead of `int`.
    *** Added nonblocking versions of all the send and recv functions, as well
    as accept and connect.  So, we now have: `acceptNB`, `connectNB`,
    `recv{Arr,Vec}{,From}NB{,'}`, `send{Arr,Vec}{,To}NB{,'}`.

* 2003-09-24
  ** Tracking basis library changes:
    *** `TextIO.inputLine` now returns a `string option`.
    *** Slices used in `Byte`, `PRIM_IO`, `PrimIO`, `Posix.IO`, `StreamIO`.
    *** `Posix.IO.readVec` raises `Size`, not `Subscript`, with negative
    argument.

* 2003-09-22
  ** Fixed `Real.toManExp` so that the mantissa is in [0.5, 1), not [1, 2).  The
  spec says that 1.0 &lt;= man * radix &lt; radix, which since radix is 2, implies
  that the mantissa is in [0.5, 1).
  ** Added `Time.{from,to}Nanoseconds`.

* 2003-09-11
  ** Added `Real.realRound`.
  ** Added `Char{Array,Vector}Slice` to `Text`.

* 2003-09-11
  ** `OS.IO.poll` and `Socket.select` now raise errors on negative timeouts.
  ** `Time.time` is now implemented using `IntInf` instead of `Int`, which means
  that a much larger range of time values is representable.

* 2003-09-10
  ** `Word64` is now there.

* 2003-09-09
  ** Replaced `Pack32{Big,Little}` with `PackWord32{Big,Little}`.
  ** Fixed bug in `OS.FileSys.fullPath`, which mistakenly stopped as soon as it
  hit a symbolic link.

* 2003-09-08
  ** Fixed `@MLton max-heap`, which was mistakenly ignored.  Cleaned up `@MLton
  fixed-heap`.  Both `fixed-heap` and `max-heap` can use copying or mark-compact
  collection.

* 2003-09-06
  ** `Int64` is completely there.
  ** Fixed `OS.FileSys.tmpName` so that it creates the file, and doesn't use
  `tmpnam`.  This eliminates an annoying linker warning message.

* 2003-09-05
  ** Added structures `{LargeInt,LargeReal,LargeWord,Word}{Array,Array2,ArraySlice,Vector,VectorSlice}`
  ** Fixed bug in `Real.toDecimal`, which return class `NORMAL` for subnormals.
  ** Fixed bug in `Real.toLargeInt`, which didn't return as precise an integer
  as possible.

* 2003-09-03
  ** Lots of fixes to `REAL` functions.
    *** `Real32` is now completely in place, except for `Real32.nextAfter` on
    SunOS.
    *** Fixed `Real.Math.exp` on x86 to return the right value when applied to
    `posInf` and `negInf`.
    *** Changed `Real.Math.{cos,sin,tan}` on x86 to always use a call to the C
    math library instead of using the x86 instruction.  This eliminates some
    anomalies between compiling `-native false` and `-native true`.
    *** Change `Real.Math.pow` to handle exceptional cases in the SML code.
    *** Fixed `Real.signBit` on Sparcs.

* 2003-08-28
  ** Fixed `PackReal{,64}Little` to work correctly on Sparc.
  ** Added `PackReal{,64}Big`, `PackReal32{Big,Little}`.
  ** Added `-runtime` switch, which passes arguments to the runtime via
  `@MLton`.  These arguments are processed before command line switches.
  ** Eliminated MLton switch `-may-load-world`.  Can use `-runtime` combined
  with new runtime switch `-no-load-world` to disable load world in an
  executable.

* 2003-08-26
  ** Changed `-host` to `-target`.
  ** Split `MLton.Platform.{arch,os}` into `MLton.Platform.{Arch,OS}.t`.

* 2003-08-21
  ** Fixed bug in C codegen that would cause undefined references to
  `Real_{fetch,move,store}` when compiling on Sparcs with `-align 4`.

* 2003-08-17
  ** Eliminated `-link` and `-lib-search`, which are no longer needed.
  Eliminated support for passing `-l*`, `-L*`, and `*.a` on the command line.
  Use `-link-opt` instead.

* 2003-08-16
  ** Added `-link-opt`, for passing options to `gcc` when linking.

* 2003-07-19
  ** Renamed `_ffi` as `_import`.  The old `_ffi` will remain for a while, but
  is deprecated and should be replaced with `_import`.
  ** Added attributes to `_export` and `_import`.  For now, the only attributes
  are `cdecl` and `stdcall`.


== Version 20030716

Here are the changes from version 20030711 to 20030716.

== Summary

* Fixed several serious bugs with the 20030711 release.

== Details

* 2003-07-15
  ** Fixed bug that caused a segfault when attempting to create an
  array that was too large, e.g

      1 + Array.sub (Array.tabulate (valOf Int.maxInt, fn i =&gt; i), 0)

  ** mlton now checks the command line arguments following the file to compile
  that are passed to the linker to make sure they are reasonable.

* 2003-07-14
  ** Fixed packaging for Cygwin and Sparc to include `libgmp.a`.
  ** Eliminated bootstrap target.  The `Makefile` automatically determines
  whether to bootstrap or not.
  ** Fixed XML type checker bug that could cause error: `"empty tyvars in
  PolyVal dec"`.

* 2003-07-12
  ** Turned off `FORCE_GENERATIONAL` in gc.  It had been set, which caused the
  gc to always use generational collection.  This could seriously slow apps down
  that don't need it.


== Version 20030711

Here are the changes from version 20030312 to 20030711.

=== Summary

* Added support for Sparc/SunOS using the C code generator.
* Completed the basis library implementation.  At this point, the only missing
basis library function is `use`.
* Added `_export`, which allows one to call SML functions from C.
* Added weak pointers (via `MLton.Weak`) and finalization (via
`MLton.Finalizable`).
* Added new integer modules: `Int8`, `Int16`.
* Better profiling call graphs
* Fixed conversions between reals and their decimal representations to be
correct using the gdtoa library.

=== Details

* 2003-07-07
  ** Profiling improvements:
    *** Eliminated `mlton -profile-split`.  Added `mlprof -split`.  Now the
    profiling infrastructure keeps track of the splits and allows one to decide
    which splits to make (if any) when `mlprof` is run, which is much better
    than having to decide at compile time.
    *** Changed `mlprof -graph` to `mlprof -keep`, and changed the behavior so
    that `-keep` also controls which functions are displayed in the table.
    *** Eliminated `mlprof -ignore`: it's behavior is now subsumed by `-keep`,
    whose meaning has changed to be more like -ignore on nodes that are not
    kept.
  ** When calling `gcc` for linking, put `-link` args in same order as they
  appeared on the MLton command line (they used to be reversed).

* 2003-07-03
  ** Making `OS.Process.{atExit,exit}` conform to the basis library spec in that
  exceptions raised during cleaners are caught and ignored.  Also, calls to
  `exit` from cleaners cause the rest of cleaners to run.

* 2003-07-02
  ** Fixed bug with negative `IntInf` constants that could cause compile time
  error message: `"x86Translate.translateChunk ... strange Offset: base: ..."`
  ** Changed argument type of `MLton.IntInf.Small` from `word` to `int`.
  ** Added fix to profiling so that the `mlmon.out` file is written even when
  the program terminates due to running out of memory.

* 2003-06-25
  ** Added `{Int{8,16},Word8}{,Array,ArraySlice,Vector,VectorSlice,Array2}`
  structures.

* 2003-06-25
  ** Fixed bug in `IntInf.sign`, which returned the wrong value for zero.

* 2003-06-24
  ** Added `_export`, for calling from C to SML.

* 2003-06-18
  ** Regularization of options:
    *** `-diag` --&gt; `-diag-pass`
    *** `-drop-pass` takes a regexp

* 2003-06-06
  ** Fixed bug in `OS.IO.poll` that caused it to return the input event types
  polled for instead of what was actually available.

* 2003-06-04
  ** Fixed bug in KnownCase SSA optimization that could case incorrect results
  in compiled programs.

* 2003-06-03
  ** Fixed bug in SSA optimizer that could cause the error message:

      Type error: Type.equals
      {from = char vector, to = unit vector}
      Type error: analyze raised exception loopStatement: ...
      unhandled exception: TypeError

* 2003-06-02
  ** Fixed `Real.rem` to work correctly on `inf`-s and `nan`-s.
  ** Fixed bug in profiling that caused the function name to be omitted on
  functions defined by `val rec`.

* 2003-05-31
  ** `Fixed Real.{fmt,fromString,scan,toString}` to match the basis library
  spec.
  ** Added `IEEEReal.{fromString,scan}`.
  ** Added `Real.{from,to}Decimal`.

* 2003-05-25
  ** Added `Real.nextAfter`.
  ** Added `OS.Path.{from,to}UnixPath`, which are the identity function on Unix.

* 2003-05-20
  ** Added type `MLton.pointer`, the type of C pointers, for use with the FFI.

* 2003-05-18
  ** Fixed two bugs in type inference that could cause the compiler to raise the
  `TypeError` exception, along with a lot of XML IL.  The `type-check.sml`
  regression contains simple examples of what failed.
  ** Fixed a bug in the simplifier that could cause the message: `"shrinker
  raised Prim.apply raised assertion failure: SmallIntInf.fromWord"`.

* 2003-05-15
  ** Fixed bug in `Real.class` introduced on 04-28 that cause many regression
  failures with reals when using newer `gcc`-s.
  ** Replaced `MLton.Finalize` with `MLton.Finalizable`, which has a more robust
  approach to finalization.

* 2003-05-13
  ** Fixed bug in `MLton.FFI` on Cygwin that caused `Thread_returnToC` to be
  undefined.

* 2003-05-12
  ** Added support for finalization with `MLton.Finalize`.

* 2003-05-09
  ** Fixed a runtime system bug that could cause a segfault.  This bug would
  happen after a GC during heap resizing when copying a heap, if the heap was
  allocated at a very low (&lt;10M) address.  The bug actually showed up on a
  Cygwin system.

* 2003-05-08
  ** Fixed bug in `HashType` that raised `"Vector.forall2"` when the arity of a
  type constructor is changed by `SimplifyTypes`, but a newly constructed type
  has the same hash value.

* 2003-05-02
  ** Switched over to new layered IO implementation, which completes the
  implementation of the `BinIO` and `TextIO` modules.

* 2003-04-28
  ** Fixed bug that caused an assertion failure when generating a jump table for
  a case dispatch on a non-word sized index with non-zero lower bound on the
  range.

* 2003-04-24
  ** Added `-align {4|8}`, which controls alignment of objects.  With `-align
  8`, memory accesses to doubles are guaranteed to be aligned mod 8, and so
  don't need special routines to load or store.

* 2003-04-22
  ** Fixed bug that caused a total failure of time profiling with `-native
  false`.  The bug was introduced with the C codegen improvements that split the
  C into multiple files.  Now, the C codegen declares all profile labels used in
  each file so that they are global symbols.

* 2003-04-18
  ** Added `MLton.Weak`, which supports weak pointers.

* 2003-04-10
  ** Replaced the basis library's `MLton.hostType` with `MLton.Platform.arch`
  and `MLton.Platform.os`.

* 2003-04
  ** Added support for SPARC/SunOS using the C codegen.

* 2003-03-25
  ** Added `MLton.FFI`, which allows callbacks to SML from C.

* 2003-03-21
  ** Fixed `mlprof` so that the default `-graph arg` for data from
  `-profile-stack true` is `(thresh-stack x)`, not `(thresh x)`.


== Version 20030312

Here are the changes from version 20020923 to 20030312.

=== Summary

* Added source-level profiling of both time and allocation.
* Updated basis library to 2002 specification.  To obtain the old
library, compile with `-basis 1997`.
* Added many modules to basis library:
 ** `BinPrimIO`, `GenericSock`, `ImperativeIO`, `INetSock`, `NetHostDB`,
 `NetProtDB`, `NetServDB`, `Socket`, `StreamIO`, `TextPrimIO`, `UnixSock`.
* Completed implementation of `IntInf` and `OS.IO`.

=== Details

* 2003-02-23
  ** Replaced `-profile-combine` wih `-profile-split`.

* 2003-02-11
  ** Regularization of options:
    *** `-l` --&gt; `-link`
    *** `-L` --&gt; `-lib-search`
    *** `-o` --&gt; `-output`
    *** `-v` --&gt; `-verbose`

* 2003-02-10
  ** Added option to `mlton`: `-profile-combine {false|true}`

* 2003-02-09
  ** Added options to `mlprof`: `-graph-title`, `-gray`, `-ignore`, `-mlmon`,
  `-tolerant`.

* 2002-11 - 2003-01
  ** Added source-level allocation and time profiling.  This includes the new
  options to mlton: `-profile` and `-profile-stack`.

* 2002-12-28
  ** Added `NetHostDB`, `NetProtDB`, `NetServDB` structures.
  ** Added `Socket`, `GenericSock`, `INetSock`, `UnixSock` structures.

* 2002-12-19
  ** Fixed bug in signal check insertion that could cause some signals to be
  missed.  The fix was to add a signal check on entry to each function in
  addition to at each loop header.

* 2002-12-10
  ** Fixed bug in runtime that might cause the message `"Unable to set
  cardMapForMutator"`.

* 2002-11-23
  ** Added support for the latest Basis Library specification.
  ** Added option `-basis` to choose Basis Library version.  Currently available
    basis libraries are `2002`, `2002-strict`, `1997`, and `none`.
  ** Added `IntInf.{orb,xorb,andb,notb,&lt;&lt;,~&gt;&gt;}` values.
  ** Added `OS.IO.{poll_desc,poll_info}` types.
  ** Added `OS.IO.{pollDesc,pollToIODesc,infoToPollDesc,Poll}` values.
  ** Added `OS.IO.{pollIn,pollOut,pollPri,poll,isIn,isOut,isPri}` values.
  ** Added `BinPrimIO`, `TextPrimIO` structures.
  ** Added `StreamIO`, `ImperativeIO` functors.

* 2002-11-22
  ** Fixed bug that caused time profiling to fail (with a segfault) when
  resuming a saved world.

* 2002-11-07
  ** Fixed bug in `MLton.eq` that could arise when using `eq` on functions.

* 2002-11-05
  ** Improvements to polymorphic equality.  Equality on IntInfs, vectors, and
  dataypes all do an `eq` test first before a more expensive comparison.

* 2002-11-01
  ** Added allocation profiling.  Now, can compile with either `-profile alloc`
  or `-profile time`.  Renamed `MLton.Profile` as `MLton.ProfileTime`.  Added
  `MLton.ProfileAlloc`.  Cleaned up and changed most `mlprof` option names.

* 2002-10-31
  ** Eliminated `MLton.debug`.
  ** Fixed bug in the optimizer that affected `IntInf.fmt`.  The optimizer had
  been always using base 10, instead of the passed in radix.

* 2002-10-22
  ** Fixed `Real.toManExp` so that the mantissa is in [1, 2), not [0.5, 1).
  ** Added `Real.fromLargeInt`, `Real.toLargeInt`.
  ** Fixed `Real.split`, which would return an incorrect whole part due to the
  underlying primitive, `Real_modf`, being treated as functional instead of
  side-effecting.

* 2002-09-30
  ** Fixed `rpath` problem with packaging.  All executables in packages
  previously made had included a setting for `RPATH`.


== Version 20020923

Here are the changes from version 20020410 to 20020923.

=== Summary

* MLton now runs on FreeBSD.
* Major runtime system improvements.  The runtime now implements mark-compact
and generational collection, in addition to the copying collection that was
there before.  It automatically switches between the the collection strategies
to improve performance and to try to avoid paging.
* Performance when compiling `-exn-history true` has been improved.
* Added `IntInf.log2`, `MLton.GC.pack`, `MLton.GC.unpack`.
* Fixed bug in load world that could cause "sread failed" on Cygwin.
* Fixed optimizer bug that could cause `"no analyze var value property"`
message.

=== Details

* 2002-09
  ** Integrated Sam Rushing's changes to port MLton to FreeBSD.

* 2002-08-25
  ** Changed the implementation of exception history to be completely
  functional.  Now, the extra field in exceptions (when compiling `-exn-history
  true`) is a `string list` instead of a `string list ref`, and `raise` conses a
  new exception with a new element in the list instead of assigning to the list.
  This changes the semantics of exception history (for the better) on some
  programs. See `regression/exnHistory3.sml` for an example.  It also
  significantly improves performance when compiling `-exn-history true`.

* 2002-07 and 2002-08
  ** Added generational GC, and code to the runtime that automatically turns it
  on and off.

* 2002-08-20
  ** Fixed SSA optimizer bug that could cause the following error message: `"x_0
  has no analyze var value property"`

* 2002-07-28
  ** Added `MLton.GC.{pack,unpack}`.  `pack` shrinks the heap so that other
  processes can use the RAM, and its dual, `unpack`, resizes the heap to the
  desired size.

* 2002-06 and 2002-07
  ** Added mark compact GC.
  ** Changed array layout so that arrays have three, not two header words.  The
  new word is a counter word that preceeds the array length and header.
  ** Changed all header words to be indices into an array of object descriptors.

* 2002-06-27
  ** Added patches from Michael Neumann to port runtime to FreeBSD 4.5.

* 2002-06-05
  ** Output file and intermediate file are now saved in the current directory
  instead of in the directory containing the input file.

* 2002-05-31
  ** Fixed bug in overloading of `/` so that the following now type checks:

      fun f (x, y) = x + y / y

* 2002-04-26
  ** Added back `max-heap` runtime option.

* 2002-04-25
  ** Fixed load/save world so that they use binary mode.  This should fix the
  `sread failed` problem that Byron Hale saw on Cygwin that caused `mlton` to
  fail to start.
  ** Added `IntInf.log2`.
  ** Changed call to linker to use `libgmp.a` (if it exists) instead of
  `libgmp.so`.  This is because the linker adds a dependency to a shared library
  even if there are no references to it

* 2002-04-23
  ** Rewrote heap resizing code.  This fixed bug that was triggered with large
  heaps and could cause a spurious out of memory error.
  ** Removed GnuMP from MLton sources (again :-).


== Version 20020410

Here are the changes from version 20011006 to version 20020410.

=== Details

* 2002-03-28
  ** Added BinIO.

* 2002-03-27
  ** Regularization of options
    *** `-g` --&gt; `-degug {false|true}`
    *** `-h n` --&gt; `-fixed-heap n`
    *** `-p` --&gt; `-profile {false|true}`

* 2002-03-22
  ** Set up the stubs so that MLton can be compiled in the standard basis
  library, with no `MLton` structure.  Thus it is now easy to compile MLton with
  an older (or newer) version of itself that has a different `MLton` structure.

* 2002-03-17
  ** Added `MLton.Process.{spawn,spawne,spawnp}`, which use primitives when
  running on Cygwin and fork/exec when running on Linux.

* 2002-02 - 2002-03
  ** Added the ability to cross-compile to Cygwin/Windows.

* 2002-02-24
  ** Added GnuMP back for use with Cygwin.

* 2002-02-10
  ** Reworked object header words so that `Array.maxLen = valOf Int.maxInt`.
  Also fixed a long-standing minor bug in MLton, where `Array.array
  (Array.maxLen, ...)` would raise `Size` instead of attempting to allocate the
  array.  It was an off-by-one error in the meaning of `Array.maxLen`.

* 2002-02-08
  ** Modifications to runtime to behave better in situations where the amount of
  live data is a signifant fraction of the amount of RAM, based on code from
  PolySpace.  MLton executables by default can now use more than the available
  amount of RAM.  Executables will still respect the `max-heap` runtime arg if
  it is set.

* 2002-02-04
  ** Improvements to runtime so that it fails to get space, it attempts to get
  less space instead of failing.  Based on PolySpace's modifications.
  ** Added `MLton.eq`.

* 2002-02-03
  ** Added `MLton.IntInf.gcd`.
  ** Removed GnuMP from MLton sources.  We now link with `/usr/lib/libgmp.a`.
  ** Added `TextIO.getPosOut`.
  ** Renamed type `MLton.Itimer.which` to `MLton.Itimer.t` and
  `MLton.Itimer.whichSignal` to `MLton.Itimer.signal`.
  ** Added `-coalesce` flag, for use with the C backend.

* 2002-01-26
  ** Added `-show-basis-used`, which prints out the parts of the basis library
  that the input program uses.
  ** Changed several other flags (`-print-at-fun-entry`, `-show-basis`,
  `-static`) to follow the `{false|true}` convention.

* 2002-01-22
  ** Improved `MLton.profile` so that multiple profile arrays can exist
  simultaneously and so that the current one being used can be set from the SML
  side.

* 2002-01-18
  ** The Machine IL has been replaced with an RSSA (representation explicit SSA)
  IL and an improved Machine IL.

* 2002-01-16
  ** Added KnownCase SSA optimization

* 2002-01-14
  ** Added rudimentary profiling control from with a MLton compile program via
  the `MLton.Profile` structure.

* 2002-01-09
  ** Fixed bug in match compiler that caused case expressions on datatypes with
  redundant cases to be compiled incorrectly.

* 2002-01-08
  ** Added redundant tuple construction elimination to SSA shrinker.
  ** Improved Flatten SSA optimization.

* 2001-12-06
  ** Changed the interface for `MLton.Signal`.  There is no longer a separate
  `Handler` substructure.  This was done so that programs that just use
  `default` and `ignore` signal handlers don't bring in the entire thread
  mechanism.

* 2001-12-05
  ** Added LocalRef elimination SSA optimization.

* 2001-11-19
  ** The CPS IL has been replaced with an SSA (static-single assignment) IL.
  All of the optimizations have been ported from CPS to SSA.

* 2001-10-24
  ** Fixed bug in `Thread_atomicEnd` -- `limit` was mistakenly set to `base`
  instead of to 0.  This caused assertion failures when for executables compiled
  `-g` because `GC_enter` didn't reset `limit`.
  ** Fixed bug in register allocation of byte registers.

* 2001-10-23
  ** Added `-D` option to `cmcat` for preprocessor defines.  Thanks to Anoq for
  sending the code.
  ** Changed limit check insertion so that limit checks are only coalesced
  within a single basic block -- not across blocks.  This slows many benchmarks
  down, but is needed to fix a bug in the way that limit checks were coalesced
  across blocks.  Hopefully we will figure out a better fix soon.

* 2001-10-18
  ** Fixed type inference of flexrecord so that it now follows the Definition.
  Many programs containing flexrecords were incorrectly rejected.  Added many
  new tests to regression/flexrecord.sml.
  ** Changed the behavior of `-keep dot` combined with `-keep pass` for SSA
  passes.  Dot files are now saved for the program before and after, instead of
  just after.

* 2001-10-11
  ** Fixed a bug in the type inference that caused type variables to be
  mistakenly generalized.  The bug was exposed in Norman Ramsey's `sled.sml`.
  Added a test to `regression/flexrecord.sml` to catch the problem.


== Version 20011006

Here are the changes from version 20010806 to version 20011006.

=== Summary

* Added `MLton.Exn.history`, which is similar to `SMLofNJ.exnHistory`.
* Support for `#line` directives of the form `(*#line line.col "file"*)`.
* Performance improvements in native codegenerator.
* Bug fixes in front-end, optimizer, register allocator,
`Real.{maxFinite,minPos,toManExp}`, and in heap save and restore.

=== Details

* 2001-10-05
  ** Fixed a bug in polymorphic layered patterns, like

      val 'a a as b = []

  These would always fail due to the variable `a` not being handled correctly.
  ** Fixed the syntax of `val rec` so that a pattern is allowed on the left-hand
  side of the `=`.  Thus, we used to reject, but now accept, the following.

      val rec a as b as c = fn _ =&gt; ()
      val rec a : unit -&gt; unit : unit -&gt; unit = fn () =&gt; ()

  Thanks again to Andreas Rossberg's test files.  This is now tested for in
  `valrec.sml`.
  ** Fixed dynamic semantics of `val rec` so that if `val rec` is used to
  override constructor status, then at run time, the `Bind` exception is raised
  as per rule 126 of the Definition.  So, for example, the following program
  type checks and compiles, but raises `Bind` at run time.

      val rec NONE = fn () =&gt; ()
      val _ = NONE ()

  Again, this is checked in `valrec.sml`.
  ** Added `\r\n` to ml.lex so that Windows style newlines are acceptable in
  input files.

* 2001-10-04
  ** Fixed bug in the implementation of `open` declarations, which in the case
  of `open A B` had opened `A` and then looked up `B` in the resulting
  environment.  The correct behaviour (see rule 22 of the Definition) is to
  lookup each _longstrid_ in the current environment, and then open them all in
  sequence.  This is now checked for in the `open.sml` regression test.  Thanks
  to Andreas Rossberg for pointing this bug out.
  ** Fixed bug that caused tyvars of length 1 (i.e. `'`) to be rejected.  This
  is now checked in the `id.sml` regression test.  Again, thanks to Andreas
  Rossberg for the test.

* 2001-10-02
  ** Fixed bugs in `Real.toManExp` (which always returned the wrong result
  because the call to `frexp` was not treated as side-effecting by the
  optimizer) and in `Real.minPos`, which was zero because of a mistake with
  extra precision bits.

* 2001-10-01
  ** Added `MLton.Exn.history`.
  ** Fixed register allocation bug with `fucom` instruction.  Was allowing
  `fucomp` when the first source was not removable.
  ** Changed `Real.isFinite` to use the C `math.h` `finite` function.  This
  fixed the nontermination bug which occurred in any program that used
  `Real.maxFinite`.

* 2001-09-22
  ** Bug fixes found from Ramsey's `lrtl` in `contify.fun` and
  `unused-args.fun`, both of which caused compile-time exceptions to be raised.

* 2001-09-21
  ** Fixed `MLton.World.{load,save}` so that the saved world does not store the
  max heap size.  Instead, the max heap size is computed upon load world in
  exactly the same way as at program startup.  This fixes a long-standing (but
  only recently noticed) problem in which `mlton` (which uses a saved world)
  would attempt to use as much memory as was on the machine used to build
  `world.mlton`.

* 2001-08-29
  ** Overlow checking is now on by default in the C backend.  This is a huge
  performance hit, but who cares, since we never use the C backend except for
  testing anyways.

* 2001-08-22
  ** Added support for #line directives of the form

      (*#line line.col "file"*)

  These directives only affect error messages produced by the parser and
  elaborator.

* 2001-08-17
  ** Fixed bug in RemoveUnused optimzation that caused the following program to
  fail to compile.

      fun f l = case l of [] =&gt; f l | _ :: l =&gt; f l
      val _ = f [13]

* 2001-08-14
  ** New x86-codegen infrastructure.
    *** support for tracking liveness of stack slots and carrying them in
    registers across basic blocks
    *** more specific `Entry` and `Transfer` datatypes to make calling convention
    distinctions more explicit
    *** new heuristic for carrying values in registers across basic blocks (look
    Ma, no Overflows!)
    *** new "predict" model for generating register allocation hints
    *** additional bug fixes

* 2001-08-07
  ** `MLton.Socket.shutdownWrite` flushes the outstream.


== Version 20010806

Here are the changes from version 20010706 to version 20010806.

=== Summary

* `Word.andb (w, 0xFF)` now works correctly
* `MLton.Rusage.rusage` has a patch to work around a linux kernel bug
* Programs of the form `_exp_ ; _program_` are now accepted
* Added the `MLton.Rlimit` structure
* Added the `-keep dot` flag, which produces call graphs, intraprocedural
control-flow graphs, and dominator trees

=== Details

* 2001-08-06
  ** Added simple CommonBlock elimination CPS optimization.

* 2001-08-02
  ** Took out `-keep il`.

* 2001-07-31
  ** Performance improvements to `TextIO.{input, output, output1}`.

* 2001-07-25
  ** Added RedundantTest elimination CPS optimization.

* 2001-07-21
  ** Added CommonSubexp elimination CPS optimization.

* 2001-07-20
  ** Bug fix to x86 codegen.  The `commuteBinALMD` peephole optimization would
  rewrite `mov 2,Y; add Y,Y` as `mov Y,Y; add 2,Y`.  Now the appropriate
  interference checks are made.
  ** Added intraprocedural unused argument removal.
  ** Added intraprocedural flattener.  This avoids some stupid tuple allocations
  in loops.  Decent speedup on a few benchmarks (`count-graphs`, `psdes-random`,
  `wc-scanStream`) and no noticeable slowdowns.
  ** Added `-keep dot` flag.

* 2001-07-17
  ** Modified grammar to properly handle `val rec`.  There were several problems.
    *** MLton had accepted `val rec 'a ...` instead of `val 'a rec ...`
    *** MLton had not accepted `val x = 13 and rec f = fn () =&gt; ()`
    *** MLton had not accepted `val rec rec f = fn () =&gt; ()`
    *** MLton had not accepted `val rec f = fn () =&gt; () and rec g = fn () =&gt; ()`

* 2001-07-16
  ** Workaround for Linux kernel bug that can cause `getrusage` to return a wrong
  system time value (low by one second).  See `fixedGetrusage` in `gc.c`.
  ** Bug fix to x86 codegen.  The register allocator could get confused when
  doing comparisons of floating point numbers and use the wrong operand.  The
  bug seems to have never been detected because it only happens when both of the
  operands are already on the floating point stack, which is rare, since one is
  almost always in memory since we don't carry floating point values in the
  stack across basic blocks.
  ** Added production to the grammar on page 58 of the Definition that had been
  missing from MLton since day one.

      program ::= exp ; &lt;program&gt;

  Also updated docs to reflect change.
  ** Modified grammar to accept the empty program.
  ** Added `-type-check` expert flag to turn on type checking in ILs.

* 2001-07-15
  ** Bug fix to the algebraic simplifier.  It had been rewriting
  `Word32.andb (w, 0wxFF)` to `w` instead of
  `Word32.andb (w, 0wxFFFFFFFF)` to `w`.

* 2001-07-13
  ** Improved CPS shrinker so that `if`-tests where the `then` and `else` branch
  jump to the same label is turned into a direct jump.
  ** Improved CPS shrinker (`Prim.apply`) to handle constructors
    *** `A = A` --&gt; `true`
    *** `A = B` --&gt; `false`
    *** `A x` = `B y` --&gt; `false`
  ** Rewrote a lot of loops in the basis library to use inequalities instead of
  equality for the loop termination test so that the (forthcoming) overflow
  detection elimination will work on the loop index variable.

* 2001-07-11
  ** Fixed minor bugs in `Array2.{array,tabulate}`, `Substring.{slice}` that
  caused the `Overflow` exception to be raised instead of `Size` or `Subscript`
  ** Fixed bug in `Pack32Big.update` that caused the wrong location to be updated.
  ** Fixed several bugs in `Pack32{Big,Little}.{subArr,subVec,update}` that
  caused `Overflow` to be raised instead of `Subscript`.  Also, improved the
  implementation so that bounds checking only occurs once per call (instead of
  four times, which was sometimes happening.
  ** Fixed bugs in `Time.{toMilliseconds,toMicroseconds}` that could cause a
  spurious `Overflow` exception.
  ** Fixed bugs in `Time.{fromMilliseconds,fromMicroseconds}` that could cause a
  spurious `Time` exception.
  ** Improved `Pack32.sub*` by reordering the `orb`-s.
  ** Improved `{Int,IntInf}.mod` to increase chances of constant folding.
  ** Switched many uses of `+`, `-`, `*` in basis library to the non-overflow
  checked versions.  Modules changed were: `Array`, `Array2`, `Byte`, `Char`,
  `Int`, `IntInf`, `List`, `Pack32{Big,Little}`, `Util`, `String`, `StringCvt`,
  `Substring`, `TextIO`, `Time`, `Vector`.
  ** Added regression tests for `Array2`, `Int` (overflow checking), `Pack32`,
  `Substring`, `Time`.
  ** Changed CPS output so that it includes a dot graph for each CPS function.

* 2001-07-09
  ** Change `OS.Process.exit` so that it raises an exception if the exit status
  is not in [0, 256).
  ** Added `MLton.Rlimit` to provide access to `getrlimit` and `setrlimit`.


== Version 20010706

Here are the changes from the 20000906 version to the 20010706 version.

=== Summary

* Native X86 code generator (instead of using `gcc`)
* Significantly improved compile times
* Significantly improved run times for generated executables
* Many bug fixes
* Correct raising of the `Overflow` exception for integer arithmetic
* New modules in the `MLton` structure

=== Details

* 2001-07-06
  ** GC mods from Henry.  Mostly adding `inline` declarations.

* 2001-07-05
  ** Fixed several runtime bugs involving threads, critical sections, and
  signals.

* 2001-06-29
  ** Fixed performance bug in `cps/two-point-lattice.fun` that caused quadratic
  behavior.  This affects the raise-to-jump and useless analayses.  In
  particular, the useless analysis was blowing up when compiling `fxp`.

* 2001-06-27
  ** Henry improved `wordAlign` -- this sped up GC by 27% (during a self
  compile).

* 2001-06-20
  ** Moved `MLton.random` to `MLton.Random.rand` and added other stuff to
  `MLton.Random`
  ** Added `MLton.TextIO.mkstemp`.
  ** Made `Int.{div,quot}` respect the `-detect-overflow` switch.

* 2001-06-20
  ** Added `MLton.Syslog`.

* 2001-06-07
  ** Fixed bug in `MLton.Socket.accept` that was in the runtime implementation
  `Socket_accept`.  It did a `setsockopt SO_REUSEADDR` after the `accept`.  It
  should have been after the call to `socket` in `Socket_listen`.  Thanks to
  Doug Bagley for the fix.

* 2001-05-30
  ** Fixed bug in remove-unused that caused polymorphic equality to return
  `true` sometimes when constructors were never used in a pattern match.  For
  example, the following (in which `A` and `B` are not used as patterns):

      datatype t = A | B
      datatype u = C of t
      val _ = if C A = C B then raise Fail "bug" else ()

* 2001-03-27
  ** Fixed bug that caused all of the following to fail:
  `{LargeWord,Word,SysWord}.{toLargeInt,toLargeIntX,fromLargeInt}` The problem
  was the basis library file `integer/patch.sml` which fixed `Word32` but not
  the other structures that are the same.

* 2001-02-12
  ** Fixed bug in match compiler that caused it to spend a lot of extra time in
  deep patterns.  It still could be exponential however.  Hopefully this will
  get fixed in the release after next.  This bug could cause very slow compile
  times in some cases.  Anyways, this fix cut the `finish infer` time of a self
  compile down from 22 to under 4 seconds.  I.E. most of the time used to be
  spent due to this bug.

* 2001-02-06
  ** Fixed bug in frontend that caused the wrong file and line number to be
  reported with errors in functor bodys.

* 2001-01-03 - 2000-02-05
  ** Changes to CoreML, XML, SXML, and CPS ILs to replace lists by vectors in
  order to decrease space usage.

* 2001-01-16
  ** Fixed a bug in constant propagation where the length of vectors was not
  propagated properly.

* 2000-12-11 - 2001-01-03
  ** Major rewrite of elaborator to use a single hash table for each namespace
  instead of a hash table for every environment.

* 2000-12-20
  ** Fixed some bugs in the SML/NJ compatibility library,
  `src/lib/mlton-subs-in-smlnj`.

* 2000-12-08
  ** More careful removal of tracing code when compiling `MLton_debug=0`.  This
  cut down self compile data size by 100k and compile time by a few seconds.
  ** Added built in character and word cases propagated throughout all ILs.

* 2000-12-06
  ** Added max stack size information to `gc-summary`.

* 2000-12-05
  ** Added `src/benchmark`, which contains an SML program that benchmarks all of
  the SML compilers I have my hands on.  The script has lots of hardwired paths
  for now.

* 2000-12-04
  ** Fixed bug in `Posix.ProcEnv.environ,` which did not work correctly in a
  saved world (the original `environ` was saved).  In fact, it did not work at
  all because the ML primitive expected a constant and the C was a nullary
  function. This caused a segfault with any program using
  `Posix.ProcEnv.environ`.
  ** `Added MLton.ProcEnv.setenv`, since there doesn't seem to be any `setenv`
  in the basis library.

* 2000-11-29
  ** Changed backend so that it should no longer generate machine programs with
  `void` operands.
  ** Added `-detect-overflow` and `-safe` flags.

* 2000-11-27 - 2000-11-28
  ** Changes in many places to use `List.revMap` instead of `List.map` to cut
  down on allocation.

* 2000-11-21
  ** Added `MLton.Word.~` and `MLton.Word8.~` to the `MLton` structure.

* 2000-11-20
  ** Fixed a bug in the CPS shrinker that could cause a compile-time failure.
  It was maintaining occurrence counts incorrectly.

* 2000-11-15
  ** Fixed a (performance) bug in constant propagation that caused the hashing
  to be bad.
  ** Improved translation to XML so that the match compiler isn't called on
  tuple or if expressions.  This should speed up the translation and make the
  output smaller.
  ** Fixed a bug in the match compiler that caused it to not generate integer
  case statements.  This should speed up the mlyacc benchmark and the MLton
  front end.

* 2000-11-09
  ** Added `IntInf_equal` and `IntInf_compare` primitives.
  ** Took out the automatic `-keep c` when compiling `-g`.

* 2000-11-08
  ** Added a whole bunch of algebraic laws to the CPS shrinker, including some
  specifically targeted to `IntInf` primitives.

* 2000-11-03
  ** Improved implementation of properties so that sets don't allocate.
  ** Improved implementation of type homomorphism in type inference.  What was
  there before appears to have been a bug -- it didn't use the property on
  types.

* 2000-11-02
  ** Fixed timers used with `-v` option to use user + sys time.

* 2000-10-27
  ** Split the runtime basis library C files into many separate files so that
  only the needed code would be included by the linker.
  ** Fixed several bugs in the front end grammar and elaborator that caused type
  specifications to be handled incorrectly.  The following three programs used
  to be handled incorrectly, but are now handled correctly.

      signature S = sig type t and u = int end (* reject *)
      signature S = sig type t = int and u = t end (* accept *)
      signature S = sig eqtype t and u = int end (* reject *)

* 2000-10-25
  ** Changes to `main.sml` to run complete compiles with `-native` switch.

* 2000-10-24
  ** Removed defunctorizer.

* 2000-10-20
  ** Fixed bug in `cps-tree.fun` with `PrimExp.maySideEffect`.  This bug could
  cause `"no operand"` failures in the backend.
  ** Fixed bug in the runtime implementation of `MLton.size`.  The size for
  stack objects was using the `used` instead of `reserved`, and so was too low.

* 2000-10-19
  ** Replaced automatically generated dependencies in `src/runtime/Makefile`
  with hand generated ones.  Took out `make depend` from `src/Makefile`.  `make
  depend` was behaving really badly on RHAT 7.0.
  ** Tweaked compiler to shorten width of C output lines to work around bug in
  RHAT 7.0 `cpp` which silently truncates (very) long lines.
  ** Fixed bug in grammar that didn't allow `op` to occur in datatype and
  exception bindings, causing the following to fail

      datatype t = op T
      exception op E = op Fail

  ** Improved error messages in CM processor.  Fixed bug in CM Alias handling.

* 2000-10-18
  ** Fixed two bugs in the gc that did comparisons with `(s-&gt;limit -
  s-&gt;frontier)`, which of course doesn't work if `frontier` is beyond `limit`,
  since these are unsigned.  This could have caused segfaults, except that the
  mutator checks the `frontier` upon return from the GC.

* 2000-10-17
  ** Fixed bug in backend in the calculation of `maxFrameSize`.  It could be
  wrong (low) in some situations.
  ** Improved CPS inliner's estimate of function sizes.  The size of a function
  now takes into account other inlined functions that the function calls.  This
  also changed the meaning of the size argument to the `-inline` switch.  It now
  corresponds (roughly) to the product of the size of the function and the
  number of calls.  In general, it should be larger than before.

* 2000-10-13
  ** Made some calls to `Array.sub` unsafe in the implementation of `Array2`.
  ** Integrated Matthew's new x86 backend with floating point support.

* 2000-10-09
  ** Fixed CM file processor so that MLton works if it is run from a different
  directory than the main CM file.

* 2000-10-04
  ** Changed LimitCheck so it loops on the `frontier &gt; limit` check.  This fixed
  a potential bug in threads caused when there is enough space available for a
  thread, `t`, before switching to another thread but not enough space when it
  resumes.  This could have caused a segfault.

* 2000-10-03
  ** More rewrites of `TextIO.StreamIO` to improve speed.
  ** Changed `TextIO` so that only `TextIO.stdErr` is unbuffered.
  ** Changed `TextIO` so that FIFOs and sockets are buffered.

* 2000-10-02
  ** Combined remove-unused-constructors, remove-unused-functions, and
  remove-unused-globals into a single pass that runs to fixed-point and produces
  results at least as good as running the previous three in (any) sequence.

* 2000-09-29
  ** Added `GC_FIRST_CHECK`, which does a gc at each limit check the first time
  it reached.
  ** Reimplemented `TextIO.StreamIO` (from 2000-09-12) to use lists of strings
  instead of lists of characters so that the per char space overhead is small.

* 2000-09-21
  ** Fixed bug in profiling labels in C code.  The label was always the basic
  block label instead of the cps function label.
  ** Added `-b` switch to `mlprof` to gather data at the basic block level.
  ** Improved performance of `TextIO.input1` by about 3X.

* 2000-09-15 - 2000-09-19
  ** Added overflow exceptions to CPS and Machine ILs.

* 2000-09-12
  ** Fixed `TextIO.scanStream`.  It was very broken.
  ** Added `TextIO.{getInstream,mkInstream,setInstream}` and
  `TextIO.StreamIO.{canInput,closeIn,endOfStream,input1,input,inputAll,inputLine,inputN}`.

* 2000-09-11
  ** Fixed `Real_qequal` in `mlton-lib.h`.  It was missing a paren that caused
  code using it to not even compile.  It was also semantically incorrect.
  ** Noted that `Real_{equal,lt,le,gt,ge}` may not follow basis library spec,
  since ANSI does not require IEEE compliance, and hence these could return
  wrong results when nans are involved.


== Version 20000906

Here are the changes from the 20000712 version to the 20000906 version.

=== Summary

* Version 20000906 is mostly a bugfix release over 20000712.  The other major
changes are that `mllex` and `mlyacc` are now included and that `mlton` can now
process a limited subset of CM files as input.

=== Details

* 2000-09-06
  ** Fixed `Socket_listen` in `mlton-lib.c` so that it closes the socket if the
  `bind`, `listen`, or `getsockname` fails.  This could have caused a file
  descriptor leak.

* 2000-09-05
  ** Added `-static` commandline switch.
  ** Changed default max heap size to .85 RAM from .95 RAM.
  ** Added `PackRealLittle` structure to basis library.

* 2000-08-25
  ** Added cases on integers to ILs (instead of using sequences of tests) so
  that backend can emit more efficient test (jump table, binary tree, ...).

* 2000-08-24
  ** Fixed bug in `gc.c`.  `dfsInitializeStack` would `smummap` a `NULL` pointer
  whenver `toSpace` was `NULL`.  This could cause `MLton.size` to segfault.
  ** Fixed bug in `Popt` that caused `-k` to fail with no keeps.

* 2000-08-22 - 2000-08-23
  ** Ported `mllex` and `mlyacc` from SML/NJ

* 2000-08-20 - 2000-08-21
  ** Added ability to use a `.cm` file as input to MLton.

* 2000-08-16
  ** Ported `mlprof` to SML.
  ** Fixed bug in `library/basic/assert.sml` that caused asserts to be run even
  when `MLton.debug = false`.

* 2000-08-15
  ** Fixed bug in backend -- computation of `maxFrameSize` was wrong.  It didn't
  count slots in frames that didn't make nontail calls.  This could lead to the
  stack being overwritten because a stack limit check didn't guarantee enough
  space, and lead to a segfault.
  ** Fixed bug in `gc.c` `newThreadOfSize`.  If the thread allocation caused a
  gc, then the stack wasn't forwarded, leading to a segfault.  The solution was
  to ensure enough memory all at once, and then fill in both objects.

* 2000-08-14
  ** Changed limit checks so that checks &lt; 512 bytes are replaced by a check for
  0 bytes.  The runtime also moves the limit down by 512.  This is done so that
  the common case, a small limit check, has less code and is faster.
  ** Fixed bug in `cps/cps-tree.fun`. `Program.hasPrim` returned `true` for any
  program that had *any* primapp, not just programs satisfying the predicate.
  This caused `cps/once.fun` to be overly conservative, since it thought that
  every program used continuations.

* 2000-08-10
  ** Fixed bug in CPS typechecker.  It didn't enforce that handlers should be
  defined before any reference to them -- including implicit references in
  `HandlerPops`.  This caused an evil bug in the liveness analysis where a
  variable that was only live in the handler was missed in a continuation
  because the liveness for the handler wasn't computed yet.
  ** Limited the size for moving up limit checks for arrays whose size is known
  at compile time to avoid huge limit checks getting moved into loops.
  ** added `-indent`, `-kp`, `-show-types` switches.
  ** Put optimization in CPS IL suggested by Neal Glew.  It determines for each
  toplevel function if it can raise an exception to its caller.  Also, it
  removes `HanderPush` and `HandlerPop` for handlers that are not on top of the
  stack for any nontail call.

* 2000-08-08
  ** Changed register allocator so that continuation formals can be allocated in
  pseudo registers -- they aren't necessarily forced to the stack.

* 2000-08-03
  ** Fixed bug in constant folding.  `Word8.&gt;&gt;` had been used to implement
  `Word8.~&gt;&gt;`.
  ** Fixed bug in allocate registers that was not forcing the size argument to
  `Primitive.Array.array` to be a stack slot.  This could cause problems if
  there was a thread switch in the limit check, since upon return the size
  pseudo register would have a bogus value.

* 2000-08-01
  ** Turned back on XML simplification after monomorphisation.

* 2000-07-31
  ** Fixed bug in `MLton.Itimer.set` that caused the time to be doubled.
  ** Fixed bug in `MLton.Thread` that made it look like asynchronous exceptions
  were allowed by `throw`-ing an exception raising thunk to an interrupted
  thread obtained via a signal handler.  Attempting asynchronous exceptions will
  now cause process death, with a helpful error message.

* 2000-07-27
  ** Updated docs to include `structure World: MLTON_WORLD` in `MLton`
  structure.
  ** Added toplevel signatures `MLTON_{CONT, ..., WORLD}` to basis library.
  ** Fixed broken link in docs to CM in `cmcat` section.

* 2000-07-26
  ** Eliminated `GC_switchToThread` and `Thread_switchTo1`, since the inlined
  version `Thread_switchTo` is all that's needed, and Matt's X86 backend now
  handles it.
  ** Added `MLton.Signal.vtalrm`, needed for `Itimer.Set{which =
  Itimer.Virtual, ...}`.

* 2000-07-25
  ** Added `MLton.Socket.shutdownWrite`.

* 2000-07-21
  ** Updated `mlton-lib.c` `MLton_bug` with new email (MLton@sourcelight.com).

* 2000-07-19
  ** Fixed `Posix.Process.kill` to check for errors.

* 2000-07-18
  ** Fixed the following `Posix.ProcEnv` functions to check for errors:
  `setgid`, `setpgid`, `setsid`, `setuid`.
  ** Fixed `doc/examples/callcc.sml`.


== Version 20000712

Here are the changes from the 1999-07-12 to the 20000712 version.

=== Details

* 2000-06-10 - 2000-07-12
  ** Too many changes to count: bug fixes, new basis library modules, optimizer
  improvements.

* 2000-06-30
  ** Fixed bug in monomorphiser that caused programs with non-value carrying
  exception declarations in polymorphic functions to have a compile-time error
  because of a duplicate label.  The problem was that the exception constructor
  wasn't duplicated.

* 2000-05-22 - 2000-06-10
  ** Finished the changes for the new CPS IL.

* 2000-01-01
  ** Fixed some errors in the basis library:
    *** `Real.copySign`
    *** `Posix.FileSys.fpathconf`
    *** `Posix.IO.{lseek, getlk, setlk, setlkw}`
    *** `Posix.ProcEnv.setpgid`
    *** `Posix.TTY.getattr`
    *** `System.FileSys.realPath`

* 1999-12-22
  ** Fixed bug in `src/closure-convert/abstract-value.fun` that caused a
  compiler failure whenever a program had a vector where the element type
  contained an `-&gt;`.

* 1999-12-10
  ** Changed dead code elimination in `core-ml/dead-code.fun` so that wildcard
  declarations (`val _ = ...`) in the basis are kept.  Changed places in the
  basis library to take advantage of this.
  ** Added `setTopLevelHander` primitive so that the basis library code can
  define the toplevel handler.
  ** Changed `basis-library/misc/suffix.sml` to call `OS.Process.exit`.  Took
  out `Halt` transfer from CPS, since the program never should reach it.
  ** Cleaned up `basis-library/system/{process.sml, unix.sml}` to use the new
  signal handling stuff.

* 1999-11-28 - 1999-12-20
  ** Added support for threads and cleaned up signal handling.  This involved a
  number of changes:
    *** The stack is now allocated as just another kind of heap object.
    *** Limit checks are inserted at all loop headers, whether or not there is
    any allocation.  This is to ensure that the signal handler always has a
    chance to get called.
    *** The register allocator puts more variables in stack slots.  The new rule
    is that a variable goes in a stack slot if it is ever live across a nontail
    call, in a handler, or (this is the new part) across a limit check.
    *** Arguments are passed on the stack, with the convention determined by
    argument types.
    *** The "locals" array of pointers that was copied to/from for GC is now
    gone, because no registers (in particular no pointer valued registers) can
    be live at a limit check point.

* 1999-11-21
  ** Runtime system
    *** Fixed a bug introduced by the signal code (presumably on 1999-08-09)
    that caused a gc to *not* be performed when doing a save world.  This caused
    the heaps created by save world to be the same size as the heap -- not the
    live data.  This was quite bad.
    *** Cleaned up the `Makefile`.  Add make depend.
    *** Added max gc pause to `gc-summary` info.
    *** Move heap translation variables that had been file statics into the
    `GC_state`.
  ** Made `structure Position` available at toplevel.
  ** Basis Library
    *** Added `MLton.loadWorld`
  ** Added `Primitive.usesCallcc`
  ** Added `Primitive.safe`
  ** Removed special size functions from `cps/save-world` -- they are no longer
  necessary since size doesn't do a gc.
  ** Fixed another (sigh) bug in `cps/simplify-types.fun` that could cause it to
  not terminate.

* 1999-11-16
  ** Cleaned up `backend/machine.fun` a bit so that it spits out macros for
  allocation of objects and bumping of frontier.  Added macros `MLTON_object`
  and `MLTON_incFrontier` to `include/mlton-lib.h`.
  ** Fixed a bug in `backend/limit-check.fun` that caused loops to not be
  detected if they were only reached by a case branch.  This could cause there
  to be loop that allocates with no limit check.  Needless to say, this could
  cause a segfault if the loop ran for long enough.

* 1999-10-18
  ** Added basis library function `Array2.copy`.

* 1999-08-15
  ** Turned off globalization of ref cells (`closure-convert/globalize.fun`)
  because it interacts badly with serialization.

* 1999-08-13
  ** Fixed bug in `mlton-lib.h` in `MLTON_allocArrayNoPointers` that was
  triggered when `bytesPerElt == 0`.  The problem was that it wasn't reserving
  space for the forwarding pointer.  This could cause a segfault.

* 1999-08-08 and 1999-08-09
  ** Added support for signal handling.

* 1999-08-07
  ** Fixed bugs in `Array.tabulate` (and other `tabulate` variants) caused if
  the function argument used `callcc`.

* 1999-08-01
  ** Added serialization, which was mostly code in `src/runtime/gc.c`. +
  `GC_serialize` converts an object to a `Word8Vector.vector`. +
  `GC_deserialize` undoes the conversion. + (de)Serialization should work for
  all objects except for functions, because I haven't yet added the support in
  the flow analysis.

* 1999-07-31
  ** Cleaned up the GC.  Changed headers, by stealing a bit from the number of
  non pointers and making it a mark bit (used in `GC_size`).
  ** Rewrote `GC_size` so that it runs in time proportional to the number of
  pointers in the object.  It does a depth-first-search now, using toSpace to
  hold the stack.

* 1999-07-30
  ** Fixed bug in `SUBSTRING`.  `getc` had the wrong type.  This bug wasn't
  noticed because MLton doesn't do enough type checking.
  ** Fixed bug (segfault) caused when a GC immediately followed a throw.

* 1999-07-29
  ** Fixed bug in `Date.fmt` (`basis-library/system/date.sml`).  It was not
  setting `Tm.buf`, and hence the time was always 0 unless there had been a
  previous call to `setTmBuf`.

* 1999-07-28
  ** Fixed bugs in `Posix.IO.FLock.{getlk,setlk,setlkw}`, which would cause
  compilation to fail because `FLock.toInt` was defined as the C `castInt`,
  which no longer exists.  Instead, expand `FLock.toInt` to
  `MLTON_pointerToInt`, which was added to `include/mlton-lib.h`.
  ** Changed `Posix.Primitive.Flock` to `Posix.Primitive.FLock`.
  ** Added `MLTON_chown`, `MLTON_ftruncate` to `include/mlton-posix.h`.  They
  were missing.  This would cause compilation of any program using
  `Posix.FileSys.{chown,ftruncate}` to fail.  Also made it so all of the
  primitives in `basis-library/posix/primitive.sml` use `MLTON_` versions of
  functions, even if a wrapper is unnecessary.

* 1999-07-25
  ** Added some other missing signature definitions to toplevel.

* 1999-07-24
  ** Added missing `OS_*` signature definitions to
  `basis-library/top-level/top-level.sml`.

* 1999-07-19
  ** Fixed bug in `basis-library/arrays-and-vectors/mono-array.sml`.  Used `:&gt;`
  instead of `:` so that the monomorphic array types are abstract.


== Version 19990712

Here are the changes from the 1999-03-19 version to the 1999-07-12 version.

=== Details

* 1999-07-12
  ** Changed `src/backend/machine.fun` so that the 'pointer locals' array is
  only as large as neccessary in order to copy all pointer-valued locals, not as
  large as the number of pointer-valued locals.

* 1999-07-11
  ** Rewrote `src/backend/allocate-registers.fun` so that it does a better job
  of sharing "registers" (i.e. C local variables) and stack slots.  This should
  cut down on the amount of copying that has to happen before and after a gc.
  It should also cut down on the size of stack slots.

* 1999-07-10
  ** Fixed a bug in `src/backend/parallel-move.fun` that should have been
  triggered on most any parallel move.  I guess parallel moves almost never
  happened due to the old register allocation strategy -- but, with the new one
  (see note for 1999-07-12) parallel moves will be frequent.

* 1999-06-27
  ** Fixed `src/main.sml` so that when compiling `-p`, the `.c` file is compiled
  `-g` and the `.o` is linked `-p`.
  ** In `bakend/machine.fun`, added profiling comments before chunkswitches and
  put in an optimization to avoid printing repeated profiling comments.  Also,
  profiling comments are only output when compiling `-p`.

* 1999-06-17
  ** Changed `-i` to `-inline`, `-f` to `-flatten`, `-np` to `-no-polyvariance`,
  `-u` to `-unsafe`.
  ** Added `-i`, `-I`, `-l`, `-L` flags for includes and libraries.
  ** Updated documentation for these options and for ffi.

* 1999-06-16
  ** Hardwired version number in `src/control/control.sml`.  As it stood, the
  version number was computed when MLton was built after someone downloaded it,
  which was clearly wrong.

* 1999-06-16
  ** Fixed undefined variable `time` in `GC_done` in `src/runtime/gc.c`.

* 19990-06-08
  ** in `include/mlton-lib.h`:
    *** removed `#include &lt;huge_val.h&gt;`
    *** added `#include &lt;math.h&gt;`
    *** and deleted all of the function signatures I had copied from `math.h`
  ** Changed `Real.{minNormalPos, minPos, maxFinite}` so that they are computed
  in `real.sml` instead of appearing as constants in the C.

* 1999-06-07
  `IntInf.pow` added to basis library.

* 1999-06-04
  ** `bin/mlton` changed to use `.arch-n-opsys` if it exists.

* 1999-06-03
  ** `src/Makefile` changed to use `sml-cm` instead of `sml`

* 1999-05-10
  ** Patch to `src/atoms/small-int-inf.fun` to work around a bug in the SML/NJ
  implementation of bignums.  This bug was causing some hex bignum constants to
  be lexed incorrectly.

* 1999-04-15
  ** Comments emitted in C code for profiling.  The comments identify the CPS
  function responsible for each C statement.

* 1999-04-15
  **  `callcc` and `throw` added.

* 1999-04-15
  ** Bug in `src/cps/simplify-types` fixed.  The bug caused nontermination
  whenever there was a circular datatype with a vector on the rhs.
  E.g. `datatype t = T of t vector`


== Version 19990319

Here are the changes from the 1998-08-26 version to the 1999-03-19 version.

=== Summary

* Compile time and code size have decreased.
* Runtime performance of executables has improved.
* Large programs can now be compiled.
* MLton is self hosting.
* The basis library is mostly complete and many bugs have been fixed.
* The monomorphiser (`-m`) is no longer available.
* The heap and stack are automatically resized.
* There are now facilities for heap checkpointing (`MLton.saveWorld`) and object
size computation (`MLton.size`).
* MLton uses the GNU multiprecision (GnuMP) library to provide a fast
implementation of `IntInf`.</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ChrisClearwater">
<title>ChrisClearwater</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Chunkify">
<title>Chunkify</title>
<simpara><link linkend="Chunkify">Chunkify</link> is an analysis pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ToMachine">ToMachine</link>.</simpara>
<section id="_description_3">
<title>Description</title>
<simpara>It partitions all the labels (function and block) in an <link linkend="RSSA">RSSA</link>
program into disjoint sets, referred to as chunks.</simpara>
</section>
<section id="_implementation_4">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/chunkify.sig"><literal>chunkify.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/chunkify.fun"><literal>chunkify.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_4">
<title>Details and Notes</title>
<simpara>Breaking large <link linkend="RSSA">RSSA</link> functions into chunks is necessary for
reasonable compile times with the <link linkend="CCodegen">CCodegen</link> and the <link linkend="LLVMCodegen">LLVMCodegen</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CKitLibrary">
<title>CKitLibrary</title>
<simpara>The <ulink url="http://www.smlnj.org/doc/ckit">ckit Library</ulink> is a C front end
written in SML that translates C source code (after preprocessing)
into abstract syntax represented as a set of SML datatypes.  The ckit
Library is distributed with SML/NJ.  Due to differences between SML/NJ
and MLton, this library will not work out-of-the box with MLton.</simpara>
<simpara>As of 20180119, MLton includes a port of the ckit Library synchronized
with SML/NJ version 110.82.</simpara>
<section id="_usage">
<title>Usage</title>
<itemizedlist>
<listitem>
<simpara>
You can import the ckit Library into an MLB file with:
</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<thead>
<row>
<entry align="left" valign="top">MLB file</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/ckit-lib/ckit-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
If you are porting a project from SML/NJ&#8217;s <link linkend="CompilationManager">CompilationManager</link> to
MLton&#8217;s <link linkend="MLBasis">ML Basis system</link> using <literal>cm2mlb</literal>, note that the
following map is included by default:
</simpara>
<screen># ckit Library
$ckit-lib.cm                            $(SML_LIB)/ckit-lib
$ckit-lib.cm/ckit-lib.cm                $(SML_LIB)/ckit-lib/ckit-lib.mlb</screen>
<simpara>This will automatically convert a <literal>$/ckit-lib.cm</literal> import in an input
<literal>.cm</literal> file into a <literal>$(SML_LIB)/ckit-lib/ckit-lib.mlb</literal> import in the
output <literal>.mlb</literal> file.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details">
<title>Details</title>
<simpara>The following changes were made to the ckit Library, in addition to
deriving the <literal>.mlb</literal> file from the <literal>.cm</literal> file:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>ast/pp/pp-ast-adornment-sig.sml</literal> (modified): Rewrote use of <literal>signature</literal> in <literal>local</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>ast/pp/pp-ast-ext-sig.sml</literal> (modified): Rewrote use of <literal>signature</literal> in <literal>local</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>ast/type-util-sig.sml</literal> (modified): Rewrote use of <literal>signature</literal> in <literal>local</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>parser/parse-tree-sig.sml</literal> (modified): Rewrote use of (sequential) <literal>withtype</literal> in signature.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>parser/parse-tree.sml</literal> (modified): Rewrote use of (sequential) <literal>withtype</literal>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_patch">
<title>Patch</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/lib/ckit-lib/ckit.patch"><literal>ckit.patch</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Closure">
<title>Closure</title>
<simpara>A closure is a data structure that is the run-time representation of a
function.</simpara>
<section id="_typical_implementation">
<title>Typical Implementation</title>
<simpara>In a typical implementation, a closure consists of a <emphasis>code pointer</emphasis>
(indicating what the function does) and an <emphasis>environment</emphasis> containing
the values of the free variables of the function.  For example, in the
expression</simpara>
<programlisting language="sml" linenumbering="unnumbered">let
   val x = 5
in
   fn y =&gt; x + y
end</programlisting>
<simpara>the closure for <literal>fn y =&gt; x + y</literal> contains a pointer to a piece of code
that knows to take its argument and add the value of <literal>x</literal> to it, plus
the environment recording the value of <literal>x</literal> as <literal>5</literal>.</simpara>
<simpara>To call a function, the code pointer is extracted and jumped to,
passing in some agreed upon location the environment and the argument.</simpara>
</section>
<section id="_mlton_8217_s_implementation">
<title>MLton&#8217;s Implementation</title>
<simpara>MLton does not implement closures traditionally.  Instead, based on
whole-program higher-order control-flow analysis, MLton represents a
function as an element of a sum type, where the variant indicates
which function it is and carries the free variables as arguments.  See
<link linkend="ClosureConvert">ClosureConvert</link> and <link linkend="References_CejtinEtAl00">CejtinEtAl00</link> for details.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ClosureConvert">
<title>ClosureConvert</title>
<simpara><link linkend="ClosureConvert">ClosureConvert</link> is a translation pass from the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="SSA">SSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_4">
<title>Description</title>
<simpara>It converts an <link linkend="SXML">SXML</link> program into an <link linkend="SSA">SSA</link> program.</simpara>
<simpara><link linkend="Defunctionalization">Defunctionalization</link> is the technique used to eliminate
<link linkend="Closure">Closure</link>s (see <link linkend="References_CejtinEtAl00">CejtinEtAl00</link>).</simpara>
<simpara>Uses <link linkend="Globalize">Globalize</link> and <link linkend="LambdaFree">LambdaFree</link> analyses.</simpara>
</section>
<section id="_implementation_5">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/closure-convert/closure-convert.sig"><literal>closure-convert.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/closure-convert/closure-convert.fun"><literal>closure-convert.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_5">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CMinusMinus">
<title>CMinusMinus</title>
<simpara><ulink url="http://cminusminus.org">C--</ulink> is a portable assembly language intended
to make it easy for compilers for different high-level languages to
share the same backend.  An experimental version of MLton has been
made to generate C--.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2005-March/026850.html">http://www.mlton.org/pipermail/mlton/2005-March/026850.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<section id="_also_see">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="LLVM">LLVM</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Codegen">
<title>Codegen</title>
<simpara><link linkend="Codegen">Codegen</link> is a translation pass from the <link linkend="Machine">Machine</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to one or more compilation units that can be
compiled to native object code by an external tool.</simpara>
<section id="_implementation_6">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/tree/master/mlton/codegen"><literal>codegen</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_6">
<title>Details and Notes</title>
<simpara>The following <link linkend="Codegen">codegens</link> are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="AMD64Codegen">AMD64Codegen</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CCodegen">CCodegen</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LLVMCodegen">LLVMCodegen</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="X86Codegen">X86Codegen</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CombineConversions">
<title>CombineConversions</title>
<simpara><link linkend="CombineConversions">CombineConversions</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_5">
<title>Description</title>
<simpara>This pass looks for and simplifies nested calls to (signed)
extension/truncation.</simpara>
</section>
<section id="_implementation_7">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/combine-conversions.fun"><literal>combine-conversions.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_7">
<title>Details and Notes</title>
<simpara>It processes each block in dfs order (visiting definitions before uses):</simpara>
<itemizedlist>
<listitem>
<simpara>
If the statement is not a <literal>PrimApp</literal> with <literal>Word_extdToWord</literal>, skip it.
</simpara>
</listitem>
<listitem>
<simpara>
After processing a conversion, it tags the <literal>Var</literal> for subsequent use.
</simpara>
</listitem>
<listitem>
<simpara>
When inspecting a conversion, check if the <literal>Var</literal> operand is also the
result of a conversion. If it is, try to combine the two operations.
Repeatedly simplify until hitting either a non-conversion <literal>Var</literal> or a
case where the conversion cannot be simplified.
</simpara>
</listitem>
</itemizedlist>
<simpara>The optimization rules are very simple:</simpara>
<screen>x1 = ...
x2 = Word_extdToWord (W1, W2, {signed=s1}) x1
x3 = Word_extdToWord (W2, W3, {signed=s2}) x2</screen>
<itemizedlist>
<listitem>
<simpara>
If <literal>W1 = W2</literal>, then there is no conversions before <literal>x_1</literal>.
</simpara>
<simpara>This is guaranteed because <literal>W2 = W3</literal> will always trigger optimization.</simpara>
</listitem>
<listitem>
<simpara>
Case <literal>W1 &lt;= W3 &lt;= W2</literal>:
</simpara>
<screen>x3 = Word_extdToWord (W1, W3, {signed=s1}) x1</screen>
</listitem>
<listitem>
<simpara>
Case <literal>W1 &lt;  W2 &lt;  W3  AND  ((NOT s1) OR s2)</literal>:
</simpara>
<screen>x3 = Word_extdToWord (W1, W3, {signed=s1}) x1</screen>
</listitem>
<listitem>
<simpara>
Case <literal>W1 =  W2 &lt;  W3</literal>:
</simpara>
<simpara>unoptimized, because there are no conversions past <literal>W1</literal> and <literal>x2 = x1</literal></simpara>
</listitem>
<listitem>
<simpara>
Case <literal>W3 &lt;= W2 &lt;= W1  OR  W3 &lt;= W1 &lt;= W2</literal>:
</simpara>
<screen>x_3 = Word_extdToWord (W1, W3, {signed=_}) x1</screen>
<simpara>because <literal>W3 &lt;= W1 &amp;&amp; W3 &lt;= W2</literal>, just clip <literal>x1</literal></simpara>
</listitem>
<listitem>
<simpara>
Case <literal>W2 &lt; W1 &lt;= W3  OR  W2 &lt; W3 &lt;= W1</literal>:
</simpara>
<simpara>unoptimized, because <literal>W2 &lt; W1 &amp;&amp; W2 &lt; W3</literal>, has truncation effect</simpara>
</listitem>
<listitem>
<simpara>
Case <literal>W1 &lt; W2 &lt; W3  AND  (s1 AND (NOT s2))</literal>:
</simpara>
<simpara>unoptimized, because each conversion affects the result separately</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CommonArg">
<title>CommonArg</title>
<simpara><link linkend="CommonArg">CommonArg</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_6">
<title>Description</title>
<simpara>It optimizes instances of <literal>Goto</literal> transfers that pass the same
arguments to the same label; e.g.</simpara>
<screen>L_1 ()
  ...
  z1 = ?
  ...
  L_3 (x, y, z1)
L_2 ()
  ...
  z2 = ?
  ...
  L_3 (x, y, z2)
L_3 (a, b, c)
  ...</screen>
<simpara>This code can be simplified to:</simpara>
<screen>L_1 ()
  ...
  z1 = ?
  ...
  L_3 (z1)
L_2 ()
  ...
  z2 = ?
  ...
  L_3 (z2)
L_3 (c)
  a = x
  b = y</screen>
<simpara>which saves a number of resources: time of setting up the arguments
for the jump to <literal>L_3</literal>, space (either stack or pseudo-registers) for
the arguments of <literal>L_3</literal>, etc.  It may also expose some other
optimizations, if more information is known about <literal>x</literal> or <literal>y</literal>.</simpara>
</section>
<section id="_implementation_8">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/common-arg.fun"><literal>common-arg.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_8">
<title>Details and Notes</title>
<simpara>Three analyses were originally proposed to drive the optimization
transformation.  Only the <emphasis>Dominator Analysis</emphasis> is currently
implemented.  (Implementations of the other analyses are available in
the <link linkend="Sources">repository history</link>.)</simpara>
<section id="_syntactic_analysis">
<title>Syntactic Analysis</title>
<simpara>The simplest analysis I could think of maintains</simpara>
<screen>varInfo: Var.t -&gt; Var.t option list ref</screen>
<simpara>initialized to <literal>[]</literal>.</simpara>
<itemizedlist>
<listitem>
<simpara>
For each variable <literal>v</literal> bound in a <literal>Statement.t</literal> or in the
<literal>Function.t</literal> args, then <literal>List.push(varInfo v, NONE)</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
For each <literal>L (x1, ..., xn)</literal> transfer where <literal>(a1, ..., an)</literal> are the
formals of <literal>L</literal>, then <literal>List.push(varInfo ai, SOME xi)</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
For each block argument a used in an unknown context (e.g.,
arguments of blocks used as continuations, handlers, arith success,
runtime return, or case switch labels), then
<literal>List.push(varInfo a, NONE)</literal>.
</simpara>
</listitem>
</itemizedlist>
<simpara>Now, any block argument <literal>a</literal> such that <literal>varInfo a = xs</literal>, where all of
the elements of <literal>xs</literal> are equal to <literal>SOME x</literal>, can be optimized by
setting <literal>a = x</literal> at the beginning of the block and dropping the
argument from <literal>Goto</literal> transfers.</simpara>
<simpara>That takes care of the example above.  We can clearly do slightly
better, by changing the transformation criteria to the following: any
block argument a such that <literal>varInfo a = xs</literal>, where all of the elements
of <literal>xs</literal> are equal to <literal>SOME x</literal> <emphasis>or</emphasis> are equal to <literal>SOME a</literal>, can be
optimized by setting <literal>a = x</literal> at the beginning of the block and
dropping the argument from <literal>Goto</literal> transfers.  This optimizes a case
like:</simpara>
<screen>L_1 ()
  ... z1 = ? ...
  L_3 (x, y, z1)
L_2 ()
  ... z2 = ? ...
  L_3(x, y, z2)
L_3 (a, b, c)
  ... w = ? ...
  case w of
    true =&gt; L_4 | false =&gt; L_5
L_4 ()
   ...
   L_3 (a, b, w)
L_5 ()
   ...</screen>
<simpara>where a common argument is passed to a loop (and is invariant through
the loop).  Of course, the <link linkend="LoopInvariant">LoopInvariant</link> optimization pass would
normally introduce a local loop and essentially reduce this to the
first example, but I have seen this in practice, which suggests that
some optimizations after <link linkend="LoopInvariant">LoopInvariant</link> do enough simplifications
to introduce (new) loop invariant arguments.</simpara>
</section>
<section id="_fixpoint_analysis">
<title>Fixpoint Analysis</title>
<simpara>However, the above analysis and transformation doesn&#8217;t cover the cases
where eliminating one common argument exposes the opportunity to
eliminate other common arguments.  For example:</simpara>
<screen>L_1 ()
  ...
  L_3 (x)
L_2 ()
  ...
  L_3 (x)
L_3 (a)
  ...
  L_5 (a)
L_4 ()
  ...
  L_5 (x)
L_5 (b)
  ...</screen>
<simpara>One pass of analysis and transformation would eliminate the argument
to <literal>L_3</literal> and rewrite the <literal>L_5(a)</literal> transfer to <literal>L_5 (x)</literal>, thereby
exposing the opportunity to eliminate the common argument to <literal>L_5</literal>.</simpara>
<simpara>The interdependency the arguments to <literal>L_3</literal> and <literal>L_5</literal> suggest
performing some sort of fixed-point analysis.  This analysis is
relatively simple; maintain</simpara>
<screen>varInfo: Var.t -&gt; VarLattice.t</screen>
<simpara>where</simpara>
<screen>VarLattice.t ~=~ Bot | Point of Var.t | Top</screen>
<simpara>(but is implemented by the <link linkend="FlatLattice">FlatLattice</link> functor with a <literal>lessThan</literal>
list and <literal>value ref</literal> under the hood), initialized to <literal>Bot</literal>.</simpara>
<itemizedlist>
<listitem>
<simpara>
For each variable <literal>v</literal> bound in a <literal>Statement.t</literal> or in the
<literal>Function.t</literal> args, then <literal>VarLattice.&lt;= (Point v, varInfo v)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
For each <literal>L (x1, ..., xn)</literal> transfer where <literal>(a1, ..., an)</literal> are the
formals of <literal>L</literal>}, then <literal>VarLattice.&lt;= (varInfo xi, varInfo ai)</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
For each block argument a used in an unknown context, then
<literal>VarLattice.&lt;= (Point a, varInfo a)</literal>.
</simpara>
</listitem>
</itemizedlist>
<simpara>Now, any block argument a such that <literal>varInfo a = Point x</literal> can be
optimized by setting <literal>a = x</literal> at the beginning of the block and
dropping the argument from <literal>Goto</literal> transfers.</simpara>
<simpara>Now, with the last example, we introduce the ordering constraints:</simpara>
<screen>varInfo x &lt;= varInfo a
varInfo a &lt;= varInfo b
varInfo x &lt;= varInfo b</screen>
<simpara>Assuming that <literal>varInfo x = Point x</literal>, then we get <literal>varInfo a = Point x</literal>
and <literal>varInfo b = Point x</literal>, and we optimize the example as desired.</simpara>
<simpara>But, that is a rather weak assumption.  It&#8217;s quite possible for
<literal>varInfo x = Top</literal>.  For example, consider:</simpara>
<screen>G_1 ()
  ... n = 1 ...
  L_0 (n)
G_2 ()
  ... m = 2 ...
  L_0 (m)
L_0 (x)
  ...
L_1 ()
  ...
  L_3 (x)
L_2 ()
  ...
  L_3 (x)
L_3 (a)
  ...
  L_5(a)
L_4 ()
  ...
  L_5(x)
L_5 (b)
   ...</screen>
<simpara>Now <literal>varInfo x = varInfo a = varInfo b = Top</literal>.  What went wrong here?
When <literal>varInfo x</literal> went to <literal>Top</literal>, it got propagated all the way through
to <literal>a</literal> and <literal>b</literal>, and prevented the elimination of any common arguments.
What we&#8217;d like to do instead is when <literal>varInfo x</literal> goes to <literal>Top</literal>,
propagate on <literal>Point x</literal>&#8201;&#8212;&#8201;we have no hope of eliminating <literal>x</literal>, but if
we hold <literal>x</literal> constant, then we have a chance of eliminating arguments
for which <literal>x</literal> is passed as an actual.</simpara>
</section>
<section id="_dominator_analysis">
<title>Dominator Analysis</title>
<simpara>Does anyone see where this is going yet?  Pausing for a little
thought, <link linkend="MatthewFluet">MatthewFluet</link> realized that he had once before tried
proposing this kind of "fix" to a fixed-point analysis&#8201;&#8212;&#8201;when we were
first investigating the <link linkend="Contify">Contify</link> optimization in light of John
Reppy&#8217;s CWS paper.  Of course, that "fix" failed because it defined a
non-monotonic function and one couldn&#8217;t take the fixed point.  But,
<link linkend="StephenWeeks">StephenWeeks</link> suggested a dominator based approach, and we were
able to show that, indeed, the dominator analysis subsumed both the
previous call based analysis and the cont based analysis.  And, a
moment&#8217;s reflection reveals further parallels: when
<literal>varInfo: Var.t -&gt; Var.t option list ref</literal>, we have something analogous
to the call analysis, and when <literal>varInfo: Var.t -&gt; VarLattice.t</literal>, we
have something analogous to the cont analysis.  Maybe there is
something analogous to the dominator approach (and therefore superior
to the previous analyses).</simpara>
<simpara>And this turns out to be the case.  Construct the graph <literal>G</literal> as follows:</simpara>
<screen>nodes(G) = {Root} U Var.t
edges(G) = {Root -&gt; v | v bound in a Statement.t or
                                in the Function.t args} U
           {xi -&gt; ai | L(x1, ..., xn) transfer where (a1, ..., an)
                                      are the formals of L} U
           {Root -&gt; a | a is a block argument used in an unknown context}</screen>
<simpara>Let <literal>idom(x)</literal> be the immediate dominator of <literal>x</literal> in <literal>G</literal> with root
<literal>Root</literal>.  Now, any block argument a such that <literal>idom(a) = x &lt;&gt; Root</literal> can
be optimized by setting <literal>a = x</literal> at the beginning of the block and
dropping the argument from <literal>Goto</literal> transfers.</simpara>
<simpara>Furthermore, experimental evidence suggests (and we are confident that
a formal presentation could prove) that the dominator analysis
subsumes the "syntactic" and "fixpoint" based analyses in this context
as well and that the dominator analysis gets "everything" in one go.</simpara>
</section>
<section id="_final_thoughts">
<title>Final Thoughts</title>
<simpara>I must admit, I was rather surprised at this progression and final
result.  At the outset, I never would have thought of a connection
between <link linkend="Contify">Contify</link> and <link linkend="CommonArg">CommonArg</link> optimizations.  They would seem
to be two completely different optimizations.  Although, this may not
really be the case.  As one of the reviewers of the ICFP paper said:</simpara>
<blockquote>
<simpara>I understand that such a form of CPS might be convenient in some
cases, but when we&#8217;re talking about analyzing code to detect that some
continuation is constant, I think it makes a lot more sense to make
all the continuation arguments completely explicit.</simpara>
<simpara>I believe that making all the continuation arguments explicit will
show that the optimization can be generalized to eliminating constant
arguments, whether continuations or not.</simpara>
</blockquote>
<simpara>What I think the common argument optimization shows is that the
dominator analysis does slightly better than the reviewer puts it: we
find more than just constant continuations, we find common
continuations.  And I think this is further justified by the fact that
I have observed common argument eliminate some <literal>env_X</literal> arguments which
would appear to correspond to determining that while the closure being
executed isn&#8217;t constant it is at least the same as the closure being
passed elsewhere.</simpara>
<simpara>At first, I was curious whether or not we had missed a bigger picture
with the dominator analysis.  When we wrote the contification paper, I
assumed that the dominator analysis was a specialized solution to a
specialized problem; we never suggested that it was a technique suited
to a larger class of analyses.  After initially finding a connection
between <link linkend="Contify">Contify</link> and <link linkend="CommonArg">CommonArg</link> (and thinking that the only
connection was the technique), I wondered if the dominator technique
really was applicable to a larger class of analyses.  That is still a
question, but after writing up the above, I&#8217;m suspecting that the
"real story" is that the dominator analysis is a solution to the
common argument optimization, and that the <link linkend="Contify">Contify</link> optimization is
specializing <link linkend="CommonArg">CommonArg</link> to the case of continuation arguments (with
a different transformation at the end).  (Note, a whole-program,
inter-procedural common argument analysis doesn&#8217;t really make sense
(in our <link linkend="SSA">SSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>), because the only way of
passing values between functions is as arguments.  (Unless of course
in the case that the common argument is also a constant argument, in
which case <link linkend="ConstantPropagation">ConstantPropagation</link> could lift it to a global.)  The
inter-procedural <link linkend="Contify">Contify</link> optimization works out because there we
move the function to the argument.)</simpara>
<simpara>Anyways, it&#8217;s still unclear to me whether or not the dominator based
approach solves other kinds of problems.</simpara>
</section>
<section id="_phase_ordering">
<title>Phase Ordering</title>
<simpara>On the downside, the optimization doesn&#8217;t have a huge impact on
runtime, although it does predictably saved some code size.  I stuck
it in the optimization sequence after <link linkend="Flatten">Flatten</link> and (the third round
of) <link linkend="LocalFlatten">LocalFlatten</link>, since it seems to me that we could have cases
where some components of a tuple used as an argument are common, but
the whole tuple isn&#8217;t.  I think it makes sense to add it after
<link linkend="IntroduceLoops">IntroduceLoops</link> and <link linkend="LoopInvariant">LoopInvariant</link> (even though <link linkend="CommonArg">CommonArg</link>
get some things that <link linkend="LoopInvariant">LoopInvariant</link> gets, it doesn&#8217;t get all of
them).  I also think that it makes sense to add it before
<link linkend="CommonSubexp">CommonSubexp</link>, since identifying variables could expose more common
subexpressions.  I would think a similar thought applies to
<link linkend="RedundantTests">RedundantTests</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="CommonBlock">
<title>CommonBlock</title>
<simpara><link linkend="CommonBlock">CommonBlock</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_7">
<title>Description</title>
<simpara>It eliminates equivalent blocks in a <link linkend="SSA">SSA</link> function.  The
equivalence criteria requires blocks to have no arguments or
statements and transfer via <literal>Raise</literal>, <literal>Return</literal>, or <literal>Goto</literal> of a single
global variable.</simpara>
</section>
<section id="_implementation_9">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/common-block.fun"><literal>common-block.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_9">
<title>Details and Notes</title>
<itemizedlist>
<listitem>
<simpara>
Rewrites
</simpara>
<screen>L_X ()
  raise (global_Y)</screen>
<simpara>to</simpara>
<screen>L_X ()
  L_Y' ()</screen>
<simpara>and adds</simpara>
<screen>L_Y' ()
  raise (global_Y)</screen>
<simpara>to the <link linkend="SSA">SSA</link> function.</simpara>
</listitem>
<listitem>
<simpara>
Rewrites
</simpara>
<screen>L_X ()
  return (global_Y)</screen>
<simpara>to</simpara>
<screen>L_X ()
  L_Y' ()</screen>
<simpara>and adds</simpara>
<screen>L_Y' ()
  return (global_Y)</screen>
<simpara>to the <link linkend="SSA">SSA</link> function.</simpara>
</listitem>
<listitem>
<simpara>
Rewrites
</simpara>
<screen>L_X ()
  L_Z (global_Y)</screen>
<simpara>to</simpara>
<screen>L_X ()
  L_Y' ()</screen>
<simpara>and adds</simpara>
<screen>L_Y' ()
  L_Z (global_Y)</screen>
<simpara>to the <link linkend="SSA">SSA</link> function.</simpara>
</listitem>
</itemizedlist>
<simpara>The <link linkend="Shrink">Shrink</link> pass rewrites all uses of <literal>L_X</literal> to <literal>L_Y'</literal> and drops <literal>L_X</literal>.</simpara>
<simpara>For example, all uncaught <literal>Overflow</literal> exceptions in a <link linkend="SSA">SSA</link> function
share the same raising block.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CommonSubexp">
<title>CommonSubexp</title>
<simpara><link linkend="CommonSubexp">CommonSubexp</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_8">
<title>Description</title>
<simpara>It eliminates instances of common subexpressions.</simpara>
</section>
<section id="_implementation_10">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/common-subexp.fun"><literal>common-subexp.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_10">
<title>Details and Notes</title>
<simpara>In addition to getting the usual sorts of things like</simpara>
<itemizedlist>
<listitem>
<simpara>
</simpara>
<screen>(w + 0wx1) + (w + 0wx1)</screen>
<simpara>rewritten to</simpara>
<screen>let val w' = w + 0wx1 in w' + w' end</screen>
</listitem>
</itemizedlist>
<simpara>it also gets things like</simpara>
<itemizedlist>
<listitem>
<simpara>
</simpara>
<screen>val a = Array_uninit n
val b = Array_length a</screen>
<simpara>rewritten to</simpara>
<screen>val a = Array_uninit n
val b = n</screen>
</listitem>
</itemizedlist>
<simpara><literal>Arith</literal> transfers are handled specially.  The <emphasis>result</emphasis> of an <literal>Arith</literal>
transfer can be used in <emphasis>common</emphasis> <literal>Arith</literal> transfers that it dominates:</simpara>
<itemizedlist>
<listitem>
<simpara>
</simpara>
<screen>val l = (n + m) + (n + m)

val k = (l + n) + ((l + m) handle Overflow =&gt; ((l + m)
                                               handle Overflow =&gt; l + n))</screen>
<simpara>is rewritten so that <literal>(n + m)</literal> is computed exactly once, as are
<literal>(l + n)</literal> and <literal>(l + m)</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CompilationManager">
<title>CompilationManager</title>
<simpara>The <ulink url="http://www.smlnj.org/doc/CM/index.html">Compilation Manager</ulink> (CM) is SML/NJ&#8217;s mechanism for supporting programming-in-the-very-large.</simpara>
<section id="_porting_sml_nj_cm_files_to_mlton">
<title>Porting SML/NJ CM files to MLton</title>
<simpara>To help in porting CM files to MLton, the MLton source distribution
includes the sources for a utility, <literal>cm2mlb</literal>, that will print an
<link linkend="MLBasis">ML Basis</link> file with essentially the same semantics as the
CM file&#8201;&#8212;&#8201;handling the full syntax of CM supported by your installed
SML/NJ version and correctly handling export filters.  When <literal>cm2mlb</literal>
encounters a <literal>.cm</literal> import, it attempts to convert it to a
corresponding <literal>.mlb</literal> import.  CM anchored paths are translated to
paths according to a default configuration file
(<ulink url="https://github.com/MLton/mlton/blob/master/util/cm2mlb/cm2mlb-map"><literal>cm2mlb-map</literal></ulink>). For example,
the default configuration includes</simpara>
<screen># Standard ML Basis Library
$SMLNJ-BASIS                            $(SML_LIB)/basis
$basis.cm                               $(SML_LIB)/basis
$basis.cm/basis.cm                      $(SML_LIB)/basis/basis.mlb</screen>
<simpara>to ensure that a <literal>$/basis.cm</literal> import is translated to a
<literal>$(SML_LIB)/basis/basis.mlb</literal> import.  See <literal>util/cm2mlb</literal> for details.
Building <literal>cm2mlb</literal> requires that you have already installed a recent
version of SML/NJ.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CompilerOverview">
<title>CompilerOverview</title>
<simpara>The following table shows the overall structure of the compiler.
<link linkend="IntermediateLanguage">IntermediateLanguage</link>s are shown in the center column.  The names
of compiler passes are listed in the left and right columns.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="3">
<colspec colname="col_1" colwidth="33*"/>
<colspec colname="col_2" colwidth="33*"/>
<colspec colname="col_3" colwidth="33*"/>
<tbody>
<row>
<entry align="center" valign="top" namest="col_1" nameend="col_3"><simpara><emphasis role="strong">Compiler Overview</emphasis></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><emphasis>Translation Passes</emphasis></simpara></entry>
<entry align="center" valign="top"><simpara><emphasis><link linkend="IntermediateLanguage">IntermediateLanguage</link></emphasis></simpara></entry>
<entry align="center" valign="top"><simpara><emphasis>Optimization Passes</emphasis></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara>Source</simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="FrontEnd">FrontEnd</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="AST">AST</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="Elaborate">Elaborate</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="CoreML">CoreML</link></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="CoreMLSimplify">CoreMLSimplify</link></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="Defunctorize">Defunctorize</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="XML">XML</link></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="XMLSimplify">XMLSimplify</link></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="Monomorphise">Monomorphise</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="SXML">SXML</link></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="SXMLSimplify">SXMLSimplify</link></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="ClosureConvert">ClosureConvert</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="SSA">SSA</link></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="SSASimplify">SSASimplify</link></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="ToSSA2">ToSSA2</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="SSA2">SSA2</link></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="SSA2Simplify">SSA2Simplify</link></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="ToRSSA">ToRSSA</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="RSSA">RSSA</link></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="RSSASimplify">RSSASimplify</link></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="ToMachine">ToMachine</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara><link linkend="Machine">Machine</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><link linkend="Codegen">Codegen</link></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
<entry align="center" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>The <literal>Compile</literal> functor (<ulink url="https://github.com/MLton/mlton/blob/master/mlton/main/compile.sig"><literal>compile.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/main/compile.fun"><literal>compile.fun</literal></ulink>), controls the
high-level view of the compiler passes, from <link linkend="FrontEnd">FrontEnd</link> to code
generation.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="CompilerPassTemplate">
<title>CompilerPassTemplate</title>
<simpara>An analysis pass for the <link linkend="ZZZ">ZZZ</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ZZZOtherPass">ZZZOtherPass</link>.
An implementation pass for the <link linkend="ZZZ">ZZZ</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ZZZSimplify">ZZZSimplify</link>.
An optimization pass for the <link linkend="ZZZ">ZZZ</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ZZZSimplify">ZZZSimplify</link>.
A rewrite pass for the <link linkend="ZZZ">ZZZ</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ZZZOtherPass">ZZZOtherPass</link>.
A translation pass from the <link linkend="ZZA">ZZA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="ZZB">ZZB</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_9">
<title>Description</title>
<simpara>A short description of the pass.</simpara>
</section>
<section id="_implementation_11">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ZZZ.fun"><literal>ZZZ.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_11">
<title>Details and Notes</title>
<simpara>Relevant details and notes.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CompileTimeOptions">
<title>CompileTimeOptions</title>
<simpara>MLton&#8217;s compile-time options control the name of the output file, the
verbosity of compile-time messages, and whether or not certain
optimizations are performed.  They also can specify which intermediate
files are saved and can stop the compilation process early, at some
intermediate pass, in which case compilation can be resumed by passing
the generated files to MLton.  MLton uses the input file suffix to
determine the type of input program.  The possibilities are <literal>.c</literal>,
<literal>.mlb</literal>, <literal>.o</literal>, <literal>.s</literal>, and <literal>.sml</literal>.</simpara>
<simpara>With no arguments, MLton prints the version number and exits.  For a
usage message, run MLton with an invalid switch, e.g.  <literal>mlton -z</literal>.  In
the explanation below and in the usage message, for flags that take a
number of choices (e.g. <literal>{true|false}</literal>), the first value listed is the
default.</simpara>
<section id="_options">
<title>Options</title>
<itemizedlist>
<listitem>
<simpara>
<literal>-align <emphasis>n</emphasis></literal>
</simpara>
<simpara>Aligns object in memory by the specified alignment (<literal>4</literal> or <literal>8</literal>).
The default varies depending on architecture.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-as-opt <emphasis>option</emphasis></literal>
</simpara>
<simpara>Pass <emphasis>option</emphasis> to <literal>gcc</literal> when compiling assembler code.  If you wish to
pass an option to the assembler, you must use <literal>gcc</literal>'s <literal>-Wa,</literal> syntax.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-cc-opt <emphasis>option</emphasis></literal>
</simpara>
<simpara>Pass <emphasis>option</emphasis> to <literal>gcc</literal> when compiling C code.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-codegen {native|amd64|c|llvm|x86}</literal>
</simpara>
<simpara>Generate native object code via amd64 assembly, C code, LLVM code, or
x86 code or C code.  With <literal>-codegen native</literal> (<literal>-codegen amd64</literal> or
<literal>-codegen x86</literal>), MLton typically compiles more quickly and generates
better code.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-const <emphasis>name</emphasis> <emphasis>value</emphasis></literal>
</simpara>
<simpara>Set the value of a compile-time constant.  Here is a list of
available constants, their default values, and what they control.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>Exn.keepHistory {false|true}</literal>
</simpara>
<simpara>Enable <literal>MLton.Exn.history</literal>.  See <link linkend="MLtonExn">MLtonExn</link> for details.  There is a
performance cost to setting this to <literal>true</literal>, both in memory usage of
exceptions and in run time, because of additional work that must be
performed at each exception construction, raise, and handle.</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>-default-ann <emphasis>ann</emphasis></literal>
</simpara>
<simpara>Specify default <link linkend="MLBasisAnnotations">ML Basis annotations</link>.  For
example, <literal>-default-ann 'warnUnused true'</literal> causes unused variable
warnings to be enabled by default.  A default is overridden by the
corresponding annotation in an ML Basis file.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-default-type <emphasis>type</emphasis></literal>
</simpara>
<simpara>Specify the default binding for a primitive type.  For example,
<literal>-default-type word64</literal> causes the top-level type <literal>word</literal> and the
top-level structure <literal>Word</literal> in the <link linkend="BasisLibrary">Basis Library</link> to be
equal to <literal>Word64.word</literal> and <literal>Word64:WORD</literal>, respectively.  Similarly,
<literal>-default-type intinf</literal> causes the top-level type <literal>int</literal> and the
top-level structure <literal>Int</literal> in the <link linkend="BasisLibrary">Basis Library</link> to be
equal to <literal>IntInf.int</literal> and <literal>IntInf:INTEGER</literal>, respectively.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-disable-ann <emphasis>ann</emphasis></literal>
</simpara>
<simpara>Ignore the specified <link linkend="MLBasisAnnotations">ML Basis annotation</link> in
every ML Basis file.  For example, to see <emphasis>all</emphasis> match and unused
warnings, compile with</simpara>
<screen>-default-ann 'warnUnused true'
-disable-ann forceUsed
-disable-ann nonexhaustiveMatch
-disable-ann redundantMatch
-disable-ann warnUnused</screen>
</listitem>
<listitem>
<simpara>
<literal>-export-header <emphasis>file</emphasis></literal>
</simpara>
<simpara>Write C prototypes to <emphasis>file</emphasis> for all of the functions in the program
<link linkend="CallingFromCToSML">exported from SML to C</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-ieee-fp {false|true}</literal>
</simpara>
<simpara>Cause the x86 native code generator to be pedantic about following the
IEEE floating point standard.  By default, it is not, because of the
performance cost.  This only has an effect with <literal>-codegen x86</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-inline <emphasis>n</emphasis></literal>
</simpara>
<simpara>Set the inlining threshold used in the optimizer.  The threshold is an
approximate measure of code size of a procedure.  The default is
<literal>320</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-keep {g|o}</literal>
</simpara>
<simpara>Save intermediate files.  If no <literal>-keep</literal> argument is given, then only
the output file is saved.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><literal>g</literal></simpara></entry>
<entry align="left" valign="top"><simpara>generated <literal>.c</literal> and <literal>.s</literal> files passed to <literal>gcc</literal> and generated <literal>.ll</literal> files passed to <literal>llvm-as</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>o</literal></simpara></entry>
<entry align="left" valign="top"><simpara>object (<literal>.o</literal>) files</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
<literal>-link-opt <emphasis>option</emphasis></literal>
</simpara>
<simpara>Pass <emphasis>option</emphasis> to <literal>gcc</literal> when linking.  You can use this to specify
library search paths, e.g. <literal>-link-opt -Lpath</literal>, and libraries to link
with, e.g., <literal>-link-opt -lfoo</literal>, or even both at the same time,
e.g. <literal>-link-opt '-Lpath -lfoo'</literal>.  If you wish to pass an option to the
linker, you must use <literal>gcc</literal>'s <literal>-Wl,</literal> syntax, e.g.,
<literal>-link-opt '-Wl,--export-dynamic'</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-llvm-as-opt <emphasis>option</emphasis></literal>
</simpara>
<simpara>Pass <emphasis>option</emphasis> to <literal>llvm-as</literal> when assembling (<literal>.ll</literal> to <literal>.bc</literal>) LLVM code.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-llvm-llc-opt <emphasis>option</emphasis></literal>
</simpara>
<simpara>Pass <emphasis>option</emphasis> to <literal>llc</literal> when compiling (<literal>.bc</literal> to <literal>.o</literal>) LLVM code.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-llvm-opt-opt <emphasis>option</emphasis></literal>
</simpara>
<simpara>Pass <emphasis>option</emphasis> to <literal>opt</literal> when optimizing (<literal>.bc</literal> to <literal>.bc</literal>) LLVM code.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-mlb-path-map <emphasis>file</emphasis></literal>
</simpara>
<simpara>Use <emphasis>file</emphasis> as an <link linkend="MLBasisPathMap">ML Basis path map</link> to define
additional MLB path variables.  Multiple uses of <literal>-mlb-path-map</literal> and
<literal>-mlb-path-var</literal> are allowed, with variable definitions in later path
maps taking precedence over earlier ones.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-mlb-path-var <emphasis>name</emphasis> <emphasis>value</emphasis></literal>
</simpara>
<simpara>Define an additional MLB path variable.  Multiple uses of
<literal>-mlb-path-map</literal> and <literal>-mlb-path-var</literal> are allowed, with variable
definitions in later path maps taking precedence over earlier ones.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-output <emphasis>file</emphasis></literal>
</simpara>
<simpara>Specify the name of the final output file. The default name is the
input file name with its suffix removed and an appropriate, possibly
empty, suffix added.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-profile {no|alloc|count|time}</literal>
</simpara>
<simpara>Produce an executable that gathers <link linkend="Profiling">profiling</link> data.  When
such an executable is run, it produces an <literal>mlmon.out</literal> file.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-profile-branch {false|true}</literal>
</simpara>
<simpara>If true, the profiler will separately gather profiling data for each
branch of a function definition, <literal>case</literal> expression, and <literal>if</literal>
expression.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-profile-stack {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, the executable will gather profiling data for all functions
on the stack, not just the currently executing function.  See
<link linkend="ProfilingTheStack">ProfilingTheStack</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-profile-val {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, the profiler will separately gather profiling data for each
(expansive) <literal>val</literal> declaration.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-runtime <emphasis>arg</emphasis></literal>
</simpara>
<simpara>Pass argument to the runtime system via <literal>@MLton</literal>.  See
<link linkend="RunTimeOptions">RunTimeOptions</link>.  The argument will be processed before other
<literal>@MLton</literal> command line switches.  Multiple uses of <literal>-runtime</literal> are
allowed, and will pass all the arguments in order.  If the same
runtime switch occurs more than once, then the last setting will take
effect.  There is no need to supply the leading <literal>@MLton</literal> or the
trailing <literal>--</literal>; these will be supplied automatically.</simpara>
<simpara>An argument to <literal>-runtime</literal> may contain spaces, which will cause the
argument to be treated as a sequence of words by the runtime.  For
example the command line:</simpara>
<screen>mlton -runtime 'ram-slop 0.4' foo.sml</screen>
<simpara>will cause <literal>foo</literal> to run as if it had been called like:</simpara>
<screen>foo @MLton ram-slop 0.4 --</screen>
<simpara>An executable created with <literal>-runtime stop</literal> doesn&#8217;t process any
<literal>@MLton</literal> arguments.  This is useful to create an executable, e.g.,
<literal>echo</literal>, that must treat <literal>@MLton</literal> like any other command-line argument.</simpara>
<screen>% mlton -runtime stop echo.sml
% echo @MLton --
@MLton --</screen>
</listitem>
<listitem>
<simpara>
<literal>-show-basis <emphasis>file</emphasis></literal>
</simpara>
<simpara>Pretty print to <emphasis>file</emphasis> the basis defined by the input program.  See
<link linkend="ShowBasis">ShowBasis</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-show-def-use <emphasis>file</emphasis></literal>
</simpara>
<simpara>Output def-use information to <emphasis>file</emphasis>.  Each identifier that is defined
appears on a line, followed on subsequent lines by the position of
each use.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-stop {f|g|o|tc}</literal>
</simpara>
<simpara>Specify when to stop.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><literal>f</literal></simpara></entry>
<entry align="left" valign="top"><simpara>list of files on stdout (only makes sense when input is <literal>foo.mlb</literal>)</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>g</literal></simpara></entry>
<entry align="left" valign="top"><simpara>generated <literal>.c</literal> and <literal>.s</literal> files</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>o</literal></simpara></entry>
<entry align="left" valign="top"><simpara>object (<literal>.o</literal>) files</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>tc</literal></simpara></entry>
<entry align="left" valign="top"><simpara>after type checking</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>If you compile with <literal>-stop g</literal> or <literal>-stop o</literal>, you can resume compilation
by running MLton on the generated <literal>.c</literal> and <literal>.s</literal> or <literal>.o</literal> files.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-target {self|<emphasis>&#8230;</emphasis>}</literal>
</simpara>
<simpara>Generate an executable that runs on the specified platform.  The
default is <literal>self</literal>, which means to compile for the machine that MLton
is running on.  To use any other target, you must first install a
<link linkend="CrossCompiling">cross compiler</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-target-as-opt <emphasis>target</emphasis> <emphasis>option</emphasis></literal>
</simpara>
<simpara>Like <literal>-as-opt</literal>, this passes <emphasis>option</emphasis> to <literal>gcc</literal> when compliling
assembler code, except it only passes <emphasis>option</emphasis> when the target
architecture, operating system, or arch-os pair is <emphasis>target</emphasis>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-target-cc-opt <emphasis>target</emphasis> <emphasis>option</emphasis></literal>
</simpara>
<simpara>Like <literal>-cc-opt</literal>, this passes <emphasis>option</emphasis> to <literal>gcc</literal> when compiling C code,
except it only passes <emphasis>option</emphasis> when the target architecture, operating
system, or arch-os pair is <emphasis>target</emphasis>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-target-link-opt <emphasis>target</emphasis> <emphasis>option</emphasis></literal>
</simpara>
<simpara>Like <literal>-link-opt</literal>, this passes <emphasis>option</emphasis> to <literal>gcc</literal> when linking, except
it only passes <emphasis>option</emphasis> when the target architecture, operating
system, or arch-os pair is <emphasis>target</emphasis>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>-verbose {0|1|2|3}</literal>
</simpara>
<simpara>How verbose to be about what passes are running.  The default is <literal>0</literal>.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><literal>0</literal></simpara></entry>
<entry align="left" valign="top"><simpara>silent</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>1</literal></simpara></entry>
<entry align="left" valign="top"><simpara>calls to compiler, assembler, and linker</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>2</literal></simpara></entry>
<entry align="left" valign="top"><simpara>1, plus intermediate compiler passes</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>3</literal></simpara></entry>
<entry align="left" valign="top"><simpara>2, plus some data structure sizes</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CompilingWithSMLNJ">
<title>CompilingWithSMLNJ</title>
<simpara>You can compile MLton with <link linkend="SMLNJ">SML/NJ</link>, however the resulting
compiler will run much more slowly than MLton compiled by itself.  We
don&#8217;t recommend using SML/NJ as a means of
<link linkend="PortingMLton">porting MLton</link> to a new platform or bootstrapping on a
new platform.</simpara>
<simpara>If you do want to build MLton with SML/NJ, it is best to have a binary
MLton package installed.  If you don&#8217;t, here are some issues you may
encounter when you run <literal>make smlnj-mlton</literal>.</simpara>
<simpara>You will get (many copies of) the error messages:</simpara>
<screen>/bin/sh: mlton: command not found</screen>
<simpara>and</simpara>
<screen>make[2]: mlton: Command not found</screen>
<simpara>The <literal>Makefile</literal> calls <literal>mlton</literal> to determine dependencies, and can
proceed in spite of this error.</simpara>
<simpara>If you don&#8217;t have an <literal>mllex</literal> executable, you will get the error
message:</simpara>
<screen>mllex: Command not found</screen>
<simpara>Building MLton requires <literal>mllex</literal> and <literal>mlyacc</literal> executables, which are
distributed with a binary package of MLton.  The easiest solution is
to copy the front-end lexer/parser files from a different machine
(<literal>ml.grm.sml</literal>, <literal>ml.grm.sig</literal>, <literal>ml.lex.sml</literal>, <literal>mlb.grm.sig</literal>,
<literal>mlb.grm.sml</literal>).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ConcurrentML">
<title>ConcurrentML</title>
<simpara><ulink url="http://cml.cs.uchicago.edu/">Concurrent ML</ulink> is an SML concurrency
library based on synchronous message passing.  MLton has an initial
port of CML from SML/NJ, but is missing a thread-safe wrapper around
the Basis Library and event-based equivalents to <literal>IO</literal> and <literal>OS</literal>
functions.</simpara>
<simpara>All of the core CML functionality is present.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure CML: CML
structure SyncVar: SYNC_VAR
structure Mailbox: MAILBOX
structure Multicast: MULTICAST
structure SimpleRPC: SIMPLE_RPC
structure RunCML: RUN_CML</programlisting>
<simpara>The <literal>RUN_CML</literal> signature is minimal.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature RUN_CML =
   sig
      val isRunning: unit -&gt; bool
      val doit: (unit -&gt; unit) * Time.time option -&gt; OS.Process.status
      val shutdown: OS.Process.status -&gt; 'a
   end</programlisting>
<simpara>MLton&#8217;s <literal>RunCML</literal> structure does not include all of the cleanup and
logging operations of SML/NJ&#8217;s <literal>RunCML</literal> structure.  However, the
implementation does include the <literal>CML.timeOutEvt</literal> and <literal>CML.atTimeEvt</literal>
functions, and a preemptive scheduler that knows to sleep when there
are no ready threads and some threads blocked on time events.</simpara>
<simpara>Because MLton does not wrap the Basis Library for CML, the "right" way
to call a Basis Library function that is stateful is to wrap the call
with <literal>MLton.Thread.atomically</literal>.</simpara>
<section id="_usage_2">
<title>Usage</title>
<itemizedlist>
<listitem>
<simpara>
You can import the CML Library into an MLB file with:
</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<thead>
<row>
<entry align="left" valign="top">MLB file</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/cml/cml.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
If you are porting a project from SML/NJ&#8217;s <link linkend="CompilationManager">CompilationManager</link> to
MLton&#8217;s <link linkend="MLBasis">ML Basis system</link> using <literal>cm2mlb</literal>, note that the
following map is included by default:
</simpara>
<screen># CML Library
$cml                                    $(SML_LIB)/cml
$cml/cml.cm                             $(SML_LIB)/cml/cml.mlb</screen>
<simpara>This will automatically convert a <literal>$cml/cml.cm</literal> import in an input <literal>.cm</literal> file into a <literal>$(SML_LIB)/cml/cml.mlb</literal> import in the output <literal>.mlb</literal> file.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_2">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ConcurrentMLImplementation">ConcurrentMLImplementation</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="eXene">eXene</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ConcurrentMLImplementation">
<title>ConcurrentMLImplementation</title>
<simpara>Here are some notes on MLton&#8217;s implementation of <link linkend="ConcurrentML">ConcurrentML</link>.</simpara>
<simpara>Concurrent ML was originally implemented for SML/NJ.  It was ported to
MLton in the summer of 2004.  The main difference between the
implementations is that SML/NJ uses continuations to implement CML
threads, while MLton uses its underlying <link linkend="MLtonThread">thread</link>
package.  Presently, MLton&#8217;s threads are a little more heavyweight
than SML/NJ&#8217;s continuations, but it&#8217;s pretty clear that there is some
fat there that could be trimmed.</simpara>
<simpara>The implementation of CML in SML/NJ is built upon the first-class
continuations of the <literal>SMLofNJ.Cont</literal> module.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a cont
val callcc: ('a cont -&gt; 'a) -&gt; 'a
val isolate: ('a -&gt; unit) -&gt; 'a cont
val throw: 'a cont -&gt; 'a -&gt; 'b</programlisting>
<simpara>The implementation of CML in MLton is built upon the first-class
threads of the <link linkend="MLtonThread">MLtonThread</link> module.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a t
val new: ('a -&gt; unit) -&gt; 'a t
val prepare: 'a t * 'a -&gt; Runnable.t
val switch: ('a t -&gt; Runnable.t) -&gt; 'a</programlisting>
<simpara>The port is relatively straightforward, because CML always throws to a
continuation at most once.  Hence, an "abstract" implementation of
CML could be built upon first-class one-shot continuations, which map
equally well to SML/NJ&#8217;s continuations and MLton&#8217;s threads.</simpara>
<simpara>The "essence" of the port is to transform:</simpara>
<screen>callcc (fn k =&gt; ... throw k' v')</screen>
<simpara>to</simpara>
<screen>switch (fn t =&gt; ... prepare (t', v'))</screen>
<simpara>which suffices for the vast majority of the CML implementation.</simpara>
<simpara>There was only one complicated transformation: blocking multiple base
events.  In SML/NJ CML, the representation of base events is given by:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a event_status
  = ENABLED of {prio: int, doFn: unit -&gt; 'a}
  | BLOCKED of {
        transId: trans_id ref,
        cleanUp: unit -&gt; unit,
        next: unit -&gt; unit
      } -&gt; 'a
type 'a base_evt = unit -&gt; 'a event_status</programlisting>
<simpara>When synchronizing on a set of base events, which are all blocked, we
must invoke each <literal>BLOCKED</literal> function with the same <literal>transId</literal> and
<literal>cleanUp</literal> (the <literal>transId</literal> is (checked and) set to <literal>CANCEL</literal> by the
<literal>cleanUp</literal> function, which is invoked by the first enabled event; this
"fizzles" every other event in the synchronization group that later
becomes enabled).  However, each <literal>BLOCKED</literal> function is implemented by
a callcc, so that when the event is enabled, it throws back to the
point of synchronization.  Hence, the next function (which doesn&#8217;t
return) is invoked by the <literal>BLOCKED</literal> function to escape the callcc and
continue in the thread performing the synchronization.  In SML/NJ this
is implemented as follows:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun ext ([], blockFns) = callcc (fn k =&gt; let
      val throw = throw k
      val (transId, setFlg) = mkFlg()
      fun log [] = S.atomicDispatch ()
        | log (blockFn:: r) =
            throw (blockFn {
                transId = transId,
                cleanUp = setFlg,
                next = fn () =&gt; log r
              })
      in
        log blockFns; error "[log]"
      end)</programlisting>
<simpara>(Note that <literal>S.atomicDispatch</literal> invokes the continuation of the next
continuation on the ready queue.)  This doesn&#8217;t map well to the MLton
thread model.  Although it follows the</simpara>
<screen>callcc (fn k =&gt; ... throw k v)</screen>
<simpara>model, the fact that <literal>blockFn</literal> will also attempt to do</simpara>
<screen>callcc (fn k' =&gt; ... next ())</screen>
<simpara>means that the naive transformation will result in nested <literal>switch</literal>-es.</simpara>
<simpara>We need to think a little more about what this code is trying to do.
Essentially, each <literal>blockFn</literal> wants to capture this continuation, hold
on to it until the event is enabled, and continue with next; when the
event is enabled, before invoking the continuation and returning to
the synchronization point, the <literal>cleanUp</literal> and other event specific
operations are performed.</simpara>
<simpara>To accomplish the same effect in the MLton thread implementation, we
have the following:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a status =
   ENABLED of {prio: int, doitFn: unit -&gt; 'a}
 | BLOCKED of {transId: trans_id,
               cleanUp: unit -&gt; unit,
               next: unit -&gt; rdy_thread} -&gt; 'a

type 'a base = unit -&gt; 'a status

fun ext ([], blockFns): 'a =
     S.atomicSwitch
     (fn (t: 'a S.thread) =&gt;
      let
         val (transId, cleanUp) = TransID.mkFlg ()
         fun log blockFns: S.rdy_thread =
            case blockFns of
               [] =&gt; S.next ()
             | blockFn::blockFns =&gt;
                  (S.prep o S.new)
                  (fn _ =&gt; fn () =&gt;
                   let
                      val () = S.atomicBegin ()
                      val x = blockFn {transId = transId,
                                       cleanUp = cleanUp,
                                       next = fn () =&gt; log blockFns}
                   in S.switch(fn _ =&gt; S.prepVal (t, x))
                   end)
      in
         log blockFns
      end)</programlisting>
<simpara>To avoid the nested <literal>switch</literal>-es, I run the <literal>blockFn</literal> in it&#8217;s own
thread, whose only purpose is to return to the synchronization point.
This corresponds to the <literal>throw (blockFn {...})</literal> in the SML/NJ
implementation.  I&#8217;m worried that this implementation might be a
little expensive, starting a new thread for each blocked event (when
there are only multiple blocked events in a synchronization group).
But, I don&#8217;t see another way of implementing this behavior in the
MLton thread model.</simpara>
<simpara>Note that another way of thinking about what is going on is to
consider each <literal>blockFn</literal> as prepending a different set of actions to
the thread <literal>t</literal>.  It might be possible to give a
<literal>MLton.Thread.unsafePrepend</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun unsafePrepend (T r: 'a t, f: 'b -&gt; 'a): 'b t =
   let
      val t =
         case !r of
            Dead =&gt; raise Fail "prepend to a Dead thread"
          | New g =&gt; New (g o f)
          | Paused (g, t) =&gt; Paused (fn h =&gt; g (f o h), t)
   in (* r := Dead; *)
      T (ref t)
   end</programlisting>
<simpara>I have commented out the <literal>r := Dead</literal>, which would allow multiple
prepends to the same thread (i.e., not destroying the original thread
in the process).  Of course, only one of the threads could be run: if
the original thread were in the <literal>Paused</literal> state, then multiple threads
would share the underlying runtime/primitive thread.  Now, this
matches the "one-shot" nature of CML continuations/threads, but I&#8217;m
not comfortable with extending <literal>MLton.Thread</literal> with such an unsafe
operation.</simpara>
<simpara>Other than this complication with blocking multiple base events, the
port was quite routine.  (As a very pleasant surprise, the CML
implementation in SML/NJ doesn&#8217;t use any SML/NJ-isms.)  There is a
slight difference in the way in which critical sections are handled in
SML/NJ and MLton; since <literal>MLton.Thread.switch</literal> <emphasis>always</emphasis> leaves a
critical section, it is sometimes necessary to add additional
<literal>atomicBegin</literal>-s/<literal>atomicEnd</literal>-s to ensure that we remain in a critical
section after a thread switch.</simpara>
<simpara>While looking at virtually every file in the core CML implementation,
I took the liberty of simplifying things where it seemed possible; in
terms of style, the implementation is about half-way between Reppy&#8217;s
original and MLton&#8217;s.</simpara>
<simpara>Some changes of note:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>util/</literal> contains all pertinent data-structures: (functional and
imperative) queues, (functional) priority queues.  Hence, it should be
easier to switch in more efficient or real-time implementations.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>core-cml/scheduler.sml</literal>: in both implementations, this is where
most of the interesting action takes place.  I&#8217;ve made the connection
between <literal>MLton.Thread.t</literal>-s and <literal>ThreadId.thread_id</literal>-s more abstract
than it is in the SML/NJ implementation, and encapsulated all of the
<literal>MLton.Thread</literal> operations in this module.
</simpara>
</listitem>
<listitem>
<simpara>
eliminated all of the "by hand" inlining
</simpara>
</listitem>
</itemizedlist>
<section id="_future_extensions">
<title>Future Extensions</title>
<simpara>The CML documentation says the following:</simpara>
<blockquote>
<screen>CML.joinEvt: thread_id -&gt; unit event</screen>
<itemizedlist>
<listitem>
<simpara>
<literal>joinEvt tid</literal>
</simpara>
<simpara>creates an event value for synchronizing on the termination of the
thread with the ID tid.  There are three ways that a thread may
terminate: the function that was passed to spawn (or spawnc) may
return; it may call the exit function, or it may have an uncaught
exception.  Note that <literal>joinEvt</literal> does not distinguish between these
cases; it also does not become enabled if the named thread deadlocks
(even if it is garbage collected).</simpara>
</listitem>
</itemizedlist>
</blockquote>
<simpara>I believe that the <literal>MLton.Finalizable</literal> might be able to relax that
last restriction.  Upon the creation of a <literal>'a Scheduler.thread</literal>, we
could attach a finalizer to the underlying <literal>'a MLton.Thread.t</literal> that
enables the <literal>joinEvt</literal> (in the associated <literal>ThreadID.thread_id</literal>) when
the <literal>'a MLton.Thread.t</literal> becomes unreachable.</simpara>
<simpara>I don&#8217;t know why CML doesn&#8217;t have</simpara>
<screen>CML.kill: thread_id -&gt; unit</screen>
<simpara>which has a fairly simple implementation&#8201;&#8212;&#8201;setting a kill flag in the
<literal>thread_id</literal> and adjusting the scheduler to discard any killed threads
that it takes off the ready queue.  The fairness of the scheduler
ensures that a killed thread will eventually be discarded.  The
semantics are little murky for blocked threads that are killed,
though.  For example, consider a thread blocked on <literal>SyncVar.mTake mv</literal>
and a thread blocked on <literal>SyncVar.mGet mv</literal>.  If the first thread is
killed while blocked, and a third thread does <literal>SyncVar.mPut (mv, x)</literal>,
then we might expect that we&#8217;ll enable the second thread, and never
the first.  But, when only the ready queue is able to discard killed
threads, then the <literal>SyncVar.mPut</literal> could enable the first thread
(putting it on the ready queue, from which it will be discarded) and
leave the second thread blocked.  We could solve this by adjusting the
<literal>TransID.trans_id types</literal> and the "cleaner" functions to look for both
canceled transactions and transactions on killed threads.</simpara>
<simpara>John Reppy says that <link linkend="References_MarlowEtAl01">MarlowEtAl01</link> and <link linkend="References_FlattFindler04">FlattFindler04</link>
explain why <literal>CML.kill</literal> would be a bad idea.</simpara>
<simpara>Between <literal>CML.timeOutEvt</literal> and <literal>CML.kill</literal>, one could give an efficient
solution to the recent <literal>comp.lang.ml</literal> post about terminating a
function that doesn&#8217;t complete in a given time.</simpara>
<programlisting language="sml" linenumbering="unnumbered">  fun timeOut (f: unit -&gt; 'a, t: Time.time): 'a option =
    let
       val iv = SyncVar.iVar ()
       val tid = CML.spawn (fn () =&gt; SyncVar.iPut (iv, f ()))
    in
       CML.select
       [CML.wrap (CML.timeOutEvt t, fn () =&gt; (CML.kill tid; NONE)),
        CML.wrap (SyncVar.iGetEvt iv, fn x =&gt; SOME x)]
    end</programlisting>
</section>
<section id="_space_safety">
<title>Space Safety</title>
<simpara>There are some CML related posts on the MLton mailing list:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-May/">http://www.mlton.org/pipermail/mlton/2004-May/</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>that discuss concerns that SML/NJ&#8217;s implementation is not space
efficient, because multi-shot continuations can be held indefinitely
on event queues.  MLton is better off because of the one-shot nature&#8201;&#8212;&#8201;when an event enables a thread, all other copies of the thread
waiting in other event queues get turned into dead threads (of zero
size).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ConstantPropagation">
<title>ConstantPropagation</title>
<simpara><link linkend="ConstantPropagation">ConstantPropagation</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_10">
<title>Description</title>
<simpara>This is whole-program constant propagation, even through data
structures.  It also performs globalization of (small) values computed
once.</simpara>
<simpara>Uses <link linkend="Multi">Multi</link>.</simpara>
</section>
<section id="_implementation_12">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/constant-propagation.fun"><literal>constant-propagation.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_12">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Contact">
<title>Contact</title>
<section id="_mailing_lists">
<title>Mailing lists</title>
<simpara>There are three mailing lists available.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="mailto:MLton-user@mlton.org"><literal>MLton-user@mlton.org</literal></ulink>
</simpara>
<simpara>MLton user community discussion</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://lists.sourceforge.net/lists/listinfo/mlton-user">subscribe</ulink>
<ulink url="https://sourceforge.net/mailarchive/forum.php?forum_name=mlton-user">archive (SourceForge; current)</ulink>,
<ulink url="http://www.mlton.org/pipermail/mlton-user/">archive (PiperMail; through 201110)</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>
</simpara>
<simpara>MLton developer community discussion</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://lists.sourceforge.net/lists/listinfo/mlton-devel">subscribe</ulink>
<ulink url="https://sourceforge.net/mailarchive/forum.php?forum_name=mlton-devel">archive (SourceForge; current)</ulink>,
<ulink url="http://www.mlton.org/pipermail/mlton-devel/">archive (PiperMail; through 201110)</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<ulink url="mailto:MLton-commit@mlton.org"><literal>MLton-commit@mlton.org</literal></ulink>
</simpara>
<simpara>MLton code commits</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://lists.sourceforge.net/lists/listinfo/mlton-commit">subscribe</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://sourceforge.net/mailarchive/forum.php?forum_name=mlton-commit">archive (SourceForge; current)</ulink>,
<ulink url="http://www.mlton.org/pipermail/mlton-commit/">archive (PiperMail; through 201110)</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<section id="_mailing_list_policies">
<title>Mailing list policies</title>
<itemizedlist>
<listitem>
<simpara>
Both mailing lists are unmoderated.  However, the mailing lists are
configured to discard all spam, to hold all non-subscriber posts
for moderation, to accept all subscriber posts, and to admin approve
subscription requests.  Please contact
<ulink url="mailto:matthew.fluet@gmail.com">Matthew Fluet</ulink> if it appears that your
messages are being discarded as spam.
</simpara>
</listitem>
<listitem>
<simpara>
Large messages (over 256K) should not be sent.  Rather, please send
an email containing the discussion text and a link to any large files.
</simpara>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<simpara>
Discussions started on the mailing lists should stay on the mailing
lists.  Private replies may be bounced to the mailing list for the
benefit of those following the discussion.
</simpara>
</listitem>
<listitem>
<simpara>
Discussions started on
<ulink url="mailto:MLton-user@mlton.org"><literal>MLton-user@mlton.org</literal></ulink> may be migrated to
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>, particularly
when the discussion shifts from how to use MLton to how to modify
MLton (e.g., to fix a bug identified by the initial discussion).
</simpara>
</listitem>
</itemizedlist>
</section>
</section>
<section id="_irc">
<title>IRC</title>
<itemizedlist>
<listitem>
<simpara>
Some MLton developers and users are in channel <literal>#sml</literal> on <ulink url="http://freenode.net">http://freenode.net</ulink>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Contify">
<title>Contify</title>
<simpara><link linkend="Contify">Contify</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_11">
<title>Description</title>
<simpara>Contification is a compiler optimization that turns a function that
always returns to the same place into a continuation.  This exposes
control-flow information that is required by many optimizations,
including traditional loop optimizations.</simpara>
</section>
<section id="_implementation_13">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/contify.fun"><literal>contify.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_13">
<title>Details and Notes</title>
<simpara>See <link linkend="References_FluetWeeks01">Contification Using Dominators</link>.  The
intermediate language described in that paper has since evolved to the
<link linkend="SSA">SSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>; hence, the complication described in
Section 6.1 is no longer relevant.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CoreML">
<title>CoreML</title>
<simpara><link linkend="CoreML">Core ML</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from
<link linkend="AST">AST</link> by <link linkend="Elaborate">Elaborate</link>, optimized by <link linkend="CoreMLSimplify">CoreMLSimplify</link>, and
translated by <link linkend="Defunctorize">Defunctorize</link> to <link linkend="XML">XML</link>.</simpara>
<section id="_description_12">
<title>Description</title>
<simpara><link linkend="CoreML">CoreML</link> is polymorphic, higher-order, and has nested patterns.</simpara>
</section>
<section id="_implementation_14">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/core-ml/core-ml.sig"><literal>core-ml.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/core-ml/core-ml.fun"><literal>core-ml.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_2">
<title>Type Checking</title>
<simpara>The <link linkend="CoreML">CoreML</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> has no independent type
checker.</simpara>
</section>
<section id="_details_and_notes_14">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CoreMLSimplify">
<title>CoreMLSimplify</title>
<simpara>The single optimization pass for the <link linkend="CoreML">CoreML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> is controlled by the <literal>Compile</literal> functor
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/main/compile.fun"><literal>compile.fun</literal></ulink>).</simpara>
<simpara>The following optimization pass is implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="DeadCode">DeadCode</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Credits">
<title>Credits</title>
<simpara>MLton was designed and implemented by HenryCejtin,
MatthewFluet, SureshJagannathan, and <link linkend="StephenWeeks">StephenWeeks</link>.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="HenryCejtin">HenryCejtin</link> wrote the <literal>IntInf</literal> implementation, the original
 profiler, the original man pages, the <literal>.spec</literal> files for the RPMs,
 and lots of little hacks to speed stuff up.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MatthewFluet">MatthewFluet</link> implemented the X86 and AMD64 native code generators,
 ported <literal>mlprof</literal> to work with the native code generator, did a lot
 of work on the SSA optimizer, both adding new optimizations and
 improving or porting existing optimizations, updated the
 <link linkend="BasisLibrary">Basis Library</link> implementation, ported
 <link linkend="ConcurrentML">ConcurrentML</link> and <link linkend="MLNLFFI">ML-NLFFI</link> to MLton, implemented the
 <link linkend="MLBasis">ML Basis system</link>, ported MLton to 64-bit platforms,
 and currently leads the project.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SureshJagannathan">SureshJagannathan</link> implemented some early inlining and uncurrying
 optimizations.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="StephenWeeks">StephenWeeks</link> implemented most of the original version of MLton, and
 continues to keep his fingers in most every part.
</simpara>
</listitem>
</itemizedlist>
<simpara>Many people have helped us over the years.  Here is an alphabetical
list.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="JesperLouisAndersen">JesperLouisAndersen</link> sent several patches to improve the runtime on
 FreeBSD and ported MLton to run on NetBSD and OpenBSD.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="JohnnyAndersen">JohnnyAndersen</link> implemented <literal>BinIO</literal>, modified MLton so it could
 cross compile to MinGW, and provided useful discussion about
 cross-compilation.
</simpara>
</listitem>
<listitem>
<simpara>
Alexander Abushkevich extended support for OpenBSD.
</simpara>
</listitem>
<listitem>
<simpara>
Ross Bayer added the <literal>-keep ast</literal> compile-time option and experimented with
 porting the build system to CMake.
</simpara>
</listitem>
<listitem>
<simpara>
Kevin Bradley added initial support for <link linkend="SuccessorML">SuccessorML</link> features.
</simpara>
</listitem>
<listitem>
<simpara>
Bryan Camp added <literal>-disable-pass _regex_</literal> and <literal>enable-pass _regex_</literal> compile
 options to generalize <literal>-drop-pass _regex_</literal> and added <literal>Array_copyArray</literal> and
 <literal>Array_copyVector</literal> primitives.
</simpara>
</listitem>
<listitem>
<simpara>
Jason Carr added a parser combinator library and a parser for the <link linkend="SXML">SXML</link>
 IR, extended compilation to start with a <literal>.sxml</literal> file, and experimented with
 alternate control-flow analyses for <link linkend="ClosureConvert">closure conversion</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Christopher Cramer contributed support for additional
 <literal>Posix.ProcEnv.sysconf</literal> variables, performance improvements for
 <literal>String.concatWith</literal>, and Debian packaging.
</simpara>
</listitem>
<listitem>
<simpara>
Alain Deutsch and
 <ulink url="http://www.polyspace.com/">PolySpace Technologies</ulink> provided many bug
 fixes and runtime system improvements, code to help the Sparc/Solaris
 port, and funded a number of improvements to MLton.
</simpara>
</listitem>
<listitem>
<simpara>
Armando Doval updated <literal>mlnlffigen</literal> to warn and skip functions with
 <literal>struct</literal>/<literal>union</literal> arguments.
</simpara>
</listitem>
<listitem>
<simpara>
Martin Elsman provided helpful discussions in the development of
 the <link linkend="MLBasis">ML Basis system</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Brent Fulgham ported MLton most of the way to MinGW.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="AdamGoode">AdamGoode</link> provided a script to build the PDF MLton Guide and
 maintains the
 <ulink url="https://admin.fedoraproject.org/pkgdb/acls/name/mlton">Fedora</ulink>
 packages.
</simpara>
</listitem>
<listitem>
<simpara>
Simon Helsen provided bug reports, suggestions, and helpful
 discussions.
</simpara>
</listitem>
<listitem>
<simpara>
Joe Hurd provided useful discussion and feedback on source-level
 profiling.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="VesaKarvonen">VesaKarvonen</link> contributed <literal>esml-mode.el</literal> and <literal>esml-mlb-mode.el</literal> (see <link linkend="Emacs">Emacs</link>),
 contributed patches for improving match warnings,
 contributed <literal>esml-du-mlton.el</literal> and extended def-use output to include types of variable definitions (see <link linkend="EmacsDefUseMode">EmacsDefUseMode</link>), and
 improved constant folding of floating-point operations.
</simpara>
</listitem>
<listitem>
<simpara>
Richard Kelsey provided helpful discussions.
</simpara>
</listitem>
<listitem>
<simpara>
Ville Laurikari ported MLton to IA64/HPUX, HPPA/HPUX, PowerPC/AIX, PowerPC64/AIX.
</simpara>
</listitem>
<listitem>
<simpara>
Brian Leibig implemented the <link linkend="LLVMCodegen">LLVMCodegen</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Geoffrey Mainland helped with FreeBSD packaging.
</simpara>
</listitem>
<listitem>
<simpara>
Eric McCorkle ported MLton to Intel Mac.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TomMurphy">TomMurphy</link> wrote the original version of <literal>MLton.Syslog</literal> as part
 of his <literal>mlftpd</literal> project, and has sent many useful bug reports and
 suggestions.
</simpara>
</listitem>
<listitem>
<simpara>
Michael Neumann helped to patch the runtime to compile under
 FreeBSD.
</simpara>
</listitem>
<listitem>
<simpara>
Barak Pearlmutter built the original
 <ulink url="http://packages.debian.org/mlton">Debian package</ulink> for MLton, and
 helped us to take over the process.
</simpara>
</listitem>
<listitem>
<simpara>
Filip Pizlo ported MLton to (PowerPC) Darwin.
</simpara>
</listitem>
<listitem>
<simpara>
Vedant Raiththa extended the <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> with support for
 <literal>pure</literal> and <literal>impure</literal> attributes to <literal>_import</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Krishna Ravikumar added initial support for vector expressions and the
 <literal>Vector_vector</literal> primitive.
</simpara>
</listitem>
<listitem>
<simpara>
John Reppy assisted in porting MLton to Intel Mac.
</simpara>
</listitem>
<listitem>
<simpara>
Sam Rushing ported MLton to FreeBSD.
</simpara>
</listitem>
<listitem>
<simpara>
Rob Simmons refactored the array and vector implementation in the
 <link linkend="BasisLibrary">Basis Library:</link> into a primitive implementation (using
 <literal>SeqInt.int</literal> for indexing) and a wrapper implementation (using the default
 <literal>Int.int</literal> for indexing).
</simpara>
</listitem>
<listitem>
<simpara>
Jeffrey Mark Siskind provided helpful discussions and inspiration
 with his Stalin Scheme compiler.
</simpara>
</listitem>
<listitem>
<simpara>
Matthew Surawski added <link linkend="LoopUnroll">LoopUnroll</link> and <link linkend="LoopUnswitch">LoopUnswitch</link> SSA optimizations.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="WesleyTerpstra">WesleyTerpstra</link> added support for <literal>MLton.Process.create</literal>, made
 a number of contributions to the <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link>,
 contributed a number of runtime system patches,
 added support for compiling to a <link linkend="LibrarySupport">C library</link>,
 ported MLton to <ulink url="http://mingw.org">MinGW</ulink> and all <ulink url="http://packages.debian.org/search?keywords=mlton&amp;searchon=names&amp;suite=all&amp;section=all">Debian</ulink> supported architectures with <link linkend="CrossCompiling">cross-compiling</link> support,
 and maintains the <ulink url="http://packages.debian.org/search?keywords=mlton&amp;searchon=names&amp;suite=all&amp;section=all">Debian</ulink> and <ulink url="http://mingw.org">MinGW</ulink> packages.
</simpara>
</listitem>
<listitem>
<simpara>
Maksim Yegorov added rudimentary support for <literal>./configure</literal> and other
 improvements to the build system and implemented the <link linkend="ShareZeroVec">ShareZeroVec</link> SSA
 optimization.
</simpara>
</listitem>
<listitem>
<simpara>
Luke Ziarek assisted in porting MLton to (PowerPC) Darwin.
</simpara>
</listitem>
</itemizedlist>
<simpara>We have also benefited from other software development tools and
used code from other sources.</simpara>
<itemizedlist>
<listitem>
<simpara>
MLton was developed using
 <link linkend="SMLNJ">Standard ML of New Jersey</link> and the
 <link linkend="CompilationManager">Compilation Manager (CM)</link>
</simpara>
</listitem>
<listitem>
<simpara>
MLton&#8217;s lexer (<literal>mlton/frontend/ml.lex</literal>), parser
 (<literal>mlton/frontend/ml.grm</literal>), and precedence-parser
 (<literal>mlton/elaborate/precedence-parse.fun</literal>) are modified versions of
 code from SML/NJ.
</simpara>
</listitem>
<listitem>
<simpara>
The MLton <link linkend="BasisLibrary">Basis Library</link> implementation of
 conversions between binary and decimal representations of reals uses
 David Gay&#8217;s <ulink url="http://www.netlib.org/fp/">gdtoa</ulink> library.
</simpara>
</listitem>
<listitem>
<simpara>
The MLton <link linkend="BasisLibrary">Basis Library</link> implementation uses
 modified versions of  portions of the the SML/NJ Basis Library
 implementation modules <literal>OS.IO</literal>, <literal>Posix.IO</literal>, <literal>Process</literal>,
 and <literal>Unix</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
The MLton <link linkend="BasisLibrary">Basis Library</link> implementation uses
 modified versions of portions of the <link linkend="MLKit">ML Kit</link> Version 4.1.4
 Basis Library implementation modules <literal>Path</literal>, <literal>Time</literal>, and
 <literal>Date</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Many of the benchmarks come from the SML/NJ benchmark suite.
</simpara>
</listitem>
<listitem>
<simpara>
Many of the regression tests come from the ML Kit Version 4.1.4
 distribution, which borrowed them from the
 <ulink url="http://www.dina.kvl.dk/%7Esestoft/mosml.html">Moscow ML</ulink> distribution.
</simpara>
</listitem>
<listitem>
<simpara>
MLton uses the <ulink url="http://www.gnu.org/software/gmp/gmp.html">GNU multiprecision library</ulink> for its implementation of <literal>IntInf</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
MLton&#8217;s implementation of <link linkend="MLLex">mllex</link>, <link linkend="MLYacc">mlyacc</link>,
 the <link linkend="CKitLibrary">ckit Library</link>,
 the <link linkend="MLLPTLibrary">ML-LPT Library</link>,
 the <link linkend="MLRISCLibrary">MLRISC Library</link>,
 the <link linkend="SMLNJLibrary">SML/NJ Library</link>,
 <link linkend="ConcurrentML">Concurrent ML</link>,
 mlnlffigen and <link linkend="MLNLFFI">ML-NLFFI</link>
 are modified versions of code from SML/NJ.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="CrossCompiling">
<title>CrossCompiling</title>
<simpara>MLton&#8217;s <literal>-target</literal> flag directs MLton to cross compile an application
for another platform.  By default, MLton is only able to compile for
the machine it is running on.  In order to use MLton as a cross
compiler, you need to do two things.</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
Install the GCC cross-compiler tools on the host so that GCC can
compile to the target.
</simpara>
</listitem>
<listitem>
<simpara>
Cross compile the MLton runtime system to build the runtime
libraries for the target.
</simpara>
</listitem>
</orderedlist>
<simpara>To make the terminology clear, we refer to the <emphasis>host</emphasis> as the machine
MLton is running on and the <emphasis>target</emphasis> as the machine that MLton is
compiling for.</simpara>
<simpara>To build a GCC cross-compiler toolset on the host, you can use the
script <literal>bin/build-cross-gcc</literal>, available in the MLton sources, as a
template.  The value of the <literal>target</literal> variable in that script is
important, since that is what you will pass to MLton&#8217;s <literal>-target</literal> flag.
Once you have the toolset built, you should be able to test it by
cross compiling a simple hello world program on your host machine.</simpara>
<screen>% gcc -b i386-pc-cygwin -o hello-world hello-world.c</screen>
<simpara>You should now be able to run <literal>hello-world</literal> on the target machine, in
this case, a Cygwin machine.</simpara>
<simpara>Next, you must cross compile the MLton runtime system and inform MLton
of the availability of the new target.  The script <literal>bin/add-cross</literal>
from the MLton sources will help you do this.  Please read the
comments at the top of the script.  Here is a sample run adding a
Solaris cross compiler.</simpara>
<screen>% add-cross sparc-sun-solaris sun blade
Making runtime.
Building print-constants executable.
Running print-constants on blade.</screen>
<simpara>Running <literal>add-cross</literal> uses <literal>ssh</literal> to compile the runtime on the target
machine and to create <literal>print-constants</literal>, which prints out all of the
constants that MLton needs in order to implement the
<link linkend="BasisLibrary">Basis Library</link>.  The script runs <literal>print-constants</literal> on
the target machine (<literal>blade</literal> in this case), and saves the output.</simpara>
<simpara>Once you have done all this, you should be able to cross compile SML
applications.  For example,</simpara>
<screen>mlton -target i386-pc-cygwin hello-world.sml</screen>
<simpara>will create <literal>hello-world</literal>, which you should be able to run from a
Cygwin shell on your Windows machine.</simpara>
<section id="_cross_compiling_alternatives">
<title>Cross-compiling alternatives</title>
<simpara>Building and maintaining cross-compiling <literal>gcc</literal>'s is complex.  You may
find it simpler to use <literal>mlton -keep g</literal> to generate the files on the
host, then copy the files to the target, and then use <literal>gcc</literal> or <literal>mlton</literal>
on the target to compile the files.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="CVS">
<title>CVS</title>
<simpara><ulink url="http://www.gnu.org/software/cvs/">CVS</ulink> (Concurrent Versions System) is
a version control system. The MLton project used CVS to maintain its
<link linkend="Sources">source code</link>, but switched to <link linkend="Subversion">Subversion</link> on 20050730.</simpara>
<simpara>Here are some online CVS resources.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://cvsbook.red-bean.com/">Open Source Development with CVS</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="DeadCode">
<title>DeadCode</title>
<simpara><link linkend="DeadCode">DeadCode</link> is an optimization pass for the <link linkend="CoreML">CoreML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="CoreMLSimplify">CoreMLSimplify</link>.</simpara>
<section id="_description_13">
<title>Description</title>
<simpara>This pass eliminates declarations from the
<link linkend="BasisLibrary">Basis Library</link> not needed by the user program.</simpara>
</section>
<section id="_implementation_15">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/core-ml/dead-code.sig"><literal>dead-code.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/core-ml/dead-code.fun"><literal>dead-code.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_15">
<title>Details and Notes</title>
<simpara>In order to compile small programs rapidly, a pass of dead code
elimination is run in order to eliminate as much of the Basis Library
as possible.  The dead code elimination algorithm used is not safe in
general, and only works because the Basis Library implementation has
special properties:</simpara>
<itemizedlist>
<listitem>
<simpara>
it terminates
</simpara>
</listitem>
<listitem>
<simpara>
it performs no I/O
</simpara>
</listitem>
</itemizedlist>
<simpara>The dead code elimination includes the minimal set of
declarations from the Basis Library so that there are no free
variables in the user program (or remaining Basis Library
implementation).  It has a special hack to include all
bindings of the form:</simpara>
<programlisting language="sml" linenumbering="unnumbered"> val _ = ...</programlisting>
<simpara>There is an <link linkend="MLBasisAnnotations">ML Basis annotation</link>,
<literal>deadCode true</literal>, that governs which code is subject to this unsafe
dead-code elimination.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="DeepFlatten">
<title>DeepFlatten</title>
<simpara><link linkend="DeepFlatten">DeepFlatten</link> is an optimization pass for the <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSA2Simplify">SSA2Simplify</link>.</simpara>
<section id="_description_14">
<title>Description</title>
<simpara>This pass flattens into mutable fields of objects and into vectors.</simpara>
<simpara>For example, an <literal>(int * int) ref</literal> is represented by a 2 word
object, and an <literal>(int * int) array</literal> contains pairs of <literal>int</literal>-s,
rather than pointers to pairs of <literal>int</literal>-s.</simpara>
</section>
<section id="_implementation_16">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/deep-flatten.fun"><literal>deep-flatten.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_16">
<title>Details and Notes</title>
<simpara>There are some performance issues with the deep flatten pass, where it
consumes an excessive amount of memory.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2005-April/026990.html">http://www.mlton.org/pipermail/mlton/2005-April/026990.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2010-June/001626.html">http://www.mlton.org/pipermail/mlton-user/2010-June/001626.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2010-December/030876.html">http://www.mlton.org/pipermail/mlton/2010-December/030876.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>A number of applications require compilation with
<literal>-disable-pass deepFlatten</literal> to avoid exceeding available memory.  It is
often asked whether the deep flatten pass usually has a significant
impact on performance.  The standard benchmark suite was run with and
without the deep flatten pass enabled when the pass was first
introduced:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-August/025760.html">http://www.mlton.org/pipermail/mlton/2004-August/025760.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>The conclusion is that it does not have a significant impact.
However, these are micro benchmarks; other applications may derive
greater benefit from the pass.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="DefineTypeBeforeUse">
<title>DefineTypeBeforeUse</title>
<simpara><link linkend="StandardML">Standard ML</link> requires types to be defined before they are
used.  Because of type inference, the use of a type can be implicit;
hence, this requirement is more subtle than it might appear.  For
example, the following program is not type correct, because the type
of <literal>r</literal> is <literal>t option ref</literal>, but <literal>t</literal> is defined after <literal>r</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val r = ref NONE
datatype t = A | B
val () = r := SOME A</programlisting>
<simpara>MLton reports the following error, indicating that the type defined on
line 2 is used on line 1.</simpara>
<screen>Error: z.sml 3.10-3.20.
  Function applied to incorrect argument.
    expects: _ * [???] option
    but got: _ * [t] option
    in: := (r, SOME A)
    note: type would escape its scope: t
    escape from: z.sml 2.10-2.10
    escape to: z.sml 1.1-1.16
Warning: z.sml 1.5-1.5.
  Type of variable was not inferred and could not be generalized: r.
    type: ??? option ref
    in: val r = ref NONE</screen>
<simpara>While the above example is benign, the following example shows how to
cast an integer to a function by (implicitly) using a type before it
is defined.  In the example, the ref cell <literal>r</literal> is of type
<literal>t option ref</literal>, where <literal>t</literal> is defined <emphasis>after</emphasis> <literal>r</literal>, as a parameter to
functor <literal>F</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val r = ref NONE
functor F (type t
           val x: t) =
   struct
      val () = r := SOME x
      fun get () = valOf (!r)
   end
structure S1 = F (type t = unit -&gt; unit
                  val x = fn () =&gt; ())
structure S2 = F (type t = int
                  val x = 13)
val () = S1.get () ()</programlisting>
<simpara>MLton reports the following error.</simpara>
<screen>Warning: z.sml 1.5-1.5.
  Type of variable was not inferred and could not be generalized: r.
    type: ??? option ref
    in: val r = ref NONE
Error: z.sml 5.16-5.26.
  Function applied to incorrect argument.
    expects: _ * [???] option
    but got: _ * [t] option
    in: := (r, SOME x)
    note: type would escape its scope: t
    escape from: z.sml 2.17-2.17
    escape to: z.sml 1.1-1.16
Warning: z.sml 6.11-6.13.
  Type of variable was not inferred and could not be generalized: get.
    type: unit -&gt; ???
    in: fun get () = (valOf (! r))
Error: z.sml 12.10-12.18.
  Function not of arrow type.
    function: [unit]
    in: (S1.get ()) ()</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="DefinitionOfStandardML">
<title>DefinitionOfStandardML</title>
<simpara><link linkend="References_MilnerEtAl97">The Definition of Standard ML (Revised)</link> is a
terse and formal specification of <link linkend="StandardML">Standard ML</link>'s syntax
and semantics.  The language specified by this book is often referred
to as SML 97. You can check its syntax
<ulink url="http://www.mpi-sws.org/~rossberg/sml.html">grammar</ulink> online (thanks to
Andreas Rossberg).</simpara>
<simpara><link linkend="References_MilnerEtAl90">The Definition of Standard ML</link> is an older
version of the definition, published in 1990. The accompanying
<link linkend="References_MilnerTofte91">Commentary</link> introduces and explains the notation
and approach. The same notation is used in the SML 97 definition, so it
is worth keeping the older definition and its commentary at hand if you
intend a close study of the definition.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Defunctorize">
<title>Defunctorize</title>
<simpara><link linkend="Defunctorize">Defunctorize</link> is a translation pass from the <link linkend="CoreML">CoreML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="XML">XML</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_15">
<title>Description</title>
<simpara>This pass converts a <link linkend="CoreML">CoreML</link> program to an <link linkend="XML">XML</link> program by
performing:</simpara>
<itemizedlist>
<listitem>
<simpara>
linearization
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MatchCompile">MatchCompile</link>
</simpara>
</listitem>
<listitem>
<simpara>
polymorphic <literal>val</literal> dec expansion
</simpara>
</listitem>
<listitem>
<simpara>
<literal>datatype</literal> lifting (to the top-level)
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_implementation_17">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/defunctorize/defunctorize.sig"><literal>defunctorize.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/defunctorize/defunctorize.fun"><literal>defunctorize.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_17">
<title>Details and Notes</title>
<simpara>This pass is grossly misnamed and does not perform defunctorization.</simpara>
<section id="_datatype_lifting">
<title>Datatype Lifting</title>
<simpara>This pass moves all <literal>datatype</literal> declarations to the top level.</simpara>
<simpara><link linkend="StandardML">Standard ML</link> <literal>datatype</literal> declarations can contain type
variables that are not bound in the declaration itself.  For example,
the following program is valid.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun 'a f (x: 'a) =
   let
      datatype 'b t = T of 'a * 'b
      val y: int t = T (x, 1)
   in
      13
   end</programlisting>
<simpara>Unfortunately, the <literal>datatype</literal> declaration can not be immediately moved
to the top level, because that would leave <literal>'a</literal> free.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'b t = T of 'a * 'b
fun 'a f (x: 'a) =
   let
      val y: int t = T (x, 1)
   in
      13
   end</programlisting>
<simpara>In order to safely move `datatype`s, this pass must close them, as
well as add any free type variables as extra arguments to the type
constructor.  For example, the above program would be translated to
the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype ('a, 'b) t = T of 'a * 'b
fun 'a f (x: 'a) =
   let
      val y: ('a * int) t = T (x, 1)
   in
      13
   end</programlisting>
</section>
</section>
<section id="_historical_notes">
<title>Historical Notes</title>
<simpara>The <link linkend="Defunctorize">Defunctorize</link> pass originally eliminated
<link linkend="StandardML">Standard ML</link> functors by duplicating their body at each
application.  These duties have been adopted by the <link linkend="Elaborate">Elaborate</link>
pass.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Developers">
<title>Developers</title>
<simpara>Here is a picture of the MLton team at a meeting in Chicago in August
2003.  From left to right we have:</simpara>
<informaltable
frame="none"
rowsep="1" colsep="1"
>
<tgroup cols="1">
<colspec colname="col_1" colwidth="100*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><link linkend="StephenWeeks">StephenWeeks</link>&#8201;&#8212;&#8201;<link linkend="MatthewFluet">MatthewFluet</link>&#8201;&#8212;&#8201;<link linkend="HenryCejtin">HenryCejtin</link>&#8201;&#8212;&#8201;<link linkend="SureshJagannathan">SureshJagannathan</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<informalfigure>
<mediaobject>
  <imageobject>
  <imagedata fileref="Developers.attachments/team.jpg" align="center"/>
  </imageobject>
  <textobject><phrase>Developers.attachments/team.jpg</phrase></textobject>
</mediaobject>
</informalfigure>
<simpara>Also see the <link linkend="Credits">Credits</link> for a list of specific contributions.</simpara>
<section id="_developers_list">
<title>Developers list</title>
<simpara>A number of people read the developers mailing list,
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>, and make
contributions there.  Here&#8217;s a list of those who have a page here.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="AndreiFormiga">AndreiFormiga</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="JesperLouisAndersen">JesperLouisAndersen</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="JohnnyAndersen">JohnnyAndersen</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MichaelNorrish">MichaelNorrish</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MikeThomas">MikeThomas</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RayRacine">RayRacine</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="WesleyTerpstra">WesleyTerpstra</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="VesaKarvonen">VesaKarvonen</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Development">
<title>Development</title>
<simpara>This page is the central point for MLton development.</simpara>
<itemizedlist>
<listitem>
<simpara>
Access the <link linkend="Sources">Sources</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Check the current <ulink url="https://github.com/MLton/mlton/blob/master/CHANGELOG.adoc"><literal>CHANGELOG.adoc</literal></ulink> or recent <ulink url="https://github.com/MLton/mlton/commits/master">commits</ulink>.
</simpara>
</listitem>
<listitem>
<simpara>
Open <ulink url="https://github.com/MLton/mlton/issues">Issues</ulink>.
</simpara>
</listitem>
<listitem>
<simpara>
Ideas for <link linkend="Projects">Projects</link> to improve MLton.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Developers">Developers</link> that are or have been involved in the project.
</simpara>
</listitem>
</itemizedlist>
<section id="_notes">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CompilerOverview">CompilerOverview</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CompilingWithSMLNJ">CompilingWithSMLNJ</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CrossCompiling">CrossCompiling</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="License">License</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="NeedsReview">NeedsReview</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PortingMLton">PortingMLton</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ReleaseChecklist">ReleaseChecklist</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SelfCompiling">SelfCompiling</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Documentation">
<title>Documentation</title>
<simpara>Documentation is available on the following topics.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="StandardML">Standard ML</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="BasisLibrary">Basis Library</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Libraries">Additional libraries</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="Installation">Installing MLton</link>
</simpara>
</listitem>
<listitem>
<simpara>
Using MLton
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ForeignFunctionInterface">Foreign function interface (FFI)</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ManualPage">Manual page</link> (<link linkend="CompileTimeOptions">compile-time options</link> <link linkend="RunTimeOptions">run-time options</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasis">ML Basis system</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonStructure">MLton structure</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PlatformSpecificNotes">Platform-specific notes</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Profiling">Profiling</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TypeChecking">Type checking</link>
</simpara>
</listitem>
<listitem>
<simpara>
Help for porting from <link linkend="SMLNJ">SML/NJ</link> to MLton.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
About MLton
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Credits">Credits</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Drawbacks">Drawbacks</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Features">Features</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="History">History</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="License">License</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Talk">Talk</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="WishList">WishList</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLLex">MLLex</link> (<ulink url="guide/Documentation.attachments/mllex.pdf"><literal>mllex.pdf</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLYacc">MLYacc</link> (<ulink url="guide/Documentation.attachments/mlyacc.pdf"><literal>mlyacc.pdf</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLNLFFIGen">MLNLFFIGen</link> (<ulink url="guide/Documentation.attachments/mlyacc.pdf"><literal>mlyacc.pdf</literal></ulink>)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="References">References</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Drawbacks">
<title>Drawbacks</title>
<simpara>MLton has several drawbacks due to its use of whole-program
compilation.</simpara>
<itemizedlist>
<listitem>
<simpara>
Large compile-time memory requirement.
</simpara>
<simpara>Because MLton performs whole-program analysis and optimization,
compilation requires a large amount of memory.  For example, compiling
MLton (over 140K lines) requires at least 512M RAM.</simpara>
</listitem>
<listitem>
<simpara>
Long compile times.
</simpara>
<simpara>Whole-program compilation can take a long time.  For example,
compiling MLton (over 140K lines) on a 1.6GHz machine takes five to
ten minutes.</simpara>
</listitem>
<listitem>
<simpara>
No interactive top level.
</simpara>
<simpara>Because of whole-program compilation, MLton does not provide an
interactive top level.  In particular, it does not implement the
optional <link linkend="BasisLibrary">Basis Library</link> function <literal>use</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Eclipse">
<title>Eclipse</title>
<simpara><ulink url="http://eclipse.org/">Eclipse</ulink> is an open, extensible IDE.</simpara>
<simpara><ulink url="http://www.cse.iitd.ernet.in/%7Ecsu02132/mldev/">ML-Dev</ulink> is a plug-in
for Eclipse, based on <link linkend="SMLNJ">SML/NJ</link>.</simpara>
<simpara>There has been some talk on the MLton mailing list about adding
support to Eclipse for MLton/SML, and in particular, using
<ulink url="http://eclipsefp.sourceforge.net/">http://eclipsefp.sourceforge.net/</ulink>.  We are unaware of any progress
along those lines.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Elaborate">
<title>Elaborate</title>
<simpara><link linkend="Elaborate">Elaborate</link> is a translation pass from the <link linkend="AST">AST</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="CoreML">CoreML</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_16">
<title>Description</title>
<simpara>This pass performs type inference and type checking according to the
<link linkend="DefinitionOfStandardML">Definition</link>.  It also defunctorizes the
program, eliminating all module-level constructs.</simpara>
</section>
<section id="_implementation_18">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate.sig"><literal>elaborate.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate.fun"><literal>elaborate.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-env.sig"><literal>elaborate-env.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-env.fun"><literal>elaborate-env.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-modules.sig"><literal>elaborate-modules.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-modules.fun"><literal>elaborate-modules.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-core.sig"><literal>elaborate-core.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/elaborate-core.fun"><literal>elaborate-core.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/tree/master/mlton/elaborate"><literal>elaborate</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_18">
<title>Details and Notes</title>
<simpara>At the modules level, the <link linkend="Elaborate">Elaborate</link> pass:</simpara>
<itemizedlist>
<listitem>
<simpara>
elaborates signatures with interfaces (see
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/interface.sig"><literal>interface.sig</literal></ulink> and
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/interface.fun"><literal>interface.fun</literal></ulink>)
</simpara>
<simpara>The main trick is to use disjoint sets to efficiently handle sharing
of tycons and of structures and then to copy signatures as dags rather
than as trees.</simpara>
</listitem>
<listitem>
<simpara>
checks functors at the point of definition, using functor summaries
to speed up checking of functor applications.
</simpara>
<simpara>When a functor is first type checked, we keep track of the dummy
argument structure and the dummy result structure, as well as all the
tycons that were created while elaborating the body.  Then, if we
later need to type check an application of the functor (as opposed to
defunctorize an application), we pair up tycons in the dummy argument
structure with the actual argument structure and then replace the
dummy tycons with the actual tycons in the dummy result structure,
yielding the actual result structure.  We also generate new tycons for
all the tycons that we created while originally elaborating the body.</simpara>
</listitem>
<listitem>
<simpara>
handles opaque signature constraints.
</simpara>
<simpara>This is implemented by building a dummy structure realized from the
signature, just as we would for a functor argument when type checking
a functor.  The dummy structure contains exactly the type information
that is in the signature, which is what opacity requires.  We then
replace the variables (and constructors) in the dummy structure with
the corresponding variables (and constructors) from the actual
structure so that the translation to <link linkend="CoreML">CoreML</link> uses the right stuff.
For each tycon in the dummy structure, we keep track of the
corresponding type structure in the actual structure.  This is used
when producing the <link linkend="CoreML">CoreML</link> types (see <literal>expandOpaque</literal> in
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/type-env.sig"><literal>type-env.sig</literal></ulink> and
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/type-env.fun"><literal>type-env.fun</literal></ulink>).</simpara>
<simpara>Then, within each <literal>structure</literal> or <literal>functor</literal> body, for each declaration
(<literal>&lt;dec&gt;</literal> in the <link linkend="StandardML">Standard ML</link> grammar), the <link linkend="Elaborate">Elaborate</link>
pass does three steps:</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
<link linkend="ScopeInference">ScopeInference</link>
</simpara>
</listitem>
<listitem>
<simpara>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="PrecedenceParse">PrecedenceParse</link>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>_{ex,im}port</literal> expansion
</simpara>
</listitem>
<listitem>
<simpara>
profiling insertion
</simpara>
</listitem>
<listitem>
<simpara>
unification
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Overloaded {constant, function, record pattern} resolution
</simpara>
</listitem>
</orderedlist>
</listitem>
</itemizedlist>
<section id="_defunctorization">
<title>Defunctorization</title>
<simpara>The <link linkend="Elaborate">Elaborate</link> pass performs a number of duties historically
assigned to the <link linkend="Defunctorize">Defunctorize</link> pass.</simpara>
<simpara>As part of the <link linkend="Elaborate">Elaborate</link> pass, all module level constructs
(<literal>open</literal>, <literal>signature</literal>, <literal>structure</literal>, <literal>functor</literal>, long identifiers) are
removed.  This works because the <link linkend="Elaborate">Elaborate</link> pass assigns a unique
name to every type and variable in the program.  This also allows the
<link linkend="Elaborate">Elaborate</link> pass to eliminate <literal>local</literal> declarations, which are purely
for namespace management.</simpara>
</section>
</section>
<section id="_examples">
<title>Examples</title>
<simpara>Here are a number of examples of elaboration.</simpara>
<itemizedlist>
<listitem>
<simpara>
All variables bound in <literal>val</literal> declarations are renamed.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x = 13
val y = x</programlisting>
<screen>val x_0 = 13
val y_0 = x_0</screen>
</listitem>
<listitem>
<simpara>
All variables in <literal>fun</literal> declarations are renamed.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f x = g x
and g y = f y</programlisting>
<screen>fun f_0 x_0 = g_0 x_0
and g_0 y_0 = f_0 y_0</screen>
</listitem>
<listitem>
<simpara>
Type abbreviations are removed, and the abbreviation is expanded
wherever it is used.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a u = int * 'a
type 'b t = 'b u * real
fun f (x : bool t) = x</programlisting>
<screen>fun f_0 (x_0 : (int * bool) * real) = x_0</screen>
</listitem>
<listitem>
<simpara>
Exception declarations create a new constructor and rename the type.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">type t = int
exception E of t * real</programlisting>
<screen>exception E_0 of int * real</screen>
</listitem>
<listitem>
<simpara>
The type and value constructors in datatype declarations are renamed.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A of int | B of real * t</programlisting>
<screen>datatype t_0 = A_0 of int | B_0 of real * t_0</screen>
</listitem>
<listitem>
<simpara>
Local declarations are moved to the top-level.  The environment
keeps track of the variables in scope.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x = 13
local val x = 14
in val y = x
end
val z = x</programlisting>
<screen>val x_0 = 13
val x_1 = 14
val y_0 = x_1
val z_0 = x_0</screen>
</listitem>
<listitem>
<simpara>
Structure declarations are eliminated, with all declarations moved
to the top level.  Long identifiers are renamed.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S =
   struct
      type t = int
      val x : t = 13
   end
val y : S.t = S.x</programlisting>
<screen>val x_0 : int = 13
val y_0 : int = x_0</screen>
</listitem>
<listitem>
<simpara>
Open declarations are eliminated.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x = 13
val y = 14
structure S =
   struct
     val x = 15
   end
open S
val z = x + y</programlisting>
<screen>val x_0 = 13
val y_0 = 14
val x_1 = 15
val z_0 = x_1 + y_0</screen>
</listitem>
<listitem>
<simpara>
Functor declarations are eliminated, and the body of a functor is
duplicated wherever the functor is applied.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor F(val x : int) =
   struct
     val y = x
   end
structure F1 = F(val x = 13)
structure F2 = F(val x = 14)
val z = F1.y + F2.y</programlisting>
<screen>val x_0 = 13
val y_0 = x_0
val x_1 = 14
val y_1 = x_1
val z_0 = y_0 + y_1</screen>
</listitem>
<listitem>
<simpara>
Signature constraints are eliminated.  Note that signatures do
affect how subsequent variables are renamed.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val y = 13
structure S : sig
                 val x : int
              end =
   struct
      val x = 14
      val y = x
   end
open S
val z = x + y</programlisting>
<screen>val y_0 = 13
val x_0 = 14
val y_1 = x_0
val z_0 = x_0 + y_0</screen>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Emacs">
<title>Emacs</title>
<section id="_sml_modes">
<title>SML modes</title>
<simpara>There are a few Emacs modes for SML.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>sml-mode</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.xemacs.org/Documentation/packages/html/sml-mode_3.html">http://www.xemacs.org/Documentation/packages/html/sml-mode_3.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.smlnj.org/doc/Emacs/sml-mode.html">http://www.smlnj.org/doc/Emacs/sml-mode.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.iro.umontreal.ca/%7Emonnier/elisp/">http://www.iro.umontreal.ca/%7Emonnier/elisp/</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/ide/emacs/mlton.el"><literal>mlton.el</literal></ulink> contains the Emacs lisp that <link linkend="StephenWeeks">StephenWeeks</link> uses to interact with MLton (in addition to using <literal>sml-mode</literal>).
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://primate.net/%7Eitz/mindent.tar">http://primate.net/%7Eitz/mindent.tar</ulink>, developed by Ian Zimmerman, who writes:
</simpara>
<blockquote>
<simpara>Unlike the widespread <literal>sml-mode.el</literal> it doesn&#8217;t try to indent code
based on ML syntax.  I gradually got skeptical about this approach
after writing the initial indentation support for caml mode and
watching it bloat insanely as the language added new features.  Also,
any such attempts that I know of impose a particular coding style, or
at best a choice among a limited set of styles, which I now oppose.
Instead my mode is based on a generic package which provides manual
bindable commands for common indentation operations (example: indent
the current line under the n-th occurrence of a particular character
in the previous non-blank line).</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_mlb_modes">
<title>MLB modes</title>
<simpara>There is a mode for editing <link linkend="MLBasis">ML Basis</link> files.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/ide/emacs/esml-mlb-mode.el"><literal>esml-mlb-mode.el</literal></ulink> (plus other files)
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_definitions_and_uses">
<title>Definitions and uses</title>
<simpara>There is a mode that supports the precise def-use information that
MLton can output.  It highlights definitions and uses and provides
commands for navigation (e.g., <literal>jump-to-def</literal>, <literal>jump-to-next</literal>,
<literal>list-all-refs</literal>).  It can be handy, for example, for navigating in the
MLton compiler source code.  See <link linkend="EmacsDefUseMode">EmacsDefUseMode</link> for further
information.</simpara>
</section>
<section id="_building_on_the_background">
<title>Building on the background</title>
<simpara>Tired of manually starting/stopping/restarting builds after editing
files?  Now you don&#8217;t have to.  See <link linkend="EmacsBgBuildMode">EmacsBgBuildMode</link> for further
information.</simpara>
</section>
<section id="_error_messages">
<title>Error messages</title>
<simpara>MLton&#8217;s error messages are not among those that the Emacs <literal>next-error</literal>
parser natively understands.  The easiest way to fix this is to add
the following to your <literal>.emacs</literal> to teach Emacs to recognize MLton&#8217;s
error messages.</simpara>
<programlisting language="cl" linenumbering="unnumbered">(require 'compile)
(add-to-list 'compilation-error-regexp-alist 'mlton)
(add-to-list 'compilation-error-regexp-alist-alist
             '(mlton
               "^[[:space:]]*\\(\\(?:\\(Error\\)\\|\\(Warning\\)\\|\\(\\(?:\\(?:defn\\|spec\\) at\\)\\|\\(?:escape \\(?:from\\|to\\)\\)\\|\\(?:scoped at\\)\\)\\): \\(.+\\) \\([0-9]+\\)\\.\\([0-9]+\\)\\(?:-\\([0-9]+\\)\\.\\([0-9]+\\)\\)?\\.?\\)$"
               5 (6 . 8) (7 . 9) (3 . 4) 1))</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="EmacsBgBuildMode">
<title>EmacsBgBuildMode</title>
<simpara>Do you really want to think about starting a build of you project?
What if you had a personal slave that would restart a build of your
project whenever you save any file belonging to that project?  The
bg-build mode does just that.  Just save the file, a compile is
started (silently!), you can continue working without even thinking
about starting a build, and if there are errors, you are notified
(with a message), and can then jump to errors.</simpara>
<simpara>This mode is not specific to MLton per se, but is particularly useful
for working with MLton due to the longer compile times.  By the time
you start wondering about possible errors, the build is already on the
way.</simpara>
<section id="_functionality_and_features">
<title>Functionality and Features</title>
<itemizedlist>
<listitem>
<simpara>
Each time a file is saved, and after a user configurable delay
period has been exhausted, a build is started silently in the
background.
</simpara>
</listitem>
<listitem>
<simpara>
When the build is finished, a status indicator (message) is
displayed non-intrusively.
</simpara>
</listitem>
<listitem>
<simpara>
At any time, you can switch to a build process buffer where all the
messages from the build are shown.
</simpara>
</listitem>
<listitem>
<simpara>
Optionally highlights (error/warning) message locations in (source
code) buffers after a finished build.
</simpara>
</listitem>
<listitem>
<simpara>
After a build has finished, you can jump to locations of warnings
and errors from the build process buffer or by using the <literal>first-error</literal>
and <literal>next-error</literal> commands.
</simpara>
</listitem>
<listitem>
<simpara>
When a build fails, bg-build mode can optionally execute a user
specified command.  By default, bg-build mode executes <literal>first-error</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
When starting a build of a particular project, a possible previous
live build of the same project is interrupted first.
</simpara>
</listitem>
<listitem>
<simpara>
A project configuration file specifies the commands required to
build a project.
</simpara>
</listitem>
<listitem>
<simpara>
Multiple projects can be loaded into bg-build mode and bg-build mode
can build a given maximum number of projects concurrently.
</simpara>
</listitem>
<listitem>
<simpara>
Supports both <ulink url="http://www.gnu.org/software/emacs/">Gnu Emacs</ulink> and
<ulink url="http://www.xemacs.org">XEmacs</ulink>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_download_4">
<title>Download</title>
<simpara>There is no package for the mode at the moment.  To install the mode you
need to fetch the Emacs Lisp, <literal>*.el</literal>, files from the MLton repository:
<ulink url="https://github.com/MLton/mlton/tree/master/ide/emacs"><literal>emacs</literal></ulink>.</simpara>
</section>
<section id="_setup">
<title>Setup</title>
<simpara>The easiest way to load the mode is to first tell Emacs where to find the
files.  For example, add</simpara>
<programlisting language="cl" linenumbering="unnumbered">(add-to-list 'load-path (file-truename "path-to-the-el-files"))</programlisting>
<simpara>to your <literal>~/.emacs</literal> or <literal>~/.xemacs/init.el</literal>.  You&#8217;ll probably also want
to start the mode automatically by adding</simpara>
<programlisting language="cl" linenumbering="unnumbered">(require 'bg-build-mode)
(bg-build-mode)</programlisting>
<simpara>to your Emacs init file.  Once the mode is activated, you should see
the <literal>BGB</literal> indicator on the mode line.</simpara>
<section id="_mlton_and_compilation_mode">
<title>MLton and Compilation-Mode</title>
<simpara>At the time of writing, neither Gnu Emacs nor XEmacs contain an error
regexp that would match MLton&#8217;s messages.</simpara>
<simpara>If you use Gnu Emacs, insert the following code into your <literal>.emacs</literal> file:</simpara>
<programlisting language="cl" linenumbering="unnumbered">(require 'compile)
(add-to-list
 'compilation-error-regexp-alist
 '("^\\(Warning\\|Error\\): \\(.+\\) \\([0-9]+\\)\\.\\([0-9]+\\)\\.$"
   2 3 4))</programlisting>
<simpara>If you use XEmacs, insert the following code into your <literal>init.el</literal> file:</simpara>
<programlisting language="cl" linenumbering="unnumbered">(require 'compile)
(add-to-list
 'compilation-error-regexp-alist-alist
 '(mlton
   ("^\\(Warning\\|Error\\): \\(.+\\) \\([0-9]+\\)\\.\\([0-9]+\\)\\.$"
    2 3 4)))
(compilation-build-compilation-error-regexp-alist)</programlisting>
</section>
</section>
<section id="_usage_3">
<title>Usage</title>
<simpara>Typically projects are built (or compiled) using a tool like <ulink url="http://www.gnu.org/software/make/"><literal>make</literal></ulink>,
but the details vary.  The bg-build mode needs a project configuration file to
know how to build your project.  A project configuration file basically contains
an Emacs Lisp expression calling a function named <literal>bg-build</literal> that returns a
project object.  A simple example of a project configuration file would be the
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/async/unstable/example/smlbot/Build.bgb"><literal>Build.bgb</literal></ulink>)
file used with smlbot:</simpara>
<programlisting language="cl" linenumbering="unnumbered">(bg-build
 :name  "SML-Bot"
 :shell "nice -n5 make all")</programlisting>
<simpara>The <literal>bg-build</literal> function takes a number of keyword arguments:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>:name</literal> specifies the name of the project.  This can be any
expression that evaluates to a string or to a nullary function that
returns a string.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>:shell</literal> specifies a shell command to execute.  This can be any
expression that evaluates to a string, a list of strings, or to a
nullary function returning a list of strings.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>:build?</literal> specifies a predicate to determine whether the project
should be built after some files have been modified.  The predicate is
given a list of filenames and should return a non-nil value when the
project should be built and nil otherwise.
</simpara>
</listitem>
</itemizedlist>
<simpara>All of the keyword arguments, except <literal>:shell</literal>, are optional and can be left out.</simpara>
<simpara>Note the use of the <literal>nice</literal> command above.  It means that background
build process is given a lower priority by the system process
scheduler.  Assuming your machine has enough memory, using nice
ensures that your computer remains responsive.  (You probably won&#8217;t
even notice when a build is started.)</simpara>
<simpara>Once you have written a project file for bg-build mode.  Use the
<literal>bg-build-add-project</literal> command to load the project file for bg-build
mode.  The bg-build mode can also optionally load recent project files
automatically at startup.</simpara>
<simpara>After the project file has been loaded and bg-build mode activated,
each time you save a file in Emacs, the bg-build mode tries to build
your project.</simpara>
<simpara>The <literal>bg-build-status</literal> command creates a buffer that displays some
status information on builds and allows you to manage projects (start
builds explicitly, remove a project from bg-build, &#8230;) as well as
visit buffers created by bg-build.  Notice the count of started
builds.  At the end of the day it can be in the hundreds or thousands.
Imagine the number of times you&#8217;ve been relieved of starting a build
explicitly!</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="EmacsDefUseMode">
<title>EmacsDefUseMode</title>
<simpara>MLton provides an <link linkend="CompileTimeOptions">option</link>,
<literal>-show-def-use <emphasis>file</emphasis></literal>, to output precise (giving exact source
locations) and accurate (including all uses and no false data)
whole-program def-use information to a file.  Unlike typical tags
facilities, the information includes local variables and distinguishes
between different definitions even when they have the same name.  The
def-use Emacs mode uses the information to provide navigation support,
which can be particularly useful while reading SML programs compiled
with MLton (such as the MLton compiler itself).</simpara>
<section id="_screen_capture">
<title>Screen Capture</title>
<simpara>Note the highlighting and the type displayed in the minibuffer.</simpara>
<informalfigure>
<mediaobject>
  <imageobject>
  <imagedata fileref="EmacsDefUseMode.attachments/def-use-capture.png" align="center"/>
  </imageobject>
  <textobject><phrase>EmacsDefUseMode.attachments/def-use-capture.png</phrase></textobject>
</mediaobject>
</informalfigure>
</section>
<section id="_features">
<title>Features</title>
<itemizedlist>
<listitem>
<simpara>
Highlights definitions and uses.  Different colors for definitions, unused definitions, and uses.
</simpara>
</listitem>
<listitem>
<simpara>
Shows types (with highlighting) of variable definitions in the minibuffer.
</simpara>
</listitem>
<listitem>
<simpara>
Navigation: <literal>jump-to-def</literal>, <literal>jump-to-next</literal>, and <literal>jump-to-prev</literal>.  These work precisely (no searching involved).
</simpara>
</listitem>
<listitem>
<simpara>
Can list, visit and mark all references to a definition (within a program).
</simpara>
</listitem>
<listitem>
<simpara>
Automatically reloads updated def-use files.
</simpara>
</listitem>
<listitem>
<simpara>
Automatically loads previously used def-use files at startup.
</simpara>
</listitem>
<listitem>
<simpara>
Supports both <ulink url="http://www.gnu.org/software/emacs/">Gnu Emacs</ulink> and <ulink url="http://www.xemacs.org">XEmacs</ulink>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_download_5">
<title>Download</title>
<simpara>There is no separate package for the def-use mode although the mode
has been relatively stable for some time already.  To install the mode
you need to get the Emacs Lisp, <literal>*.el</literal>, files from MLton&#8217;s repository:
<ulink url="https://github.com/MLton/mlton/tree/master/ide/emacs"><literal>emacs</literal></ulink>.  The easiest way to get the files
is to use <link linkend="Git">Git</link> to access MLton&#8217;s <link linkend="Sources">sources</link>.</simpara>
</section>
<section id="_setup_2">
<title>Setup</title>
<simpara>The easiest way to load def-use mode is to first tell Emacs where to
find the files.  For example, add</simpara>
<programlisting language="cl" linenumbering="unnumbered">(add-to-list 'load-path (file-truename "path-to-the-el-files"))</programlisting>
<simpara>to your <literal>~/.emacs</literal> or <literal>~/.xemacs/init.el</literal>.  You&#8217;ll probably
also want to start <literal>def-use-mode</literal> automatically by adding</simpara>
<programlisting language="cl" linenumbering="unnumbered">(require 'esml-du-mlton)
(def-use-mode)</programlisting>
<simpara>to your Emacs init file.  Once the def-use mode is activated, you
should see the <literal>DU</literal> indicator on the mode line.</simpara>
</section>
<section id="_usage_4">
<title>Usage</title>
<simpara>To use def-use mode one typically first sets up the program&#8217;s makefile
or build script so that the def-use information is saved each time the
program is compiled.  In addition to the <literal>-show-def-use <emphasis>file</emphasis></literal>
option, the <literal>-prefer-abs-paths true</literal> expert option is required.
Note that the time it takes to save the information is small (compared
to type-checking), so it is recommended to simply add the options to
the MLton invocation that compiles the program.  However, it is only
necessary to type check the program (or library), so one can specify
the <literal>-stop tc</literal> option.  For example, suppose you have a program
defined by an MLB file named <literal>my-prg.mlb</literal>, you can save the def-use
information to the file <literal>my-prg.du</literal> by invoking MLton as:</simpara>
<screen>mlton -prefer-abs-paths true -show-def-use my-prg.du -stop tc my-prg.mlb</screen>
<simpara>Finally, one needs to tell the mode where to find the def-use
information.  This is done with the <literal>esml-du-mlton</literal> command.  For
example, to load the <literal>my-prg.du</literal> file, one would type:</simpara>
<screen>M-x esml-du-mlton my-prg.du</screen>
<simpara>After doing all of the above, find an SML file covered by the
previously saved and loaded def-use information, and place the cursor
at some variable (definition or use, it doesn&#8217;t matter).  You should
see the variable being highlighted.  (Note that specifications in
signatures do not define variables.)</simpara>
<simpara>You might also want to setup and use the
<link linkend="EmacsBgBuildMode">Bg-Build mode</link> to start builds automatically.</simpara>
</section>
<section id="_types">
<title>Types</title>
<simpara><literal>-show-def-use</literal> output was extended to include types of variable
definitions in revision <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6333"><literal>r6333</literal></ulink>.  To get good type names, the
types must be in scope at the end of the program.  If you are using the
<link linkend="MLBasis">ML Basis</link> system, this means that the root MLB-file for your
application should not wrap the libraries used in the application inside
<literal>local ... in ... end</literal>, because that would remove them from the scope before
the end of the program.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Enscript">
<title>Enscript</title>
<simpara><ulink url="http://www.gnu.org/s/enscript/">GNU Enscript</ulink> converts ASCII files to
PostScript, HTML, and other output languages, applying language
sensitive highlighting (similar to <link linkend="Emacs">Emacs</link>'s font lock mode).  Here
are a few <emphasis>states</emphasis> files for highlighting <link linkend="StandardML">Standard ML</link>.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/ide/enscript/sml_simple.st"><literal>sml_simple.st</literal></ulink>&#8201;&#8212;&#8201;Provides highlighting of keywords, string and character constants, and (nested) comments.
</simpara>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/ide/enscript/sml_verbose.st"><literal>sml_verbose.st</literal></ulink>&#8201;&#8212;&#8201;Supersedes
the above, adding highlighting of numeric constants.  Due to the
limited parsing available, numeric record labels are highlighted as
numeric constants, in all contexts.  Likewise, a binding precedence
separated from <literal>infix</literal> or <literal>infixr</literal> by a newline is highlighted as a
numeric constant and a numeric record label selector separated from
<literal>#</literal> by a newline is highlighted as a numeric constant.
</simpara>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/ide/enscript/sml_fancy.st"><literal>sml_fancy.st</literal></ulink>&#8201;&#8212;&#8201;Supersedes the
above, adding highlighting of type and constructor bindings,
highlighting of explicit binding of type variables at <literal>val</literal> and <literal>fun</literal>
declarations, and separate highlighting of core and modules level
keywords.  Due to the limited parsing available, it is assumed that
the input is a syntactically correct, top-level declaration.
</simpara>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/ide/enscript/sml_gaudy.st"><literal>sml_gaudy.st</literal></ulink>&#8201;&#8212;&#8201;Supersedes the
above, adding highlighting of type annotations, in both expressions
and signatures.  Due to the limited parsing available, it is assumed
that the input is a syntactically correct, top-level declaration.
</simpara>
</listitem>
</itemizedlist>
<section id="_install_and_use">
<title>Install and use</title>
<itemizedlist>
<listitem>
<simpara>
Version 1.6.3 of <ulink url="http://people.ssh.com/mtr/genscript">GNU Enscript</ulink>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Copy all files to <literal>/usr/share/enscript/hl/</literal> or <literal>.enscript/</literal> in your home directory.
</simpara>
</listitem>
<listitem>
<simpara>
Invoke <literal>enscript</literal> with <literal>--highlight=sml_simple</literal> (or <literal>--highlight=sml_verbose</literal> or <literal>--highlight=sml_fancy</literal> or <literal>--highlight=sml_gaudy</literal>).
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Version 1.6.1 of <ulink url="http://people.ssh.com/mtr/genscript">GNU Enscript</ulink>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Append <ulink url="https://github.com/MLton/mlton/blob/master/ide/enscript/sml_all.st"><literal>sml_all.st</literal></ulink> to <literal>/usr/share/enscript/enscript.st</literal>
</simpara>
</listitem>
<listitem>
<simpara>
Invoke <literal>enscript</literal> with <literal>--pretty-print=sml_simple</literal> (or <literal>--pretty-print=sml_verbose</literal> or <literal>--pretty-print=sml_fancy</literal> or <literal>--pretty-print=sml_gaudy</literal>).
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_feedback">
<title>Feedback</title>
<simpara>Comments and suggestions should be directed to <link linkend="MatthewFluet">MatthewFluet</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="EqualityType">
<title>EqualityType</title>
<simpara>An equality type is a type to which <link linkend="PolymorphicEquality">PolymorphicEquality</link> can be
applied.  The <link linkend="DefinitionOfStandardML">Definition</link> and the
<link linkend="BasisLibrary">Basis Library</link> precisely spell out which types are
equality types.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>bool</literal>, <literal>char</literal>, <literal>IntInf.int</literal>, <literal>Int<emphasis>&lt;N&gt;</emphasis>.int</literal>, <literal>string</literal>, and <literal>Word<emphasis>&lt;N&gt;</emphasis>.word</literal> are equality types.
</simpara>
</listitem>
<listitem>
<simpara>
for any <literal>t</literal>, both <literal>t array</literal> and <literal>t ref</literal> are equality types.
</simpara>
</listitem>
<listitem>
<simpara>
if <literal>t</literal> is an equality type, then <literal>t list</literal>, and <literal>t vector</literal> are equality types.
</simpara>
</listitem>
<listitem>
<simpara>
if <literal>t1</literal>, &#8230;, <literal>tn</literal> are equality types, then <literal>t1 * ... * tn</literal> and <literal>{l1: t1, ..., ln: tn}</literal> are equality types.
</simpara>
</listitem>
<listitem>
<simpara>
if <literal>t1</literal>, &#8230;, <literal>tn</literal> are equality types and <literal>t</literal> <link linkend="AdmitsEquality">AdmitsEquality</link>, then <literal>(t1, ..., tn) t</literal> is an equality type.
</simpara>
</listitem>
</itemizedlist>
<simpara>To check that a type t is an equality type, use the following idiom.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S: sig eqtype t end =
   struct
      type t = ...
   end</programlisting>
<simpara>Notably, <literal>exn</literal> and <literal>real</literal> are not equality types.  Neither is <literal>t1 -&gt; t2</literal>, for any <literal>t1</literal> and <literal>t2</literal>.</simpara>
<simpara>Equality on arrays and ref cells is by identity, not structure.
For example, <literal>ref 13 = ref 13</literal> is <literal>false</literal>.
On the other hand, equality for lists, strings, and vectors is by
structure, not identity.  For example, the following equalities hold.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val _ = [1, 2, 3] = 1 :: [2, 3]
val _ = "foo" = concat ["f", "o", "o"]
val _ = Vector.fromList [1, 2, 3] = Vector.tabulate (3, fn i =&gt; i + 1)</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="EqualityTypeVariable">
<title>EqualityTypeVariable</title>
<simpara>An equality type variable is a type variable that starts with two or
more primes, as in <literal>''a</literal> or <literal>''b</literal>.  The canonical use of equality type
variables is in specifying the type of the <link linkend="PolymorphicEquality">PolymorphicEquality</link>
function, which is <literal>''a * ''a -&gt; bool</literal>.  Equality type variables
ensure that polymorphic equality is only used on
<link linkend="EqualityType">equality types</link>, by requiring that at every use of a
polymorphic value, equality type variables are instantiated by
equality types.</simpara>
<simpara>For example, the following program is type correct because polymorphic
equality is applied to variables of type <literal>''a</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (x: ''a, y: ''a): bool = x = y</programlisting>
<simpara>On the other hand, the following program is not type correct, because
polymorphic equality is applied to variables of type <literal>'a</literal>, which is
not an equality type.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (x: 'a, y: 'a): bool = x = y</programlisting>
<simpara>MLton reports the following error, indicating that polymorphic
equality expects equality types, but didn&#8217;t get them.</simpara>
<screen>Error: z.sml 1.30-1.34.
  Function applied to incorrect argument.
    expects: [&lt;equality&gt;] * [&lt;equality&gt;]
    but got: ['a] * ['a]
    in: = (x, y)</screen>
<simpara>As an example of using such a function that requires equality types,
suppose that <literal>f</literal> has polymorphic type <literal>''a -&gt; unit</literal>.  Then, <literal>f 13</literal> is
type correct because <literal>int</literal> is an equality type.  On the other hand,
<literal>f 13.0</literal> and <literal>f (fn x =&gt; x)</literal> are not type correct, because <literal>real</literal> and
arrow types are not equality types.  We can test these facts with the
following short programs.  First, we verify that such an <literal>f</literal> can be
applied to integers.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Ok (val f: ''a -&gt; unit): sig end =
   struct
      val () = f 13
      val () = f 14
   end</programlisting>
<simpara>We can do better, and verify that such an <literal>f</literal> can be applied to
any integer.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Ok (val f: ''a -&gt; unit): sig end =
   struct
      fun g (x: int) = f x
   end</programlisting>
<simpara>Even better, we don&#8217;t need to introduce a dummy function name; we can
use a type constraint.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Ok (val f: ''a -&gt; unit): sig end =
   struct
      val _ = f: int -&gt; unit
   end</programlisting>
<simpara>Even better, we can use a signature constraint.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Ok (S: sig val f: ''a -&gt; unit end):
   sig val f: int -&gt; unit end = S</programlisting>
<simpara>This functor concisely verifies that a function of polymorphic type
<literal>''a -&gt; unit</literal> can be safely used as a function of type <literal>int -&gt; unit</literal>.</simpara>
<simpara>As above, we can verify that such an <literal>f</literal> can not be used at
non-equality types.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Bad (S: sig val f: ''a -&gt; unit end):
   sig val f: real -&gt; unit end = S

functor Bad (S: sig val f: ''a -&gt; unit end):
   sig val f: ('a -&gt; 'a) -&gt; unit end = S</programlisting>
<simpara>MLton reports the following errors.</simpara>
<screen>Error: z.sml 2.4-2.30.
  Variable in structure disagrees with signature (type): f.
    structure: val f: [&lt;equality&gt;] -&gt; _
    defn at: z.sml 1.25-1.25
    signature: val f: [real] -&gt; _
    spec at: z.sml 2.12-2.12
Error: z.sml 5.4-5.36.
  Variable in structure disagrees with signature (type): f.
    structure: val f: [&lt;equality&gt;] -&gt; _
    defn at: z.sml 4.25-4.25
    signature: val f: [_ -&gt; _] -&gt; _
    spec at: z.sml 5.12-5.12</screen>
<section id="_equality_type_variables_in_type_and_datatype_declarations">
<title>Equality type variables in type and datatype declarations</title>
<simpara>Equality type variables can be used in type and datatype declarations;
however they play no special role.  For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a t = 'a * int</programlisting>
<simpara>is completely identical to</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ''a t = ''a * int</programlisting>
<simpara>In particular, such a definition does <emphasis>not</emphasis> require that <literal>t</literal> only be
applied to equality types.</simpara>
<simpara>Similarly,</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A | B of 'a</programlisting>
<simpara>is completely identical to</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype ''a t = A | B of ''a</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="EtaExpansion">
<title>EtaExpansion</title>
<simpara>Eta expansion is a simple syntactic change used to work around the
<link linkend="ValueRestriction">ValueRestriction</link> in <link linkend="StandardML">Standard ML</link>.</simpara>
<simpara>The eta expansion of an expression <literal>e</literal> is the expression
<literal>fn z =&gt; e z</literal>, where <literal>z</literal> does not occur in <literal>e</literal>.  This only
makes sense if <literal>e</literal> denotes a function, i.e. is of arrow type.  Eta
expansion delays the evaluation of <literal>e</literal> until the function is
applied, and will re-evaluate <literal>e</literal> each time the function is
applied.</simpara>
<simpara>The name "eta expansion" comes from the eta-conversion rule of the
<link linkend="LambdaCalculus">lambda calculus</link>.  Expansion refers to the
directionality of the equivalence being used, namely taking <literal>e</literal> to
<literal>fn z =&gt; e z</literal> rather than <literal>fn z =&gt; e z</literal> to <literal>e</literal> (eta
contraction).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="eXene">
<title>eXene</title>
<simpara><ulink url="http://people.cs.uchicago.edu/%7Ejhr/eXene/index.html">eXene</ulink> is a
multi-threaded X Window System toolkit written in <link linkend="ConcurrentML">ConcurrentML</link>.</simpara>
<simpara>There is a group at K-State working toward
<ulink url="http://www.cis.ksu.edu/%7Estough/eXene/">eXene 2.0</ulink>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="FAQ">
<title>FAQ</title>
<simpara>Feel free to ask questions and to update answers by editing this page.
Since we try to make as much information as possible available on the
web site and we like to avoid duplication, many of the answers are
simply links to a web page that answers the question.</simpara>
<section id="_how_do_you_pronounce_mlton">
<title>How do you pronounce MLton?</title>
<simpara><link linkend="Pronounce">Pronounce</link></simpara>
</section>
<section id="_what_sml_software_has_been_ported_to_mlton">
<title>What SML software has been ported to MLton?</title>
<simpara><link linkend="Libraries">Libraries</link></simpara>
</section>
<section id="_what_graphical_libraries_are_available_for_mlton">
<title>What graphical libraries are available for MLton?</title>
<simpara><link linkend="Libraries">Libraries</link></simpara>
</section>
<section id="_how_does_mlton_8217_s_performance_compare_to_other_sml_compilers_and_to_other_languages">
<title>How does MLton&#8217;s performance compare to other SML compilers and to other languages?</title>
<simpara>MLton has <link linkend="Performance">excellent performance</link>.</simpara>
</section>
<section id="_does_mlton_treat_monomorphic_arrays_and_vectors_specially">
<title>Does MLton treat monomorphic arrays and vectors specially?</title>
<simpara>MLton implements monomorphic arrays and vectors (e.g. <literal>BoolArray</literal>,
<literal>Word8Vector</literal>) exactly as instantiations of their polymorphic
counterpart (e.g. <literal>bool array</literal>, <literal>Word8.word vector</literal>).  Thus, there is
no need to use the monomorphic versions except when required to
interface with the <link linkend="BasisLibrary">Basis Library</link> or for portability
with other SML implementations.</simpara>
</section>
<section id="_why_do_i_get_a_segfault_bus_error_in_a_program_that_uses_literal_intinf_literal_literal_largeint_literal_to_calculate_numbers_with_several_hundred_thousand_digits">
<title>Why do I get a Segfault/Bus error in a program that uses <literal>IntInf</literal>/<literal>LargeInt</literal> to calculate numbers with several hundred thousand digits?</title>
<simpara><link linkend="GnuMP">GnuMP</link></simpara>
</section>
<section id="_how_can_i_decrease_compile_time_memory_usage">
<title>How can I decrease compile-time memory usage?</title>
<itemizedlist>
<listitem>
<simpara>
Compile with <literal>-verbose 3</literal> to find out if the problem is due to an
SSA optimization pass.  If so, compile with <literal>-disable-pass <emphasis>pass</emphasis></literal> to
skip that pass.
</simpara>
</listitem>
<listitem>
<simpara>
Compile with <literal>@MLton hash-cons 0.5 --</literal>, which will instruct the
runtime to hash cons the heap every other GC.
</simpara>
</listitem>
<listitem>
<simpara>
Compile with <literal>-polyvariance false</literal>, which is an undocumented option
that causes less code duplication.
</simpara>
</listitem>
</itemizedlist>
<simpara>Also, please <link linkend="Contact">Contact</link> us to let us know the problem to help us
better understand MLton&#8217;s limitations.</simpara>
</section>
<section id="_how_portable_is_sml_code_across_sml_compilers">
<title>How portable is SML code across SML compilers?</title>
<simpara><link linkend="StandardMLPortability">StandardMLPortability</link></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Features">
<title>Features</title>
<simpara>MLton has the following features.</simpara>
<section id="_portability">
<title>Portability</title>
<itemizedlist>
<listitem>
<simpara>
Runs on a variety of platforms.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnARM">ARM</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnAlpha">Alpha</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnAMD64">AMD64</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnDarwin">Darwin</link> (Mac OS X)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnFreeBSD">FreeBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian, Fedora, Ubuntu, &#8230;)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnOpenBSD">OpenBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSolaris">Solaris</link> (10 and above)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnHPPA">HPPA</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnHPUX">HPUX</link> (11.11 and above)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnIA64">IA64</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnHPUX">HPUX</link> (11.11 and above)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC">PowerPC</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAIX">AIX</link> (5.2 and above)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnDarwin">Darwin</link> (Mac OS X)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian, Fedora, &#8230;)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC64">PowerPC64</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAIX">AIX</link> (5.2 and above)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnS390">S390</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSparc">Sparc</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSolaris">Solaris</link> (8 and above)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnX86">X86</link>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnCygwin">Cygwin</link>/Windows
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnDarwin">Darwin</link> (Mac OS X)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnFreeBSD">FreeBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link> (Debian, Fedora, Ubuntu, &#8230;)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnMinGW">MinGW</link>/Windows
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnNetBSD">NetBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnOpenBSD">OpenBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSolaris">Solaris</link> (10 and above)
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_robustness">
<title>Robustness</title>
<itemizedlist>
<listitem>
<simpara>
Supports the full SML 97 language as given in <link linkend="DefinitionOfStandardML">The Definition of Standard ML (Revised)</link>.
</simpara>
<simpara>If there is a program that is valid according to the
<link linkend="DefinitionOfStandardML">Definition</link> that is rejected by MLton, or a
program that is invalid according to the
<link linkend="DefinitionOfStandardML">Definition</link> that is accepted by MLton, it is
a bug.  For a list of known bugs, see <link linkend="UnresolvedBugs">UnresolvedBugs</link>.</simpara>
</listitem>
<listitem>
<simpara>
A complete implementation of the <link linkend="BasisLibrary">Basis Library</link>.
</simpara>
<simpara>MLton&#8217;s implementation matches latest <link linkend="BasisLibrary">Basis Library</link>
<ulink url="http://www.standardml.org/Basis">specification</ulink>, and includes a
complete implementation of all the required modules, as well as many
of the optional modules.</simpara>
</listitem>
<listitem>
<simpara>
Generates standalone executables.
</simpara>
<simpara>No additional code or libraries are necessary in order to run an
executable, except for the standard shared libraries.  MLton can also
generate statically linked executables.</simpara>
</listitem>
<listitem>
<simpara>
Compiles large programs.
</simpara>
<simpara>MLton is sufficiently efficient and robust that it can compile large
programs, including itself (over 190K lines).  The distributed version
of MLton was compiled by MLton.</simpara>
</listitem>
<listitem>
<simpara>
Support for large amounts of memory (up to 4G on 32-bit systems; more on 64-bit systems).
</simpara>
</listitem>
<listitem>
<simpara>
Support for large array lengths (up to 2<superscript>31</superscript>-1 on 32-bit systems; up to 2<superscript>63</superscript>-1 on 64-bit systems).
</simpara>
</listitem>
<listitem>
<simpara>
Support for large files, using 64-bit file positions.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_performance">
<title>Performance</title>
<itemizedlist>
<listitem>
<simpara>
Executables have <link linkend="Performance">excellent running times</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Generates small executables.
</simpara>
<simpara>MLton takes advantage of whole-program compilation to perform very
aggressive dead-code elimination, which often leads to smaller
executables than with other SML compilers.</simpara>
</listitem>
<listitem>
<simpara>
Untagged and unboxed native integers, reals, and words.
</simpara>
<simpara>In MLton, integers and words are 8 bits, 16 bits, 32 bits, and 64 bits
and arithmetic does not have any overhead due to tagging or boxing.
Also, reals (32-bit and 64-bit) are stored unboxed, avoiding any
overhead due to boxing.</simpara>
</listitem>
<listitem>
<simpara>
Unboxed native arrays.
</simpara>
<simpara>In MLton, an array (or vector) of integers, reals, or words uses the
natural C-like representation.  This is fast and supports easy
exchange of data with C.  Monomorphic arrays (and vectors) use the
same C-like representations as their polymorphic counterparts.</simpara>
</listitem>
<listitem>
<simpara>
Multiple <link linkend="GarbageCollection">garbage collection</link> strategies.
</simpara>
</listitem>
<listitem>
<simpara>
Fast arbitrary precision arithmetic (<literal>IntInf</literal>) based on <link linkend="GnuMP">GnuMP</link>.
</simpara>
<simpara>For <literal>IntInf</literal> intensive programs, MLton can be an order of magnitude or
more faster than Poly/ML or SML/NJ.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_tools">
<title>Tools</title>
<itemizedlist>
<listitem>
<simpara>
Source-level <link linkend="Profiling">Profiling</link> of both time and allocation.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLLex">MLLex</link> lexer generator
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLYacc">MLYacc</link> parser generator
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLNLFFIGen">MLNLFFIGen</link> foreign-function-interface generator
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_extensions">
<title>Extensions</title>
<itemizedlist>
<listitem>
<simpara>
A simple and fast C <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> that supports calling from SML to C and from C to SML.
</simpara>
</listitem>
<listitem>
<simpara>
The <link linkend="MLBasis">ML Basis system</link> for programming in the very large, separate delivery of library sources, and more.
</simpara>
</listitem>
<listitem>
<simpara>
A number of extension libraries that provide useful functionality
that cannot be implemented with the <link linkend="BasisLibrary">Basis Library</link>.
See below for an overview and <link linkend="MLtonStructure">MLtonStructure</link> for details.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLtonCont">continuations</link>
</simpara>
<simpara>MLton supports continuations via <literal>callcc</literal> and <literal>throw</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonFinalizable">finalization</link>
</simpara>
<simpara>MLton supports finalizable values of arbitrary type.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonItimer">interval timers</link>
</simpara>
<simpara>MLton supports the functionality of the C <literal>setitimer</literal> function.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonRandom">random numbers</link>
</simpara>
<simpara>MLton has functions similar to the C <literal>rand</literal> and <literal>srand</literal> functions, as well as support for access to <literal>/dev/random</literal> and <literal>/dev/urandom</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonRlimit">resource limits</link>
</simpara>
<simpara>MLton has functions similar to the C <literal>getrlimit</literal> and <literal>setrlimit</literal> functions.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonRusage">resource usage</link>
</simpara>
<simpara>MLton supports a subset of the functionality of the C <literal>getrusage</literal> function.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonSignal">signal handlers</link>
</simpara>
<simpara>MLton supports signal handlers written in SML.  Signal handlers run in
a separate MLton thread, and have access to the thread that was
interrupted by the signal.  Signal handlers can be used in conjunction
with threads to implement preemptive multitasking.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonStructure">size primitive</link>
</simpara>
<simpara>MLton includes a primitive that returns the size (in bytes) of any
object.  This can be useful in understanding the space behavior of a
program.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonSyslog">system logging</link>
</simpara>
<simpara>MLton has a complete interface to the C <literal>syslog</literal> function.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonThread">threads</link>
</simpara>
<simpara>MLton has support for its own threads, upon which either preemptive or
non-preemptive multitasking can be implemented.  MLton also has
support for <link linkend="ConcurrentML">Concurrent ML</link> (CML).</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonWeak">weak pointers</link>
</simpara>
<simpara>MLton supports weak pointers, which allow the garbage collector to
reclaim objects that it would otherwise be forced to keep.  Weak
pointers are also used to provide finalization.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonWorld">world save and restore</link>
</simpara>
<simpara>MLton has a facility for saving the entire state of a computation to a
file and restarting it later.  This facility can be used for staging
and for checkpointing computations.  It can even be used from within
signal handlers, allowing interrupt driven checkpointing.</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="FirstClassPolymorphism">
<title>FirstClassPolymorphism</title>
<simpara>First-class polymorphism is the ability to treat polymorphic functions
just like other values: pass them as arguments, store them in data
structures, etc.  Although <link linkend="StandardML">Standard ML</link> does have
polymorphic functions, it does not support first-class polymorphism.</simpara>
<simpara>For example, the following declares and uses the polymorphic function
<literal>id</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id = fn x =&gt; x
val _ = id 13
val _ = id "foo"</programlisting>
<simpara>If SML supported first-class polymorphism, we could write the
following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun useId id = (id 13; id "foo")</programlisting>
<simpara>However, this does not type check.  MLton reports the following error.</simpara>
<screen>Error: z.sml 1.24-1.31.
  Function applied to incorrect argument.
    expects: [int]
    but got: [string]
    in: id "foo"</screen>
<simpara>The error message arises because MLton infers from <literal>id 13</literal> that <literal>id</literal>
accepts an integer argument, but that <literal>id "foo"</literal> is passing a string.</simpara>
<simpara>Using explicit types sheds some light on the problem.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun useId (id: 'a -&gt; 'a) = (id 13; id "foo")</programlisting>
<simpara>On this, MLton reports the following errors.</simpara>
<screen>Error: z.sml 1.29-1.33.
  Function applied to incorrect argument.
    expects: ['a]
    but got: [int]
    in: id 13
Error: z.sml 1.36-1.43.
  Function applied to incorrect argument.
    expects: ['a]
    but got: [string]
    in: id "foo"</screen>
<simpara>The errors arise because the argument <literal>id</literal> is <emphasis>not</emphasis> polymorphic;
rather, it is monomorphic, with type <literal>'a -&gt; 'a</literal>.  It is perfectly
valid to apply <literal>id</literal> to a value of type <literal>'a</literal>, as in the following</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun useId (id: 'a -&gt; 'a, x: 'a) = id x  (* type correct *)</programlisting>
<simpara>So, what is the difference between the type specification on <literal>id</literal> in
the following two declarations?</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
fun useId (id: 'a -&gt; 'a) = (id 13; id "foo")</programlisting>
<simpara>While the type specifications on <literal>id</literal> look identical, they mean
different things.  The difference can be made clearer by explicitly
<link linkend="TypeVariableScope">scoping the type variables</link>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a id: 'a -&gt; 'a = fn x =&gt; x
fun 'a useId (id: 'a -&gt; 'a) = (id 13; id "foo")  (* type error *)</programlisting>
<simpara>In <literal>val 'a id</literal>, the type variable scoping means that for any <literal>'a</literal>,
<literal>id</literal> has type <literal>'a -&gt; 'a</literal>.  Hence, <literal>id</literal> can be applied to arguments of
type <literal>int</literal>, <literal>real</literal>, etc.  Similarly, in <literal>fun 'a useId</literal>, the scoping
means that <literal>useId</literal> is a polymorphic function that for any <literal>'a</literal> takes a
function of type <literal>'a -&gt; 'a</literal> and does something.  Thus, <literal>useId</literal> could
be applied to a function of type <literal>int -&gt; int</literal>, <literal>real -&gt; real</literal>, etc.</simpara>
<simpara>One could imagine an extension of SML that allowed scoping of type
variables at places other than <literal>fun</literal> or <literal>val</literal> declarations, as in the
following.</simpara>
<screen>fun useId (id: ('a).'a -&gt; 'a) = (id 13; id "foo")  (* not SML *)</screen>
<simpara>Such an extension would need to be thought through very carefully, as
it could cause significant complications with <link linkend="TypeInference">TypeInference</link>,
possible even undecidability.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Fixpoints">
<title>Fixpoints</title>
<simpara>This page discusses a framework that makes it possible to compute
fixpoints over arbitrary products of abstract types.  The code is from
an Extended Basis library
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/README"><literal>README</literal></ulink>).</simpara>
<simpara>First the signature of the framework
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/public/generic/tie.sig"><literal>tie.sig</literal></ulink>):</simpara>
<programlisting language="sml" linenumbering="unnumbered">(**
 * A framework for computing fixpoints.
 *
 * In a strict language you sometimes want to provide a fixpoint
 * combinator for an abstract type {t} to make it possible to write
 * recursive definitions.  Unfortunately, a single combinator {fix} of the
 * type {(t -&gt; t) -&gt; t} does not support mutual recursion.  To support
 * mutual recursion, you would need to provide a family of fixpoint
 * combinators having types of the form {(u -&gt; u) -&gt; u} where {u} is a
 * type of the form {t * ... * t}.  Unfortunately, even such a family of
 * fixpoint combinators does not support mutual recursion over different
 * abstract types.
 *)
signature TIE = sig
   include ETAEXP'
   type 'a t = 'a etaexp
   (** The type of fixpoint witnesses. *)

   val fix : 'a t -&gt; 'a Fix.t
   (**
    * Produces a fixpoint combinator from the given witness.  For example,
    * one can make a mutually recursive definition of functions:
    *
    *&gt; val isEven &amp; isOdd =
    *&gt;     let open Tie in fix (function *` function) end
    *&gt;        (fn isEven &amp; isOdd =&gt;
    *&gt;            (fn 0 =&gt; true
    *&gt;              | 1 =&gt; false
    *&gt;              | n =&gt; isOdd (n-1)) &amp;
    *&gt;            (fn 0 =&gt; false
    *&gt;              | 1 =&gt; true
    *&gt;              | n =&gt; isEven (n-1)))
    *)

   (** == Making New Witnesses == *)

   val pure : ('a * 'a UnOp.t) Thunk.t -&gt; 'a t
   (**
    * {pure} is a more general version of {tier}.  It is mostly useful for
    * computing fixpoints in a non-imperative manner.
    *)

   val tier : ('a * 'a Effect.t) Thunk.t -&gt; 'a t
   (**
    * {tier} is used to define fixpoint witnesses for new abstract types
    * by providing a thunk whose instantiation allocates a mutable proxy
    * and a procedure for updating it with the result.
    *)

   val id : 'a -&gt; 'a t
   (** {id x} is equivalent to {pure (const (x, id))}. *)

   (** == Combining Existing Witnesses == *)

   val iso : 'b t -&gt; ('a, 'b) Iso.t -&gt; 'a t
   (**
    * Given an isomorphism between {'a} and {'b} and a witness for {'b},
    * produces a witness for {'a}.  This is useful when you have a new
    * type that is isomorphic to some old type for which you already have
    * a witness.
    *)

   val product : 'a t * ('a -&gt; 'b t) -&gt; ('a, 'b) Product.t t
   (**
    * Dependent product combinator.  Given a witness for {'a} and a
    * constructor from a {'a} to witness for {'b}, produces a witness for
    * the product {('a, 'b) Product.t}.  The constructor for {'b} should
    * not access the (proxy) value {'a} before it has been fixed.
    *)

   val *` : 'a t * 'b t -&gt; ('a, 'b) Product.t t
   (** {a *` b} is equivalent to {product (a, const b)}. *)

   val tuple2 : 'a t * 'b t -&gt; ('a * 'b) t
   (**
    * Given witnesses for {'a} and {'b} produces a witness for the product
    * {'a * 'b}.
    *)

   (** == Particular Witnesses == *)

   val function : ('a -&gt; 'b) t
   (** Witness for functions. *)
end</programlisting>
<simpara><literal>fix</literal> is a <link linkend="TypeIndexedValues">type-indexed</link> function.  The type-index
parameter to <literal>fix</literal> is called a "witness".  To compute fixpoints over
products, one uses the <literal>*&grave;</literal> operator to combine witnesses.  To provide
a fixpoint combinator for an abstract type, one implements a witness
providing a thunk whose instantiation allocates a fresh, mutable proxy
and a procedure for updating the proxy with the solution.  Naturally
this means that not all possible ways of computing a fixpoint of a
particular type are possible under the framework.  The <literal>pure</literal>
combinator is a generalization of <literal>tier</literal>.  The <literal>iso</literal> combinator is
provided for reusing existing witnesses.</simpara>
<simpara>Note that instead of using an infix operator, we could alternatively
employ an interface using <link linkend="Fold">Fold</link>.  Also, witnesses are eta-expanded
to work around the <link linkend="ValueRestriction">value restriction</link>, while
maintaining abstraction.</simpara>
<simpara>Here is the implementation
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/detail/generic/tie.sml"><literal>tie.sml</literal></ulink>):</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Tie :&gt; TIE = struct
   open Product
   infix &amp;
   type 'a etaexp_dom = Unit.t
   type 'a etaexp_cod = ('a * 'a UnOp.t) Thunk.t
   type 'a etaexp = 'a etaexp_dom -&gt; 'a etaexp_cod
   type 'a t = 'a etaexp
   fun fix aT f = let val (a, ta) = aT () () in ta (f a) end
   val pure = Thunk.mk
   fun iso bT (iso as (_, b2a)) () () = let
      val (b, fB) = bT () ()
   in
      (b2a b, Fn.map iso fB)
   end
   fun product (aT, a2bT) () () = let
      val (a, fA) = aT () ()
      val (b, fB) = a2bT a () ()
   in
      (a &amp; b, Product.map (fA, fB))
   end
   (* The rest are not primitive operations. *)
   fun op *` (aT, bT) = product (aT, Fn.const bT)
   fun tuple2 ab = iso (op *` ab) Product.isoTuple2
   fun tier th = pure ((fn (a, ua) =&gt; (a, Fn.const a o ua)) o th)
   fun id x = pure (Fn.const (x, Fn.id))
   fun function ? =
       pure (fn () =&gt; let
                   val r = ref (Basic.raising Fix.Fix)
                in
                   (fn x =&gt; !r x, fn f =&gt; (r := f ; f))
                end) ?
end</programlisting>
<simpara>Let&#8217;s then take a look at a couple of additional examples.</simpara>
<simpara>Here is a naive implementation of lazy promises:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Promise :&gt; sig
   type 'a t
   val lazy : 'a Thunk.t -&gt; 'a t
   val force : 'a t -&gt; 'a
   val Y : 'a t Tie.t
end = struct
   datatype 'a t' =
      EXN of exn
    | THUNK of 'a Thunk.t
    | VALUE of 'a
   type 'a t = 'a t' Ref.t
   fun lazy f = ref (THUNK f)
   fun force t =
      case !t
       of EXN e   =&gt; raise e
        | THUNK f =&gt; (t := VALUE (f ()) handle e =&gt; t := EXN e ; force t)
        | VALUE v =&gt; v
   fun Y ? = Tie.tier (fn () =&gt; let
                             val r = lazy (raising Fix.Fix)
                          in
                             (r, r &lt;\ op := o !)
                          end) ?
end</programlisting>
<simpara>An example use of our naive lazy promises is to implement equally naive
lazy streams:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Stream :&gt; sig
   type 'a t
   val cons : 'a * 'a t -&gt; 'a t
   val get : 'a t -&gt; ('a * 'a t) Option.t
   val Y : 'a t Tie.t
end = struct
   datatype 'a t = IN of ('a * 'a t) Option.t Promise.t
   fun cons (x, xs) = IN (Promise.lazy (fn () =&gt; SOME (x, xs)))
   fun get (IN p) = Promise.force p
   fun Y ? = Tie.iso Promise.Y (fn IN p =&gt; p, IN) ?
end</programlisting>
<simpara>Note that above we make use of the <literal>iso</literal> combinator.  Here is a finite
representation of an infinite stream of ones:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val ones = let
   open Tie Stream
in
   fix Y (fn ones =&gt; cons (1, ones))
end</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Flatten">
<title>Flatten</title>
<simpara><link linkend="Flatten">Flatten</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_17">
<title>Description</title>
<simpara>This pass flattens arguments to <link linkend="SSA">SSA</link> constructors, blocks, and
functions.</simpara>
<simpara>If a tuple is explicitly available at all uses of a function
(resp. block), then:</simpara>
<itemizedlist>
<listitem>
<simpara>
The formals and call sites are changed so that the components of the
tuple are passed.
</simpara>
</listitem>
<listitem>
<simpara>
The tuple is reconstructed at the beginning of the body of the
function (resp. block).
</simpara>
</listitem>
</itemizedlist>
<simpara>Similarly, if a tuple is explicitly available at all uses of a
constructor, then:</simpara>
<itemizedlist>
<listitem>
<simpara>
The constructor argument datatype is changed to flatten the tuple
type.
</simpara>
</listitem>
<listitem>
<simpara>
The tuple is passed flat at each <literal>ConApp</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
The tuple is reconstructed at each <literal>Case</literal> transfer target.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_implementation_19">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/flatten.fun"><literal>flatten.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_19">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Fold">
<title>Fold</title>
<simpara>This page describes a technique that enables convenient syntax for a
number of language features that are not explicitly supported by
<link linkend="StandardML">Standard ML</link>, including: variable number of arguments,
<link linkend="OptionalArguments">optional arguments and labeled arguments</link>,
<link linkend="ArrayLiteral">array and vector literals</link>,
<link linkend="FunctionalRecordUpdate">functional record update</link>,
and (seemingly) dependently typed functions like <link linkend="Printf">printf</link> and scanf.</simpara>
<simpara>The key idea to <emphasis>fold</emphasis> is to define functions <literal>fold</literal>, <literal>step0</literal>,
and <literal>$</literal> such that the following equation holds.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold (a, f) (step0 h1) (step0 h2) ... (step0 hn) $
= f (hn (... (h2 (h1 a))))</programlisting>
<simpara>The name <literal>fold</literal> comes because this is like a traditional list fold,
where <literal>a</literal> is the <emphasis>base element</emphasis>, and each <emphasis>step function</emphasis>,
<literal>step0 hi</literal>, corresponds to one element of the list and does one
step of the fold.  The name <literal>$</literal> is chosen to mean "end of
arguments" from its common use in regular-expression syntax.</simpara>
<simpara>Unlike the usual list fold in which the same function is used to step
over each element in the list, this fold allows the step functions to
be different from each other, and even to be of different types.  Also
unlike the usual list fold, this fold includes a "finishing
function", <literal>f</literal>, that is applied to the result of the fold.  The
presence of the finishing function may seem odd because there is no
analogy in list fold.  However, the finishing function is essential;
without it, there would be no way for the folder to perform an
arbitrary computation after processing all the arguments.  The
examples below will make this clear.</simpara>
<simpara>The functions <literal>fold</literal>, <literal>step0</literal>, and <literal>$</literal> are easy to
define.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun $ (a, f) = f a
fun id x = x
structure Fold =
   struct
      fun fold (a, f) g = g (a, f)
      fun step0 h (a, f) = fold (h a, f)
   end</programlisting>
<simpara>We&#8217;ve placed <literal>fold</literal> and <literal>step0</literal> in the <literal>Fold</literal> structure
but left <literal>$</literal> at the toplevel because it is convenient in code to
always have <literal>$</literal> in scope.  We&#8217;ve also defined the identity
function, <literal>id</literal>, at the toplevel since we use it so frequently.</simpara>
<simpara>Plugging in the definitions, it is easy to verify the equation from
above.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold (a, f) (step0 h1) (step0 h2) ... (step0 hn) $
= step0 h1 (a, f) (step0 h2) ... (step0 hn) $
= fold (h1 a, f) (step0 h2) ... (step0 hn) $
= step0 h2 (h1 a, f) ... (step0 hn) $
= fold (h2 (h1 a), f) ... (step0 hn) $
...
= fold (hn (... (h2 (h1 a))), f) $
= $ (hn (... (h2 (h1 a))), f)
= f (hn (... (h2 (h1 a))))</programlisting>
<section id="_example_variable_number_of_arguments">
<title>Example: variable number of arguments</title>
<simpara>The simplest example of fold is accepting a variable number of
(curried) arguments.  We&#8217;ll define a function <literal>f</literal> and argument
<literal>a</literal> such that all of the following expressions are valid.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f $
f a $
f a a $
f a a a $
f a a a ... a a a $ (* as many a's as we want *)</programlisting>
<simpara>Off-hand it may appear impossible that all of the above expressions
are type correct SML&#8201;&#8212;&#8201;how can a function <literal>f</literal> accept a variable
number of curried arguments?  What could the type of <literal>f</literal> be?
We&#8217;ll have more to say later on how type checking works.  For now,
once we have supplied the definitions below, you can check that the
expressions are type correct by feeding them to your favorite SML
implementation.</simpara>
<simpara>It is simple to define <literal>f</literal> and <literal>a</literal>.  We define <literal>f</literal> as a
folder whose base element is <literal>()</literal> and whose finish function does
nothing.  We define <literal>a</literal> as the step function that does nothing.
The only trickiness is that we must <link linkend="EtaExpansion">eta expand</link> the
definition of <literal>f</literal> and <literal>a</literal> to work around the ValueRestriction;
we frequently use eta expansion for this purpose without mention.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val base = ()
fun finish () = ()
fun step () = ()
val f = fn z =&gt; Fold.fold (base, finish) z
val a = fn z =&gt; Fold.step0 step z</programlisting>
<simpara>One can easily apply the fold equation to verify by hand that <literal>f</literal>
applied to any number of <literal>a</literal>'s evaluates to <literal>()</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a ... a $
= finish (step (... (step base)))
= finish (step (... ()))
...
= finish ()
= ()</programlisting>
</section>
<section id="_example_variable_argument_sum">
<title>Example: variable-argument sum</title>
<simpara>Let&#8217;s look at an example that computes something: a variable-argument
function <literal>sum</literal> and a stepper <literal>a</literal> such that</simpara>
<programlisting language="sml" linenumbering="unnumbered">sum (a i1) (a i2) ... (a im) $ = i1 + i2 + ... + im</programlisting>
<simpara>The idea is simple&#8201;&#8212;&#8201;the folder starts with a base accumulator of
<literal>0</literal> and the stepper adds each element to the accumulator, <literal>s</literal>,
which the folder simply returns at the end.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val sum = fn z =&gt; Fold.fold (0, fn s =&gt; s) z
fun a i = Fold.step0 (fn s =&gt; i + s)</programlisting>
<simpara>Using the fold equation, one can verify the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">sum (a 1) (a 2) (a 3) $ = 6</programlisting>
</section>
<section id="_step1">
<title>Step1</title>
<simpara>It is sometimes syntactically convenient to omit the parentheses
around the steps in a fold.  This is easily done by defining a new
function, <literal>step1</literal>, as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Fold =
   struct
      open Fold
      fun step1 h (a, f) b = fold (h (b, a), f)
   end</programlisting>
<simpara>From the definition of <literal>step1</literal>, we have the following
equivalence.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold (a, f) (step1 h) b
= step1 h (a, f) b
= fold (h (b, a), f)</programlisting>
<simpara>Using the above equivalence, we can compute the following equation for
<literal>step1</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold (a, f) (step1 h1) b1 (step1 h2) b2 ... (step1 hn) bn $
= fold (h1 (b1, a), f) (step1 h2) b2 ... (step1 hn) bn $
= fold (h2 (b2, h1 (b1, a)), f) ... (step1 hn) bn $
= fold (hn (bn, ... (h2 (b2, h1 (b1, a)))), f) $
= f (hn (bn, ... (h2 (b2, h1 (b1, a)))))</programlisting>
<simpara>Here is an example using <literal>step1</literal> to define a variable-argument
product function, <literal>prod</literal>, with a convenient syntax.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val prod = fn z =&gt; Fold.fold (1, fn p =&gt; p) z
val ` = fn z =&gt; Fold.step1 (fn (i, p) =&gt; i * p) z</programlisting>
<simpara>The functions <literal>prod</literal> and <literal>&grave;</literal> satisfy the following equation.</simpara>
<programlisting language="sml" linenumbering="unnumbered">prod `i1 `i2 ... `im $ = i1 * i2 * ... * im</programlisting>
<simpara>Note that in SML, <literal>&grave;i1</literal> is two different tokens, <literal>&grave;</literal> and
<literal>i1</literal>.  We often use <literal>&grave;</literal> for an instance of a <literal>step1</literal> function
because of its syntactic unobtrusiveness and because no space is
required to separate it from an alphanumeric token.</simpara>
<simpara>Also note that there are no parenthesis around the steps.  That is,
the following expression is not the same as the above one (in fact, it
is not type correct).</simpara>
<programlisting language="sml" linenumbering="unnumbered">prod (`i1) (`i2) ... (`im) $</programlisting>
</section>
<section id="_example_list_literals">
<title>Example: list literals</title>
<simpara>SML already has a syntax for list literals, e.g. <literal>[w, x, y, z]</literal>.
However, using fold, we can define our own syntax.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val list = fn z =&gt; Fold.fold ([], rev) z
val ` = fn z =&gt; Fold.step1 (op ::) z</programlisting>
<simpara>The idea is that the folder starts out with the empty list, the steps
accumulate the elements into a list, and then the finishing function
reverses the list at the end.</simpara>
<simpara>With these definitions one can write a list like:</simpara>
<programlisting language="sml" linenumbering="unnumbered">list `w `x `y `z $</programlisting>
<simpara>While the example is not practically useful, it does demonstrate the
need for the finishing function to be incorporated in <literal>fold</literal>.
Without a finishing function, every use of <literal>list</literal> would need to be
wrapped in <literal>rev</literal>, as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">rev (list `w `x `y `z $)</programlisting>
<simpara>The finishing function allows us to incorporate the reversal into the
definition of <literal>list</literal>, and to treat <literal>list</literal> as a truly variable
argument function, performing an arbitrary computation after receiving
all of its arguments.</simpara>
<simpara>See <link linkend="ArrayLiteral">ArrayLiteral</link> for a similar use of <literal>fold</literal> that provides a
syntax for array and vector literals, which are not built in to SML.</simpara>
</section>
<section id="_fold_right">
<title>Fold right</title>
<simpara>Just as <literal>fold</literal> is analogous to a fold left, in which the functions
are applied to the accumulator left-to-right, we can define a variant
of <literal>fold</literal> that is analogous to a fold right, in which the
functions are applied to the accumulator right-to-left.  That is, we
can define functions <literal>foldr</literal> and <literal>step0</literal> such that the
following equation holds.</simpara>
<programlisting language="sml" linenumbering="unnumbered">foldr (a, f) (step0 h1) (step0 h2) ... (step0 hn) $
= f (h1 (h2 (... (hn a))))</programlisting>
<simpara>The implementation of fold right is easy, using fold.  The idea is for
the fold to start with <literal>f</literal> and for each step to precompose the
next <literal>hi</literal>.  Then, the finisher applies the composed function to
the base value, <literal>a</literal>.  Here is the code.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Foldr =
   struct
      fun foldr (a, f) = Fold.fold (f, fn g =&gt; g a)
      fun step0 h = Fold.step0 (fn g =&gt; g o h)
   end</programlisting>
<simpara>Verifying the fold-right equation is straightforward, using the
fold-left equation.</simpara>
<programlisting language="sml" linenumbering="unnumbered">foldr (a, f) (Foldr.step0 h1) (Foldr.step0 h2) ... (Foldr.step0 hn) $
= fold (f, fn g =&gt; g a)
    (Fold.step0 (fn g =&gt; g o h1))
    (Fold.step0 (fn g =&gt; g o h2))
    ...
    (Fold.step0 (fn g =&gt; g o hn)) $
= (fn g =&gt; g a)
  ((fn g =&gt; g o hn) (... ((fn g =&gt; g o h2) ((fn g =&gt; g o h1) f))))
= (fn g =&gt; g a)
  ((fn g =&gt; g o hn) (... ((fn g =&gt; g o h2) (f o h1))))
= (fn g =&gt; g a) ((fn g =&gt; g o hn) (... (f o h1 o h2)))
= (fn g =&gt; g a) (f o h1 o h2 o ... o hn)
= (f o h1 o h2 o ... o hn) a
= f (h1 (h2 (... (hn a))))</programlisting>
<simpara>One can also define the fold-right analogue of <literal>step1</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Foldr =
   struct
      open Foldr
      fun step1 h = Fold.step1 (fn (b, g) =&gt; g o (fn a =&gt; h (b, a)))
   end</programlisting>
</section>
<section id="_example_list_literals_via_fold_right">
<title>Example: list literals via fold right</title>
<simpara>Revisiting the list literal example from earlier, we can use fold
right to define a syntax for list literals that doesn&#8217;t do a reversal.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val list = fn z =&gt; Foldr.foldr ([], fn l =&gt; l) z
val ` = fn z =&gt; Foldr.step1 (op ::) z</programlisting>
<simpara>As before, with these definitions, one can write a list like:</simpara>
<programlisting language="sml" linenumbering="unnumbered">list `w `x `y `z $</programlisting>
<simpara>The difference between the fold-left and fold-right approaches is that
the fold-right approach does not have to reverse the list at the end,
since it accumulates the elements in the correct order.  In practice,
MLton will simplify away all of the intermediate function composition,
so the the fold-right approach will be more efficient.</simpara>
</section>
<section id="_mixing_steppers">
<title>Mixing steppers</title>
<simpara>All of the examples so far have used the same step function throughout
a fold.  This need not be the case.  For example, consider the
following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val n = fn z =&gt; Fold.fold (0, fn i =&gt; i) z
val I = fn z =&gt; Fold.step0 (fn i =&gt; i * 2) z
val O = fn z =&gt; Fold.step0 (fn i =&gt; i * 2 + 1) z</programlisting>
<simpara>Here we have one folder, <literal>n</literal>, that can be used with two different
steppers, <literal>I</literal> and <literal>O</literal>.  By using the fold equation, one can
verify the following equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">n O $ = 0
n I $ = 1
n I O $ = 2
n I O I $ = 5
n I I I O $ = 14</programlisting>
<simpara>That is, we&#8217;ve defined a syntax for writing binary integer constants.</simpara>
<simpara>Not only can one use different instances of <literal>step0</literal> in the same
fold, one can also intermix uses of <literal>step0</literal> and <literal>step1</literal>.  For
example, consider the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val n = fn z =&gt; Fold.fold (0, fn i =&gt; i) z
val O = fn z =&gt; Fold.step0 (fn i =&gt; n * 8) z
val ` = fn z =&gt; Fold.step1 (fn (i, n) =&gt; n * 8 + i) z</programlisting>
<simpara>Using the straightforward generalization of the fold equation to mixed
steppers, one can verify the following equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">n 0 $ = 0
n `3 O $ = 24
n `1 O `7 $ = 71</programlisting>
<simpara>That is, we&#8217;ve defined a syntax for writing octal integer constants,
with a special syntax, <literal>O</literal>, for the zero digit (admittedly
contrived, since one could just write <literal>&grave;0</literal> instead of <literal>O</literal>).</simpara>
<simpara>See <link linkend="NumericLiteral">NumericLiteral</link> for a practical extension of this approach that
supports numeric constants in any base and of any type.</simpara>
</section>
<section id="_seemingly_dependent_types">
<title>(Seemingly) dependent types</title>
<simpara>A normal list fold always returns the same type no matter what
elements are in the list or how long the list is.  Variable-argument
fold is more powerful, because the result type can vary based both on
the arguments that are passed and on their number.  This can provide
the illusion of dependent types.</simpara>
<simpara>For example, consider the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = fn z =&gt; Fold.fold ((), id) z
val a = fn z =&gt; Fold.step0 (fn () =&gt; "hello") z
val b = fn z =&gt; Fold.step0 (fn () =&gt; 13) z
val c = fn z =&gt; Fold.step0 (fn () =&gt; (1, 2)) z</programlisting>
<simpara>Using the fold equation, one can verify the following equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a $ = "hello": string
f b $ = 13: int
f c $ = (1, 2): int * int</programlisting>
<simpara>That is, <literal>f</literal> returns a value of a different type depending on
whether it is applied to argument <literal>a</literal>, argument <literal>b</literal>, or
argument <literal>c</literal>.</simpara>
<simpara>The following example shows how the type of a fold can depend on the
number of arguments.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val grow = fn z =&gt; Fold.fold ([], fn l =&gt; l) z
val a = fn z =&gt; Fold.step0 (fn x =&gt; [x]) z</programlisting>
<simpara>Using the fold equation, one can verify the following equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">grow $ = []: 'a list
grow a $ = [[]]: 'a list list
grow a a $ = [[[]]]: 'a list list list</programlisting>
<simpara>Clearly, the result type of a call to the variable argument <literal>grow</literal>
function depends on the number of arguments that are passed.</simpara>
<simpara>As a reminder, this is well-typed SML.  You can check it out in any
implementation.</simpara>
</section>
<section id="_seemingly_dependently_typed_functional_results">
<title>(Seemingly) dependently-typed functional results</title>
<simpara>Fold is especially useful when it returns a curried function whose
arity depends on the number of arguments.  For example, consider the
following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val makeSum = fn z =&gt; Fold.fold (id, fn f =&gt; f 0) z
val I = fn z =&gt; Fold.step0 (fn f =&gt; fn i =&gt; fn x =&gt; f (x + i)) z</programlisting>
<simpara>The <literal>makeSum</literal> folder constructs a function whose arity depends on
the number of <literal>I</literal> arguments and that adds together all of its
arguments.  For example,
<literal>makeSum I $</literal> is of type <literal>int -&gt; int</literal> and
<literal>makeSum I I $</literal> is of type <literal>int -&gt; int -&gt; int</literal>.</simpara>
<simpara>One can use the fold equation to verify that the <literal>makeSum</literal> works
correctly.  For example, one can easily check by hand the following
equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">makeSum I $ 1 = 1
makeSum I I $ 1 2 = 3
makeSum I I I $ 1 2 3 = 6</programlisting>
<simpara>Returning a function becomes especially interesting when there are
steppers of different types.  For example, the following <literal>makeSum</literal>
folder constructs functions that sum integers and reals.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val makeSum = fn z =&gt; Foldr.foldr (id, fn f =&gt; f 0.0) z
val I = fn z =&gt; Foldr.step0 (fn f =&gt; fn x =&gt; fn i =&gt; f (x + real i)) z
val R = fn z =&gt; Foldr.step0 (fn f =&gt; fn x: real =&gt; fn r =&gt; f (x + r)) z</programlisting>
<simpara>With these definitions, <literal>makeSum I R $</literal> is of type
<literal>int -&gt; real -&gt; real</literal> and <literal>makeSum R I I $</literal> is of type
<literal>real -&gt; int -&gt; int -&gt; real</literal>.  One can use the foldr equation to
check the following equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">makeSum I $ 1 = 1.0
makeSum I R $ 1 2.5 = 3.5
makeSum R I I $ 1.5 2 3 = 6.5</programlisting>
<simpara>We used <literal>foldr</literal> instead of <literal>fold</literal> for this so that the order
in which the specifiers <literal>I</literal> and <literal>R</literal> appear is the same as the
order in which the arguments appear.  Had we used <literal>fold</literal>, things
would have been reversed.</simpara>
<simpara>An extension of this idea is sufficient to define <link linkend="Printf">Printf</link>-like
functions in SML.</simpara>
</section>
<section id="_an_idiom_for_combining_steps">
<title>An idiom for combining steps</title>
<simpara>It is sometimes useful to combine a number of steps together and name
them as a single step.  As a simple example, suppose that one often
sees an integer follower by a real in the <literal>makeSum</literal> example above.
One can define a new <emphasis>compound step</emphasis> <literal>IR</literal> as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val IR = fn u =&gt; Fold.fold u I R</programlisting>
<simpara>With this definition in place, one can verify the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">makeSum IR IR $ 1 2.2 3 4.4 = 10.6</programlisting>
<simpara>In general, one can combine steps <literal>s1</literal>, <literal>s2</literal>, &#8230; <literal>sn</literal> as</simpara>
<programlisting language="sml" linenumbering="unnumbered">fn u =&gt; Fold.fold u s1 s2 ... sn</programlisting>
<simpara>The following calculation shows why a compound step behaves as the
composition of its constituent steps.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold u (fn u =&gt; fold u s1 s2 ... sn)
= (fn u =&gt; fold u s1 s2 ... sn) u
= fold u s1 s2 ... sn</programlisting>
</section>
<section id="_post_composition">
<title>Post composition</title>
<simpara>Suppose we already have a function defined via fold,
<literal>w = fold (a, f)</literal>, and we would like to construct a new fold
function that is like <literal>w</literal>, but applies <literal>g</literal> to the result
produced by <literal>w</literal>.  This is similar to function composition, but we
can&#8217;t just do <literal>g o w</literal>, because we don&#8217;t want to use <literal>g</literal> until
<literal>w</literal> has been applied to all of its arguments and received the
end-of-arguments terminator <literal>$</literal>.</simpara>
<simpara>More precisely, we want to define a post-composition function
<literal>post</literal> that satisfies the following equation.</simpara>
<programlisting language="sml" linenumbering="unnumbered">post (w, g) s1 ... sn $ = g (w s1 ... sn $)</programlisting>
<simpara>Here is the definition of <literal>post</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Fold =
   struct
      open Fold
      fun post (w, g) s = w (fn (a, h) =&gt; s (a, g o h))
   end</programlisting>
<simpara>The following calculations show that <literal>post</literal> satisfies the desired
equation, where <literal>w = fold (a, f)</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">post (w, g) s
= w (fn (a, h) =&gt; s (a, g o h))
= fold (a, f) (fn (a, h) =&gt; s (a, g o h))
= (fn (a, h) =&gt; s (a, g o h)) (a, f)
= s (a, g o f)
= fold (a, g o f) s</programlisting>
<simpara>Now, suppose <literal>si = step0 hi</literal> for <literal>i</literal> from <literal>1</literal> to <literal>n</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">post (w, g) s1 s2 ... sn $
= fold (a, g o f) s1 s2 ... sn $
= (g o f) (hn (... (h1 a)))
= g (f (hn (... (h1 a))))
= g (fold (a, f) s1 ... sn $)
= g (w s1 ... sn $)</programlisting>
<simpara>For a practical example of post composition, see <link linkend="ArrayLiteral">ArrayLiteral</link>.</simpara>
</section>
<section id="_lift">
<title>Lift</title>
<simpara>We now define a peculiar-looking function, <literal>lift0</literal>, that is,
equationally speaking, equivalent to the identity function on a step
function.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun lift0 s (a, f) = fold (fold (a, id) s $, f)</programlisting>
<simpara>Using the definitions, we can prove the following equation.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold (a, f) (lift0 (step0 h)) = fold (a, f) (step0 h)</programlisting>
<simpara>Here is the proof.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fold (a, f) (lift0 (step0 h))
= lift0 (step0 h) (a, f)
= fold (fold (a, id) (step0 h) $, f)
= fold (step0 h (a, id) $, f)
= fold (fold (h a, id) $, f)
= fold ($ (h a, id), f)
= fold (id (h a), f)
= fold (h a, f)
= step0 h (a, f)
= fold (a, f) (step0 h)</programlisting>
<simpara>If <literal>lift0</literal> is the identity, then why even define it?  The answer
lies in the typing of fold expressions, which we have, until now, left
unexplained.</simpara>
</section>
<section id="_typing">
<title>Typing</title>
<simpara>Perhaps the most surprising aspect of fold is that it can be checked
by the SML type system.  The types involved in fold expressions are
complex; fortunately type inference is able to deduce them.
Nevertheless, it is instructive to study the types of fold functions
and steppers.  More importantly, it is essential to understand the
typing aspects of fold in order to write down signatures of functions
defined using fold and step.</simpara>
<simpara>Here is the <literal>FOLD</literal> signature, and a recapitulation of the entire
<literal>Fold</literal> structure, with additional type annotations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature FOLD =
   sig
      type ('a, 'b, 'c, 'd) step = 'a * ('b -&gt; 'c) -&gt; 'd
      type ('a, 'b, 'c, 'd) t = ('a, 'b, 'c, 'd) step -&gt; 'd
      type ('a1, 'a2, 'b, 'c, 'd) step0 =
         ('a1, 'b, 'c, ('a2, 'b, 'c, 'd) t) step
      type ('a11, 'a12, 'a2, 'b, 'c, 'd) step1 =
         ('a12, 'b, 'c, 'a11 -&gt; ('a2, 'b, 'c, 'd) t) step

      val fold: 'a * ('b -&gt; 'c) -&gt; ('a, 'b, 'c, 'd) t
      val lift0: ('a1, 'a2, 'a2, 'a2, 'a2) step0
                 -&gt; ('a1, 'a2, 'b, 'c, 'd) step0
      val post: ('a, 'b, 'c1, 'd) t * ('c1 -&gt; 'c2)
                -&gt; ('a, 'b, 'c2, 'd) t
      val step0: ('a1 -&gt; 'a2) -&gt; ('a1, 'a2, 'b, 'c, 'd) step0
      val step1: ('a11 * 'a12 -&gt; 'a2)
                 -&gt; ('a11, 'a12, 'a2, 'b, 'c, 'd) step1
   end

structure Fold:&gt; FOLD =
   struct
      type ('a, 'b, 'c, 'd) step = 'a * ('b -&gt; 'c) -&gt; 'd

      type ('a, 'b, 'c, 'd) t = ('a, 'b, 'c, 'd) step -&gt; 'd

      type ('a1, 'a2, 'b, 'c, 'd) step0 =
         ('a1, 'b, 'c, ('a2, 'b, 'c, 'd) t) step

      type ('a11, 'a12, 'a2, 'b, 'c, 'd) step1 =
         ('a12, 'b, 'c, 'a11 -&gt; ('a2, 'b, 'c, 'd) t) step

      fun fold (a: 'a, f: 'b -&gt; 'c)
               (g: ('a, 'b, 'c, 'd) step): 'd =
         g (a, f)

      fun step0 (h: 'a1 -&gt; 'a2)
                (a1: 'a1, f: 'b -&gt; 'c): ('a2, 'b, 'c, 'd) t =
         fold (h a1, f)

      fun step1 (h: 'a11 * 'a12 -&gt; 'a2)
                (a12: 'a12, f: 'b -&gt; 'c)
                (a11: 'a11): ('a2, 'b, 'c, 'd) t =
         fold (h (a11, a12), f)

      fun lift0 (s: ('a1, 'a2, 'a2, 'a2, 'a2) step0)
                (a: 'a1, f: 'b -&gt; 'c): ('a2, 'b, 'c, 'd) t =
         fold (fold (a, id) s $, f)

      fun post (w: ('a, 'b, 'c1, 'd) t,
                g: 'c1 -&gt; 'c2)
               (s: ('a, 'b, 'c2, 'd) step): 'd =
         w (fn (a, h) =&gt; s (a, g o h))
   end</programlisting>
<simpara>That&#8217;s a lot to swallow, so let&#8217;s walk through it one step at a time.
First, we have the definition of type <literal>Fold.step</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b, 'c, 'd) step = 'a * ('b -&gt; 'c) -&gt; 'd</programlisting>
<simpara>As a fold proceeds over its arguments, it maintains two things: the
accumulator, of type <literal>'a</literal>, and the finishing function, of type
<literal>'b -&gt; 'c</literal>.  Each step in the fold is a function that takes those
two pieces (i.e. <literal>'a * ('b -&gt; 'c)</literal> and does something to them
(i.e. produces <literal>'d</literal>).  The result type of the step is completely
left open to be filled in by type inference, as it is an arrow type
that is capable of consuming the rest of the arguments to the fold.</simpara>
<simpara>A folder, of type <literal>Fold.t</literal>, is a function that consumes a single
step.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b, 'c, 'd) t = ('a, 'b, 'c, 'd) step -&gt; 'd</programlisting>
<simpara>Expanding out the type, we have:</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b, 'c, 'd) t = ('a * ('b -&gt; 'c) -&gt; 'd) -&gt; 'd</programlisting>
<simpara>This shows that the only thing a folder does is to hand its
accumulator (<literal>'a</literal>) and finisher (<literal>'b -&gt; 'c</literal>) to the next step
(<literal>'a * ('b -&gt; 'c) -&gt; 'd</literal>).  If SML had <link linkend="FirstClassPolymorphism">first-class polymorphism</link>,
we would write the fold type as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b, 'c) t = Forall 'd . ('a, 'b, 'c, 'd) step -&gt; 'd</programlisting>
<simpara>This type definition shows that a folder had nothing to do with
the rest of the fold, it only deals with the next step.</simpara>
<simpara>We now can understand the type of <literal>fold</literal>, which takes the initial
value of the accumulator and the finishing function, and constructs a
folder, i.e. a function awaiting the next step.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val fold: 'a * ('b -&gt; 'c) -&gt; ('a, 'b, 'c, 'd) t
fun fold (a: 'a, f: 'b -&gt; 'c)
         (g: ('a, 'b, 'c, 'd) step): 'd =
   g (a, f)</programlisting>
<simpara>Continuing on, we have the type of step functions.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a1, 'a2, 'b, 'c, 'd) step0 =
   ('a1, 'b, 'c, ('a2, 'b, 'c, 'd) t) step</programlisting>
<simpara>Expanding out the type a bit gives:</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a1, 'a2, 'b, 'c, 'd) step0 =
   'a1 * ('b -&gt; 'c) -&gt; ('a2, 'b, 'c, 'd) t</programlisting>
<simpara>So, a step function takes the accumulator (<literal>'a1</literal>) and finishing
function (<literal>'b -&gt; 'c</literal>), which will be passed to it by the previous
folder, and transforms them to a new folder.  This new folder has a
new accumulator (<literal>'a2</literal>) and the same finishing function.</simpara>
<simpara>Again, imagining that SML had <link linkend="FirstClassPolymorphism">first-class polymorphism</link> makes the type
clearer.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a1, 'a2) step0 =
   Forall ('b, 'c) . ('a1, 'b, 'c, ('a2, 'b, 'c) t) step</programlisting>
<simpara>Thus, in essence, a <literal>step0</literal> function is a wrapper around a
function of type <literal>'a1 -&gt; 'a2</literal>, which is exactly what the
definition of <literal>step0</literal> does.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val step0: ('a1 -&gt; 'a2) -&gt; ('a1, 'a2, 'b, 'c, 'd) step0
fun step0 (h: 'a1 -&gt; 'a2)
          (a1: 'a1, f: 'b -&gt; 'c): ('a2, 'b, 'c, 'd) t =
   fold (h a1, f)</programlisting>
<simpara>It is not much beyond <literal>step0</literal> to understand <literal>step1</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a11, 'a12, 'a2, 'b, 'c, 'd) step1 =
   ('a12, 'b, 'c, 'a11 -&gt; ('a2, 'b, 'c, 'd) t) step</programlisting>
<simpara>A <literal>step1</literal> function takes the accumulator (<literal>'a12</literal>) and finisher
(<literal>'b -&gt; 'c</literal>) passed to it by the previous folder and transforms
them into a function that consumes the next argument (<literal>'a11</literal>) and
produces a folder that will continue the fold with a new accumulator
(<literal>'a2</literal>) and the same finisher.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun step1 (h: 'a11 * 'a12 -&gt; 'a2)
          (a12: 'a12, f: 'b -&gt; 'c)
          (a11: 'a11): ('a2, 'b, 'c, 'd) t =
   fold (h (a11, a12), f)</programlisting>
<simpara>With <link linkend="FirstClassPolymorphism">first-class polymorphism</link>, a <literal>step1</literal> function is more clearly
seen as a wrapper around a binary function of type
<literal>'a11 * 'a12 -&gt; 'a2</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a11, 'a12, 'a2) step1 =
   Forall ('b, 'c) . ('a12, 'b, 'c, 'a11 -&gt; ('a2, 'b, 'c) t) step</programlisting>
<simpara>The type of <literal>post</literal> is clear: it takes a folder with a finishing
function that produces type <literal>'c1</literal>, and a function of type
<literal>'c1 -&gt; 'c2</literal> to postcompose onto the folder.  It returns a new
folder with a finishing function that produces type <literal>'c2</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val post: ('a, 'b, 'c1, 'd) t * ('c1 -&gt; 'c2)
          -&gt; ('a, 'b, 'c2, 'd) t
fun post (w: ('a, 'b, 'c1, 'd) t,
          g: 'c1 -&gt; 'c2)
         (s: ('a, 'b, 'c2, 'd) step): 'd =
   w (fn (a, h) =&gt; s (a, g o h))</programlisting>
<simpara>We will return to <literal>lift0</literal> after an example.</simpara>
</section>
<section id="_an_example_typing">
<title>An example typing</title>
<simpara>Let&#8217;s type check our simplest example, a variable-argument fold.
Recall that we have a folder <literal>f</literal> and a stepper <literal>a</literal> defined as
follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = fn z =&gt; Fold.fold ((), fn () =&gt; ()) z
val a = fn z =&gt; Fold.step0 (fn () =&gt; ()) z</programlisting>
<simpara>Since the accumulator and finisher are uninteresting, we&#8217;ll use some
abbreviations to simplify things.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'd step = (unit, unit, unit, 'd) Fold.step
type 'd fold = 'd step -&gt; 'd</programlisting>
<simpara>With these abbreviations, <literal>f</literal> and <literal>a</literal> have the following polymorphic
types.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f: 'd fold
a: 'd step</programlisting>
<simpara>Suppose we want to type check</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a a a $: unit</programlisting>
<simpara>As a reminder, the fully parenthesized expression is</simpara>
<programlisting language="sml" linenumbering="unnumbered">((((f a) a) a) a) $</programlisting>
<simpara>The observation that we will use repeatedly is that for any type
<literal>z</literal>, if <literal>f: z fold</literal> and <literal>s: z step</literal>, then <literal>f s: z</literal>.
So, if we want</simpara>
<programlisting language="sml" linenumbering="unnumbered">(f a a a) $: unit</programlisting>
<simpara>then we must have</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a a a: unit fold
$: unit step</programlisting>
<simpara>Applying the observation again, we must have</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a a: unit fold fold
a: unit fold step</programlisting>
<simpara>Applying the observation two more times leads to the following type
derivation.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f: unit fold fold fold fold  a: unit fold fold fold step
f a: unit fold fold fold     a: unit fold fold step
f a a: unit fold fold        a: unit fold step
f a a a: unit fold           $: unit step
f a a a $: unit</programlisting>
<simpara>So, each application is a fold that consumes the next step, producing
a fold of one smaller type.</simpara>
<simpara>One can expand some of the type definitions in <literal>f</literal> to see that it is
indeed a function that takes four curried arguments, each one a step
function.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f: unit fold fold fold step
   -&gt; unit fold fold step
   -&gt; unit fold step
   -&gt; unit step
   -&gt; unit</programlisting>
<simpara>This example shows why we must eta expand uses of <literal>fold</literal> and <literal>step0</literal>
to work around the value restriction and make folders and steppers
polymorphic.  The type of a fold function like <literal>f</literal> depends on the
number of arguments, and so will vary from use to use.  Similarly,
each occurrence of an argument like <literal>a</literal> has a different type,
depending on the number of remaining arguments.</simpara>
<simpara>This example also shows that the type of a folder, when fully
expanded, is exponential in the number of arguments: there are as many
nested occurrences of the <literal>fold</literal> type constructor as there are
arguments, and each occurrence duplicates its type argument.  One can
observe this exponential behavior in a type checker that doesn&#8217;t share
enough of the representation of types (e.g. one that represents types
as trees rather than directed acyclic graphs).</simpara>
<simpara>Generalizing this type derivation to uses of fold where the
accumulator and finisher are more interesting is straightforward.  One
simply includes the type of the accumulator, which may change, for
each step, and the type of the finisher, which doesn&#8217;t change from
step to step.</simpara>
</section>
<section id="_typing_lift">
<title>Typing lift</title>
<simpara>The lack of <link linkend="FirstClassPolymorphism">first-class polymorphism</link> in SML
causes problems if one wants to use a step in a first-class way.
Consider the following <literal>double</literal> function, which takes a step, <literal>s</literal>, and
produces a composite step that does <literal>s</literal> twice.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun double s = fn u =&gt; Fold.fold u s s</programlisting>
<simpara>The definition of <literal>double</literal> is not type correct.  The problem is that
the type of a step depends on the number of remaining arguments but
that the parameter <literal>s</literal> is not polymorphic, and so can not be used in
two different positions.</simpara>
<simpara>Fortunately, we can define a function, <literal>lift0</literal>, that takes a monotyped
step function and <emphasis>lifts</emphasis> it into a polymorphic step function.  This
is apparent in the type of <literal>lift0</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val lift0: ('a1, 'a2, 'a2, 'a2, 'a2) step0
           -&gt; ('a1, 'a2, 'b, 'c, 'd) step0
fun lift0 (s: ('a1, 'a2, 'a2, 'a2, 'a2) step0)
          (a: 'a1, f: 'b -&gt; 'c): ('a2, 'b, 'c, 'd) t =
   fold (fold (a, id) s $, f)</programlisting>
<simpara>The following definition of <literal>double</literal> uses <literal>lift0</literal>, appropriately eta
wrapped, to fix the problem.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun double s =
   let
      val s = fn z =&gt; Fold.lift0 s z
   in
      fn u =&gt; Fold.fold u s s
   end</programlisting>
<simpara>With that definition of <literal>double</literal> in place, we can use it as in the
following example.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = fn z =&gt; Fold.fold ((), fn () =&gt; ()) z
val a = fn z =&gt; Fold.step0 (fn () =&gt; ()) z
val a2 = fn z =&gt; double a z
val () = f a a2 a a2 $</programlisting>
<simpara>Of course, we must eta wrap the call <literal>double</literal> in order to use its
result, which is a step function, polymorphically.</simpara>
</section>
<section id="_hiding_the_type_of_the_accumulator">
<title>Hiding the type of the accumulator</title>
<simpara>For clarity and to avoid mistakes, it can be useful to hide the type
of the accumulator in a fold.  Reworking the simple variable-argument
example to do this leads to the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S:&gt;
  sig
     type ac
     val f: (ac, ac, unit, 'd) Fold.t
     val s: (ac, ac, 'b, 'c, 'd) Fold.step0
  end =
  struct
     type ac = unit
     val f = fn z =&gt; Fold.fold ((), fn () =&gt; ()) z
     val s = fn z =&gt; Fold.step0 (fn () =&gt; ()) z
  end</programlisting>
<simpara>The idea is to name the accumulator type and use opaque signature
matching to make it abstract.  This can prevent improper manipulation
of the accumulator by client code and ensure invariants that the
folder and stepper would like to maintain.</simpara>
<simpara>For a practical example of this technique, see <link linkend="ArrayLiteral">ArrayLiteral</link>.</simpara>
</section>
<section id="_also_see_3">
<title>Also see</title>
<simpara>Fold has a number of practical applications.  Here are some of them.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ArrayLiteral">ArrayLiteral</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Fold01N">Fold01N</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="FunctionalRecordUpdate">FunctionalRecordUpdate</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="NumericLiteral">NumericLiteral</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="OptionalArguments">OptionalArguments</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Printf">Printf</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="VariableArityPolymorphism">VariableArityPolymorphism</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>There are a number of related techniques.  Here are some of them.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="StaticSum">StaticSum</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TypeIndexedValues">TypeIndexedValues</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Fold01N">
<title>Fold01N</title>
<simpara>A common use pattern of <link linkend="Fold">Fold</link> is to define a variable-arity
function that combines multiple arguments together using a binary
function.  It is slightly tricky to do this directly using fold,
because of the special treatment required for the case of zero or one
argument.  Here is a structure, <literal>Fold01N</literal>, that solves the problem
once and for all, and eases the definition of such functions.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Fold01N =
   struct
      fun fold {finish, start, zero} =
         Fold.fold ((id, finish, fn () =&gt; zero, start),
                    fn (finish, _, p, _) =&gt; finish (p ()))

      fun step0 {combine, input} =
         Fold.step0 (fn (_, finish, _, f) =&gt;
                     (finish,
                      finish,
                      fn () =&gt; f input,
                      fn x' =&gt; combine (f input, x')))

      fun step1 {combine} z input =
         step0 {combine = combine, input = input} z
   end</programlisting>
<simpara>If one has a value <literal>zero</literal>, and functions <literal>start</literal>, <literal>c</literal>, and <literal>finish</literal>,
then one can define a variable-arity function <literal>f</literal> and stepper
<literal>&grave;</literal> as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = fn z =&gt; Fold01N.fold {finish = finish, start = start, zero = zero} z
val ` = fn z =&gt; Fold01N.step1 {combine = c} z</programlisting>
<simpara>One can then use the fold equation to prove the following equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f $ = zero
f `a1 $ = finish (start a1)
f `a1 `a2 $ = finish (c (start a1, a2))
f `a1 `a2 `a3 $ = finish (c (c (start a1, a2), a3))
...</programlisting>
<simpara>For an example of <literal>Fold01N</literal>, see <link linkend="VariableArityPolymorphism">VariableArityPolymorphism</link>.</simpara>
<section id="_typing_fold01n">
<title>Typing Fold01N</title>
<simpara>Here is the signature for <literal>Fold01N</literal>.  We use a trick to avoid having
to duplicate the definition of some rather complex types in both the
signature and the structure.  We first define the types in a
structure.  Then, we define them via type re-definitions in the
signature, and via <literal>open</literal> in the full structure.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Fold01N =
   struct
      type ('input, 'accum1, 'accum2, 'answer, 'zero,
            'a, 'b, 'c, 'd, 'e) t =
         (('zero -&gt; 'zero)
          * ('accum2 -&gt; 'answer)
          * (unit -&gt; 'zero)
          * ('input -&gt; 'accum1),
          ('a -&gt; 'b) * 'c * (unit -&gt; 'a) * 'd,
          'b,
          'e) Fold.t

       type ('input1, 'accum1, 'input2, 'accum2,
            'a, 'b, 'c, 'd, 'e, 'f) step0 =
         ('a * 'b * 'c * ('input1 -&gt; 'accum1),
          'b * 'b * (unit -&gt; 'accum1) * ('input2 -&gt; 'accum2),
          'd, 'e, 'f) Fold.step0

      type ('accum1, 'input, 'accum2,
            'a, 'b, 'c, 'd, 'e, 'f, 'g) step1 =
         ('a,
          'b * 'c * 'd * ('a -&gt; 'accum1),
          'c * 'c * (unit -&gt; 'accum1) * ('input -&gt; 'accum2),
          'e, 'f, 'g) Fold.step1
   end

signature FOLD_01N =
   sig
      type ('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j) t =
         ('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j) Fold01N.t
      type ('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j) step0 =
         ('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j) Fold01N.step0
      type ('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j) step1 =
         ('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j) Fold01N.step1

      val fold:
         {finish: 'accum2 -&gt; 'answer,
          start: 'input -&gt; 'accum1,
          zero: 'zero}
         -&gt; ('input, 'accum1, 'accum2, 'answer, 'zero,
             'a, 'b, 'c, 'd, 'e) t

      val step0:
         {combine: 'accum1 * 'input2 -&gt; 'accum2,
          input: 'input1}
         -&gt; ('input1, 'accum1, 'input2, 'accum2,
             'a, 'b, 'c, 'd, 'e, 'f) step0

      val step1:
         {combine: 'accum1 * 'input -&gt; 'accum2}
         -&gt; ('accum1, 'input, 'accum2,
             'a, 'b, 'c, 'd, 'e, 'f, 'g) step1
   end

structure Fold01N: FOLD_01N =
   struct
      open Fold01N

      fun fold {finish, start, zero} =
         Fold.fold ((id, finish, fn () =&gt; zero, start),
                    fn (finish, _, p, _) =&gt; finish (p ()))

      fun step0 {combine, input} =
         Fold.step0 (fn (_, finish, _, f) =&gt;
                     (finish,
                      finish,
                      fn () =&gt; f input,
                      fn x' =&gt; combine (f input, x')))

      fun step1 {combine} z input =
         step0 {combine = combine, input = input} z
   end</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ForeignFunctionInterface">
<title>ForeignFunctionInterface</title>
<simpara>MLton&#8217;s foreign function interface (FFI) extends Standard ML and makes
it easy to take the address of C global objects, access C global
variables, call from SML to C, and call from C to SML.  MLton also
provides <link linkend="MLNLFFI">ML-NLFFI</link>, which is a higher-level FFI for calling
C functions and manipulating C data from SML.</simpara>
<section id="_overview">
<title>Overview</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ForeignFunctionInterfaceTypes">Foreign Function Interface Types</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ForeignFunctionInterfaceSyntax">Foreign Function Interface Syntax</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_importing_code_into_sml">
<title>Importing Code into SML</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CallingFromSMLToC">Calling From SML To C</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CallingFromSMLToCFunctionPointer">Calling From SML To C Function Pointer</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_exporting_code_from_sml">
<title>Exporting Code from SML</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CallingFromCToSML">Calling From C To SML</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_building_system_libraries">
<title>Building System Libraries</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="LibrarySupport">Library Support</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ForeignFunctionInterfaceSyntax">
<title>ForeignFunctionInterfaceSyntax</title>
<simpara>MLton extends the syntax of SML with expressions that enable a
<link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> to C.  The following description of the
syntax uses some abbreviations.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="3">
<colspec colname="col_1" colwidth="33*"/>
<colspec colname="col_2" colwidth="33*"/>
<colspec colname="col_3" colwidth="33*"/>
<thead>
<row>
<entry align="left" valign="top"> C base type </entry>
<entry align="left" valign="top"> <emphasis>cBaseTy</emphasis> </entry>
<entry align="left" valign="top"> <link linkend="ForeignFunctionInterfaceTypes">Foreign Function Interface types</link></entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara>C argument type</simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cArgTy</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cBaseTy</emphasis><subscript>1</subscript> <literal>*</literal> &#8230; <literal>*</literal> <emphasis>cBaseTy</emphasis><subscript>n</subscript> or <literal>unit</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>C return type</simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cRetTy</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cBaseTy</emphasis> or <literal>unit</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>C function type</simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cFuncTy</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cArgTy</emphasis> <literal>-&gt;</literal> <emphasis>cRetTy</emphasis></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>C pointer type</simpara></entry>
<entry align="left" valign="top"><simpara><emphasis>cPtrTy</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>MLton.Pointer.t</literal></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>The type annotation and the semicolon are not optional in the syntax
of <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> expressions.  However, the type is
lexed, parsed, and elaborated as an SML type, so any type (including
type abbreviations) may be used, so long as it elaborates to a type of
the correct form.</simpara>
<section id="_address">
<title>Address</title>
<screen>_address "CFunctionOrVariableName" attr... : cPtrTy;</screen>
<simpara>Denotes the address of the C function or variable.</simpara>
<simpara><literal>attr...</literal> denotes a (possibly empty) sequence of attributes.  The following attributes are recognized:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>external</literal> : import with external symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>) (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>private</literal> : import with private symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>public</literal> : import with public symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>).
</simpara>
</listitem>
</itemizedlist>
<simpara>See <link linkend="MLtonPointer">MLtonPointer</link> for functions that manipulate C pointers.</simpara>
</section>
<section id="_symbol">
<title>Symbol</title>
<screen>_symbol "CVariableName" attr... : (unit -&gt; cBaseTy) * (cBaseTy -&gt; unit);</screen>
<simpara>Denotes the <emphasis>getter</emphasis> and <emphasis>setter</emphasis> for a C variable.  The <emphasis>cBaseTy</emphasis>s
must be identical.</simpara>
<simpara><literal>attr...</literal> denotes a (possibly empty) sequence of attributes.  The following attributes are recognized:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>alloc</literal> : allocate storage (and export a symbol) for the C variable.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>external</literal> : import or export with external symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>) (default if not <literal>alloc</literal>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>private</literal> : import or export with private symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>public</literal> : import or export with public symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>) (default if <literal>alloc</literal>).
</simpara>
</listitem>
</itemizedlist>
<screen>_symbol * : cPtrTy -&gt; (unit -&gt; cBaseTy) * (cBaseTy -&gt; unit);</screen>
<simpara>Denotes the <emphasis>getter</emphasis> and <emphasis>setter</emphasis> for a C pointer to a variable.
The <emphasis>cBaseTy</emphasis>s must be identical.</simpara>
</section>
<section id="_import">
<title>Import</title>
<screen>_import "CFunctionName" attr... : cFuncTy;</screen>
<simpara>Denotes an SML function whose behavior is implemented by calling the C
function.  See <link linkend="CallingFromSMLToC">Calling from SML to C</link> for more
details.</simpara>
<simpara><literal>attr...</literal> denotes a (possibly empty) sequence of attributes.  The following attributes are recognized:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>cdecl</literal> : call with the <literal>cdecl</literal> calling convention (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>external</literal> : import with external symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>) (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>impure</literal>: assert that the function depends upon state and/or performs side effects (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>private</literal> : import with private symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>public</literal> : import with public symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>pure</literal>: assert that the function does not depend upon state or perform any side effects; such functions are subject to various optimizations (e.g., <link linkend="CommonSubexp">CommonSubexp</link>, <link linkend="RemoveUnused">RemoveUnused</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>reentrant</literal>: assert that the function (directly or indirectly) calls an <literal>_export</literal>-ed SML function.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>stdcall</literal> : call with the <literal>stdcall</literal> calling convention (ignored except on Cygwin and MinGW).
</simpara>
</listitem>
</itemizedlist>
<screen>_import * attr... : cPtrTy -&gt; cFuncTy;</screen>
<simpara>Denotes an SML function whose behavior is implemented by calling a C
function through a C function pointer.</simpara>
<simpara><literal>attr...</literal> denotes a (possibly empty) sequence of attributes.  The following attributes are recognized:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>cdecl</literal> : call with the <literal>cdecl</literal> calling convention (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>impure</literal>: assert that the function depends upon state and/or performs side effects (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>pure</literal>: assert that the function does not depend upon state or perform any side effects; such functions are subject to various optimizations (e.g., <link linkend="CommonSubexp">CommonSubexp</link>, <link linkend="RemoveUnused">RemoveUnused</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>reentrant</literal>: assert that the function (directly or indirectly) calls an <literal>_export</literal>-ed SML function.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>stdcall</literal> : call with the <literal>stdcall</literal> calling convention (ignored except on Cygwin and MinGW).
</simpara>
</listitem>
</itemizedlist>
<simpara>See
<link linkend="CallingFromSMLToCFunctionPointer">Calling from SML to C function pointer</link>
for more details.</simpara>
</section>
<section id="_export">
<title>Export</title>
<screen>_export "CFunctionName" attr... : cFuncTy -&gt; unit;</screen>
<simpara>Exports a C function with the name <literal>CFunctionName</literal> that can be used to
call an SML function of the type <emphasis>cFuncTy</emphasis>. When the function denoted
by the export expression is applied to an SML function <literal>f</literal>, subsequent
C calls to <literal>CFunctionName</literal> will call <literal>f</literal>.  It is an error to call
<literal>CFunctionName</literal> before the export has been applied.  The export may be
applied more than once, with each application replacing any previous
definition of <literal>CFunctionName</literal>.</simpara>
<simpara><literal>attr...</literal> denotes a (possibly empty) sequence of attributes.  The following attributes are recognized:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>cdecl</literal> : call with the <literal>cdecl</literal> calling convention (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>private</literal> : export with private symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>public</literal> : export with public symbol scope (see <link linkend="LibrarySupport">LibrarySupport</link>) (default).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>stdcall</literal> : call with the <literal>stdcall</literal> calling convention (ignored except on Cygwin and MinGW).
</simpara>
</listitem>
</itemizedlist>
<simpara>See <link linkend="CallingFromCToSML">Calling from C to SML</link> for more details.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ForeignFunctionInterfaceTypes">
<title>ForeignFunctionInterfaceTypes</title>
<simpara>MLton&#8217;s <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> only allows values of certain SML
types to be passed between SML and C.  The following types are
allowed: <literal>bool</literal>, <literal>char</literal>, <literal>int</literal>, <literal>real</literal>, <literal>word</literal>.  All of the different
sizes of (fixed-sized) integers, reals, and words are supported as
well: <literal>Int8.int</literal>, <literal>Int16.int</literal>, <literal>Int32.int</literal>, <literal>Int64.int</literal>,
<literal>Real32.real</literal>, <literal>Real64.real</literal>, <literal>Word8.word</literal>, <literal>Word16.word</literal>,
<literal>Word32.word</literal>, <literal>Word64.word</literal>.  There is a special type,
<literal>MLton.Pointer.t</literal>, for passing C pointers&#8201;&#8212;&#8201;see <link linkend="MLtonPointer">MLtonPointer</link> for
details.</simpara>
<simpara>Arrays, refs, and vectors of the above types are also allowed.
Because in MLton monomorphic arrays and vectors are exactly the same
as their polymorphic counterpart, these are also allowed.  Hence,
<literal>string</literal>, <literal>char vector</literal>, and <literal>CharVector.vector</literal> are also allowed.
Strings are not null terminated, unless you manually do so from the
SML side.</simpara>
<simpara>Unfortunately, passing tuples or datatypes is not allowed because that
would interfere with representation optimizations.</simpara>
<simpara>The C header file that <literal>-export-header</literal> generates includes
<literal>typedef</literal>s for the C types corresponding to the SML types.  Here is
the mapping between SML types and C types.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="4">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="25*"/>
<colspec colname="col_3" colwidth="25*"/>
<colspec colname="col_4" colwidth="25*"/>
<thead>
<row>
<entry align="left" valign="top"> SML type </entry>
<entry align="left" valign="top"> C typedef </entry>
<entry align="left" valign="top"> C type </entry>
<entry align="left" valign="top"> Note</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>array</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Pointer</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>unsigned char *</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>bool</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Bool</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>int32_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>char</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Char8</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>uint8_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Int8.int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int8</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>int8_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Int16.int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int16</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>int16_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Int32.int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int32</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>int32_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Int64.int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int64</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>int64_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int32</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>int32_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><link linkend="ForeignFunctionInterfaceTypes_Default">(default)</link></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>MLton.Pointer.t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Pointer</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>unsigned char *</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Real32.real</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Real32</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>float</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Real64.real</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Real64</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>double</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>real</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Real64</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>double</literal></simpara></entry>
<entry align="left" valign="top"><simpara><link linkend="ForeignFunctionInterfaceTypes_Default">(default)</link></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>ref</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Pointer</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>unsigned char *</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>string</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Pointer</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>unsigned char *</literal></simpara></entry>
<entry align="left" valign="top"><simpara><link linkend="ForeignFunctionInterfaceTypes_ReadOnly">(read only)</link></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>vector</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Pointer</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>unsigned char *</literal></simpara></entry>
<entry align="left" valign="top"><simpara><link linkend="ForeignFunctionInterfaceTypes_ReadOnly">(read only)</link></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Word8.word</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word8</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>uint8_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Word16.word</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word16</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>uint16_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Word32.word</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word32</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>uint32_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>Word64.word</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word64</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>uint64_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>word</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word32</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>uint32_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><link linkend="ForeignFunctionInterfaceTypes_Default">(default)</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><anchor id="ForeignFunctionInterfaceTypes_Default" xreflabel="[ForeignFunctionInterfaceTypes_Default]"/>Note (default): The default <literal>int</literal>, <literal>real</literal>, and
<literal>word</literal> types may be set by the <literal>-default-type <emphasis>type</emphasis></literal>
<link linkend="CompileTimeOptions">compiler option</link>.  The given C typedef and C
types correspond to the default behavior.</simpara>
<simpara><anchor id="ForeignFunctionInterfaceTypes_ReadOnly" xreflabel="[ForeignFunctionInterfaceTypes_ReadOnly]"/>Note (read only): Because MLton assumes that
vectors and strings are read-only (and will perform optimizations
that, for instance, cause them to share space), you must not modify
the data pointed to by the <literal>unsigned char *</literal> in C code.</simpara>
<simpara>Although the C type of an array, ref, or vector is always <literal>Pointer</literal>,
in reality, the object has the natural C representation.  Your C code
should cast to the appropriate C type if you want to keep the C
compiler from complaining.</simpara>
<simpara>When calling an <link linkend="CallingFromSMLToC">imported C function from SML</link>
that returns an array, ref, or vector result or when calling an
<link linkend="CallingFromCToSML">exported SML function from C</link> that takes an
array, ref, or string argument, then the object must be an ML object
allocated on the ML heap.  (Although an array, ref, or vector object
has the natural C representation, the object also has an additional
header used by the SML runtime system.)</simpara>
<simpara>In addition, there is an <link linkend="MLBasis">MLBasis</link> file, <literal>$(SML_LIB)/basis/c-types.mlb</literal>,
which provides structure aliases for various C types:</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="3">
<colspec colname="col_1" colwidth="33*"/>
<colspec colname="col_2" colwidth="33*"/>
<colspec colname="col_3" colwidth="33*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara>C type</simpara></entry>
<entry align="left" valign="top"><simpara>Structure</simpara></entry>
<entry align="left" valign="top"><simpara>Signature</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>char</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Char</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>signed char</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_SChar</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>unsigned char</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_UChar</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>short</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Short</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>signed short</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_SShort</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>unsigned short</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_UShort</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>signed int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_SInt</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>unsigned int</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_UInt</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>signed long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_SLong</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>unsigned long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_ULong</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>long long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_LongLong</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>signed long long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_SLongLong</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>unsigned long long</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_ULongLong</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>float</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Float</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>REAL</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>double</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Double</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>REAL</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>size_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Size</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>ptrdiff_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Ptrdiff</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>intmax_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Intmax</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>uintmax_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_UIntmax</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>intptr_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Intptr</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>INTEGER</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>uintptr_t</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_UIntptr</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>void *</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>C_Pointer</literal></simpara></entry>
<entry align="left" valign="top"><simpara><literal>WORD</literal></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>These aliases depend on the configuration of the C compiler for the
target architecture, and are independent of the configuration of MLton
(including the <literal>-default-type <emphasis>type</emphasis></literal>
<link linkend="CompileTimeOptions">compiler option</link>).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ForLoops">
<title>ForLoops</title>
<simpara>A <literal>for</literal>-loop is typically used to iterate over a range of consecutive
integers that denote indices of some sort.  For example, in <link linkend="OCaml">OCaml</link>
a <literal>for</literal>-loop takes either the form</simpara>
<screen>for &lt;name&gt; = &lt;lower&gt; to &lt;upper&gt; do &lt;body&gt; done</screen>
<simpara>or the form</simpara>
<screen>for &lt;name&gt; = &lt;upper&gt; downto &lt;lower&gt; do &lt;body&gt; done</screen>
<simpara>Some languages provide considerably more flexible <literal>for</literal>-loop or
<literal>foreach</literal>-constructs.</simpara>
<simpara>A bit surprisingly, <link linkend="StandardML">Standard ML</link> provides special syntax
for <literal>while</literal>-loops, but not for <literal>for</literal>-loops.  Indeed, in SML, many uses
of <literal>for</literal>-loops are better expressed using <literal>app</literal>, <literal>foldl</literal>/<literal>foldr</literal>,
<literal>map</literal> and many other higher-order functions provided by the
<link linkend="BasisLibrary">Basis Library</link> for manipulating lists, vectors and
arrays.  However, the Basis Library does not provide a function for
iterating over a range of integer values.  Fortunately, it is very
easy to write one.</simpara>
<section id="_a_fairly_simple_design">
<title>A fairly simple design</title>
<simpara>The following implementation imitates both the syntax and semantics of
the OCaml <literal>for</literal>-loop.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype for = to of int * int
             | downto of int * int

infix to downto

val for =
    fn lo to up =&gt;
       (fn f =&gt; let fun loop lo = if lo &gt; up then ()
                                  else (f lo; loop (lo+1))
                in loop lo end)
     | up downto lo =&gt;
       (fn f =&gt; let fun loop up = if up &lt; lo then ()
                                  else (f up; loop (up-1))
                in loop up end)</programlisting>
<simpara>For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">for (1 to 9)
    (fn i =&gt; print (Int.toString i))</programlisting>
<simpara>would print <literal>123456789</literal> and</simpara>
<programlisting language="sml" linenumbering="unnumbered">for (9 downto 1)
    (fn i =&gt; print (Int.toString i))</programlisting>
<simpara>would print <literal>987654321</literal>.</simpara>
<simpara>Straightforward formatting of nested loops</simpara>
<programlisting language="sml" linenumbering="unnumbered">for (a to b)
    (fn i =&gt;
        for (c to d)
            (fn j =&gt;
                ...))</programlisting>
<simpara>is fairly readable, but tends to cause the body of the loop to be
indented quite deeply.</simpara>
</section>
<section id="_off_by_one">
<title>Off-by-one</title>
<simpara>The above design has an annoying feature.  In practice, the upper
bound of the iterated range is almost always excluded and most loops
would subtract one from the upper bound:</simpara>
<programlisting language="sml" linenumbering="unnumbered">for (0 to n-1) ...
for (n-1 downto 0) ...</programlisting>
<simpara>It is probably better to break convention and exclude the upper bound
by default, because it leads to more concise code and becomes
idiomatic with very little practice.  The iterator combinators
described below exclude the upper bound by default.</simpara>
</section>
<section id="_iterator_combinators">
<title>Iterator combinators</title>
<simpara>While the simple <literal>for</literal>-function described in the previous section is
probably good enough for many uses, it is a bit cumbersome when one
needs to iterate over a Cartesian product.  One might also want to
iterate over more than just consecutive integers.  It turns out that
one can provide a library of iterator combinators that allow one to
implement iterators more flexibly.</simpara>
<simpara>Since the types of the combinators may be a bit difficult to infer
from their implementations, let&#8217;s first take a look at a signature of
the iterator combinator library:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature ITER =
  sig
    type 'a t = ('a -&gt; unit) -&gt; unit

    val return : 'a -&gt; 'a t
    val &gt;&gt;= : 'a t * ('a -&gt; 'b t) -&gt; 'b t

    val none : 'a t

    val to : int * int -&gt; int t
    val downto : int * int -&gt; int t

    val inList : 'a list -&gt; 'a t
    val inVector : 'a vector -&gt; 'a t
    val inArray : 'a array -&gt; 'a t

    val using : ('a, 'b) StringCvt.reader -&gt; 'b -&gt; 'a t

    val when : 'a t * ('a -&gt; bool) -&gt; 'a t
    val by : 'a t * ('a -&gt; 'b) -&gt; 'b t
    val @@ : 'a t * 'a t -&gt; 'a t
    val ** : 'a t * 'b t -&gt; ('a, 'b) product t

    val for : 'a -&gt; 'a
  end</programlisting>
<simpara>Several of the above combinators are meant to be used as infix
operators.  Here is a set of suitable infix declarations:</simpara>
<programlisting language="sml" linenumbering="unnumbered">infix 2 to downto
infix 1 @@ when by
infix 0 &gt;&gt;= **</programlisting>
<simpara>A few notes are in order:</simpara>
<itemizedlist>
<listitem>
<simpara>
The <literal>'a t</literal> type constructor with the <literal>return</literal> and <literal>&gt;&gt;=</literal> operators forms a monad.
</simpara>
</listitem>
<listitem>
<simpara>
The <literal>to</literal> and <literal>downto</literal> combinators will omit the upper bound of the range.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>for</literal> is the identity function.  It is purely for syntactic sugar and is not strictly required.
</simpara>
</listitem>
<listitem>
<simpara>
The <literal>@@</literal> combinator produces an iterator for the concatenation of the given iterators.
</simpara>
</listitem>
<listitem>
<simpara>
The <literal>**</literal> combinator produces an iterator for the Cartesian product of the given iterators.
</simpara>
<itemizedlist>
<listitem>
<simpara>
See <link linkend="ProductType">ProductType</link> for the type constructor <literal>('a, 'b) product</literal> used in the type of the iterator produced by <literal>**</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
The <literal>using</literal> combinator allows one to iterate over slices, streams and many other kinds of sequences.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>when</literal> is the filtering combinator.  The name <literal>when</literal> is   inspired by <link linkend="OCaml">OCaml</link>'s guard clauses.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>by</literal> is the mapping combinator.
</simpara>
</listitem>
</itemizedlist>
<simpara>The below implementation of the <literal>ITER</literal>-signature makes use of the
following basic combinators:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun const x _ = x
fun flip f x y = f y x
fun id x = x
fun opt fno fso = fn NONE =&gt; fno () | SOME ? =&gt; fso ?
fun pass x f = f x</programlisting>
<simpara>Here is an implementation the <literal>ITER</literal>-signature:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Iter :&gt; ITER =
  struct
    type 'a t = ('a -&gt; unit) -&gt; unit

    val return = pass
    fun (iA &gt;&gt;= a2iB) f = iA (flip a2iB f)

    val none = ignore

    fun (l to u) f = let fun `l = if l&lt;u then (f l; `(l+1)) else () in `l end
    fun (u downto l) f = let fun `u = if u&gt;l then (f (u-1); `(u-1)) else () in `u end

    fun inList ? = flip List.app ?
    fun inVector ? = flip Vector.app ?
    fun inArray ? = flip Array.app ?

    fun using get s f = let fun `s = opt (const ()) (fn (x, s) =&gt; (f x; `s)) (get s) in `s end

    fun (iA when p) f = iA (fn a =&gt; if p a then f a else ())
    fun (iA by g) f = iA (f o g)
    fun (iA @@ iB) f = (iA f : unit; iB f)
    fun (iA ** iB) f = iA (fn a =&gt; iB (fn b =&gt; f (a &amp; b)))

    val for = id
  end</programlisting>
<simpara>Note that some of the above combinators (e.g. <literal>**</literal>) could be expressed
in terms of the other combinators, most notably <literal>return</literal> and <literal>&gt;&gt;=</literal>.
Another implementation issue worth mentioning is that <literal>downto</literal> is
written specifically to avoid computing <literal>l-1</literal>, which could cause an
<literal>Overflow</literal>.</simpara>
<simpara>To use the above combinators the <literal>Iter</literal>-structure needs to be opened</simpara>
<programlisting language="sml" linenumbering="unnumbered">open Iter</programlisting>
<simpara>and one usually also wants to declare the infix status of the
operators as shown earlier.</simpara>
<simpara>Here is an example that illustrates some of the features:</simpara>
<programlisting language="sml" linenumbering="unnumbered">for (0 to 10 when (fn x =&gt; x mod 3 &lt;&gt; 0) ** inList ["a", "b"] ** 2 downto 1 by real)
    (fn x &amp; y &amp; z =&gt;
       print ("("^Int.toString x^", \""^y^"\", "^Real.toString z^")\n"))</programlisting>
<simpara>Using the <literal>Iter</literal> combinators one can easily produce more complicated
iterators.  For example, here is an iterator over a "triangle":</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun triangle (l, u) = l to u &gt;&gt;= (fn i =&gt; i to u &gt;&gt;= (fn j =&gt; return (i, j)))</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="FrontEnd">
<title>FrontEnd</title>
<simpara><link linkend="FrontEnd">FrontEnd</link> is a translation pass from source to the <link linkend="AST">AST</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_18">
<title>Description</title>
<simpara>This pass performs lexing and parsing to produce an abstract syntax
tree.</simpara>
</section>
<section id="_implementation_20">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/front-end/front-end.sig"><literal>front-end.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/front-end/front-end.fun"><literal>front-end.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_20">
<title>Details and Notes</title>
<simpara>The lexer is produced by <link linkend="MLLex">MLLex</link> from
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/front-end/ml.lex"><literal>ml.lex</literal></ulink>.</simpara>
<simpara>The parser is produced by <link linkend="MLYacc">MLYacc</link> from
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/front-end/ml.grm"><literal>ml.grm</literal></ulink>.</simpara>
<simpara>The specifications for the lexer and parser were originally taken from
<link linkend="SMLNJ">SML/NJ</link> (version 109.32), but have been heavily modified
since then.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="FSharp">
<title>FSharp</title>
<simpara><ulink url="http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/">F#</ulink>
is a functional programming language developed at Microsoft Research.
F# was partly inspired by the <link linkend="OCaml">OCaml</link> language and shares some
common core constructs with it.  F# is integrated with Visual Studio
2010 as a first-class language.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="FunctionalRecordUpdate">
<title>FunctionalRecordUpdate</title>
<simpara>Functional record update is the copying of a record while replacing
the values of some of the fields.  <link linkend="StandardML">Standard ML</link> does not
have explicit syntax for functional record update.  We will show below
how to implement functional record update in SML, with a little
boilerplate code.</simpara>
<simpara>As an example, the functional update of the record</simpara>
<programlisting language="sml" linenumbering="unnumbered">{a = 13, b = 14, c = 15}</programlisting>
<simpara>with <literal>c = 16</literal> yields a new record</simpara>
<programlisting language="sml" linenumbering="unnumbered">{a = 13, b = 14, c = 16}</programlisting>
<simpara>Functional record update also makes sense with multiple simultaneous
updates.  For example, the functional update of the record above with
<literal>a = 18, c = 19</literal> yields a new record</simpara>
<programlisting language="sml" linenumbering="unnumbered">{a = 18, b = 14, c = 19}</programlisting>
<simpara>One could easily imagine an extension of the SML that supports
functional record update.  For example</simpara>
<programlisting language="sml" linenumbering="unnumbered">e with {a = 16, b = 17}</programlisting>
<simpara>would create a copy of the record denoted by <literal>e</literal> with field <literal>a</literal>
replaced with <literal>16</literal> and <literal>b</literal> replaced with <literal>17</literal>.</simpara>
<simpara>Since there is no such syntax in SML, we now show how to implement
functional record update directly.  We first give a simple
implementation that has a number of problems.  We then give an
advanced implementation, that, while complex underneath, is a reusable
library that admits simple use.</simpara>
<section id="_simple_implementation">
<title>Simple implementation</title>
<simpara>To support functional record update on the record type</simpara>
<programlisting language="sml" linenumbering="unnumbered">{a: 'a, b: 'b, c: 'c}</programlisting>
<simpara>first, define an update function for each component.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun withA ({a = _, b, c}, a) = {a = a, b = b, c = c}
fun withB ({a, b = _, c}, b) = {a = a, b = b, c = c}
fun withC ({a, b, c = _}, c) = {a = a, b = b, c = c}</programlisting>
<simpara>Then, one can express <literal>e with {a = 16, b = 17}</literal> as</simpara>
<programlisting language="sml" linenumbering="unnumbered">withB (withA (e, 16), 17)</programlisting>
<simpara>With infix notation</simpara>
<programlisting language="sml" linenumbering="unnumbered">infix withA withB withC</programlisting>
<simpara>the syntax is almost as concise as a language extension.</simpara>
<programlisting language="sml" linenumbering="unnumbered">e withA 16 withB 17</programlisting>
<simpara>This approach suffers from the fact that the amount of boilerplate
code is quadratic in the number of record fields.  Furthermore,
changing, adding, or deleting a field requires time proportional to
the number of fields (because each <literal>with<emphasis>&lt;L&gt;</emphasis></literal> function must be
changed).  It is also annoying to have to define a <literal>with<emphasis>&lt;L&gt;</emphasis></literal>
function, possibly with a fixity declaration, for each field.</simpara>
<simpara>Fortunately, there is a solution to these problems.</simpara>
</section>
<section id="_advanced_implementation">
<title>Advanced implementation</title>
<simpara>Using <link linkend="Fold">Fold</link> one can define a family of <literal>makeUpdate<emphasis>&lt;N&gt;</emphasis></literal>
functions and single <emphasis>update</emphasis> operator <literal>U</literal> so that one can define a
functional record update function for any record type simply by
specifying a (trivial) isomorphism between that type and function
argument list.  For example, suppose that we would like to do
functional record update on records with fields <literal>a</literal> and <literal>b</literal>.  Then one
defines a function <literal>updateAB</literal> as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val updateAB =
   fn z =&gt;
   let
      fun from v1 v2 = {a = v1, b = v2}
      fun to f {a = v1, b = v2} = f v1 v2
   in
      makeUpdate2 (from, from, to)
   end
   z</programlisting>
<simpara>The functions <literal>from</literal> (think <emphasis>from function arguments</emphasis>) and <literal>to</literal> (think
<emphasis>to function arguements</emphasis>) specify an isomorphism between <literal>a</literal>,<literal>b</literal>
records and function arguments.  There is a second use of <literal>from</literal> to
work around the lack of
<link linkend="FirstClassPolymorphism">first-class polymorphism</link> in SML.</simpara>
<simpara>With the definition of <literal>updateAB</literal> in place, the following expressions
are valid.</simpara>
<programlisting language="sml" linenumbering="unnumbered">updateAB {a = 13, b = "hello"} (set#b "goodbye") $
updateAB {a = 13.5, b = true} (set#b false) (set#a 12.5) $</programlisting>
<simpara>As another example, suppose that we would like to do functional record
update on records with fields <literal>b</literal>, <literal>c</literal>, and <literal>d</literal>.  Then one defines a
function <literal>updateBCD</literal> as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val updateBCD =
   fn z =&gt;
   let
      fun from v1 v2 v3 = {b = v1, c = v2, d = v3}
      fun to f {b = v1, c = v2, d = v3} = f v1 v2 v3
   in
      makeUpdate3 (from, from, to)
   end
   z</programlisting>
<simpara>With the definition of <literal>updateBCD</literal> in place, the following expression
is valid.</simpara>
<programlisting language="sml" linenumbering="unnumbered">updateBCD {b = 1, c = 2, d = 3} (set#c 4) (set#c 5) $</programlisting>
<simpara>Note that not all fields need be updated and that the same field may
be updated multiple times.  Further note that the same <literal>set</literal> operator
is used for all update functions (in the above, for both <literal>updateAB</literal>
and <literal>updateBCD</literal>).</simpara>
<simpara>In general, to define a functional-record-update function on records
with fields <literal>f1</literal>, <literal>f2</literal>, &#8230;, <literal>fN</literal>, use the following template.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val update =
   fn z =&gt;
   let
      fun from v1 v2 ... vn = {f1 = v1, f2 = v2, ..., fn = vn}
      fun to f {f1 = v1, f2 = v2, ..., fn = vn} = v1 v2 ... vn
   in
      makeUpdateN (from, from, to)
   end
   z</programlisting>
<simpara>With this, one can update a record as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">update {f1 = v1, ..., fn = vn} (set#fi1 vi1) ... (set#fim vim) $</programlisting>
</section>
<section id="_the_literal_functionalrecordupdate_literal_structure">
<title>The <literal>FunctionalRecordUpdate</literal> structure</title>
<simpara>Here is the implementation of functional record update.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure FunctionalRecordUpdate =
   struct
      local
         fun next g (f, z) x = g (f x, z)
         fun f1 (f, z) x = f (z x)
         fun f2  z = next f1  z
         fun f3  z = next f2  z

         fun c0  from = from
         fun c1  from = c0  from f1
         fun c2  from = c1  from f2
         fun c3  from = c2  from f3

         fun makeUpdate cX (from, from', to) record =
            let
               fun ops () = cX from'
               fun vars f = to f record
            in
               Fold.fold ((vars, ops), fn (vars, _) =&gt; vars from)
            end
      in
         fun makeUpdate0  z = makeUpdate c0  z
         fun makeUpdate1  z = makeUpdate c1  z
         fun makeUpdate2  z = makeUpdate c2  z
         fun makeUpdate3  z = makeUpdate c3  z

         fun upd z = Fold.step2 (fn (s, f, (vars, ops)) =&gt; (fn out =&gt; vars (s (ops ()) (out, f)), ops)) z
         fun set z = Fold.step2 (fn (s, v, (vars, ops)) =&gt; (fn out =&gt; vars (s (ops ()) (out, fn _ =&gt; v)), ops)) z
      end
   end</programlisting>
<simpara>The idea of <literal>makeUpdate</literal> is to build a record of functions which can
replace the contents of one argument out of a list of arguments.  The
functions <literal>f<emphasis>&lt;X&gt;</emphasis></literal> replace the 0th, 1st, &#8230; argument with their
argument <literal>z</literal>. The <literal>c<emphasis>&lt;X&gt;</emphasis></literal> functions pass the first <emphasis>X</emphasis> <literal>f</literal>
functions to the record constructor.</simpara>
<simpara>The <literal>#field</literal> notation of Standard ML allows us to select the map
function which replaces the corresponding argument. By converting the
record to an argument list, feeding that list through the selected map
function and piping the list into the record constructor, functional
record update is achieved.</simpara>
</section>
<section id="_efficiency">
<title>Efficiency</title>
<simpara>With MLton, the efficiency of this approach is as good as one would
expect with the special syntax.  Namely a sequence of updates will be
optimized into a single record construction that copies the unchanged
fields and fills in the changed fields with their new values.</simpara>
<simpara>Before Sep 14, 2009, this page advocated an alternative implementation
of <link linkend="FunctionalRecordUpdate">FunctionalRecordUpdate</link>.  However, the old structure caused
exponentially increasing compile times.  We advise you to switch to
the newer version.</simpara>
</section>
<section id="_applications">
<title>Applications</title>
<simpara>Functional record update can be used to implement labelled
<link linkend="OptionalArguments">optional arguments</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="fxp">
<title>fxp</title>
<simpara><ulink url="http://atseidl2.informatik.tu-muenchen.de/%7Eberlea/Fxp/">fxp</ulink> is an XML
parser written in Standard ML.</simpara>
<simpara>It has a
<ulink url="http://atseidl2.informatik.tu-muenchen.de/%7Eberlea/Fxp/mlton.html">patch</ulink>
to compile with MLton.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="GarbageCollection">
<title>GarbageCollection</title>
<simpara>For a good introduction and overview to garbage collection, see
<link linkend="References_Jones99">Jones99</link>.</simpara>
<simpara>MLton&#8217;s garbage collector uses copying, mark-compact, and generational
collection, automatically switching between them at run time based on
the amount of live data relative to the amount of RAM.  The runtime
system tries to keep the heap within RAM if at all possible.</simpara>
<simpara>MLton&#8217;s copying collector is a simple, two-space, breadth-first,
Cheney-style collector.  The design for the generational and
mark-compact GC is based on <link linkend="References_Sansom91">Sansom91</link>.</simpara>
<section id="_design_notes">
<title>Design notes</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2002-May/012420.html">http://www.mlton.org/pipermail/mlton/2002-May/012420.html</ulink>
</simpara>
<simpara>object layout and header word design</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_4">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Regions">Regions</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="GenerativeDatatype">
<title>GenerativeDatatype</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, datatype declarations are said to be
<emphasis>generative</emphasis>, because each time a datatype declaration is evaluated,
it yields a new type.  Thus, any attempt to mix the types will lead to
a type error at compile-time.  The following program, which does not
type check, demonstrates this.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor F () =
   struct
      datatype t = T
   end
structure S1 = F ()
structure S2 = F ()
val _: S1.t -&gt; S2.t = fn x =&gt; x</programlisting>
<simpara>Generativity also means that two different datatype declarations
define different types, even if they define identical constructors.
The following program does not type check due to this.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B
val a1 = A
datatype t = A | B
val a2 = A
val _ = if true then a1 else a2</programlisting>
<section id="_also_see_5">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="GenerativeException">GenerativeException</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="GenerativeException">
<title>GenerativeException</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, exception declarations are said to be
<emphasis>generative</emphasis>, because each time an exception declaration is evaluated,
it yields a new exception.</simpara>
<simpara>The following program demonstrates the generativity of exceptions.</simpara>
<programlisting language="sml" linenumbering="unnumbered">exception E
val e1 = E
fun isE1 (e: exn): bool =
   case e of
      E =&gt; true
    | _ =&gt; false
exception E
val e2 = E
fun isE2 (e: exn): bool =
   case e of
      E =&gt; true
    | _ =&gt; false
fun pb (b: bool): unit =
   print (concat [Bool.toString b, "\n"])
val () = (pb (isE1 e1)
          ;pb (isE1 e2)
          ; pb (isE2 e1)
          ; pb (isE2 e2))</programlisting>
<simpara>In the above program, two different exception declarations declare an
exception <literal>E</literal> and a corresponding function that returns <literal>true</literal> only on
that exception.  Although declared by syntactically identical
exception declarations, <literal>e1</literal> and <literal>e2</literal> are different exceptions.  The
program, when run, prints <literal>true</literal>, <literal>false</literal>, <literal>false</literal>, <literal>true</literal>.</simpara>
<simpara>A slight modification of the above program shows that even a single
exception declaration yields a new exception each time it is
evaluated.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (): exn * (exn -&gt; bool) =
   let
      exception E
   in
      (E, fn E =&gt; true | _ =&gt; false)
   end
val (e1, isE1) = f ()
val (e2, isE2) = f ()
fun pb (b: bool): unit =
   print (concat [Bool.toString b, "\n"])
val () = (pb (isE1 e1)
          ; pb (isE1 e2)
          ; pb (isE2 e1)
          ; pb (isE2 e2))</programlisting>
<simpara>Each call to <literal>f</literal> yields a new exception and a function that returns
<literal>true</literal> only on that exception.  The program, when run, prints <literal>true</literal>,
<literal>false</literal>, <literal>false</literal>, <literal>true</literal>.</simpara>
<section id="_type_safety">
<title>Type Safety</title>
<simpara>Exception generativity is required for type safety.  Consider the
following valid SML program.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (): ('a -&gt; exn) * (exn -&gt; 'a) =
   let
      exception E of 'a
   in
      (E, fn E x =&gt; x | _ =&gt; raise Fail "f")
   end
fun cast (a: 'a): 'b =
   let
      val (make: 'a -&gt; exn, _) = f ()
      val (_, get: exn -&gt; 'b) = f ()
   in
      get (make a)
   end
val _ = ((cast 13): int -&gt; int) 14</programlisting>
<simpara>If exceptions weren&#8217;t generative, then each call <literal>f ()</literal> would yield
the same exception constructor <literal>E</literal>.  Then, our <literal>cast</literal> function could
use <literal>make: 'a -&gt; exn</literal> to convert any value into an exception and then
<literal>get: exn -&gt; 'b</literal> to convert that exception to a value of arbitrary
type.  If <literal>cast</literal> worked, then we could cast an integer as a function
and apply.  Of course, because of generative exceptions, this program
raises <literal>Fail "f"</literal>.</simpara>
</section>
<section id="_applications_2">
<title>Applications</title>
<simpara>The <literal>exn</literal> type is effectively a <link linkend="UniversalType">universal type</link>.</simpara>
</section>
<section id="_also_see_6">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="GenerativeDatatype">GenerativeDatatype</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Git">
<title>Git</title>
<simpara><ulink url="http://git-scm.com/">Git</ulink> is a distributed version control system.  The
MLton project currently uses Git to maintain its
<link linkend="Sources">source code</link>.</simpara>
<simpara>Here are some online Git resources.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://git-scm.com/docs">Reference Manual</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://git-scm.com/book">ProGit, by Scott Chacon</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Glade">
<title>Glade</title>
<simpara><ulink url="http://glade.gnome.org/features.html">Glade</ulink> is a tool for generating
Gtk user interfaces.</simpara>
<simpara><link linkend="WesleyTerpstra">WesleyTerpstra</link> is working on a Glade&#8594;mGTK converter.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-December/016865.html">http://www.mlton.org/pipermail/mlton/2004-December/016865.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Globalize">
<title>Globalize</title>
<simpara><link linkend="Globalize">Globalize</link> is an analysis pass for the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ClosureConvert">ClosureConvert</link>.</simpara>
<section id="_description_19">
<title>Description</title>
<simpara>This pass marks values that are constant, allowing <link linkend="ClosureConvert">ClosureConvert</link>
to move them out to the top level so they are only evaluated once and
do not appear in closures.</simpara>
</section>
<section id="_implementation_21">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/closure-convert/globalize.sig"><literal>globalize.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/closure-convert/globalize.fun"><literal>globalize.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_21">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="GnuMP">
<title>GnuMP</title>
<simpara>The <ulink url="http://gmplib.org">GnuMP</ulink> library (GNU Multiple Precision
arithmetic library) is a library for arbitrary precision integer
arithmetic.  MLton uses the GnuMP library to implement the
<link linkend="BasisLibrary">Basis Library</link> <literal>IntInf</literal> module.</simpara>
<section id="_known_issues">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
There is a known problem with the GnuMP library (prior to version
4.2.x), where it requires a lot of stack space for some computations,
e.g. <literal>IntInf.toString</literal> of a million digit number.  If you run with
stack size limited, you may see a segfault in such programs.  This
problem is mentioned in the <ulink url="http://gmplib.org/#FAQ">GnuMP FAQ</ulink>, where
they describe two solutions.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Increase (or unlimit) your stack space.  From your program, use
<literal>setrlimit</literal>, or from the shell, use <literal>ulimit</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Configure and rebuild <literal>libgmp</literal> with <literal>--disable-alloca</literal>, which will
cause it to allocate temporaries using <literal>malloc</literal> instead of on the
stack.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
On some platforms, the GnuMP library may be configured to use one of
multiple ABIs (Application Binary Interfaces).  For example, on some
32-bit architectures, GnuMP may be configured to represent a limb as
either a 32-bit <literal>long</literal> or as a 64-bit <literal>long long</literal>.  Similarly, GnuMP
may be configured to use specific CPU features.
</simpara>
<simpara>In order to efficiently use the GnuMP library, MLton represents an
<literal>IntInf.int</literal> value in a manner compatible with the GnuMP library&#8217;s
representation of a limb.  Hence, it is important that MLton and the
GnuMP library agree upon the representation of a limb.</simpara>
<itemizedlist>
<listitem>
<simpara>
When using a source package of MLton, building will detect the
GnuMP library&#8217;s representation of a limb.
</simpara>
</listitem>
<listitem>
<simpara>
When using a binary package of MLton that is dynamically linked
against the GnuMP library, the build machine and the install machine
must have the GnuMP library configured with the same representation of
a limb.  (On the other hand, the build machine need not have the GnuMP
library configured with CPU features compatible with the install
machine.)
</simpara>
</listitem>
<listitem>
<simpara>
When using a binary package of MLton that is statically linked
against the GnuMP library, the build machine and the install machine
need not have the GnuMP library configured with the same
representation of a limb.  (On the other hand, the build machine must
have the GnuMP library configured with CPU features compatible with
the install machine.)
</simpara>
<simpara>However, MLton will be configured with the representation of a limb
from the GnuMP library of the build machine.  Executables produced by
MLton will be incompatible with the GnuMP library of the install
machine.  To <emphasis>reconfigure</emphasis> MLton with the representation of a limb
from the GnuMP library of the install machine, one must edit:</simpara>
<screen>/usr/lib/mlton/self/sizes</screen>
<simpara>changing the</simpara>
<screen>mplimb = ??</screen>
<simpara>entry so that <literal>??</literal> corresponds to the bytes in a limb; and, one must edit:</simpara>
<screen>/usr/lib/mlton/sml/basis/config/c/arch-os/c-types.sml</screen>
<simpara>changing the</simpara>
<screen>(* from "gmp.h" *)
structure C_MPLimb = struct open Word?? type t = word end
functor C_MPLimb_ChooseWordN (A: CHOOSE_WORDN_ARG) = ChooseWordN_Word?? (A)</screen>
<simpara>entries so that <literal>??</literal> corresponds to the bits in a limb.</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="GoogleSummerOfCode2013">
<title>Google Summer of Code (2013)</title>
<section id="_mentors">
<title>Mentors</title>
<simpara>The following developers have agreed to serve as mentors for the 2013 Google Summer of Code:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.cs.rit.edu/%7Emtf">Matthew Fluet</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cse.buffalo.edu/%7Elziarek/">Lukasz (Luke) Ziarek</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cs.purdue.edu/homes/suresh/">Suresh Jagannathan</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_ideas_list">
<title>Ideas List</title>
<section id="_implement_a_partial_redundancy_elimination_pre_optimization">
<title>Implement a Partial Redundancy Elimination (PRE) Optimization</title>
<simpara>Partial redundancy elimination (PRE) is a program transformation that
removes operations that are redundant on some, but not necessarily all
paths, through the program.  PRE can subsume both common subexpression
elimination and loop-invariant code motion, and is therefore a
potentially powerful optimization.  However, a na&iuml;ve
implementation of PRE on a program in static single assignment (SSA)
form is unlikely to be effective.  This project aims to adapt and
implement the SSAPRE algorithm(s) of Thomas VanDrunen in MLton&#8217;s SSA
intermediate language.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://onlinelibrary.wiley.com/doi/10.1002/spe.618/abstract">Anticipation-based partial redundancy elimination for static single assignment form</ulink>; Thomas VanDrunen and Antony L. Hosking
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://cs.wheaton.edu/%7Etvandrun/writings/thesis.pdf">Partial Redundancy Elimination for Global Value Numbering</ulink>; Thomas VanDrunen
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.springerlink.com/content/w06m3cw453nphm1u/">Value-Based Partial Redundancy Elimination</ulink>; Thomas VanDrunen and Antony L. Hosking
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=319301.319348">Partial redundancy elimination in SSA form</ulink>; Robert Kennedy, Sun Chan, Shin-Ming Liu, Raymond Lo, Peng Tu, and Fred Chow
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some middle-end compiler experience</simpara>
</section>
<section id="_design_and_implement_a_heap_profiler">
<title>Design and Implement a Heap Profiler</title>
<simpara>A heap profile is a description of the space usage of a program.  A
heap profile is concerned with the allocation, retention, and
deallocation (via garbage collection) of heap data during the
execution of a program.  A heap profile can be used to diagnose
performance problems in a functional program that arise from space
leaks.  This project aims to design and implement a heap profiler for
MLton compiled programs.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=583854.582451">GCspy: an adaptable heap visualisation framework</ulink>; Tony Printezis and Richard Jones
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1349892">New dimensions in heap profiling</ulink>; Colin Runciman and Niklas R&ouml;jemo
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.springerlink.com/content/710501660722gw37/">Heap profiling for space efficiency</ulink>; Colin Runciman and Niklas R&ouml;jemo
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1323096">Heap profiling of lazy functional programs</ulink>; Colin Runciman and David Wakeling
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: C and SML programming experience; some experience with UI and visualization</simpara>
</section>
<section id="_garbage_collector_improvements">
<title>Garbage Collector Improvements</title>
<simpara>The garbage collector plays a significant role in the performance of
functional languages.  Garbage collect too often, and program
performance suffers due to the excessive time spent in the garbage
collector.  Garbage collect not often enough, and program performance
suffers due to the excessive space used by the uncollected garbage.
One particular issue is ensuring that a program utilizing a garbage
collector "plays nice" with other processes on the system, by not
using too much or too little physical memory.  While there are some
reasonable theoretical results about garbage collections with heaps of
fixed size, there seems to be insufficient work that really looks
carefully at the question of dynamically resizing the heap in response
to the live data demands of the application and, similarly, in
response to the behavior of the operating system and other processes.
This project aims to investigate improvements to the memory behavior of
MLton compiled programs through better tuning of the garbage
collector.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.dcs.gla.ac.uk/%7Ewhited/papers/automated_heap_sizing.pdf">Automated Heap Sizing in the Poly/ML Runtime (Position Paper)</ulink>; David White, Jeremy Singer, Jonathan Aitken, and David Matthews
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4145125">Isla Vista Heap Sizing: Using Feedback to Avoid Paging</ulink>; Chris Grzegorczyk, Sunil Soman, Chandra Krintz, and Rich Wolski
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1152649.1152652">Controlling garbage collection and heap growth to reduce the execution time of Java applications</ulink>; Tim Brecht, Eshrat Arjomandi, Chang Li, and Hang Pham
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1065010.1065028">Garbage collection without paging</ulink>; Matthew Hertz, Yi Feng, and Emery D. Berger
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1029873.1029881">Automatic heap sizing: taking real memory into account</ulink>; Ting Yang, Matthew Hertz, Emery D. Berger, Scott F. Kaplan, and J. Eliot B. Moss
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: C programming experience; some operating systems and/or systems programming experience; some compiler and garbage collector experience</simpara>
</section>
<section id="_implement_successor_160_ml_language_features">
<title>Implement Successor&#160;ML Language Features</title>
<simpara>Any programming language, including Standard&#160;ML, can be improved.
The community has identified a number of modest extensions and
revisions to the Standard&#160;ML programming language that would
likely prove useful in practice.  This project aims to implement these
language features in the MLton compiler.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://successor-ml.org/index.php?title=Main_Page">Successor&#160;ML</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mpi-sws.org/%7Erossberg/hamlet/index.html#successor-ml">HaMLet (Successor&#160;ML)</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1322628">A critique of Standard&#160;ML</ulink>; Andrew W. Appel
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some front-end compiler experience (i.e., scanners and parsers)</simpara>
</section>
<section id="_implement_source_level_debugging">
<title>Implement Source-level Debugging</title>
<simpara>Debugging is a fact of programming life.  Unfortunately, most SML
implementations (including MLton) provide little to no source-level
debugging support.  This project aims to add basic to intermediate
source-level debugging support to the MLton compiler.  MLton already
supports source-level profiling, which can be used to attribute bytes
allocated or time spent in source functions.  It should be relatively
straightforward to leverage this source-level information into basic
source-level debugging support, with the ability to set/unset
breakpoints and step through declarations and functions.  It may be
possible to also provide intermediate source-level debugging support,
with the ability to inspect in-scope variables of basic types (e.g.,
types compatible with MLton&#8217;s foreign function interface).</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://mlton.org/HowProfilingWorks">MLton&#8201;&#8212;&#8201;How Profiling Works</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://mlton.org/ForeignFunctionInterfaceTypes">MLton&#8201;&#8212;&#8201;Foreign Function Interface Types</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dwarfstd.org/">DWARF Debugging Standard</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceware.org/gdb/current/onlinedocs/stabs/index.html">STABS Debugging Format</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some compiler experience</simpara>
</section>
<section id="_simd_primitives">
<title>SIMD Primitives</title>
<simpara>Most modern processors offer some direct support for SIMD (Single
Instruction, Multiple Data) operations, such as Intel&#8217;s MMX/SSE
instructions, AMD&#8217;s 3DNow!  instructions, and IBM&#8217;s AltiVec.  Such
instructions are particularly useful for multimedia, scientific, and
cryptographic applications.  This project aims to add preliminary
support for vector data and vector operations to the MLton compiler.
Ideally, after surveying SIMD instruction sets and SIMD support in
other compilers, a core set of SIMD primitives with broad architecture
and compiler support can be identified.  After adding SIMD primitives
to the core compiler and carrying them through to the various
backends, there will be opportunities to design and implement an SML
library that exposes the primitives to the SML programmer as well as
opportunities to design and implement auto-vectorization
optimizations.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://en.wikipedia.org/wiki/SIMD">SIMD</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://gcc.gnu.org/projects/tree-ssa/vectorization.html">Auto-vectorization in GCC</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://llvm.org/docs/Vectorizers.html">Auto-vectorization in LLVM</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some compiler experience; some computer architecture experience</simpara>
</section>
<section id="_rtos_support">
<title>RTOS Support</title>
<simpara>This project entails porting the MLton compiler to RTOSs such as:
RTEMS, RT Linux, and FreeRTOS.  The project will include modifications
to the MLton build and configuration process.  Students will need to
extend the MLton configuration process for each of the RTOSs.  The
MLton compilation process will need to be extended to invoke the C
cross compilers the RTOSs provide for embedded support.  Test scripts
for validation will be necessary and these will need to be run in
emulators for supported architectures.</simpara>
<simpara>Recommended Skills: C programming experience; some scripting experience</simpara>
</section>
<section id="_region_based_memory_management">
<title>Region Based Memory Management</title>
<simpara>Region based memory management is an alternative automatic memory
management scheme to garbage collection.  Regions can be inferred by
the compiler (e.g., Cyclone and MLKit) or provided to the programmer
through a library.  Since many students do not have extensive
experience with compilers we plan on adopting the later approach.
Creating a viable region based memory solution requires the removal of
the GC and changes to the allocator.  Additionally, write barriers
will be necessary to ensure references between two ML objects is never
established if the left hand side of the assignment has a longer
lifetime than the right hand side.  Students will need to come up with
an appropriate interface for creating, entering, and exiting regions
(examples include RTSJ scoped memory and SCJ scoped memory).</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
Cyclone
</simpara>
</listitem>
<listitem>
<simpara>
MLKit
</simpara>
</listitem>
<listitem>
<simpara>
RTSJ + SCJ scopes
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; C programming experience; some compiler and garbage collector experience</simpara>
</section>
<section id="_integration_of_multi_mlton">
<title>Integration of Multi-MLton</title>
<simpara><ulink url="http://multimlton.cs.purdue.edu">MultiMLton</ulink> is a compiler and runtime
environment that targets scalable multicore platforms.  It is an
extension of MLton.  It combines new language abstractions and
associated compiler analyses for expressing and implementing various
kinds of fine-grained parallelism (safe futures, speculation,
transactions, etc.), along with a sophisticated runtime system tuned
to efficiently handle large numbers of lightweight threads.  The core
stable features of MultiMLton will need to be integrated with the
latest MLton public release.  Certain experimental features, such as
support for the Intel SCC and distributed runtime will be omitted.
This project requires students to understand the delta between the
MultiMLton code base and the MLton code base.  Students will need to
create build and configuration scripts for MLton to enable MultiMLton
features.</simpara>
<simpara>Background</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://multimlton.cs.purdue.edu/mML/Publications.html">MultiMLton&#8201;&#8212;&#8201;Publications</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; C programming experience; some compiler experience</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="GoogleSummerOfCode2014">
<title>Google Summer of Code (2014)</title>
<section id="_mentors_2">
<title>Mentors</title>
<simpara>The following developers have agreed to serve as mentors for the 2014 Google Summer of Code:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.cs.rit.edu/%7Emtf">Matthew Fluet</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cse.buffalo.edu/%7Elziarek/">Lukasz (Luke) Ziarek</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://people.cs.uchicago.edu/~jhr/">John Reppy</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cs.purdue.edu/homes/chandras">KC Sivaramakrishnan</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_ideas_list_2">
<title>Ideas List</title>
<section id="_implement_a_partial_redundancy_elimination_pre_optimization_2">
<title>Implement a Partial Redundancy Elimination (PRE) Optimization</title>
<simpara>Partial redundancy elimination (PRE) is a program transformation that
removes operations that are redundant on some, but not necessarily all
paths, through the program.  PRE can subsume both common subexpression
elimination and loop-invariant code motion, and is therefore a
potentially powerful optimization.  However, a na&iuml;ve
implementation of PRE on a program in static single assignment (SSA)
form is unlikely to be effective.  This project aims to adapt and
implement the SSAPRE algorithm(s) of Thomas VanDrunen in MLton&#8217;s SSA
intermediate language.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://onlinelibrary.wiley.com/doi/10.1002/spe.618/abstract">Anticipation-based partial redundancy elimination for static single assignment form</ulink>; Thomas VanDrunen and Antony L. Hosking
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://cs.wheaton.edu/%7Etvandrun/writings/thesis.pdf">Partial Redundancy Elimination for Global Value Numbering</ulink>; Thomas VanDrunen
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.springerlink.com/content/w06m3cw453nphm1u/">Value-Based Partial Redundancy Elimination</ulink>; Thomas VanDrunen and Antony L. Hosking
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=319301.319348">Partial redundancy elimination in SSA form</ulink>; Robert Kennedy, Sun Chan, Shin-Ming Liu, Raymond Lo, Peng Tu, and Fred Chow
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some middle-end compiler experience</simpara>
</section>
<section id="_design_and_implement_a_heap_profiler_2">
<title>Design and Implement a Heap Profiler</title>
<simpara>A heap profile is a description of the space usage of a program.  A
heap profile is concerned with the allocation, retention, and
deallocation (via garbage collection) of heap data during the
execution of a program.  A heap profile can be used to diagnose
performance problems in a functional program that arise from space
leaks.  This project aims to design and implement a heap profiler for
MLton compiled programs.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=583854.582451">GCspy: an adaptable heap visualisation framework</ulink>; Tony Printezis and Richard Jones
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1349892">New dimensions in heap profiling</ulink>; Colin Runciman and Niklas R&ouml;jemo
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.springerlink.com/content/710501660722gw37/">Heap profiling for space efficiency</ulink>; Colin Runciman and Niklas R&ouml;jemo
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1323096">Heap profiling of lazy functional programs</ulink>; Colin Runciman and David Wakeling
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: C and SML programming experience; some experience with UI and visualization</simpara>
</section>
<section id="_garbage_collector_improvements_2">
<title>Garbage Collector Improvements</title>
<simpara>The garbage collector plays a significant role in the performance of
functional languages.  Garbage collect too often, and program
performance suffers due to the excessive time spent in the garbage
collector.  Garbage collect not often enough, and program performance
suffers due to the excessive space used by the uncollected garbage.
One particular issue is ensuring that a program utilizing a garbage
collector "plays nice" with other processes on the system, by not
using too much or too little physical memory.  While there are some
reasonable theoretical results about garbage collections with heaps of
fixed size, there seems to be insufficient work that really looks
carefully at the question of dynamically resizing the heap in response
to the live data demands of the application and, similarly, in
response to the behavior of the operating system and other processes.
This project aims to investigate improvements to the memory behavior of
MLton compiled programs through better tuning of the garbage
collector.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.dcs.gla.ac.uk/%7Ewhited/papers/automated_heap_sizing.pdf">Automated Heap Sizing in the Poly/ML Runtime (Position Paper)</ulink>; David White, Jeremy Singer, Jonathan Aitken, and David Matthews
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4145125">Isla Vista Heap Sizing: Using Feedback to Avoid Paging</ulink>; Chris Grzegorczyk, Sunil Soman, Chandra Krintz, and Rich Wolski
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1152649.1152652">Controlling garbage collection and heap growth to reduce the execution time of Java applications</ulink>; Tim Brecht, Eshrat Arjomandi, Chang Li, and Hang Pham
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1065010.1065028">Garbage collection without paging</ulink>; Matthew Hertz, Yi Feng, and Emery D. Berger
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1029873.1029881">Automatic heap sizing: taking real memory into account</ulink>; Ting Yang, Matthew Hertz, Emery D. Berger, Scott F. Kaplan, and J. Eliot B. Moss
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: C programming experience; some operating systems and/or systems programming experience; some compiler and garbage collector experience</simpara>
</section>
<section id="_implement_successor_160_ml_language_features_2">
<title>Implement Successor&#160;ML Language Features</title>
<simpara>Any programming language, including Standard&#160;ML, can be improved.
The community has identified a number of modest extensions and
revisions to the Standard&#160;ML programming language that would
likely prove useful in practice.  This project aims to implement these
language features in the MLton compiler.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://successor-ml.org/index.php?title=Main_Page">Successor&#160;ML</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mpi-sws.org/%7Erossberg/hamlet/index.html#successor-ml">HaMLet (Successor&#160;ML)</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1322628">A critique of Standard&#160;ML</ulink>; Andrew W. Appel
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some front-end compiler experience (i.e., scanners and parsers)</simpara>
</section>
<section id="_implement_source_level_debugging_2">
<title>Implement Source-level Debugging</title>
<simpara>Debugging is a fact of programming life.  Unfortunately, most SML
implementations (including MLton) provide little to no source-level
debugging support.  This project aims to add basic to intermediate
source-level debugging support to the MLton compiler.  MLton already
supports source-level profiling, which can be used to attribute bytes
allocated or time spent in source functions.  It should be relatively
straightforward to leverage this source-level information into basic
source-level debugging support, with the ability to set/unset
breakpoints and step through declarations and functions.  It may be
possible to also provide intermediate source-level debugging support,
with the ability to inspect in-scope variables of basic types (e.g.,
types compatible with MLton&#8217;s foreign function interface).</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://mlton.org/HowProfilingWorks">MLton&#8201;&#8212;&#8201;How Profiling Works</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://mlton.org/ForeignFunctionInterfaceTypes">MLton&#8201;&#8212;&#8201;Foreign Function Interface Types</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dwarfstd.org/">DWARF Debugging Standard</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceware.org/gdb/current/onlinedocs/stabs/index.html">STABS Debugging Format</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some compiler experience</simpara>
</section>
<section id="_region_based_memory_management_2">
<title>Region Based Memory Management</title>
<simpara>Region based memory management is an alternative automatic memory
management scheme to garbage collection.  Regions can be inferred by
the compiler (e.g., Cyclone and MLKit) or provided to the programmer
through a library.  Since many students do not have extensive
experience with compilers we plan on adopting the later approach.
Creating a viable region based memory solution requires the removal of
the GC and changes to the allocator.  Additionally, write barriers
will be necessary to ensure references between two ML objects is never
established if the left hand side of the assignment has a longer
lifetime than the right hand side.  Students will need to come up with
an appropriate interface for creating, entering, and exiting regions
(examples include RTSJ scoped memory and SCJ scoped memory).</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
Cyclone
</simpara>
</listitem>
<listitem>
<simpara>
MLKit
</simpara>
</listitem>
<listitem>
<simpara>
RTSJ + SCJ scopes
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; C programming experience; some compiler and garbage collector experience</simpara>
</section>
<section id="_integration_of_multi_mlton_2">
<title>Integration of Multi-MLton</title>
<simpara><ulink url="http://multimlton.cs.purdue.edu">MultiMLton</ulink> is a compiler and runtime
environment that targets scalable multicore platforms.  It is an
extension of MLton.  It combines new language abstractions and
associated compiler analyses for expressing and implementing various
kinds of fine-grained parallelism (safe futures, speculation,
transactions, etc.), along with a sophisticated runtime system tuned
to efficiently handle large numbers of lightweight threads.  The core
stable features of MultiMLton will need to be integrated with the
latest MLton public release.  Certain experimental features, such as
support for the Intel SCC and distributed runtime will be omitted.
This project requires students to understand the delta between the
MultiMLton code base and the MLton code base.  Students will need to
create build and configuration scripts for MLton to enable MultiMLton
features.</simpara>
<simpara>Background</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://multimlton.cs.purdue.edu/mML/Publications.html">MultiMLton&#8201;&#8212;&#8201;Publications</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; C programming experience; some compiler experience</simpara>
</section>
<section id="_concurrent_160_ml_improvements">
<title>Concurrent&#160;ML Improvements</title>
<simpara><ulink url="http://cml.cs.uchicago.edu/">Concurrent ML</ulink> is an SML concurrency
library based on synchronous message passing.  MLton has a partial
implementation of the CML message-passing primitives, but its use in
real-world applications has been stymied by the lack of completeness
and thread-safe I/O libraries.  This project would aim to flesh out
the CML implementation in MLton to be fully compatible with the
"official" version distributed as part of SML/NJ.  Furthermore, time
permitting, runtime system support could be added to allow use of
modern OS features, such as asynchronous I/O, in the implementation of
CML&#8217;s system interfaces.</simpara>
<simpara>Background</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://cml.cs.uchicago.edu/">http://cml.cs.uchicago.edu/</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://mlton.org/ConcurrentML">http://mlton.org/ConcurrentML</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://mlton.org/ConcurrentMLImplementation">http://mlton.org/ConcurrentMLImplementation</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; knowledge of concurrent programming; some operating systems and/or systems programming experience</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="GoogleSummerOfCode2015">
<title>Google Summer of Code (2015)</title>
<section id="_mentors_3">
<title>Mentors</title>
<simpara>The following developers have agreed to serve as mentors for the 2015 Google Summer of Code:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.cs.rit.edu/%7Emtf">Matthew Fluet</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cse.buffalo.edu/%7Elziarek/">Lukasz (Luke) Ziarek</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_ideas_list_3">
<title>Ideas List</title>
<section id="_design_and_implement_a_heap_profiler_3">
<title>Design and Implement a Heap Profiler</title>
<simpara>A heap profile is a description of the space usage of a program.  A
heap profile is concerned with the allocation, retention, and
deallocation (via garbage collection) of heap data during the
execution of a program.  A heap profile can be used to diagnose
performance problems in a functional program that arise from space
leaks.  This project aims to design and implement a heap profiler for
MLton compiled programs.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=583854.582451">GCspy: an adaptable heap visualisation framework</ulink>; Tony Printezis and Richard Jones
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1349892">New dimensions in heap profiling</ulink>; Colin Runciman and Niklas R&ouml;jemo
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.springerlink.com/content/710501660722gw37/">Heap profiling for space efficiency</ulink>; Colin Runciman and Niklas R&ouml;jemo
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1323096">Heap profiling of lazy functional programs</ulink>; Colin Runciman and David Wakeling
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: C and SML programming experience; some experience with UI and visualization</simpara>
</section>
<section id="_garbage_collector_improvements_3">
<title>Garbage Collector Improvements</title>
<simpara>The garbage collector plays a significant role in the performance of
functional languages.  Garbage collect too often, and program
performance suffers due to the excessive time spent in the garbage
collector.  Garbage collect not often enough, and program performance
suffers due to the excessive space used by the uncollected
garbage.  One particular issue is ensuring that a program utilizing a
garbage collector "plays nice" with other processes on the system, by
not using too much or too little physical memory.  While there are some
reasonable theoretical results about garbage collections with heaps of
fixed size, there seems to be insufficient work that really looks
carefully at the question of dynamically resizing the heap in response
to the live data demands of the application and, similarly, in
response to the behavior of the operating system and other
processes.  This project aims to investigate improvements to the memory
behavior of MLton compiled programs through better tuning of the
garbage collector.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://gchandbook.org/">The Garbage Collection Handbook: The Art of Automatic Memory Management</ulink>; Richard Jones, Antony Hosking, Eliot Moss
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.1020">Dual-Mode Garbage Collection</ulink>; Patrick Sansom
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1029873.1029881">Automatic Heap Sizing: Taking Real Memory into Account</ulink>; Ting Yang, Matthew Hertz, Emery D. Berger, Scott F. Kaplan, and J. Eliot B. Moss
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1152649.1152652">Controlling Garbage Collection and Heap Growth to Reduce the Execution Time of Java Applications</ulink>; Tim Brecht, Eshrat Arjomandi, Chang Li, and Hang Pham
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4145125">Isla Vista Heap Sizing: Using Feedback to Avoid Paging</ulink>; Chris Grzegorczyk, Sunil Soman, Chandra Krintz, and Rich Wolski
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=1806651.1806669">The Economics of Garbage Collection</ulink>; Jeremy Singer, Richard E. Jones, Gavin Brown, and Mikel Luján
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.dcs.gla.ac.uk/%7Ejsinger/pdfs/tfp12.pdf">Automated Heap Sizing in the Poly/ML Runtime (Position Paper)</ulink>; David White, Jeremy Singer, Jonathan Aitken, and David Matthews
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=2555670.2466481">Control Theory for Principled Heap Sizing</ulink>; David R. White, Jeremy Singer, Jonathan M. Aitken, and Richard E. Jones
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: C programming experience; some operating systems and/or systems programming experience; some compiler and garbage collector experience</simpara>
</section>
<section id="_heap_allocated_activation_records">
<title>Heap-allocated Activation Records</title>
<simpara>Activation records (a.k.a., stack frames) are traditionally allocated
on a stack.  This naturally corresponds to the call-return pattern of
function invocation.  However, there are some disadvantages to
stack-allocated activation records.  In a functional programming
language, functions may be deeply recursive, resulting in call stacks
that are much larger than typically supported by the operating system;
hence, a functional programming language implementation will typically
store its stack in its heap.  Furthermore, a functional programming
language implementation must handle and recover from stack overflow,
by allocating a larger stack (again, in its heap) and copying
activation records from the old stack to the new stack.  In the
presence of threads, stacks must be allocated in a heap and, in the
presence of a garbage collector, should be garbage collected when
unreachable.  While heap-allocated activation records avoid many of
these disadvantages, they have not been widely implemented.  This
project aims to implement and evaluate heap-allocated activation
records in the MLton compiler.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://journals.cambridge.org/action/displayAbstract?aid=1295104">Empirical and Analytic Study of Stack Versus Heap Cost for Languages with Closures</ulink>; Andrew W. Appel and Zhong Shao
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=182590.156783">Space-efficient closure representations</ulink>; Zhong Shao and Andrew W. Appel
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://portal.acm.org/citation.cfm?doid=93548.93554">Representing control in the presence of first-class continuations</ulink>; R. Hieb, R. Kent Dybvig, and Carl Bruggeman
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some middle- and back-end compiler experience</simpara>
</section>
<section id="_correctly_rounded_floating_point_binary_to_decimal_and_decimal_to_binary_conversion_routines_in_standard_ml">
<title>Correctly Rounded Floating-point Binary-to-Decimal and Decimal-to-Binary Conversion Routines in Standard ML</title>
<simpara>The
<ulink url="http://en.wikipedia.org/wiki/IEEE_754-2008">IEEE Standard for Floating-Point Arithmetic (IEEE 754)</ulink>
is the de facto representation for floating-point computation.
However, it is a <emphasis>binary</emphasis> (base 2) representation of floating-point
values, while many applications call for input and output of
floating-point values in <emphasis>decimal</emphasis> (base 10) representation.  The
<emphasis>decimal-to-binary</emphasis> conversion problem takes a decimal floating-point
representation (e.g., a string like <literal>"0.1"</literal>) and returns the best
binary floating-point representation of that number.  The
<emphasis>binary-to-decimal</emphasis> conversion problem takes a binary floating-point
representation and returns a decimal floating-point representation
using the smallest number of digits that allow the decimal
floating-point representation to be converted to the original binary
floating-point representation.  For both conversion routines, "best"
is dependent upon the current floating-point rounding mode.</simpara>
<simpara>MLton uses David Gay&#8217;s
<ulink url="http://www.netlib.org/fp/gdtoa.tgz">gdtoa library</ulink> for floating-point
conversions.  While this is an exellent library, it generalizes the
decimal-to-binary and binary-to-decimal conversion routines beyond
what is required by the
<ulink url="http://standardml.org/Basis/">Standard ML Basis Library</ulink> and induces an
external dependency on the compiler.  Native implementations of these
conversion routines in Standard ML would obviate the dependency on the
<literal>gdtoa</literal> library, while also being able to take advantage of Standard
ML features in the implementation (e.g., the published algorithms
often require use of infinite precision arithmetic, which is provided
by the <literal>IntInf</literal> structure in Standard ML, but is provided in an ad hoc
fasion in the <literal>gdtoa</literal> library).</simpara>
<simpara>This project aims to develop a native implementation of the conversion
routines in Standard ML.</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://dl.acm.org/citation.cfm?doid=103162.103163">What every computer scientist should know about floating-point arithmetic</ulink>; David Goldberg
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dl.acm.org/citation.cfm?doid=93542.93559">How to print floating-point numbers accurately</ulink>; Guy L. Steele, Jr. and Jon L. White
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dl.acm.org/citation.cfm?doid=93542.93557">How to read floating point numbers accurately</ulink>; William D. Clinger
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://cm.bell-labs.com/cm/cs/doc/90/4-10.ps.gz">Correctly Rounded Binary-Decimal and Decimal-Binary Conversions</ulink>; David Gay
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dl.acm.org/citation.cfm?doid=249069.231397">Printing floating-point numbers quickly and accurately</ulink>; Robert G. Burger and R. Kent Dybvig
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dl.acm.org/citation.cfm?doid=1806596.1806623">Printing floating-point numbers quickly and accurately with integers</ulink>; Florian Loitsch
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; algorithm design and implementation</simpara>
</section>
<section id="_implement_source_level_debugging_3">
<title>Implement Source-level Debugging</title>
<simpara>Debugging is a fact of programming life.  Unfortunately, most SML
implementations (including MLton) provide little to no source-level
debugging support.  This project aims to add basic to intermediate
source-level debugging support to the MLton compiler.  MLton already
supports source-level profiling, which can be used to attribute bytes
allocated or time spent in source functions.  It should be relatively
straightforward to leverage this source-level information into basic
source-level debugging support, with the ability to set/unset
breakpoints and step through declarations and functions.  It may be
possible to also provide intermediate source-level debugging support,
with the ability to inspect in-scope variables of basic types (e.g.,
types compatible with MLton&#8217;s foreign function interface).</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://mlton.org/HowProfilingWorks">MLton&#8201;&#8212;&#8201;How Profiling Works</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://mlton.org/ForeignFunctionInterfaceTypes">MLton&#8201;&#8212;&#8201;Foreign Function Interface Types</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://dwarfstd.org/">DWARF Debugging Standard</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceware.org/gdb/current/onlinedocs/stabs/index.html">STABS Debugging Format</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; some compiler experience</simpara>
</section>
<section id="_region_based_memory_management_3">
<title>Region Based Memory Management</title>
<simpara>Region based memory management is an alternative automatic memory
management scheme to garbage collection.  Regions can be inferred by
the compiler (e.g., Cyclone and MLKit) or provided to the programmer
through a library.  Since many students do not have extensive
experience with compilers we plan on adopting the later approach.
Creating a viable region based memory solution requires the removal of
the GC and changes to the allocator.  Additionally, write barriers
will be necessary to ensure references between two ML objects is never
established if the left hand side of the assignment has a longer
lifetime than the right hand side.  Students will need to come up with
an appropriate interface for creating, entering, and exiting regions
(examples include RTSJ scoped memory and SCJ scoped memory).</simpara>
<simpara>Background:</simpara>
<itemizedlist>
<listitem>
<simpara>
Cyclone
</simpara>
</listitem>
<listitem>
<simpara>
MLKit
</simpara>
</listitem>
<listitem>
<simpara>
RTSJ + SCJ scopes
</simpara>
</listitem>
</itemizedlist>
<simpara>Recommended Skills: SML programming experience; C programming experience; some compiler and garbage collector experience</simpara>
</section>
<section id="_adding_real_time_capabilities">
<title>Adding Real-Time Capabilities</title>
<simpara>This project focuses on exposing real-time APIs from a real-time OS
kernel at the SML level.  This will require mapping the current MLton
(or <ulink url="http://multimlton.cs.purdue.edu">MultiMLton</ulink>) threading framework
to real-time threads that the RTOS provides.  This will include
associating priorities with MLton threads and building priority based
scheduling algorithms.  Additionally, support for perdioc, aperiodic,
and sporadic tasks should be supported.  A real-time SML library will
need to be created to provide a forward facing interface for
programmers.  Stretch goals include reworking the MLton <literal>atomic</literal>
statement and associated synchronization primitives built on top of
the MLton <literal>atomic</literal> statement.</simpara>
<simpara>Recommended Skills: SML programming experience; C programming experience; real-time experience a plus but not required</simpara>
</section>
<section id="_real_time_garbage_collection">
<title>Real-Time Garbage Collection</title>
<simpara>This project focuses on modifications to the MLton GC to support
real-time garbage collection.  We will model the real-time GC on the
Schism RTGC.  The first task will be to create a fixed size runtime
object representation.  Large structures will need to be represented
as a linked lists of fixed sized objects.  Arrays and vectors will be
transferred into dense trees.  Compaction and copying can therefore be
removed from the GC algorithms that MLton currently supports.  Lastly,
the GC will be made concurrent, allowing for the execution of the GC
threads as the lowest priority task in the system.  Stretch goals
include a priority aware mechanism for the GC to signal to real-time
ML threads that it needs to scan their stack and identification of
places where the stack is shallow to bound priority inversion during
this procedure.</simpara>
<simpara>Recommended Skills: C programming experience; garbage collector experience a plus but not required</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="HaMLet">
<title>HaMLet</title>
<simpara><ulink url="http://www.mpi-sws.org/~rossberg/hamlet/">HaMLet</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link>.  It is
intended as reference implementation of
<link linkend="DefinitionOfStandardML">The Definition of Standard ML (Revised)</link> and
not for serious practical work.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="HenryCejtin">
<title>HenryCejtin</title>
<simpara>I was one of the original developers of Mathematica (actually employee #1).
My background is a combination of mathematics and computer science.
Currently I am doing various things in Chicago.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="History">
<title>History</title>
<simpara>In April 1997, Stephen Weeks wrote a defunctorizer for Standard ML and
integrated it with SML/NJ.  The defunctorizer used SML/NJ&#8217;s visible
compiler and operated on the <literal>Ast</literal> intermediate representation
produced by the SML/NJ front end.  Experiments showed that
defunctorization gave a speedup of up to six times over separate
compilation and up to two times over batch compilation without functor
expansion.</simpara>
<simpara>In August 1997, we began development of an independent compiler for
SML.  At the time the compiler was called <literal>smlc</literal>.  By October, we had
a working monomorphiser.  By November, we added a polyvariant
higher-order control-flow analysis.  At that point, MLton was about
10,000 lines of code.</simpara>
<simpara>Over the next year and half, <literal>smlc</literal> morphed into a full-fledged
compiler for SML.  It was renamed MLton, and first released in March
1999.</simpara>
<simpara>From the start, MLton has been driven by whole-program optimization
and an emphasis on performance.  Also from the start, MLton has had a
fast C FFI and <literal>IntInf</literal> based on the GNU multiprecision library.  At
its first release, MLton was 48,006 lines.</simpara>
<simpara>Between the March 1999 and January 2002, MLton grew to 102,541 lines,
as we added a native code generator, mllex, mlyacc, a profiler, many
optimizations, and many libraries including threads and signal
handling.</simpara>
<simpara>During 2002, MLton grew to 112,204 lines and we had releases in April
and September.  We added support for cross compilation and used this
to enable MLton to run on Cygwin/Windows and FreeBSD.  We also made
improvements to the garbage collector, so that it now works with large
arrays and up to 4G of memory and so that it automatically uses
copying, mark-compact, or generational collection depending on heap
usage and RAM size.  We also continued improvements to the optimizer
and libraries.</simpara>
<simpara>During 2003, MLton grew to 122,299 lines and we had releases in March
and July.  We extended the profiler to support source-level profiling
of time and allocation and to display call graphs.  We completed the
Basis Library implementation, and added new MLton-specific libraries
for weak pointers and finalization.  We extended the FFI to allow
callbacks from C to SML.  We added support for the Sparc/Solaris
platform, and made many improvements to the C code generator.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="HowProfilingWorks">
<title>HowProfilingWorks</title>
<simpara>Here&#8217;s how <link linkend="Profiling">Profiling</link> works.  If profiling is on, the front end
(elaborator) inserts <literal>Enter</literal> and <literal>Leave</literal> statements into the source
program for function entry and exit.  For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f n = if n = 0 then 0 else 1 + f (n - 1)</programlisting>
<simpara>becomes</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f n =
   let
      val () = Enter "f"
      val res = (if n = 0 then 0 else 1 + f (n - 1))
                handle e =&gt; (Leave "f"; raise e)
      val () = Leave "f"
   in
      res
   end</programlisting>
<simpara>Actually there is a bit more information than just the source function
name; there is also lexical nesting and file position.</simpara>
<simpara>Most of the middle of the compiler ignores, but preserves, <literal>Enter</literal> and
<literal>Leave</literal>.  However, so that profiling preserves tail calls, the
<link linkend="Shrink">SSA shrinker</link> has an optimization that notices when the only
operations that cause a call to be a nontail call are profiling
operations, and if so, moves them before the call, turning it into a
tail call. If you observe a program that has a tail call that appears
to be turned into a nontail when compiled with profiling, please
<link linkend="Bug">report a bug</link>.</simpara>
<simpara>There is the <literal>checkProf</literal> function in
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/type-check.fun"><literal>type-check.fun</literal></ulink>, which checks that
the <literal>Enter</literal>/<literal>Leave</literal> statements match up.</simpara>
<simpara>In the backend, just before translating to the <link linkend="Machine">Machine IL</link>,
the profiler uses the <literal>Enter</literal>/<literal>Leave</literal> statements to infer the "local"
portion of the control stack at each program point.  The profiler then
removes the <literal>Enter</literal>s/<literal>Leave</literal>s and inserts different information
depending on which kind of profiling is happening.  For time profiling
(with the <link linkend="AMD64Codegen">AMD64Codegen</link> and <link linkend="X86Codegen">X86Codegen</link>), the profiler inserts labels that cover the
code (i.e. each statement has a unique label in its basic block that
prefixes it) and associates each label with the local control stack.
For time profiling (with the <link linkend="CCodegen">CCodegen</link> and <link linkend="LLVMCodegen">LLVMCodegen</link>), the profiler
inserts code that sets a global field that records the local control
stack.  For allocation profiling, the profiler inserts calls to a C
function that will maintain byte counts.  With stack profiling, the
profiler also inserts a call to a C function at each nontail call in
order to maintain information at runtime about what SML functions are
on the stack.</simpara>
<simpara>At run time, the profiler associates counters (either clock ticks or
byte counts) with source functions.  When the program finishes, the
profiler writes the counts out to the <literal>mlmon.out</literal> file.  Then,
<literal>mlprof</literal> uses source information stored in the executable to
associate the counts in the <literal>mlmon.out</literal> file with source
functions.</simpara>
<simpara>For time profiling, the profiler catches the <literal>SIGPROF</literal> signal 100
times per second and increments the appropriate counter, determined by
looking at the label prefixing the current program counter and mapping
that to the current source function.</simpara>
<section id="_caveats_2">
<title>Caveats</title>
<simpara>There may be a few missed clock ticks or bytes allocated at the very
end of the program after the data is written.</simpara>
<simpara>Profiling has not been tested with signals or threads.  In particular,
stack profiling may behave strangely.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Identifier">
<title>Identifier</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, there are syntactically two kinds of
identifiers.</simpara>
<itemizedlist>
<listitem>
<simpara>
Alphanumeric: starts with a letter or prime (<literal>'</literal>) and is followed by letters, digits, primes and underbars (<literal>_</literal>).
</simpara>
<simpara>Examples: <literal>abc</literal>, <literal>ABC123</literal>, <literal>Abc_123</literal>, <literal>'a</literal>.</simpara>
</listitem>
<listitem>
<simpara>
Symbolic: a sequence of the following
</simpara>
<screen> ! % &amp; $ # + - / : &lt; = &gt; ? @ | ~ ` ^ | *</screen>
<simpara>Examples: <literal>+=</literal>, <literal>&lt;=</literal>, <literal>&gt;&gt;</literal>, <literal>$</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara>With the exception of <literal>=</literal>, reserved words can not be identifiers.</simpara>
<simpara>There are a number of different classes of identifiers, some of which
have additional syntactic rules.</simpara>
<itemizedlist>
<listitem>
<simpara>
Identifiers not starting with a prime.
</simpara>
<itemizedlist>
<listitem>
<simpara>
value identifier (includes variables and constructors)
</simpara>
</listitem>
<listitem>
<simpara>
type constructor
</simpara>
</listitem>
<listitem>
<simpara>
structure identifier
</simpara>
</listitem>
<listitem>
<simpara>
signature identifier
</simpara>
</listitem>
<listitem>
<simpara>
functor identifier
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Identifiers starting with a prime.
</simpara>
<itemizedlist>
<listitem>
<simpara>
type variable
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Identifiers not starting with a prime and numeric labels (<literal>1</literal>, <literal>2</literal>, &#8230;).
</simpara>
<itemizedlist>
<listitem>
<simpara>
record label
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Immutable">
<title>Immutable</title>
<simpara>Immutable means not <link linkend="Mutable">mutable</link> and is an adjective meaning
"can not be modified".  Most values in <link linkend="StandardML">Standard ML</link> are
immutable.  For example, constants, tuples, records, lists, and
vectors are all immutable.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ImperativeTypeVariable">
<title>ImperativeTypeVariable</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, an imperative type variable is a type
variable whose second character is a digit, as in <literal>'1a</literal> or
<literal>'2b</literal>.  Imperative type variables were used as an alternative to
the <link linkend="ValueRestriction">ValueRestriction</link> in an earlier version of SML, but no longer play
a role.  They are treated exactly as other type variables.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ImplementExceptions">
<title>ImplementExceptions</title>
<simpara><link linkend="ImplementExceptions">ImplementExceptions</link> is a pass for the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SXMLSimplify">SXMLSimplify</link>.</simpara>
<section id="_description_20">
<title>Description</title>
<simpara>This pass implements exceptions.</simpara>
</section>
<section id="_implementation_22">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/implement-exceptions.fun"><literal>implement-exceptions.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_22">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ImplementHandlers">
<title>ImplementHandlers</title>
<simpara><link linkend="ImplementHandlers">ImplementHandlers</link> is a pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="RSSASimplify">RSSASimplify</link>.</simpara>
<section id="_description_21">
<title>Description</title>
<simpara>This pass implements the (threaded) exception handler stack.</simpara>
</section>
<section id="_implementation_23">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/implement-handlers.fun"><literal>implement-handlers.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_23">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ImplementProfiling">
<title>ImplementProfiling</title>
<simpara><link linkend="ImplementProfiling">ImplementProfiling</link> is a pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="RSSASimplify">RSSASimplify</link>.</simpara>
<section id="_description_22">
<title>Description</title>
<simpara>This pass implements profiling.</simpara>
</section>
<section id="_implementation_24">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/implement-profiling.fun"><literal>implement-profiling.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_24">
<title>Details and Notes</title>
<simpara>See <link linkend="HowProfilingWorks">HowProfilingWorks</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ImplementSuffix">
<title>ImplementSuffix</title>
<simpara><link linkend="ImplementSuffix">ImplementSuffix</link> is a pass for the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SXMLSimplify">SXMLSimplify</link>.</simpara>
<section id="_description_23">
<title>Description</title>
<simpara>This pass implements the <literal>TopLevel_setSuffix</literal> primitive, which
installs a function to exit the program.</simpara>
</section>
<section id="_implementation_25">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/implement-suffix.fun"><literal>implement-suffix.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_25">
<title>Details and Notes</title>
<simpara><link linkend="ImplementSuffix">ImplementSuffix</link> works by introducing a new <literal>ref</literal> cell to contain
the function of type <literal>unit -&gt; unit</literal> that should be called on program
exit.</simpara>
<itemizedlist>
<listitem>
<simpara>
The following code (appropriately alpha-converted) is appended to the beginning of the <link linkend="SXML">SXML</link> program:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val z_0 =
  fn a_0 =&gt;
  let
    val x_0 =
      "toplevel suffix not installed"
    val x_1 =
      MLton_bug (x_0)
  in
    x_1
  end
val topLevelSuffixCell =
  Ref_ref (z_0)</programlisting>
</listitem>
<listitem>
<simpara>
Any occurrence of
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x_0 =
  TopLevel_setSuffix (f_0)</programlisting>
<simpara>is rewritten to</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x_0 =
  Ref_assign (topLevelSuffixCell, f_0)</programlisting>
</listitem>
<listitem>
<simpara>
The following code (appropriately alpha-converted) is appended to the end of the <link linkend="SXML">SXML</link> program:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f_0 =
  Ref_deref (topLevelSuffixCell)
val z_0 =
  ()
val x_0 =
  f_0 z_0</programlisting>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="InfixingOperators">
<title>InfixingOperators</title>
<simpara>Fixity specifications are not part of signatures in
<link linkend="StandardML">Standard ML</link>. When one wants to use a module that
provides functions designed to be used as infix operators there are
several obvious alternatives:</simpara>
<itemizedlist>
<listitem>
<simpara>
Use only prefix applications. Unfortunately there are situations
where infix applications lead to considerably more readable code.
</simpara>
</listitem>
<listitem>
<simpara>
Make the fixity declarations at the top-level. This may lead to
collisions and may be unsustainable in a large project. Pollution of
the top-level should be avoided.
</simpara>
</listitem>
<listitem>
<simpara>
Make the fixity declarations at each scope where you want to use
infix applications. The duplication becomes inconvenient if the
operators are widely used. Duplication of code should be avoided.
</simpara>
</listitem>
<listitem>
<simpara>
Use non-standard extensions, such as the <link linkend="MLBasis">ML Basis system</link>
to control the scope of fixity declarations. This has the obvious
drawback of reduced portability.
</simpara>
</listitem>
<listitem>
<simpara>
Reuse existing infix operator symbols (<literal>^</literal>, <literal>+</literal>, <literal>-</literal>, &#8230;).  This
can be convenient when the standard operators aren&#8217;t needed in the
same scope with the new operators.  On the other hand, one is limited
to the standard operator symbols and the code may appear confusing.
</simpara>
</listitem>
</itemizedlist>
<simpara>None of the obvious alternatives is best in every case. The following
describes a slightly less obvious alternative that can sometimes be
useful. The idea is to approximate Haskell&#8217;s special syntax for
treating any identifier enclosed in grave accents (backquotes) as an
infix operator. In Haskell, instead of writing the prefix application
<literal>f x y</literal> one can write the infix application <literal>x &grave;f&grave; y</literal>.</simpara>
<section id="_infixing_operators">
<title>Infixing operators</title>
<simpara>Let&#8217;s first take a look at the definitions of the operators:</simpara>
<programlisting language="sml" linenumbering="unnumbered">infix  3 &lt;\     fun x &lt;\ f = fn y =&gt; f (x, y)     (* Left section      *)
infix  3 \&gt;     fun f \&gt; y = f y                  (* Left application  *)
infixr 3 /&gt;     fun f /&gt; y = fn x =&gt; f (x, y)     (* Right section     *)
infixr 3 &lt;/     fun x &lt;/ f = f x                  (* Right application *)

infix  2 o  (* See motivation below *)
infix  0 :=</programlisting>
<simpara>The left and right sectioning operators, <literal>&lt;\</literal> and <literal>/&gt;</literal>, are useful in
SML for partial application of infix operators.
<link linkend="References_Paulson96">ML For the Working Programmer</link> describes curried
functions <literal>secl</literal> and <literal>secr</literal> for the same purpose on pages 179-181.
For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">List.map (op- /&gt; y)</programlisting>
<simpara>is a function for subtracting <literal>y</literal> from a list of integers and</simpara>
<programlisting language="sml" linenumbering="unnumbered">List.exists (x &lt;\ op=)</programlisting>
<simpara>is a function for testing whether a list contains an <literal>x</literal>.</simpara>
<simpara>Together with the left and right application operators, <literal>\&gt;</literal> and <literal>&lt;/</literal>,
the sectioning operators provide a way to treat any binary function
(i.e. a function whose domain is a pair) as an infix operator.  In
general,</simpara>
<screen>x0 &lt;\f1\&gt; x1 &lt;\f2\&gt; x2 ... &lt;\fN\&gt; xN = fN (... f2 (f1 (x0, x1), x2) ..., xN)</screen>
<simpara>and</simpara>
<screen>xN &lt;/fN/&gt; ... x2 &lt;/f2/&gt; x1 &lt;/f1/&gt; x0  =  fN (xN, ... f2 (x2, f1 (x1, x0)) ...)</screen>
<section id="_examples_2">
<title>Examples</title>
<simpara>As a fairly realistic example, consider providing a function for sequencing
comparisons:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Order (* ... *) =
   struct
      (* ... *)
      val orWhenEq = fn (EQUAL, th) =&gt; th ()
                      | (other,  _) =&gt; other
      (* ... *)
   end</programlisting>
<simpara>Using <literal>orWhenEq</literal> and the infixing operators, one can write a
<literal>compare</literal> function for triples as</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun compare (fad, fbe, fcf) ((a, b, c), (d, e, f)) =
    fad (a, d) &lt;\Order.orWhenEq\&gt; `fbe (b, e) &lt;\Order.orWhenEq\&gt; `fcf (c, f)</programlisting>
<simpara>where <literal>&grave;</literal> is defined as</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun `f x = fn () =&gt; f x</programlisting>
<simpara>Although <literal>orWhenEq</literal> can be convenient (try rewriting the above without
it), it is probably not useful enough to be defined at the top level
as an infix operator. Fortunately we can use the infixing operators
and don&#8217;t have to.</simpara>
<simpara>Another fairly realistic example would be to use the infixing operators with
the technique described on the <link linkend="Printf">Printf</link> page. Assuming that you would have
a <literal>Printf</literal> module binding <literal>printf</literal>, <literal>&grave;</literal>, and formatting combinators
named <literal>int</literal> and <literal>string</literal>, you could write</simpara>
<programlisting language="sml" linenumbering="unnumbered">let open Printf in
  printf (`"Here's an int "&lt;\int\&gt;" and a string "&lt;\string\&gt;".") 13 "foo" end</programlisting>
<simpara>without having to duplicate the fixity declarations. Alternatively, you could
write</simpara>
<programlisting language="sml" linenumbering="unnumbered">P.printf (P.`"Here's an int "&lt;\P.int\&gt;" and a string "&lt;\P.string\&gt;".") 13 "foo"</programlisting>
<simpara>assuming you have the made the binding</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure P = Printf</programlisting>
</section>
</section>
<section id="_application_and_piping_operators">
<title>Application and piping operators</title>
<simpara>The left and right application operators may also provide some notational
convenience on their own. In general,</simpara>
<screen>f \&gt; x1 \&gt; ... \&gt; xN = f x1 ... xN</screen>
<simpara>and</simpara>
<screen>xN &lt;/ ... &lt;/ x1 &lt;/ f = f x1 ... xN</screen>
<simpara>If nothing else, both of them can eliminate parentheses. For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">foo (1 + 2) = foo \&gt; 1 + 2</programlisting>
<simpara>The left and right application operators are related to operators
that could be described as the right and left piping operators:</simpara>
<programlisting language="sml" linenumbering="unnumbered">infix  1 &gt;|     val op&gt;| = op&lt;/      (* Left pipe *)
infixr 1 |&lt;     val op|&lt; = op\&gt;      (* Right pipe *)</programlisting>
<simpara>As you can see, the left and right piping operators, <literal>&gt;|</literal> and <literal>|&lt;</literal>,
are the same as the right and left application operators,
respectively, except the associativities are reversed and the binding
strength is lower. They are useful for piping data through a sequence
of operations. In general,</simpara>
<screen>x &gt;| f1 &gt;| ... &gt;| fN = fN (... (f1 x) ...) = (fN o ... o f1) x</screen>
<simpara>and</simpara>
<screen>fN |&lt; ... |&lt; f1 |&lt; x = fN (... (f1 x) ...) = (fN o ... o f1) x</screen>
<simpara>The right piping operator, <literal>|&lt;</literal>, is provided by the Haskell prelude as
<literal>$</literal>. It can be convenient in CPS or continuation passing style.</simpara>
<simpara>A use for the left piping operator is with parsing combinators. In a
strict language, like SML, eta-reduction is generally unsafe. Using
the left piping operator, parsing functions can be formatted
conveniently as</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun parsingFunc input =
   input &gt;| (* ... *)
         || (* ... *)
         || (* ... *)</programlisting>
<simpara>where <literal>||</literal> is supposed to be a combinator provided by the parsing combinator
library.</simpara>
</section>
<section id="_about_precedences">
<title>About precedences</title>
<simpara>You probably noticed that we redefined the
<link linkend="OperatorPrecedence">precedences</link> of the function composition operator
<literal>o</literal> and the assignment operator <literal>:=</literal>. Doing so is not strictly
necessary, but can be convenient and should be relatively
safe. Consider the following motivating examples from
<link linkend="WesleyTerpstra">Wesley W. Terpstra</link> relying on the redefined
precedences:</simpara>
<programlisting language="sml" linenumbering="unnumbered">Word8.fromInt o Char.ord o s &lt;\String.sub
(* Combining sectioning and composition *)

x := s &lt;\String.sub\&gt; i
(* Assigning the result of an infixed application *)</programlisting>
<simpara>In imperative languages, assignment usually has the lowest precedence
(ignoring statement separators). The precedence of <literal>:=</literal> in the
<link linkend="BasisLibrary">Basis Library</link> is perhaps unnecessarily high, because
an expression of the form <literal>r := x</literal> always returns a unit, which makes
little sense to combine with anything. Dropping <literal>:=</literal> to the lowest
precedence level makes it behave more like in other imperative
languages.</simpara>
<simpara>The case for <literal>o</literal> is different. With the exception of <literal>before</literal> and
<literal>:=</literal>, it doesn&#8217;t seem to make much sense to use <literal>o</literal> with any of the
operators defined by the <link linkend="BasisLibrary">Basis Library</link> in an
unparenthesized expression. This is simply because none of the other
operators deal with functions. It would seem that the precedence of
<literal>o</literal> could be chosen completely arbitrarily from the set <literal>{1, ..., 9}</literal>
without having any adverse effects with respect to other infix
operators defined by the <link linkend="BasisLibrary">Basis Library</link>.</simpara>
</section>
<section id="_design_of_the_symbols">
<title>Design of the symbols</title>
<simpara>The closest approximation of Haskell&#8217;s <literal>x &grave;f&grave; y</literal> syntax
achievable in Standard ML would probably be something like
<literal>x &grave;f^ y</literal>, but <literal>^</literal> is already used for string
concatenation by the <link linkend="BasisLibrary">Basis Library</link>. Other
combinations of the characters <literal>&grave;</literal> and <literal>^</literal> would be
possible, but none seems clearly the best visually. The symbols <literal>&lt;\</literal>,
<literal>\&gt;</literal>, <literal>&lt;/</literal>, and <literal>/&gt;</literal> are reasonably concise and have a certain
self-documenting appearance and symmetry, which can help to remember
them.  As the names suggest, the symbols of the piping operators <literal>&gt;|</literal>
and <literal>|&lt;</literal> are inspired by Unix shell pipelines.</simpara>
</section>
<section id="_also_see_7">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Utilities">Utilities</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Inline">
<title>Inline</title>
<simpara><link linkend="Inline">Inline</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_24">
<title>Description</title>
<simpara>This pass inlines <link linkend="SSA">SSA</link> functions using a size-based metric.</simpara>
</section>
<section id="_implementation_26">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/inline.sig"><literal>inline.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/inline.fun"><literal>inline.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_26">
<title>Details and Notes</title>
<simpara>The <link linkend="Inline">Inline</link> pass can be invoked to use one of three metrics:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>NonRecursive(product, small)</literal>&#8201;&#8212;&#8201;inline any function satisfying <literal>(numCalls - 1) * (size - small) &lt;= product</literal>, where <literal>numCalls</literal> is the static number of calls to the function and <literal>size</literal> is the size of the function.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Leaf(size)</literal>&#8201;&#8212;&#8201;inline any leaf function smaller than <literal>size</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>LeafNoLoop(size)</literal>&#8201;&#8212;&#8201;inline any leaf function without loops smaller than <literal>size</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="InsertLimitChecks">
<title>InsertLimitChecks</title>
<simpara><link linkend="InsertLimitChecks">InsertLimitChecks</link> is a pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="RSSASimplify">RSSASimplify</link>.</simpara>
<section id="_description_25">
<title>Description</title>
<simpara>This pass inserts limit checks.</simpara>
</section>
<section id="_implementation_27">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/limit-check.fun"><literal>limit-check.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_27">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="InsertSignalChecks">
<title>InsertSignalChecks</title>
<simpara><link linkend="InsertSignalChecks">InsertSignalChecks</link> is a pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="RSSASimplify">RSSASimplify</link>.</simpara>
<section id="_description_26">
<title>Description</title>
<simpara>This pass inserts signal checks.</simpara>
</section>
<section id="_implementation_28">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/limit-check.fun"><literal>limit-check.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_28">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Installation">
<title>Installation</title>
<simpara>MLton runs on a variety of platforms and is distributed in both source and
binary form.</simpara>
<simpara>A <literal>.tgz</literal> or <literal>.tbz</literal> binary package can be extracted at any location, yielding
<literal>README.adoc</literal> (this file), <literal>CHANGELOG.adoc</literal>, <literal>LICENSE</literal>, <literal>Makefile</literal>, <literal>bin/</literal>,
<literal>lib/</literal>, and <literal>share/</literal>.  The compiler and tools can be executed in-place (e.g.,
<literal>./bin/mlton</literal>).</simpara>
<simpara>A small set of <literal>Makefile</literal> variables can be used to customize the binary package
via <literal>make update</literal>:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>CC</literal>: Specify C compiler.  Can be used for alternative tools (e.g.,
   <literal>CC=clang</literal> or <literal>CC=gcc-7</literal>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>WITH_GMP_DIR</literal>, <literal>WITH_GMP_INC_DIR</literal>, <literal>WITH_GMP_LIB_DIR</literal>: Specify GMP include
   and library paths, if not on default search paths.  (If <literal>WITH_GMP_DIR</literal> is
   set, then <literal>WITH_GMP_INC_DIR</literal> defaults to <literal>$(WITH_GMP_DIR)/include</literal> and
   <literal>WITH_GMP_LIB_DIR</literal> defaults to <literal>$(WITH_GMP_DIR)/lib</literal>.)
</simpara>
</listitem>
</itemizedlist>
<simpara>For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">$ make CC=clang WITH_GMP_DIR=/opt/gmp update</programlisting>
<simpara>On typical platforms, installing MLton (after optionally performing
<literal>make update</literal>) to <literal>/usr/local</literal> can be accomplished via:</simpara>
<programlisting language="sml" linenumbering="unnumbered">$ make install</programlisting>
<simpara>A small set of <literal>Makefile</literal> variables can be used to customize the installation:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>PREFIX</literal>: Specify the installation prefix.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>CC</literal>: Specify C compiler.  Can be used for alternative tools (e.g.,
   <literal>CC=clang</literal> or <literal>CC=gcc-7</literal>).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>WITH_GMP_DIR</literal>, <literal>WITH_GMP_INC_DIR</literal>, <literal>WITH_GMP_LIB_DIR</literal>: Specify GMP include
   and library paths, if not on default search paths.  (If <literal>WITH_GMP_DIR</literal> is
   set, then <literal>WITH_GMP_INC_DIR</literal> defaults to <literal>$(WITH_GMP_DIR)/include</literal> and
   <literal>WITH_GMP_LIB_DIR</literal> defaults to <literal>$(WITH_GMP_DIR)/lib</literal>.)
</simpara>
</listitem>
</itemizedlist>
<simpara>For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">$ make PREFIX=/opt/mlton install</programlisting>
<simpara>Installation of MLton creates the following files and directories.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/bin/mllex</literal>
</simpara>
<simpara>The <link linkend="MLLex">MLLex</link> lexer generator.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/bin/mlnlffigen</literal>
</simpara>
<simpara>The <link linkend="MLNLFFI">ML-NLFFI</link> tool.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/bin/mlprof</literal>
</simpara>
<simpara>A <link linkend="Profiling">Profiling</link> tool.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/bin/mlton</literal>
</simpara>
<simpara>A script to call the compiler.  This script may be moved anywhere,
however, it makes use of files in <literal><emphasis>prefix</emphasis>/lib/mlton</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/bin/mlyacc</literal>
</simpara>
<simpara>The <link linkend="MLYacc">MLYacc</link> parser generator.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/lib/mlton</literal>
</simpara>
<simpara>Directory containing libraries and include files needed during compilation.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/share/man/man1/{mllex,mlnlffigen,mlprof,mlton,mlyacc}.1</literal>
</simpara>
<simpara>Man pages.</simpara>
</listitem>
<listitem>
<simpara>
<literal><emphasis>prefix</emphasis>/share/doc/mlton</literal>
</simpara>
<simpara>Directory containing the user guide for MLton, mllex, and mlyacc, as
well as example SML programs (in the <literal>examples</literal> directory), and license
information.</simpara>
</listitem>
</itemizedlist>
<section id="_hello_world">
<title>Hello, World!</title>
<simpara>Once you have installed MLton, create a file called <literal>hello-world.sml</literal>
with the following contents.</simpara>
<screen>print "Hello, world!\n";</screen>
<simpara>Now create an executable, <literal>hello-world</literal>, with the following command.</simpara>
<screen>mlton hello-world.sml</screen>
<simpara>You can now run <literal>hello-world</literal> to verify that it works.  There are more
small examples in <literal><emphasis>prefix</emphasis>/share/doc/mlton/examples</literal>.</simpara>
</section>
<section id="_installation_on_cygwin">
<title>Installation on Cygwin</title>
<simpara>When installing the Cygwin <literal>tgz</literal>, you should use Cygwin&#8217;s <literal>bash</literal> and
<literal>tar</literal>.  The use of an archiving tool that is not aware of Cygwin&#8217;s
mounts will put the files in the wrong place.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="IntermediateLanguage">
<title>IntermediateLanguage</title>
<simpara>MLton uses a number of intermediate languages in translating from the input source program to low-level code.  Here is a list in the order which they are translated to.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="AST">AST</link>.  Pretty close to the source.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CoreML">CoreML</link>.  Explicitly typed, no module constructs.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="XML">XML</link>.  Polymorphic, <link linkend="HigherOrder">HigherOrder</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SXML">SXML</link>.  SimplyTyped, <link linkend="HigherOrder">HigherOrder</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SSA">SSA</link>.  SimplyTyped, <link linkend="FirstOrder">FirstOrder</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SSA2">SSA2</link>.  SimplyTyped, <link linkend="FirstOrder">FirstOrder</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RSSA">RSSA</link>.  Explicit data representations.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Machine">Machine</link>.  Untyped register transfer language.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="IntroduceLoops">
<title>IntroduceLoops</title>
<simpara><link linkend="IntroduceLoops">IntroduceLoops</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_27">
<title>Description</title>
<simpara>This pass rewrites any <link linkend="SSA">SSA</link> function that calls itself in tail
position into one with a local loop and no self tail calls.</simpara>
<simpara>A <link linkend="SSA">SSA</link> function like</simpara>
<screen>fun F (arg_0, arg_1) = L_0 ()
  ...
  L_16 (x_0)
    ...
    F (z_0, z_1) Tail
  ...</screen>
<simpara>becomes</simpara>
<screen>fun F (arg_0', arg_1') = loopS_0 ()
  loopS_0 ()
    loop_0 (arg_0', arg_1')
  loop_0 (arg_0, arg_1)
    L_0 ()
  ...
  L_16 (x_0)
    ...
    loop_0 (z_0, z_1)
  ...</screen>
</section>
<section id="_implementation_29">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/introduce-loops.fun"><literal>introduce-loops.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_29">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="JesperLouisAndersen">
<title>JesperLouisAndersen</title>
<simpara>Jesper Louis Andersen is an undergraduate student at DIKU, the department of computer science, Copenhagen university. His contributions to MLton are few, though he has made the port of MLton to the NetBSD and OpenBSD platforms.</simpara>
<simpara>His general interests in computer science are compiler theory, language theory, algorithms and datastructures and programming. His assets are his general knowledge of UNIX systems, knowledge of system administration, knowledge of operating system kernels; NetBSD in particular.</simpara>
<simpara>He was employed by the university as a system administrator for 2 years, which has set him back somewhat in his studies. Currently he is trying to learn mathematics (real analysis, general topology, complex functional analysis and algebra).</simpara>
<section id="_projects_using_mlton">
<title>Projects using MLton</title>
<section id="_a_register_allocator">
<title>A register allocator</title>
<simpara>For internal use at a compiler course at DIKU. It is written in the literate programming style and implements the <emphasis>Iterated Register Coalescing</emphasis> algorithm by Lal George and Andrew Appel <ulink url="http://citeseer.ist.psu.edu/george96iterated.html">http://citeseer.ist.psu.edu/george96iterated.html</ulink>. The status of the project is that it is unfinished. Most of the basic parts of the algorithm is done, but the interface to the students (simple) datatype takes some conversion.</simpara>
</section>
<section id="_a_configuration_management_system_in_sml">
<title>A configuration management system in SML</title>
<simpara>At this time, only loose plans exists for this. The plan is to build a Configuration Management system on the principles of the OpenCM system, see <ulink url="http://www.opencm.org/docs.html">http://www.opencm.org/docs.html</ulink>. The basic idea is to unify "naming" and "identity" into one by uniquely identifying all objects managed in the repository by the use of cryptographic checksums. This mantra guides the rest of the system, providing integrity, accessibility and confidentiality.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="JohnnyAndersen">
<title>JohnnyAndersen</title>
<simpara>Johnny Andersen (aka Anoq of the Sun)</simpara>
<simpara>Here is a picture in front of the academy building
at the University of Athens, Greece, taken in September 2003.</simpara>
<informalfigure>
<mediaobject>
  <imageobject>
  <imagedata fileref="JohnnyAndersen.attachments/anoq.jpg" align="center"/>
  </imageobject>
  <textobject><phrase>JohnnyAndersen.attachments/anoq.jpg</phrase></textobject>
</mediaobject>
</informalfigure>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="KnownCase">
<title>KnownCase</title>
<simpara><link linkend="KnownCase">KnownCase</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_28">
<title>Description</title>
<simpara>This pass duplicates and simplifies <literal>Case</literal> transfers when the
constructor of the scrutinee is known.</simpara>
<simpara>Uses <link linkend="Restore">Restore</link>.</simpara>
<simpara>For example, the program</simpara>
<programlisting language="sml" linenumbering="unnumbered">val rec last =
  fn [] =&gt; 0
   | [x] =&gt; x
   | _ :: l =&gt; last l

val _ = 1 + last [2, 3, 4, 5, 6, 7]</programlisting>
<simpara>gives rise to the <link linkend="SSA">SSA</link> function</simpara>
<screen>fun last_0 (x_142) = loopS_1 ()
  loopS_1 ()
    loop_11 (x_142)
  loop_11 (x_143)
    case x_143 of
      nil_1 =&gt; L_73 | ::_0 =&gt; L_74
  L_73 ()
    return global_5
  L_74 (x_145, x_144)
    case x_145 of
      nil_1 =&gt; L_75 | _ =&gt; L_76
  L_75 ()
    return x_144
  L_76 ()
    loop_11 (x_145)</screen>
<simpara>which is simplified to</simpara>
<screen>fun last_0 (x_142) = loopS_1 ()
  loopS_1 ()
    case x_142 of
      nil_1 =&gt; L_73 | ::_0 =&gt; L_118
  L_73 ()
    return global_5
  L_118 (x_230, x_229)
    L_74 (x_230, x_229, x_142)
  L_74 (x_145, x_144, x_232)
    case x_145 of
      nil_1 =&gt; L_75 | ::_0 =&gt; L_114
  L_75 ()
    return x_144
  L_114 (x_227, x_226)
    L_74 (x_227, x_226, x_145)</screen>
</section>
<section id="_implementation_30">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/known-case.fun"><literal>known-case.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_30">
<title>Details and Notes</title>
<simpara>One interesting aspect of <link linkend="KnownCase">KnownCase</link>, is that it often has the
effect of unrolling list traversals by one iteration, moving the
<literal>nil</literal>/<literal>::</literal> check to the end of the loop, rather than the beginning.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LambdaCalculus">
<title>LambdaCalculus</title>
<simpara>The <ulink url="http://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</ulink> is
the formal system underlying <link linkend="StandardML">Standard ML</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="LambdaFree">
<title>LambdaFree</title>
<simpara><link linkend="LambdaFree">LambdaFree</link> is an analysis pass for the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ClosureConvert">ClosureConvert</link>.</simpara>
<section id="_description_29">
<title>Description</title>
<simpara>This pass descends the entire <link linkend="SXML">SXML</link> program and attaches a property
to each <literal>Lambda</literal> <literal>PrimExp.t</literal> in the program.  Then, you can use
<literal>lambdaFree</literal> and <literal>lambdaRec</literal> to get free variables of that <literal>Lambda</literal>.</simpara>
</section>
<section id="_implementation_31">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/closure-convert/lambda-free.sig"><literal>lambda-free.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/closure-convert/lambda-free.fun"><literal>lambda-free.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_31">
<title>Details and Notes</title>
<simpara>For <literal>Lambda</literal>-s bound in a <literal>Fun</literal> dec, <literal>lambdaFree</literal> gives the union of
the frees of the entire group of mutually recursive functions.  Hence,
<literal>lambdaFree</literal> for every <literal>Lambda</literal> in a single <literal>Fun</literal> dec is the same.
Furthermore, for a <literal>Lambda</literal> bound in a <literal>Fun</literal> dec, <literal>lambdaRec</literal> gives
the list of other functions bound in the same dec defining that
<literal>Lambda</literal>.</simpara>
<simpara>For example:</simpara>
<screen>val rec f = fn x =&gt; ... y ... g ... f ...
and g = fn z =&gt; ... f ... w ...</screen>
<screen>lambdaFree(fn x =&gt;) = [y, w]
lambdaFree(fn z =&gt;) = [y, w]
lambdaRec(fn x =&gt;) = [g, f]
lambdaRec(fn z =&gt;) = [f]</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LanguageChanges">
<title>LanguageChanges</title>
<simpara>We are sometimes asked to modify MLton to change the language it
compiles.  In short, we are conservative about making such changes.
There are a number of reasons for this.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="DefinitionOfStandardML">The Definition of Standard ML</link> is an
extremely high standard of specification.  The value of the Definition
would be significantly diluted by changes that are not specified at an
equally high level, and the dilution increases with the complexity of
the language change and its interaction with other language features.
</simpara>
</listitem>
<listitem>
<simpara>
The SML community is small and there are a number of
<link linkend="StandardMLImplementations">SML implementations</link>.  Without an
agreed-upon standard, it becomes very difficult to port programs
between compilers, and the community would be balkanized.
</simpara>
</listitem>
<listitem>
<simpara>
Our main goal is to enable programmers to be as effective as
possible with MLton/SML.  There are a number of improvements other
than language changes that we could spend our time on that would
provide more benefit to programmers.
</simpara>
</listitem>
<listitem>
<simpara>
The more the language that MLton compiles changes over time, the
more difficult it is to use MLton as a stable platform for serious
program development.
</simpara>
</listitem>
</itemizedlist>
<simpara>Despite these drawbacks, we have extended SML in a couple of cases.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ForeignFunctionInterface">Foreign function interface</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasis">ML Basis system</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SuccessorML">Successor ML features</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>We allow these language extensions because they provide functionality
that is impossible to achieve without them or have non-trivial
community support.  The Definition does not define a foreign function
interface.  So, we must either extend the language or greatly restrict
the class of programs that can be written.  Similarly, the Definition
does not provide a mechanism for namespace control at the module
level, making it impossible to deliver packaged libraries and have a
hope of users using them without name clashes.  The ML Basis system
addresses this problem.  We have also provided a formal specification
of the ML Basis system at the level of the Definition.</simpara>
<section id="_also_see_8">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-August/016165.html">http://www.mlton.org/pipermail/mlton/2004-August/016165.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2004-December/000320.html">http://www.mlton.org/pipermail/mlton-user/2004-December/000320.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Lazy">
<title>Lazy</title>
<simpara>In a lazy (or non-strict) language, the arguments to a function are
not evaluated before calling the function.  Instead, the arguments are
suspended and only evaluated by the function if needed.</simpara>
<simpara><link linkend="StandardML">Standard ML</link> is an eager (or strict) language, not a lazy
language.  However, it is easy to delay evaluation of an expression in
SML by creating a <emphasis>thunk</emphasis>, which is a nullary function.  In SML, a
thunk is written <literal>fn () =&gt; e</literal>.  Another essential feature of laziness
is <emphasis>memoization</emphasis>, meaning that once a suspended argument is evaluated,
subsequent references look up the value.  We can express this in SML
with a function that maps a thunk to a memoized thunk.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature LAZY =
   sig
      val lazy: (unit -&gt; 'a) -&gt; unit -&gt; 'a
   end</programlisting>
<simpara>This is easy to implement in SML.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Lazy: LAZY =
   struct
      fun lazy (th: unit -&gt; 'a): unit -&gt; 'a =
         let
            datatype 'a lazy_result = Unevaluated of (unit -&gt; 'a)
                                    | Evaluated of 'a
                                    | Failed of exn

            val r = ref (Unevaluated th)
         in
            fn () =&gt;
               case !r of
                   Unevaluated th =&gt; let
                                       val a  = th ()
                                           handle x =&gt; (r := Failed x; raise x)
                                       val () =         r := Evaluated a
                                     in
                                       a
                                     end
                 | Evaluated a =&gt; a
                 | Failed x    =&gt; raise x
         end
   end</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Libraries">
<title>Libraries</title>
<simpara>In theory every strictly conforming Standard ML program should run on
MLton.  However, often large SML projects use implementation specific
features so some "porting" is required. Here is a partial list of
software that is known to run on MLton.</simpara>
<itemizedlist>
<listitem>
<simpara>
Utility libraries:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="SMLNJLibrary">SMLNJLibrary</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonLibraryProject">MLtonLibraryProject</link> - various libraries located on the MLton subversion repository
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/tree/master/lib/mlton"><literal>mlton</literal></ulink> - the internal MLton utility library, which we hope to cleanup and make more accessible someday
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://github.com/seanmcl/sml-ext">sml-ext</ulink>, a grab bag of libraries for MLton and other SML implementations (by Sean McLaughlin)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://tom7misc.cvs.sourceforge.net/tom7misc/sml-lib/">sml-lib</ulink>, a grab bag of libraries for MLton and other SML implementations (by <link linkend="TomMurphy">TomMurphy</link>)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Scanner generators:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLLPTLibrary">MLLPTLibrary</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLLex">MLLex</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLULex">MLULex</link> -
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Parser generators:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLAntlr">MLAntlr</link> -
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLLPTLibrary">MLLPTLibrary</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLYacc">MLYacc</link> - distributed with MLton
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Concurrency: <link linkend="ConcurrentML">ConcurrentML</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
Graphics
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="SML3d">SML3d</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="mGTK">mGTK</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Misc. libraries:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CKitLibrary">CKitLibrary</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLRISCLibrary">MLRISCLibrary</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLNLFFI">ML-NLFFI</link> - distributed with MLton
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Swerve">Swerve</link>, an HTTP server
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="fxp">fxp</link>, an XML parser
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<section id="_ports_in_progress">
<title>Ports in progress</title>
<simpara><link linkend="Contact">Contact</link> us for details on any of these.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLDoc">MLDoc</link> <ulink url="http://people.cs.uchicago.edu/%7Ejhr/tools/ml-doc.html">http://people.cs.uchicago.edu/%7Ejhr/tools/ml-doc.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Unicode">Unicode</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_more">
<title>More</title>
<simpara>More projects using MLton can be seen on the <link linkend="Users">Users</link> page.</simpara>
</section>
<section id="_software_for_sml_implementations_other_than_mlton">
<title>Software for SML implementations other than MLton</title>
<itemizedlist>
<listitem>
<simpara>
PostgreSQL
</simpara>
<itemizedlist>
<listitem>
<simpara>
Moscow ML: <ulink url="http://www.dina.kvl.dk/%7Esestoft/mosmllib/Postgres.html">http://www.dina.kvl.dk/%7Esestoft/mosmllib/Postgres.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ NLFFI: <ulink url="http://smlweb.sourceforge.net/smlsql/">http://smlweb.sourceforge.net/smlsql/</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Web:
</simpara>
<itemizedlist>
<listitem>
<simpara>
ML Kit: <ulink url="http://www.smlserver.org">SMLserver</ulink>  (a plugin for AOLserver)
</simpara>
</listitem>
<listitem>
<simpara>
Moscow ML: <ulink url="http://ellemose.dina.kvl.dk/%7Esestoft/msp/index.msp">ML Server Pages</ulink> (support for PHP-style CGI scripting)
</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ: <ulink url="http://smlweb.sourceforge.net/">smlweb</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LibrarySupport">
<title>LibrarySupport</title>
<simpara>MLton supports both linking to and creating system-level libraries.
While Standard ML libraries should be designed with the <link linkend="MLBasis">MLBasis</link> system to work with other Standard ML programs,
system-level library support allows MLton to create libraries for use by other programming languages.
Even more importantly, system-level library support allows MLton to access libraries from other languages.
This article will explain how to use libraries portably with MLton.</simpara>
<section id="_the_basics">
<title>The Basics</title>
<simpara>A Dynamic Shared Object (DSO) is a piece of executable code written in a format understood by the operating system.
Executable programs and dynamic libraries are the two most common examples of a DSO.
They are called shared because if they are used more than once, they are only loaded once into main memory.
For example, if you start two instances of your web browser (an executable), there may be two processes running, but the program code of the executable is only loaded once.
A dynamic library, for example a graphical toolkit, might be used by several different executable programs, each possibly running multiple times.
Nevertheless, the dynamic library is only loaded once and it&#8217;s program code is shared between all of the processes.</simpara>
<simpara>In addition to program code, DSOs contain a table of textual strings called symbols.
These are used in order to make the DSO do something useful, like execute.
For example, on linux the symbol <literal>_start</literal> refers to the point in the program code where the operating system should start executing the program.
Dynamic libraries generally provide many symbols, corresponding to functions which can be called and variables which can be read or written.
Symbols can be used by the DSO itself, or by other DSOs which require services.</simpara>
<simpara>When a DSO creates a symbol, this is called <emphasis>exporting</emphasis>.
If a DSO needs to use a symbol, this is called <emphasis>importing</emphasis>.
A DSO might need to use symbols defined within itself or perhaps from another DSO.
In both cases, it is importing that symbol, but the scope of the import differs.
Similarly, a DSO might export a symbol for use only within itself, or it might export a symbol for use by other DSOs.
Some symbols are resolved at compile time by the linker (those used within the DSO) and some are resolved at runtime by the dynamic link loader (symbols accessed between DSOs).</simpara>
</section>
<section id="_symbols_in_mlton">
<title>Symbols in MLton</title>
<simpara>Symbols in MLton are both imported and exported via the <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link>.
The notation <literal>_import "symbolname"</literal> imports functions, <literal>_symbol "symbolname"</literal> imports variables, and <literal>_address "symbolname"</literal> imports an address.
To create and export a symbol, <literal>_export "symbolname"</literal> creates a function symbol and <literal>_symbol "symbolname" 'alloc'</literal> creates and exports a variable.
For details of the syntax and restrictions on the supported FFI types, read the <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> page.
In this discussion it only matters that every FFI use is either an import or an export.</simpara>
<simpara>When exporting a symbol, MLton supports controlling the export scope.
If the symbol should only be used within the same DSO, that symbol has <emphasis><literal>private</literal></emphasis> scope.
Conversely, if the symbol should also be available to other DSOs the symbol has <emphasis><literal>public</literal></emphasis> scope.
Generally, one should have as few public exports as possible.
Since they are public, other DSOs will come to depend on them, limiting your ability to change them.
You specify the export scope in MLton by putting <literal>private</literal> or <literal>public</literal> after the symbol&#8217;s name in an FFI directive.
eg: <literal>_export "foo" private: int-&gt;int;</literal> or <literal>_export "bar" public: int-&gt;int;</literal> .</simpara>
<simpara>For technical reasons, the linker and loader on various platforms need to know the scope of a symbol being imported.
If the symbol is exported by the same DSO, use <literal>public</literal> or <literal>private</literal> as appropriate.
If the symbol is exported by a different DSO, then the scope <emphasis><literal>external</literal></emphasis> should be used to import it.
Within a DSO, all references to a symbol must use the same scope.
MLton will check this at compile time, reporting: <literal>symbol "foo" redeclared as public (previously external)</literal>. This may cause linker errors.
However, MLton can only check usage within Standard ML.
All objects being linked into a resulting DSO must agree, and it is the programmer&#8217;s responsibility to ensure this.</simpara>
<simpara>Summary of symbol scopes:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>private</literal>: used for symbols exported within a DSO only for use within that DSO
</simpara>
</listitem>
<listitem>
<simpara>
<literal>public</literal>: used for symbols exported within a DSO that may also be used outside that DSO
</simpara>
</listitem>
<listitem>
<simpara>
<literal>external</literal>: used for importing symbols from another DSO
</simpara>
</listitem>
<listitem>
<simpara>
All uses of a symbol within a DSO (both imports and exports) must agree on the symbol scope
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_output_formats">
<title>Output Formats</title>
<simpara>MLton can create executables (<literal>-format executable</literal>) and dynamic shared libraries (<literal>-format library</literal>).
To link a shared library, use <literal>-link-opt -l&lt;dso_name&gt;</literal>.
The default output format is executable.</simpara>
<simpara>MLton can also create archives.
An archive is not a DSO, but it does have a collection of symbols.
When an archive is linked into a DSO, it is completely absorbed.
Other objects being compiled into the DSO should refer to the public symbols in the archive as public, since they are still in the same DSO.
However, in the interest of modular programming, private symbols in an archive cannot be used outside of that archive, even within the same DSO.</simpara>
<simpara>Although both executables and libraries are DSOs, some implementation details differ on some platforms.
For this reason, MLton can create two types or archives.
A normal archive (<literal>-format archive</literal>) is appropriate for linking into an executable.
Conversely, a libarchive (<literal>-format libarchive</literal>) should be used if it will be linked into a dynamic library.</simpara>
<simpara>When MLton does not create an executable, it creates two special symbols.
The symbol <literal>libname_open</literal> is a function which must be called before any other symbols are accessed.
The <literal>libname</literal> is controlled by the <literal>-libname</literal> compile option and defaults to the name of the output, with any prefixing lib stripped (eg: <literal>foo</literal> &#8594; <literal>foo</literal>, <literal>libfoo</literal> &#8594; <literal>foo</literal>).
The symbol <literal>libname_close</literal> is a function which should be called to clean up memory once done.</simpara>
<simpara>Summary of <literal>-format</literal> options:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>executable</literal>: create an executable (a DSO)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>library</literal>: create a dynamic shared library (a DSO)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>archive</literal>: create an archive of symbols (not a DSO) that can be linked into an executable
</simpara>
</listitem>
<listitem>
<simpara>
<literal>libarchive</literal>: create an archive of symbols (not a DSO) that can be linked into a library
</simpara>
</listitem>
</itemizedlist>
<simpara>Related options:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-libname x</literal>: controls the name of the special <literal>_open</literal> and <literal>_close</literal> functions.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_interfacing_with_c">
<title>Interfacing with C</title>
<simpara>MLton can generate a C header file.
When the output format is not an executable, it creates one by default named <literal>libname.h</literal>.
This can be overridden with <literal>-export-header foo.h</literal>.
This header file should be included by any C files using the exported Standard ML symbols.</simpara>
<simpara>If C is being linked with Standard ML into the same output archive or DSO,
then the C code should <literal>#define PART_OF_LIBNAME</literal> before it includes the header file.
This ensures that the C code is using the symbols with correct scope.
Any symbols exported from C should also be marked using the <literal>PRIVATE</literal>/<literal>PUBLIC</literal>/<literal>EXTERNAL</literal> macros defined in the Standard ML export header.
The declared C scope on exported C symbols should match the import scope used in Standard ML.</simpara>
<simpara>An example:</simpara>
<programlisting language="c" linenumbering="unnumbered">#define PART_OF_FOO
#include "foo.h"

PUBLIC int cFoo() {
  return smlFoo();
}</programlisting>
<programlisting language="sml" linenumbering="unnumbered">val () = _export "smlFoo" private: unit -&gt; int; (fn () =&gt; 5)
val cFoo = _import "cFoo" public: unit -&gt; int;</programlisting>
</section>
<section id="_operating_system_specific_details">
<title>Operating-system specific details</title>
<simpara>On Windows, <literal>libarchive</literal> and <literal>archive</literal> are the same.
However, depending on this will lead to portability problems.
Windows is also especially sensitive to mixups of <emphasis><literal>public</literal></emphasis> and <emphasis><literal>external</literal></emphasis>.
If an archive is linked, make sure it&#8217;s symbols are imported as <literal>public</literal>.
If a DLL is linked, make sure it&#8217;s symbols are imported as <literal>external</literal>.
Using <literal>external</literal> instead of <literal>public</literal> will result in link errors that <literal>__imp__foo is undefined</literal>.
Using <literal>public</literal> instead of <literal>external</literal> will result in inconsistent function pointer addresses and failure to update the imported variables.</simpara>
<simpara>On Linux, <literal>libarchive</literal> and <literal>archive</literal> are different.
Libarchives are quite rare, but necessary if creating a library from an archive.
It is common for a library to provide both an archive and a dynamic library on this platform.
The linker will pick one or the other, usually preferring the dynamic library.
While a quirk of the operating system allows external import to work for both archives and libraries,
portable projects should not depend on this behaviour.
On other systems it can matter how the library is linked (static or dynamic).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="License">
<title>License</title>
<section id="_web_site">
<title>Web Site</title>
<simpara>In order to allow the maximum freedom for the future use of the
content in this web site, we require that contributions to the web
site be dedicated to the public domain.  That means that you can only
add works that are already in the public domain, or that you must hold
the copyright on the work that you agree to dedicate the work to the
public domain.</simpara>
<simpara>By contributing to this web site, you agree to dedicate your
contribution to the public domain.</simpara>
</section>
<section id="_software">
<title>Software</title>
<simpara>As of 20050812, MLton software is licensed under the BSD-style license
below.  By contributing code to the project, you agree to release the
code under this license.  Contributors can retain copyright to their
contributions by asserting copyright in their code.  Contributors may
also add to the list of copyright holders in
<literal>doc/license/MLton-LICENSE</literal>, which appears below.</simpara>
<programlisting language="text" linenumbering="unnumbered">../../LICENSE</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LineDirective">
<title>LineDirective</title>
<simpara>To aid in the debugging of code produced by program generators such
as <ulink url="http://www.eecs.harvard.edu/%7Enr/noweb/">Noweb</ulink>, MLton supports
comments with line directives of the form</simpara>
<programlisting language="sml" linenumbering="unnumbered">(*#line l.c "f"*)</programlisting>
<simpara>Here, <emphasis>l</emphasis> and <emphasis>c</emphasis> are sequences of decimal digits and <emphasis>f</emphasis> is the
source file.  The first character of a source file has the position
1.1.  A line directive causes the front end to believe that the
character following the right parenthesis is at the line and column of
the specified file.  A line directive only affects the reporting of
error messages and does not affect program semantics (except for
functions like <literal>MLton.Exn.history</literal> that report source file positions).
Syntactically invalid line directives are ignored.  To prevent
incompatibilities with SML, the file name may not contain the
character sequence <literal>*)</literal>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="LLVM">
<title>LLVM</title>
<simpara>The <ulink url="http://www.llvm.org/">LLVM Project</ulink> is a collection of modular and
reusable compiler and toolchain technologies.</simpara>
<simpara>MLton supports code generation via LLVM (<literal>-codegen llvm</literal>); see
<link linkend="LLVMCodegen">LLVMCodegen</link>.</simpara>
<section id="_also_see_9">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CMinusMinus">CMinusMinus</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LLVMCodegen">
<title>LLVMCodegen</title>
<simpara>The <link linkend="LLVMCodegen">LLVMCodegen</link> is a <link linkend="Codegen">code generator</link> that translates the
<link linkend="Machine">Machine</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> to <link linkend="LLVM">LLVM</link> assembly, which is
further optimized and compiled to native object code by the <link linkend="LLVM">LLVM</link>
toolchain.</simpara>
<simpara>It requires <link linkend="LLVM">LLVM</link> version 3.7 or greater to be installed.</simpara>
<simpara>In benchmarks performed on the <link linkend="RunningOnAMD64">AMD64</link> architecture,
code size with this generator is usually slightly smaller than either
the <link linkend="AMD64Codegen">native</link> or the <link linkend="CCodegen">C</link> code generators. Compile
time is worse than <link linkend="AMD64Codegen">native</link>, but slightly better than
<link linkend="CCodegen">C</link>. Run time is often better than either <link linkend="AMD64Codegen">native</link>
or <link linkend="CCodegen">C</link>.</simpara>
<section id="_implementation_32">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/codegen/llvm-codegen/llvm-codegen.sig"><literal>llvm-codegen.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/codegen/llvm-codegen/llvm-codegen.fun"><literal>llvm-codegen.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_32">
<title>Details and Notes</title>
<simpara>The <link linkend="LLVMCodegen">LLVMCodegen</link> was initially developed by Brian Leibig (see
<link linkend="References_Leibig13">An LLVM Back-end for MLton</link>).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LocalFlatten">
<title>LocalFlatten</title>
<simpara><link linkend="LocalFlatten">LocalFlatten</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_30">
<title>Description</title>
<simpara>This pass flattens arguments to <link linkend="SSA">SSA</link> blocks.</simpara>
<simpara>A block argument is flattened as long as it only flows to selects and
there is some tuple constructed in this function that flows to it.</simpara>
</section>
<section id="_implementation_33">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/local-flatten.fun"><literal>local-flatten.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_33">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LocalRef">
<title>LocalRef</title>
<simpara><link linkend="LocalRef">LocalRef</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_31">
<title>Description</title>
<simpara>This pass optimizes <literal>ref</literal> cells local to a <link linkend="SSA">SSA</link> function:</simpara>
<itemizedlist>
<listitem>
<simpara>
global <literal>ref</literal>-s only used in one function are moved to the function
</simpara>
</listitem>
<listitem>
<simpara>
<literal>ref</literal>-s only created, read from, and written to (i.e., don&#8217;t escape)
are converted into function local variables
</simpara>
</listitem>
</itemizedlist>
<simpara>Uses <link linkend="Multi">Multi</link> and <link linkend="Restore">Restore</link>.</simpara>
</section>
<section id="_implementation_34">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/local-ref.fun"><literal>local-ref.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_34">
<title>Details and Notes</title>
<simpara>Moving a global <literal>ref</literal> requires the <link linkend="Multi">Multi</link> analysis, because a
global <literal>ref</literal> can only be moved into a function that is executed at
most once.</simpara>
<simpara>Conversion of non-escaping <literal>ref</literal>-s is structured in three phases:</simpara>
<itemizedlist>
<listitem>
<simpara>
analysis&#8201;&#8212;&#8201;a variable <literal>r = Ref_ref x</literal> escapes if
</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>r</literal> is used in any context besides <literal>Ref_assign (r, _)</literal> or <literal>Ref_deref r</literal>
</simpara>
</listitem>
<listitem>
<simpara>
all uses <literal>r</literal> reachable from a (direct or indirect) call to <literal>Thread_copyCurrent</literal> are of the same flavor (either <literal>Ref_assign</literal> or <literal>Ref_deref</literal>); this also requires the <link linkend="Multi">Multi</link> analysis.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
transformation
</simpara>
<itemizedlist>
<listitem>
<simpara>
rewrites <literal>r = Ref_ref x</literal> to <literal>r = x</literal>
</simpara>
</listitem>
<listitem>
<simpara>
rewrites <literal>_ = Ref_assign (r, y)</literal> to <literal>r = y</literal>
</simpara>
</listitem>
<listitem>
<simpara>
rewrites <literal>z = Ref_deref r</literal> to <literal>z = r</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>Note that the resulting program violates the SSA condition.</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Restore">Restore</link>&#8201;&#8212;&#8201;restore the SSA condition.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Logo">
<title>Logo</title>
<informalfigure>
<mediaobject>
  <imageobject>
  <imagedata fileref="Logo.attachments/mlton-128.pdf" align="center"/>
  </imageobject>
  <textobject><phrase>Logo.attachments/mlton-128.pdf</phrase></textobject>
</mediaobject>
</informalfigure>
<section id="_files">
<title>Files</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton.svg"><literal>mlton.svg</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton-1024.png"><literal>mlton-1024.png</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton-512.png"><literal>mlton-512.png</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton-256.png"><literal>mlton-256.png</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton-128.png"><literal>mlton-128.png</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton-64.png"><literal>mlton-64.png</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="guide/Logo.attachments/mlton-32.png"><literal>mlton-32.png</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LoopInvariant">
<title>LoopInvariant</title>
<simpara><link linkend="LoopInvariant">LoopInvariant</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_32">
<title>Description</title>
<simpara>This pass removes loop invariant arguments to local loops.</simpara>
<screen>  loop (x, y)
    ...
  ...
    loop (x, z)
  ...</screen>
<simpara>becomes</simpara>
<screen>  loop' (x, y)
    loop (y)
  loop (y)
    ...
  ...
    loop (z)
  ...</screen>
</section>
<section id="_implementation_35">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/loop-invariant.fun"><literal>loop-invariant.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_35">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LoopUnroll">
<title>LoopUnroll</title>
<simpara><link linkend="LoopUnroll">LoopUnroll</link> is an optimization pass for the <link linkend="SSA">SSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>,
invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_33">
<title>Description</title>
<simpara>A simple loop unrolling optimization.</simpara>
</section>
<section id="_implementation_36">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/loop-unroll.fun"><literal>loop-unroll.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_36">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="LoopUnswitch">
<title>LoopUnswitch</title>
<simpara><link linkend="LoopUnswitch">LoopUnswitch</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_34">
<title>Description</title>
<simpara>A simple loop unswitching optimization.</simpara>
</section>
<section id="_implementation_37">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/loop-unswitch.fun"><literal>loop-unswitch.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_37">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Machine">
<title>Machine</title>
<simpara><link linkend="Machine">Machine</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from <link linkend="RSSA">RSSA</link>
by <link linkend="ToMachine">ToMachine</link> and used as input by the <link linkend="Codegen">Codegen</link>.</simpara>
<section id="_description_35">
<title>Description</title>
<simpara><link linkend="Machine">Machine</link> is an <link linkend="Untyped">Untyped</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>, corresponding
to a abstract register machine.</simpara>
</section>
<section id="_implementation_38">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/machine.sig"><literal>machine.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/machine.fun"><literal>machine.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_3">
<title>Type Checking</title>
<simpara>The <link linkend="Machine">Machine</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> has a primitive type checker
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/machine.sig"><literal>machine.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/machine.fun"><literal>machine.fun</literal></ulink>), which only checks
some liveness properties.</simpara>
</section>
<section id="_details_and_notes_38">
<title>Details and Notes</title>
<simpara>The runtime structure sets some constants according to the
configuration files on the target architecture and OS.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ManualPage">
<title>ManualPage</title>
<simpara>MLton is run from the command line with a collection of options
followed by a file name and a list of files to compile, assemble, and
link with.</simpara>
<screen>mlton [option ...] file.{c|mlb|o|sml} [file.{c|o|s|S} ...]</screen>
<simpara>The simplest case is to run <literal>mlton foo.sml</literal>, where <literal>foo.sml</literal> contains
a valid SML program, in which case MLton compiles the program to
produce an executable <literal>foo</literal>.  Since MLton does not support separate
compilation, the program must be the entire program you wish to
compile.  However, the program may refer to signatures and structures
defined in the <link linkend="BasisLibrary">Basis Library</link>.</simpara>
<simpara>Larger programs, spanning many files, can be compiled with the
<link linkend="MLBasis">ML Basis system</link>.  In this case, <literal>mlton foo.mlb</literal> will
compile the complete SML program described by the basis <literal>foo.mlb</literal>,
which may specify both SML files and additional bases.</simpara>
<section id="_next_steps_3">
<title>Next Steps</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CompileTimeOptions">CompileTimeOptions</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunTimeOptions">RunTimeOptions</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MatchCompilation">
<title>MatchCompilation</title>
<simpara>Match compilation is the process of translating an SML match into a
nested tree (or dag) of simple case expressions and tests.</simpara>
<simpara>MLton&#8217;s match compiler is described <link linkend="MatchCompile">here</link>.</simpara>
<section id="_match_compilation_in_other_compilers">
<title>Match compilation in other compilers</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_BaudinetMacQueen85">BaudinetMacQueen85</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Leroy90">Leroy90</link>, pages 60-69.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Sestoft96">Sestoft96</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_ScottRamsey00">ScottRamsey00</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MatchCompile">
<title>MatchCompile</title>
<simpara><link linkend="MatchCompile">MatchCompile</link> is a translation pass, agnostic in the
<link linkend="IntermediateLanguage">IntermediateLanguage</link>s between which it translates.</simpara>
<section id="_description_36">
<title>Description</title>
<simpara><link linkend="MatchCompilation">Match compilation</link> converts a case expression with
nested patterns into a case expression with flat patterns.</simpara>
</section>
<section id="_implementation_39">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/match-compile/match-compile.sig"><literal>match-compile.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/match-compile/match-compile.fun"><literal>match-compile.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_39">
<title>Details and Notes</title>
<programlisting language="sml" linenumbering="unnumbered">val matchCompile:
   {caseType: Type.t, (* type of entire expression *)
    cases: (NestedPat.t * ((Var.t -&gt; Var.t) -&gt; Exp.t)) vector,
    conTycon: Con.t -&gt; Tycon.t,
    region: Region.t,
    test: Var.t,
    testType: Type.t,
    tyconCons: Tycon.t -&gt; {con: Con.t, hasArg: bool} vector}
   -&gt; Exp.t * (unit -&gt; ((Layout.t * {isOnlyExns: bool}) vector) vector)</programlisting>
<simpara><literal>matchCompile</literal> is complicated by the desire for modularity between the
match compiler and its caller.  Its caller is responsible for building
the right hand side of a rule <literal>p =&gt; e</literal>.  On the other hand, the match
compiler is responsible for destructing the test and binding new
variables to the components.  In order to connect the new variables
created by the match compiler with the variables in the pattern <literal>p</literal>,
the match compiler passes an environment back to its caller that maps
each variable in <literal>p</literal> to the corresponding variable introduced by the
match compiler.</simpara>
<simpara>The match compiler builds a tree of n-way case expressions by working
from outside to inside and left to right in the patterns.  For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">case x of
  (_, C1 a) =&gt; e1
| (C2 b, C3 c) =&gt; e2</programlisting>
<simpara>is translated to</simpara>
<programlisting language="sml" linenumbering="unnumbered">let
   fun f1 a = e1
   fun f2 (b, c) = e2
in
  case x of
     (x1, x2) =&gt;
       (case x1 of
          C2 b' =&gt; (case x2 of
                      C1 a' =&gt; f1 a'
                    | C3 c' =&gt; f2(b',c')
                    | _ =&gt; raise Match)
        | _ =&gt; (case x2 of
                  C1 a_ =&gt; f1 a_
                | _ =&gt; raise Match))
end</programlisting>
<simpara>Here you can see the necessity of abstracting out the ride hand sides
of the cases in order to avoid code duplication.  Right hand sides are
always abstracted.  The simplifier cleans things up.  You can also see
the new (primed) variables introduced by the match compiler and how
the renaming works.  Finally, you can see how the match compiler
introduces the necessary default clauses in order to make a match
exhaustive, i.e. cover all the cases.</simpara>
<simpara>The match compiler uses <literal>numCons</literal> and <literal>tyconCons</literal> to determine
the exhaustivity of matches against constructors.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MatthewFluet">
<title>MatthewFluet</title>
<simpara>Matthew Fluet (
<ulink url="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</ulink>
,
<ulink url="http://www.cs.rit.edu/%7Emtf">http://www.cs.rit.edu/%7Emtf</ulink>
)
is an Assistant Professor at the <ulink url="http://www.rit.edu">Rochester Institute of Technology</ulink>.</simpara>
<simpara><?asciidoc-hr?></simpara>
<simpara>Current MLton projects:</simpara>
<itemizedlist>
<listitem>
<simpara>
general maintenance
</simpara>
</listitem>
<listitem>
<simpara>
release new version
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-hr?></simpara>
<simpara>Misc. and underspecified TODOs:</simpara>
<itemizedlist>
<listitem>
<simpara>
understand <link linkend="RefFlatten">RefFlatten</link> and <link linkend="DeepFlatten">DeepFlatten</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2005-April/026990.html">http://www.mlton.org/pipermail/mlton/2005-April/026990.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2007-November/030056.html">http://www.mlton.org/pipermail/mlton/2007-November/030056.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-April/030250.html">http://www.mlton.org/pipermail/mlton/2008-April/030250.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-July/030279.html">http://www.mlton.org/pipermail/mlton/2008-July/030279.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-August/030312.html">http://www.mlton.org/pipermail/mlton/2008-August/030312.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-September/030360.html">http://www.mlton.org/pipermail/mlton/2008-September/030360.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2009-June/001542.html">http://www.mlton.org/pipermail/mlton-user/2009-June/001542.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>MSG_DONTWAIT</literal> isn&#8217;t Posix
</simpara>
</listitem>
<listitem>
<simpara>
coordinate w/ Dan Spoonhower and Lukasz Ziarek and Armand Navabi on multi-threaded
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-March/030214.html">http://www.mlton.org/pipermail/mlton/2008-March/030214.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Intel Research bug: <literal>no tyconRep property</literal> (company won&#8217;t release sample code)
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2008-March/001358.html">http://www.mlton.org/pipermail/mlton-user/2008-March/001358.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
treatment of real constants
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-May/030262.html">http://www.mlton.org/pipermail/mlton/2008-May/030262.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-June/030271.html">http://www.mlton.org/pipermail/mlton/2008-June/030271.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
representation of <literal>bool</literal> and <literal>_bool</literal> in <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-May/030264.html">http://www.mlton.org/pipermail/mlton/2008-May/030264.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.icfpcontest.org">http://www.icfpcontest.org</ulink>
</simpara>
<itemizedlist>
<listitem>
<simpara>
John Reppy claims that "It looks like the card-marking overhead that one incurs when using generational collection swamps the benefits of generational collection."
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
page to disk policy / single heap
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-June/030278.html">http://www.mlton.org/pipermail/mlton/2008-June/030278.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-August/030318.html">http://www.mlton.org/pipermail/mlton/2008-August/030318.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>MLton.GC.pack</literal> doesn&#8217;t keep a small heap if a garbage collection occurs before <literal>MLton.GC.unpack</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
It might be preferable for <literal>MLton.GC.pack</literal> to be implemented as a (new) <literal>MLton.GC.Ratios.setLive 1.1</literal> followed by <literal>MLton.GC.collect ()</literal> and for <literal>MLton.GC.unpack</literal> to be implemented as <literal>MLton.GC.Ratios.setLive 8.0</literal> followed by <literal>MLton.GC.collect ()</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
The <literal>static struct GC_objectType objectTypes[] =</literal> array includes many duplicates.  Objects of distinct source type, but equivalent representations (in terms of size, bytes non-pointers, number pointers) can share the objectType index.
</simpara>
</listitem>
<listitem>
<simpara>
PolySpace bug: <link linkend="Redundant">Redundant</link> optimization (company won&#8217;t release sample code)
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-September/030355.html">http://www.mlton.org/pipermail/mlton/2008-September/030355.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
treatment of exception raised during <link linkend="BasisLibrary">BasisLibrary</link> evaluation
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-December/030501.html">http://www.mlton.org/pipermail/mlton/2008-December/030501.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-December/030502.html">http://www.mlton.org/pipermail/mlton/2008-December/030502.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-December/030503.html">http://www.mlton.org/pipermail/mlton/2008-December/030503.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Use <literal>memcpy</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2009-January/001506.html">http://www.mlton.org/pipermail/mlton-user/2009-January/001506.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2009-January/030506.html">http://www.mlton.org/pipermail/mlton/2009-January/030506.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Implement more 64bit primops in x86 codegen
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2009-January/030507.html">http://www.mlton.org/pipermail/mlton/2009-January/030507.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Enrich path-map file syntax:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2008-September/030348.html">http://www.mlton.org/pipermail/mlton/2008-September/030348.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2009-January/001507.html">http://www.mlton.org/pipermail/mlton-user/2009-January/001507.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
PolySpace bug: crash during Cheney-copy collection
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2009-February/030513.html">http://www.mlton.org/pipermail/mlton/2009-February/030513.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
eliminate <literal>-build-constants</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
all <literal>_const</literal>-s are known by <literal>runtime/gen/basis-ffi.def</literal>
</simpara>
</listitem>
<listitem>
<simpara>
generate <literal>gen-constants.c</literal> from <literal>basis-ffi.def</literal>
</simpara>
</listitem>
<listitem>
<simpara>
generate <literal>constants</literal> from <literal>gen-constants.c</literal> and <literal>libmlton.a</literal>
</simpara>
</listitem>
<listitem>
<simpara>
similar to <literal>gen-sizes.c</literal> and <literal>sizes</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
eliminate "Windows hacks" for Cygwin from <literal>Path</literal> module
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2009-July/030606.html">http://www.mlton.org/pipermail/mlton/2009-July/030606.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
extend IL type checkers to check for empty property lists
</simpara>
</listitem>
<listitem>
<simpara>
make (unsafe) <literal>IntInf</literal> conversions into primitives
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2009-July/030622.html">http://www.mlton.org/pipermail/mlton/2009-July/030622.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="mGTK">
<title>mGTK</title>
<simpara><ulink url="http://mgtk.sourceforge.net/">mGTK</ulink> is a wrapper for
<ulink url="http://www.gtk.org/">GTK+</ulink>, a GUI toolkit.</simpara>
<simpara>We recommend using mGTK 0.93, which is not listed on their home page,
but is available at the
<ulink url="http://sourceforge.net/project/showfiles.php?group_id=23226&amp;package_id=16523">file
release page</ulink>.  To test it, after unpacking, do <literal>cd examples; make
mlton</literal>, after which you should be able to run the many examples
(<literal>signup-mlton</literal>, <literal>listview-mlton</literal>, &#8230;).</simpara>
<section id="_also_see_10">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Glade">Glade</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MichaelNorrish">
<title>MichaelNorrish</title>
<simpara>I am a researcher at <ulink url="http://nicta.com.au">NICTA</ulink>, with a web-page <ulink url="http://web.rsise.anu.edu.au/%7Emichaeln/">here</ulink>.</simpara>
<simpara>I&#8217;m interested in MLton because of the chance that it might be a good vehicle for future implementations of the <ulink url="http://hol.sf.net">HOL</ulink> theorem-proving system. It&#8217;s beginning to look as if one route forward will be to embed an SML interpreter into a MLton-compiled executable.  I don&#8217;t know if an extensible interpreter of the kind we&#8217;re looking for already exists.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MikeThomas">
<title>MikeThomas</title>
<simpara>Here is a picture at home in Brisbane, Queensland, Australia, taken in January 2004.</simpara>
<informalfigure>
<mediaobject>
  <imageobject>
  <imagedata fileref="MikeThomas.attachments/picture.jpg" align="center"/>
  </imageobject>
  <textobject><phrase>MikeThomas.attachments/picture.jpg</phrase></textobject>
</mediaobject>
</informalfigure>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ML">
<title>ML</title>
<simpara>ML stands for <emphasis>meta language</emphasis>.  ML was originally designed in the
1970s as a programming language to assist theorem proving in the logic
LCF.  In the 1980s, ML split into two variants,
<link linkend="StandardML">Standard ML</link> and <link linkend="OCaml">OCaml</link>, both of which are still used
today.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLAntlr">
<title>MLAntlr</title>
<simpara><ulink url="http://smlnj-gforge.cs.uchicago.edu/projects/ml-lpt/">MLAntlr</ulink> is a
parser generator for <link linkend="StandardML">Standard ML</link>.</simpara>
<section id="_also_see_11">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLULex">MLULex</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLLPTLibrary">MLLPTLibrary</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLBasis">
<title>MLBasis</title>
<simpara>The ML Basis system extends <link linkend="StandardML">Standard ML</link> to support
programming-in-the-very-large, namespace management at the module
level, separate delivery of library sources, and more.  While Standard
ML modules are a sophisticated language for programming-in-the-large,
it is difficult, if not impossible, to accomplish a number of routine
namespace management operations when a program draws upon multiple
libraries provided by different vendors.</simpara>
<simpara>The ML Basis system is a simple, yet powerful, approach that builds
upon the programmer&#8217;s intuitive notion (and
<link linkend="DefinitionOfStandardML">The Definition of Standard ML (Revised)</link>'s
formal notion) of the top-level environment (a <emphasis>basis</emphasis>).  The system
is designed as a natural extension of <link linkend="StandardML">Standard ML</link>; the
formal specification of the ML Basis system
(<ulink url="guide/MLBasis.attachments/mlb-formal.pdf"><literal>mlb-formal.pdf</literal></ulink>) is given in the style
of the Definition.</simpara>
<simpara>Here are some of the key features of the ML Basis system:</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
Explicit file order: The order of files (and, hence, the order of
evaluation) in the program is explicit.  The ML Basis system&#8217;s
semantics are structured in such a way that for any well-formed
project, there will be exactly one possible interpretation of the
project&#8217;s syntax, static semantics, and dynamic semantics.
</simpara>
</listitem>
<listitem>
<simpara>
Implicit dependencies: A source file (corresponding to an SML
top-level declaration) is elaborated in the environment described by
preceding declarations.  It is not necessary to explicitly list the
dependencies of a file.
</simpara>
</listitem>
<listitem>
<simpara>
Scoping and renaming: The ML Basis system provides mechanisms for
limiting the scope of (i.e, hiding) and renaming identifiers.
</simpara>
</listitem>
<listitem>
<simpara>
No naming convention for finding the file that defines a module.
To import a module, its defining file must appear in some ML Basis
file.
</simpara>
</listitem>
</orderedlist>
<section id="_next_steps_4">
<title>Next steps</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLBasisSyntaxAndSemantics">MLBasisSyntaxAndSemantics</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasisExamples">MLBasisExamples</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasisPathMap">MLBasisPathMap</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasisAnnotations">MLBasisAnnotations</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasisAvailableLibraries">MLBasisAvailableLibraries</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLBasisAnnotationExamples">
<title>MLBasisAnnotationExamples</title>
<simpara>Here are some example uses of <link linkend="MLBasisAnnotations">MLBasisAnnotations</link>.</simpara>
<section id="_eliminate_spurious_warnings_in_automatically_generated_code">
<title>Eliminate spurious warnings in automatically generated code</title>
<simpara>Programs that automatically generate source code can often produce
nonexhaustive patterns, relying on invariants of the generated code to
ensure that the pattern matchings never fail.  A programmer may wish
to elide the nonexhaustive warnings from this code, in order that
legitimate warnings are not missed in a flurry of false positives.  To
do so, the programmer simply annotates the generated code with the
<literal>nonexhaustiveBind ignore</literal> and <literal>nonexhaustiveMatch ignore</literal>
annotations:</simpara>
<screen>local
  $(GEN_ROOT)/gen-lib.mlb

  ann
    "nonexhaustiveBind ignore"
    "nonexhaustiveMatch ignore"
  in
    foo.gen.sml
  end
in
  signature FOO
  structure Foo
end</screen>
</section>
<section id="_deliver_a_library">
<title>Deliver a library</title>
<simpara>Standard ML libraries can be delivered via <literal>.mlb</literal> files.  Authors of
such libraries should strive to be mindful of the ways in which
programmers may choose to compile their programs.  For example,
although the defaults for <literal>sequenceNonUnit</literal> and <literal>warnUnused</literal> are
<literal>ignore</literal> and <literal>false</literal>, periodically compiling with these annotations
defaulted to <literal>warn</literal> and <literal>true</literal> can help uncover likely bugs.  However,
a programmer is unlikely to be interested in unused modules from an
imported library, and the behavior of <literal>sequenceNonUnit error</literal> may be
incompatible with some libraries.  Hence, a library author may choose
to deliver a library as follows:</simpara>
<screen>ann
  "nonexhaustiveBind warn" "nonexhaustiveMatch warn"
  "redundantBind warn" "redundantMatch warn"
  "sequenceNonUnit warn"
  "warnUnused true" "forceUsed"
in
  local
    file1.sml
    ...
    filen.sml
  in
    functor F1
    ...
    signature S1
    ...
    structure SN
    ...
  end
end</screen>
<simpara>The annotations <literal>nonexhaustiveBind warn</literal>, <literal>redundantBind warn</literal>,
<literal>nonexhaustiveMatch warn</literal>, <literal>redundantMatch warn</literal>, and <literal>sequenceNonUnit
warn</literal> have the obvious effect on elaboration.  The annotations
<literal>warnUnused true</literal> and <literal>forceUsed</literal> work in conjunction&#8201;&#8212;&#8201;warning on
any identifiers that do not contribute to the exported modules, and
preventing warnings on exported modules that are not used in the
remainder of the program.  Many of the
<link linkend="MLBasisAvailableLibraries">available libraries</link> are delivered with
these annotations.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLBasisAnnotations">
<title>MLBasisAnnotations</title>
<simpara><link linkend="MLBasis">ML Basis</link> annotations control options that affect the
elaboration of SML source files.  Conceptually, a basis file is
elaborated in a default annotation environment (just as it is
elaborated in an empty basis).  The declaration
<literal>ann</literal>&#160;<literal>"</literal><emphasis>ann</emphasis><literal>"</literal>&#160;<literal>in</literal>&#160;<emphasis>basdec</emphasis>&#160;<literal>end</literal>
merges the annotation <emphasis>ann</emphasis> with the "current" annotation environment
for the elaboration of <emphasis>basdec</emphasis>.  To allow for future expansion,
<literal>"</literal><emphasis>ann</emphasis><literal>"</literal> is lexed as a single SML string constant.  To
conveniently specify multiple annotations, the following derived form
is provided:</simpara>
<sidebar>
<simpara><literal>ann</literal> <literal>"</literal><emphasis>ann</emphasis><literal>"</literal> (<literal>"</literal><emphasis>ann</emphasis><literal>"</literal> )<superscript>+</superscript> <literal>in</literal> <emphasis>basdec</emphasis> <literal>end</literal>
&#8658;
<literal>ann</literal> <literal>"</literal><emphasis>ann</emphasis><literal>"</literal> <literal>in</literal> <literal>ann</literal> (<literal>"</literal><emphasis>ann</emphasis><literal>"</literal>)<superscript>+</superscript> <literal>in</literal> <emphasis>basdec</emphasis> <literal>end</literal> <literal>end</literal></simpara>
</sidebar>
<simpara>Here are the available annotations.  In the explanation below, for
annotations that take an argument, the first value listed is the
default.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>allowFFI {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow <literal>_address</literal>, <literal>_export</literal>, <literal>_import</literal>, and <literal>_symbol</literal>
expressions to appear in source files.  See
<link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowSuccessorML {false|true}</literal>
</simpara>
<simpara>Allow or disallow all of the <link linkend="SuccessorML">SuccessorML</link> features.  This is a
proxy for all of the following annotations.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>allowDoDecls {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow a <literal>do <emphasis>exp</emphasis></literal> declaration form.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowExtendedConsts {false|true}</literal>
</simpara>
<simpara>Allow or disallow all of the extended constants features.  This is a
proxy for all of the following annotations.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>allowExtendedNumConsts {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow extended numeric constants.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowExtendedTextConsts {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow extended text constants.</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>allowLineComments {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow line comments beginning with the token <literal>(*)</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowOptBar {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow a bar to appear before the first match rule of a
<literal>case</literal>, <literal>fn</literal>, or <literal>handle</literal> expression, allow a bar to appear before the
first function-value binding of a <literal>fun</literal> declaration, and allow a bar
to appear before the first constructor binding or description of a
<literal>datatype</literal> declaration or specification.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowOptSemicolon {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allows a semicolon to appear after the last expression in a
sequence expression or <literal>let</literal> body.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowOrPats {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allows disjunctive (a.k.a., "or") patterns of the form
<literal><emphasis>pat</emphasis> | <emphasis>pat</emphasis></literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowRecordPunExps {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allows record punning expressions.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowSigWithtype {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allows <literal>withtype</literal> to modify a <literal>datatype</literal> specification in a
signature.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowVectorExpsAndPats {false|true}</literal>
</simpara>
<simpara>Allow or disallow vector expressions and vector patterns.  This is a
proxy for all of the following annotations.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>allowVectorExps {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow vector expressions.</simpara>
</listitem>
<listitem>
<simpara>
<literal>allowVectorPats {false|true}</literal>
</simpara>
<simpara>If <literal>true</literal>, allow vector patterns.</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>forceUsed</literal>
</simpara>
<simpara>Force all identifiers in the basis denoted by the body of the <literal>ann</literal> to
be considered used; use in conjunction with <literal>warnUnused true</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>nonexhaustiveBind {warn|error|ignore}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report nonexhaustive patterns in <literal>val</literal>
declarations (i.e., pattern-match failures that raise the <literal>Bind</literal>
exception).  An error will abort a compile, while a warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>nonexhaustiveExnBind {default|ignore}</literal>
</simpara>
<simpara>If <literal>ignore</literal>, suppress errors and warnings about nonexhaustive matches
in <literal>val</literal> declarations that arise solely from unmatched exceptions.
If <literal>default</literal>, follow the behavior of <literal>nonexhaustiveBind</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>nonexhaustiveExnMatch {default|ignore}</literal>
</simpara>
<simpara>If <literal>ignore</literal>, suppress errors and warnings about nonexhaustive matches
in <literal>fn</literal> expressions, <literal>case</literal> expressions, and <literal>fun</literal> declarations that
arise solely from unmatched exceptions.  If <literal>default</literal>, follow the
behavior of <literal>nonexhaustiveMatch</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>nonexhaustiveExnRaise {ignore|default}</literal>
</simpara>
<simpara>If <literal>ignore</literal>, suppress errors and warnings about nonexhaustive matches
in <literal>handle</literal> expressions that arise solely from unmatched exceptions.
If <literal>default</literal>, follow the behavior of <literal>nonexhaustiveRaise</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>nonexhaustiveMatch {warn|error|ignore}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report nonexhaustive patterns in <literal>fn</literal>
expressions, <literal>case</literal> expressions, and <literal>fun</literal> declarations (i.e.,
pattern-match failures that raise the <literal>Match</literal> exception).  An error
will abort a compile, while a warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>nonexhaustiveRaise {ignore|warn|error}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report nonexhaustive patterns in <literal>handle</literal>
expressions (i.e., pattern-match failures that implicitly (re)raise
the unmatched exception).  An error will abort a compile, while a
warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>redundantBind {warn|error|ignore}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report redundant patterns in <literal>val</literal> declarations.
An error will abort a compile, while a warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>redundantMatch {warn|error|ignore}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report redundant patterns in <literal>fn</literal> expressions,
<literal>case</literal> expressions, and <literal>fun</literal> declarations.  An error will abort a
compile, while a warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>redundantRaise {warn|error|ignore}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report redundant patterns in <literal>handle</literal>
expressions.  An error will abort a compile, while a warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>resolveScope {strdec|dec|topdec|program}</literal>
</simpara>
<simpara>Used to control the scope at which overload constraints are resolved
to default types (if not otherwise resolved by type inference) and the
scope at which unresolved flexible record constraints are reported.</simpara>
<simpara>The syntactic-class argument means to perform resolution checks at the
smallest enclosing syntactic form of the given class.  The default
behavior is to resolve at the smallest enclosing <emphasis>strdec</emphasis> (which is
equivalent to the largest enclosing <emphasis>dec</emphasis>).  Other useful behaviors
are to resolve at the smallest enclosing <emphasis>topdec</emphasis> (which is equivalent
to the largest enclosing <emphasis>strdec</emphasis>) and at the smallest enclosing
<emphasis>program</emphasis> (which corresponds to a single <literal>.sml</literal> file and does not
correspond to the whole <literal>.mlb</literal> program).</simpara>
</listitem>
<listitem>
<simpara>
<literal>sequenceNonUnit {ignore|error|warn}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report when <literal>e1</literal> is not of type <literal>unit</literal> in the
sequence expression <literal>(e1; e2)</literal>.  This can be helpful in detecting
curried applications that are mistakenly not fully applied.  To
silence spurious messages, you can use <literal>ignore e1</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>valrecConstr {warn|error|ignore}</literal>
</simpara>
<simpara>If <literal>error</literal> or <literal>warn</literal>, report when a <literal>val rec</literal> (or <literal>fun</literal>) declaration
redefines an identifier that previously had constructor status.  An
error will abort a compile, while a warning will not.</simpara>
</listitem>
<listitem>
<simpara>
<literal>warnUnused {false|true}</literal>
</simpara>
<simpara>Report unused identifiers.</simpara>
</listitem>
</itemizedlist>
<section id="_next_steps_5">
<title>Next Steps</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLBasisAnnotationExamples">MLBasisAnnotationExamples</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="WarnUnusedAnomalies">WarnUnusedAnomalies</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLBasisAvailableLibraries">
<title>MLBasisAvailableLibraries</title>
<simpara>MLton comes with the following <link linkend="MLBasis">ML Basis</link> files available.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/basis.mlb</literal>
</simpara>
<simpara>The <link linkend="BasisLibrary">Basis Library</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/basis-1997.mlb</literal>
</simpara>
<simpara>The (deprecated) 1997 version of the <link linkend="BasisLibrary">Basis Library</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/mlton.mlb</literal>
</simpara>
<simpara>The <link linkend="MLtonStructure">MLton</link> structure and signatures.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/c-types.mlb</literal>
</simpara>
<simpara>Various structure aliases useful as <link linkend="ForeignFunctionInterfaceTypes">ForeignFunctionInterfaceTypes</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/unsafe.mlb</literal>
</simpara>
<simpara>The <link linkend="UnsafeStructure">Unsafe</link> structure and signature.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/sml-nj.mlb</literal>
</simpara>
<simpara>The <link linkend="SMLofNJStructure">SMLofNJ</link> structure and signature.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/mlyacc-lib/mlyacc-lib.mlb</literal>
</simpara>
<simpara>Modules used by parsers built with <link linkend="MLYacc">MLYacc</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/cml/cml.mlb</literal>
</simpara>
<simpara><link linkend="ConcurrentML">ConcurrentML</link>, a library for message-passing concurrency.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/mlnlffi-lib/mlnlffi-lib.mlb</literal>
</simpara>
<simpara><link linkend="MLNLFFI">ML-NLFFI</link>, a library for foreign function interfaces.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/mlrisc-lib/...</literal>
</simpara>
<simpara><link linkend="MLRISCLibrary">MLRISCLibrary</link>, a library for retargetable and optimizing compiler back ends.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/smlnj-lib/...</literal>
</simpara>
<simpara><link linkend="SMLNJLibrary">SMLNJLibrary</link>, a collection of libraries distributed with SML/NJ.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/ckit-lib/ckit-lib.mlb</literal>
</simpara>
<simpara><link linkend="CKitLibrary">CKitLibrary</link>, a library for C source code.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/mllpt-lib/mllpt-lib.mlb</literal>
</simpara>
<simpara><link linkend="MLLPTLibrary">MLLPTLibrary</link>, a support library for the <link linkend="MLULex">MLULex</link> scanner generator and the <link linkend="MLAntlr">MLAntlr</link> parser generator.</simpara>
</listitem>
</itemizedlist>
<section id="_basis_fragments">
<title>Basis fragments</title>
<simpara>There are a number of specialized ML Basis files for importing
fragments of the <link linkend="BasisLibrary">Basis Library</link> that can not be
expressed within SML.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/pervasive-types.mlb</literal>
</simpara>
<simpara>The top-level types and constructors of the Basis Library.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/pervasive-exns.mlb</literal>
</simpara>
<simpara>The top-level exception constructors of the Basis Library.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/pervasive-vals.mlb</literal>
</simpara>
<simpara>The top-level values of the Basis Library, without infix status.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/overloads.mlb</literal>
</simpara>
<simpara>The top-level overloaded values of the Basis Library, without infix status.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/equal.mlb</literal>
</simpara>
<simpara>The polymorphic equality <literal>=</literal> and inequality <literal>&lt;&gt;</literal> values, without infix status.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/infixes.mlb</literal>
</simpara>
<simpara>The infix declarations of the Basis Library.</simpara>
</listitem>
<listitem>
<simpara>
<literal>$(SML_LIB)/basis/pervasive.mlb</literal>
</simpara>
<simpara>The entire top-level value and type environment of the Basis Library, with infix status.  This is the same as importing the above six MLB files.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLBasisExamples">
<title>MLBasisExamples</title>
<simpara>Here are some example uses of <link linkend="MLBasis">ML Basis</link> files.</simpara>
<section id="_complete_program">
<title>Complete program</title>
<simpara>Suppose your complete program consists of the files <literal>file1.sml</literal>, &#8230;,
<literal>filen.sml</literal>, which depend upon libraries <literal>lib1.mlb</literal>, &#8230;, <literal>libm.mlb</literal>.</simpara>
<screen>(* import libraries *)
lib1.mlb
...
libm.mlb

(* program files *)
file1.sml
...
filen.sml</screen>
<simpara>The bases denoted by <literal>lib1.mlb</literal>, &#8230;, <literal>libm.mlb</literal> are merged (bindings
of names in later bases take precedence over bindings of the same name
in earlier bases), producing a basis in which <literal>file1.sml</literal>, &#8230;,
<literal>filen.sml</literal> are elaborated, adding additional bindings to the basis.</simpara>
</section>
<section id="_export_filter">
<title>Export filter</title>
<simpara>Suppose you only want to export certain structures, signatures, and
functors from a collection of files.</simpara>
<screen>local
  file1.sml
  ...
  filen.sml
in
  (* export filter here *)
  functor F
  structure S
end</screen>
<simpara>While <literal>file1.sml</literal>, &#8230;, <literal>filen.sml</literal> may declare top-level identifiers
in addition to <literal>F</literal> and <literal>S</literal>, such names are not accessible to programs
and libraries that import this <literal>.mlb</literal>.</simpara>
</section>
<section id="_export_filter_with_renaming">
<title>Export filter with renaming</title>
<simpara>Suppose you want an export filter, but want to rename one of the
modules.</simpara>
<screen>local
  file1.sml
  ...
  filen.sml
in
  (* export filter, with renaming, here *)
  functor F
  structure S' = S
end</screen>
<simpara>Note that <literal>functor F</literal> is an abbreviation for <literal>functor F = F</literal>, which
simply exports an identifier under the same name.</simpara>
</section>
<section id="_import_filter">
<title>Import filter</title>
<simpara>Suppose you only want to import a functor <literal>F</literal> from one library and a
structure <literal>S</literal> from another library.</simpara>
<screen>local
  lib1.mlb
in
  (* import filter here *)
  functor F
end
local
  lib2.mlb
in
  (* import filter here *)
  structure S
end
file1.sml
...
filen.sml</screen>
</section>
<section id="_import_filter_with_renaming">
<title>Import filter with renaming</title>
<simpara>Suppose you want to import a structure <literal>S</literal> from one library and
another structure <literal>S</literal> from another library.</simpara>
<screen>local
  lib1.mlb
in
  (* import filter, with renaming, here *)
  structure S1 = S
end
local
  lib2.mlb
in
  (* import filter, with renaming, here *)
  structure S2 = S
end
file1.sml
...
filen.sml</screen>
</section>
<section id="_full_basis">
<title>Full Basis</title>
<simpara>Since the Modules level of SML is the natural means for organizing
program and library components, MLB files provide convenient syntax
for renaming Modules level identifiers (in fact, renaming of functor
identifiers provides a mechanism that is not available in SML).
However, please note that <literal>.mlb</literal> files elaborate to full bases
including top-level types and values (including infix status), in
addition to structures, signatures, and functors.  For example,
suppose you wished to extend the <link linkend="BasisLibrary">Basis Library</link> with an
<literal>('a, 'b) either</literal> datatype corresponding to a disjoint sum; the type
and some operations should be available at the top-level;
additionally, a signature and structure provide the complete
interface.</simpara>
<simpara>We could use the following files.</simpara>
<simpara><literal>either-sigs.sml</literal></simpara>
<programlisting language="sml" linenumbering="unnumbered">signature EITHER_GLOBAL =
  sig
    datatype ('a, 'b) either = Left of 'a | Right of 'b
    val &amp;  : ('a -&gt; 'c) * ('b -&gt; 'c) -&gt; ('a, 'b) either -&gt; 'c
    val &amp;&amp; : ('a -&gt; 'c) * ('b -&gt; 'd) -&gt; ('a, 'b) either -&gt; ('c, 'd) either
  end

signature EITHER =
  sig
    include EITHER_GLOBAL
    val isLeft  : ('a, 'b) either -&gt; bool
    val isRight : ('a, 'b) either -&gt; bool
    ...
  end</programlisting>
<simpara><literal>either-strs.sml</literal></simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Either : EITHER =
  struct
    datatype ('a, 'b) either = Left of 'a | Right of 'b
    fun f &amp; g = fn x =&gt;
      case x of Left z =&gt; f z | Right z =&gt; g z
    fun f &amp;&amp; g = (Left o f) &amp; (Right o g)
    fun isLeft x = ((fn _ =&gt; true) &amp; (fn _ =&gt; false)) x
    fun isRight x = (not o isLeft) x
    ...
  end
structure EitherGlobal : EITHER_GLOBAL = Either</programlisting>
<simpara><literal>either-infixes.sml</literal></simpara>
<programlisting language="sml" linenumbering="unnumbered">infixr 3 &amp; &amp;&amp;</programlisting>
<simpara><literal>either-open.sml</literal></simpara>
<programlisting language="sml" linenumbering="unnumbered">open EitherGlobal</programlisting>
<simpara><literal>either.mlb</literal></simpara>
<screen>either-infixes.sml
local
  (* import Basis Library *)
  $(SML_LIB)/basis/basis.mlb
  either-sigs.sml
  either-strs.sml
in
  signature EITHER
  structure Either
  either-open.sml
end</screen>
<simpara>A client that imports <literal>either.mlb</literal> will have access to neither
<literal>EITHER_GLOBAL</literal> nor <literal>EitherGlobal</literal>, but will have access to the type
<literal>either</literal> and the values <literal>&amp;</literal> and <literal>&amp;&amp;</literal> (with infix status) in the
top-level environment.  Note that <literal>either-infixes.sml</literal> is outside the
scope of the local, because we want the infixes available in the
implementation of the library and to clients of the library.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLBasisPathMap">
<title>MLBasisPathMap</title>
<simpara>An <link linkend="MLBasis">ML Basis</link> <emphasis>path map</emphasis> describes a map from ML Basis path
variables (of the form <literal>$(VAR)</literal>) to file system paths.  ML Basis path
variables provide a flexible way to refer to libraries while allowing
them to be moved without changing their clients.</simpara>
<simpara>The format of an <literal>mlb-path-map</literal> file is a sequence of lines; each line
consists of two, white-space delimited tokens.  The first token is a
path variable <literal>VAR</literal> and the second token is the path to which the
variable is mapped.  The path may include path variables, which are
recursively expanded.</simpara>
<simpara>The mapping from path variables to paths is initialized by the compiler.
Additional path maps can be specified with <literal>-mlb-path-map</literal> and
individual path variable mappings can be specified with
<literal>-mlb-path-var</literal> (see <link linkend="CompileTimeOptions">CompileTimeOptions</link>).  Configuration files are
processed from first to last and from top to bottom, later mappings
take precedence over earlier mappings.</simpara>
<simpara>The compiler and system-wide configuration file makes the following
path variables available.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<thead>
<row>
<entry align="center" valign="top">MLB path variable</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="center" valign="top"><simpara><literal>SML_LIB</literal></simpara></entry>
<entry align="left" valign="top"><simpara>path to system-wide libraries, usually <literal>/usr/lib/mlton/sml</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>TARGET_ARCH</literal></simpara></entry>
<entry align="left" valign="top"><simpara>string representation of target architecture</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>TARGET_OS</literal></simpara></entry>
<entry align="left" valign="top"><simpara>string representation of target operating system</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>DEFAULT_INT</literal></simpara></entry>
<entry align="left" valign="top"><simpara>binding for default int, usually <literal>int32</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>DEFAULT_WORD</literal></simpara></entry>
<entry align="left" valign="top"><simpara>binding for default word, usually <literal>word32</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>DEFAULT_REAL</literal></simpara></entry>
<entry align="left" valign="top"><simpara>binding for default real, usually <literal>real64</literal></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLBasisSyntaxAndSemantics">
<title>MLBasisSyntaxAndSemantics</title>
<simpara>An <link linkend="MLBasis">ML Basis</link> (MLB) file should have the <literal>.mlb</literal> suffix and
should contain a basis declaration.</simpara>
<section id="_syntax">
<title>Syntax</title>
<simpara>A basis declaration (<emphasis>basdec</emphasis>) must be one of the following forms.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>basis</literal> <emphasis>basid</emphasis> <literal>=</literal> <emphasis>basexp</emphasis> (<literal>and</literal> <emphasis>basid</emphasis> <literal>=</literal> <emphasis>basexp</emphasis>)<superscript>*</superscript>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>open</literal> <emphasis>basid<subscript>1</subscript></emphasis> &#8230; <emphasis>basid<subscript>n</subscript></emphasis>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>local</literal> <emphasis>basdec</emphasis> <literal>in</literal> <emphasis>basdec</emphasis> <literal>end</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>basdec</emphasis> [<literal>;</literal>] <emphasis>basdec</emphasis>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>structure</literal> <emphasis>strid</emphasis> [<literal>=</literal> <emphasis>strid</emphasis>]  (<literal>and</literal> <emphasis>strid</emphasis>[<literal>=</literal> <emphasis>strid</emphasis>])<superscript>*</superscript>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>signature</literal> <emphasis>sigid</emphasis> [<literal>=</literal> <emphasis>sigid</emphasis>]  (<literal>and</literal> <emphasis>sigid</emphasis> [<literal>=</literal> <emphasis>sigid</emphasis>])<superscript>*</superscript>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>functor</literal> <emphasis>funid</emphasis> [<literal>=</literal> <emphasis>funid</emphasis>]  (<literal>and</literal> <emphasis>funid</emphasis> [<literal>=</literal> <emphasis>funid</emphasis>])<superscript>*</superscript>
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>path</emphasis><literal>.sml</literal>, <emphasis>path</emphasis><literal>.sig</literal>, or <emphasis>path</emphasis><literal>.fun</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>path</emphasis><literal>.mlb</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>ann</literal> <literal>"</literal><emphasis>ann</emphasis><literal>"</literal> <literal>in</literal> <emphasis>basdec</emphasis> <literal>end</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>A basis expression (<emphasis>basexp</emphasis>) must be of one the following forms.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>bas</literal> <emphasis>basdec</emphasis> <literal>end</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>basid</emphasis>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>let</literal> <emphasis>basdec</emphasis> <literal>in</literal> <emphasis>basexp</emphasis> <literal>end</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>Nested SML-style comments (enclosed with <literal>(*</literal> and <literal>*)</literal>) are ignored
(but <link linkend="LineDirective">LineDirective</link>s are recognized).</simpara>
<simpara>Paths can be relative or absolute.  Relative paths are relative to the
directory containing the MLB file.  Paths may include path variables
and are expanded according to a <link linkend="MLBasisPathMap">path map</link>.  Unquoted
paths may include alpha-numeric characters and the symbols "<literal>-</literal>" and
"<literal>_</literal>", along with the arc separator "<literal>/</literal>" and extension separator
"<literal>.</literal>".  More complicated paths, including paths with spaces, may be
included by quoting the path with <literal>"</literal>.  A quoted path is lexed as an
SML string constant.</simpara>
<simpara><link linkend="MLBasisAnnotations">Annotations</link> allow a library author to
control options that affect the elaboration of SML source files.</simpara>
</section>
<section id="_semantics">
<title>Semantics</title>
<simpara>There is a <ulink url="guide/MLBasis.attachments/mlb-formal.pdf">formal semantics</ulink> for
ML Basis files in the style of the
<link linkend="DefinitionOfStandardML">Definition</link>.  Here, we give an informal
explanation.</simpara>
<simpara>An SML structure is a collection of types, values, and other
structures.  Similarly, a basis is a collection, but of more kinds of
objects: types, values, structures, fixities, signatures, functors,
and other bases.</simpara>
<simpara>A basis declaration denotes a basis.  A structure, signature, or
functor declaration denotes a basis containing the corresponding
module.  Sequencing of basis declarations merges bases, with later
definitions taking precedence over earlier ones, just like sequencing
of SML declarations.  Local declarations provide name hiding, just
like SML local declarations.  A reference to an SML source file causes
the file to be elaborated in the basis extant at the point of
reference.  A reference to an MLB file causes the basis denoted by
that MLB file to be imported&#8201;&#8212;&#8201;the basis at the point of reference
does <emphasis>not</emphasis> affect the imported basis.</simpara>
<simpara>Basis expressions and basis identifiers allow binding a basis to a
name.</simpara>
<simpara>An MLB file is elaborated starting in an empty basis.  Each MLB file
is elaborated and evaluated only once, with the result being cached.
Subsequent references use the cached value.  Thus, any observable
effects due to evaluation are not duplicated if the MLB file is
referred to multiple times.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLj">
<title>MLj</title>
<simpara><ulink url="http://www.dcs.ed.ac.uk/home/mlj/">MLj</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link> that targets
Java bytecode.  It is no longer maintained.  It has morphed into
<link linkend="SMLNET">SML.NET</link>.</simpara>
<section id="_also_see_12">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_BentonEtAl98">BentonEtAl98</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_BentonKennedy99">BentonKennedy99</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLKit">
<title>MLKit</title>
<simpara>The <ulink url="http://sourceforge.net/apps/mediawiki/mlkit">ML Kit</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link>.</simpara>
<simpara>MLKit supports:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="DefinitionOfStandardML">SML&#8217;97</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
including most of the latest <link linkend="BasisLibrary">Basis Library</link>
<ulink url="http://www.standardml.org/Basis">specification</ulink>,
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasis">ML Basis</link> files
</simpara>
<itemizedlist>
<listitem>
<simpara>
and separate compilation,
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="Regions">Region-Based Memory Management</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
and <link linkend="GarbageCollection">garbage collection</link>,
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Multiple backends, including
</simpara>
<itemizedlist>
<listitem>
<simpara>
native x86,
</simpara>
</listitem>
<listitem>
<simpara>
bytecode, and
</simpara>
</listitem>
<listitem>
<simpara>
JavaScript (see <ulink url="http://www.itu.dk/people/mael/smltojs/">SMLtoJs</ulink>).
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>At the time of writing, MLKit does not support:</simpara>
<itemizedlist>
<listitem>
<simpara>
concurrent programming / threads,
</simpara>
</listitem>
<listitem>
<simpara>
calling from C to SML.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLLex">
<title>MLLex</title>
<simpara><link linkend="MLLex">MLLex</link> is a lexical analyzer generator for <link linkend="StandardML">Standard ML</link>
modeled after the Lex lexical analyzer generator.</simpara>
<simpara>A version of MLLex, ported from the <link linkend="SMLNJ">SML/NJ</link> sources, is
distributed with MLton.</simpara>
<section id="_description_37">
<title>Description</title>
<simpara>MLLex takes as input the lex language as defined in the ML-Lex manual,
and outputs a lexical analyzer in SML.</simpara>
</section>
<section id="_implementation_40">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mllex/lexgen.sml"><literal>lexgen.sml</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mllex/main.sml"><literal>main.sml</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mllex/call-main.sml"><literal>call-main.sml</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_40">
<title>Details and Notes</title>
<simpara>There are 3 main passes in the MLLex tool:</simpara>
<itemizedlist>
<listitem>
<simpara>
Source parsing. In this pass, lex source program are parsed into internal representations. The core part of this pass is a hand-written lexer and an LL(1) parser. The output of this pass is a record of user code, rules (along with start states) and actions. (MLLex definitions are wiped off.)
</simpara>
</listitem>
<listitem>
<simpara>
DFA construction. In this pass, a DFA is constructed by the algorithm of H. Yamada et. al.
</simpara>
</listitem>
<listitem>
<simpara>
Output. In this pass, the generated DFA is written out as a transition table, along with a table-driven algorithm, to an SML file.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_13">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="guide/Documentation.attachments/mllex.pdf"><literal>mllex.pdf</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLYacc">MLYacc</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_AppelEtAl94">AppelEtAl94</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Price09">Price09</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLLPTLibrary">
<title>MLLPTLibrary</title>
<simpara>The
<ulink url="http://smlnj-gforge.cs.uchicago.edu/projects/ml-lpt/">ML-LPT Library</ulink>
is a support library for the <link linkend="MLULex">MLULex</link> scanner generator and the
<link linkend="MLAntlr">MLAntlr</link> parser generator.  The ML-LPT Library is distributed with
SML/NJ.</simpara>
<simpara>As of 20180119, MLton includes the ML-LPT Library synchronized with
SML/NJ version 110.82.</simpara>
<section id="_usage_5">
<title>Usage</title>
<itemizedlist>
<listitem>
<simpara>
You can import the ML-LPT Library into an MLB file with:
</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<thead>
<row>
<entry align="left" valign="top">MLB file</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mllpt-lib/mllpt-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
If you are porting a project from SML/NJ&#8217;s <link linkend="CompilationManager">CompilationManager</link> to
MLton&#8217;s <link linkend="MLBasis">ML Basis system</link> using <literal>cm2mlb</literal>, note that the
following map is included by default:
</simpara>
<screen># MLLPT Library
$ml-lpt-lib.cm                          $(SML_LIB)/mllpt-lib
$ml-lpt-lib.cm/ml-lpt-lib.cm            $(SML_LIB)/mllpt-lib/mllpt-lib.mlb</screen>
<simpara>This will automatically convert a <literal>$/mllpt-lib.cm</literal> import in an input
<literal>.cm</literal> file into a <literal>$(SML_LIB)/mllpt-lib/mllpt-lib.mlb</literal> import in the
output <literal>.mlb</literal> file.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_2">
<title>Details</title>
<simpara></simpara>
</section>
<section id="_patch_2">
<title>Patch</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/lib/mllpt-lib/ml-lpt.patch"><literal>ml-lpt.patch</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLmon">
<title>MLmon</title>
<simpara>An <literal>mlmon.out</literal> file records dynamic <link linkend="Profiling">profiling</link> counts.</simpara>
<section id="_file_format">
<title>File format</title>
<simpara>An <literal>mlmon.out</literal> file is a text file with a sequence of lines.</simpara>
<itemizedlist>
<listitem>
<simpara>
The string "<literal>MLton prof</literal>".
</simpara>
</listitem>
<listitem>
<simpara>
The string "<literal>alloc</literal>", "<literal>count</literal>", or "<literal>time</literal>", depending on the kind
of profiling information, corresponding to the command-line argument
supplied to <literal>mlton -profile</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
The string "<literal>current</literal>" or "<literal>stack</literal>" depending on whether profiling
data was gathered for only the current function (the top of the stack)
or for all functions on the stack.  This corresponds to whether the
executable was compiled with <literal>-profile-stack false</literal> or <literal>-profile-stack
true</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
The magic number of the executable.
</simpara>
</listitem>
<listitem>
<simpara>
The number of non-gc ticks, followed by a space, then the number of
GC ticks.
</simpara>
</listitem>
<listitem>
<simpara>
The number of (split) functions for which data is recorded.
</simpara>
</listitem>
<listitem>
<simpara>
A line for each (split) function with counts.  Each line contains an
integer count of the number of ticks while the function was current.
In addition, if stack data was gathered (<literal>-profile-stack true</literal>), then
the line contains two additional tick counts:
</simpara>
<itemizedlist>
<listitem>
<simpara>
the number of ticks while the function was on the stack.
</simpara>
</listitem>
<listitem>
<simpara>
the number of ticks while the function was on the stack and a GC
   was performed.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
The number of (master) functions for which data is recorded.
</simpara>
</listitem>
<listitem>
<simpara>
A line for each (master) function with counts.  The lines have the
same format and meaning as with split-function counts.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLNLFFI">
<title>MLNLFFI</title>
<simpara><link linkend="References_Blume01">ML-NLFFI</link> is the no-longer-foreign-function interface
library for SML.</simpara>
<simpara>As of 20050212, MLton has an initial port of ML-NLFFI from SML/NJ to
MLton.  All of the ML-NLFFI functionality is present.</simpara>
<simpara>Additionally, MLton has an initial port of the
<link linkend="MLNLFFIGen">mlnlffigen</link> tool from SML/NJ to MLton.  Due to low-level
details, the code generated by SML/NJ&#8217;s <literal>ml-nlffigen</literal> is not
compatible with MLton, and vice-versa.  However, the generated code
has the same interface, so portable client code can be written.
MLton&#8217;s <literal>mlnlffigen</literal> does not currently support C functions with
<literal>struct</literal> or <literal>union</literal> arguments.</simpara>
<section id="_usage_6">
<title>Usage</title>
<itemizedlist>
<listitem>
<simpara>
You can import the ML-NLFFI Library into an MLB file with
</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<thead>
<row>
<entry align="left" valign="top">MLB file</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlnlffi-lib/mlnlffi-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
If you are porting a project from SML/NJ&#8217;s <link linkend="CompilationManager">CompilationManager</link> to
MLton&#8217;s <link linkend="MLBasis">ML Basis system</link> using <literal>cm2mlb</literal>, note that the
following maps are included by default:
</simpara>
<screen># MLNLFFI Library
$c                                      $(SML_LIB)/mlnlffi-lib
$c/c.cm                                 $(SML_LIB)/mlnlffi-lib/mlnlffi-lib.mlb</screen>
<simpara>This will automatically convert a <literal>$/c.cm</literal> import in an input <literal>.cm</literal>
file into a <literal>$(SML_LIB)/mlnlffi-lib/mlnlffi-lib.mlb</literal> import in the
output <literal>.mlb</literal> file.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_14">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Blume01">Blume01</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLNLFFIImplementation">MLNLFFIImplementation</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLNLFFIGen">MLNLFFIGen</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLNLFFIGen">
<title>MLNLFFIGen</title>
<simpara><literal>mlnlffigen</literal> generates a <link linkend="MLNLFFI">MLNLFFI</link> binding from a collection of <literal>.c</literal>
files. It is based on the <link linkend="CKitLibrary">CKitLibrary</link>, which is primarily designed
to handle standardized C and thus does not understand many (any?)
compiler extensions; however, it attempts to recover from errors when
seeing unrecognized definitions.</simpara>
<simpara>In order to work around common gcc extensions, it may be useful to add
<literal>-cppopt</literal> options to the command line; for example
<literal>-cppopt '-D__extension__'</literal> may be occasionally useful. Fortunately,
most portable libraries largely avoid the use of these types of
extensions in header files.</simpara>
<simpara><literal>mlnlffigen</literal> will normally not generate bindings for <literal>#included</literal>
files; see <literal>-match</literal> and <literal>-allSU</literal> if this is desirable.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLNLFFIImplementation">
<title>MLNLFFIImplementation</title>
<simpara>MLton&#8217;s implementation(s) of the <link linkend="MLNLFFI">MLNLFFI</link> library differs from the
SML/NJ implementation in two important ways:</simpara>
<itemizedlist>
<listitem>
<simpara>
MLton cannot utilize the <literal>Unsafe.cast</literal> "cheat" described in Section
3.7 of <link linkend="References_Blume01">Blume01</link>.  (MLton&#8217;s representation of
<link linkend="Closure">closures</link> and
<link linkend="PackedRepresentation">aggressive representation</link> optimizations make
an <literal>Unsafe.cast</literal> even more "unsafe" than in other implementations.)
</simpara>
<simpara>We have considered two solutions:</simpara>
<itemizedlist>
<listitem>
<simpara>
One solution is to utilize an additional type parameter (as
described in Section 3.7 of <link linkend="References_Blume01">Blume01</link>):
</simpara>
<blockquote>
<programlisting language="sml" linenumbering="unnumbered">signature C = sig
    type ('t, 'f, 'c) obj
    eqtype ('t, 'f, 'c) obj'
    ...
    type ('o, 'f) ptr
    eqtype ('o, 'f) ptr'
    ...
    type 'f fptr
    type 'f ptr'
    ...
    structure T : sig
        type ('t, 'f) typ
        ...
    end
end</programlisting>
<simpara>The rule for <literal>('t, 'f, 'c) obj</literal>,<literal>('t, 'f, 'c) ptr</literal>, and also <literal>('t, 'f)
T.typ</literal> is that whenever <literal>F fptr</literal> occurs within the instantiation of
<literal>'t</literal>, then <literal>'f</literal> must be instantiated to <literal>F</literal>.  In all other cases, <literal>'f</literal>
will be instantiated to <literal>unit</literal>.</simpara>
</blockquote>
<simpara>(In the actual MLton implementation, an abstract type <literal>naf</literal>
(not-a-function) is used instead of <literal>unit</literal>.)</simpara>
<simpara>While this means that type-annotated programs may not type-check under
both the SML/NJ implementation and the MLton implementation, this
should not be a problem in practice.  Tools, like <literal>ml-nlffigen</literal>, which
are necessarily implementation dependent (in order to make
<link linkend="CallingFromSMLToCFunctionPointer">calls through a C function pointer</link>), may be easily extended to emit the additional type
parameter.  Client code which uses such generated glue-code (e.g.,
Section 1 of <link linkend="References_Blume01">Blume01</link>) need rarely write type-annotations,
thanks to the magic of type inference.</simpara>
</listitem>
<listitem>
<simpara>
The above implementation suffers from two disadvantages.
</simpara>
<simpara>First, it changes the MLNLFFI Library interface, meaning that the same
program may not type-check under both the SML/NJ implementation and
the MLton implementation (though, in light of type inference and the
richer <literal>MLRep</literal> structure provided by MLton, this point is mostly
moot).</simpara>
<simpara>Second, it appears to unnecessarily duplicate type information.  For
example, an external C variable of type <literal>int (* f[3])(int)</literal> (that is,
an array of three function pointers), would be represented by the SML
type <literal>(((sint -&gt; sint) fptr, dec dg3) arr, sint -&gt; sint, rw) obj</literal>.
One might well ask why the <literal>'f</literal> instantiation (<literal>sint -&gt; sint</literal> in this
case) cannot be <emphasis>extracted</emphasis> from the <literal>'t</literal> instantiation
(<literal>((sint -&gt; sint) fptr, dec dg3) arr</literal> in this case), obviating the
need for a separate <emphasis>function-type</emphasis> type argument.  There are a number
of components to an complete answer to this question.  Foremost is the
fact that <link linkend="StandardML">Standard ML</link> supports neither (general)
type-level functions nor intensional polymorphism.</simpara>
<simpara>A more direct answer for MLNLFFI is that in the SML/NJ implemention,
the definition of the types <literal>('t, 'c) obj</literal> and <literal>('t, 'c) ptr</literal> are made
in such a way that the type variables <literal>'t</literal> and <literal>'c</literal> are <link linkend="PhantomType">phantom</link> (not contributing to the run-time representation of an
<literal>('t, 'c) obj</literal> or <literal>('t, 'c) ptr</literal> value), despite the fact that the
types <literal>((sint -&gt; sint) fptr, rw) ptr</literal> and
<literal>((double -&gt; double) fptr, rw) ptr</literal> necessarily carry distinct (and
type incompatible) run-time (C-)type information (RTTI), corresponding
to the different calling conventions of the two C functions.  The
<literal>Unsafe.cast</literal> "cheat" overcomes the type incompatibility without
introducing a new type variable (as in the first solution above).</simpara>
<simpara>Hence, the reason that <emphasis>function-type</emphasis> type cannot be extracted from
the <literal>'t</literal> type variable instantiation is that the type of the
representation of RTTI doesn&#8217;t even <emphasis>see</emphasis> the (phantom) <literal>'t</literal> type
variable.  The solution which presents itself is to give up on the
phantomness of the <literal>'t</literal> type variable, making it available to the
representation of RTTI.</simpara>
<simpara>This is not without some small drawbacks.  Because many of the types
used to instantiate <literal>'t</literal> carry more structure than is strictly
necessary for <literal>'t</literal>'s RTTI, it is sometimes necessary to wrap and
unwrap RTTI to accommodate the additional structure.  (In the other
implementations, the corresponding operations can pass along the RTTI
unchanged.)  However, these coercions contribute minuscule overhead;
in fact, in a majority of cases, MLton&#8217;s optimizations will completely
eliminate the RTTI from the final program.</simpara>
</listitem>
</itemizedlist>
<simpara>The implementation distributed with MLton uses the second solution.</simpara>
<simpara>Bonus question: Why can&#8217;t one use a <link linkend="UniversalType">universal type</link>
to eliminate the use of <literal>Unsafe.cast</literal>?</simpara>
<itemizedlist>
<listitem>
<simpara>
Answer: ???
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
MLton (in both of the above implementations) provides a richer
<literal>MLRep</literal> structure, utilizing <literal>Int<emphasis>&lt;N&gt;</emphasis></literal> and <literal>Word<emphasis>&lt;N&gt;</emphasis></literal>
structures.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure MLRep = struct
    structure Char =
       struct
          structure Signed = Int8
          structure Unsigned = Word8
          (* word-style bit-operations on integers... *)
          structure &lt;:SignedBitops:&gt; = IntBitOps(structure I = Signed
                                             structure W = Unsigned)
       end
    structure Short =
       struct
          structure Signed = Int16
          structure Unsigned = Word16
          (* word-style bit-operations on integers... *)
          structure &lt;:SignedBitops:&gt; = IntBitOps(structure I = Signed
                                             structure W = Unsigned)
       end
    structure Int =
       struct
          structure Signed = Int32
          structure Unsigned = Word32
          (* word-style bit-operations on integers... *)
          structure &lt;:SignedBitops:&gt; = IntBitOps(structure I = Signed
                                             structure W = Unsigned)
       end
    structure Long =
       struct
          structure Signed = Int32
          structure Unsigned = Word32
          (* word-style bit-operations on integers... *)
          structure &lt;:SignedBitops:&gt; = IntBitOps(structure I = Signed
                                             structure W = Unsigned)
       end
    structure &lt;:LongLong:&gt; =
       struct
          structure Signed = Int64
          structure Unsigned = Word64
          (* word-style bit-operations on integers... *)
          structure &lt;:SignedBitops:&gt; = IntBitOps(structure I = Signed
                                             structure W = Unsigned)
       end
    structure Float = Real32
    structure Double = Real64
end</programlisting>
<simpara>This would appear to be a better interface, even when an
implementation must choose <literal>Int32</literal> and <literal>Word32</literal> as the representation
for smaller C-types.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLRISCLibrary">
<title>MLRISCLibrary</title>
<simpara>The <ulink url="http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/index.html">MLRISC
Library</ulink> is a framework for retargetable and optimizing compiler back
ends.  The MLRISC Library is distributed with SML/NJ.  Due to
differences between SML/NJ and MLton, this library will not work
out-of-the box with MLton.</simpara>
<simpara>As of 20180119, MLton includes a port of the MLRISC Library
synchronized with SML/NJ version 110.82.</simpara>
<section id="_usage_7">
<title>Usage</title>
<itemizedlist>
<listitem>
<simpara>
You can import a sub-library of the MLRISC Library into an MLB file with:
</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<thead>
<row>
<entry align="left" valign="top">MLB file</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/ALPHA.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The ALPHA backend</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/AMD64.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The AMD64 backend</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/AMD64-Peephole.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The AMD64 peephole optimizer</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/CCall.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/CCall-sparc.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/CCall-x86-64.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/CCall-x86.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/Control.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/Graphs.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/HPPA.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The HPPA backend</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/IA32.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The IA32 backend</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/IA32-Peephole.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The IA32 peephole optimizer</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/Lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/MLRISC.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/MLTREE.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/Peephole.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/PPC.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The PPC backend</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/RA.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/SPARC.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>The Sparc backend</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/StagedAlloc.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/mlrisc-lib/mlb/Visual.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
If you are porting a project from SML/NJ&#8217;s <link linkend="CompilationManager">CompilationManager</link> to
MLton&#8217;s <link linkend="MLBasis">ML Basis system</link> using <literal>cm2mlb</literal>, note that the
following map is included by default:
</simpara>
<screen># MLRISC Library
$SMLNJ-MLRISC                           $(SML_LIB)/mlrisc-lib/mlb</screen>
<simpara>This will automatically convert a <literal>$SMLNJ-MLRISC/MLRISC.cm</literal> import in
an input <literal>.cm</literal> file into a <literal>$(SML_LIB)/mlrisc-lib/mlb/MLRISC.mlb</literal>
import in the output <literal>.mlb</literal> file.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_3">
<title>Details</title>
<simpara>The following changes were made to the MLRISC Library, in addition to
deriving the <literal>.mlb</literal> files from the <literal>.cm</literal> files:</simpara>
<itemizedlist>
<listitem>
<simpara>
eliminate sequential <literal>withtype</literal> expansions: Most could be rewritten as a sequence of type definitions and datatype definitions.
</simpara>
</listitem>
<listitem>
<simpara>
eliminate higher-order functors: Every higher-order functor definition and application could be uncurried in the obvious way.
</simpara>
</listitem>
<listitem>
<simpara>
eliminate <literal>where &lt;str&gt; = &lt;str&gt;</literal>: Quite painful to expand out all the flexible types in the respective structures.  Furthermore, many of the implied type equalities aren&#8217;t needed, but it&#8217;s too hard to pick out the right ones.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>library/array-noneq.sml</literal> (added, not exported): Implements <literal>signature ARRAY_NONEQ</literal>, similar to <literal>signature ARRAY</literal> from the <link linkend="BasisLibrary">Basis Library</link>, but replacing the latter&#8217;s <literal>eqtype 'a array = 'a array</literal> and <literal>type 'a vector = 'a Vector.vector</literal> with <literal>type 'a array</literal> and <literal>type 'a vector</literal>.  Thus, array-like containers may match <literal>ARRAY_NONEQ</literal>, whereas only the pervasive <literal>'a array</literal> container may math <literal>ARRAY</literal>.  (SML/NJ&#8217;s implementation of <literal>signature ARRAY</literal> omits the type realizations.)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>library/dynamic-array.sml</literal> and <literal>library/hash-array.sml</literal> (modifed): Replace <literal>include ARRAY</literal> with <literal>include ARRAY_NONEQ</literal>; see above.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_patch_3">
<title>Patch</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/lib/mlrisc-lib/MLRISC.patch"><literal>MLRISC.patch</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonArray">
<title>MLtonArray</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_ARRAY =
   sig
      val unfoldi: int * 'b * (int * 'b -&gt; 'a * 'b) -&gt; 'a array * 'b
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>unfoldi (n, b, f)</literal>
</simpara>
<simpara>constructs an array <emphasis>a</emphasis> of length <literal>n</literal>, whose elements <emphasis>a<subscript>i</subscript></emphasis> are
determined by the equations <emphasis>b<subscript>0</subscript> = b</emphasis> and
<emphasis>(a<subscript>i</subscript>, b<subscript>i+1</subscript>) = f (i, b<subscript>i</subscript>)</emphasis>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonBinIO">
<title>MLtonBinIO</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_BIN_IO = MLTON_IO</programlisting>
<simpara>See <link linkend="MLtonIO">MLtonIO</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonCont">
<title>MLtonCont</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_CONT =
   sig
      type 'a t

      val callcc: ('a t -&gt; 'a) -&gt; 'a
      val isolate: ('a -&gt; unit) -&gt; 'a t
      val prepend: 'a t * ('b -&gt; 'a) -&gt; 'b t
      val throw: 'a t * 'a -&gt; 'b
      val throw': 'a t * (unit -&gt; 'a) -&gt; 'b
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>type 'a t</literal>
</simpara>
<simpara>the type of continuations that expect a value of type <literal>'a</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>callcc f</literal>
</simpara>
<simpara>applies <literal>f</literal> to the current continuation.  This copies the entire
stack; hence, <literal>callcc</literal> takes time proportional to the size of the
current stack.</simpara>
</listitem>
<listitem>
<simpara>
<literal>isolate f</literal>
</simpara>
<simpara>creates a continuation that evaluates <literal>f</literal> in an empty context.  This
is a constant time operation, and yields a constant size stack.</simpara>
</listitem>
<listitem>
<simpara>
<literal>prepend (k, f)</literal>
</simpara>
<simpara>composes a function <literal>f</literal> with a continuation <literal>k</literal> to create a
continuation that first does <literal>f</literal> and then does <literal>k</literal>.  This is a
constant time operation.</simpara>
</listitem>
<listitem>
<simpara>
<literal>throw (k, v)</literal>
</simpara>
<simpara>throws value <literal>v</literal> to continuation <literal>k</literal>.  This copies the entire stack of
<literal>k</literal>; hence, <literal>throw</literal> takes time proportional to the size of this stack.</simpara>
</listitem>
<listitem>
<simpara>
<literal>throw' (k, th)</literal>
</simpara>
<simpara>a generalization of throw that evaluates <literal>th ()</literal> in the context of
<literal>k</literal>.  Thus, for example, if <literal>th ()</literal> raises an exception or captures
another continuation, it will see <literal>k</literal>, not the current continuation.</simpara>
</listitem>
</itemizedlist>
<section id="_also_see_15">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLtonContIsolateImplementation">MLtonContIsolateImplementation</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonContIsolateImplementation">
<title>MLtonContIsolateImplementation</title>
<simpara>As noted before, it is fairly easy to get the operational behavior of <literal>isolate</literal> with just <literal>callcc</literal> and <literal>throw</literal>, but establishing the right space behavior is trickier.  Here, we show how to start from the obvious, but inefficient, implementation of <literal>isolate</literal> using only <literal>callcc</literal> and <literal>throw</literal>, and <emphasis>derive</emphasis> an equivalent, but more efficient, implementation of <literal>isolate</literal> using MLton&#8217;s primitive stack capture and copy operations.  This isn&#8217;t a formal derivation, as we are not formally showing the equivalence of the programs (though I believe that they are all equivalent, modulo the space behavior).</simpara>
<simpara>Here is a direct implementation of isolate using only <literal>callcc</literal> and <literal>throw</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val isolate: ('a -&gt; unit) -&gt; 'a t =
  fn (f: 'a -&gt; unit) =&gt;
  callcc
  (fn k1 =&gt;
   let
      val x = callcc (fn k2 =&gt; throw (k1, k2))
      val _ = (f x ; Exit.topLevelSuffix ())
              handle exn =&gt; MLtonExn.topLevelHandler exn
   in
      raise Fail "MLton.Cont.isolate: return from (wrapped) func"
   end)</programlisting>
<simpara>We use the standard nested <literal>callcc</literal> trick to return a continuation that is ready to receive an argument, execute the isolated function, and exit the program.  Both <literal>Exit.topLevelSuffix</literal> and <literal>MLtonExn.topLevelHandler</literal> will terminate the program.</simpara>
<simpara>Throwing to an isolated function will execute the function in a <emphasis>semantically</emphasis> empty context, in the sense that we never re-execute the <emphasis>original</emphasis> continuation of the call to isolate (i.e., the context that was in place at the time <literal>isolate</literal> was called).  However, we assume that the compiler isn&#8217;t able to recognize that the <emphasis>original</emphasis> continuation is unused; for example, while we (the programmer) know that <literal>Exit.topLevelSuffix</literal> and <literal>MLtonExn.topLevelHandler</literal> will terminate the program, the compiler may only see opaque calls to unknown foreign-functions.  So, that original continuation (in its entirety) is part of the continuation returned by <literal>isolate</literal> and throwing to the continuation returned by <literal>isolate</literal> will execute <literal>f x</literal> (with the exit wrapper) in the context of that original continuation.  Thus, the garbage collector will retain  everything reachable from that original continuation during the evaluation of <literal>f x</literal>, even though it is <emphasis>semantically</emphasis> garbage.</simpara>
<simpara>Note that this space-leak is independent of the implementation of continuations (it arises in both MLton&#8217;s stack copying implementation of continuations and would arise in SML/NJ&#8217;s CPS-translation implementation); we are only assuming that the implementation can&#8217;t <emphasis>see</emphasis> the program termination, and so must retain the original continuation (and anything reachable from it).</simpara>
<simpara>So, we need an <emphasis>empty</emphasis> continuation in which to execute <literal>f x</literal>.  (No surprise there, as that is the written description of <literal>isolate</literal>.)  To do this, we capture a top-level continuation and throw to that in order to execute <literal>f x</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val base: (unit -&gt; unit) t =
  callcc
  (fn k1 =&gt;
   let
      val th = callcc (fn k2 =&gt; throw (k1, k2))
      val _ = (th () ; Exit.topLevelSuffix ())
              handle exn =&gt; MLtonExn.topLevelHandler exn
   in
      raise Fail "MLton.Cont.isolate: return from (wrapped) func"
   end)
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
  fn (f: 'a -&gt; unit) =&gt;
  callcc
  (fn k1 =&gt;
   let
      val x = callcc (fn k2 =&gt; throw (k1, k2))
   in
      throw (base, fn () =&gt; f x)
   end)
end</programlisting>
<simpara>We presume that <literal>base</literal> is evaluated <emphasis>early</emphasis> in the program.  There is a subtlety here, because one needs to believe that this <literal>base</literal> continuation (which technically corresponds to the entire rest of the program evaluation) <emphasis>works</emphasis> as an empty context; in particular, we want it to be the case that executing <literal>f x</literal> in the <literal>base</literal> context retains less space than executing <literal>f x</literal> in the context in place at the call to <literal>isolate</literal> (as occurred in the previous implementation of <literal>isolate</literal>).  This isn&#8217;t particularly easy to believe if one takes a normal substitution-based operational semantics, because it seems that the context captured and bound to <literal>base</literal> is arbitrarily large.  However, this context is mostly unevaluated code; the only heap-allocated values that are reachable from it are those that were evaluated before the evaluation of <literal>base</literal> (and used in the program after the evaluation of <literal>base</literal>).  Assuming that <literal>base</literal> is evaluated <emphasis>early</emphasis> in the program, we conclude that there are few heap-allocated values reachable from its continuation.  In contrast, the previous implementation of <literal>isolate</literal> could capture a context that has many heap-allocated values reachable from it (because we could evaluate <literal>isolate f</literal> <emphasis>late</emphasis> in the program and <emphasis>deep</emphasis> in a call stack), which would all remain reachable during the evaluation of
<literal>f x</literal>.  [We&#8217;ll return to this point later, as it is taking a slightly MLton-esque view of the evaluation of a program, and may not apply as strongly to other implementations (e.g., SML/NJ).]</simpara>
<simpara>Now, once we throw to <literal>base</literal> and begin executing <literal>f x</literal>, only the heap-allocated values reachable from <literal>f</literal> and <literal>x</literal> and the few heap-allocated values reachable from <literal>base</literal> are retained by the garbage collector.  So, it seems that <literal>base</literal> <emphasis>works</emphasis> as an empty context.</simpara>
<simpara>But, what about the continuation returned from <literal>isolate f</literal>?  Note that the continuation returned by <literal>isolate</literal> is one that receives an argument <literal>x</literal> and then
throws to <literal>base</literal> to evaluate <literal>f x</literal>.  If we used a CPS-translation implementation (and assume sufficient beta-contractions to eliminate administrative redexes), then the original continuation passed to <literal>isolate</literal> (i.e., the continuation bound to <literal>k1</literal>) will not be free in the continuation returned by <literal>isolate f</literal>.  Rather, the only free variables in the continuation returned by <literal>isolate f</literal> will be <literal>base</literal> and <literal>f</literal>, so the only heap-allocated values reachable from the continuation returned by <literal>isolate f</literal> will be those values reachable from <literal>base</literal> (assumed to be few) and those values reachable from <literal>f</literal> (necessary in order to execute <literal>f</literal> at some later point).</simpara>
<simpara>But, MLton doesn&#8217;t use a CPS-translation implementation.  Rather, at each call to <literal>callcc</literal> in the body of <literal>isolate</literal>, MLton will copy the current execution stack.  Thus, <literal>k2</literal> (the continuation returned by <literal>isolate f</literal>) will include execution stack at the time of the call to <literal>isolate f</literal>&#8201;&#8212;&#8201;that is, it will include the <emphasis>original</emphasis> continuation of the call to <literal>isolate f</literal>.  Thus, the heap-allocated values reachable from the continuation returned by <literal>isolate f</literal> will include those values reachable from <literal>base</literal>, those values reachable from <literal>f</literal>, and those values reachable from the original continuation of the call to <literal>isolate f</literal>.  So, just holding on to the continuation returned by <literal>isolate f</literal> will retain all of the heap-allocated values live at the time <literal>isolate f</literal> was called.  This leaks space, since, <emphasis>semantically</emphasis>, the
continuation returned by <literal>isolate f</literal> only needs the heap-allocated values reachable from <literal>f</literal> (and <literal>base</literal>).</simpara>
<simpara>In practice, this probably isn&#8217;t a significant issue.  A common use of <literal>isolate</literal> is implement <literal>abort</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun abort th = throw (isolate th, ())</programlisting>
<simpara>The continuation returned by <literal>isolate th</literal> is dead immediately after being thrown to&#8201;&#8212;&#8201;the continuation isn&#8217;t retained, so neither is the <emphasis>semantic</emphasis>
garbage it would have retained.</simpara>
<simpara>But, it is easy enough to <emphasis>move</emphasis> onto the <emphasis>empty</emphasis> context <literal>base</literal> the capturing of the context that we want to be returned by <literal>isolate f</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val base: (unit -&gt; unit) t =
  callcc
  (fn k1 =&gt;
   let
      val th = callcc (fn k2 =&gt; throw (k1, k2))
      val _ = (th () ; Exit.topLevelSuffix ())
              handle exn =&gt; MLtonExn.topLevelHandler exn
   in
      raise Fail "MLton.Cont.isolate: return from (wrapped) func"
   end)
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
  fn (f: 'a -&gt; unit) =&gt;
  callcc
  (fn k1 =&gt;
   throw (base, fn () =&gt;
          let
             val x = callcc (fn k2 =&gt; throw (k1, k2))
          in
             throw (base, fn () =&gt; f x)
          end))
end</programlisting>
<simpara>This implementation now has the right space behavior; the continuation returned by <literal>isolate f</literal> will only retain the heap-allocated values reachable from <literal>f</literal> and from <literal>base</literal>.  (Technically, the continuation will retain two copies of the stack that was in place at the time <literal>base</literal> was evaluated, but we are assuming that that stack small.)</simpara>
<simpara>One minor inefficiency of this implementation (given MLton&#8217;s implementation of continuations) is that every <literal>callcc</literal> and <literal>throw</literal> entails copying a stack (albeit, some of them are small).  We can avoid this in the evaluation of <literal>base</literal> by using a reference cell, because <literal>base</literal> is evaluated at the top-level:</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val base: (unit -&gt; unit) option t =
  let
     val baseRef: (unit -&gt; unit) option t option ref = ref NONE
     val th = callcc (fn k =&gt; (base := SOME k; NONE))
  in
     case th of
        NONE =&gt; (case !baseRef of
                    NONE =&gt; raise Fail "MLton.Cont.isolate: missing base"
                  | SOME base =&gt; base)
      | SOME th =&gt; let
                      val _ = (th () ; Exit.topLevelSuffix ())
                              handle exn =&gt; MLtonExn.topLevelHandler exn
                   in
                      raise Fail "MLton.Cont.isolate: return from (wrapped)
                      func"
                   end
  end
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
  fn (f: 'a -&gt; unit) =&gt;
  callcc
  (fn k1 =&gt;
   throw (base, SOME (fn () =&gt;
          let
             val x = callcc (fn k2 =&gt; throw (k1, k2))
          in
             throw (base, SOME (fn () =&gt; f x))
          end)))
end</programlisting>
<simpara>Now, to evaluate <literal>base</literal>, we only copy the stack once (instead of 3 times).  Because we don&#8217;t have a dummy continuation around to initialize the reference cell, the reference cell holds a continuation <literal>option</literal>.  To distinguish between the original evaluation of <literal>base</literal> (when we want to return the continuation) and the subsequent evaluations of <literal>base</literal> (when we want to evaluate a thunk), we capture a <literal>(unit -&gt; unit) option</literal> continuation.</simpara>
<simpara>This seems to be as far as we can go without exploiting the concrete implementation of continuations in <link linkend="MLtonCont">MLtonCont</link>.  Examining the implementation, we note that the type of
continuations is given by</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a t = (unit -&gt; 'a) -&gt; unit</programlisting>
<simpara>and the implementation of <literal>throw</literal> is given by</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun ('a, 'b) throw' (k: 'a t, v: unit -&gt; 'a): 'b =
  (k v; raise Fail "MLton.Cont.throw': return from continuation")

fun ('a, 'b) throw (k: 'a t, v: 'a): 'b = throw' (k, fn () =&gt; v)</programlisting>
<simpara>Suffice to say, a continuation is simply a function that accepts a thunk to yield the thrown value and the body of the function performs the actual throw. Using this knowledge, we can create a dummy continuation to initialize <literal>baseRef</literal> and greatly simplify the body of <literal>isolate</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val base: (unit -&gt; unit) option t =
  let
     val baseRef: (unit -&gt; unit) option t ref =
        ref (fn _ =&gt; raise Fail "MLton.Cont.isolate: missing base")
     val th = callcc (fn k =&gt; (baseRef := k; NONE))
  in
     case th of
        NONE =&gt; !baseRef
      | SOME th =&gt; let
                      val _ = (th () ; Exit.topLevelSuffix ())
                              handle exn =&gt; MLtonExn.topLevelHandler exn
                   in
                      raise Fail "MLton.Cont.isolate: return from (wrapped)
                      func"
                   end
  end
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
  fn (f: 'a -&gt; unit) =&gt;
  fn (v: unit -&gt; 'a) =&gt;
  throw (base, SOME (f o v))
end</programlisting>
<simpara>Note that this implementation of <literal>isolate</literal> makes it clear that the continuation returned by <literal>isolate f</literal> only retains the heap-allocated values reachable from <literal>f</literal> and <literal>base</literal>.  It also retains only one copy of the stack that was in place at the time <literal>base</literal> was evaluated.  Finally, it completely avoids making any copies of the stack that is in place at the time <literal>isolate f</literal> is evaluated; indeed, <literal>isolate f</literal> is a constant-time operation.</simpara>
<simpara>Next, suppose we limited ourselves to capturing <literal>unit</literal> continuations with <literal>callcc</literal>.  We can&#8217;t pass the thunk to be evaluated in the <emphasis>empty</emphasis> context directly, but we can use a reference cell.</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val thRef: (unit -&gt; unit) option ref = ref NONE
val base: unit t =
  let
     val baseRef: unit t ref =
        ref (fn _ =&gt; raise Fail "MLton.Cont.isolate: missing base")
     val () = callcc (fn k =&gt; baseRef := k)
  in
     case !thRef of
        NONE =&gt; !baseRef
      | SOME th =&gt;
           let
              val _ = thRef := NONE
              val _ = (th () ; Exit.topLevelSuffix ())
                      handle exn =&gt; MLtonExn.topLevelHandler exn
           in
              raise Fail "MLton.Cont.isolate: return from (wrapped) func"
           end
  end
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
  fn (f: 'a -&gt; unit) =&gt;
  fn (v: unit -&gt; 'a) =&gt;
  let
     val () = thRef := SOME (f o v)
  in
     throw (base, ())
  end
end</programlisting>
<simpara>Note that it is important to set <literal>thRef</literal> to <literal>NONE</literal> before evaluating the thunk, so that the garbage collector doesn&#8217;t retain all the heap-allocated values reachable from <literal>f</literal> and <literal>v</literal> during the evaluation of <literal>f (v ())</literal>.  This is because <literal>thRef</literal> is still live during the evaluation of the thunk; in particular, it was allocated before the evaluation of <literal>base</literal> (and used after), and so is retained by continuation on which the thunk is evaluated.</simpara>
<simpara>This implementation can be easily adapted to use MLton&#8217;s primitive stack copying operations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val thRef: (unit -&gt; unit) option ref = ref NONE
val base: Thread.preThread =
   let
      val () = Thread.copyCurrent ()
   in
      case !thRef of
         NONE =&gt; Thread.savedPre ()
       | SOME th =&gt;
            let
               val () = thRef := NONE
               val _ = (th () ; Exit.topLevelSuffix ())
                       handle exn =&gt; MLtonExn.topLevelHandler exn
            in
               raise Fail "MLton.Cont.isolate: return from (wrapped) func"
            end
   end
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
   fn (f: 'a -&gt; unit) =&gt;
   fn (v: unit -&gt; 'a) =&gt;
   let
      val () = thRef := SOME (f o v)
      val new = Thread.copy base
   in
      Thread.switchTo new
   end
end</programlisting>
<simpara>In essence, <literal>Thread.copyCurrent</literal> copies the current execution stack and stores it in an implicit reference cell in the runtime system, which is fetchable with <literal>Thread.savedPre</literal>.  When we are ready to throw to the isolated function, <literal>Thread.copy</literal> copies the saved execution stack (because the stack is modified in place during execution, we need to retain a pristine copy in case the isolated function itself throws to other isolated functions) and <literal>Thread.switchTo</literal> abandons the current execution stack, installing the newly copied execution stack.</simpara>
<simpara>The actual implementation of <literal>MLton.Cont.isolate</literal> simply adds some <literal>Thread.atomicBegin</literal> and <literal>Thread.atomicEnd</literal> commands, which effectively protect the global <literal>thRef</literal> and accommodate the fact that <literal>Thread.switchTo</literal> does an implicit <literal>Thread.atomicEnd</literal> (used for leaving a signal handler thread).</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
val thRef: (unit -&gt; unit) option ref = ref NONE
val base: Thread.preThread =
   let
      val () = Thread.copyCurrent ()
   in
      case !thRef of
         NONE =&gt; Thread.savedPre ()
       | SOME th =&gt;
            let
               val () = thRef := NONE
               val _ = MLton.atomicEnd (* Match 1 *)
               val _ = (th () ; Exit.topLevelSuffix ())
                       handle exn =&gt; MLtonExn.topLevelHandler exn
            in
               raise Fail "MLton.Cont.isolate: return from (wrapped) func"
            end
   end
in
val isolate: ('a -&gt; unit) -&gt; 'a t =
   fn (f: 'a -&gt; unit) =&gt;
   fn (v: unit -&gt; 'a) =&gt;
   let
      val _ = MLton.atomicBegin (* Match 1 *)
      val () = thRef := SOME (f o v)
      val new = Thread.copy base
      val _ = MLton.atomicBegin (* Match 2 *)
   in
      Thread.switchTo new (* Match 2 *)
   end
end</programlisting>
<simpara>It is perhaps interesting to note that the above implementation was originally <emphasis>derived</emphasis> by specializing implementations of the <link linkend="MLtonThread">MLtonThread</link> <literal>new</literal>, <literal>prepare</literal>, and <literal>switch</literal> functions as if their only use was in the following implementation of <literal>isolate</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val isolate: ('a -&gt; unit) -&gt; 'a t =
   fn (f: 'a -&gt; unit) =&gt;
   fn (v: unit -&gt; 'a) =&gt;
   let
      val th = (f (v ()) ; Exit.topLevelSuffix ())
               handle exn =&gt; MLtonExn.topLevelHandler exn
      val t = MLton.Thread.prepare (MLton.Thread.new th, ())
   in
      MLton.Thread.switch (fn _ =&gt; t)
   end</programlisting>
<simpara>It was pleasant to discover that it could equally well be <emphasis>derived</emphasis> starting from the <literal>callcc</literal> and <literal>throw</literal> implementation.</simpara>
<simpara>As a final comment, we noted that the degree to which the context of <literal>base</literal> could be considered <emphasis>empty</emphasis> (i.e., retaining few heap-allocated values) depended upon a slightly MLton-esque view.  In particular, MLton does not heap allocate executable code.  So, although the <literal>base</literal> context keeps a lot of unevaluated code <emphasis>live</emphasis>, such code is not heap allocated.  In a system like SML/NJ, that does heap allocate executable code, one might want it to be the case that after throwing to an isolated function, the garbage collector retains only the code necessary to evaluate the function, and not any code that was necessary to evaluate the <literal>base</literal> context.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonCross">
<title>MLtonCross</title>
<simpara>The debian package MLton-Cross adds various targets to MLton. In
combination with the emdebian project, this allows a debian system to
compile SML files to other architectures.</simpara>
<simpara>Currently, these targets are supported:</simpara>
<itemizedlist>
<listitem>
<simpara>
<emphasis>Windows (MinGW)</emphasis>
</simpara>
<itemizedlist>
<listitem>
<simpara>
-target i586-mingw32msvc (mlton-target-i586-mingw32msvc)
</simpara>
</listitem>
<listitem>
<simpara>
-target amd64-mingw32msvc( mlton-target-amd64-mingw32msvc)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<emphasis>Linux (Debian)</emphasis>
</simpara>
<itemizedlist>
<listitem>
<simpara>
-target alpha-linux-gnu (mlton-target-alpha-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target arm-linux-gnueabi (mlton-target-arm-linux-gnueabi)
</simpara>
</listitem>
<listitem>
<simpara>
-target hppa-linux-gnu (mlton-target-hppa-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target i486-linux-gnu (mlton-target-i486-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target ia64-linux-gnu (mlton-target-ia64-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target mips-linux-gnu (mlton-target-mips-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target mipsel-linux-gnu (mlton-target-mipsel-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target powerpc-linux-gnu (mlton-target-powerpc-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target s390-linux-gnu (mlton-target-s390-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target sparc-linux-gnu (mlton-target-sparc-linux-gnu)
</simpara>
</listitem>
<listitem>
<simpara>
-target x86-64-linux-gnu (mlton-target-x86-64-linux-gnu)
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<section id="_download_6">
<title>Download</title>
<simpara>MLton-Cross is kept in-sync with the current MLton release.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="guide/MLtonCross.attachments/mlton-cross_20100608.orig.tar.gz"><literal>mlton-cross_20100608.orig.tar.gz</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonExn">
<title>MLtonExn</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_EXN =
   sig
      val addExnMessager: (exn -&gt; string option) -&gt; unit
      val history: exn -&gt; string list

      val defaultTopLevelHandler: exn -&gt; 'a
      val getTopLevelHandler: unit -&gt; (exn -&gt; unit)
      val setTopLevelHandler: (exn -&gt; unit) -&gt; unit
      val topLevelHandler: exn -&gt; 'a
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>addExnMessager f</literal>
</simpara>
<simpara>adds <literal>f</literal> as a pretty-printer to be used by <literal>General.exnMessage</literal> for
converting exceptions to strings.  Messagers are tried in order from
most recently added to least recently added.</simpara>
</listitem>
<listitem>
<simpara>
<literal>history e</literal>
</simpara>
<simpara>returns call stack at the point that <literal>e</literal> was first raised.  Each
element of the list is a file position.  The elements are in reverse
chronological order, i.e. the function called last is at the front of
the list.</simpara>
<simpara><literal>history e</literal> will return <literal>[]</literal> unless the program is compiled with
<literal>-const 'Exn.keepHistory true'</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>defaultTopLevelHandler e</literal>
</simpara>
<simpara>function that behaves as the default top level handler; that is, print
out the unhandled exception message for <literal>e</literal> and exit.</simpara>
</listitem>
<listitem>
<simpara>
<literal>getTopLevelHandler ()</literal>
</simpara>
<simpara>get the top level handler.</simpara>
</listitem>
<listitem>
<simpara>
<literal>setTopLevelHandler f</literal>
</simpara>
<simpara>set the top level handler to the function <literal>f</literal>.  The function <literal>f</literal>
should not raise an exception or return normally.</simpara>
</listitem>
<listitem>
<simpara>
<literal>topLevelHandler e</literal>
</simpara>
<simpara>behaves as if the top level handler received the exception <literal>e</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonFinalizable">
<title>MLtonFinalizable</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_FINALIZABLE =
   sig
      type 'a t

      val addFinalizer: 'a t * ('a -&gt; unit) -&gt; unit
      val finalizeBefore: 'a t * 'b t -&gt; unit
      val new: 'a -&gt; 'a t
      val touch: 'a t -&gt; unit
      val withValue: 'a t * ('a -&gt; 'b) -&gt; 'b
   end</programlisting>
<simpara>A <emphasis>finalizable</emphasis> value is a container to which finalizers can be
attached.  A container holds a value, which is reachable as long as
the container itself is reachable.  A <emphasis>finalizer</emphasis> is a function that
runs at some point after garbage collection determines that the
container to which it is attached has become
<link linkend="Reachability">unreachable</link>.  A finalizer is treated like a signal
handler, in that it runs asynchronously in a separate thread, with
signals blocked, and will not interrupt a critical section (see
<link linkend="MLtonThread">MLtonThread</link>).</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>addFinalizer (v, f)</literal>
</simpara>
<simpara>adds <literal>f</literal> as a finalizer to <literal>v</literal>.  This means that sometime after the
last call to <literal>withValue</literal> on <literal>v</literal> completes and <literal>v</literal> becomes unreachable,
<literal>f</literal> will be called with the value of <literal>v</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>finalizeBefore (v1, v2)</literal>
</simpara>
<simpara>ensures that <literal>v1</literal> will be finalized before <literal>v2</literal>.  A cycle of values
<literal>v</literal> = <literal>v1</literal>, &#8230;, <literal>vn</literal> = <literal>v</literal> with <literal>finalizeBefore (vi, vi+1)</literal> will
result in none of the <literal>vi</literal> being finalized.</simpara>
</listitem>
<listitem>
<simpara>
<literal>new x</literal>
</simpara>
<simpara>creates a new finalizable value, <literal>v</literal>, with value <literal>x</literal>.  The finalizers
of <literal>v</literal> will run sometime after the last call to <literal>withValue</literal> on <literal>v</literal>
when the garbage collector determines that <literal>v</literal> is unreachable.</simpara>
</listitem>
<listitem>
<simpara>
<literal>touch v</literal>
</simpara>
<simpara>ensures that <literal>v</literal>'s finalizers will not run before the call to <literal>touch</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>withValue (v, f)</literal>
</simpara>
<simpara>returns the result of applying <literal>f</literal> to the value of <literal>v</literal> and ensures
that <literal>v</literal>'s finalizers will not run before <literal>f</literal> completes.  The call to
<literal>f</literal> is a nontail call.</simpara>
</listitem>
</itemizedlist>
<section id="_example_4">
<title>Example</title>
<simpara>Suppose that <literal>finalizable.sml</literal> contains the following:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature CLIST =
   sig
      type t

      val cons: int * t -&gt; t
      val sing: int -&gt; t
      val sum: t -&gt; int
   end

functor CList (structure F: MLTON_FINALIZABLE
               structure P: MLTON_POINTER
               structure Prim:
                  sig
                     val cons: int * P.t -&gt; P.t
                     val free: P.t -&gt; unit
                     val sing: int -&gt; P.t
                     val sum: P.t -&gt; int
                  end): CLIST =
   struct
      type t = P.t F.t

      fun cons (n: int, l: t) =
         F.withValue
         (l, fn w' =&gt;
          let
             val c = F.new (Prim.cons (n, w'))
             val _ = F.addFinalizer (c, Prim.free)
             val _ = F.finalizeBefore (c, l)
          in
             c
          end)

      fun sing n =
         let
            val c = F.new (Prim.sing n)
            val _ = F.addFinalizer (c, Prim.free)
         in
            c
         end

      fun sum c = F.withValue (c, Prim.sum)
   end

functor Test (structure CList: CLIST
              structure MLton: sig
                                  structure GC:
                                     sig
                                        val collect: unit -&gt; unit
                                     end
                               end) =
   struct
      fun f n =
         if n = 1
            then ()
         else
            let
               val a = Array.tabulate (n, fn i =&gt; i)
               val _ = Array.sub (a, 0) + Array.sub (a, 1)
            in
               f (n - 1)
            end

      val l = CList.sing 2
      val l = CList.cons (2,l)
      val l = CList.cons (2,l)
      val l = CList.cons (2,l)
      val l = CList.cons (2,l)
      val l = CList.cons (2,l)
      val l = CList.cons (2,l)
      val _ = MLton.GC.collect ()
      val _ = f 100
      val _ = print (concat ["listSum(l) = ",
                             Int.toString (CList.sum l),
                             "\n"])
      val _ = MLton.GC.collect ()
      val _ = f 100
   end

structure CList =
   CList (structure F = MLton.Finalizable
          structure P = MLton.Pointer
          structure Prim =
             struct
                val cons = _import "listCons": int * P.t -&gt; P.t;
                val free = _import "listFree": P.t -&gt; unit;
                val sing = _import "listSing": int -&gt; P.t;
                val sum = _import "listSum": P.t -&gt; int;
             end)

structure S = Test (structure CList = CList
                    structure MLton = MLton)</programlisting>
<simpara>Suppose that <literal>cons.c</literal> contains the following.</simpara>
<programlisting language="c" linenumbering="unnumbered">#include &lt;stdio.h&gt;

typedef unsigned int uint;

typedef struct Cons {
        struct Cons *next;
        int value;
} *Cons;

Cons listCons (int n, Cons c) {
        Cons res;

        res = (Cons) malloc (sizeof(*res));
        fprintf (stderr, "0x%08x = listCons (%d)\n", (uint)res, n);
        res-&gt;next = c;
        res-&gt;value = n;
        return res;
}

Cons listSing (int n) {
        Cons res;

        res = (Cons) malloc (sizeof(*res));
        fprintf (stderr, "0x%08x = listSing (%d)\n", (uint)res, n);
        res-&gt;next = NULL;
        res-&gt;value = n;
        return res;
}

void listFree (Cons p) {
        fprintf (stderr, "listFree (0x%08x)\n", (uint)p);
        free (p);
}

int listSum (Cons c) {
        int res;

        fprintf (stderr, "listSum\n");
        res = 0;
        for (; c != NULL; c = c-&gt;next)
                res += c-&gt;value;
        return res;
}</programlisting>
<simpara>We can compile these to create an executable with</simpara>
<screen>% mlton -default-ann 'allowFFI true' finalizable.sml cons.c</screen>
<simpara>Running this executable will create output like the following.</simpara>
<screen>% finalizable
0x08072890 = listSing (2)
0x080728a0 = listCons (2)
0x080728b0 = listCons (2)
0x080728c0 = listCons (2)
0x080728d0 = listCons (2)
0x080728e0 = listCons (2)
0x080728f0 = listCons (2)
listSum
listSum(l) = 14
listFree (0x080728f0)
listFree (0x080728e0)
listFree (0x080728d0)
listFree (0x080728c0)
listFree (0x080728b0)
listFree (0x080728a0)
listFree (0x08072890)</screen>
</section>
<section id="_synchronous_finalizers">
<title>Synchronous Finalizers</title>
<simpara>Finalizers in MLton are asynchronous.  That is, they run at an
unspecified time, interrupting the user program.  It is also possible,
and sometimes useful, to have synchronous finalizers, where the user
program explicitly decides when to run enabled finalizers.  We have
considered this in MLton, and it seems possible, but there are some
unresolved design issues.  See the thread at</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-September/016570.html">http://www.mlton.org/pipermail/mlton/2004-September/016570.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_16">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Boehm03">Boehm03</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonGC">
<title>MLtonGC</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_GC =
   sig
      val collect: unit -&gt; unit
      val pack: unit -&gt; unit
      val setMessages: bool -&gt; unit
      val setSummary: bool -&gt; unit
      val unpack: unit -&gt; unit
      structure Statistics :
         sig
            val bytesAllocated: unit -&gt; IntInf.int
            val lastBytesLive: unit -&gt; IntInf.int
            val numCopyingGCs: unit -&gt; IntInf.int
            val numMarkCompactGCs: unit -&gt; IntInf.int
            val numMinorGCs: unit -&gt; IntInf.int
            val maxBytesLive: unit -&gt; IntInf.int
         end
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>collect ()</literal>
</simpara>
<simpara>causes a garbage collection to occur.</simpara>
</listitem>
<listitem>
<simpara>
<literal>pack ()</literal>
</simpara>
<simpara>shrinks the heap as much as possible so that other processes can use
available RAM.</simpara>
</listitem>
<listitem>
<simpara>
<literal>setMessages b</literal>
</simpara>
<simpara>controls whether diagnostic messages are printed at the beginning and
end of each garbage collection.  It is the same as the <literal>gc-messages</literal>
runtime system option.</simpara>
</listitem>
<listitem>
<simpara>
<literal>setSummary b</literal>
</simpara>
<simpara>controls whether a summary of garbage collection statistics is printed
upon termination of the program.  It is the same as the <literal>gc-summary</literal>
runtime system option.</simpara>
</listitem>
<listitem>
<simpara>
<literal>unpack ()</literal>
</simpara>
<simpara>resizes a packed heap to the size desired by the runtime.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Statistics.bytesAllocated ()</literal>
</simpara>
<simpara>returns bytes allocated (as of the most recent garbage collection).</simpara>
</listitem>
<listitem>
<simpara>
<literal>Statistics.lastBytesLive ()</literal>
</simpara>
<simpara>returns bytes live (as of the most recent garbage collection).</simpara>
</listitem>
<listitem>
<simpara>
<literal>Statistics.numCopyingGCs ()</literal>
</simpara>
<simpara>returns number of (major) copying garbage collections performed (as of
the most recent garbage collection).</simpara>
</listitem>
<listitem>
<simpara>
<literal>Statistics.numMarkCompactGCs ()</literal>
</simpara>
<simpara>returns number of (major) mark-compact garbage collections performed
(as of the most recent garbage collection).</simpara>
</listitem>
<listitem>
<simpara>
<literal>Statistics.numMinorGCs ()</literal>
</simpara>
<simpara>returns number of minor garbage collections performed (as of the most
recent garbage collection).</simpara>
</listitem>
<listitem>
<simpara>
<literal>Statistics.maxBytesLive ()</literal>
</simpara>
<simpara>returns maximum bytes live (as of the most recent garbage collection).</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonIntInf">
<title>MLtonIntInf</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_INT_INF =
   sig
      type t = IntInf.int

      val areSmall: t * t -&gt; bool
      val gcd: t * t -&gt; t
      val isSmall: t -&gt; bool

      structure BigWord : WORD
      structure SmallInt : INTEGER
      datatype rep =
         Big of BigWord.word vector
       | Small of SmallInt.int
      val rep: t -&gt; rep
      val fromRep : rep -&gt; t option
   end</programlisting>
<simpara>MLton represents an arbitrary precision integer either as an unboxed
word with the bottom bit set to 1 and the top bits representing a
small signed integer, or as a pointer to a vector of words, where the
first word indicates the sign and the rest are the limbs of a
<link linkend="GnuMP">GnuMP</link> big integer.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>the same as type <literal>IntInf.int</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>areSmall (a, b)</literal>
</simpara>
<simpara>returns true iff both <literal>a</literal> and <literal>b</literal> are small.</simpara>
</listitem>
<listitem>
<simpara>
<literal>gcd (a, b)</literal>
</simpara>
<simpara>uses the <link linkend="GnuMP">GnuMP&#8217;s</link> fast gcd implementation.</simpara>
</listitem>
<listitem>
<simpara>
<literal>isSmall a</literal>
</simpara>
<simpara>returns true iff <literal>a</literal> is small.</simpara>
</listitem>
<listitem>
<simpara>
<literal>BigWord : WORD</literal>
</simpara>
<simpara>representation of a big <literal>IntInf.int</literal> as a vector of words; on 32-bit
platforms, <literal>BigWord</literal> is likely to be equivalent to <literal>Word32</literal>, and on
64-bit platforms, <literal>BigWord</literal> is likely to be equivalent to <literal>Word64</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>SmallInt : INTEGER</literal>
</simpara>
<simpara>representation of a small <literal>IntInf.int</literal> as a signed integer; on 32-bit
platforms, <literal>SmallInt</literal> is likely to be equivalent to <literal>Int32</literal>, and on
64-bit platforms, <literal>SmallInt</literal> is likely to be equivalent to <literal>Int64</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>datatype rep</literal>
</simpara>
<simpara>the underlying representation of an <literal>IntInf.int</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>rep i</literal>
</simpara>
<simpara>returns the underlying representation of <literal>i</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>fromRep r</literal>
</simpara>
<simpara>converts from the underlying representation back to an <literal>IntInf.int</literal>.
If <literal>fromRep r</literal> is given anything besides the valid result of <literal>rep i</literal>
for some <literal>i</literal>, this function call will return <literal>NONE</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonIO">
<title>MLtonIO</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_IO =
   sig
      type instream
      type outstream

      val inFd: instream -&gt; Posix.IO.file_desc
      val mkstemp: string -&gt; string * outstream
      val mkstemps: {prefix: string, suffix: string} -&gt; string * outstream
      val newIn: Posix.IO.file_desc * string -&gt; instream
      val newOut: Posix.IO.file_desc * string -&gt; outstream
      val outFd: outstream -&gt; Posix.IO.file_desc
      val tempPrefix: string -&gt; string
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>inFd ins</literal>
</simpara>
<simpara>returns the file descriptor corresponding to <literal>ins</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>mkstemp s</literal>
</simpara>
<simpara>like the C <literal>mkstemp</literal> function, generates and open a temporary file
with prefix <literal>s</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>mkstemps {prefix, suffix}</literal>
</simpara>
<simpara>like <literal>mkstemp</literal>, except it has both a prefix and suffix.</simpara>
</listitem>
<listitem>
<simpara>
<literal>newIn (fd, name)</literal>
</simpara>
<simpara>creates a new instream from file descriptor <literal>fd</literal>, with <literal>name</literal> used in
any <literal>Io</literal> exceptions later raised.</simpara>
</listitem>
<listitem>
<simpara>
<literal>newOut (fd, name)</literal>
</simpara>
<simpara>creates a new outstream from file descriptor <literal>fd</literal>, with <literal>name</literal> used in
any <literal>Io</literal> exceptions later raised.</simpara>
</listitem>
<listitem>
<simpara>
<literal>outFd out</literal>
</simpara>
<simpara>returns the file descriptor corresponding to <literal>out</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>tempPrefix s</literal>
</simpara>
<simpara>adds a suitable system or user specific prefix (directory) for temp
files.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonItimer">
<title>MLtonItimer</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_ITIMER =
   sig
      datatype t =
         Prof
       | Real
       | Virtual

      val set: t * {interval: Time.time, value: Time.time} -&gt; unit
      val signal: t -&gt; Posix.Signal.signal
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>set (t, {interval, value})</literal>
</simpara>
<simpara>sets the interval timer (using <literal>setitimer</literal>) specified by <literal>t</literal> to the
given <literal>interval</literal> and <literal>value</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>signal t</literal>
</simpara>
<simpara>returns the signal corresponding to <literal>t</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonLibraryProject">
<title>MLtonLibraryProject</title>
<simpara>We have a <ulink url="https://github.com/MLton/mltonlib">MLton Library repository</ulink>
that is intended to collect libraries.</simpara>
<informalexample>
<literallayout class="monospaced">https://github.com/MLton/mltonlib</literallayout>
</informalexample>
<simpara>Libraries are kept in the <literal>master</literal> branch, and are grouped according
to domain name, in the Java package style.  For example,
<link linkend="VesaKarvonen">VesaKarvonen</link>, who works at <literal>ssh.com</literal>, has been putting code at:</simpara>
<informalexample>
<literallayout class="monospaced">https://github.com/MLton/mltonlib/tree/master/com/ssh</literallayout>
</informalexample>
<simpara><link linkend="StephenWeeks">StephenWeeks</link>, owning <literal>sweeks.com</literal>, has been putting code at:</simpara>
<informalexample>
<literallayout class="monospaced">https://github.com/MLton/mltonlib/tree/master/com/sweeks</literallayout>
</informalexample>
<simpara>A "library" is a subdirectory of some such directory.  For example,
Stephen&#8217;s basis-library replacement library is at</simpara>
<informalexample>
<literallayout class="monospaced">https://github.com/MLton/mltonlib/tree/master/com/sweeks/basic</literallayout>
</informalexample>
<simpara>We use "transparent per-library branching" to handle library
versioning.  Each library has an "unstable" subdirectory in which work
happens.  When one is happy with a library, one tags it by copying it
to a stable version directory.  Stable libraries are immutable&#8201;&#8212;&#8201;when
one refers to a stable library, one always gets exactly the same code.
No one has actually made a stable library yet, but, when I&#8217;m ready to
tag my library, I was thinking that I would do something like copying</simpara>
<informalexample>
<literallayout class="monospaced">https://github.com/MLton/mltonlib/tree/master/com/sweeks/basic/unstable</literallayout>
</informalexample>
<simpara>to</simpara>
<informalexample>
<literallayout class="monospaced">https://github.com/MLton/mltonlib/tree/master/com/sweeks/basic/v1</literallayout>
</informalexample>
<simpara>So far, libraries in the MLton repository have been licensed under
MLton&#8217;s <link linkend="License">License</link>.  We haven&#8217;t decided on whether that will be a
requirement to be in the repository or not.  For the sake of
simplicity (a single license) and encouraging widest use of code,
contributors are encouraged to use that license.  But it may be too
strict to require it.</simpara>
<simpara>If someone wants to contribute a new library to our repository or to
work on an old one, they can make a pull request.  If people want to
work in their own repository, they can do so&#8201;&#8212;&#8201;that&#8217;s the point of
using domain names to prevent clashes.  The idea is that a user should
be able to bring library collections in from many different
repositories without problems.  And those libraries could even work
with each other.</simpara>
<simpara>At some point we may want to settle on an <link linkend="MLBasisPathMap">MLBasisPathMap</link> variable
for the root of the library project.  Or, we could reuse <literal>SML_LIB</literal>,
and migrate what we currently keep there into the library
infrastructure.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonMonoArray">
<title>MLtonMonoArray</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_MONO_ARRAY =
   sig
      type t
      type elem
      val fromPoly: elem array -&gt; t
      val toPoly: t -&gt; elem array
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>type of monomorphic array</simpara>
</listitem>
<listitem>
<simpara>
<literal>type elem</literal>
</simpara>
<simpara>type of array elements</simpara>
</listitem>
<listitem>
<simpara>
<literal>fromPoly a</literal>
</simpara>
<simpara>type cast a polymorphic array to its monomorphic counterpart; the
argument and result arrays share the same identity</simpara>
</listitem>
<listitem>
<simpara>
<literal>toPoly a</literal>
</simpara>
<simpara>type cast a monomorphic array to its polymorphic counterpart; the
argument and result arrays share the same identity</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonMonoVector">
<title>MLtonMonoVector</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_MONO_VECTOR =
   sig
      type t
      type elem
      val fromPoly: elem vector -&gt; t
      val toPoly: t -&gt; elem vector
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>type of monomorphic vector</simpara>
</listitem>
<listitem>
<simpara>
<literal>type elem</literal>
</simpara>
<simpara>type of vector elements</simpara>
</listitem>
<listitem>
<simpara>
<literal>fromPoly v</literal>
</simpara>
<simpara>type cast a polymorphic vector to its monomorphic counterpart; in
MLton, this is a constant-time operation</simpara>
</listitem>
<listitem>
<simpara>
<literal>toPoly v</literal>
</simpara>
<simpara>type cast a monomorphic vector to its polymorphic counterpart; in
MLton, this is a constant-time operation</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonPlatform">
<title>MLtonPlatform</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_PLATFORM =
   sig
      structure Arch:
         sig
            datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | m68k
                       | MIPS | PowerPC | PowerPC64 | S390 | Sparc | X86

            val fromString: string -&gt; t option
            val host: t
            val toString: t -&gt; string
         end

      structure OS:
         sig
            datatype t = AIX | Cygwin | Darwin | FreeBSD | Hurd | HPUX
                       | Linux | MinGW | NetBSD | OpenBSD | Solaris

            val fromString: string -&gt; t option
            val host: t
            val toString: t -&gt; string
         end
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>datatype Arch.t</literal>
</simpara>
<simpara>processor architectures</simpara>
</listitem>
<listitem>
<simpara>
<literal>Arch.fromString a</literal>
</simpara>
<simpara>converts from string to architecture.  Case insensitive.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Arch.host</literal>
</simpara>
<simpara>the architecture for which the program is compiled.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Arch.toString</literal>
</simpara>
<simpara>string for architecture.</simpara>
</listitem>
<listitem>
<simpara>
<literal>datatype OS.t</literal>
</simpara>
<simpara>operating systems</simpara>
</listitem>
<listitem>
<simpara>
<literal>OS.fromString</literal>
</simpara>
<simpara>converts from string to operating system.  Case insensitive.</simpara>
</listitem>
<listitem>
<simpara>
<literal>OS.host</literal>
</simpara>
<simpara>the operating system for which the program is compiled.</simpara>
</listitem>
<listitem>
<simpara>
<literal>OS.toString</literal>
</simpara>
<simpara>string for operating system.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonPointer">
<title>MLtonPointer</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_POINTER =
   sig
      eqtype t

      val add: t * word -&gt; t
      val compare: t * t -&gt; order
      val diff: t * t -&gt; word
      val getInt8: t * int -&gt; Int8.int
      val getInt16: t * int -&gt; Int16.int
      val getInt32: t * int -&gt; Int32.int
      val getInt64: t * int -&gt; Int64.int
      val getPointer: t * int -&gt; t
      val getReal32: t * int -&gt; Real32.real
      val getReal64: t * int -&gt; Real64.real
      val getWord8: t * int -&gt; Word8.word
      val getWord16: t * int -&gt; Word16.word
      val getWord32: t * int -&gt; Word32.word
      val getWord64: t * int -&gt; Word64.word
      val null: t
      val setInt8: t * int * Int8.int -&gt; unit
      val setInt16: t * int * Int16.int -&gt; unit
      val setInt32: t * int * Int32.int -&gt; unit
      val setInt64: t * int * Int64.int -&gt; unit
      val setPointer: t * int * t -&gt; unit
      val setReal32: t * int * Real32.real -&gt; unit
      val setReal64: t * int * Real64.real -&gt; unit
      val setWord8: t * int * Word8.word -&gt; unit
      val setWord16: t * int * Word16.word -&gt; unit
      val setWord32: t * int * Word32.word -&gt; unit
      val setWord64: t * int * Word64.word -&gt; unit
      val sizeofPointer: word
      val sub: t * word -&gt; t
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>eqtype t</literal>
</simpara>
<simpara>the type of pointers, i.e. machine addresses.</simpara>
</listitem>
<listitem>
<simpara>
<literal>add (p, w)</literal>
</simpara>
<simpara>returns the pointer <literal>w</literal> bytes after than <literal>p</literal>.  Does not check for
overflow.</simpara>
</listitem>
<listitem>
<simpara>
<literal>compare (p1, p2)</literal>
</simpara>
<simpara>compares the pointer <literal>p1</literal> to the pointer <literal>p2</literal> (as addresses).</simpara>
</listitem>
<listitem>
<simpara>
<literal>diff (p1, p2)</literal>
</simpara>
<simpara>returns the number of bytes <literal>w</literal> such that <literal>add (p2, w) = p1</literal>.  Does
not check for overflow.</simpara>
</listitem>
<listitem>
<simpara>
<literal>get<emphasis>&lt;X&gt;</emphasis> (p, i)</literal>
</simpara>
<simpara>returns the object stored at index i of the array of <emphasis>X</emphasis> objects
pointed to by <literal>p</literal>.  For example, <literal>getWord32 (p, 7)</literal> returns the 32-bit
word stored 28 bytes beyond <literal>p</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>null</literal>
</simpara>
<simpara>the null pointer, i.e. 0.</simpara>
</listitem>
<listitem>
<simpara>
<literal>set<emphasis>&lt;X&gt;</emphasis> (p, i, v)</literal>
</simpara>
<simpara>assigns <literal>v</literal> to the object stored at index i of the array of <emphasis>X</emphasis>
objects pointed to by <literal>p</literal>.  For example, <literal>setWord32 (p, 7, w)</literal> stores
the 32-bit word <literal>w</literal> at the address 28 bytes beyond <literal>p</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>sizeofPointer</literal>
</simpara>
<simpara>size, in bytes, of a pointer.</simpara>
</listitem>
<listitem>
<simpara>
<literal>sub (p, w)</literal>
</simpara>
<simpara>returns the pointer <literal>w</literal> bytes before <literal>p</literal>.  Does not check for
overflow.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonProcEnv">
<title>MLtonProcEnv</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_PROC_ENV =
   sig
      type gid

      val setenv: {name: string, value: string} -&gt; unit
      val setgroups: gid list -&gt; unit
  end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>setenv {name, value}</literal>
</simpara>
<simpara>like the C <literal>setenv</literal> function.  Does not require <literal>name</literal> or <literal>value</literal> to
be null terminated.</simpara>
</listitem>
<listitem>
<simpara>
<literal>setgroups grps</literal>
</simpara>
<simpara>like the C <literal>setgroups</literal> function.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonProcess">
<title>MLtonProcess</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_PROCESS =
   sig
      type pid

      val spawn: {args: string list, path: string} -&gt; pid
      val spawne: {args: string list, env: string list, path: string} -&gt; pid
      val spawnp: {args: string list, file: string} -&gt; pid

      type ('stdin, 'stdout, 'stderr) t

      type input
      type output

      type none
      type chain
      type any

      exception MisuseOfForget
      exception DoublyRedirected

      structure Child:
        sig
          type ('use, 'dir) t

          val binIn: (BinIO.instream, input) t -&gt; BinIO.instream
          val binOut: (BinIO.outstream, output) t -&gt; BinIO.outstream
          val fd: (Posix.FileSys.file_desc, 'dir) t -&gt; Posix.FileSys.file_desc
          val remember: (any, 'dir) t -&gt; ('use, 'dir) t
          val textIn: (TextIO.instream, input) t -&gt; TextIO.instream
          val textOut: (TextIO.outstream, output) t -&gt; TextIO.outstream
        end

      structure Param:
        sig
          type ('use, 'dir) t

          val child: (chain, 'dir) Child.t -&gt; (none, 'dir) t
          val fd: Posix.FileSys.file_desc -&gt; (none, 'dir) t
          val file: string -&gt; (none, 'dir) t
          val forget: ('use, 'dir) t -&gt; (any, 'dir) t
          val null: (none, 'dir) t
          val pipe: ('use, 'dir) t
          val self: (none, 'dir) t
        end

      val create:
         {args: string list,
          env: string list option,
          path: string,
          stderr: ('stderr, output) Param.t,
          stdin: ('stdin, input) Param.t,
          stdout: ('stdout, output) Param.t}
         -&gt; ('stdin, 'stdout, 'stderr) t
      val getStderr: ('stdin, 'stdout, 'stderr) t -&gt; ('stderr, input) Child.t
      val getStdin:  ('stdin, 'stdout, 'stderr) t -&gt; ('stdin, output) Child.t
      val getStdout: ('stdin, 'stdout, 'stderr) t -&gt; ('stdout, input) Child.t
      val kill: ('stdin, 'stdout, 'stderr) t * Posix.Signal.signal -&gt; unit
      val reap: ('stdin, 'stdout, 'stderr) t -&gt; Posix.Process.exit_status
   end</programlisting>
<section id="_spawn">
<title>Spawn</title>
<simpara>The <literal>spawn</literal> functions provide an alternative to the
<literal>fork</literal>/<literal>exec</literal> idiom that is typically used to create a new
process.  On most platforms, the <literal>spawn</literal> functions are simple
wrappers around <literal>fork</literal>/<literal>exec</literal>.  However, under Windows, the
<literal>spawn</literal> functions are primitive.  All <literal>spawn</literal> functions return
the process id of the spawned process.  They differ in how the
executable is found and the environment that it uses.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>spawn {args, path}</literal>
</simpara>
<simpara>starts a new process running the executable specified by <literal>path</literal>
with the arguments <literal>args</literal>.  Like <literal>Posix.Process.exec</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>spawne {args, env, path}</literal>
</simpara>
<simpara>starts a new process running the executable specified by <literal>path</literal> with
the arguments <literal>args</literal> and environment <literal>env</literal>.  Like
<literal>Posix.Process.exece</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>spawnp {args, file}</literal>
</simpara>
<simpara>search the <literal>PATH</literal> environment variable for an executable named <literal>file</literal>,
and start a new process running that executable with the arguments
<literal>args</literal>.  Like <literal>Posix.Process.execp</literal>.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_create">
<title>Create</title>
<simpara><literal>MLton.Process.create</literal> provides functionality similar to
<literal>Unix.executeInEnv</literal>, but provides more control control over the input,
output, and error streams.  In addition, <literal>create</literal> works on all
platforms, including Cygwin and MinGW (Windows) where <literal>Posix.fork</literal> is
unavailable.  For greatest portability programs should still use the
standard <literal>Unix.execute</literal>, <literal>Unix.executeInEnv</literal>, and <literal>OS.Process.system</literal>.</simpara>
<simpara>The following types and sub-structures are used by the <literal>create</literal>
function.  They provide static type checking of correct stream usage.</simpara>
<section id="_child">
<title>Child</title>
<itemizedlist>
<listitem>
<simpara>
<literal>('use, 'dir) Child.t</literal>
</simpara>
<simpara>This represents a handle to one of a child&#8217;s standard streams. The
<literal>'dir</literal> is viewed with respect to the parent. Thus a <literal>('a, input)
Child.t</literal> handle means that the parent may input the output from the
child.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Child.{bin,text}{In,Out} h</literal>
</simpara>
<simpara>These functions take a handle and bind it to a stream of the named
type.  The type system will detect attempts to reverse the direction
of a stream or to use the same stream in multiple, incompatible ways.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Child.fd h</literal>
</simpara>
<simpara>This function behaves like the other <literal>Child.*</literal> functions; it opens a
stream. However, it does not enforce that you read or write from the
handle. If you use the descriptor in an inappropriate direction, the
behavior is undefined. Furthermore, this function may potentially be
unavailable on future MLton host platforms.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Child.remember h</literal>
</simpara>
<simpara>This function takes a stream of use <literal>any</literal> and resets the use of the
stream so that the stream may be used by <literal>Child.*</literal>. An <literal>any</literal> stream
may have had use <literal>none</literal> or <literal>'use</literal> prior to calling <literal>Param.forget</literal>. If
the stream was <literal>none</literal> and is used, <literal>MisuseOfForget</literal> is raised.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_param">
<title>Param</title>
<itemizedlist>
<listitem>
<simpara>
<literal>('use, 'dir) Param.t</literal>
</simpara>
<simpara>This is a handle to an input/output source and will be passed to the
created child process. The <literal>'dir</literal> is relative to the child process.
Input means that the child process will read from this stream.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.child h</literal>
</simpara>
<simpara>Connect the stream of the new child process to the stream of a
previously created child process. A single child stream should be
connected to only one child process or else <literal>DoublyRedirected</literal> will be
raised.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.fd fd</literal>
</simpara>
<simpara>This creates a stream from the provided file descriptor which will be
closed when <literal>create</literal> is called. This function may not be available on
future MLton host platforms.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.forget h</literal>
</simpara>
<simpara>This hides the type of the actual parameter as <literal>any</literal>. This is useful
if you are implementing an application which conditionally attaches
the child process to files or pipes. However, you must ensure that
your use after <literal>Child.remember</literal> matches the original type.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.file s</literal>
</simpara>
<simpara>Open the given file and connect it to the child process. Note that the
file will be opened only when <literal>create</literal> is called. So any exceptions
will be raised there and not by this function. If used for <literal>input</literal>,
the file is opened read-only. If used for <literal>output</literal>, the file is opened
read-write.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.null</literal>
</simpara>
<simpara>In some situations, the child process should have its output
discarded.  The <literal>null</literal> param when passed as <literal>stdout</literal> or <literal>stderr</literal> does
this.  When used for <literal>stdin</literal>, the child process will either receive
<literal>EOF</literal> or a failure condition if it attempts to read from <literal>stdin</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.pipe</literal>
</simpara>
<simpara>This will connect the input/output of the child process to a pipe
which the parent process holds. This may later form the input to one
of the <literal>Child.*</literal> functions and/or the <literal>Param.child</literal> function.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Param.self</literal>
</simpara>
<simpara>This will connect the input/output of the child process to the
corresponding stream of the parent process.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_process">
<title>Process</title>
<itemizedlist>
<listitem>
<simpara>
<literal>type ('stdin, 'stdout, 'stderr) t</literal>
</simpara>
<simpara>represents a handle to a child process.  The type arguments capture
how the named stream of the child process may be used.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type any</literal>
</simpara>
<simpara>bypasses the type system in situations where an application does not
want the it to enforce correct usage.  See <literal>Child.remember</literal> and
<literal>Param.forget</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type chain</literal>
</simpara>
<simpara>means that the child process&#8217;s stream was connected via a pipe to the
parent process. The parent process may pass this pipe in turn to
another child, thus chaining them together.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type input, output</literal>
</simpara>
<simpara>record the direction that a stream flows.  They are used as a part of
<literal>Param.t</literal> and <literal>Child.t</literal> and is detailed there.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type none</literal>
</simpara>
<simpara>means that the child process&#8217;s stream my not be used by the parent
process.  This happens when the child process is connected directly to
some source.</simpara>
<simpara>The types <literal>BinIO.instream</literal>, <literal>BinIO.outstream</literal>, <literal>TextIO.instream</literal>,
<literal>TextIO.outstream</literal>, and <literal>Posix.FileSys.file_desc</literal> are also valid types
with which to instantiate child streams.</simpara>
</listitem>
<listitem>
<simpara>
<literal>exception MisuseOfForget</literal>
</simpara>
<simpara>may be raised if <literal>Child.remember</literal> and <literal>Param.forget</literal> are used to
bypass the normal type checking.  This exception will only be raised
in cases where the <literal>forget</literal> mechanism allows a misuse that would be
impossible with the type-safe versions.</simpara>
</listitem>
<listitem>
<simpara>
<literal>exception DoublyRedirected</literal>
</simpara>
<simpara>raised if a stream connected to a child process is redirected to two
separate child processes.  It is safe, though bad style, to use the a
<literal>Child.t</literal> with the same <literal>Child.*</literal> function repeatedly.</simpara>
</listitem>
<listitem>
<simpara>
<literal>create {args, path, env, stderr, stdin, stdout}</literal>
</simpara>
<simpara>starts a child process with the given command-line <literal>args</literal> (excluding
the program name). <literal>path</literal> should be an absolute path to the executable
run in the new child process; relative paths work, but are less
robust.  Optionally, the environment may be overridden with <literal>env</literal>
where each string element has the form <literal>"key=value"</literal>. The <literal>std*</literal>
options must be provided by the <literal>Param.*</literal> functions documented above.</simpara>
<simpara>Processes which are <literal>create</literal>-d must be either <literal>reap</literal>-ed or <literal>kill</literal>-ed.</simpara>
</listitem>
<listitem>
<simpara>
<literal>getStd{in,out,err} proc</literal>
</simpara>
<simpara>gets a handle to the specified stream. These should be used by the
<literal>Child.*</literal> functions. Failure to use a stream connected via pipe to a
child process may result in runtime dead-lock and elicits a compiler
warning.</simpara>
</listitem>
<listitem>
<simpara>
<literal>kill (proc, sig)</literal>
</simpara>
<simpara>terminates the child process immediately.  The signal may or may not
mean anything depending on the host platform.  A good value is
<literal>Posix.Signal.term</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>reap proc</literal>
</simpara>
<simpara>waits for the child process to terminate and return its exit status.</simpara>
</listitem>
</itemizedlist>
</section>
</section>
<section id="_important_usage_notes">
<title>Important usage notes</title>
<simpara>When building an application with many pipes between child processes,
it is important to ensure that there are no cycles in the undirected
pipe graph.  If this property is not maintained, deadlocks are a very
serious potential bug which may only appear under difficult to
reproduce conditions.</simpara>
<simpara>The danger lies in that most operating systems implement pipes with a
fixed buffer size. If process A has two output pipes which process B
reads, it can happen that process A blocks writing to pipe 2 because
it is full while process B blocks reading from pipe 1 because it is
empty. This same situation can happen with any undirected cycle formed
between processes (vertexes) and pipes (undirected edges) in the
graph.</simpara>
<simpara>It is possible to make this safe using low-level I/O primitives for
polling.  However, these primitives are not very portable and
difficult to use properly.  A far better approach is to make sure you
never create a cycle in the first place.</simpara>
<simpara>For these reasons, the <literal>Unix.executeInEnv</literal> is a very dangerous
function. Be careful when using it to ensure that the child process
only operates on either <literal>stdin</literal> or <literal>stdout</literal>, but not both.</simpara>
</section>
<section id="_example_use_of_mlton_process_create">
<title>Example use of MLton.Process.create</title>
<simpara>The following example program launches the <literal>ipconfig</literal> utility, pipes
its output through <literal>grep</literal>, and then reads the result back into the
program.</simpara>
<programlisting language="sml" linenumbering="unnumbered">open MLton.Process
val p =
        create {args = [ "/all" ],
                env = NONE,
                path = "C:\\WINDOWS\\system32\\ipconfig.exe",
                stderr = Param.self,
                stdin = Param.null,
                stdout = Param.pipe}
val q =
        create {args = [ "IP-Ad" ],
                env = NONE,
                path = "C:\\msys\\bin\\grep.exe",
                stderr = Param.self,
                stdin = Param.child (getStdout p),
                stdout = Param.pipe}
fun suck h =
        case TextIO.inputLine h of
                NONE =&gt; ()
                | SOME s =&gt; (print ("'" ^ s ^ "'\n"); suck h)

val () = suck (Child.textIn (getStdout q))</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonProfile">
<title>MLtonProfile</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_PROFILE =
   sig
      structure Data:
         sig
            type t

            val equals: t * t -&gt; bool
            val free: t -&gt; unit
            val malloc: unit -&gt; t
            val write: t * string -&gt; unit
         end

      val isOn: bool
      val withData: Data.t * (unit -&gt; 'a) -&gt; 'a
   end</programlisting>
<simpara><literal>MLton.Profile</literal> provides <link linkend="Profiling">Profiling</link> control from within the
program, allowing you to profile individual portions of your
program. With <literal>MLton.Profile</literal>, you can create many units of profiling
data (essentially, mappings from functions to counts) during a run of
a program, switch between them while the program is running, and
output multiple <literal>mlmon.out</literal> files.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>isOn</literal>
</simpara>
<simpara>a compile-time constant that is false only when compiling <literal>-profile no</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type Data.t</literal>
</simpara>
<simpara>the type of a unit of profiling data.  In order to most efficiently
execute non-profiled programs, when compiling <literal>-profile no</literal> (the
default), <literal>Data.t</literal> is equivalent to <literal>unit ref</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Data.equals (x, y)</literal>
</simpara>
<simpara>returns true if the <literal>x</literal> and <literal>y</literal> are the same unit of profiling data.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Data.free x</literal>
</simpara>
<simpara>frees the memory associated with the unit of profiling data <literal>x</literal>.  It
is an error to free the current unit of profiling data or to free a
previously freed unit of profiling data.  When compiling
<literal>-profile no</literal>, <literal>Data.free x</literal> is a no-op.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Data.malloc ()</literal>
</simpara>
<simpara>returns a new unit of profiling data.  Each unit of profiling data is
allocated from the process address space (but is <emphasis>not</emphasis> in the MLton
heap) and consumes memory proportional to the number of source
functions.  When compiling <literal>-profile no</literal>, <literal>Data.malloc ()</literal> is
equivalent to allocating a new <literal>unit ref</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>write (x, f)</literal>
</simpara>
<simpara>writes the accumulated ticks in the unit of profiling data <literal>x</literal> to file
<literal>f</literal>.  It is an error to write a previously freed unit of profiling
data.  When compiling <literal>-profile no</literal>, <literal>write (x, f)</literal> is a no-op.  A
profiled program will always write the current unit of profiling data
at program exit to a file named <literal>mlmon.out</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>withData (d, f)</literal>
</simpara>
<simpara>runs <literal>f</literal> with <literal>d</literal> as the unit of profiling data, and returns the
result of <literal>f</literal> after restoring the current unit of profiling data.
When compiling <literal>-profile no</literal>, <literal>withData (d, f)</literal> is equivalent to
<literal>f ()</literal>.</simpara>
</listitem>
</itemizedlist>
<section id="_example_5">
<title>Example</title>
<simpara>Here is an example, taken from the <literal>examples/profiling</literal> directory,
showing how to profile the executions of the <literal>fib</literal> and <literal>tak</literal> functions
separately.  Suppose that <literal>fib-tak.sml</literal> contains the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Profile = MLton.Profile

val fibData = Profile.Data.malloc ()
val takData = Profile.Data.malloc ()

fun wrap (f, d) x =
   Profile.withData (d, fn () =&gt; f x)

val rec fib =
   fn 0 =&gt; 0
    | 1 =&gt; 1
    | n =&gt; fib (n - 1) + fib (n - 2)
val fib = wrap (fib, fibData)

fun tak (x,y,z) =
   if not (y &lt; x)
      then z
   else tak (tak (x - 1, y, z),
             tak (y - 1, z, x),
             tak (z - 1, x, y))
val tak = wrap (tak, takData)

val rec f =
   fn 0 =&gt; ()
    | n =&gt; (fib 38; f (n-1))
val _ = f 2

val rec g =
   fn 0 =&gt; ()
    | n =&gt; (tak (18,12,6); g (n-1))
val _ = g 500

fun done (data, file) =
   (Profile.Data.write (data, file)
    ; Profile.Data.free data)

val _ = done (fibData, "mlmon.fib.out")
val _ = done (takData, "mlmon.tak.out")</programlisting>
<simpara>Compile and run the program.</simpara>
<screen>% mlton -profile time fib-tak.sml
% ./fib-tak</screen>
<simpara>Separately display the profiling data for <literal>fib</literal></simpara>
<screen>% mlprof fib-tak mlmon.fib.out
5.77 seconds of CPU time (0.00 seconds GC)
function   cur
--------- -----
fib       96.9%
&lt;unknown&gt;  3.1%</screen>
<simpara>and for <literal>tak</literal></simpara>
<screen>% mlprof fib-tak mlmon.tak.out
0.68 seconds of CPU time (0.00 seconds GC)
function  cur
-------- ------
tak      100.0%</screen>
<simpara>Combine the data for <literal>fib</literal> and <literal>tak</literal> by calling <literal>mlprof</literal>
with multiple <literal>mlmon.out</literal> files.</simpara>
<screen>% mlprof fib-tak mlmon.fib.out mlmon.tak.out mlmon.out
6.45 seconds of CPU time (0.00 seconds GC)
function   cur
--------- -----
fib       86.7%
tak       10.5%
&lt;unknown&gt;  2.8%</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonRandom">
<title>MLtonRandom</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_RANDOM =
   sig
      val alphaNumChar: unit -&gt; char
      val alphaNumString: int -&gt; string
      val rand: unit -&gt; word
      val seed: unit -&gt; word option
      val srand: word -&gt; unit
      val useed: unit -&gt; word option
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>alphaNumChar ()</literal>
</simpara>
<simpara>returns a random alphanumeric character.</simpara>
</listitem>
<listitem>
<simpara>
<literal>alphaNumString n</literal>
</simpara>
<simpara>returns a string of length <literal>n</literal> of random alphanumeric characters.</simpara>
</listitem>
<listitem>
<simpara>
<literal>rand ()</literal>
</simpara>
<simpara>returns the next pseudo-random number.</simpara>
</listitem>
<listitem>
<simpara>
<literal>seed ()</literal>
</simpara>
<simpara>returns a random word from <literal>/dev/random</literal>.  Useful as an arg to
<literal>srand</literal>.  If <literal>/dev/random</literal> can not be read from, <literal>seed ()</literal> returns
<literal>NONE</literal>.  A call to <literal>seed</literal> may block until enough random bits are
available.</simpara>
</listitem>
<listitem>
<simpara>
<literal>srand w</literal>
</simpara>
<simpara>sets the seed used by <literal>rand</literal> to <literal>w</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>useed ()</literal>
</simpara>
<simpara>returns a random word from <literal>/dev/urandom</literal>.  Useful as an arg to
<literal>srand</literal>.  If <literal>/dev/urandom</literal> can not be read from, <literal>useed ()</literal> returns
<literal>NONE</literal>.  A call to <literal>useed</literal> will never block&#8201;&#8212;&#8201;it will instead return
lower quality random bits.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonReal">
<title>MLtonReal</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_REAL =
   sig
      type t

      val fromWord: word -&gt; t
      val fromLargeWord: LargeWord.word -&gt; t
      val toWord: IEEEReal.rounding_mode -&gt; t -&gt; word
      val toLargeWord: IEEEReal.rounding_mode -&gt; t -&gt; LargeWord.word
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>the type of reals.  For <literal>MLton.LargeReal</literal> this is <literal>LargeReal.real</literal>,
for <literal>MLton.Real</literal> this is <literal>Real.real</literal>, for <literal>MLton.Real32</literal> this is
<literal>Real32.real</literal>, for <literal>MLton.Real64</literal> this is <literal>Real64.real</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>fromWord w</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>fromLargeWord w</literal>
</simpara>
<simpara>convert the word <literal>w</literal> to a real value.  If the value of <literal>w</literal> is larger
than (the appropriate) <literal>REAL.maxFinite</literal>, then infinity is returned.
If <literal>w</literal> cannot be exactly represented as a real value, then the current
rounding mode is used to determine the resulting value.</simpara>
</listitem>
<listitem>
<simpara>
<literal>toWord mode r</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>toLargeWord mode r</literal>
</simpara>
<simpara>convert the argument <literal>r</literal> to a word type using the specified rounding
mode. They raise <literal>Overflow</literal> if the result is not representable, in
particular, if <literal>r</literal> is an infinity. They raise <literal>Domain</literal> if <literal>r</literal> is NaN.</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Real32.castFromWord w</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Real64.castFromWord w</literal>
</simpara>
<simpara>convert the argument <literal>w</literal> to a real type as a bit-wise cast.</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Real32.castToWord r</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Real64.castToWord r</literal>
</simpara>
<simpara>convert the argument <literal>r</literal> to a word type as a bit-wise cast.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonRlimit">
<title>MLtonRlimit</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_RLIMIT =
   sig
      structure RLim : sig
                          type t
                          val castFromSysWord: SysWord.word -&gt; t
                          val castToSysWord: t -&gt; SysWord.word
                       end

      val infinity: RLim.t

      type t

      val coreFileSize: t        (* CORE    max core file size *)
      val cpuTime: t             (* CPU     CPU time in seconds *)
      val dataSize: t            (* DATA    max data size *)
      val fileSize: t            (* FSIZE   Maximum filesize *)
      val numFiles: t            (* NOFILE  max number of open files *)
      val lockedInMemorySize: t  (* MEMLOCK max locked address space *)
      val numProcesses: t        (* NPROC   max number of processes *)
      val residentSetSize: t     (* RSS     max resident set size *)
      val stackSize: t           (* STACK   max stack size *)
      val virtualMemorySize: t   (* AS      virtual memory limit *)

      val get: t -&gt; {hard: rlim, soft: rlim}
      val set: t * {hard: rlim, soft: rlim} -&gt; unit
   end</programlisting>
<simpara><literal>MLton.Rlimit</literal> provides a wrapper around the C <literal>getrlimit</literal> and
<literal>setrlimit</literal> functions.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>type Rlim.t</literal>
</simpara>
<simpara>the type of resource limits.</simpara>
</listitem>
<listitem>
<simpara>
<literal>infinity</literal>
</simpara>
<simpara>indicates that a resource is unlimited.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>the types of resources that can be inspected and modified.</simpara>
</listitem>
<listitem>
<simpara>
<literal>get r</literal>
</simpara>
<simpara>returns the current hard and soft limits for resource <literal>r</literal>. May raise
<literal>OS.SysErr</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>set (r, {hard, soft})</literal>
</simpara>
<simpara>sets the hard and soft limits for resource <literal>r</literal>.  May raise
<literal>OS.SysErr</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonRusage">
<title>MLtonRusage</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_RUSAGE =
   sig
      type t = {utime: Time.time, (* user time *)
                stime: Time.time} (* system time *)

      val measureGC: bool -&gt; unit
      val rusage: unit -&gt; {children: t, gc: t, self: t}
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>corresponds to a subset of the C <literal>struct rusage</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>measureGC b</literal>
</simpara>
<simpara>controls whether garbage collection time is separately measured during
program execution.  This affects the behavior of both <literal>rusage</literal> and
<literal>Timer.checkCPUTimes</literal>, both of which will return gc times of zero with
<literal>measureGC false</literal>.  Garbage collection time is always measured when
either <literal>gc-messages</literal> or <literal>gc-summary</literal> is given as a
<link linkend="RunTimeOptions">runtime system option</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>rusage ()</literal>
</simpara>
<simpara>corresponds to the C <literal>getrusage</literal> function.  It returns the resource
usage of the exited children, the garbage collector, and the process
itself.  The <literal>self</literal> component includes the usage of the <literal>gc</literal>
component, regardless of whether <literal>measureGC</literal> is <literal>true</literal> or <literal>false</literal>.  If
<literal>rusage</literal> is used in a program, either directly, or indirectly via the
<literal>Timer</literal> structure, then <literal>measureGC true</literal> is automatically called at
the start of the program (it can still be disable by user code later).</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonSignal">
<title>MLtonSignal</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_SIGNAL =
   sig
      type t = Posix.Signal.signal
      type signal = t

      structure Handler:
         sig
            type t

            val default: t
            val handler: (Thread.Runnable.t -&gt; Thread.Runnable.t) -&gt; t
            val ignore: t
            val isDefault: t -&gt; bool
            val isIgnore: t -&gt; bool
            val simple: (unit -&gt; unit) -&gt; t
         end

      structure Mask:
         sig
            type t

            val all: t
            val allBut: signal list -&gt; t
            val block: t -&gt; unit
            val getBlocked: unit -&gt; t
            val isMember: t * signal -&gt; bool
            val none: t
            val setBlocked: t -&gt; unit
            val some: signal list -&gt; t
            val unblock: t -&gt; unit
         end

      val getHandler: t -&gt; Handler.t
      val handled: unit -&gt; Mask.t
      val prof: t
      val restart: bool ref
      val setHandler: t * Handler.t -&gt; unit
      val suspend: Mask.t -&gt; unit
      val vtalrm: t
   end</programlisting>
<simpara>Signals handlers are functions from (runnable) threads to (runnable)
threads.  When a signal arrives, the corresponding signal handler is
invoked, its argument being the thread that was interrupted by the
signal.  The signal handler runs asynchronously, in its own thread.
The signal handler returns the thread that it would like to resume
execution (this is often the thread that it was passed).  It is an
error for a signal handler to raise an exception that is not handled
within the signal handler itself.</simpara>
<simpara>A signal handler is never invoked while the running thread is in a
critical section (see <link linkend="MLtonThread">MLtonThread</link>).  Invoking a signal handler
implicitly enters a critical section and the normal return of a signal
handler implicitly exits the critical section; hence, a signal handler
is never interrupted by another signal handler.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>the type of signals.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type Handler.t</literal>
</simpara>
<simpara>the type of signal handlers.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Handler.default</literal>
</simpara>
<simpara>handles the signal with the default action.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Handler.handler f</literal>
</simpara>
<simpara>returns a handler <literal>h</literal> such that when a signal <literal>s</literal> is handled by <literal>h</literal>,
<literal>f</literal> will be passed the thread that was interrupted by <literal>s</literal> and should
return the thread that will resume execution.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Handler.ignore</literal>
</simpara>
<simpara>is a handler that will ignore the signal.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Handler.isDefault</literal>
</simpara>
<simpara>returns true if the handler is the default handler.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Handler.isIgnore</literal>
</simpara>
<simpara>returns true if the handler is the ignore handler.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Handler.simple f</literal>
</simpara>
<simpara>returns a handler that executes <literal>f ()</literal> and does not switch threads.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type Mask.t</literal>
</simpara>
<simpara>the type of signal masks, which are sets of blocked signals.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.all</literal>
</simpara>
<simpara>a mask of all signals.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.allBut l</literal>
</simpara>
<simpara>a mask of all signals except for those in <literal>l</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.block m</literal>
</simpara>
<simpara>blocks all signals in <literal>m</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.getBlocked ()</literal>
</simpara>
<simpara>gets the signal mask <literal>m</literal>, i.e. a signal is blocked if and only if it
is in <literal>m</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.isMember (m, s)</literal>
</simpara>
<simpara>returns true if the signal <literal>s</literal> is in <literal>m</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.none</literal>
</simpara>
<simpara>a mask of no signals.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.setBlocked m</literal>
</simpara>
<simpara>sets the signal mask to <literal>m</literal>, i.e. a signal is blocked if and only if
it is in <literal>m</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.some l</literal>
</simpara>
<simpara>a mask of the signals in <literal>l</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>Mask.unblock m</literal>
</simpara>
<simpara>unblocks all signals in <literal>m</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>getHandler s</literal>
</simpara>
<simpara>returns the current handler for signal <literal>s</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>handled ()</literal>
</simpara>
<simpara>returns the signal mask <literal>m</literal> corresponding to the currently handled
signals; i.e., a signal is handled if and only if it is in <literal>m</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>prof</literal>
</simpara>
<simpara><literal>SIGPROF</literal>, the profiling signal.</simpara>
</listitem>
<listitem>
<simpara>
<literal>restart</literal>
</simpara>
<simpara>dynamically determines the behavior of interrupted system calls; when
<literal>true</literal>, interrupted system calls are restarted; when <literal>false</literal>,
interrupted system calls raise <literal>OS.SysError</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>setHandler (s, h)</literal>
</simpara>
<simpara>sets the handler for signal <literal>s</literal> to <literal>h</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>suspend m</literal>
</simpara>
<simpara>temporarily sets the signal mask to <literal>m</literal> and suspends until an unmasked
signal is received and handled, at which point <literal>suspend</literal> resets the
mask and returns.</simpara>
</listitem>
<listitem>
<simpara>
<literal>vtalrm</literal>
</simpara>
<simpara><literal>SIGVTALRM</literal>, the signal for virtual timers.</simpara>
</listitem>
</itemizedlist>
<section id="_interruptible_system_calls">
<title>Interruptible System Calls</title>
<simpara>Signal handling interacts in a non-trivial way with those functions in
the <link linkend="BasisLibrary">Basis Library</link> that correspond directly to
interruptible system calls (a subset of those functions that may raise
<literal>OS.SysError</literal>).  The desire is that these functions should have
predictable semantics.  The principal concerns are:</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
System calls that are interrupted by signals should, by default, be
restarted; the alternative is to raise
</simpara>
<programlisting language="sml" linenumbering="unnumbered">OS.SysError (Posix.Error.errorMsg Posix.Error.intr,
             SOME Posix.Error.intr)</programlisting>
<simpara>This behavior is determined dynamically by the value of <literal>Signal.restart</literal>.</simpara>
</listitem>
<listitem>
<simpara>
Signal handlers should always get a chance to run (when outside a
critical region).  If a system call is interrupted by a signal, then
the signal handler will run before the call is restarted or
<literal>OS.SysError</literal> is raised; that is, before the <literal>Signal.restart</literal> check.
</simpara>
</listitem>
<listitem>
<simpara>
A system call that must be restarted while in a critical section
will be restarted with the handled signals blocked (and the previously
blocked signals remembered).  This encourages the system call to
complete, allowing the program to make progress towards leaving the
critical section where the signal can be handled.  If the system call
completes, the set of blocked signals are restored to those previously
blocked.
</simpara>
</listitem>
</orderedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonStructure">
<title>MLtonStructure</title>
<simpara>The <literal>MLton</literal> structure contains a lot of functionality that is not
available in the <link linkend="BasisLibrary">Basis Library</link>.  As a warning,
please keep in mind that the <literal>MLton</literal> structure and its
substructures do change from release to release of MLton.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure MLton:
   sig
      val eq: 'a * 'a -&gt; bool
      val equal: 'a * 'a -&gt; bool
      val hash: 'a -&gt; Word32.word
      val isMLton: bool
      val share: 'a -&gt; unit
      val shareAll: unit -&gt; unit
      val size: 'a -&gt; int

      structure Array: MLTON_ARRAY
      structure BinIO: MLTON_BIN_IO
      structure CharArray: MLTON_MONO_ARRAY where type t = CharArray.array
                                            where type elem = CharArray.elem
      structure CharVector: MLTON_MONO_VECTOR where type t = CharVector.vector
                                              where type elem = CharVector.elem
      structure Cont: MLTON_CONT
      structure Exn: MLTON_EXN
      structure Finalizable: MLTON_FINALIZABLE
      structure GC: MLTON_GC
      structure IntInf: MLTON_INT_INF
      structure Itimer: MLTON_ITIMER
      structure LargeReal: MLTON_REAL where type t = LargeReal.real
      structure LargeWord: MLTON_WORD where type t = LargeWord.word
      structure Platform: MLTON_PLATFORM
      structure Pointer: MLTON_POINTER
      structure ProcEnv: MLTON_PROC_ENV
      structure Process: MLTON_PROCESS
      structure Profile: MLTON_PROFILE
      structure Random: MLTON_RANDOM
      structure Real: MLTON_REAL where type t = Real.real
      structure Real32: sig
                           include MLTON_REAL
                           val castFromWord: Word32.word -&gt; t
                           val castToWord: t -&gt; Word32.word
                        end where type t = Real32.real
      structure Real64: sig
                           include MLTON_REAL
                           val castFromWord: Word64.word -&gt; t
                           val castToWord: t -&gt; Word64.word
                        end where type t = Real64.real
      structure Rlimit: MLTON_RLIMIT
      structure Rusage: MLTON_RUSAGE
      structure Signal: MLTON_SIGNAL
      structure Syslog: MLTON_SYSLOG
      structure TextIO: MLTON_TEXT_IO
      structure Thread: MLTON_THREAD
      structure Vector: MLTON_VECTOR
      structure Weak: MLTON_WEAK
      structure Word: MLTON_WORD where type t = Word.word
      structure Word8: MLTON_WORD where type t = Word8.word
      structure Word16: MLTON_WORD where type t = Word16.word
      structure Word32: MLTON_WORD where type t = Word32.word
      structure Word64: MLTON_WORD where type t = Word64.word
      structure Word8Array: MLTON_MONO_ARRAY where type t = Word8Array.array
                                             where type elem = Word8Array.elem
      structure Word8Vector: MLTON_MONO_VECTOR where type t = Word8Vector.vector
                                               where type elem = Word8Vector.elem
      structure World: MLTON_WORLD
   end</programlisting>
<section id="_substructures">
<title>Substructures</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLtonArray">MLtonArray</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonBinIO">MLtonBinIO</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonCont">MLtonCont</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonExn">MLtonExn</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonFinalizable">MLtonFinalizable</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonGC">MLtonGC</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonIntInf">MLtonIntInf</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonIO">MLtonIO</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonItimer">MLtonItimer</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonMonoArray">MLtonMonoArray</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonMonoVector">MLtonMonoVector</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonPlatform">MLtonPlatform</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonPointer">MLtonPointer</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonProcEnv">MLtonProcEnv</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonProcess">MLtonProcess</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonRandom">MLtonRandom</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonReal">MLtonReal</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonRlimit">MLtonRlimit</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonRusage">MLtonRusage</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonSignal">MLtonSignal</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonSyslog">MLtonSyslog</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonTextIO">MLtonTextIO</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonThread">MLtonThread</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonVector">MLtonVector</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonWeak">MLtonWeak</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonWord">MLtonWord</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonWorld">MLtonWorld</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_values">
<title>Values</title>
<itemizedlist>
<listitem>
<simpara>
<literal>eq (x, y)</literal>
</simpara>
<simpara>returns true if <literal>x</literal> and <literal>y</literal> are equal as pointers.  For simple types
like <literal>char</literal>, <literal>int</literal>, and <literal>word</literal>, this is the same as equals.  For
arrays, datatypes, strings, tuples, and vectors, this is a simple
pointer equality.  The semantics is a bit murky.</simpara>
</listitem>
<listitem>
<simpara>
<literal>equal (x, y)</literal>
</simpara>
<simpara>returns true if <literal>x</literal> and <literal>y</literal> are structurally equal.  For equality
types, this is the same as <link linkend="PolymorphicEquality">PolymorphicEquality</link>.  For other types,
it is a conservative approximation of equivalence.</simpara>
</listitem>
<listitem>
<simpara>
<literal>hash x</literal>
</simpara>
<simpara>returns a structural hash of <literal>x</literal>.  The hash function is consistent
between execution of the same program, but may not be consistent
between different programs.</simpara>
</listitem>
<listitem>
<simpara>
<literal>isMLton</literal>
</simpara>
<simpara>is always <literal>true</literal> in a MLton implementation, and is always <literal>false</literal> in a
stub implementation.</simpara>
</listitem>
<listitem>
<simpara>
<literal>share x</literal>
</simpara>
<simpara>maximizes sharing in the heap for the object graph reachable from <literal>x</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>shareAll ()</literal>
</simpara>
<simpara>maximizes sharing in the heap by sharing space for equivalent
immutable objects.  A call to <literal>shareAll</literal> performs a major garbage
collection, and takes time proportional to the size of the heap.</simpara>
</listitem>
<listitem>
<simpara>
<literal>size x</literal>
</simpara>
<simpara>returns the amount of heap space (in bytes) taken by the value of <literal>x</literal>,
including all objects reachable from <literal>x</literal> by following pointers.  It
takes time proportional to the size of <literal>x</literal>.  See below for an example.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_mltonstructure_size_xreflabel_mltonstructure_size_example_of_literal_mlton_size_literal">
<title><anchor id="MLtonStructure_size" xreflabel="[MLtonStructure_size]"/>Example of <literal>MLton.size</literal></title>
<simpara>This example, <literal>size.sml</literal>, demonstrates the application of <literal>MLton.size</literal>
to many different kinds of objects.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun 'a printSize (name: string, value: 'a): unit=
   (print "The size of "
    ; print name
    ; print " is "
    ; print (Int.toString (MLton.size value))
    ; print " bytes.\n")

val l = [1, 2, 3, 4]

val _ =
   (
    printSize ("an int list of length 4", l)
    ; printSize ("a string of length 10", "0123456789")
    ; printSize ("an int array of length 10", Array.tabulate (10, fn _ =&gt; 0))
    ; printSize ("a double array of length 10",
                 Array.tabulate (10, fn _ =&gt; 0.0))
    ; printSize ("an array of length 10 of 2-ples of ints",
                 Array.tabulate (10, fn i =&gt; (i, i + 1)))
    ; printSize ("a useless function", fn _ =&gt; 13)
    )

(* This is here so that the list is "useful".
 * If it were removed, then the optimizer (remove-unused-constructors)
 * would remove l entirely.
 *)
val _ = if 10 = foldl (op +) 0 l
           then ()
        else raise Fail "bug"

local
   open MLton.Cont
in
   val rc: int option t option ref = ref NONE
   val _ =
      case callcc (fn k: int option t =&gt; (rc := SOME k; throw (k, NONE))) of
         NONE =&gt; ()
       | SOME i =&gt; print (concat [Int.toString i, "\n"])
end

val _ = printSize ("a continuation option ref", rc)

val _ =
   case !rc of
      NONE =&gt; ()
    | SOME k =&gt; (rc := NONE; MLton.Cont.throw (k, SOME 13))</programlisting>
<simpara>Compile and run as usual.</simpara>
<screen>% mlton size.sml
% ./size
The size of an int list of length 4 is 48 bytes.
The size of a string of length 10 is 24 bytes.
The size of an int array of length 10 is 52 bytes.
The size of a double array of length 10 is 92 bytes.
The size of an array of length 10 of 2-ples of ints is 92 bytes.
The size of a useless function is 0 bytes.
The size of a continuation option ref is 4544 bytes.
13
The size of a continuation option ref is 8 bytes.</screen>
<simpara>Note that sizes are dependent upon the target platform and compiler
optimizations.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonSyslog">
<title>MLtonSyslog</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_SYSLOG =
   sig
      type openflag

      val CONS     : openflag
      val NDELAY   : openflag
      val NOWAIT   : openflag
      val ODELAY   : openflag
      val PERROR   : openflag
      val PID      : openflag

      type facility

      val AUTHPRIV : facility
      val CRON     : facility
      val DAEMON   : facility
      val KERN     : facility
      val LOCAL0   : facility
      val LOCAL1   : facility
      val LOCAL2   : facility
      val LOCAL3   : facility
      val LOCAL4   : facility
      val LOCAL5   : facility
      val LOCAL6   : facility
      val LOCAL7   : facility
      val LPR      : facility
      val MAIL     : facility
      val NEWS     : facility
      val SYSLOG   : facility
      val USER     : facility
      val UUCP     : facility

      type loglevel

      val EMERG    : loglevel
      val ALERT    : loglevel
      val CRIT     : loglevel
      val ERR      : loglevel
      val WARNING  : loglevel
      val NOTICE   : loglevel
      val INFO     : loglevel
      val DEBUG    : loglevel

      val closelog: unit -&gt; unit
      val log: loglevel * string -&gt; unit
      val openlog: string * openflag list * facility -&gt; unit
   end</programlisting>
<simpara><literal>MLton.Syslog</literal> is a complete interface to the system logging
facilities.  See <literal>man 3 syslog</literal> for more details.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>closelog ()</literal>
</simpara>
<simpara>closes the connection to the system logger.</simpara>
</listitem>
<listitem>
<simpara>
<literal>log (l, s)</literal>
</simpara>
<simpara>logs message <literal>s</literal> at a loglevel <literal>l</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>openlog (name, flags, facility)</literal>
</simpara>
<simpara>opens a connection to the system logger. <literal>name</literal> will be prefixed to
each message, and is typically set to the program name.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonTextIO">
<title>MLtonTextIO</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_TEXT_IO = MLTON_IO</programlisting>
<simpara>See <link linkend="MLtonIO">MLtonIO</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonThread">
<title>MLtonThread</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_THREAD =
   sig
      structure AtomicState:
         sig
            datatype t = NonAtomic | Atomic of int
         end

      val atomically: (unit -&gt; 'a) -&gt; 'a
      val atomicBegin: unit -&gt; unit
      val atomicEnd: unit -&gt; unit
      val atomicState: unit -&gt; AtomicState.t

      structure Runnable:
         sig
            type t
         end

      type 'a t

      val atomicSwitch: ('a t -&gt; Runnable.t) -&gt; 'a
      val new: ('a -&gt; unit) -&gt; 'a t
      val prepend: 'a t * ('b -&gt; 'a) -&gt; 'b t
      val prepare: 'a t * 'a -&gt; Runnable.t
      val switch: ('a t -&gt; Runnable.t) -&gt; 'a
   end</programlisting>
<simpara><literal>MLton.Thread</literal> provides access to MLton&#8217;s user-level thread
implementation (i.e. not OS-level threads).  Threads are lightweight
data structures that represent a paused computation.  Runnable threads
are threads that will begin or continue computing when <literal>switch</literal>-ed to.
<literal>MLton.Thread</literal> does not include a default scheduling mechanism, but it
can be used to implement both preemptive and non-preemptive threads.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>type AtomicState.t</literal>
</simpara>
<simpara>the type of atomic states.</simpara>
</listitem>
<listitem>
<simpara>
<literal>atomically f</literal>
</simpara>
<simpara>runs <literal>f</literal> in a critical section.</simpara>
</listitem>
<listitem>
<simpara>
<literal>atomicBegin ()</literal>
</simpara>
<simpara>begins a critical section.</simpara>
</listitem>
<listitem>
<simpara>
<literal>atomicEnd ()</literal>
</simpara>
<simpara>ends a critical section.</simpara>
</listitem>
<listitem>
<simpara>
<literal>atomicState ()</literal>
</simpara>
<simpara>returns the current atomic state.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type Runnable.t</literal>
</simpara>
<simpara>the type of threads that can be resumed.</simpara>
</listitem>
<listitem>
<simpara>
<literal>type 'a t</literal>
</simpara>
<simpara>the type of threads that expect a value of type <literal>'a</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>atomicSwitch f</literal>
</simpara>
<simpara>like <literal>switch</literal>, but assumes an atomic calling context.  Upon
<literal>switch</literal>-ing back to the current thread, an implicit <literal>atomicEnd</literal> is
performed.</simpara>
</listitem>
<listitem>
<simpara>
<literal>new f</literal>
</simpara>
<simpara>creates a new thread that, when run, applies <literal>f</literal> to the value given to
the thread.  <literal>f</literal> must terminate by `switch`ing to another thread or
exiting the process.</simpara>
</listitem>
<listitem>
<simpara>
<literal>prepend (t, f)</literal>
</simpara>
<simpara>creates a new thread (destroying <literal>t</literal> in the process) that first
applies <literal>f</literal> to the value given to the thread and then continues with
<literal>t</literal>.  This is a constant time operation.</simpara>
</listitem>
<listitem>
<simpara>
<literal>prepare (t, v)</literal>
</simpara>
<simpara>prepares a new runnable thread (destroying <literal>t</literal> in the process) that
will evaluate <literal>t</literal> on <literal>v</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>switch f</literal>
</simpara>
<simpara>applies <literal>f</literal> to the current thread to get <literal>rt</literal>, and then start running
thread <literal>rt</literal>.  It is an error for <literal>f</literal> to perform another <literal>switch</literal>.  <literal>f</literal>
is guaranteed to run atomically.</simpara>
</listitem>
</itemizedlist>
<section id="_example_of_non_preemptive_threads">
<title>Example of non-preemptive threads</title>
<programlisting language="sml" linenumbering="unnumbered">structure Queue:
   sig
      type 'a t

      val new: unit -&gt; 'a t
      val enque: 'a t * 'a -&gt; unit
      val deque: 'a t -&gt; 'a option
   end =
   struct
      datatype 'a t = T of {front: 'a list ref, back: 'a list ref}

      fun new () = T {front = ref [], back = ref []}

      fun enque (T {back, ...}, x) = back := x :: !back

      fun deque (T {front, back}) =
         case !front of
            [] =&gt; (case !back of
                      [] =&gt; NONE
                    | l =&gt; let val l = rev l
                           in case l of
                              [] =&gt; raise Fail "deque"
                            | x :: l =&gt; (back := []; front := l; SOME x)
                           end)
          | x :: l =&gt; (front := l; SOME x)
   end

structure Thread:
   sig
      val exit: unit -&gt; 'a
      val run: unit -&gt; unit
      val spawn: (unit -&gt; unit) -&gt; unit
      val yield: unit -&gt; unit
   end =
   struct
      open MLton
      open Thread

      val topLevel: Thread.Runnable.t option ref = ref NONE

      local
         val threads: Thread.Runnable.t Queue.t = Queue.new ()
      in
         fun ready (t: Thread.Runnable.t) : unit =
            Queue.enque(threads, t)
         fun next () : Thread.Runnable.t =
            case Queue.deque threads of
               NONE =&gt; valOf (!topLevel)
             | SOME t =&gt; t
      end

      fun 'a exit (): 'a = switch (fn _ =&gt; next ())

      fun new (f: unit -&gt; unit): Thread.Runnable.t =
         Thread.prepare
         (Thread.new (fn () =&gt; ((f () handle _ =&gt; exit ())
                                ; exit ())),
          ())

      fun schedule t = (ready t; next ())

      fun yield (): unit = switch (fn t =&gt; schedule (Thread.prepare (t, ())))

      val spawn = ready o new

      fun run(): unit =
         (switch (fn t =&gt;
                  (topLevel := SOME (Thread.prepare (t, ()))
                   ; next()))
          ; topLevel := NONE)
   end

val rec loop =
   fn 0 =&gt; ()
    | n =&gt; (print(concat[Int.toString n, "\n"])
            ; Thread.yield()
            ; loop(n - 1))

val rec loop' =
   fn 0 =&gt; ()
    | n =&gt; (Thread.spawn (fn () =&gt; loop n); loop' (n - 2))

val _ = Thread.spawn (fn () =&gt; loop' 10)

val _ = Thread.run ()

val _ = print "success\n"</programlisting>
</section>
<section id="_example_of_preemptive_threads">
<title>Example of preemptive threads</title>
<programlisting language="sml" linenumbering="unnumbered">structure Queue:
   sig
      type 'a t

      val new: unit -&gt; 'a t
      val enque: 'a t * 'a -&gt; unit
      val deque: 'a t -&gt; 'a option
   end =
   struct
      datatype 'a t = T of {front: 'a list ref, back: 'a list ref}

      fun new () = T {front = ref [], back = ref []}

      fun enque (T {back, ...}, x) = back := x :: !back

      fun deque (T {front, back}) =
         case !front of
            [] =&gt; (case !back of
                      [] =&gt; NONE
                    | l =&gt; let val l = rev l
                           in case l of
                              [] =&gt; raise Fail "deque"
                            | x :: l =&gt; (back := []; front := l; SOME x)
                           end)
          | x :: l =&gt; (front := l; SOME x)
   end

structure Thread:
   sig
      val exit: unit -&gt; 'a
      val run: unit -&gt; unit
      val spawn: (unit -&gt; unit) -&gt; unit
      val yield: unit -&gt; unit
   end =
   struct
      open Posix.Signal
      open MLton
      open Itimer Signal Thread

      val topLevel: Thread.Runnable.t option ref = ref NONE

      local
         val threads: Thread.Runnable.t Queue.t = Queue.new ()
      in
         fun ready (t: Thread.Runnable.t) : unit =
            Queue.enque(threads, t)
         fun next () : Thread.Runnable.t =
            case Queue.deque threads of
               NONE =&gt; valOf (!topLevel)
             | SOME t =&gt; t
      end

      fun 'a exit (): 'a = switch (fn _ =&gt; next ())

      fun new (f: unit -&gt; unit): Thread.Runnable.t =
         Thread.prepare
         (Thread.new (fn () =&gt; ((f () handle _ =&gt; exit ())
                                ; exit ())),
          ())

      fun schedule t = (ready t; next ())

      fun yield (): unit = switch (fn t =&gt; schedule (Thread.prepare (t, ())))

      val spawn = ready o new

      fun setItimer t =
         Itimer.set (Itimer.Real,
                     {value = t,
                      interval = t})

      fun run (): unit =
         (switch (fn t =&gt;
                  (topLevel := SOME (Thread.prepare (t, ()))
                   ; new (fn () =&gt; (setHandler (alrm, Handler.handler schedule)
                                    ; setItimer (Time.fromMilliseconds 20)))))
          ; setItimer Time.zeroTime
          ; ignore alrm
          ; topLevel := NONE)
   end

val rec delay =
   fn 0 =&gt; ()
    | n =&gt; delay (n - 1)

val rec loop =
   fn 0 =&gt; ()
    | n =&gt; (delay 500000; loop (n - 1))

val rec loop' =
   fn 0 =&gt; ()
    | n =&gt; (Thread.spawn (fn () =&gt; loop n); loop' (n - 1))

val _ = Thread.spawn (fn () =&gt; loop' 10)

val _ = Thread.run ()

val _ = print "success\n"</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLtonVector">
<title>MLtonVector</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_VECTOR =
   sig
      val create: int -&gt; {done: unit -&gt; 'a vector,
                          sub: int -&gt; 'a,
                          update: int * 'a -&gt; unit}
      val unfoldi: int * 'b * (int * 'b -&gt; 'a * 'b) -&gt; 'a vector * 'b
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>create n</literal>
</simpara>
<simpara>initiates the construction a vector <emphasis>v</emphasis> of length <literal>n</literal>, returning
functions to manipulate the vector.  The <literal>done</literal> function may be called
to return the created vector; it is an error to call <literal>done</literal> before all
entries have been initialized; it is an error to call <literal>done</literal> after
having called <literal>done</literal>.  The <literal>sub</literal> function may be called to return an
initialized vector entry; it is not an error to call <literal>sub</literal> after
having called <literal>done</literal>.  The <literal>update</literal> function may be called to
initialize a vector entry; it is an error to call <literal>update</literal> after
having called <literal>done</literal>.  One must initialize vector entries in order
from lowest to highest; that is, before calling <literal>update (i, x)</literal>, one
must have already called <literal>update (j, x)</literal> for all <literal>j</literal> in <literal>[0, i)</literal>.  The
<literal>done</literal>, <literal>sub</literal>, and <literal>update</literal> functions are all constant-time
operations.</simpara>
</listitem>
<listitem>
<simpara>
<literal>unfoldi (n, b, f)</literal>
</simpara>
<simpara>constructs a vector <emphasis>v</emphasis> of length <literal>n</literal>, whose elements <emphasis>v<subscript>i</subscript></emphasis> are
determined by the equations <emphasis>b<subscript>0</subscript> = b</emphasis> and
<emphasis>(v<subscript>i</subscript>, b<subscript>i+1</subscript>) = f (i, b<subscript>i</subscript>)</emphasis>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonWeak">
<title>MLtonWeak</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_WEAK =
   sig
      type 'a t

      val get: 'a t -&gt; 'a option
      val new: 'a -&gt; 'a t
   end</programlisting>
<simpara>A weak pointer is a pointer to an object that is nulled if the object
becomes <link linkend="Reachability">unreachable</link> due to garbage collection.  The
weak pointer does not itself cause the object it points to be retained
by the garbage collector&#8201;&#8212;&#8201;only other strong pointers can do that.
For objects that are not allocated in the heap, like integers, a weak
pointer will always be nulled.  So, if <literal>w: int Weak.t</literal>, then
<literal>Weak.get w = NONE</literal>.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>type 'a t</literal>
</simpara>
<simpara>the type of weak pointers to objects of type <literal>'a</literal></simpara>
</listitem>
<listitem>
<simpara>
<literal>get w</literal>
</simpara>
<simpara>returns <literal>NONE</literal> if the object pointed to by <literal>w</literal> no longer exists.
Otherwise, returns <literal>SOME</literal> of the object pointed to by <literal>w</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>new x</literal>
</simpara>
<simpara>returns a weak pointer to <literal>x</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonWord">
<title>MLtonWord</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_WORD =
   sig
      type t

      val bswap: t -&gt; t
      val rol: t * word -&gt; t
      val ror: t * word -&gt; t
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>type t</literal>
</simpara>
<simpara>the type of words.  For <literal>MLton.LargeWord</literal> this is <literal>LargeWord.word</literal>,
for <literal>MLton.Word</literal> this is <literal>Word.word</literal>, for <literal>MLton.Word8</literal> this is
<literal>Word8.word</literal>, for <literal>MLton.Word16</literal> this is <literal>Word16.word</literal>, for
<literal>MLton.Word32</literal> this is <literal>Word32.word</literal>, for <literal>MLton.Word64</literal> this is
<literal>Word64.word</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>bswap w</literal>
</simpara>
<simpara>byte swap.</simpara>
</listitem>
<listitem>
<simpara>
<literal>rol (w, w')</literal>
</simpara>
<simpara>rotates left (circular).</simpara>
</listitem>
<listitem>
<simpara>
<literal>ror (w, w')</literal>
</simpara>
<simpara>rotates right (circular).</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="MLtonWorld">
<title>MLtonWorld</title>
<programlisting language="sml" linenumbering="unnumbered">signature MLTON_WORLD =
   sig
      datatype status = Clone | Original

      val load: string -&gt; 'a
      val save: string -&gt; status
      val saveThread: string * Thread.Runnable.t -&gt; unit
   end</programlisting>
<itemizedlist>
<listitem>
<simpara>
<literal>datatype status</literal>
</simpara>
<simpara>specifies whether a world is original or restarted (a clone).</simpara>
</listitem>
<listitem>
<simpara>
<literal>load f</literal>
</simpara>
<simpara>loads the saved computation from file <literal>f</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>save f</literal>
</simpara>
<simpara>saves the entire state of the computation to the file <literal>f</literal>.  The
computation can then be restarted at a later time using <literal>World.load</literal>
or the <literal>load-world</literal> <link linkend="RunTimeOptions">runtime option</link>.  The call to
<literal>save</literal> in the original computation returns <literal>Original</literal> and the call in
the restarted world returns <literal>Clone</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>saveThread (f, rt)</literal>
</simpara>
<simpara>saves the entire state of the computation to the file <literal>f</literal> that will
resume with thread <literal>rt</literal> upon restart.</simpara>
</listitem>
</itemizedlist>
<section id="_notes_2">
<title>Notes</title>
<simpara><anchor id="MLtonWorld_ASLR" xreflabel="[MLtonWorld_ASLR]"/>
Executables that save and load worlds are incompatible with
<ulink url="http://en.wikipedia.org/wiki/Address_space_layout_randomization">address space layout randomization (ASLR)</ulink>
of the executable (though, not of shared libraries).  The state of a
computation includes addresses into the code and data segments of the
executable (e.g., static runtime-system data, return addresses); such
addresses are invalid when interpreted by the executable loaded at a
different base address.</simpara>
<simpara>Executables that save and load worlds should be compiled with an
option to suppress the generation of position-independent executables.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnDarwin">Darwin 11 (Mac OS X Lion) and higher</link> : <literal>-link-opt -fno-PIE</literal>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_example_6">
<title>Example</title>
<simpara>Suppose that <literal>save-world.sml</literal> contains the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">open MLton.World

val _ =
   case save "world" of
      Original =&gt; print "I am the original\n"
    | Clone =&gt; print "I am the clone\n"</programlisting>
<simpara>Then, if we compile <literal>save-world.sml</literal> and run it, the <literal>Original</literal>
branch will execute, and a file named <literal>world</literal> will be created.</simpara>
<screen>% mlton save-world.sml
% ./save-world
I am the original</screen>
<simpara>We can then load <literal>world</literal> using the <literal>load-world</literal>
<link linkend="RunTimeOptions">run time option</link>.</simpara>
<screen>% ./save-world @MLton load-world world --
I am the clone</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLULex">
<title>MLULex</title>
<simpara><ulink url="http://smlnj-gforge.cs.uchicago.edu/projects/ml-lpt/">MLULex</ulink> is a
scanner generator for <link linkend="StandardML">Standard ML</link>.</simpara>
<section id="_also_see_17">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLAntlr">MLAntlr</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLLPTLibrary">MLLPTLibrary</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_OwensEtAl09">OwensEtAl09</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MLYacc">
<title>MLYacc</title>
<simpara><link linkend="MLYacc">MLYacc</link> is a parser generator for <link linkend="StandardML">Standard ML</link> modeled
after the Yacc parser generator.</simpara>
<simpara>A version of MLYacc, ported from the <link linkend="SMLNJ">SML/NJ</link> sources, is
distributed with MLton.</simpara>
<section id="_also_see_18">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="guide/Documentation.attachments/mlyacc.pdf"><literal>mlyacc.pdf</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLLex">MLLex</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_TarditiAppel00">TarditiAppel00</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Price09">Price09</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Monomorphise">
<title>Monomorphise</title>
<simpara><link linkend="Monomorphise">Monomorphise</link> is a translation pass from the <link linkend="XML">XML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="SXML">SXML</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_38">
<title>Description</title>
<simpara>Monomorphisation eliminates polymorphic values and datatype
declarations by duplicating them for each type at which they are used.</simpara>
<simpara>Consider the following <link linkend="XML">XML</link> program.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = T of 'a
fun 'a f (x: 'a) = T x
val a = f 1
val b = f 2
val z = f (3, 4)</programlisting>
<simpara>The result of monomorphising this program is the following <link linkend="SXML">SXML</link> program:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t1 = T1 of int
datatype t2 = T2 of int * int
fun f1 (x: int) = T1 x
fun f2 (x: int * int) = T2 x
val a = f1 1
val b = f1 2
val z = f2 (3, 4)</programlisting>
</section>
<section id="_implementation_41">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/monomorphise.sig"><literal>monomorphise.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/monomorphise.fun"><literal>monomorphise.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_41">
<title>Details and Notes</title>
<simpara>The monomorphiser works by making one pass over the entire program.
On the way down, it creates a cache for each variable declared in a
polymorphic declaration that maps a lists of type arguments to a new
variable name.  At a variable reference, it consults the cache (based
on the types the variable is applied to).  If there is already an
entry in the cache, it is used.  If not, a new entry is created.  On
the way up, the monomorphiser duplicates a variable declaration for
each entry in the cache.</simpara>
<simpara>As with variables, the monomorphiser records all of the type at which
constructors are used.  After the entire program is processed, the
monomorphiser duplicates each datatype declaration and its associated
constructors.</simpara>
<simpara>The monomorphiser duplicates all of the functions declared in a
<literal>fun</literal> declaration as a unit.  Consider the following program</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun 'a f (x: 'a) = g x
and g (y: 'a) = f y
val a = f 13
val b = g 14
val c = f (1, 2)</programlisting>
<simpara>and its monomorphisation</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f1 (x: int) = g1 x
and g1 (y: int) = f1 y
fun f2 (x : int * int) = g2 x
and g2 (y : int * int) = f2 y
val a = f1 13
val b = g1 14
val c = f2 (1, 2)</programlisting>
</section>
<section id="_pathological_datatype_declarations">
<title>Pathological datatype declarations</title>
<simpara>SML allows a pathological polymorphic datatype declaration in which
recursive uses of the defined type constructor are applied to
different type arguments than the definition.  This has been
disallowed by others on type theoretic grounds.  A canonical example
is the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of 'a | B of ('a * 'a) t
val z : int t = B (B (A ((1, 2), (3, 4))))</programlisting>
<simpara>The presence of the recursion in the datatype declaration might appear
to cause the need for the monomorphiser to create an infinite number
of types.  However, due to the absence of polymorphic recursion in
SML, there are in fact only a finite number of instances of such types
in any given program.  The monomorphiser translates the above program
to the following one.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t1 = B1 of t2
datatype t2 = B2 of t3
datatype t3 = A3 of (int * int) * (int * int)
val z : int t = B1 (B2 (A3 ((1, 2), (3, 4))))</programlisting>
<simpara>It is crucial that the monomorphiser be allowed to drop unused
constructors from datatype declarations in order for the translation
to terminate.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="MoscowML">
<title>MoscowML</title>
<simpara><ulink url="http://mosml.org">Moscow ML</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link>.  It is a
byte-code compiler, so it compiles code quickly, but the code runs
slowly.  See <link linkend="Performance">Performance</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Multi">
<title>Multi</title>
<simpara><link linkend="Multi">Multi</link> is an analysis pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ConstantPropagation">ConstantPropagation</link> and
<link linkend="LocalRef">LocalRef</link>.</simpara>
<section id="_description_39">
<title>Description</title>
<simpara>This pass analyzes the control flow of a <link linkend="SSA">SSA</link> program to determine
which <link linkend="SSA">SSA</link> functions and blocks might be executed more than once or
by more than one thread.  It also determines when a program uses
threads and when functions and blocks directly or indirectly invoke
<literal>Thread_copyCurrent</literal>.</simpara>
</section>
<section id="_implementation_42">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/multi.sig"><literal>multi.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/multi.fun"><literal>multi.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_42">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Mutable">
<title>Mutable</title>
<simpara>Mutable is an adjective meaning "can be modified".  In
<link linkend="StandardML">Standard ML</link>, ref cells and arrays are mutable, while all
other values are <link linkend="Immutable">immutable</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="NeedsReview">
<title>NeedsReview</title>
<simpara>This page documents some patches and bug fixes that need additional review by experienced developers:</simpara>
<itemizedlist>
<listitem>
<simpara>
Bug in transparent signature match:
</simpara>
<itemizedlist>
<listitem>
<simpara>
What is an <emphasis>original</emphasis> interface and why does the equivalence of original interfaces implies the equivalence of the actual interfaces?
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2007-September/029991.html">http://www.mlton.org/pipermail/mlton/2007-September/029991.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2007-September/029995.html">http://www.mlton.org/pipermail/mlton/2007-September/029995.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
SVN Revision: <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6046"><literal>r6046</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Bug in <link linkend="DeepFlatten">DeepFlatten</link> pass:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Should we allow argument to <literal>Weak_new</literal> to be flattened?
</simpara>
</listitem>
<listitem>
<simpara>
SVN Revision: <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6189"><literal>r6189</literal></ulink> (regression test demonstrating bug)
</simpara>
</listitem>
<listitem>
<simpara>
SVN Revision: <ulink url="https://github.com/MLton/mlton/commit/%3A%2FSVN%20r6191"><literal>r6191</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="NumericLiteral">
<title>NumericLiteral</title>
<simpara>Numeric literals in <link linkend="StandardML">Standard ML</link> can be written in either
decimal or hexadecimal notation.  Sometimes it can be convenient to
write numbers down in other bases.  Fortunately, using <link linkend="Fold">Fold</link>, it is
possible to define a concise syntax for numeric literals that allows
one to write numeric constants in any base and of various types
(<literal>int</literal>, <literal>IntInf.int</literal>, <literal>word</literal>, and more).</simpara>
<simpara>We will define constants <literal>I</literal>, <literal>II</literal>, <literal>W</literal>, and <literal>`</literal> so
that, for example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">I 10 `1`2`3 $</programlisting>
<simpara>denotes <literal>123:int</literal> in base 10, while</simpara>
<programlisting language="sml" linenumbering="unnumbered">II 8 `2`3 $</programlisting>
<simpara>denotes <literal>19:IntInf.int</literal> in base 8, and</simpara>
<programlisting language="sml" linenumbering="unnumbered">W 2 `1`1`0`1 $</programlisting>
<simpara>denotes <literal>0w13: word</literal>.</simpara>
<simpara>Here is the code.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Num =
   struct
      fun make (op *, op +, i2x) iBase =
          let
             val xBase = i2x iBase
          in
             Fold.fold
                ((i2x 0,
                  fn (i, x) =&gt;
                     if 0 &lt;= i andalso i &lt; iBase then
                        x * xBase + i2x i
                     else
                        raise Fail (concat
                                       ["Num: ", Int.toString i,
                                        " is not a valid\
                                        \ digit in base ",
                                        Int.toString iBase])),
                 fst)
          end

      fun I  ? = make (op *, op +, id) ?
      fun II ? = make (op *, op +, IntInf.fromInt) ?
      fun W  ? = make (op *, op +, Word.fromInt) ?

      fun ` ? = Fold.step1 (fn (i, (x, step)) =&gt;
                               (step (i, x), step)) ?

      val a = 10
      val b = 11
      val c = 12
      val d = 13
      val e = 14
      val f = 15
   end</programlisting>
<simpara>where</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun fst (x, _) = x</programlisting>
<simpara>The idea is for the fold to start with zero and to construct the
result one digit at a time, with each stepper multiplying the previous
result by the base and adding the next digit.  The code is abstracted
in two different ways for extra generality.  First, the <literal>make</literal>
function abstracts over the various primitive operations (addition,
multiplication, etc) that are needed to construct a number.  This
allows the same code to be shared for constants <literal>I</literal>, <literal>II</literal>, <literal>W</literal> used to
write down the various numeric types.  It also allows users to add new
constants for additional numeric types, by supplying the necessary
arguments to make.</simpara>
<simpara>Second, the step function, <literal>&grave;</literal>, is abstracted over the actual
construction operation, which is created by make, and passed along the
fold.  This allows the same constant, <literal>&grave;</literal>, to be used for all
numeric types.  The alternative approach, having a different step
function for each numeric type, would be more painful to use.</simpara>
<simpara>On the surface, it appears that the code checks the digits dynamically
to ensure they are valid for the base.  However, MLton will simplify
everything away at compile time, leaving just the final numeric
constant.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ObjectOrientedProgramming">
<title>ObjectOrientedProgramming</title>
<simpara><link linkend="StandardML">Standard ML</link> does not have explicit support for
object-oriented programming.  Here are some papers that show how to
express certain object-oriented concepts in SML.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Berthomieu00">OO Programming styles in ML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_ThorupTofte94">Object-oriented programming and Standard ML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_LarsenNiss04">mGTK: An SML binding of Gtk+</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_FluetPucella06">Phantom Types and Subtyping</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The question of OO programming in SML comes up every now and then.
The following discusses a simple object-oriented (OO) programming
technique in Standard ML.  The reader is assumed to be able to read
Java and SML code.</simpara>
<section id="_motivation">
<title>Motivation</title>
<simpara>SML doesn&#8217;t provide subtyping, but it does provide parametric
polymorphism, which can be used to encode some forms of subtyping.
Most articles on OO programming in SML concentrate on such encoding
techniques.  While those techniques are interesting&#8201;&#8212;&#8201;and it is
recommended to read such articles&#8201;&#8212;&#8201;and sometimes useful, it seems
that basically all OO gurus agree that (deep) subtyping (or
inheritance) hierarchies aren&#8217;t as practical as they were thought to
be in the early OO days.  "Good", flexible, "OO" designs tend to have
a flat structure</simpara>
<screen>         Interface
             ^
             |
- - -+-------+-------+- - -
     |       |       |
   ImplA   ImplB   ImplC</screen>
<simpara>and deep inheritance hierarchies</simpara>
<screen>ClassA
  ^
  |
ClassB
  ^
  |
ClassC
  ^
  |</screen>
<simpara>tend to be signs of design mistakes.  There are good underlying
reasons for this, but a thorough discussion is not in the scope of
this article.  However, the point is that perhaps the encoding of
subtyping is not as important as one might believe.  In the following
we ignore subtyping and rather concentrate on a very simple and basic
dynamic dispatch technique.</simpara>
</section>
<section id="_dynamic_dispatch_using_a_recursive_record_of_functions">
<title>Dynamic Dispatch Using a Recursive Record of Functions</title>
<simpara>Quite simply, the basic idea is to implement a "virtual function
table" using a record that is wrapped inside a (possibly recursive)
datatype.  Let&#8217;s first take a look at a simple concrete example.</simpara>
<simpara>Consider the following Java interface:</simpara>
<screen>public interface Counter {
  public void inc();
  public int get();
}</screen>
<simpara>We can translate the <literal>Counter</literal> interface to SML as follows:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype counter = Counter of {inc : unit -&gt; unit, get : unit -&gt; int}</programlisting>
<simpara>Each value of type <literal>counter</literal> can be thought of as an object that
responds to two messages <literal>inc</literal> and <literal>get</literal>.  To actually send messages
to a counter, it is useful to define auxiliary functions</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
   fun mk m (Counter t) = m t ()
in
   val cGet = mk#get
   val cInc = mk#inc
end</programlisting>
<simpara>that basically extract the "function table" <literal>t</literal> from a counter object
and then select the specified method <literal>m</literal> from the table.</simpara>
<simpara>Let&#8217;s then implement a simple function that increments a counter until a
given maximum is reached:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun incUpto counter max = while cGet counter &lt; max do cInc counter</programlisting>
<simpara>You can easily verify that the above code compiles even without any
concrete implementation of a counter, thus it is clear that it doesn&#8217;t
depend on a particular counter implementation.</simpara>
<simpara>Let&#8217;s then implement a couple of counters.  First consider the
following Java class implementing the <literal>Counter</literal> interface given earlier.</simpara>
<screen>public class BasicCounter implements Counter {
  private int cnt;
  public BasicCounter(int initialCnt) { this.cnt = initialCnt; }
  public void inc() { this.cnt += 1; }
  public int get() { return this.cnt; }
}</screen>
<simpara>We can translate the above to SML as follows:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun newBasicCounter initialCnt = let
       val cnt = ref initialCnt
    in
       Counter {inc = fn () =&gt; cnt := !cnt + 1,
                get = fn () =&gt; !cnt}
    end</programlisting>
<simpara>The SML function <literal>newBasicCounter</literal> can be described as a constructor
function for counter objects of the <literal>BasicCounter</literal> "class".  We can
also have other counter implementations.  Here is the constructor for
a counter decorator that logs messages:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun newLoggedCounter counter =
    Counter {inc = fn () =&gt; (print "inc\n" ; cInc counter),
             get = fn () =&gt; (print "get\n" ; cGet counter)}</programlisting>
<simpara>The <literal>incUpto</literal> function works just as well with objects of either
class:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val aCounter = newBasicCounter 0
val () = incUpto aCounter 5
val () = print (Int.toString (cGet aCounter) ^"\n")

val aCounter = newLoggedCounter (newBasicCounter 0)
val () = incUpto aCounter 5
val () = print (Int.toString (cGet aCounter) ^"\n")</programlisting>
<simpara>In general, a dynamic dispatch interface is represented as a record
type wrapped inside a datatype.  Each field of the record corresponds
to a public method or field of the object:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype interface =
   Interface of {method : t1 -&gt; t2,
                 immutableField : t,
                 mutableField : t ref}</programlisting>
<simpara>The reason for wrapping the record inside a datatype is that records,
in SML, can not be recursive.  However, SML datatypes can be
recursive.  A record wrapped in a datatype can contain fields that
contain the datatype.  For example, an interface such as <literal>Cloneable</literal></simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype cloneable = Cloneable of {clone : unit -&gt; cloneable}</programlisting>
<simpara>can be represented using recursive datatypes.</simpara>
<simpara>Like in OO languages, interfaces are abstract and can not be
instantiated to produce objects.  To be able to instantiate objects,
the constructors of a concrete class are needed.  In SML, we can
implement constructors as simple functions from arbitrary arguments to
values of the interface type.  Such a constructor function can
encapsulate arbitrary private state and functions using lexical
closure.  It is also easy to share implementations of methods between
two or more constructors.</simpara>
<simpara>While the <literal>Counter</literal> example is rather trivial, it should not be
difficult to see that this technique quite simply doesn&#8217;t require a huge
amount of extra verbiage and is more than usable in practice.</simpara>
</section>
<section id="_sml_modules_and_dynamic_dispatch">
<title>SML Modules and Dynamic Dispatch</title>
<simpara>One might wonder about how SML modules and the dynamic dispatch
technique work together.  Let&#8217;s investigate!  Let&#8217;s use a simple
dispenser framework as a concrete example.  (Note that this isn&#8217;t
intended to be an introduction to the SML module system.)</simpara>
<section id="_programming_with_sml_modules">
<title>Programming with SML Modules</title>
<simpara>Using SML signatures we can specify abstract data types (ADTs) such as
dispensers.  Here is a signature for an "abstract" functional (as
opposed to imperative) dispenser:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature ABSTRACT_DISPENSER = sig
   type 'a t
   val isEmpty : 'a t -&gt; bool
   val push : 'a * 'a t -&gt; 'a t
   val pop : 'a t -&gt; ('a * 'a t) option
end</programlisting>
<simpara>The term "abstract" in the name of the signature refers to the fact that
the signature gives no way to instantiate a dispenser.  It has nothing to
do with the concept of abstract data types.</simpara>
<simpara>Using SML functors we can write "generic" algorithms that manipulate
dispensers of an unknown type.  Here are a couple of very simple
algorithms:</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor DispenserAlgs (D : ABSTRACT_DISPENSER) = struct
   open D

   fun pushAll (xs, d) = foldl push d xs

   fun popAll d = let
          fun lp (xs, NONE) = rev xs
            | lp (xs, SOME (x, d)) = lp (x::xs, pop d)
       in
          lp ([], pop d)
       end

   fun cp (from, to) = pushAll (popAll from, to)
end</programlisting>
<simpara>As one can easily verify, the above compiles even without any concrete
dispenser structure.  Functors essentially provide a form a static
dispatch that one can use to break compile-time dependencies.</simpara>
<simpara>We can also give a signature for a concrete dispenser</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature DISPENSER = sig
   include ABSTRACT_DISPENSER
   val empty : 'a t
end</programlisting>
<simpara>and write any number of concrete structures implementing the signature.
For example, we could implement stacks</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Stack :&gt; DISPENSER = struct
   type 'a t = 'a list
   val empty = []
   val isEmpty = null
   val push = op ::
   val pop = List.getItem
end</programlisting>
<simpara>and queues</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Queue :&gt; DISPENSER = struct
   datatype 'a t = T of 'a list * 'a list
   val empty = T ([], [])
   val isEmpty = fn T ([], _) =&gt; true | _ =&gt; false
   val normalize = fn ([], ys) =&gt; (rev ys, []) | q =&gt; q
   fun push (y, T (xs, ys)) = T (normalize (xs, y::ys))
   val pop = fn (T (x::xs, ys)) =&gt; SOME (x, T (normalize (xs, ys))) | _ =&gt; NONE
end</programlisting>
<simpara>One can now write code that uses either the <literal>Stack</literal> or the <literal>Queue</literal>
dispenser.  One can also instantiate the previously defined functor to
create functions for manipulating dispensers of a type:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S = DispenserAlgs (Stack)
val [4,3,2,1] = S.popAll (S.pushAll ([1,2,3,4], Stack.empty))

structure Q = DispenserAlgs (Queue)
val [1,2,3,4] = Q.popAll (Q.pushAll ([1,2,3,4], Queue.empty))</programlisting>
<simpara>There is no dynamic dispatch involved at the module level in SML.  An
attempt to do dynamic dispatch</simpara>
<programlisting language="sml" linenumbering="unnumbered">val q = Q.push (1, Stack.empty)</programlisting>
<simpara>will give a type error.</simpara>
</section>
<section id="_combining_sml_modules_and_dynamic_dispatch">
<title>Combining SML Modules and Dynamic Dispatch</title>
<simpara>Let&#8217;s then combine SML modules and the dynamic dispatch technique
introduced in this article.  First we define an interface for
dispensers:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Dispenser = struct
   datatype 'a t =
      I of {isEmpty : unit -&gt; bool,
            push : 'a -&gt; 'a t,
            pop : unit -&gt; ('a * 'a t) option}

   fun O m (I t) = m t

   fun isEmpty t = O#isEmpty t ()
   fun push (v, t) = O#push t v
   fun pop t = O#pop t ()
end</programlisting>
<simpara>The <literal>Dispenser</literal> module, which we can think of as an interface for
dispensers, implements the <literal>ABSTRACT_DISPENSER</literal> signature using
the dynamic dispatch technique, but we leave the signature ascription
until later.</simpara>
<simpara>Then we define a <literal>DispenserClass</literal> functor that makes a "class" out of
a given dispenser module:</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor DispenserClass (D : DISPENSER) : DISPENSER = struct
   open Dispenser

   fun make d =
       I {isEmpty = fn () =&gt; D.isEmpty d,
          push = fn x =&gt; make (D.push (x, d)),
          pop = fn () =&gt;
                   case D.pop d of
                      NONE =&gt; NONE
                    | SOME (x, d) =&gt; SOME (x, make d)}

   val empty =
       I {isEmpty = fn () =&gt; true,
          push = fn x =&gt; make (D.push (x, D.empty)),
          pop = fn () =&gt; NONE}
end</programlisting>
<simpara>Finally we seal the <literal>Dispenser</literal> module:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Dispenser : ABSTRACT_DISPENSER = Dispenser</programlisting>
<simpara>This isn&#8217;t necessary for type safety, because the unsealed <literal>Dispenser</literal>
module does not allow one to break encapsulation, but makes sure that
only the <literal>DispenserClass</literal> functor can create dispenser classes
(because the constructor <literal>Dispenser.I</literal> is no longer accessible).</simpara>
<simpara>Using the <literal>DispenserClass</literal> functor we can turn any concrete dispenser
module into a dispenser class:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure StackClass = DispenserClass (Stack)
structure QueueClass = DispenserClass (Queue)</programlisting>
<simpara>Each dispenser class implements the same dynamic dispatch interface
and the <literal>ABSTRACT_DISPENSER</literal> -signature.</simpara>
<simpara>Because the dynamic dispatch <literal>Dispenser</literal> module implements the
<literal>ABSTRACT_DISPENSER</literal>-signature, we can use it to instantiate the
<literal>DispenserAlgs</literal>-functor:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure D = DispenserAlgs (Dispenser)</programlisting>
<simpara>The resulting <literal>D</literal> module, like the <literal>Dispenser</literal> module, works with
any dispenser class and uses dynamic dispatch:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val [4, 3, 2, 1] = D.popAll (D.pushAll ([1, 2, 3, 4], StackClass.empty))
val [1, 2, 3, 4] = D.popAll (D.pushAll ([1, 2, 3, 4], QueueClass.empty))</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="OCaml">
<title>OCaml</title>
<simpara><ulink url="http://caml.inria.fr/">OCaml</ulink> is a variant of <link linkend="ML">ML</link> and is similar to
<link linkend="StandardML">Standard ML</link>.</simpara>
<section id="_ocaml_and_sml">
<title>OCaml and SML</title>
<simpara>Here&#8217;s a comparison of some aspects of the OCaml and SML languages.</simpara>
<itemizedlist>
<listitem>
<simpara>
Standard ML has a formal <link linkend="DefinitionOfStandardML">Definition</link>, while
OCaml is specified by its lone implementation and informal
documentation.
</simpara>
</listitem>
<listitem>
<simpara>
Standard ML has a number of <link linkend="StandardMLImplementations">compilers</link>,
while OCaml has only one.
</simpara>
</listitem>
<listitem>
<simpara>
OCaml has built-in support for object-oriented programming, while
Standard ML does not (however, see <link linkend="ObjectOrientedProgramming">ObjectOrientedProgramming</link>).
</simpara>
</listitem>
<listitem>
<simpara>
Andreas Rossberg has a
<ulink url="http://www.mpi-sws.org/%7Erossberg/sml-vs-ocaml.html">side-by-side
comparison</ulink> of the syntax of SML and OCaml.
</simpara>
</listitem>
<listitem>
<simpara>
Adam Chlipala has a
<ulink url="http://adam.chlipala.net/mlcomp">point-by-point comparison</ulink> of OCaml
and SML.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_ocaml_and_mlton">
<title>OCaml and MLton</title>
<simpara>Here&#8217;s a comparison of some aspects of OCaml and MLton.</simpara>
<itemizedlist>
<listitem>
<simpara>
Performance
</simpara>
<itemizedlist>
<listitem>
<simpara>
Both OCaml and MLton have excellent performance.
</simpara>
</listitem>
<listitem>
<simpara>
MLton performs extensive <link linkend="WholeProgramOptimization">WholeProgramOptimization</link>, which can
provide substantial improvements in large, modular programs.
</simpara>
</listitem>
<listitem>
<simpara>
MLton uses native types, like 32-bit integers, without any penalty
due to tagging or boxing.  OCaml uses 31-bit integers with a penalty
due to tagging, and 32-bit integers with a penalty due to boxing.
</simpara>
</listitem>
<listitem>
<simpara>
MLton uses native types, like 64-bit floats, without any penalty
due to boxing.  OCaml, in some situations, boxes 64-bit floats.
</simpara>
</listitem>
<listitem>
<simpara>
MLton represents arrays of all types unboxed.  In OCaml, only
arrays of 64-bit floats are unboxed, and then only when it is
syntactically apparent.
</simpara>
</listitem>
<listitem>
<simpara>
MLton represents records compactly by reordering and packing the
fields.
</simpara>
</listitem>
<listitem>
<simpara>
In MLton, polymorphic and monomorphic code have the same
performance.  In OCaml, polymorphism can introduce a performance
penalty.
</simpara>
</listitem>
<listitem>
<simpara>
In MLton, module boundaries have no impact on performance.  In
OCaml, moving code between modules can cause a performance penalty.
</simpara>
</listitem>
<listitem>
<simpara>
MLton&#8217;s <link linkend="ForeignFunctionInterface">ForeignFunctionInterface</link> is simpler than OCaml&#8217;s.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools
</simpara>
<itemizedlist>
<listitem>
<simpara>
OCaml has a debugger, while MLton does not.
</simpara>
</listitem>
<listitem>
<simpara>
OCaml supports separate compilation, while MLton does not.
</simpara>
</listitem>
<listitem>
<simpara>
OCaml compiles faster than MLton.
</simpara>
</listitem>
<listitem>
<simpara>
MLton supports profiling of both time and allocation.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Libraries
</simpara>
<itemizedlist>
<listitem>
<simpara>
OCaml has more available libraries.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Community
</simpara>
<itemizedlist>
<listitem>
<simpara>
OCaml has a larger community than MLton.
</simpara>
</listitem>
<listitem>
<simpara>
MLton has a very responsive
   <ulink url="http://www.mlton.org/mailman/listinfo/mlton">developer list</ulink>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="OpenGL">
<title>OpenGL</title>
<simpara>There are at least two interfaces to OpenGL for MLton/SML, both of
which should be considered alpha quality.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MikeThomas">MikeThomas</link> built a low-level interface, directly translating
many of the functions, covering GL, GLU, and GLUT.  This is available
in the MLton <link linkend="Sources">Sources</link>:
<ulink url="https://github.com/MLton/mltonlib/tree/master/org/mlton/mike/opengl"><literal>opengl</literal></ulink>.  The code
contains a number of small, standard OpenGL examples translated to
SML.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ChrisClearwater">ChrisClearwater</link> has written at least an interface to GL, and
possibly more.  See
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://mlton.org/pipermail/mlton/2005-January/026669.html">http://mlton.org/pipermail/mlton/2005-January/026669.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><link linkend="Contact">Contact</link> us for more information or an update on the status of
these projects.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="OperatorPrecedence">
<title>OperatorPrecedence</title>
<simpara><link linkend="StandardML">Standard ML</link> has a built in notion of precedence for
certain symbols.  Every program that includes the
<link linkend="BasisLibrary">Basis Library</link> automatically gets the following infix
declarations.  Higher number indicates higher precedence.</simpara>
<programlisting language="sml" linenumbering="unnumbered">infix 7 * / mod div
infix 6 + - ^
infixr 5 :: @
infix 4 = &lt;&gt; &gt; &gt;= &lt; &lt;=
infix 3 := o
infix 0 before</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="OptionalArguments">
<title>OptionalArguments</title>
<simpara><link linkend="StandardML">Standard ML</link> does not have built-in support for optional
arguments.  Nevertheless, using <link linkend="Fold">Fold</link>, it is easy to define
functions that take optional arguments.</simpara>
<simpara>For example, suppose that we have the following definition of a
function <literal>f</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (i, r, s) =
   concat [Int.toString i, ", ", Real.toString r, ", ", s]</programlisting>
<simpara>Using the <literal>OptionalArg</literal> structure described below, we can define a
function <literal>f'</literal>, an optionalized version of <literal>f</literal>, that takes 0, 1, 2, or
3 arguments.  Embedded within <literal>f'</literal> will be default values for <literal>i</literal>,
<literal>r</literal>, and <literal>s</literal>.  If <literal>f'</literal> gets no arguments, then all the defaults are
used.  If <literal>f'</literal> gets one argument, then that will be used for <literal>i</literal>.  Two
arguments will be used for <literal>i</literal> and <literal>r</literal> respectively.  Three arguments
will override all default values.  Calls to <literal>f'</literal> will look like the
following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">f' $
f' `2 $
f' `2 `3.0 $
f' `2 `3.0 `"four" $</programlisting>
<simpara>The optional argument indicator, <literal>&grave;</literal>, is not special syntax ---
it is a normal SML value, defined in the <literal>OptionalArg</literal> structure
below.</simpara>
<simpara>Here is the definition of <literal>f'</literal> using the <literal>OptionalArg</literal> structure, in
particular, <literal>OptionalArg.make</literal> and <literal>OptionalArg.D</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f' =
   fn z =&gt;
   let open OptionalArg in
      make (D 1) (D 2.0) (D "three") $
   end (fn i &amp; r &amp; s =&gt; f (i, r, s))
   z</programlisting>
<simpara>The definition of <literal>f'</literal> is eta expanded as with all uses of fold.  A
call to <literal>OptionalArg.make</literal> is supplied with a variable number of
defaults (in this case, three), the end-of-arguments terminator, <literal>$</literal>,
and the function to run, taking its arguments as an n-ary
<link linkend="ProductType">product</link>.  In this case, the function simply converts
the product to an ordinary tuple and calls <literal>f</literal>.  Often, the function
body will simply be written directly.</simpara>
<simpara>In general, the definition of an optional-argument function looks like
the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f =
   fn z =&gt;
   let open OptionalArg in
      make (D &lt;default1&gt;) (D &lt;default2&gt;) ... (D &lt;defaultn&gt;) $
   end (fn x1 &amp; x2 &amp; ... &amp; xn =&gt;
        &lt;function code goes here&gt;)
   z</programlisting>
<simpara>Here is the definition of <literal>OptionalArg</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure OptionalArg =
   struct
      val make =
         fn z =&gt;
         Fold.fold
         ((id, fn (f, x) =&gt; f x),
          fn (d, r) =&gt; fn func =&gt;
          Fold.fold ((id, d ()), fn (f, d) =&gt;
                     let
                        val d &amp; () = r (id, f d)
                     in
                        func d
                     end))
         z

      fun D d = Fold.step0 (fn (f, r) =&gt;
                            (fn ds =&gt; f (d &amp; ds),
                             fn (f, a &amp; b) =&gt; r (fn x =&gt; f a &amp; x, b)))

      val ` =
         fn z =&gt;
         Fold.step1 (fn (x, (f, _ &amp; d)) =&gt; (fn d =&gt; f (x &amp; d), d))
         z
   end</programlisting>
<simpara><literal>OptionalArg.make</literal> uses a nested fold.  The first <literal>fold</literal> accumulates
the default values in a product, associated to the right, and a
reversal function that converts a product (of the same arity as the
number of defaults) from right associativity to left associativity.
The accumulated defaults are used by the second fold, which recurs
over the product, replacing the appropriate component as it encounters
optional arguments.  The second fold also constructs a "fill"
function, <literal>f</literal>, that is used to reconstruct the product once the
end-of-arguments is reached.  Finally, the finisher reconstructs the
product and uses the reversal function to convert the product from
right associative to left associative, at which point it is passed to
the user-supplied function.</simpara>
<simpara>Much of the complexity comes from the fact that while recurring over a
product from left to right, one wants it to be right-associative,
e.g., look like</simpara>
<programlisting language="sml" linenumbering="unnumbered">a &amp; (b &amp; (c &amp; d))</programlisting>
<simpara>but the user function in the end wants the product to be left
associative, so that the product argument pattern can be written
without parentheses (since <literal>&amp;</literal> is left associative).</simpara>
<section id="_labelled_optional_arguments">
<title>Labelled optional arguments</title>
<simpara>In addition to the positional optional arguments described above, it
is sometimes useful to have labelled optional arguments.  These allow
one to define a function, <literal>f</literal>, with defaults, say <literal>a</literal> and <literal>b</literal>.  Then,
a caller of <literal>f</literal> can supply values for <literal>a</literal> and <literal>b</literal> by name.  If no
value is supplied then the default is used.</simpara>
<simpara>Labelled optional arguments are a simple extension of
<link linkend="FunctionalRecordUpdate">FunctionalRecordUpdate</link> using post composition.  Suppose, for
example, that one wants a function <literal>f</literal> with labelled optional
arguments <literal>a</literal> and <literal>b</literal> with default values <literal>0</literal> and <literal>0.0</literal> respectively.
If one has a functional-record-update function <literal>updateAB</literal> for records
with <literal>a</literal> and <literal>b</literal> fields, then one can define <literal>f</literal> in the following way.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f =
   fn z =&gt;
   Fold.post
   (updateAB {a = 0, b = 0.0},
    fn {a, b} =&gt; print (concat [Int.toString a, " ",
                                Real.toString b, "\n"]))
   z</programlisting>
<simpara>The idea is that <literal>f</literal> is the post composition (using <literal>Fold.post</literal>) of
the actual code for the function with a functional-record updater that
starts with the defaults.</simpara>
<simpara>Here are some example calls to <literal>f</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = f $
val () = f (U#a 13) $
val () = f (U#a 13) (U#b 17.5) $
val () = f (U#b 17.5) (U#a 13) $</programlisting>
<simpara>Notice that a caller can supply neither of the arguments, either of
the arguments, or both of the arguments, and in either order.  All
that matter is that the arguments be labelled correctly (and of the
right type, of course).</simpara>
<simpara>Here is another example.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f =
   fn z =&gt;
   Fold.post
   (updateBCD {b = 0, c = 0.0, d = "&lt;&gt;"},
    fn {b, c, d} =&gt;
    print (concat [Int.toString b, " ",
                   Real.toString c, " ",
                   d, "\n"]))
   z</programlisting>
<simpara>Here are some example calls.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = f $
val () = f (U#d "goodbye") $
val () = f (U#d "hello") (U#b 17) (U#c 19.3) $</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Overloading">
<title>Overloading</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, constants (like <literal>13</literal>, <literal>0w13</literal>, <literal>13.0</literal>)
are overloaded, meaning that they can denote a constant of the
appropriate type as determined by context.  SML defines the
overloading classes <emphasis>Int</emphasis>, <emphasis>Real</emphasis>, and <emphasis>Word</emphasis>, which denote the sets
of types that integer, real, and word constants may take on.  In
MLton, these are defined as follows.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><emphasis>Int</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int2.int</literal>, <literal>Int3.int</literal>, &#8230; <literal>Int32.int</literal>, <literal>Int64.int</literal>, <literal>Int.int</literal>, <literal>IntInf.int</literal>, <literal>LargeInt.int</literal>, <literal>FixedInt.int</literal>, <literal>Position.int</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><emphasis>Real</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Real32.real</literal>, <literal>Real64.real</literal>, <literal>Real.real</literal>, <literal>LargeReal.real</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><emphasis>Word</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word2.word</literal>, <literal>Word3.word</literal>, &#8230; <literal>Word32.word</literal>, <literal>Word64.word</literal>, <literal>Word.word</literal>, <literal>LargeWord.word</literal>, <literal>SysWord.word</literal></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>The <link linkend="DefinitionOfStandardML">Definition</link> allows flexibility in how
much context is used to resolve overloading.  It says that the context
is <emphasis>no larger than the smallest enclosing structure-level
declaration</emphasis>, but that <emphasis>an implementation may require that a smaller
context determines the type</emphasis>.  MLton uses the largest possible context
allowed by SML in resolving overloading.  If the type of a constant is
not determined by context, then it takes on a default type.  In MLton,
these are defined as follows.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><emphasis>Int</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Int.int</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><emphasis>Real</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Real.real</literal></simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><emphasis>Word</emphasis></simpara></entry>
<entry align="left" valign="top"><simpara><literal>Word.word</literal></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>Other implementations may use a smaller context or different default
types.</simpara>
<section id="_also_see_19">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.standardml.org/Basis/top-level-chapter.html">discussion of overloading in the Basis Library</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_examples_3">
<title>Examples</title>
<itemizedlist>
<listitem>
<simpara>
The following program is rejected.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S:
   sig
      val x: Word8.word
   end =
   struct
      val x = 0w0
   end</programlisting>
<simpara>The smallest enclosing structure declaration for <literal>0w0</literal> is
<literal>val x = 0w0</literal>.  Hence, <literal>0w0</literal> receives the default type for words,
which is <literal>Word.word</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PackedRepresentation">
<title>PackedRepresentation</title>
<simpara><link linkend="PackedRepresentation">PackedRepresentation</link> is an analysis pass for the <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="ToRSSA">ToRSSA</link>.</simpara>
<section id="_description_40">
<title>Description</title>
<simpara>This pass analyzes a <link linkend="SSA2">SSA2</link> program to compute a packed
representation for each object.</simpara>
</section>
<section id="_implementation_43">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/representation.sig"><literal>representation.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/packed-representation.fun"><literal>packed-representation.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_43">
<title>Details and Notes</title>
<simpara>Has a special case to make sure that <literal>true</literal> is represented as <literal>1</literal> and
<literal>false</literal> is represented as <literal>0</literal>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ParallelMove">
<title>ParallelMove</title>
<simpara><link linkend="ParallelMove">ParallelMove</link> is a rewrite pass, agnostic in the
<link linkend="IntermediateLanguage">IntermediateLanguage</link> which it produces.</simpara>
<section id="_description_41">
<title>Description</title>
<simpara>This function computes a sequence of individual moves to effect a
parallel move (with possibly overlapping froms and tos).</simpara>
</section>
<section id="_implementation_44">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/parallel-move.sig"><literal>parallel-move.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/parallel-move.fun"><literal>parallel-move.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_44">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Performance">
<title>Performance</title>
<simpara>This page compares the performance of a number of SML compilers on a
range of benchmarks.</simpara>
<simpara>This page compares the following SML compiler versions.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Home">MLton</link> 20171211 (git 79d4a623c)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLKit">ML Kit</link> 4.3.12 (20171210)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MoscowML">Moscow ML</link> 2.10.1 ++ (git f529b33bb, 20170711)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PolyML">Poly/ML</link> 5.7.2 Testing (git 5.7.1-35-gcb73407a)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SMLNJ">SML/NJ</link> 110.81 (20170501)
</simpara>
</listitem>
</itemizedlist>
<simpara>There are tables for <link linkend="Performance_RunTime">run time</link>, <link linkend="Performance_CodeSize">code size</link>, and
<link linkend="Performance_CompileTime">compile time</link>.</simpara>
<section id="_setup_3">
<title>Setup</title>
<simpara>All benchmarks were compiled and run on a 2.6 GHz Core i7-5600U with 16G of
RAM.  The benchmarks were compiled with the default settings for all
the compilers, except for Moscow ML, which was passed the
<literal>-orthodox -standalone -toplevel</literal> switches.  The Poly/ML executables
were produced using <literal>polyc</literal>.
The SML/NJ executables were produced by wrapping the entire program in
a <literal>local</literal> declaration whose body performs an <literal>SMLofNJ.exportFn</literal>.</simpara>
<simpara>For more details, or if you want to run the benchmarks yourself,
please see the <ulink url="https://github.com/MLton/mlton/tree/master/benchmark"><literal>benchmark</literal></ulink> directory of our
<link linkend="Sources">Sources</link>.</simpara>
<simpara>All of the benchmarks are available for download from this page.  Some
of the benchmarks were obtained from the SML/NJ benchmark suite.  Some
of the benchmarks expect certain input files to exist in the
<ulink url="https://github.com/MLton/mlton/tree/master/benchmark/tests/DATA"><literal>DATA</literal></ulink> subdirectory.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/hamlet.sml"><literal>hamlet.sml</literal></ulink> <ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DATA/hamlet-input.sml"><literal>hamlet-input.sml</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ray.sml"><literal>ray.sml</literal></ulink> <ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DATA/ray"><literal>ray</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/raytrace.sml"><literal>raytrace.sml</literal></ulink> <ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DATA/chess.gml"><literal>chess.gml</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vliw.sml"><literal>vliw.sml</literal></ulink> <ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DATA/ndotprod.s"><literal>ndotprod.s</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_performance_runtime_xreflabel_performance_runtime_run_time_ratio">
<title><anchor id="Performance_RunTime" xreflabel="[Performance_RunTime]"/>Run-time ratio</title>
<simpara>The following table gives the ratio of the run time of each benchmark
when compiled by another compiler to the run time when compiled by
MLton.  That is, the larger the number, the slower the generated code
runs.  A number larger than one indicates that the corresponding
compiler produces code that runs more slowly than MLton.  A * in an
entry means the compiler failed to compile the benchmark or that the
benchmark failed to run.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="6">
<colspec colname="col_1" colwidth="28*"/>
<colspec colname="col_2" colwidth="14*"/>
<colspec colname="col_3" colwidth="14*"/>
<colspec colname="col_4" colwidth="14*"/>
<colspec colname="col_5" colwidth="14*"/>
<colspec colname="col_6" colwidth="14*"/>
<thead>
<row>
<entry align="left" valign="top">benchmark</entry>
<entry align="left" valign="top">MLton</entry>
<entry align="left" valign="top">ML-Kit</entry>
<entry align="left" valign="top">MosML</entry>
<entry align="left" valign="top">Poly/ML</entry>
<entry align="left" valign="top">SML/NJ</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/barnes-hut.sml"><literal>barnes-hut.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>10.11</simpara></entry>
<entry align="left" valign="top"><simpara>19.36</simpara></entry>
<entry align="left" valign="top"><simpara>2.98</simpara></entry>
<entry align="left" valign="top"><simpara>1.24</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/boyer.sml"><literal>boyer.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>7.87</simpara></entry>
<entry align="left" valign="top"><simpara>1.22</simpara></entry>
<entry align="left" valign="top"><simpara>1.75</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/checksum.sml"><literal>checksum.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>30.79</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>10.94</simpara></entry>
<entry align="left" valign="top"><simpara>9.08</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/count-graphs.sml"><literal>count-graphs.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>6.51</simpara></entry>
<entry align="left" valign="top"><simpara>40.42</simpara></entry>
<entry align="left" valign="top"><simpara>2.34</simpara></entry>
<entry align="left" valign="top"><simpara>2.32</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DLXSimulator.sml"><literal>DLXSimulator.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>0.97</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.60</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/even-odd.sml"><literal>even-odd.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>0.50</simpara></entry>
<entry align="left" valign="top"><simpara>11.50</simpara></entry>
<entry align="left" valign="top"><simpara>0.42</simpara></entry>
<entry align="left" valign="top"><simpara>0.42</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/fft.sml"><literal>fft.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>7.35</simpara></entry>
<entry align="left" valign="top"><simpara>81.51</simpara></entry>
<entry align="left" valign="top"><simpara>4.03</simpara></entry>
<entry align="left" valign="top"><simpara>1.19</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/fib.sml"><literal>fib.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.41</simpara></entry>
<entry align="left" valign="top"><simpara>10.94</simpara></entry>
<entry align="left" valign="top"><simpara>1.25</simpara></entry>
<entry align="left" valign="top"><simpara>1.17</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/flat-array.sml"><literal>flat-array.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>7.19</simpara></entry>
<entry align="left" valign="top"><simpara>68.33</simpara></entry>
<entry align="left" valign="top"><simpara>5.28</simpara></entry>
<entry align="left" valign="top"><simpara>13.16</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/hamlet.sml"><literal>hamlet.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>4.97</simpara></entry>
<entry align="left" valign="top"><simpara>22.85</simpara></entry>
<entry align="left" valign="top"><simpara>1.58</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/imp-for.sml"><literal>imp-for.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>4.99</simpara></entry>
<entry align="left" valign="top"><simpara>57.84</simpara></entry>
<entry align="left" valign="top"><simpara>3.34</simpara></entry>
<entry align="left" valign="top"><simpara>4.67</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/knuth-bendix.sml"><literal>knuth-bendix.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>18.43</simpara></entry>
<entry align="left" valign="top"><simpara>3.18</simpara></entry>
<entry align="left" valign="top"><simpara>3.06</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/lexgen.sml"><literal>lexgen.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>2.76</simpara></entry>
<entry align="left" valign="top"><simpara>7.94</simpara></entry>
<entry align="left" valign="top"><simpara>3.19</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/life.sml"><literal>life.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.80</simpara></entry>
<entry align="left" valign="top"><simpara>20.19</simpara></entry>
<entry align="left" valign="top"><simpara>0.89</simpara></entry>
<entry align="left" valign="top"><simpara>1.50</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/logic.sml"><literal>logic.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>5.10</simpara></entry>
<entry align="left" valign="top"><simpara>11.06</simpara></entry>
<entry align="left" valign="top"><simpara>1.15</simpara></entry>
<entry align="left" valign="top"><simpara>1.27</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mandelbrot.sml"><literal>mandelbrot.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>3.50</simpara></entry>
<entry align="left" valign="top"><simpara>25.52</simpara></entry>
<entry align="left" valign="top"><simpara>1.33</simpara></entry>
<entry align="left" valign="top"><simpara>1.28</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/matrix-multiply.sml"><literal>matrix-multiply.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>29.40</simpara></entry>
<entry align="left" valign="top"><simpara>183.02</simpara></entry>
<entry align="left" valign="top"><simpara>7.41</simpara></entry>
<entry align="left" valign="top"><simpara>15.19</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/md5.sml"><literal>md5.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>95.18</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>32.61</simpara></entry>
<entry align="left" valign="top"><simpara>47.47</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/merge.sml"><literal>merge.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.42</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.74</simpara></entry>
<entry align="left" valign="top"><simpara>3.24</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mlyacc.sml"><literal>mlyacc.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.83</simpara></entry>
<entry align="left" valign="top"><simpara>8.45</simpara></entry>
<entry align="left" valign="top"><simpara>0.84</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/model-elimination.sml"><literal>model-elimination.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>4.03</simpara></entry>
<entry align="left" valign="top"><simpara>12.42</simpara></entry>
<entry align="left" valign="top"><simpara>1.70</simpara></entry>
<entry align="left" valign="top"><simpara>2.25</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mpuz.sml"><literal>mpuz.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>3.73</simpara></entry>
<entry align="left" valign="top"><simpara>57.44</simpara></entry>
<entry align="left" valign="top"><simpara>2.05</simpara></entry>
<entry align="left" valign="top"><simpara>3.22</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/nucleic.sml"><literal>nucleic.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>3.96</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>1.73</simpara></entry>
<entry align="left" valign="top"><simpara>1.20</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/output1.sml"><literal>output1.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>6.26</simpara></entry>
<entry align="left" valign="top"><simpara>30.85</simpara></entry>
<entry align="left" valign="top"><simpara>7.82</simpara></entry>
<entry align="left" valign="top"><simpara>5.99</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/peek.sml"><literal>peek.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>9.37</simpara></entry>
<entry align="left" valign="top"><simpara>44.78</simpara></entry>
<entry align="left" valign="top"><simpara>2.18</simpara></entry>
<entry align="left" valign="top"><simpara>2.15</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/psdes-random.sml"><literal>psdes-random.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>2.79</simpara></entry>
<entry align="left" valign="top"><simpara>3.59</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ratio-regions.sml"><literal>ratio-regions.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>5.68</simpara></entry>
<entry align="left" valign="top"><simpara>165.56</simpara></entry>
<entry align="left" valign="top"><simpara>3.92</simpara></entry>
<entry align="left" valign="top"><simpara>37.52</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ray.sml"><literal>ray.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>12.05</simpara></entry>
<entry align="left" valign="top"><simpara>25.08</simpara></entry>
<entry align="left" valign="top"><simpara>8.73</simpara></entry>
<entry align="left" valign="top"><simpara>1.75</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/raytrace.sml"><literal>raytrace.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>2.11</simpara></entry>
<entry align="left" valign="top"><simpara>3.33</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/simple.sml"><literal>simple.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>2.95</simpara></entry>
<entry align="left" valign="top"><simpara>24.03</simpara></entry>
<entry align="left" valign="top"><simpara>3.67</simpara></entry>
<entry align="left" valign="top"><simpara>1.93</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/smith-normal-form.sml"><literal>smith-normal-form.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>1.04</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/string-concat.sml"><literal>string-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.88</simpara></entry>
<entry align="left" valign="top"><simpara>28.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.70</simpara></entry>
<entry align="left" valign="top"><simpara>2.67</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tailfib.sml"><literal>tailfib.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.58</simpara></entry>
<entry align="left" valign="top"><simpara>23.57</simpara></entry>
<entry align="left" valign="top"><simpara>0.90</simpara></entry>
<entry align="left" valign="top"><simpara>1.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tak.sml"><literal>tak.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>1.69</simpara></entry>
<entry align="left" valign="top"><simpara>15.90</simpara></entry>
<entry align="left" valign="top"><simpara>1.57</simpara></entry>
<entry align="left" valign="top"><simpara>2.01</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tensor.sml"><literal>tensor.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>2.07</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tsp.sml"><literal>tsp.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>2.19</simpara></entry>
<entry align="left" valign="top"><simpara>66.76</simpara></entry>
<entry align="left" valign="top"><simpara>3.27</simpara></entry>
<entry align="left" valign="top"><simpara>1.48</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tyan.sml"><literal>tyan.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>19.43</simpara></entry>
<entry align="left" valign="top"><simpara>1.08</simpara></entry>
<entry align="left" valign="top"><simpara>1.03</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector32-concat.sml"><literal>vector32-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>13.85</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>1.80</simpara></entry>
<entry align="left" valign="top"><simpara>12.48</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector64-concat.sml"><literal>vector64-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>13.92</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector-rev.sml"><literal>vector-rev.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>7.88</simpara></entry>
<entry align="left" valign="top"><simpara>68.85</simpara></entry>
<entry align="left" valign="top"><simpara>9.39</simpara></entry>
<entry align="left" valign="top"><simpara>68.80</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vliw.sml"><literal>vliw.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>2.46</simpara></entry>
<entry align="left" valign="top"><simpara>15.39</simpara></entry>
<entry align="left" valign="top"><simpara>1.43</simpara></entry>
<entry align="left" valign="top"><simpara>1.55</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/wc-input1.sml"><literal>wc-input1.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>6.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>29.25</simpara></entry>
<entry align="left" valign="top"><simpara>9.54</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/wc-scanStream.sml"><literal>wc-scanStream.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>80.43</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>19.45</simpara></entry>
<entry align="left" valign="top"><simpara>8.71</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/zebra.sml"><literal>zebra.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>4.62</simpara></entry>
<entry align="left" valign="top"><simpara>35.56</simpara></entry>
<entry align="left" valign="top"><simpara>1.68</simpara></entry>
<entry align="left" valign="top"><simpara>9.97</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/zern.sml"><literal>zern.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1.00</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>1.60</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><anchor id="Performance_SNFNote" xreflabel="[Performance_SNFNote]"/>
Note: for SML/NJ, the
<ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/smith-normal-form.sml"><literal>smith-normal-form.sml</literal></ulink>
benchmark was killed after running for over 51,000 seconds.</simpara>
</section>
<section id="_anchor_id_performance_codesize_xreflabel_performance_codesize_code_size">
<title><anchor id="Performance_CodeSize" xreflabel="[Performance_CodeSize]"/>Code size</title>
<simpara>The following table gives the code size of each benchmark in bytes.
The size for MLton and the ML Kit is the sum of text and data for the
standalone executable as reported by <literal>size</literal>.  The size for Moscow
ML is the size in bytes of the executable <literal>a.out</literal>.  The size for
Poly/ML is the difference in size of the database before the session
start and after the commit.  The size for SML/NJ is the size of the
heap file created by <literal>exportFn</literal> and does not include the size of
the SML/NJ runtime system (approximately 100K).  A * in an entry means
that the compiler failed to compile the benchmark.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="6">
<colspec colname="col_1" colwidth="28*"/>
<colspec colname="col_2" colwidth="14*"/>
<colspec colname="col_3" colwidth="14*"/>
<colspec colname="col_4" colwidth="14*"/>
<colspec colname="col_5" colwidth="14*"/>
<colspec colname="col_6" colwidth="14*"/>
<thead>
<row>
<entry align="left" valign="top">benchmark</entry>
<entry align="left" valign="top">MLton</entry>
<entry align="left" valign="top">ML-Kit</entry>
<entry align="left" valign="top">MosML</entry>
<entry align="left" valign="top">Poly/ML</entry>
<entry align="left" valign="top">SML/NJ</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/barnes-hut.sml"><literal>barnes-hut.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>180,788</simpara></entry>
<entry align="left" valign="top"><simpara>810,267</simpara></entry>
<entry align="left" valign="top"><simpara>199,503</simpara></entry>
<entry align="left" valign="top"><simpara>148,120</simpara></entry>
<entry align="left" valign="top"><simpara>402,480</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/boyer.sml"><literal>boyer.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>250,246</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>248,018</simpara></entry>
<entry align="left" valign="top"><simpara>196,984</simpara></entry>
<entry align="left" valign="top"><simpara>496,664</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/checksum.sml"><literal>checksum.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,422</simpara></entry>
<entry align="left" valign="top"><simpara>225,274</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>106,088</simpara></entry>
<entry align="left" valign="top"><simpara>406,560</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/count-graphs.sml"><literal>count-graphs.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>151,878</simpara></entry>
<entry align="left" valign="top"><simpara>250,126</simpara></entry>
<entry align="left" valign="top"><simpara>187,048</simpara></entry>
<entry align="left" valign="top"><simpara>144,032</simpara></entry>
<entry align="left" valign="top"><simpara>428,136</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DLXSimulator.sml"><literal>DLXSimulator.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>223,073</simpara></entry>
<entry align="left" valign="top"><simpara>827,483</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>272,664</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/even-odd.sml"><literal>even-odd.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,350</simpara></entry>
<entry align="left" valign="top"><simpara>87,586</simpara></entry>
<entry align="left" valign="top"><simpara>181,415</simpara></entry>
<entry align="left" valign="top"><simpara>106,072</simpara></entry>
<entry align="left" valign="top"><simpara>380,928</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/fft.sml"><literal>fft.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>145,008</simpara></entry>
<entry align="left" valign="top"><simpara>237,230</simpara></entry>
<entry align="left" valign="top"><simpara>186,228</simpara></entry>
<entry align="left" valign="top"><simpara>131,400</simpara></entry>
<entry align="left" valign="top"><simpara>418,896</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/fib.sml"><literal>fib.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,310</simpara></entry>
<entry align="left" valign="top"><simpara>87,402</simpara></entry>
<entry align="left" valign="top"><simpara>181,312</simpara></entry>
<entry align="left" valign="top"><simpara>106,088</simpara></entry>
<entry align="left" valign="top"><simpara>380,928</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/flat-array.sml"><literal>flat-array.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>121,958</simpara></entry>
<entry align="left" valign="top"><simpara>104,102</simpara></entry>
<entry align="left" valign="top"><simpara>181,464</simpara></entry>
<entry align="left" valign="top"><simpara>106,072</simpara></entry>
<entry align="left" valign="top"><simpara>394,256</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/hamlet.sml"><literal>hamlet.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>1,503,849</simpara></entry>
<entry align="left" valign="top"><simpara>2,280,691</simpara></entry>
<entry align="left" valign="top"><simpara>407,219</simpara></entry>
<entry align="left" valign="top"><simpara>2,249,504</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/imp-for.sml"><literal>imp-for.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,078</simpara></entry>
<entry align="left" valign="top"><simpara>89,346</simpara></entry>
<entry align="left" valign="top"><simpara>181,470</simpara></entry>
<entry align="left" valign="top"><simpara>106,088</simpara></entry>
<entry align="left" valign="top"><simpara>381,952</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/knuth-bendix.sml"><literal>knuth-bendix.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>193,145</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>192,659</simpara></entry>
<entry align="left" valign="top"><simpara>161,080</simpara></entry>
<entry align="left" valign="top"><simpara>400,408</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/lexgen.sml"><literal>lexgen.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>308,296</simpara></entry>
<entry align="left" valign="top"><simpara>826,819</simpara></entry>
<entry align="left" valign="top"><simpara>213,128</simpara></entry>
<entry align="left" valign="top"><simpara>268,272</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/life.sml"><literal>life.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>141,862</simpara></entry>
<entry align="left" valign="top"><simpara>721,419</simpara></entry>
<entry align="left" valign="top"><simpara>186,463</simpara></entry>
<entry align="left" valign="top"><simpara>118,552</simpara></entry>
<entry align="left" valign="top"><simpara>384,024</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/logic.sml"><literal>logic.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>211,086</simpara></entry>
<entry align="left" valign="top"><simpara>782,667</simpara></entry>
<entry align="left" valign="top"><simpara>188,908</simpara></entry>
<entry align="left" valign="top"><simpara>198,408</simpara></entry>
<entry align="left" valign="top"><simpara>409,624</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mandelbrot.sml"><literal>mandelbrot.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,086</simpara></entry>
<entry align="left" valign="top"><simpara>700,075</simpara></entry>
<entry align="left" valign="top"><simpara>183,037</simpara></entry>
<entry align="left" valign="top"><simpara>106,104</simpara></entry>
<entry align="left" valign="top"><simpara>386,048</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/matrix-multiply.sml"><literal>matrix-multiply.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>124,398</simpara></entry>
<entry align="left" valign="top"><simpara>280,006</simpara></entry>
<entry align="left" valign="top"><simpara>184,328</simpara></entry>
<entry align="left" valign="top"><simpara>110,232</simpara></entry>
<entry align="left" valign="top"><simpara>416,784</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/md5.sml"><literal>md5.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>150,497</simpara></entry>
<entry align="left" valign="top"><simpara>271,794</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>122,624</simpara></entry>
<entry align="left" valign="top"><simpara>399,416</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/merge.sml"><literal>merge.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>123,846</simpara></entry>
<entry align="left" valign="top"><simpara>100,858</simpara></entry>
<entry align="left" valign="top"><simpara>181,542</simpara></entry>
<entry align="left" valign="top"><simpara>106,136</simpara></entry>
<entry align="left" valign="top"><simpara>381,960</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mlyacc.sml"><literal>mlyacc.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>678,920</simpara></entry>
<entry align="left" valign="top"><simpara>1,233,587</simpara></entry>
<entry align="left" valign="top"><simpara>263,721</simpara></entry>
<entry align="left" valign="top"><simpara>576,728</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/model-elimination.sml"><literal>model-elimination.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>846,779</simpara></entry>
<entry align="left" valign="top"><simpara>1,432,283</simpara></entry>
<entry align="left" valign="top"><simpara>297,108</simpara></entry>
<entry align="left" valign="top"><simpara>777,664</simpara></entry>
<entry align="left" valign="top"><simpara>985,304</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mpuz.sml"><literal>mpuz.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>124,126</simpara></entry>
<entry align="left" valign="top"><simpara>229,078</simpara></entry>
<entry align="left" valign="top"><simpara>184,440</simpara></entry>
<entry align="left" valign="top"><simpara>114,584</simpara></entry>
<entry align="left" valign="top"><simpara>392,232</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/nucleic.sml"><literal>nucleic.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>298,038</simpara></entry>
<entry align="left" valign="top"><simpara>507,186</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>475,808</simpara></entry>
<entry align="left" valign="top"><simpara>456,744</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/output1.sml"><literal>output1.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>157,973</simpara></entry>
<entry align="left" valign="top"><simpara>699,003</simpara></entry>
<entry align="left" valign="top"><simpara>181,680</simpara></entry>
<entry align="left" valign="top"><simpara>118,800</simpara></entry>
<entry align="left" valign="top"><simpara>380,928</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/peek.sml"><literal>peek.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>156,401</simpara></entry>
<entry align="left" valign="top"><simpara>201,138</simpara></entry>
<entry align="left" valign="top"><simpara>183,438</simpara></entry>
<entry align="left" valign="top"><simpara>110,456</simpara></entry>
<entry align="left" valign="top"><simpara>385,072</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/psdes-random.sml"><literal>psdes-random.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>126,486</simpara></entry>
<entry align="left" valign="top"><simpara>106,166</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>106,088</simpara></entry>
<entry align="left" valign="top"><simpara>393,256</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ratio-regions.sml"><literal>ratio-regions.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>150,174</simpara></entry>
<entry align="left" valign="top"><simpara>265,694</simpara></entry>
<entry align="left" valign="top"><simpara>190,088</simpara></entry>
<entry align="left" valign="top"><simpara>184,536</simpara></entry>
<entry align="left" valign="top"><simpara>414,760</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ray.sml"><literal>ray.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>260,863</simpara></entry>
<entry align="left" valign="top"><simpara>736,795</simpara></entry>
<entry align="left" valign="top"><simpara>195,064</simpara></entry>
<entry align="left" valign="top"><simpara>198,976</simpara></entry>
<entry align="left" valign="top"><simpara>512,160</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/raytrace.sml"><literal>raytrace.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>384,905</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>446,424</simpara></entry>
<entry align="left" valign="top"><simpara>623,824</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/simple.sml"><literal>simple.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>365,578</simpara></entry>
<entry align="left" valign="top"><simpara>895,139</simpara></entry>
<entry align="left" valign="top"><simpara>197,765</simpara></entry>
<entry align="left" valign="top"><simpara>1,051,952</simpara></entry>
<entry align="left" valign="top"><simpara>708,696</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/smith-normal-form.sml"><literal>smith-normal-form.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>286,474</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>262,616</simpara></entry>
<entry align="left" valign="top"><simpara>547,984</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/string-concat.sml"><literal>string-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>119,102</simpara></entry>
<entry align="left" valign="top"><simpara>140,626</simpara></entry>
<entry align="left" valign="top"><simpara>183,249</simpara></entry>
<entry align="left" valign="top"><simpara>106,088</simpara></entry>
<entry align="left" valign="top"><simpara>390,160</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tailfib.sml"><literal>tailfib.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,110</simpara></entry>
<entry align="left" valign="top"><simpara>87,890</simpara></entry>
<entry align="left" valign="top"><simpara>181,369</simpara></entry>
<entry align="left" valign="top"><simpara>106,072</simpara></entry>
<entry align="left" valign="top"><simpara>381,952</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tak.sml"><literal>tak.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,246</simpara></entry>
<entry align="left" valign="top"><simpara>87,402</simpara></entry>
<entry align="left" valign="top"><simpara>181,349</simpara></entry>
<entry align="left" valign="top"><simpara>106,088</simpara></entry>
<entry align="left" valign="top"><simpara>376,832</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tensor.sml"><literal>tensor.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>186,545</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>421,984</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tsp.sml"><literal>tsp.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>163,033</simpara></entry>
<entry align="left" valign="top"><simpara>722,571</simpara></entry>
<entry align="left" valign="top"><simpara>188,634</simpara></entry>
<entry align="left" valign="top"><simpara>126,984</simpara></entry>
<entry align="left" valign="top"><simpara>393,264</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tyan.sml"><literal>tyan.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>235,449</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>195,401</simpara></entry>
<entry align="left" valign="top"><simpara>184,816</simpara></entry>
<entry align="left" valign="top"><simpara>478,296</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector32-concat.sml"><literal>vector32-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>123,790</simpara></entry>
<entry align="left" valign="top"><simpara>104,398</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>106,200</simpara></entry>
<entry align="left" valign="top"><simpara>394,256</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector64-concat.sml"><literal>vector64-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>123,846</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>405,552</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector-rev.sml"><literal>vector-rev.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>122,982</simpara></entry>
<entry align="left" valign="top"><simpara>104,614</simpara></entry>
<entry align="left" valign="top"><simpara>181,534</simpara></entry>
<entry align="left" valign="top"><simpara>106,072</simpara></entry>
<entry align="left" valign="top"><simpara>394,256</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vliw.sml"><literal>vliw.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>538,074</simpara></entry>
<entry align="left" valign="top"><simpara>1,182,851</simpara></entry>
<entry align="left" valign="top"><simpara>249,884</simpara></entry>
<entry align="left" valign="top"><simpara>580,792</simpara></entry>
<entry align="left" valign="top"><simpara>749,752</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/wc-input1.sml"><literal>wc-input1.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>186,152</simpara></entry>
<entry align="left" valign="top"><simpara>699,459</simpara></entry>
<entry align="left" valign="top"><simpara>191,347</simpara></entry>
<entry align="left" valign="top"><simpara>127,200</simpara></entry>
<entry align="left" valign="top"><simpara>386,048</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/wc-scanStream.sml"><literal>wc-scanStream.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>196,232</simpara></entry>
<entry align="left" valign="top"><simpara>700,131</simpara></entry>
<entry align="left" valign="top"><simpara>191,539</simpara></entry>
<entry align="left" valign="top"><simpara>127,232</simpara></entry>
<entry align="left" valign="top"><simpara>387,072</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/zebra.sml"><literal>zebra.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>230,433</simpara></entry>
<entry align="left" valign="top"><simpara>128,354</simpara></entry>
<entry align="left" valign="top"><simpara>186,322</simpara></entry>
<entry align="left" valign="top"><simpara>127,048</simpara></entry>
<entry align="left" valign="top"><simpara>390,184</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/zern.sml"><literal>zern.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>156,902</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>453,768</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</section>
<section id="_anchor_id_performance_compiletime_xreflabel_performance_compiletime_compile_time">
<title><anchor id="Performance_CompileTime" xreflabel="[Performance_CompileTime]"/>Compile time</title>
<simpara>The following table gives the compile time of each benchmark in
seconds.  A * in an entry means that the compiler failed to compile
the benchmark.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="6">
<colspec colname="col_1" colwidth="28*"/>
<colspec colname="col_2" colwidth="14*"/>
<colspec colname="col_3" colwidth="14*"/>
<colspec colname="col_4" colwidth="14*"/>
<colspec colname="col_5" colwidth="14*"/>
<colspec colname="col_6" colwidth="14*"/>
<thead>
<row>
<entry align="left" valign="top">benchmark</entry>
<entry align="left" valign="top">MLton</entry>
<entry align="left" valign="top">ML-Kit</entry>
<entry align="left" valign="top">MosML</entry>
<entry align="left" valign="top">Poly/ML</entry>
<entry align="left" valign="top">SML/NJ</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/barnes-hut.sml"><literal>barnes-hut.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.70</simpara></entry>
<entry align="left" valign="top"><simpara>0.89</simpara></entry>
<entry align="left" valign="top"><simpara>0.15</simpara></entry>
<entry align="left" valign="top"><simpara>0.29</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/boyer.sml"><literal>boyer.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.87</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.14</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
<entry align="left" valign="top"><simpara>0.41</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/checksum.sml"><literal>checksum.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.21</simpara></entry>
<entry align="left" valign="top"><simpara>0.24</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/count-graphs.sml"><literal>count-graphs.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.28</simpara></entry>
<entry align="left" valign="top"><simpara>0.34</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
<entry align="left" valign="top"><simpara>0.11</simpara></entry>
<entry align="left" valign="top"><simpara>0.21</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/DLXSimulator.sml"><literal>DLXSimulator.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.93</simpara></entry>
<entry align="left" valign="top"><simpara>1.01</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.27</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/even-odd.sml"><literal>even-odd.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.23</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/fft.sml"><literal>fft.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.35</simpara></entry>
<entry align="left" valign="top"><simpara>0.28</simpara></entry>
<entry align="left" valign="top"><simpara>0.03</simpara></entry>
<entry align="left" valign="top"><simpara>0.09</simpara></entry>
<entry align="left" valign="top"><simpara>0.10</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/fib.sml"><literal>fib.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.16</simpara></entry>
<entry align="left" valign="top"><simpara>0.19</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/flat-array.sml"><literal>flat-array.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.16</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/hamlet.sml"><literal>hamlet.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>12.28</simpara></entry>
<entry align="left" valign="top"><simpara>19.25</simpara></entry>
<entry align="left" valign="top"><simpara>23.75</simpara></entry>
<entry align="left" valign="top"><simpara>6.44</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/imp-for.sml"><literal>imp-for.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.14</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/knuth-bendix.sml"><literal>knuth-bendix.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.48</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.14</simpara></entry>
<entry align="left" valign="top"><simpara>0.23</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/lexgen.sml"><literal>lexgen.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>3.31</simpara></entry>
<entry align="left" valign="top"><simpara>0.75</simpara></entry>
<entry align="left" valign="top"><simpara>0.15</simpara></entry>
<entry align="left" valign="top"><simpara>0.22</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/life.sml"><literal>life.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.25</simpara></entry>
<entry align="left" valign="top"><simpara>0.32</simpara></entry>
<entry align="left" valign="top"><simpara>0.03</simpara></entry>
<entry align="left" valign="top"><simpara>0.09</simpara></entry>
<entry align="left" valign="top"><simpara>0.10</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/logic.sml"><literal>logic.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.72</simpara></entry>
<entry align="left" valign="top"><simpara>0.57</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.17</simpara></entry>
<entry align="left" valign="top"><simpara>0.21</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mandelbrot.sml"><literal>mandelbrot.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.14</simpara></entry>
<entry align="left" valign="top"><simpara>0.24</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/matrix-multiply.sml"><literal>matrix-multiply.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.14</simpara></entry>
<entry align="left" valign="top"><simpara>0.24</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/md5.sml"><literal>md5.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.31</simpara></entry>
<entry align="left" valign="top"><simpara>0.39</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.12</simpara></entry>
<entry align="left" valign="top"><simpara>0.27</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/merge.sml"><literal>merge.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.15</simpara></entry>
<entry align="left" valign="top"><simpara>0.21</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mlyacc.sml"><literal>mlyacc.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>7.07</simpara></entry>
<entry align="left" valign="top"><simpara>4.53</simpara></entry>
<entry align="left" valign="top"><simpara>2.05</simpara></entry>
<entry align="left" valign="top"><simpara>0.80</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/model-elimination.sml"><literal>model-elimination.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>6.78</simpara></entry>
<entry align="left" valign="top"><simpara>4.76</simpara></entry>
<entry align="left" valign="top"><simpara>1.20</simpara></entry>
<entry align="left" valign="top"><simpara>1.65</simpara></entry>
<entry align="left" valign="top"><simpara>4.78</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/mpuz.sml"><literal>mpuz.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.14</simpara></entry>
<entry align="left" valign="top"><simpara>0.28</simpara></entry>
<entry align="left" valign="top"><simpara>0.02</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/nucleic.sml"><literal>nucleic.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>3.96</simpara></entry>
<entry align="left" valign="top"><simpara>2.12</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.37</simpara></entry>
<entry align="left" valign="top"><simpara>0.49</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/output1.sml"><literal>output1.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.30</simpara></entry>
<entry align="left" valign="top"><simpara>0.22</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/peek.sml"><literal>peek.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.26</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/psdes-random.sml"><literal>psdes-random.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.12</simpara></entry>
<entry align="left" valign="top"><simpara>0.22</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>9.83</simpara></entry>
<entry align="left" valign="top"><simpara>12.55</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ratio-regions.sml"><literal>ratio-regions.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.59</simpara></entry>
<entry align="left" valign="top"><simpara>0.47</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.16</simpara></entry>
<entry align="left" valign="top"><simpara>0.24</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/ray.sml"><literal>ray.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.95</simpara></entry>
<entry align="left" valign="top"><simpara>0.46</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
<entry align="left" valign="top"><simpara>0.17</simpara></entry>
<entry align="left" valign="top"><simpara>0.14</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/raytrace.sml"><literal>raytrace.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>3.93</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.45</simpara></entry>
<entry align="left" valign="top"><simpara>0.74</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/simple.sml"><literal>simple.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>3.42</simpara></entry>
<entry align="left" valign="top"><simpara>1.23</simpara></entry>
<entry align="left" valign="top"><simpara>0.30</simpara></entry>
<entry align="left" valign="top"><simpara>0.32</simpara></entry>
<entry align="left" valign="top"><simpara>0.53</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/smith-normal-form.sml"><literal>smith-normal-form.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>3.23</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.15</simpara></entry>
<entry align="left" valign="top"><simpara>0.32</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/string-concat.sml"><literal>string-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.25</simpara></entry>
<entry align="left" valign="top"><simpara>0.28</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tailfib.sml"><literal>tailfib.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.24</simpara></entry>
<entry align="left" valign="top"><simpara>0.21</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tak.sml"><literal>tak.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.23</simpara></entry>
<entry align="left" valign="top"><simpara>0.20</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tensor.sml"><literal>tensor.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.73</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.44</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tsp.sml"><literal>tsp.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.42</simpara></entry>
<entry align="left" valign="top"><simpara>0.38</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
<entry align="left" valign="top"><simpara>0.11</simpara></entry>
<entry align="left" valign="top"><simpara>0.11</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/tyan.sml"><literal>tyan.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.93</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.10</simpara></entry>
<entry align="left" valign="top"><simpara>0.27</simpara></entry>
<entry align="left" valign="top"><simpara>0.31</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector32-concat.sml"><literal>vector32-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.23</simpara></entry>
<entry align="left" valign="top"><simpara>0.22</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.07</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector64-concat.sml"><literal>vector64-concat.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.18</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.04</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vector-rev.sml"><literal>vector-rev.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.23</simpara></entry>
<entry align="left" valign="top"><simpara>0.22</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/vliw.sml"><literal>vliw.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>5.25</simpara></entry>
<entry align="left" valign="top"><simpara>2.93</simpara></entry>
<entry align="left" valign="top"><simpara>0.63</simpara></entry>
<entry align="left" valign="top"><simpara>0.94</simpara></entry>
<entry align="left" valign="top"><simpara>1.85</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/wc-input1.sml"><literal>wc-input1.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.46</simpara></entry>
<entry align="left" valign="top"><simpara>0.24</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/wc-scanStream.sml"><literal>wc-scanStream.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.61</simpara></entry>
<entry align="left" valign="top"><simpara>0.25</simpara></entry>
<entry align="left" valign="top"><simpara>0.01</simpara></entry>
<entry align="left" valign="top"><simpara>0.08</simpara></entry>
<entry align="left" valign="top"><simpara>0.05</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/zebra.sml"><literal>zebra.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.99</simpara></entry>
<entry align="left" valign="top"><simpara>0.35</simpara></entry>
<entry align="left" valign="top"><simpara>0.03</simpara></entry>
<entry align="left" valign="top"><simpara>0.09</simpara></entry>
<entry align="left" valign="top"><simpara>0.11</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><ulink url="https://raw.github.com/MLton/mlton/master/benchmark/tests/zern.sml"><literal>zern.sml</literal></ulink></simpara></entry>
<entry align="left" valign="top"><simpara>2.31</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>*</simpara></entry>
<entry align="left" valign="top"><simpara>0.11</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PhantomType">
<title>PhantomType</title>
<simpara>A phantom type is a type that has no run-time representation, but is
used to force the type checker to ensure invariants at compile time.
This is done by augmenting a type with additional arguments (phantom
type variables) and expressing constraints by choosing phantom types
to stand for the phantom types in the types of values.</simpara>
<section id="_also_see_20">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Blume01">Blume01</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
dimensions
</simpara>
</listitem>
<listitem>
<simpara>
C type system
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="References_FluetPucella06">FluetPucella06</link>
</simpara>
<itemizedlist>
<listitem>
<simpara>
subtyping
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
socket module in <link linkend="BasisLibrary">Basis Library</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PlatformSpecificNotes">
<title>PlatformSpecificNotes</title>
<simpara>Here are notes about using MLton on the following platforms.</simpara>
<section id="_operating_systems">
<title>Operating Systems</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAIX">AIX</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnCygwin">Cygwin</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnDarwin">Darwin</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnFreeBSD">FreeBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnHPUX">HPUX</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnLinux">Linux</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnMinGW">MinGW</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnNetBSD">NetBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnOpenBSD">OpenBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSolaris">Solaris</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_architectures">
<title>Architectures</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAMD64">AMD64</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnHPPA">HPPA</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC">PowerPC</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC64">PowerPC64</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSparc">Sparc</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnX86">X86</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_21">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="PortingMLton">PortingMLton</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PolyEqual">
<title>PolyEqual</title>
<simpara><link linkend="PolyEqual">PolyEqual</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_42">
<title>Description</title>
<simpara>This pass implements polymorphic equality.</simpara>
</section>
<section id="_implementation_45">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/poly-equal.fun"><literal>poly-equal.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_45">
<title>Details and Notes</title>
<simpara>For each datatype, tycon, and vector type, it builds and equality
function and translates calls to <literal>MLton_equal</literal> into calls to that
function.</simpara>
<simpara>Also generates calls to <literal>Word_equal</literal>.</simpara>
<simpara>For tuples, it does the equality test inline; i.e., it does not create
a separate equality function for each tuple type.</simpara>
<simpara>All equality functions are created only if necessary, i.e., if
equality is actually used at a type.</simpara>
<simpara>Optimizations:</simpara>
<itemizedlist>
<listitem>
<simpara>
for datatypes that are enumerations, do not build a case dispatch,
just use <literal>MLton_eq</literal>, as the backend will represent these as ints
</simpara>
</listitem>
<listitem>
<simpara>
deep equality always does an <literal>MLton_eq</literal> test first
</simpara>
</listitem>
<listitem>
<simpara>
If one argument to <literal>=</literal> is a constant and the type will get
translated to an <literal>IntOrPointer</literal>, then just use <literal>eq</literal> instead of the
full equality.  This is important for implementing code like the
following efficiently:
</simpara>
<screen>if x = 0  ...    (* where x is of type IntInf.int *)</screen>
</listitem>
<listitem>
<simpara>
Also convert pointer equality on scalar types to type specific
primitives.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PolyHash">
<title>PolyHash</title>
<simpara><link linkend="PolyHash">PolyHash</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_43">
<title>Description</title>
<simpara>This pass implements polymorphic, structural hashing.</simpara>
</section>
<section id="_implementation_46">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/poly-hash.fun"><literal>poly-hash.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_46">
<title>Details and Notes</title>
<simpara>For each datatype, tycon, and vector type, it builds and equality
function and translates calls to <literal>MLton_hash</literal> into calls to that
function.</simpara>
<simpara>For tuples, it does the equality test inline; i.e., it does not create
a separate equality function for each tuple type.</simpara>
<simpara>All equality functions are created only if necessary, i.e., if
equality is actually used at a type.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PolyML">
<title>PolyML</title>
<simpara><ulink url="http://www.polyml.org/">Poly/ML</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link>.</simpara>
<section id="_also_see_22">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Matthews95">Matthews95</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PolymorphicEquality">
<title>PolymorphicEquality</title>
<simpara>Polymorphic equality is a built-in function in
<link linkend="StandardML">Standard ML</link> that compares two values of the same type
for equality.  It is specified as</simpara>
<programlisting language="sml" linenumbering="unnumbered">val = : ''a * ''a -&gt; bool</programlisting>
<simpara>The <literal>''a</literal> in the specification are
<link linkend="EqualityTypeVariable">equality type variables</link>, and indicate that
polymorphic equality can only be applied to values of an
<link linkend="EqualityType">equality type</link>.  It is not allowed in SML to rebind
<literal>=</literal>, so a programmer is guaranteed that <literal>=</literal> always denotes polymorphic
equality.</simpara>
<section id="_equality_of_ground_types">
<title>Equality of ground types</title>
<simpara>Ground types like <literal>char</literal>, <literal>int</literal>, and <literal>word</literal> may be compared (to values
of the same type).  For example, <literal>13 = 14</literal> is type correct and yields
<literal>false</literal>.</simpara>
</section>
<section id="_equality_of_reals">
<title>Equality of reals</title>
<simpara>The one ground type that can not be compared is <literal>real</literal>.  So,
<literal>13.0 = 14.0</literal> is not type correct.  One can use <literal>Real.==</literal> to compare
reals for equality, but beware that this has different algebraic
properties than polymorphic equality.</simpara>
<simpara>See <ulink url="http://standardml.org/Basis/real.html">http://standardml.org/Basis/real.html</ulink> for a discussion of why
<literal>real</literal> is not an equality type.</simpara>
</section>
<section id="_equality_of_functions">
<title>Equality of functions</title>
<simpara>Comparison of functions is not allowed.</simpara>
</section>
<section id="_equality_of_immutable_types">
<title>Equality of immutable types</title>
<simpara>Polymorphic equality can be used on <link linkend="Immutable">immutable</link> values like
tuples, records, lists, and vectors.  For example,</simpara>
<screen>(1, 2, 3) = (4, 5, 6)</screen>
<simpara>is a type-correct expression yielding <literal>false</literal>, while</simpara>
<screen>[1, 2, 3] = [1, 2, 3]</screen>
<simpara>is type correct and yields <literal>true</literal>.</simpara>
<simpara>Equality on immutable values is computed by structure, which means
that values are compared by recursively descending the data structure
until ground types are reached, at which point the ground types are
compared with primitive equality tests (like comparison of
characters).  So, the expression</simpara>
<screen>[1, 2, 3] = [1, 1 + 1, 1 + 1 + 1]</screen>
<simpara>is guaranteed to yield <literal>true</literal>, even though the lists may occupy
different locations in memory.</simpara>
<simpara>Because of structural equality, immutable values can only be compared
if their components can be compared.  For example, <literal>[1, 2, 3]</literal> can be
compared, but <literal>[1.0, 2.0, 3.0]</literal> can not.  The SML type system uses
<link linkend="EqualityType">equality types</link> to ensure that structural equality is
only applied to valid values.</simpara>
</section>
<section id="_equality_of_mutable_values">
<title>Equality of mutable values</title>
<simpara>In contrast to immutable values, polymorphic equality of
<link linkend="Mutable">mutable</link> values (like ref cells and arrays) is performed by
pointer comparison, not by structure.  So, the expression</simpara>
<screen>ref 13 = ref 13</screen>
<simpara>is guaranteed to yield <literal>false</literal>, even though the ref cells hold the
same contents.</simpara>
<simpara>Because equality of mutable values is not structural, arrays and refs
can be compared <emphasis>even if their components are not equality types</emphasis>.
Hence, the following expression is type correct (and yields true).</simpara>
<programlisting language="sml" linenumbering="unnumbered">let
   val r = ref 13.0
in
   r = r
end</programlisting>
</section>
<section id="_equality_of_datatypes">
<title>Equality of datatypes</title>
<simpara>Polymorphic equality of datatypes is structural.  Two values of the
same datatype are equal if they are of the same <link linkend="Variant">variant</link> and
if the <link linkend="Variant">variant</link>'s arguments are equal (recursively).  So,
with the datatype</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of t</programlisting>
<simpara>then <literal>B (B A) = B A</literal> is type correct and yields <literal>false</literal>, while <literal>A = A</literal>
and <literal>B A = B A</literal> yield <literal>true</literal>.</simpara>
<simpara>As polymorphic equality descends two values to compare them, it uses
pointer equality whenever it reaches a mutable value.  So, with the
datatype</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A of int ref | ...</programlisting>
<simpara>then <literal>A (ref 13) = A (ref 13)</literal> is type correct and yields <literal>false</literal>,
because the pointer equality on the two ref cells yields <literal>false</literal>.</simpara>
<simpara>One weakness of the SML type system is that datatypes do not inherit
the special property of the <literal>ref</literal> and <literal>array</literal> type constructors that
allows them to be compared regardless of their component type.  For
example, after declaring</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of 'a ref</programlisting>
<simpara>one might expect to be able to compare two values of type <literal>real t</literal>,
because pointer comparison on a ref cell would suffice.
Unfortunately, the type system can only express that a user-defined
datatype <link linkend="AdmitsEquality">admits equality</link> or not.  In this case, <literal>t</literal>
admits equality, which means that <literal>int t</literal> can be compared but that
<literal>real t</literal> can not.  We can confirm this with the program</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of 'a ref
fun f (x: real t, y: real t) = x = y</programlisting>
<simpara>on which MLton reports the following error.</simpara>
<screen>Error: z.sml 2.32-2.36.
  Function applied to incorrect argument.
    expects: [&lt;equality&gt;] t * [&lt;equality&gt;] t
    but got: [real] t * [real] t
    in: = (x, y)</screen>
</section>
<section id="_implementation_47">
<title>Implementation</title>
<simpara>Polymorphic equality is implemented by recursively descending the two
values being compared, stopping as soon as they are determined to be
unequal, or exploring the entire values to determine that they are
equal.  Hence, polymorphic equality can take time proportional to the
size of the smaller value.</simpara>
<simpara>MLton uses some optimizations to improve performance.</simpara>
<itemizedlist>
<listitem>
<simpara>
When computing structural equality, first do a pointer comparison.
If the comparison yields <literal>true</literal>, then stop and return <literal>true</literal>, since
the structural comparison is guaranteed to do so.  If the pointer
comparison fails, then recursively descend the values.
</simpara>
</listitem>
<listitem>
<simpara>
If a datatype is an enum (e.g. <literal>datatype t = A | B | C</literal>), then a
single comparison suffices to compare values of the datatype.  No case
dispatch is required to determine whether the two values are of the
same <link linkend="Variant">variant</link>.
</simpara>
</listitem>
<listitem>
<simpara>
When comparing a known constant non-value-carrying
<link linkend="Variant">variant</link>, use a single comparison.  For example, the
following code will compile into a single comparison for <literal>A = x</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B | C of ...
fun f x = ... if A = x then ...</programlisting>
</listitem>
<listitem>
<simpara>
When comparing a small constant <literal>IntInf.int</literal> to another
<literal>IntInf.int</literal>, use a single comparison against the constant.  No case
dispatch is required.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_23">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="AdmitsEquality">AdmitsEquality</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="EqualityType">EqualityType</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="EqualityTypeVariable">EqualityTypeVariable</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Polyvariance">
<title>Polyvariance</title>
<simpara>Polyvariance is an optimization pass for the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SXMLSimplify">SXMLSimplify</link>.</simpara>
<section id="_description_44">
<title>Description</title>
<simpara>This pass duplicates a higher-order, <literal>let</literal> bound function at each
variable reference, if the cost is smaller than some threshold.</simpara>
</section>
<section id="_implementation_48">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/polyvariance.fun"><literal>polyvariance.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_47">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Poplog">
<title>Poplog</title>
<simpara><ulink url="http://www.cs.bham.ac.uk/research/poplog/poplog.info.html">POPLOG</ulink> is a
development environment that includes implementations of a number of
languages, including <link linkend="StandardML">Standard ML</link>.</simpara>
<simpara>While POPLOG is actively developed, the <link linkend="ML">ML</link> support predates
<link linkend="DefinitionOfStandardML">SML&#8217;97</link>, and there is no support for the
<link linkend="BasisLibrary">Basis Library</link>
<ulink url="http://www.standardml.org/Basis">specification</ulink>.</simpara>
<section id="_also_see_24">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.cs.bham.ac.uk/research/poplog/doc/pmlhelp/mlinpop">Mixed-language programming in ML and Pop-11</ulink>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PortingMLton">
<title>PortingMLton</title>
<simpara>Porting MLton to a new target platform (architecture or OS) involves
the following steps.</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
Make the necessary changes to the scripts, runtime system,
<link linkend="BasisLibrary">Basis Library</link> implementation, and compiler.
</simpara>
</listitem>
<listitem>
<simpara>
Get the regressions working using a cross compiler.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CrossCompiling">Cross compile</link> MLton and bootstrap on the target.
</simpara>
</listitem>
</orderedlist>
<simpara>MLton has a native code generator only for AMD64 and X86, so, if you
are porting to another architecture, you must use the C code
generator.  These notes do not cover building a new native code
generator.</simpara>
<simpara>Some of the following steps will not be necessary if MLton already
supports the architecture or operating system you are porting to.</simpara>
<section id="_what_code_to_change">
<title>What code to change</title>
<itemizedlist>
<listitem>
<simpara>
Scripts.
</simpara>
<itemizedlist>
<listitem>
<simpara>
In <literal>bin/platform</literal>, add new cases to define <literal>$HOST_OS</literal> and <literal>$HOST_ARCH</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Runtime system.
</simpara>
<simpara>The goal of this step is to be able to successfully run <literal>make</literal> in the
<literal>runtime</literal> directory on the target machine.</simpara>
<itemizedlist>
<listitem>
<simpara>
In <literal>platform.h</literal>, add a new case to include <literal>platform/&lt;arch&gt;.h</literal> and <literal>platform/&lt;os&gt;.h</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
In <literal>platform/&lt;arch&gt;.h</literal>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
define <literal>MLton_Platform_Arch_host</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
In <literal>platform/&lt;os&gt;.h</literal>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
include platform-specific includes.
</simpara>
</listitem>
<listitem>
<simpara>
define <literal>MLton_Platform_OS_host</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
define all of the <literal>HAS_*</literal> macros.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
In <literal>platform/&lt;os&gt;.c</literal> implement any platform-dependent functions that the runtime needs.
</simpara>
</listitem>
<listitem>
<simpara>
Add rounding mode control to <literal>basis/Real/IEEEReal.c</literal> for the new arch (if not <literal>HAS_FEROUND</literal>)
</simpara>
</listitem>
<listitem>
<simpara>
Compile and install the <link linkend="GnuMP">GnuMP</link>.  This varies from platform to platform.  In <literal>platform/&lt;os&gt;.h</literal>, you need to include the appropriate <literal>gmp.h</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Basis Library implementation (<literal>basis-library/*</literal>)
</simpara>
<itemizedlist>
<listitem>
<simpara>
In <literal>primitive/prim-mlton.sml</literal>:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Add a new variant to the <literal>MLton.Platform.Arch.t</literal> datatype.
</simpara>
</listitem>
<listitem>
<simpara>
modify the constants that define <literal>MLton.Platform.Arch.host</literal> to match with <literal>MLton_Platform_Arch_host</literal>, as set in <literal>runtime/platform/&lt;arch&gt;.h</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Add a new variant to the <literal>MLton.Platform.OS.t</literal> datatype.
</simpara>
</listitem>
<listitem>
<simpara>
modify the constants that define <literal>MLton.Platform.OS.host</literal> to match with <literal>MLton_Platform_OS_host</literal>, as set in <literal>runtime/platform/&lt;os&gt;.h</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
In <literal>mlton/platform.{sig,sml}</literal> add a new variant.
</simpara>
</listitem>
<listitem>
<simpara>
In <literal>sml-nj/sml-nj.sml</literal>, modify <literal>getOSKind</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Look at all the uses of <literal>MLton.Platform</literal> in the Basis Library implementation and see if you need to do anything special.  You might use the following command to see where to look.
</simpara>
<screen>find basis-library -type f | xargs grep 'MLton\.Platform'</screen>
<simpara>If in doubt, leave the code alone and wait to see what happens when you run the regression tests.</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Compiler.
</simpara>
<itemizedlist>
<listitem>
<simpara>
In <literal>lib/stubs/mlton-stubs/platform.sig</literal> add any new variants, as was done in the Basis Library.
</simpara>
</listitem>
<listitem>
<simpara>
In <literal>lib/stubs/mlton-stubs/mlton.sml</literal> add any new variants in <literal>MLton.Platform</literal>, as was done in the Basis Library.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>The string used to identify a particular architecture or operating
system must be the same (except for possibly case of letters) in the
scripts, runtime, Basis Library implementation, and compiler (stubs).
In <literal>mlton/main/main.fun</literal>, MLton itself uses the conversions to and
from strings:</simpara>
<screen>MLton.Platform.{Arch,OS}.{from,to}String</screen>
<simpara>If the there is a mismatch, you may see the error message
<literal>strange arch</literal> or <literal>strange os</literal>.</simpara>
</section>
<section id="_running_the_regressions_with_a_cross_compiler">
<title>Running the regressions with a cross compiler</title>
<simpara>When porting to a new platform, it is always best to get all (or as
many as possible) of the regressions working before moving to a self
compile.  It is easiest to do this by modifying and rebuilding the
compiler on a working machine and then running the regressions with a
cross compiler.  It is not easy to build a gcc cross compiler, so we
recommend generating the C and assembly on a working machine (using
MLton&#8217;s <literal>-target</literal> and <literal>-stop g</literal> flags, copying the generated files to
the target machine, then compiling and linking there.</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
Remake the compiler on a working machine.
</simpara>
</listitem>
<listitem>
<simpara>
Use <literal>bin/add-cross</literal> to add support for the new target.  In particular, this should create <literal>build/lib/mlton/targets/&lt;target&gt;/</literal> with the platform-specific necessary cross-compilation information.
</simpara>
</listitem>
<listitem>
<simpara>
Run the regression tests with the cross-compiler.  To cross-compile all the tests, do
</simpara>
<screen>bin/regression -cross &lt;target&gt;</screen>
<simpara>This will create all the executables.  Then, copy <literal>bin/regression</literal> and
the <literal>regression</literal> directory to the target machine, and do</simpara>
<screen>bin/regression -run-only &lt;target&gt;</screen>
<simpara>This should run all the tests.</simpara>
</listitem>
</orderedlist>
<simpara>Repeat this step, interleaved with appropriate compiler modifications,
until all the regressions pass.</simpara>
</section>
<section id="_bootstrap">
<title>Bootstrap</title>
<simpara>Once you&#8217;ve got all the regressions working, you can build MLton for
the new target.  As with the regressions, the idea for bootstrapping
is to generate the C and assembly on a working machine, copy it to the
target machine, and then compile and link there.  Here&#8217;s the sequence
of steps.</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
On a working machine, with the newly rebuilt compiler, in the <literal>mlton</literal> directory, do:
</simpara>
<screen>mlton -stop g -target &lt;target&gt; mlton.mlb</screen>
</listitem>
<listitem>
<simpara>
Copy to the target machine.
</simpara>
</listitem>
<listitem>
<simpara>
On the target machine, move the libraries to the right place. That is, in <literal>build/lib/mlton/targets</literal>, do:
</simpara>
<screen>rm -rf self
mv &lt;target&gt; self</screen>
<simpara>Also make sure you have all the header files in build/lib/mlton/include. You can copy them from a host machine that has run <literal>make runtime</literal>.</simpara>
</listitem>
<listitem>
<simpara>
On the target machine, compile and link MLton.  That is, in the  mlton directory, do something like:
</simpara>
<screen>gcc -c -Ibuild/lib/mlton/include -Ibuild/lib/mlton/targets/self/include -O1 -w mlton/mlton.*.[cs]
gcc -o build/lib/mlton/mlton-compile \
        -Lbuild/lib/mlton/targets/self \
        -L/usr/local/lib \
        mlton.*.o \
        -lmlton -lgmp -lgdtoa -lm</screen>
</listitem>
<listitem>
<simpara>
At this point, MLton should be working and you can finish the rest of a usual make on the target machine.
</simpara>
<screen>make basis-no-check script mlbpathmap constants libraries tools</screen>
</listitem>
<listitem>
<simpara>
Making the last tool, mlyacc, will fail, because mlyacc cannot bootstrap its own yacc.grm.* files. On the host machine, run <literal>make -C mlyacc src/yacc.grm.sml</literal>. Then copy both files to the target machine, and compile mlyacc, making sure to supply the path to your newly compile mllex: <literal>make -C mlyacc MLLEX=mllex/mllex</literal>.
</simpara>
</listitem>
</orderedlist>
<simpara>There are other details to get right, like making sure that the tools
directories were clean so that the tools are rebuilt on the new
platform, but hopefully this structure works.  Once you&#8217;ve got a
compiler on the target machine, you should test it by running all the
regressions normally (i.e. without the <literal>-cross</literal> flag) and by running a
couple rounds of self compiles.</simpara>
</section>
<section id="_also_see_25">
<title>Also see</title>
<simpara>The above description is based on the following emails sent to the
MLton list.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2002-October/013110.html">http://www.mlton.org/pipermail/mlton/2002-October/013110.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-July/016029.html">http://www.mlton.org/pipermail/mlton/2004-July/016029.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PrecedenceParse">
<title>PrecedenceParse</title>
<simpara><link linkend="PrecedenceParse">PrecedenceParse</link> is an analysis/rewrite pass for the <link linkend="AST">AST</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="Elaborate">Elaborate</link>.</simpara>
<section id="_description_45">
<title>Description</title>
<simpara>This pass rewrites <link linkend="AST">AST</link> function clauses, expressions, and patterns
to resolve <link linkend="OperatorPrecedence">OperatorPrecedence</link>.</simpara>
</section>
<section id="_implementation_49">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/precedence-parse.sig"><literal>precedence-parse.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/precedence-parse.fun"><literal>precedence-parse.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_48">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Printf">
<title>Printf</title>
<simpara>Programmers coming from C or Java often ask if
<link linkend="StandardML">Standard ML</link> has a <literal>printf</literal> function.  It does not.
However, it is possible to implement your own version with only a few
lines of code.</simpara>
<simpara>Here is a definition for <literal>printf</literal> and <literal>fprintf</literal>, along with format
specifiers for booleans, integers, and reals.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Printf =
   struct
      fun $ (_, f) = f (fn p =&gt; p ()) ignore
      fun fprintf out f = f (out, id)
      val printf = fn z =&gt; fprintf TextIO.stdOut z
      fun one ((out, f), make) g =
         g (out, fn r =&gt;
            f (fn p =&gt;
               make (fn s =&gt;
                     r (fn () =&gt; (p (); TextIO.output (out, s))))))
      fun ` x s = one (x, fn f =&gt; f s)
      fun spec to x = one (x, fn f =&gt; f o to)
      val B = fn z =&gt; spec Bool.toString z
      val I = fn z =&gt; spec Int.toString z
      val R = fn z =&gt; spec Real.toString z
   end</programlisting>
<simpara>Here&#8217;s an example use.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = printf `"Int="I`"  Bool="B`"  Real="R`"\n" $ 1 false 2.0</programlisting>
<simpara>This prints the following.</simpara>
<screen>Int=1  Bool=false  Real=2.0</screen>
<simpara>In general, a use of <literal>printf</literal> looks like</simpara>
<screen>printf &lt;spec1&gt; ... &lt;specn&gt; $ &lt;arg1&gt; ... &lt;argm&gt;</screen>
<simpara>where each <literal>&lt;speci&gt;</literal> is either a specifier like <literal>B</literal>, <literal>I</literal>, or <literal>R</literal>, or
is an inline string, like <literal>&grave;"foo"</literal>.  A backtick (<literal>&grave;</literal>)
must precede each inline string.  Each <literal>&lt;argi&gt;</literal> must be of the
appropriate type for the corresponding specifier.</simpara>
<simpara>SML <literal>printf</literal> is more powerful than its C counterpart in a number of
ways.  In particular, the function produced by <literal>printf</literal> is a perfectly
ordinary SML function, and can be passed around, used multiple times,
etc.  For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f: int -&gt; bool -&gt; unit = printf `"Int="I`"  Bool="B`"\n" $
val () = f 1 true
val () = f 2 false</programlisting>
<simpara>The definition of <literal>printf</literal> is even careful to not print anything until
it is fully applied.  So, examples like the following will work as
expected.</simpara>
<screen>val f: int -&gt; bool -&gt; unit = printf `"Int="I`"  Bool="B`"\n" $ 13
val () = f true
val () = f false</screen>
<simpara>It is also easy to define new format specifiers.  For example, suppose
we wanted format specifiers for characters and strings.</simpara>
<screen>val C = fn z =&gt; spec Char.toString z
val S = fn z =&gt; spec (fn s =&gt; s) z</screen>
<simpara>One can define format specifiers for more complex types, e.g. pairs of
integers.</simpara>
<screen>val I2 =
   fn z =&gt;
   spec (fn (i, j) =&gt;
         concat ["(", Int.toString i, ", ", Int.toString j, ")"])
   z</screen>
<simpara>Here&#8217;s an example use.</simpara>
<screen>val () = printf `"Test "I2`"  a string "S`"\n" $ (1, 2) "hello"</screen>
<section id="_printf_via_link_linkend_fold_fold_link">
<title>Printf via <link linkend="Fold">Fold</link></title>
<simpara><literal>printf</literal> is best viewed as a special case of variable-argument
<link linkend="Fold">Fold</link> that inductively builds a function as it processes its
arguments.  Here is the definition of a <literal>Printf</literal> structure in terms of
fold.  The structure is equivalent to the above one, except that it
uses the standard <literal>$</literal> instead of a specialized one.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Printf =
   struct
      fun fprintf out =
         Fold.fold ((out, id), fn (_, f) =&gt; f (fn p =&gt; p ()) ignore)

      val printf = fn z =&gt; fprintf TextIO.stdOut z

      fun one ((out, f), make) =
         (out, fn r =&gt;
          f (fn p =&gt;
             make (fn s =&gt;
                   r (fn () =&gt; (p (); TextIO.output (out, s))))))

      val ` =
         fn z =&gt; Fold.step1 (fn (s, x) =&gt; one (x, fn f =&gt; f s)) z

      fun spec to = Fold.step0 (fn x =&gt; one (x, fn f =&gt; f o to))

      val B = fn z =&gt; spec Bool.toString z
      val I = fn z =&gt; spec Int.toString z
      val R = fn z =&gt; spec Real.toString z
   end</programlisting>
<simpara>Viewing <literal>printf</literal> as a fold opens up a number of possibilities.  For
example, one can name parts of format strings using the fold idiom for
naming sequences of steps.</simpara>
<screen>val IB = fn u =&gt; Fold.fold u `"Int="I`" Bool="B
val () = printf IB`"  "IB`"\n" $ 1 true 3 false</screen>
<simpara>One can even parametrize over partial format strings.</simpara>
<screen>fun XB X = fn u =&gt; Fold.fold u `"X="X`" Bool="B
val () = printf (XB I)`"  "(XB R)`"\n" $ 1 true 2.0 false</screen>
</section>
<section id="_also_see_26">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="PrintfGentle">PrintfGentle</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Danvy98">Functional Unparsing</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="PrintfGentle">
<title>PrintfGentle</title>
<simpara>This page provides a gentle introduction and derivation of <link linkend="Printf">Printf</link>,
with sections and arrangement more suitable to a talk.</simpara>
<section id="_introduction">
<title>Introduction</title>
<simpara>SML does not have <literal>printf</literal>.  Could we define it ourselves?</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = printf ("here's an int %d and a real %f.\n", 13, 17.0)
val () = printf ("here's three values (%d, %f, %f).\n", 13, 17.0, 19.0)</programlisting>
<simpara>What could the type of <literal>printf</literal> be?</simpara>
<simpara>This obviously can&#8217;t work, because SML functions take a fixed number
of arguments.  Actually they take one argument, but if that&#8217;s a tuple,
it can only have a fixed number of components.</simpara>
</section>
<section id="_from_tupling_to_currying">
<title>From tupling to currying</title>
<simpara>What about currying to get around the typing problem?</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = printf "here's an int %d and a real %f.\n" 13 17.0
val () = printf "here's three values (%d, %f, %f).\n" 13 17.0 19.0</programlisting>
<simpara>That fails for a similar reason.  We need two types for <literal>printf</literal>.</simpara>
<screen>val printf: string -&gt; int -&gt; real -&gt; unit
val printf: string -&gt; int -&gt; real -&gt; real -&gt; unit</screen>
<simpara>This can&#8217;t work, because <literal>printf</literal> can only have one type.  SML doesn&#8217;t
support programmer-defined overloading.</simpara>
</section>
<section id="_overloading_and_dependent_types">
<title>Overloading and dependent types</title>
<simpara>Even without worrying about number of arguments, there is another
problem.  The type of <literal>printf</literal> depends on the format string.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = printf "here's an int %d and a real %f.\n" 13 17.0
val () = printf "here's a real %f and an int %d.\n" 17.0 13</programlisting>
<simpara>Now we need</simpara>
<screen>val printf: string -&gt; int -&gt; real -&gt; unit
val printf: string -&gt; real -&gt; int -&gt; unit</screen>
<simpara>Again, this can&#8217;t possibly working because SML doesn&#8217;t have
overloading, and types can&#8217;t depend on values.</simpara>
</section>
<section id="_idea_express_type_information_in_the_format_string">
<title>Idea: express type information in the format string</title>
<simpara>If we express type information in the format string, then different
uses of <literal>printf</literal> can have different types.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type 'a t  (* the type of format strings *)
val printf: 'a t -&gt; 'a
infix D F
val fs1: (int -&gt; real -&gt; unit) t = "here's an int "D" and a real "F".\n"
val fs2: (int -&gt; real -&gt; real -&gt; unit) t =
   "here's three values ("D", "F", "F").\n"
val () = printf fs1 13 17.0
val () = printf fs2 13 17.0 19.0</programlisting>
<simpara>Now, our two calls to <literal>printf</literal> type check, because the format
string specializes <literal>printf</literal> to the appropriate type.</simpara>
</section>
<section id="_the_types_of_format_characters">
<title>The types of format characters</title>
<simpara>What should the type of format characters <literal>D</literal> and <literal>F</literal> be?  Each format
character requires an additional argument of the appropriate type to
be supplied to <literal>printf</literal>.</simpara>
<simpara>Idea: guess the final type that will be needed for <literal>printf</literal> the format
string and verify it with each format character.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b) t   (* 'a = rest of type to verify, 'b = final type *)
val ` : string -&gt; ('a, 'a) t  (* guess the type, which must be verified *)
val D: (int -&gt; 'a, 'b) t * string -&gt; ('a, 'b) t  (* consume an int *)
val F: (real -&gt; 'a, 'b) t * string -&gt; ('a, 'b) t  (* consume a real *)
val printf: (unit, 'a) t -&gt; 'a</programlisting>
<simpara>Don&#8217;t worry.  In the end, type inference will guess and verify for us.</simpara>
</section>
<section id="_understanding_guess_and_verify">
<title>Understanding guess and verify</title>
<simpara>Now, let&#8217;s build up a format string and a specialized <literal>printf</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">infix D F
val f0 = `"here's an int "
val f1 = f0 D " and a real "
val f2 = f1 F ".\n"
val p = printf f2</programlisting>
<simpara>These definitions yield the following types.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f0: (int -&gt; real -&gt; unit, int -&gt; real -&gt; unit) t
val f1: (real -&gt; unit, int -&gt; real -&gt; unit) t
val f2: (unit, int -&gt; real -&gt; unit) t
val p: int -&gt; real -&gt; unit</programlisting>
<simpara>So, <literal>p</literal> is a specialized <literal>printf</literal> function.  We could use it as
follows</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = p 13 17.0
val () = p 14 19.0</programlisting>
</section>
<section id="_type_checking_this_using_a_functor">
<title>Type checking this using a functor</title>
<programlisting language="sml" linenumbering="unnumbered">signature PRINTF =
   sig
      type ('a, 'b) t
      val ` : string -&gt; ('a, 'a) t
      val D: (int -&gt; 'a, 'b) t * string -&gt; ('a, 'b) t
      val F: (real -&gt; 'a, 'b) t * string -&gt; ('a, 'b) t
      val printf: (unit, 'a) t -&gt; 'a
   end

functor Test (P: PRINTF) =
   struct
      open P
      infix D F

      val () = printf (`"here's an int "D" and a real "F".\n") 13 17.0
      val () = printf (`"here's three values ("D", "F ", "F").\n") 13 17.0 19.0
   end</programlisting>
</section>
<section id="_implementing_literal_printf_literal">
<title>Implementing <literal>Printf</literal></title>
<simpara>Think of a format character as a formatter transformer.  It takes the
formatter for the part of the format string before it and transforms
it into a new formatter that first does the left hand bit, then does
its bit, then continues on with the rest of the format string.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Printf: PRINTF =
   struct
      datatype ('a, 'b) t = T of (unit -&gt; 'a) -&gt; 'b

      fun printf (T f) = f (fn () =&gt; ())

      fun ` s = T (fn a =&gt; (print s; a ()))

      fun D (T f, s) =
         T (fn g =&gt; f (fn () =&gt; fn i =&gt;
                       (print (Int.toString i); print s; g ())))

      fun F (T f, s) =
         T (fn g =&gt; f (fn () =&gt; fn i =&gt;
                       (print (Real.toString i); print s; g ())))
   end</programlisting>
</section>
<section id="_testing_printf">
<title>Testing printf</title>
<programlisting language="sml" linenumbering="unnumbered">structure Z = Test (Printf)</programlisting>
</section>
<section id="_user_definable_formats">
<title>User-definable formats</title>
<simpara>The definition of the format characters is pretty much the same.
Within the <literal>Printf</literal> structure we can define a format character
generator.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val newFormat: ('a -&gt; string) -&gt; ('a -&gt; 'b, 'c) t * string -&gt; ('b, 'c) t =
   fn toString =&gt; fn (T f, s) =&gt;
   T (fn th =&gt; f (fn () =&gt; fn a =&gt; (print (toString a); print s ; th ())))
val D = fn z =&gt; newFormat Int.toString z
val F = fn z =&gt; newFormat Real.toString z</programlisting>
</section>
<section id="_a_core_literal_printf_literal">
<title>A core <literal>Printf</literal></title>
<simpara>We can now have a very small <literal>PRINTF</literal> signature, and define all
the format strings externally to the core module.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature PRINTF =
   sig
      type ('a, 'b) t
      val ` : string -&gt; ('a, 'a) t
      val newFormat: ('a -&gt; string) -&gt; ('a -&gt; 'b, 'c) t * string -&gt; ('b, 'c) t
      val printf: (unit, 'a) t -&gt; 'a
   end

structure Printf: PRINTF =
   struct
      datatype ('a, 'b) t = T of (unit -&gt; 'a) -&gt; 'b

      fun printf (T f) = f (fn () =&gt; ())

      fun ` s = T (fn a =&gt; (print s; a ()))

      fun newFormat toString (T f, s) =
         T (fn th =&gt;
            f (fn () =&gt; fn a =&gt;
               (print (toString a)
                ; print s
                ; th ())))
   end</programlisting>
</section>
<section id="_extending_to_fprintf">
<title>Extending to fprintf</title>
<simpara>One can implement fprintf by threading the outstream through all the
transformers.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature PRINTF =
   sig
      type ('a, 'b) t
      val ` : string -&gt; ('a, 'a) t
      val fprintf: (unit, 'a) t * TextIO.outstream -&gt; 'a
      val newFormat: ('a -&gt; string) -&gt; ('a -&gt; 'b, 'c) t * string -&gt; ('b, 'c) t
      val printf: (unit, 'a) t -&gt; 'a
   end

structure Printf: PRINTF =
   struct
      type out = TextIO.outstream
      val output = TextIO.output

      datatype ('a, 'b) t = T of (out -&gt; 'a) -&gt; out -&gt; 'b

      fun fprintf (T f, out) = f (fn _ =&gt; ()) out

      fun printf t = fprintf (t, TextIO.stdOut)

      fun ` s = T (fn a =&gt; fn out =&gt; (output (out, s); a out))

      fun newFormat toString (T f, s) =
         T (fn g =&gt;
            f (fn out =&gt; fn a =&gt;
               (output (out, toString a)
                ; output (out, s)
                ; g out)))
   end</programlisting>
</section>
<section id="_notes_3">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
Lesson: instead of using dependent types for a function, express the
the dependency in the type of the argument.
</simpara>
</listitem>
<listitem>
<simpara>
If <literal>printf</literal> is partially applied, it will do the printing then and
there.  Perhaps this could be fixed with some kind of terminator.
</simpara>
<simpara>A syntactic or argument terminator is not necessary.  A formatter can
either be eager (as above) or lazy (as below).  A lazy formatter
accumulates enough state to print the entire string.  The simplest
lazy formatter concatenates the strings as they become available:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure PrintfLazyConcat: PRINTF =
   struct
      datatype ('a, 'b) t = T of (string -&gt; 'a) -&gt; string -&gt; 'b

      fun printf (T f) = f print ""

      fun ` s = T (fn th =&gt; fn s' =&gt; th (s' ^ s))

      fun newFormat toString (T f, s) =
         T (fn th =&gt;
            f (fn s' =&gt; fn a =&gt;
               th (s' ^ toString a ^ s)))
   end</programlisting>
<simpara>It is somewhat more efficient to accumulate the strings as a list:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure PrintfLazyList: PRINTF =
   struct
      datatype ('a, 'b) t = T of (string list -&gt; 'a) -&gt; string list -&gt; 'b

      fun printf (T f) = f (List.app print o List.rev) []

      fun ` s = T (fn th =&gt; fn ss =&gt; th (s::ss))

      fun newFormat toString (T f, s) =
         T (fn th =&gt;
            f (fn ss =&gt; fn a =&gt;
               th (s::toString a::ss)))
   end</programlisting>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_27">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Printf">Printf</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Danvy98">Functional Unparsing</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ProductType">
<title>ProductType</title>
<simpara><link linkend="StandardML">Standard ML</link> has special syntax for products (tuples). A
product type is written as</simpara>
<programlisting language="sml" linenumbering="unnumbered">t1 * t2 * ... * tN</programlisting>
<simpara>and a product pattern is written as</simpara>
<programlisting language="sml" linenumbering="unnumbered">(p1, p2, ..., pN)</programlisting>
<simpara>In most situations the syntax is quite convenient.  However, there are
situations where the syntax is cumbersome.  There are also situations
in which it is useful to construct and destruct n-ary products
inductively, especially when using <link linkend="Fold">Fold</link>.</simpara>
<simpara>In such situations, it is useful to have a binary product datatype
with an infix constructor defined as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype ('a, 'b) product = &amp; of 'a * 'b
infix &amp;</programlisting>
<simpara>With these definitions, one can write an n-ary product as a nested
binary product quite conveniently.</simpara>
<programlisting language="sml" linenumbering="unnumbered">x1 &amp; x2 &amp; ... &amp; xn</programlisting>
<simpara>Because of left associativity, this is the same as</simpara>
<programlisting language="sml" linenumbering="unnumbered">(((x1 &amp; x2) &amp; ...) &amp; xn)</programlisting>
<simpara>Because <literal>&amp;</literal> is a constructor, the syntax can also be used for
patterns.</simpara>
<simpara>The symbol <literal>&amp;</literal> is inspired by the Curry-Howard isomorphism: the proof
of a conjunction <literal>(A &amp; B)</literal> is a pair of proofs <literal>(a, b)</literal>.</simpara>
<section id="_example_parser_combinators">
<title>Example: parser combinators</title>
<simpara>A typical parser combinator library provides a combinator that has a
type of the form.</simpara>
<programlisting language="sml" linenumbering="unnumbered">'a parser * 'b parser -&gt; ('a * 'b) parser</programlisting>
<simpara>and produces a parser for the concatenation of two parsers. When more
than two parsers are concatenated, the result of the resulting parser
is a nested structure of pairs</simpara>
<programlisting language="sml" linenumbering="unnumbered">(...((p1, p2), p3)..., pN)</programlisting>
<simpara>which is somewhat cumbersome.</simpara>
<simpara>By using a product type, the type of the concatenation combinator then
becomes</simpara>
<programlisting language="sml" linenumbering="unnumbered">'a parser * 'b parser -&gt; ('a, 'b) product parser</programlisting>
<simpara>While this doesn&#8217;t stop the nesting, it makes the pattern significantly
easier to write. Instead of</simpara>
<programlisting language="sml" linenumbering="unnumbered">(...((p1, p2), p3)..., pN)</programlisting>
<simpara>the pattern is written as</simpara>
<programlisting language="sml" linenumbering="unnumbered">p1 &amp; p2 &amp; p3 &amp; ... &amp; pN</programlisting>
<simpara>which is considerably more concise.</simpara>
</section>
<section id="_also_see_28">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="VariableArityPolymorphism">VariableArityPolymorphism</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Utilities">Utilities</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Profiling">
<title>Profiling</title>
<simpara>With MLton and <literal>mlprof</literal>, you can profile your program to find out
bytes allocated, execution counts, or time spent in each function.  To
profile you program, compile with <literal>-profile <emphasis>kind</emphasis></literal>, where <emphasis>kind</emphasis>
is one of <literal>alloc</literal>, <literal>count</literal>, or <literal>time</literal>.  Then, run the executable,
which will write an <literal>mlmon.out</literal> file when it finishes.  You can then
run <literal>mlprof</literal> on the executable and the <literal>mlmon.out</literal> file to see the
performance data.</simpara>
<simpara>Here are the three kinds of profiling that MLton supports.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ProfilingAllocation">ProfilingAllocation</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ProfilingCounts">ProfilingCounts</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ProfilingTime">ProfilingTime</link>
</simpara>
</listitem>
</itemizedlist>
<section id="_next_steps_6">
<title>Next steps</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CallGraph">CallGraph</link>s to visualize profiling data.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="HowProfilingWorks">HowProfilingWorks</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLmon">MLmon</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonProfile">MLtonProfile</link> to selectively profile parts of your program.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ProfilingTheStack">ProfilingTheStack</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ShowProf">ShowProf</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ProfilingAllocation">
<title>ProfilingAllocation</title>
<simpara>With MLton and <literal>mlprof</literal>, you can <link linkend="Profiling">profile</link> your program to
find out how many bytes each function allocates.  To do so, compile
your program with <literal>-profile alloc</literal>.  For example, suppose that
<literal>list-rev.sml</literal> is the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun append (l1, l2) =
   case l1 of
      [] =&gt; l2
    | x :: l1 =&gt; x :: append (l1, l2)

fun rev l =
   case l of
      [] =&gt; []
    | x :: l =&gt; append (rev l, [x])

val l = List.tabulate (1000, fn i =&gt; i)
val _ = 1 + hd (rev l)</programlisting>
<simpara>Compile and run <literal>list-rev</literal> as follows.</simpara>
<screen>% mlton -profile alloc list-rev.sml
% ./list-rev
% mlprof -show-line true list-rev mlmon.out
6,030,136 bytes allocated (108,336 bytes by GC)
       function          cur
----------------------- -----
append  list-rev.sml: 1 97.6%
&lt;gc&gt;                     1.8%
&lt;main&gt;                   0.4%
rev  list-rev.sml: 6     0.2%</screen>
<simpara>The data shows that most of the allocation is done by the <literal>append</literal>
function defined on line 1 of <literal>list-rev.sml</literal>.  The table also shows
how special functions like <literal>gc</literal> and <literal>main</literal> are handled: they are
printed with surrounding brackets.  C functions are displayed
similarly.  In this example, the allocation done by the garbage
collector is due to stack growth, which is usually the case.</simpara>
<simpara>The run-time performance impact of allocation profiling is noticeable,
because it inserts additional C calls for object allocation.</simpara>
<simpara>Compile with <literal>-profile alloc -profile-branch true</literal> to find out how
much allocation is done in each branch of a function; see
<link linkend="ProfilingCounts">ProfilingCounts</link> for more details on <literal>-profile-branch</literal>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ProfilingCounts">
<title>ProfilingCounts</title>
<simpara>With MLton and <literal>mlprof</literal>, you can <link linkend="Profiling">profile</link> your program to
find out how many times each function is called and how many times
each branch is taken.  To do so, compile your program with
<literal>-profile count -profile-branch true</literal>. For example, suppose that
<literal>tak.sml</literal> contains the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Tak =
   struct
      fun tak1 (x, y, z) =
         let
            fun tak2 (x, y, z) =
               if y &gt;= x
                  then z
               else
                  tak1 (tak2 (x - 1, y, z),
                        tak2 (y - 1, z, x),
                        tak2 (z - 1, x, y))
         in
            if y &gt;= x
               then z
            else
               tak1 (tak2 (x - 1, y, z),
                     tak2 (y - 1, z, x),
                     tak2 (z - 1, x, y))
         end
   end

val rec f =
   fn 0 =&gt; ()
    | ~1 =&gt; print "this branch is not taken\n"
    | n =&gt; (Tak.tak1 (18, 12, 6) ; f (n-1))

val _ = f 5000

fun uncalled () = ()</programlisting>
<simpara>Compile with count profiling and run the program.</simpara>
<screen>% mlton -profile count -profile-branch true tak.sml
% ./tak</screen>
<simpara>Display the profiling data, along with raw counts and file positions.</simpara>
<screen>% mlprof -raw true -show-line true tak mlmon.out
623,610,002 ticks
            function               cur       raw
--------------------------------- ----- -------------
Tak.tak1.tak2  tak.sml: 5         38.2% (238,530,000)
Tak.tak1.tak2.&lt;true&gt;  tak.sml: 7  27.5% (171,510,000)
Tak.tak1  tak.sml: 3              10.7%  (67,025,000)
Tak.tak1.&lt;true&gt;  tak.sml: 14      10.7%  (67,025,000)
Tak.tak1.tak2.&lt;false&gt;  tak.sml: 9 10.7%  (67,020,000)
Tak.tak1.&lt;false&gt;  tak.sml: 16      2.0%  (12,490,000)
f  tak.sml: 23                     0.0%       (5,001)
f.&lt;branch&gt;  tak.sml: 25            0.0%       (5,000)
f.&lt;branch&gt;  tak.sml: 23            0.0%           (1)
uncalled  tak.sml: 29              0.0%           (0)
f.&lt;branch&gt;  tak.sml: 24            0.0%           (0)</screen>
<simpara>Branches are displayed with lexical nesting followed by <literal>&lt;branch&gt;</literal>
where the function name would normally be, or <literal>&lt;true&gt;</literal> or <literal>&lt;false&gt;</literal>
for if-expressions.  It is best to run <literal>mlprof</literal> with <literal>-show-line true</literal>
to help identify the branch.</simpara>
<simpara>One use of <literal>-profile count</literal> is as a code-coverage tool, to help find
code in your program that hasn&#8217;t been tested.  For this reason,
<literal>mlprof</literal> displays functions and branches even if they have a count of
zero.  As the above output shows, the branch on line 24 was never
taken and the function defined on line 29 was never called.  To see
zero counts, it is best to run <literal>mlprof</literal> with <literal>-raw true</literal>, since some
code (e.g. the branch on line 23 above) will show up with <literal>0.0%</literal> but
may still have been executed and hence have a nonzero raw count.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ProfilingTheStack">
<title>ProfilingTheStack</title>
<simpara>For all forms of <link linkend="Profiling">Profiling</link>, you can gather counts for all
functions on the stack, not just the currently executing function.  To
do so, compile your program with <literal>-profile-stack true</literal>.  For example,
suppose that <literal>list-rev.sml</literal> contains the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun append (l1, l2) =
   case l1 of
      [] =&gt; l2
    | x :: l1 =&gt; x :: append (l1, l2)

fun rev l =
   case l of
      [] =&gt; []
    | x :: l =&gt; append (rev l, [x])

val l = List.tabulate (1000, fn i =&gt; i)
val _ = 1 + hd (rev l)</programlisting>
<simpara>Compile with stack profiling and then run the program.</simpara>
<screen>% mlton -profile alloc -profile-stack true list-rev.sml
% ./list-rev</screen>
<simpara>Display the profiling data.</simpara>
<screen>% mlprof -show-line true list-rev mlmon.out
6,030,136 bytes allocated (108,336 bytes by GC)
       function          cur  stack  GC
----------------------- ----- ----- ----
append  list-rev.sml: 1 97.6% 97.6% 1.4%
&lt;gc&gt;                     1.8%  0.0% 1.8%
&lt;main&gt;                   0.4% 98.2% 1.8%
rev  list-rev.sml: 6     0.2% 97.6% 1.8%</screen>
<simpara>In the above table, we see that <literal>rev</literal>, defined on line 6 of
<literal>list-rev.sml</literal>, is only responsible for 0.2% of the allocation, but is
on the stack while 97.6% of the allocation is done by the user program
and while 1.8% of the allocation is done by the garbage collector.</simpara>
<simpara>The run-time performance impact of <literal>-profile-stack true</literal> can be
noticeable since there is some extra bookkeeping at every nontail call
and return.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ProfilingTime">
<title>ProfilingTime</title>
<simpara>With MLton and <literal>mlprof</literal>, you can <link linkend="Profiling">profile</link> your program to
find out how much time is spent in each function over an entire run of
the program.  To do so, compile your program with <literal>-profile time</literal>.
For example, suppose that <literal>tak.sml</literal> contains the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Tak =
   struct
      fun tak1 (x, y, z) =
         let
            fun tak2 (x, y, z) =
               if y &gt;= x
                  then z
               else
                  tak1 (tak2 (x - 1, y, z),
                        tak2 (y - 1, z, x),
                        tak2 (z - 1, x, y))
         in
            if y &gt;= x
               then z
            else
               tak1 (tak2 (x - 1, y, z),
                     tak2 (y - 1, z, x),
                     tak2 (z - 1, x, y))
         end
   end

val rec f =
   fn 0 =&gt; ()
    | ~1 =&gt; print "this branch is not taken\n"
    | n =&gt; (Tak.tak1 (18, 12, 6) ; f (n-1))

val _ = f 5000

fun uncalled () = ()</programlisting>
<simpara>Compile with time profiling and run the program.</simpara>
<screen>% mlton -profile time tak.sml
% ./tak</screen>
<simpara>Display the profiling data.</simpara>
<screen>% mlprof tak mlmon.out
6.00 seconds of CPU time (0.00 seconds GC)
function     cur
------------- -----
Tak.tak1.tak2 75.8%
Tak.tak1      24.2%</screen>
<simpara>This example shows how <literal>mlprof</literal> indicates lexical nesting: as a
sequence of period-separated names indicating the structures and
functions in which a function definition is nested.  The profiling
data shows that roughly three-quarters of the time is spent in the
<literal>Tak.tak1.tak2</literal> function, while the rest is spent in <literal>Tak.tak1</literal>.</simpara>
<simpara>Display raw counts in addition to percentages with <literal>-raw true</literal>.</simpara>
<screen>% mlprof -raw true tak mlmon.out
6.00 seconds of CPU time (0.00 seconds GC)
  function     cur    raw
------------- ----- -------
Tak.tak1.tak2 75.8% (4.55s)
Tak.tak1      24.2% (1.45s)</screen>
<simpara>Display the file name and line number for each function in addition to
its name with <literal>-show-line true</literal>.</simpara>
<screen>% mlprof -show-line true tak mlmon.out
6.00 seconds of CPU time (0.00 seconds GC)
        function           cur
------------------------- -----
Tak.tak1.tak2  tak.sml: 5 75.8%
Tak.tak1  tak.sml: 3      24.2%</screen>
<simpara>Time profiling is designed to have a very small performance impact.
However, in some cases there will be a run-time performance cost,
which may perturb the results.  There is more likely to be an impact
with <literal>-codegen c</literal> than <literal>-codegen native</literal>.</simpara>
<simpara>You can also compile with <literal>-profile time -profile-branch true</literal> to find
out how much time is spent in each branch of a function; see
<link linkend="ProfilingCounts">ProfilingCounts</link> for more details on <literal>-profile-branch</literal>.</simpara>
<section id="_caveats_3">
<title>Caveats</title>
<simpara>With <literal>-profile time</literal>, use of the following in your program will cause
a run-time error, since they would interfere with the profiler signal
handler.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>MLton.Itimer.set (MLton.Itimer.Prof, ...)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Signal.setHandler (MLton.Signal.prof, ...)</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>Also, because of the random sampling used to implement <literal>-profile
time</literal>, it is best to have a long running program (at least tens of
seconds) in order to get reasonable time</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Projects">
<title>Projects</title>
<simpara>We have lots of ideas for projects to improve MLton, many of which we
do not have time to implement, or at least haven&#8217;t started on yet.
Here is a list of some of those improvements, ranging from the easy (1
week) to the difficult (several months).  If you have any interest in
working on one of these, or some other improvement to MLton not listed
here, please send mail to
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>.</simpara>
<itemizedlist>
<listitem>
<simpara>
Port to new platform: Windows (native, not Cygwin or MinGW), &#8230;
</simpara>
</listitem>
<listitem>
<simpara>
Source-level debugger
</simpara>
</listitem>
<listitem>
<simpara>
Heap profiler
</simpara>
</listitem>
<listitem>
<simpara>
Interfaces to libraries: OpenGL, Gtk+, D-BUS, &#8230;
</simpara>
</listitem>
<listitem>
<simpara>
More libraries written in SML (see <ulink url="https://github.com/MLton/mltonlib"><literal>mltonlib</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Additional constant types: <literal>structure Real80: REAL</literal>, &#8230;
</simpara>
</listitem>
<listitem>
<simpara>
An IDE (possibly integrated with <link linkend="Eclipse">Eclipse</link>)
</simpara>
</listitem>
<listitem>
<simpara>
Port MLRISC and use for code generation
</simpara>
</listitem>
<listitem>
<simpara>
Optimizations
</simpara>
<itemizedlist>
<listitem>
<simpara>
Improved closure representation
</simpara>
<simpara>Right now, MLton&#8217;s closure conversion algorithm uses a simple flat closure to represent each function.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2003-October/024570.html">http://www.mlton.org/pipermail/mlton/2003-October/024570.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton-user/2007-July/001150.html">http://www.mlton.org/pipermail/mlton-user/2007-July/001150.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_ShaoAppel94">ShaoAppel94</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Elimination of array bounds checks in loops
</simpara>
</listitem>
<listitem>
<simpara>
Elimination of overflow checks on array index computations
</simpara>
</listitem>
<listitem>
<simpara>
Common-subexpression elimination of repeated array subscripts
</simpara>
</listitem>
<listitem>
<simpara>
Loop-invariant code motion, especially for tuple selects
</simpara>
</listitem>
<listitem>
<simpara>
Partial redundancy elimination
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2006-April/028598.html">http://www.mlton.org/pipermail/mlton/2006-April/028598.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Loop unrolling, especially for small loops
</simpara>
</listitem>
<listitem>
<simpara>
Auto-vectorization, for MMX/SSE/3DNow!/AltiVec (see the <ulink url="http://gcc.gnu.org/projects/tree-ssa/vectorization.html">work done on GCC</ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Optimize <literal>MLton_eq</literal>: pointer equality is necessarily false when one of the arguments is freshly allocated in the block
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Analyses
</simpara>
<itemizedlist>
<listitem>
<simpara>
Uncaught exception analysis
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Pronounce">
<title>Pronounce</title>
<simpara>Here is <ulink url="guide/Pronounce.attachments/pronounce-mlton.mp3">how "MLton" sounds</ulink>.</simpara>
<simpara>"MLton" is pronounced in two syllables, with stress on the first
syllable.  The first syllable sounds like the word <emphasis>mill</emphasis> (as in
"steel mill"), the second like the word <emphasis>tin</emphasis> (as in "cookie tin").</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="PropertyList">
<title>PropertyList</title>
<simpara>A property list is a dictionary-like data structure into which
properties (name-value pairs) can be inserted and from which
properties can be looked up by name.  The term comes from the Lisp
language, where every symbol has a property list for storing
information, and where the names are typically symbols and keys can be
any type of value.</simpara>
<simpara>Here is an SML signature for property lists such that for any type of
value a new property can be dynamically created to manipulate that
type of value in a property list.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature PROPERTY_LIST =
   sig
      type t

      val new: unit -&gt; t
      val newProperty: unit -&gt; {add: t * 'a -&gt; unit,
                                peek: t -&gt; 'a option}
   end</programlisting>
<simpara>Here is a functor demonstrating the use of property lists.  It first
creates a property list, then two new properties (of different types),
and adds a value to the list for each property.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Test (P: PROPERTY_LIST) =
   struct
      val pl = P.new ()

      val {add = addInt: P.t * int -&gt; unit, peek = peekInt} = P.newProperty ()
      val {add = addReal: P.t * real -&gt; unit, peek = peekReal} = P.newProperty ()

      val () = addInt (pl, 13)
      val () = addReal (pl, 17.0)
      val s1 = Int.toString (valOf (peekInt pl))
      val s2 = Real.toString (valOf (peekReal pl))
      val () = print (concat [s1, " ", s2, "\n"])
   end</programlisting>
<simpara>Applied to an appropriate implementation <literal>PROPERTY_LIST</literal>, the <literal>Test</literal>
functor will produce the following output.</simpara>
<screen>13 17.0</screen>
<section id="_implementation_50">
<title>Implementation</title>
<simpara>Because property lists can hold values of any type, their
implementation requires a <link linkend="UniversalType">UniversalType</link>.  Given that, a property
list is simply a list of elements of the universal type.  Adding a
property adds to the front of the list, and looking up a property
scans the list.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor PropertyList (U: UNIVERSAL_TYPE): PROPERTY_LIST =
   struct
      datatype t = T of U.t list ref

      fun new () = T (ref [])

      fun 'a newProperty () =
         let
            val (inject, out) = U.embed ()
            fun add (T r, a: 'a): unit = r := inject a :: (!r)
            fun peek (T r) =
               Option.map (valOf o out) (List.find (isSome o out) (!r))
         in
            {add = add, peek = peek}
         end
   end</programlisting>
<simpara>If <literal>U: UNIVERSAL_TYPE</literal>, then we can test our code as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Z = Test (PropertyList (U))</programlisting>
<simpara>Of course, a serious implementation of property lists would have to
handle duplicate insertions of the same property, as well as the
removal of elements in order to avoid space leaks.</simpara>
</section>
<section id="_also_see_29">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
MLton relies heavily on property lists for attaching information to
syntax tree nodes in its intermediate languages.  See
<ulink url="https://github.com/MLton/mlton/blob/master/lib/mlton/basic/property-list.sig"><literal>property-list.sig</literal></ulink> and
<ulink url="https://github.com/MLton/mlton/blob/master/lib/mlton/basic/property-list.fun"><literal>property-list.fun</literal></ulink>.
</simpara>
</listitem>
<listitem>
<simpara>
The <link linkend="MLRISCLibrary">MLRISCLibrary</link> <link linkend="References_LeungGeorge99">uses property lists extensively</link>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Pygments">
<title>Pygments</title>
<simpara><ulink url="http://pygments.org/">Pygments</ulink> is a generic syntax highlighter.  Here is a <emphasis>lexer</emphasis> for highlighting
<link linkend="StandardML">Standard ML</link>.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/tree/master/ide/pygments/sml_lexer"><literal>sml_lexer</literal></ulink>&#8201;&#8212;&#8201;Provides highlighting of keywords, special constants, and (nested) comments.
</simpara>
</listitem>
</itemizedlist>
<section id="_install_and_use_2">
<title>Install and use</title>
<itemizedlist>
<listitem>
<simpara>
Checkout all files and install as a <ulink url="http://pygments.org/">Pygments</ulink> plugin.
</simpara>
<screen>$ git clone https://github.com/MLton/mlton.git mlton
$ cd mlton/ide/pygments
$ python setup.py install</screen>
</listitem>
<listitem>
<simpara>
Invoke <literal>pygmentize</literal> with <literal>-l sml</literal>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_feedback_2">
<title>Feedback</title>
<simpara>Comments and suggestions should be directed to <link linkend="MatthewFluet">MatthewFluet</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RayRacine">
<title>RayRacine</title>
<simpara>Using SML in some <emphasis>Semantic Web</emphasis> stuff.   Anyone interested in
similar, please contact me.  GreyLensman on #sml on IRC or rracine at
this domain adelphia with a dot here net.</simpara>
<simpara>Current areas of coding.</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
Pretty solid, high performance Rete implementation - base functionality is complete.
</simpara>
</listitem>
<listitem>
<simpara>
N3 parser - mostly complete
</simpara>
</listitem>
<listitem>
<simpara>
RDF parser based on fxg - not started.
</simpara>
</listitem>
<listitem>
<simpara>
Swerve HTTP server - 1/2 done.
</simpara>
</listitem>
<listitem>
<simpara>
SPARQL implementation - not started.
</simpara>
</listitem>
<listitem>
<simpara>
Persistent engine based on BerkelyDB - not started.
</simpara>
</listitem>
<listitem>
<simpara>
Native implementation of Postgresql protocol - underway, ways to go.
</simpara>
</listitem>
<listitem>
<simpara>
I also have a small change to the MLton compiler to add <literal>PackWord<emphasis>&lt;N&gt;</emphasis></literal> - changes compile but needs some more work, clean-up and unit tests.
</simpara>
</listitem>
</orderedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Reachability">
<title>Reachability</title>
<simpara>Reachability is a notion dealing with the graph of heap objects
maintained at runtime.  Nodes in the graph are heap objects and edges
correspond to the pointers between heap objects.  As the program runs,
it allocates new objects (adds nodes to the graph), and those new
objects can contain pointers to other objects (new edges in the
graph).  If the program uses mutable objects (refs or arrays), it can
also change edges in the graph.</simpara>
<simpara>At any time, the program has access to some finite set of <emphasis>root</emphasis>
nodes, and can only ever access nodes that are reachable by following
edges from these root nodes.  Nodes that are <emphasis>unreachable</emphasis> can be
garbage collected.</simpara>
<section id="_also_see_30">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLtonFinalizable">MLtonFinalizable</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonWeak">MLtonWeak</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Redundant">
<title>Redundant</title>
<simpara><link linkend="Redundant">Redundant</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_46">
<title>Description</title>
<simpara>The redundant SSA optimization eliminates redundant function and label
arguments; an argument of a function or label is redundant if it is
always the same as another argument of the same function or label.
The analysis finds an equivalence relation on the arguments of a
function or label, such that all arguments in an equivalence class are
redundant with respect to the other arguments in the equivalence
class; the transformation selects one representative of each
equivalence class and drops the binding occurrence of
non-representative variables and renames use occurrences of the
non-representative variables to the representative variable.  The
analysis finds the equivalence classes via a fixed-point analysis.
Each vector of arguments to a function or label is initialized to
equivalence classes that equate all arguments of the same type; one
could start with an equivalence class that equates all arguments, but
arguments of different type cannot be redundant.  Variables bound in
statements are initialized to singleton equivalence classes.  The
fixed-point analysis repeatedly refines these equivalence classes on
the formals by the equivalence classes of the actuals.</simpara>
</section>
<section id="_implementation_51">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/redundant.fun"><literal>redundant.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_49">
<title>Details and Notes</title>
<simpara>The reason <link linkend="Redundant">Redundant</link> got put in was due to some output of the
<link linkend="ClosureConvert">ClosureConvert</link> pass converter where the environment record, or
components of it, were passed around in several places.  That may have
been more relevant with polyvariant analyses (which are long gone).
But it still seems possibly relevant, especially with more aggressive
flattening, which should reveal some fields in nested closure records
that are redundant.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RedundantTests">
<title>RedundantTests</title>
<simpara><link linkend="RedundantTests">RedundantTests</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_47">
<title>Description</title>
<simpara>This pass simplifies conditionals whose results are implied by a
previous conditional test.</simpara>
</section>
<section id="_implementation_52">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/redundant-tests.fun"><literal>redundant-tests.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_50">
<title>Details and Notes</title>
<simpara>An additional test will sometimes eliminate the overflow test when
adding or subtracting 1.  In particular, it will eliminate it in the
following cases:</simpara>
<programlisting language="sml" linenumbering="unnumbered">if x &lt; y
  then ... x + 1 ...
else ... y - 1 ...</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="References">
<title>References</title>
<simpara><link linkend="References_AAA">A</link>
<link linkend="References_BBB">B</link>
<link linkend="References_CCC">C</link>
<link linkend="References_DDD">D</link>
<link linkend="References_EEE">E</link>
<link linkend="References_FFF">F</link>
<link linkend="References_GGG">G</link>
<link linkend="References_HHH">H</link>
<link linkend="References_III">I</link>
<link linkend="References_JJJ">J</link>
<link linkend="References_KKK">K</link>
<link linkend="References_LLL">L</link>
<link linkend="References_MMM">M</link>
<link linkend="References_NNN">N</link>
<link linkend="References_OOO">O</link>
<link linkend="References_PPP">P</link>
<link linkend="References_QQQ">Q</link>
<link linkend="References_RRR">R</link>
<link linkend="References_SSS">S</link>
<link linkend="References_TTT">T</link>
<link linkend="References_UUU">U</link>
<link linkend="References_VVV">V</link>
<link linkend="References_WWW">W</link>
<link linkend="References_XXX">X</link>
<link linkend="References_YYY">Y</link>
<link linkend="References_ZZZ">Z</link></simpara>
<section id="_anchor_id_references_aaa_xreflabel_references_aaa_a">
<title><anchor id="References_AAA" xreflabel="[References_AAA]"/>A</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_AcarEtAl06" xreflabel="[References_AcarEtAl06]"/>
 <ulink url="http://www.umut-acar.org/publications/pldi2006.pdf">An Experimental Analysis of Self-Adjusting Computation</ulink>
 Umut Acar, Guy Blelloch, Matthias Blume, and Kanat Tangwongsan.
 <link linkend="References_PLDI">PLDI</link> 2006.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Appel92" xreflabel="[References_Appel92]"/>
 <ulink url="http://us.cambridge.org/titles/catalogue.asp?isbn=0521416957">Compiling with Continuations</ulink>
 (<ulink url="http://www.addall.com/New/submitNew.cgi?query=0-521-41695-7&amp;type=ISBN&amp;location=10000&amp;state=&amp;dispCurr=USD">addall</ulink>).
 ISBN 0521416957.
 Andrew W. Appel.
 Cambridge University Press, 1992.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Appel93" xreflabel="[References_Appel93]"/>
 <ulink url="http://www.cs.princeton.edu/research/techreps/TR-364-92">A Critique of Standard ML</ulink>.
 Andrew W. Appel.
 <link linkend="References_JFP">JFP</link> 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Appel98" xreflabel="[References_Appel98]"/>
 <ulink url="http://us.cambridge.org/titles/catalogue.asp?isbn=0521582741">Modern Compiler Implementation in ML</ulink>
 (<ulink url="http://www.addall.com/New/submitNew.cgi?query=0-521-58274-1&amp;type=ISBN&amp;location=10000&amp;state=&amp;dispCurr=USD">addall</ulink>).
 ISBN 0521582741
 Andrew W. Appel.
 Cambridge University Press, 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_AppelJim97" xreflabel="[References_AppelJim97]"/>
 <ulink url="http://ncstrl.cs.princeton.edu/expand.php?id=TR-556-97">Shrinking Lambda Expressions in Linear Time</ulink>
 Andrew Appel and Trevor Jim.
 <link linkend="References_JFP">JFP</link> 1997.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_AppelEtAl94" xreflabel="[References_AppelEtAl94]"/>
 <ulink url="http://www.smlnj.org/doc/ML-Lex/manual.html">A lexical analyzer generator for Standard ML. Version 1.6.0</ulink>
 Andrew W. Appel, James S. Mattson, and David R. Tarditi.  1994
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_bbb_xreflabel_references_bbb_b">
<title><anchor id="References_BBB" xreflabel="[References_BBB]"/>B</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_BaudinetMacQueen85" xreflabel="[References_BaudinetMacQueen85]"/>
 <ulink url="http://www.classes.cs.uchicago.edu/archive/2011/spring/22620-1/papers/macqueen-baudinet85.pdf">Tree Pattern Matching for ML</ulink>.
 Marianne Baudinet, David MacQueen.  1985.
</simpara>
<blockquote>
<simpara>Describes the match compiler used in an early version of
<link linkend="SMLNJ">SML/NJ</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_BentonEtAl98" xreflabel="[References_BentonEtAl98]"/>
 <ulink url="http://research.microsoft.com/en-us/um/people/nick/icfp98.pdf">Compiling Standard ML to Java Bytecodes</ulink>.
 Nick Benton, Andrew Kennedy, and George Russell.
 <link linkend="References_ICFP">ICFP</link> 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_BentonKennedy99" xreflabel="[References_BentonKennedy99]"/>
 <ulink url="http://research.microsoft.com/en-us/um/people/nick/SMLJavaInterop.pdf">Interlanguage Working Without Tears: Blending SML with Java</ulink>.
 Nick Benton and Andrew Kennedy.
 <link linkend="References_ICFP">ICFP</link> 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_BentonKennedy01" xreflabel="[References_BentonKennedy01]"/>
 <ulink url="http://research.microsoft.com/en-us/um/people/akenn/sml/ExceptionalSyntax.pdf">Exceptional Syntax</ulink>.
 Nick Benton and Andrew Kennedy.
 <link linkend="References_JFP">JFP</link> 2001.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_BentonEtAl04" xreflabel="[References_BentonEtAl04]"/>
 <ulink url="http://research.microsoft.com/en-us/um/people/nick/p53-Benton.pdf">Adventures in Interoperability: The SML.NET Experience</ulink>.
 Nick Benton, Andrew Kennedy, and Claudio Russo.
 <link linkend="References_PPDP">PPDP</link> 2004.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_BentonEtAl04_2" xreflabel="[References_BentonEtAl04_2]"/>
 <ulink url="http://research.microsoft.com/en-us/um/people/nick/shrinking.pdf">Shrinking Reductions in SML.NET</ulink>.
 Nick Benton, Andrew Kennedy, Sam Lindley and Claudio Russo.
 <link linkend="References_IFL">IFL</link> 2004.
</simpara>
<blockquote>
<simpara>Describes a linear-time implementation of an
<link linkend="References_AppelJim97">Appel-Jim shrinker</link>, using a mutable IL, and shows
that it yields nice speedups in SML.NET&#8217;s compile times.  There are
also benchmarks showing that SML.NET when compiled by MLton runs
roughly five times faster than when compiled by SML/NJ.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Benton05" xreflabel="[References_Benton05]"/>
 <ulink url="http://research.microsoft.com/en-us/um/people/nick/benton03.pdf">Embedded Interpreters</ulink>.
 Nick Benton.
 <link linkend="References_JFP">JFP</link> 2005.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Berry91" xreflabel="[References_Berry91]"/>
 <ulink url="http://www.lfcs.inf.ed.ac.uk/reports/91/ECS-LFCS-91-148/ECS-LFCS-91-148.pdf">The Edinburgh SML Library</ulink>.
 Dave Berry.
 University of Edinburgh Technical Report ECS-LFCS-91-148, 1991.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_BerryEtAl93" xreflabel="[References_BerryEtAl93]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.7958&amp;rep=rep1&amp;type=ps">A semantics for ML concurrency primitives</ulink>.
 Dave Berry, Robin Milner, and David N. Turner.
 <link linkend="References_POPL">POPL</link> 1992.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Berry93" xreflabel="[References_Berry93]"/>
 <ulink url="http://journals.cambridge.org/abstract_S0956796800000873">Lessons From the Design of a Standard ML Library</ulink>.
 Dave Berry.
 <link linkend="References_JFP">JFP</link> 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Bertelsen98" xreflabel="[References_Bertelsen98]"/>
 <ulink url="http://www.petermb.dk/sml2jvm.ps.gz">Compiling SML to Java Bytecode</ulink>.
 Peter Bertelsen.
 Master&#8217;s Thesis, 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Berthomieu00" xreflabel="[References_Berthomieu00]"/>
 <ulink url="http://homepages.laas.fr/bernard/oo/ooml.html">OO Programming styles in ML</ulink>.
 Bernard Berthomieu.
 LAAS Report #2000111, 2000.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Blume01" xreflabel="[References_Blume01]"/>
 <ulink url="http://people.cs.uchicago.edu/~blume/papers/nlffi-entcs.pdf">No-Longer-Foreign: Teaching an ML compiler to speak C "natively"</ulink>.
 Matthias Blume.
 <link linkend="References_BABEL">BABEL</link> 2001.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Blume01_02" xreflabel="[References_Blume01_02]"/>
 <ulink url="http://people.cs.uchicago.edu/~blume/pgraph/proposal.pdf">Portable library descriptions for Standard ML</ulink>.
 Matthias Blume.  2001.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Boehm03" xreflabel="[References_Boehm03]"/>
 <ulink url="http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html">Destructors, Finalizers, and Synchronization</ulink>.
 Hans Boehm.
 <link linkend="References_POPL">POPL</link> 2003.
</simpara>
<blockquote>
<simpara>Discusses a number of issues in the design of finalizers.  Many of the
design choices are consistent with <link linkend="MLtonFinalizable">MLtonFinalizable</link>.</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_ccc_xreflabel_references_ccc_c">
<title><anchor id="References_CCC" xreflabel="[References_CCC]"/>C</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_CejtinEtAl00" xreflabel="[References_CejtinEtAl00]"/>
 <ulink url="http://www.cs.purdue.edu/homes/suresh/papers/icfp99.ps.gz">Flow-directed Closure Conversion for Typed Languages</ulink>.
 Henry Cejtin, Suresh Jagannathan, and Stephen Weeks.
 <link linkend="References_ESOP">ESOP</link> 2000.
</simpara>
<blockquote>
<simpara>Describes MLton&#8217;s closure-conversion algorithm, which translates from
its simply-typed higher-order intermediate language to its
simply-typed first-order intermediate language.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_ChengBlelloch01" xreflabel="[References_ChengBlelloch01]"/>
 <ulink url="http://www.cs.cmu.edu/afs/cs/project/pscico/pscico/papers/gc01/pldi-final.pdf">A Parallel, Real-Time Garbage Collector</ulink>.
 Perry Cheng and Guy E. Blelloch.
 <link linkend="References_PLDI">PLDI</link> 2001.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Claessen00" xreflabel="[References_Claessen00]"/>
 <ulink url="http://users.eecs.northwestern.edu/~robby/courses/395-495-2009-fall/quick.pdf">QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs</ulink>.
 Koen Claessen and John Hughes.
 <link linkend="References_ICFP">ICFP</link> 2000.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Clinger98" xreflabel="[References_Clinger98]"/>
 <ulink url="http://www.cesura17.net/~will/Professional/Research/Papers/tail.pdf">Proper Tail Recursion and Space Efficiency</ulink>.
 William D. Clinger.
 <link linkend="References_PLDI">PLDI</link> 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_CooperMorrisett90" xreflabel="[References_CooperMorrisett90]"/>
 <ulink url="http://www.eecs.harvard.edu/~greg/papers/jgmorris-mlthreads.ps">Adding Threads to Standard ML</ulink>.
 Eric C. Cooper and J. Gregory Morrisett.
 CMU Technical Report CMU-CS-90-186, 1990.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_CouttsEtAl07" xreflabel="[References_CouttsEtAl07]"/>
 <ulink url="http://metagraph.org/papers/stream_fusion.pdf">Stream Fusion: From Lists to Streams to Nothing at All</ulink>.
 Duncan Coutts, Roman Leshchinskiy, and Don Stewart.
 Submitted for publication.  April 2007.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_ddd_xreflabel_references_ddd_d">
<title><anchor id="References_DDD" xreflabel="[References_DDD]"/>D</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_DamasMilner82" xreflabel="[References_DamasMilner82]"/>
 <ulink url="http://groups.csail.mit.edu/pag/6.883/readings/p207-damas.pdf">Principal Type-Schemes for Functional Programs</ulink>.
 Luis Damas and Robin Milner.
 <link linkend="References_POPL">POPL</link> 1982.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Danvy98" xreflabel="[References_Danvy98]"/>
 <ulink url="http://www.brics.dk/RS/98/12">Functional Unparsing</ulink>.
 Olivier Danvy.
 BRICS Technical Report RS 98-12, 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Deboer05" xreflabel="[References_Deboer05]"/>
 <ulink url="http://alleystoughton.us/eXene/dusty-thesis.pdf">Exhancements to eXene</ulink>.
 Dustin B. deBoer.
 Master of Science Thesis, 2005.
</simpara>
<blockquote>
<simpara>Describes ways to improve widget concurrency, handling of input focus,
X resources and selections.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_DoligezLeroy93" xreflabel="[References_DoligezLeroy93]"/>
 <ulink url="http://cristal.inria.fr/~doligez/publications/doligez-leroy-popl-1993.pdf">A Concurrent, Generational Garbage Collector for a Multithreaded Implementation of ML</ulink>.
 Damien Doligez and Xavier Leroy.
 <link linkend="References_POPL">POPL</link> 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Dreyer07" xreflabel="[References_Dreyer07]"/>
 <ulink url="http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf">Modular Type Classes</ulink>.
 Derek Dreyer, Robert Harper, Manuel M.T. Chakravarty, Gabriele Keller.
 University of Chicago Technical Report TR-2007-02, 2006.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_DreyerBlume07" xreflabel="[References_DreyerBlume07]"/>
 <ulink url="http://www.mpi-sws.org/~dreyer/papers/infmod/main-long.pdf">Principal Type Schemes for Modular Programs</ulink>.
 Derek Dreyer and Matthias Blume.
 <link linkend="References_ESOP">ESOP</link> 2007.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Dubois95" xreflabel="[References_Dubois95]"/>
 <ulink url="ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/generics.dvi.Z">Extensional Polymorphism</ulink>.
 Catherin Dubois, Francois Rouaix, and Pierre Weis.
 <link linkend="References_POPL">POPL</link> 1995.
</simpara>
<blockquote>
<simpara>An extension of ML that allows the definition of ad-hoc polymorphic
functions by inspecting the type of their argument.</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_eee_xreflabel_references_eee_e">
<title><anchor id="References_EEE" xreflabel="[References_EEE]"/>E</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Elsman03" xreflabel="[References_Elsman03]"/>
 <ulink url="http://www.elsman.com/tldi03.pdf">Garbage Collection Safety for Region-based Memory Management</ulink>.
 Martin Elsman.
 <link linkend="References_TLDI">TLDI</link> 2003.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Elsman04" xreflabel="[References_Elsman04]"/>
 <ulink url="http://www.elsman.com/ITU-TR-2004-43.pdf">Type-Specialized Serialization with Sharing</ulink>.
 Martin Elsman.  University of Copenhagen. IT University Technical
 Report TR-2004-43, 2004.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_fff_xreflabel_references_fff_f">
<title><anchor id="References_FFF" xreflabel="[References_FFF]"/>F</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_FelleisenFreidman98" xreflabel="[References_FelleisenFreidman98]"/>
 <ulink url="http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&amp;tid=4787">The Little MLer</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=026256114X&amp;type=ISBN">addall</ulink>).
 ISBN 026256114X.
 Matthias Felleisen and Dan Freidman.
 The MIT Press, 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_FlattFindler04" xreflabel="[References_FlattFindler04]"/>
 <ulink url="http://www.cs.utah.edu/plt/kill-safe/">Kill-Safe Synchronization Abstractions</ulink>.
 Matthew Flatt and Robert Bruce Findler.
 <link linkend="References_PLDI">PLDI</link> 2004.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_FluetWeeks01" xreflabel="[References_FluetWeeks01]"/>
 <ulink url="http://www.cs.rit.edu/~mtf/research/contification">Contification Using Dominators</ulink>.
 Matthew Fluet and Stephen Weeks.
 <link linkend="References_ICFP">ICFP</link> 2001.
</simpara>
<blockquote>
<simpara>Describes contification, a generalization of tail-recursion
elimination that is an optimization operating on MLton&#8217;s static single
assignment (SSA) intermediate language.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_FluetPucella06" xreflabel="[References_FluetPucella06]"/>
 <ulink url="http://www.cs.rit.edu/~mtf/research/phantom-subtyping/jfp06/jfp06.pdf">Phantom Types and Subtyping</ulink>.
 Matthew Fluet and Riccardo Pucella.
 <link linkend="References_JFP">JFP</link> 2006.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Furuse01" xreflabel="[References_Furuse01]"/>
 <ulink url="http://jfla.inria.fr/2001/actes/07-furuse.ps">Generic Polymorphism in ML</ulink>.
 J. Furuse.
 <link linkend="References_JFLA">JFLA</link> 2001.
</simpara>
<blockquote>
<simpara>The formalism behind G&#8217;CAML, which has an approach to ad-hoc
polymorphism based on <link linkend="References_Dubois95">Dubois95</link>, the differences being in how
type checking works an an improved compilation approach for typecase
that does the matching at compile time, not run time.</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_ggg_xreflabel_references_ggg_g">
<title><anchor id="References_GGG" xreflabel="[References_GGG]"/>G</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_GansnerReppy93" xreflabel="[References_GansnerReppy93]"/>
 <ulink url="http://alleystoughton.us/eXene/1993-trends.pdf">A Multi-Threaded Higher-order User Interface Toolkit</ulink>.
 Emden R. Gansner and John H. Reppy.
 User Interface Software, 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_GansnerReppy04" xreflabel="[References_GansnerReppy04]"/>
<ulink url="http://www.cambridge.org/gb/academic/subjects/computer-science/programming-languages-and-applied-logic/standard-ml-basis-library">The Standard ML Basis Library</ulink>.
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=9780521794787&amp;type=ISBN">addall</ulink>)
 ISBN 9780521794787.
 Emden R. Gansner and John H. Reppy.
 Cambridge University Press, 2004.
</simpara>
<blockquote>
<simpara>An introduction and overview of the <link linkend="BasisLibrary">Basis Library</link>,
followed by a detailed description of each module.  The module
descriptions are also available
<ulink url="http://www.standardml.org/Basis">online</ulink>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_GrossmanEtAl02" xreflabel="[References_GrossmanEtAl02]"/>
 <ulink url="http://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf">Region-based Memory Management in Cyclone</ulink>.
 Dan Grossman, Greg Morrisett, Trevor Jim, Michael Hicks, Yanling
 Wang, and James Cheney.
 <link linkend="References_PLDI">PLDI</link> 2002.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_hhh_xreflabel_references_hhh_h">
<title><anchor id="References_HHH" xreflabel="[References_HHH]"/>H</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_HallenbergEtAl02" xreflabel="[References_HallenbergEtAl02]"/>
 <ulink url="http://www.itu.dk/people/tofte/publ/pldi2002.pdf">Combining Region Inference and Garbage Collection</ulink>.
 Niels Hallenberg, Martin Elsman, and Mads Tofte.
 <link linkend="References_PLDI">PLDI</link> 2002.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_HansenRichel99" xreflabel="[References_HansenRichel99]"/>
 <ulink url="http://www.it.dtu.dk/introSML">Introduction to Programming Using SML</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=0201398206&amp;type=ISBN">addall</ulink>).
 ISBN 0201398206.
 Michael R. Hansen, Hans Rischel.
 Addison-Wesley, 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Harper11" xreflabel="[References_Harper11]"/>
 <ulink url="http://www.cs.cmu.edu/~rwh/smlbook/book.pdf">Programming in Standard ML</ulink>.
 Robert Harper.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_HarperEtAl93" xreflabel="[References_HarperEtAl93]"/>
 <ulink url="http://www.cs.cmu.edu/~rwh/papers/callcc/jfp.pdf">Typing First-Class Continuations in ML</ulink>.
 Robert Harper, Bruce F. Duba, and David MacQueen.
 <link linkend="References_JFP">JFP</link> 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_HarperMitchell92" xreflabel="[References_HarperMitchell92]"/>
 <ulink url="http://www.cs.cmu.edu/~rwh/papers/xml/toplas93.pdf">On the Type Structure of Standard ML</ulink>.
 Robert Harper and John C. Mitchell.
 <link linkend="References_TOPLAS">TOPLAS</link> 1992.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_HauserBenson04" xreflabel="[References_HauserBenson04]"/>
 <ulink url="http://doi.ieeecomputersociety.org/10.1109/CSD.2004.1309122">On the Practicality and Desirability of Highly-concurrent, Mostly-functional Programming</ulink>.
 Carl H. Hauser and David B. Benson.
 <link linkend="References_ACSD">ACSD</link> 2004.
</simpara>
<blockquote>
<simpara>Describes the use of <link linkend="ConcurrentML">Concurrent ML</link> in implementing
the Ped text editor.  Argues that using large numbers of threads and
message passing style is a practical and effective way of
modularizing a program.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_HeckmanWilhelm97" xreflabel="[References_HeckmanWilhelm97]"/>
 <ulink url="http://rw4.cs.uni-sb.de/~heckmann/abstracts/neuform.html">A Functional Description of TeX&#8217;s Formula Layout</ulink>.
 Reinhold Heckmann and Reinhard Wilhelm.
 <link linkend="References_JFP">JFP</link> 1997.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_HicksEtAl03" xreflabel="[References_HicksEtAl03]"/>
 <ulink url="http://wwwold.cs.umd.edu/Library/TRs/CS-TR-4514/CS-TR-4514.pdf">Safe and Flexible Memory Management in Cyclone</ulink>.
 Mike Hicks, Greg Morrisett, Dan Grossman, and Trevor Jim.
 University of Maryland Technical Report CS-TR-4514, 2003.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Hurd04" xreflabel="[References_Hurd04]"/>
 <ulink url="http://www.gilith.com/research/talks/tphols2004.pdf">Compiling HOL4 to Native Code</ulink>.
 Joe Hurd.
 <link linkend="References_TPHOLs">TPHOLs</link> 2004.
</simpara>
<blockquote>
<simpara>Describes a port of HOL from Moscow ML to MLton, the difficulties
encountered in compiling large programs, and the speedups achieved
(roughly 10x).</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_iii_xreflabel_references_iii_i">
<title><anchor id="References_III" xreflabel="[References_III]"/>I</title>
<simpara></simpara>
</section>
<section id="_anchor_id_references_jjj_xreflabel_references_jjj_j">
<title><anchor id="References_JJJ" xreflabel="[References_JJJ]"/>J</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Jones99" xreflabel="[References_Jones99]"/>
 <ulink url="http://www.cs.kent.ac.uk/people/staff/rej/gcbook">Garbage Collection: Algorithms for Automatic Memory Management</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=0471941484&amp;type=ISBN">addall</ulink>).
 ISBN 0471941484.
 Richard Jones.
 John Wiley &amp; Sons, 1999.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_kkk_xreflabel_references_kkk_k">
<title><anchor id="References_KKK" xreflabel="[References_KKK]"/>K</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Kahrs93" xreflabel="[References_Kahrs93]"/>
 <ulink url="http://kar.kent.ac.uk/21122/">Mistakes and Ambiguities in the Definition of Standard ML</ulink>.
 Stefan Kahrs.
 University of Edinburgh Technical Report ECS-LFCS-93-257, 1993.
</simpara>
<blockquote>
<simpara>Describes a number of problems with the
<link linkend="References_MilnerEtAl90">1990 Definition</link>, many of which were fixed in the
<link linkend="References_MilnerEtAl97">1997 Definition</link>.</simpara>
<simpara>Also see the <ulink url="http://www.cs.kent.ac.uk/~smk/errors-new.ps.Z">addenda</ulink>
published in 1996.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Karvonen07" xreflabel="[References_Karvonen07]"/>
 <ulink url="http://dl.acm.org/citation.cfm?doid=1292535.1292547">Generics for the Working ML&#8217;er</ulink>.
 Vesa Karvonen.
 <link linkend="References_ML">ML</link> 2007. <ulink url="http://research.microsoft.com/~crusso/ml2007/slides/ml08rp-karvonen-slides.pdf">Slides</ulink> from the presentation are also available.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Kennedy04" xreflabel="[References_Kennedy04]"/>
 <ulink url="http://research.microsoft.com/~akenn/fun/picklercombinators.pdf">Pickler Combinators</ulink>.
 Andrew Kennedy.
 <link linkend="References_JFP">JFP</link> 2004.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_KoserEtAl03" xreflabel="[References_KoserEtAl03]"/>
 <ulink url="http://www.litech.org/~vaughan/pdf/dpcool2003.pdf">sml2java: A Source To Source Translator</ulink>.
 Justin Koser, Haakon Larsen, Jeffrey A. Vaughan.
 <link linkend="References_DPCOOL">DPCOOL</link> 2003.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_lll_xreflabel_references_lll_l">
<title><anchor id="References_LLL" xreflabel="[References_LLL]"/>L</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Lang99" xreflabel="[References_Lang99]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.7130&amp;rep=rep1&amp;type=ps">Faster Algorithms for Finding Minimal Consistent DFAs</ulink>.
 Kevin Lang. 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_LarsenNiss04" xreflabel="[References_LarsenNiss04]"/>
 <ulink url="http://usenix.org/publications/library/proceedings/usenix04/tech/freenix/full_papers/larsen/larsen.pdf">mGTK: An SML binding of Gtk+</ulink>.
 Ken Larsen and Henning Niss.
 USENIX Annual Technical Conference, 2004.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Leibig13" xreflabel="[References_Leibig13]"/>
 <ulink url="http://www.cs.rit.edu/~bal6053/msproject/">An LLVM Back-end for MLton</ulink>.
 Brian Leibig.
 MS Project Report, 2013.
</simpara>
<blockquote>
<simpara>Describes MLton&#8217;s <link linkend="LLVMCodegen">LLVMCodegen</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Leroy90" xreflabel="[References_Leroy90]"/>
 <ulink url="http://pauillac.inria.fr/~xleroy/bibrefs/Leroy-ZINC.html">The ZINC Experiment: an Economical Implementation of the ML Language</ulink>.
 Xavier Leroy.
 Technical report 117, INRIA, 1990.
</simpara>
<blockquote>
<simpara>A detailed explanation of the design and implementation of a bytecode
compiler and interpreter for ML with a machine model aimed at
efficient implementation.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Leroy93" xreflabel="[References_Leroy93]"/>
 <ulink url="http://pauillac.inria.fr/~xleroy/bibrefs/Leroy-poly-par-nom.html">Polymorphism by Name for References and Continuations</ulink>.
 Xavier Leroy.
 <link linkend="References_POPL">POPL</link> 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_LeungGeorge99" xreflabel="[References_LeungGeorge99]"/>
 <ulink url="http://www.cs.nyu.edu/leunga/my-papers/annotations.ps">MLRISC Annotations</ulink>.
 Allen Leung and Lal George. 1999.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_mmm_xreflabel_references_mmm_m">
<title><anchor id="References_MMM" xreflabel="[References_MMM]"/>M</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_MarlowEtAl01" xreflabel="[References_MarlowEtAl01]"/>
 <ulink url="http://community.haskell.org/~simonmar/papers/async.pdf">Asynchronous Exceptions in Haskell</ulink>.
 Simon Marlow, Simon Peyton Jones, Andy Moran and John Reppy.
 <link linkend="References_PLDI">PLDI</link> 2001.
</simpara>
<blockquote>
<simpara>An asynchronous exception is a signal that one thread can send to
another, and is useful for the receiving thread to treat as an
exception so that it can clean up locks or other state relevant to its
current context.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_MacQueenEtAl84" xreflabel="[References_MacQueenEtAl84]"/>
 <ulink url="http://homepages.inf.ed.ac.uk/gdp/publications/Ideal_model.pdf">An Ideal Model for Recursive Polymorphic Types</ulink>.
 David MacQueen, Gordon Plotkin, Ravi Sethi.
 <link linkend="References_POPL">POPL</link> 1984.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Matthews91" xreflabel="[References_Matthews91]"/>
 <ulink url="http://www.lfcs.inf.ed.ac.uk/reports/91/ECS-LFCS-91-174">A Distributed Concurrent Implementation of Standard ML</ulink>.
 David Matthews.
 University of Edinburgh Technical Report ECS-LFCS-91-174, 1991.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Matthews95" xreflabel="[References_Matthews95]"/>
 <ulink url="http://www.lfcs.inf.ed.ac.uk/reports/95/ECS-LFCS-95-335">Papers on Poly/ML</ulink>.
 David C. J. Matthews.
 University of Edinburgh Technical Report ECS-LFCS-95-335, 1995.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.lfcs.inf.ed.ac.uk/reports/97/ECS-LFCS-97-375">That About Wraps it Up: Using FIX to Handle Errors Without Exceptions, and Other Programming Tricks</ulink>.
 Bruce J. McAdam.
 University of Edinburgh Technical Report ECS-LFCS-97-375, 1997.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_MeierNorgaard93" xreflabel="[References_MeierNorgaard93]"/>
 A Just-In-Time Backend for Moscow ML 2.00 in SML.
 Bjarke Meier, Kristian Nørgaard.
 Masters Thesis, 2003.
</simpara>
<blockquote>
<simpara>A just-in-time compiler using GNU Lightning, showing a speedup of up
to four times over Moscow ML&#8217;s usual bytecode interpreter.</simpara>
<simpara>The full report is only available in
<ulink url="http://www.itu.dk/stud/speciale/bmkn/fundanemt/download/report">Danish</ulink>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Milner78" xreflabel="[References_Milner78]"/>
 <ulink url="http://courses.engr.illinois.edu/cs421/sp2013/project/milner-polymorphism.pdf">A Theory of Type Polymorphism in Programming</ulink>.
 Robin Milner.
 Journal of Computer and System Sciences, 1978.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Milner82" xreflabel="[References_Milner82]"/>
 <ulink url="http://homepages.inf.ed.ac.uk/dts/fps/papers/evolved.dvi.gz">How ML Evolved</ulink>.
 Robin Milner.
 Polymorphism&#8212;The ML/LCF/Hope Newsletter, 1983.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_MilnerTofte91" xreflabel="[References_MilnerTofte91]"/>
 <ulink url="http://www.itu.dk/people/tofte/publ/1990sml/1990sml.html">Commentary on Standard ML</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=0262631377&amp;type=ISBN">addall</ulink>)
 ISBN 0262631377.
 Robin Milner and Mads Tofte.
 The MIT Press, 1991.
</simpara>
<blockquote>
<simpara>Introduces and explains the notation and approach used in
<link linkend="References_MilnerEtAl90">The Definition of Standard ML</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_MilnerEtAl90" xreflabel="[References_MilnerEtAl90]"/>
 <ulink url="http://www.itu.dk/people/tofte/publ/1990sml/1990sml.html">The Definition of Standard ML</ulink>.
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=0262631326&amp;type=ISBN">addall</ulink>)
 ISBN 0262631326.
 Robin Milner, Mads Tofte, and Robert Harper.
 The MIT Press, 1990.
</simpara>
<blockquote>
<simpara>Superseded by <link linkend="References_MilnerEtAl97">The Definition of Standard ML (Revised)</link>.
Accompanied by the <link linkend="References_MilnerTofte91">Commentary on Standard ML</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_MilnerEtAl97" xreflabel="[References_MilnerEtAl97]"/>
 <ulink url="http://mitpress.mit.edu/books/definition-standard-ml">The Definition of Standard ML (Revised)</ulink>.
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=0262631814&amp;type=ISBN">addall</ulink>)
 ISBN 0262631814.
 Robin Milner, Mads Tofte, Robert Harper, and David MacQueen.
 The MIT Press, 1997.
</simpara>
<blockquote>
<simpara>A terse and formal specification of Standard ML&#8217;s syntax and
semantics.  Supersedes <link linkend="References_MilnerEtAl90">The Definition of Standard ML</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_ML2000" xreflabel="[References_ML2000]"/>
 <ulink url="http://flint.cs.yale.edu/flint/publications/ml2000.html">Principles and a Preliminary Design for ML2000</ulink>.
 The ML2000 working group, 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Morentsen99" xreflabel="[References_Morentsen99]"/>
 <ulink url="http://daimi.au.dk/CPnets/workshop99/papers/Mortensen.pdf">Automatic Code Generation from Coloured Petri Nets for an Access Control System</ulink>.
 Kjeld H. Mortensen.
 Workshop on Practical Use of Coloured Petri Nets and Design/CPN, 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_MorrisettTolmach93" xreflabel="[References_MorrisettTolmach93]"/>
 <ulink url="http://web.cecs.pdx.edu/~apt/ppopp93.ps">Procs and Locks: a Portable Multiprocessing Platform for Standard ML of New Jersey</ulink>.
 J. Gregory Morrisett and Andrew Tolmach.
 <link linkend="References_PPoPP">PPoPP</link> 1993.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Murphy06" xreflabel="[References_Murphy06]"/>
 <ulink url="http://www.cs.cmu.edu/~tom7/papers/grid-ml06.pdf">ML Grid Programming with ConCert</ulink>.
 Tom Murphy VII.
 <link linkend="References_ML">ML</link> 2006.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_nnn_xreflabel_references_nnn_n">
<title><anchor id="References_NNN" xreflabel="[References_NNN]"/>N</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Neumann99" xreflabel="[References_Neumann99]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.9485&amp;rep=rep1&amp;type=ps">fxp - Processing Structured Documents in SML</ulink>.
 Andreas Neumann.
 Scottish Functional Programming Workshop, 1999.
</simpara>
<blockquote>
<simpara>Describes <ulink url="http://atseidl2.informatik.tu-muenchen.de/~berlea/Fxp">fxp</ulink>,
an XML parser implemented in Standard ML.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Neumann99Thesis" xreflabel="[References_Neumann99Thesis]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.8108&amp;rep=rep1&amp;type=ps">Parsing and Querying XML Documents in SML</ulink>.
 Andreas Neumann.
 Doctoral Thesis, 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_NguyenOhori06" xreflabel="[References_NguyenOhori06]"/>
 <ulink url="http://www.pllab.riec.tohoku.ac.jp/~ohori/research/NguyenOhoriPPDP06.pdf">Compiling ML Polymorphism with Explicit Layout Bitmap</ulink>.
 Huu-Duc Nguyen and Atsushi Ohori.
 <link linkend="References_PPDP">PPDP</link> 2006.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_ooo_xreflabel_references_ooo_o">
<title><anchor id="References_OOO" xreflabel="[References_OOO]"/>O</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Okasaki99" xreflabel="[References_Okasaki99]"/>
<ulink url="http://www.cambridge.org/gb/academic/subjects/computer-science/programming-languages-and-applied-logic/purely-functional-data-structures">Purely Functional Data Structures</ulink>.
 ISBN 9780521663502.
 Chris Okasaki.
 Cambridge University Press, 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Ohori89" xreflabel="[References_Ohori89]"/>
 <ulink url="http://www.pllab.riec.tohoku.ac.jp/~ohori/research/fpca89.pdf">A Simple Semantics for ML Polymorphism</ulink>.
 Atsushi Ohori.
 <link linkend="References_FPCA">FPCA</link> 1989.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Ohori95" xreflabel="[References_Ohori95]"/>
 <ulink url="http://www.pllab.riec.tohoku.ac.jp/~ohori/research/toplas95.pdf">A Polymorphic Record Calculus and Its Compilation</ulink>.
 Atsushi Ohori.
 <link linkend="References_TOPLAS">TOPLAS</link> 1995.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_OhoriTakamizawa97" xreflabel="[References_OhoriTakamizawa97]"/>
 <ulink url="http://www.pllab.riec.tohoku.ac.jp/~ohori/research/jlsc97.pdf">An Unboxed Operational Semantics for ML Polymorphism</ulink>.
 Atsushi Ohori and Tomonobu Takamizawa.
 <link linkend="References_LASC">LASC</link> 1997.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Ohori99" xreflabel="[References_Ohori99]"/>
 <ulink url="http://www.pllab.riec.tohoku.ac.jp/~ohori/research/ic98.pdf">Type-Directed Specialization of Polymorphism</ulink>.
 Atsushi Ohori.
 <link linkend="References_IC">IC</link> 1999.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_OwensEtAl09" xreflabel="[References_OwensEtAl09]"/>
 <ulink url="http://www.mpi-sws.org/~turon/re-deriv.pdf">Regular-expression derivatives reexamined</ulink>.
 Scott Owens, John Reppy, and Aaron Turon.
 <link linkend="References_JFP">JFP</link> 2009.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_ppp_xreflabel_references_ppp_p">
<title><anchor id="References_PPP" xreflabel="[References_PPP]"/>P</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Paulson96" xreflabel="[References_Paulson96]"/>
 <ulink url="http://www.cambridge.org/co/academic/subjects/computer-science/programming-languages-and-applied-logic/ml-working-programmer-2nd-edition">ML For the Working Programmer</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=052156543X&amp;type=ISBN">addall</ulink>)
 ISBN 052156543X.
 Larry C. Paulson.
 Cambridge University Press, 1996.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_PetterssonEtAl02" xreflabel="[References_PetterssonEtAl02]"/>
 <ulink url="http://user.it.uu.se/~kostis/Papers/flops02_22.ps.gz">The HiPE/x86 Erlang Compiler: System Description and Performance Evaluation</ulink>.
 Mikael Pettersson, Konstantinos Sagonas, and Erik Johansson.
 <link linkend="References_FLOPS">FLOPS</link> 2002.
</simpara>
<blockquote>
<simpara>Describes a native x86 Erlang compiler and a comparison of many
different native x86 compilers (including MLton) and their register
usage and call stack implementations.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Price09" xreflabel="[References_Price09]"/>
 <ulink url="http://rogerprice.org/#UG">User&#8217;s Guide to ML-Lex and ML-Yacc</ulink>
 Roger Price.  2009.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Pucella98" xreflabel="[References_Pucella98]"/>
 <ulink url="http://arxiv.org/abs/cs.PL/0405080">Reactive Programming in Standard ML</ulink>.
 Riccardo R. Puccella.  1998.
 <link linkend="References_ICCL">ICCL</link> 1998.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_qqq_xreflabel_references_qqq_q">
<title><anchor id="References_QQQ" xreflabel="[References_QQQ]"/>Q</title>
<simpara></simpara>
</section>
<section id="_anchor_id_references_rrr_xreflabel_references_rrr_r">
<title><anchor id="References_RRR" xreflabel="[References_RRR]"/>R</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Ramsey90" xreflabel="[References_Ramsey90]"/>
 <ulink url="https://www.cs.princeton.edu/research/techreps/TR-262-90">Concurrent Programming in ML</ulink>.
 Norman Ramsey.
 Princeton University Technical Report CS-TR-262-90, 1990.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Ramsey11" xreflabel="[References_Ramsey11]"/>
 <ulink url="http://www.cs.tufts.edu/~nr/pubs/embedj-abstract.html">Embedding an Interpreted Language Using Higher-Order Functions and Types</ulink>.
 Norman Ramsey.
 <link linkend="References_JFP">JFP</link> 2011.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_RamseyFisherGovereau05" xreflabel="[References_RamseyFisherGovereau05]"/>
 <ulink url="http://www.cs.tufts.edu/~nr/pubs/els-abstract.html">An Expressive Language of Signatures</ulink>.
 Norman Ramsey, Kathleen Fisher, and Paul Govereau.
 <link linkend="References_ICFP">ICFP</link> 2005.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_RedwineRamsey04" xreflabel="[References_RedwineRamsey04]"/>
 <ulink url="http://www.cs.tufts.edu/~nr/pubs/widen-abstract.html">Widening Integer Arithmetic</ulink>.
 Kevin Redwine and Norman Ramsey.
 <link linkend="References_CC">CC</link> 2004.
</simpara>
<blockquote>
<simpara>Describes a method to implement numeric types and operations (like
<literal>Int31</literal> or <literal>Word17</literal>) for sizes smaller than that provided by the
processor.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Reppy88" xreflabel="[References_Reppy88]"/>
 Synchronous Operations as First-Class Values.
 John Reppy.
 <link linkend="References_PLDI">PLDI</link> 1988.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Reppy07" xreflabel="[References_Reppy07]"/>
 <ulink url="http://www.cambridge.org/co/academic/subjects/computer-science/distributed-networked-and-mobile-computing/concurrent-programming-ml">Concurrent Programming in ML</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=9780521714723&amp;type=ISBN">addall</ulink>).
 ISBN 9780521714723.
 John Reppy.
 Cambridge University Press, 2007.
</simpara>
<blockquote>
<simpara>Describes <link linkend="ConcurrentML">ConcurrentML</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Reynolds98" xreflabel="[References_Reynolds98]"/>
 <ulink url="https://users-cs.au.dk/hosc/local/HOSC-11-4-pp355-361.pdf">Definitional Interpreters Revisited</ulink>.
 John C. Reynolds.
 <link linkend="References_HOSC">HOSC</link> 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Reynolds98_2" xreflabel="[References_Reynolds98_2]"/>
 <ulink url="https://users-cs.au.dk/hosc/local/HOSC-11-4-pp363-397.pdf">Definitional Interpreters for Higher-Order Programming Languages</ulink>
 John C. Reynolds.
 <link linkend="References_HOSC">HOSC</link> 1998.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Rossberg01" xreflabel="[References_Rossberg01]"/>
 <ulink url="http://www.mpi-sws.org/~rossberg/papers/Rossberg%20-%20Defects%20in%20the%20Revised%20Definition%20of%20Standard%20ML%20%5B2007-01-22%20Update%5D.pdf">Defects in the Revised Definition of Standard ML</ulink>.
 Andreas Rossberg. 2001.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_sss_xreflabel_references_sss_s">
<title><anchor id="References_SSS" xreflabel="[References_SSS]"/>S</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Sansom91" xreflabel="[References_Sansom91]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.1020&amp;rep=rep1&amp;type=ps">Dual-Mode Garbage Collection</ulink>.
 Patrick M. Sansom.
 Workshop on the Parallel Implementation of Functional Languages, 1991.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ScottRamsey00" xreflabel="[References_ScottRamsey00]"/>
 <ulink url="http://www.cs.tufts.edu/~nr/pubs/match-abstract.html">When Do Match-Compilation Heuristics Matter</ulink>.
 Kevin Scott and Norman Ramsey.
 University of Virginia Technical Report CS-2000-13, 2000.
</simpara>
<blockquote>
<simpara>Modified SML/NJ to experimentally compare a number of
match-compilation heuristics and showed that choice of heuristic
usually does not significantly affect code size or run time.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Sestoft96" xreflabel="[References_Sestoft96]"/>
 <ulink url="http://www.itu.dk/~sestoft/papers/match.ps.gz">ML Pattern Match Compilation and Partial Evaluation</ulink>.
 Peter Sestoft.
 Partial Evaluation, 1996.
</simpara>
<blockquote>
<simpara>Describes the derivation of the match compiler used in
<link linkend="MoscowML">Moscow ML</link>.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_ShaoAppel94" xreflabel="[References_ShaoAppel94]"/>
 <ulink url="http://flint.cs.yale.edu/flint/publications/closure.html">Space-Efficient Closure Representations</ulink>.
 Zhong Shao and Andrew W. Appel.
 <link linkend="References_LFP">LFP</link> 1994.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Shipman02" xreflabel="[References_Shipman02]"/>
 <ulink url="guide/References.attachments/Shipman02.pdf">Unix System Programming with Standard ML</ulink>.
 Anthony L. Shipman.
 2002.
</simpara>
<blockquote>
<simpara>Includes a description of the <link linkend="Swerve">Swerve</link> HTTP server written in SML.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Signoles03" xreflabel="[References_Signoles03]"/>
 Calcul Statique des Applications de Modules Parametres.
 Julien Signoles.
 <link linkend="References_JFLA">JFLA</link> 2003.
</simpara>
<blockquote>
<simpara>Describes a <ulink url="http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=382">defunctorizer</ulink>
for OCaml, and compares it to existing defunctorizers, including MLton.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_SittampalamEtAl04" xreflabel="[References_SittampalamEtAl04]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.1349&amp;rep=rep1&amp;type=ps">Incremental Execution of Transformation Specifications</ulink>.
 Ganesh Sittampalam, Oege de Moor, and Ken Friis Larsen.
 <link linkend="References_POPL">POPL</link> 2004.
</simpara>
<blockquote>
<simpara>Mentions a port from Moscow ML to MLton of
<ulink url="http://www.itu.dk/research/muddy/">MuDDY</ulink>, an SML wrapper around the
<ulink url="http://sourceforge.net/projects/buddy">BuDDY</ulink> BDD package.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_SwaseyEtAl06" xreflabel="[References_SwaseyEtAl06]"/>
 <ulink url="http://www.cs.cmu.edu/~tom7/papers/smlsc2-ml06.pdf">A Separate Compilation Extension to Standard ML</ulink>.
 David Swasey, Tom Murphy VII, Karl Crary and Robert Harper.
 <link linkend="References_ML">ML</link> 2006.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_ttt_xreflabel_references_ttt_t">
<title><anchor id="References_TTT" xreflabel="[References_TTT]"/>T</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_TarditiAppel00" xreflabel="[References_TarditiAppel00]"/>
 <ulink url="http://www.smlnj.org/doc/ML-Yacc/index.html">ML-Yacc User&#8217;s Manual. Version 2.4</ulink>
 David R. Tarditi and Andrew W. Appel. 2000.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TarditiEtAl90" xreflabel="[References_TarditiEtAl90]"/>
 <ulink url="http://research.microsoft.com/pubs/68738/loplas-sml2c.ps">No Assembly Required: Compiling Standard ML to C</ulink>.
 David Tarditi, Peter Lee, and Anurag Acharya. 1990.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ThorupTofte94" xreflabel="[References_ThorupTofte94]"/>
 <ulink url="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.5372&amp;rep=rep1&amp;type=ps">Object-oriented programming and Standard ML</ulink>.
 Lars Thorup and Mads Tofte.
 <link linkend="References_ML">ML</link>, 1994.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Tofte90" xreflabel="[References_Tofte90]"/>
 Type Inference for Polymorphic References.
 Mads Tofte.
 <link linkend="References_IC">IC</link> 1990.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Tofte96" xreflabel="[References_Tofte96]"/>
 <ulink url="http://www.itu.dk/courses/FDP/E2004/Tofte-1996-Essentials_of_SML_Modules.pdf">Essentials of Standard ML Modules</ulink>.
 Mads Tofte.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Tofte09" xreflabel="[References_Tofte09]"/>
 <ulink url="http://www.itu.dk/people/tofte/publ/tips.pdf">Tips for Computer Scientists on Standard ML (Revised)</ulink>.
 Mads Tofte.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TolmachAppel95" xreflabel="[References_TolmachAppel95]"/>
 <ulink url="http://web.cecs.pdx.edu/~apt/jfp95.ps">A Debugger for Standard ML</ulink>.
 Andrew Tolmach and Andrew W. Appel.
 <link linkend="References_JFP">JFP</link> 1995.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Tolmach97" xreflabel="[References_Tolmach97]"/>
 <ulink url="http://web.cecs.pdx.edu/~apt/tic97.ps">Combining Closure Conversion with Closure Analysis using Algebraic Types</ulink>.
 Andrew Tolmach.
 <link linkend="References_TIC">TIC</link> 1997.
</simpara>
<blockquote>
<simpara>Describes a closure-conversion algorithm for a monomorphic IL.  The
algorithm uses a unification-based flow analysis followed by
defunctionalization and is similar to the approach used in MLton
(<link linkend="References_CejtinEtAl00">CejtinEtAl00</link>).</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_TolmachOliva98" xreflabel="[References_TolmachOliva98]"/>
 <ulink url="http://web.cecs.pdx.edu/~apt/jfp98.ps">From ML to Ada: Strongly-typed Language Interoperability via Source Translation</ulink>.
 Andrew Tolmach and Dino Oliva.
 <link linkend="References_JFP">JFP</link> 1998.
</simpara>
<blockquote>
<simpara>Describes a compiler for RML, a core SML-like language.  The compiler
is similar in structure to MLton, using monomorphisation,
defunctionalization, and optimization on a first-order IL.</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_uuu_xreflabel_references_uuu_u">
<title><anchor id="References_UUU" xreflabel="[References_UUU]"/>U</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Ullman98" xreflabel="[References_Ullman98]"/>
 <ulink url="http://www-db.stanford.edu/~ullman/emlp.html">Elements of ML Programming</ulink>
 (<ulink url="http://www3.addall.com/New/submitNew.cgi?query=0137903871&amp;type=ISBN">addall</ulink>).
 ISBN 0137903871.
 Jeffrey D. Ullman.
 Prentice-Hall, 1998.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_vvv_xreflabel_references_vvv_v">
<title><anchor id="References_VVV" xreflabel="[References_VVV]"/>V</title>
<simpara></simpara>
</section>
<section id="_anchor_id_references_www_xreflabel_references_www_w">
<title><anchor id="References_WWW" xreflabel="[References_WWW]"/>W</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Wand84" xreflabel="[References_Wand84]"/>
 <ulink url="http://portal.acm.org/citation.cfm?id=800527">A Types-as-Sets Semantics for Milner-Style Polymorphism</ulink>.
 Mitchell Wand.
 <link linkend="References_POPL">POPL</link> 1984.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Wang01" xreflabel="[References_Wang01]"/>
 <ulink url="http://ncstrl.cs.princeton.edu/expand.php?id=TR-640-01">Managing Memory with Types</ulink>.
 Daniel C. Wang.
 PhD Thesis.
</simpara>
<blockquote>
<simpara>Chapter 6 describes an implementation of a type-preserving garbage
collector for MLton.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_WangAppel01" xreflabel="[References_WangAppel01]"/>
 <ulink url="http://www.cs.princeton.edu/~appel/papers/typegc.pdf">Type-Preserving Garbage Collectors</ulink>.
 Daniel C. Wang and Andrew W. Appel.
 <link linkend="References_POPL">POPL</link> 2001.
</simpara>
<blockquote>
<simpara>Shows how to modify MLton to generate a strongly-typed garbage
collector as part of a program.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_WangMurphy02" xreflabel="[References_WangMurphy02]"/>
 <ulink url="http://www.cs.cmu.edu/~tom7/papers/wang-murphy-recursion.pdf">Programming With Recursion Schemes</ulink>.
 Daniel C. Wang and Tom Murphy VII.
</simpara>
<blockquote>
<simpara>Describes a programming technique for data abstraction, along with
benchmarks of MLton and other SML compilers.</simpara>
</blockquote>
</listitem>
<listitem>
<simpara>
<anchor id="References_Weeks06" xreflabel="[References_Weeks06]"/>
 <ulink url="guide/References.attachments/060916-mlton.pdf">Whole-Program Compilation in MLton</ulink>.
 Stephen Weeks.
 <link linkend="References_ML">ML</link> 2006.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_Wright95" xreflabel="[References_Wright95]"/>
 <ulink url="http://homepages.inf.ed.ac.uk/dts/fps/papers/wright.ps.gz">Simple Imperative Polymorphism</ulink>.
 Andrew Wright.
 <link linkend="References_LASC">LASC</link>, 8(4):343-355, 1995.
</simpara>
<blockquote>
<simpara>The origin of the <link linkend="ValueRestriction">ValueRestriction</link>.</simpara>
</blockquote>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_xxx_xreflabel_references_xxx_x">
<title><anchor id="References_XXX" xreflabel="[References_XXX]"/>X</title>
<simpara></simpara>
</section>
<section id="_anchor_id_references_yyy_xreflabel_references_yyy_y">
<title><anchor id="References_YYY" xreflabel="[References_YYY]"/>Y</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_Yang98" xreflabel="[References_Yang98]"/>
 <ulink url="http://cs.nyu.edu/zheyang/papers/YangZ--ICFP98.html">Encoding Types in ML-like Languages</ulink>.
 Zhe Yang.
 <link linkend="References_ICFP">ICFP</link> 1998.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_anchor_id_references_zzz_xreflabel_references_zzz_z">
<title><anchor id="References_ZZZ" xreflabel="[References_ZZZ]"/>Z</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_ZiarekEtAl06" xreflabel="[References_ZiarekEtAl06]"/>
 <ulink url="http://www.cs.purdue.edu/homes/lziarek/icfp06.pdf">Stabilizers: A Modular Checkpointing Abstraction for Concurrent Functional Programs</ulink>.
 Lukasz Ziarek, Philip Schatz, and Suresh Jagannathan.
 <link linkend="References_ICFP">ICFP</link> 2006.
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ZiarekEtAl08" xreflabel="[References_ZiarekEtAl08]"/>
 <ulink url="http://www.cse.buffalo.edu/~lziarek/hosc.pdf">Flattening tuples in an SSA intermediate representation</ulink>.
 Lukasz Ziarek, Stephen Weeks, and Suresh Jagannathan.
 <link linkend="References_HOSC">HOSC</link> 2008.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_abbreviations">
<title>Abbreviations</title>
<itemizedlist>
<listitem>
<simpara>
<anchor id="References_ACSD" xreflabel="[References_ACSD]"/> ACSD = International Conference on Application of Concurrency to System Design
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_BABEL" xreflabel="[References_BABEL]"/> BABEL = Workshop on multi-language infrastructure and interoperability
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_CC" xreflabel="[References_CC]"/> CC = International Conference on Compiler Construction
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_DPCOOL" xreflabel="[References_DPCOOL]"/> DPCOOL = Workshop on Declarative Programming in the Context of OO Languages
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ESOP" xreflabel="[References_ESOP]"/> ESOP = European Symposium on Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_FLOPS" xreflabel="[References_FLOPS]"/> FLOPS = Symposium on Functional and Logic Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_FPCA" xreflabel="[References_FPCA]"/> FPCA = Conference on Functional Programming Languages and Computer Architecture
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_HOSC" xreflabel="[References_HOSC]"/> HOSC = Higher-Order and Symbolic Computation
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_IC" xreflabel="[References_IC]"/> IC = Information and Computation
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ICCL" xreflabel="[References_ICCL]"/> ICCL = IEEE International Conference on Computer Languages
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ICFP" xreflabel="[References_ICFP]"/> ICFP = International Conference on Functional Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_IFL" xreflabel="[References_IFL]"/> IFL = International Workshop on Implementation and Application of Functional Languages
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_IVME" xreflabel="[References_IVME]"/> IVME = Workshop on Interpreters, Virtual Machines and Emulators
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_JFLA" xreflabel="[References_JFLA]"/> JFLA = Journees Francophones des Langages Applicatifs
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_JFP" xreflabel="[References_JFP]"/> JFP = Journal of Functional Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_LASC" xreflabel="[References_LASC]"/> LASC = Lisp and Symbolic Computation
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_LFP" xreflabel="[References_LFP]"/> LFP = Lisp and Functional Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_ML" xreflabel="[References_ML]"/> ML = Workshop on ML
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_PLDI" xreflabel="[References_PLDI]"/> PLDI = Conference on Programming Language Design and Implementation
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_POPL" xreflabel="[References_POPL]"/> POPL = Symposium on Principles of Programming Languages
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_PPDP" xreflabel="[References_PPDP]"/> PPDP = International Conference on Principles and Practice of Declarative Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_PPoPP" xreflabel="[References_PPoPP]"/> PPoPP = Principles and Practice of Parallel Programming
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TCS" xreflabel="[References_TCS]"/> TCS = IFIP International Conference on Theoretical Computer Science
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TIC" xreflabel="[References_TIC]"/> TIC = Types in Compilation
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TLDI" xreflabel="[References_TLDI]"/> TLDI = Workshop on Types in Language Design and Implementation
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TOPLAS" xreflabel="[References_TOPLAS]"/> TOPLAS = Transactions on Programming Languages and Systems
</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="References_TPHOLs" xreflabel="[References_TPHOLs]"/> TPHOLs = International Conference on Theorem Proving in Higher Order Logics
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RefFlatten">
<title>RefFlatten</title>
<simpara><link linkend="RefFlatten">RefFlatten</link> is an optimization pass for the <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSA2Simplify">SSA2Simplify</link>.</simpara>
<section id="_description_48">
<title>Description</title>
<simpara>This pass flattens a <literal>ref</literal> cell into its containing object.
The idea is to replace, where possible, a type like</simpara>
<screen>(int ref * real)</screen>
<simpara>with a type like</simpara>
<screen>(int[m] * real)</screen>
<simpara>where the <literal>[m]</literal> indicates a mutable field of a tuple.</simpara>
</section>
<section id="_implementation_53">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ref-flatten.fun"><literal>ref-flatten.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_51">
<title>Details and Notes</title>
<simpara>The savings is obvious, I hope.  We avoid an extra heap-allocated
object for the <literal>ref</literal>, which in the above case saves two words.  We
also save the time and code for the extra indirection at each get and
set.  There are lots of useful data structures (singly-linked and
doubly-linked lists, union-find, Fibonacci heaps, &#8230;) that I believe
we are paying through the nose right now because of the absence of ref
flattening.</simpara>
<simpara>The idea is to compute for each occurrence of a <literal>ref</literal> type in the
program whether or not that <literal>ref</literal> can be represented as an offset of
some object (constructor or tuple).  As before, a unification-based
whole-program with deep abstract values makes sure the analysis is
consistent.</simpara>
<simpara>The only syntactic part of the analysis that remains is the part that
checks that for a variable bound to a value constructed by <literal>Ref_ref</literal>:</simpara>
<itemizedlist>
<listitem>
<simpara>
the object allocation is in the same block.  This is pretty
draconian, and it would be nice to generalize it some day to allow
flattening as long as the <literal>ref</literal> allocation and object allocation "line
up one-to-one" in the same loop-free chunk of code.
</simpara>
</listitem>
<listitem>
<simpara>
updates occur in the same block (and hence it is safe-for-space
because the containing object is still alive).  It would be nice to
relax this to allow updates as long as it can be provedthat the
container is live.
</simpara>
</listitem>
</itemizedlist>
<simpara>Prevent flattening of <literal>unit ref</literal>-s.</simpara>
<simpara><link linkend="RefFlatten">RefFlatten</link> is safe for space.  The idea is to prevent a <literal>ref</literal>
being flattened into an object that has a component of unbounded size
(other than possibly the <literal>ref</literal> itself) unless we can prove that at
each point the <literal>ref</literal> is live, then the containing object is live too.
I used a pretty simple approximation to liveness.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Regions">
<title>Regions</title>
<simpara>In region-based memory management, the heap is divided into a
collection of regions into which objects are allocated.  At compile
time, either in the source program or through automatic inference,
allocation points are annotated with the region in which the
allocation will occur.  Typically, although not always, the regions
are allocated and deallocated according to a stack discipline.</simpara>
<simpara>MLton does not use region-based memory management; it uses traditional
<link linkend="GarbageCollection">GarbageCollection</link>.  We have considered integrating regions with
MLton, but in our opinion it is far from clear that regions would
provide MLton with improved performance, while they would certainly
add a lot of complexity to the compiler and complicate reasoning about
and achieving <link linkend="SpaceSafety">SpaceSafety</link>.  Region-based memory management and
garbage collection have different strengths and weaknesses; it&#8217;s
pretty easy to come up with programs that do significantly better
under regions than under GC, and vice versa.  We believe that it is
the case that common SML idioms tend to work better under GC than
under regions.</simpara>
<simpara>One common argument for regions is that the region operations can all
be done in (approximately) constant time; therefore, you eliminate GC
pause times, leading to a real-time GC.  However, because of space
safety concerns (see below), we believe that region-based memory
management for SML must also include a traditional garbage collector.
Hence, to achieve real-time memory management for MLton/SML, we
believe that it would be both easier and more efficient to implement a
traditional real-time garbage collector than it would be to implement
a region system.</simpara>
<section id="_regions_the_ml_kit_and_space_safety">
<title>Regions, the ML Kit, and space safety</title>
<simpara>The <link linkend="MLKit">ML Kit</link> pioneered the use of regions for compiling
Standard ML.  The ML Kit maintains a stack of regions at run time.  At
compile time, it uses region inference to decide when data can be
allocated in a stack-like manner, assigning it to an appropriate
region.  The ML Kit has put a lot of effort into improving the
supporting analyses and representations of regions, which are all
necessary to improve the performance.</simpara>
<simpara>Unfortunately, under a pure stack-based region system, space leaks are
inevitable in theory, and costly in practice.  Data for which region
inference can not determine the lifetime is moved into the "global
region" whose lifetime is the entire program.  There are two ways in
which region inference will place an object to the global region.</simpara>
<itemizedlist>
<listitem>
<simpara>
When the inference is too conservative, that is, when the data is
used in a stack-like manner but the region inference can&#8217;t figure it
out.
</simpara>
</listitem>
<listitem>
<simpara>
When data is not used in a stack-like manner.  In this case,
correctness requires region inference to place the object
</simpara>
</listitem>
</itemizedlist>
<simpara>This global region is a source of space leaks.  No matter what region
system you use, there are some programs such that the global region
must exist, and its size will grow to an unbounded multiple of the
live data size.  For these programs one must have a GC to achieve
space safety.</simpara>
<simpara>To solve this problem, the ML Kit has undergone work to combine
garbage collection with region-based memory management.
<link linkend="References_HallenbergEtAl02">HallenbergEtAl02</link> and <link linkend="References_Elsman03">Elsman03</link> describe the addition
of a garbage collector to the ML Kit&#8217;s region-based system.  These
papers provide convincing evidence for space leaks in the global
region.  They show a number of benchmarks where the memory usage of
the program running with just regions is a large multiple (2, 10, 50,
even 150) of the program running with regions plus GC.</simpara>
<simpara>These papers also give some numbers to show the ML Kit with just
regions does better than either a system with just GC or a combined
system.  Unfortunately, a pure region system isn&#8217;t practical because
of the lack of space safety.  And the other performance numbers are
not so convincing, because they compare to an old version of SML/NJ
and not at all with MLton.  It would be interesting to see a
comparison with a more serious collector.</simpara>
</section>
<section id="_regions_garbage_collection_and_cyclone">
<title>Regions, Garbage Collection, and Cyclone</title>
<simpara>One possibility is to take Cyclone&#8217;s approach, and provide both
region-based memory management and garbage collection, but at the
programmer&#8217;s option (<link linkend="References_GrossmanEtAl02">GrossmanEtAl02</link>, <link linkend="References_HicksEtAl03">HicksEtAl03</link>).</simpara>
<simpara>One might ask whether we might do the same thing&#8201;&#8212;&#8201;i.e., provide a
<literal>MLton.Regions</literal> structure with explicit region based memory
management operations, so that the programmer could use them when
appropriate.  <link linkend="MatthewFluet">MatthewFluet</link> has thought about this question</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.cs.cornell.edu/People/fluet/rgn-monad/index.html">http://www.cs.cornell.edu/People/fluet/rgn-monad/index.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>Unfortunately, his conclusion is that the SML type system is too weak
to support this option, although there might be a "poor-man&#8217;s" version
with dynamic checks.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Release20041109">
<title>Release20041109</title>
<simpara>This is an archived public release of MLton, version 20041109.</simpara>
<section id="_changes_since_the_last_public_release">
<title>Changes since the last public release</title>
<itemizedlist>
<listitem>
<simpara>
New platforms:
</simpara>
<itemizedlist>
<listitem>
<simpara>
x86: FreeBSD 5.x, OpenBSD
</simpara>
</listitem>
<listitem>
<simpara>
PowerPC: Darwin (MacOSX)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Support for the <link linkend="MLBasis">ML Basis system</link>, a new mechanism supporting programming in the very large, separate delivery of library sources, and more.
</simpara>
</listitem>
<listitem>
<simpara>
Support for dynamic libraries.
</simpara>
</listitem>
<listitem>
<simpara>
Support for <link linkend="ConcurrentML">ConcurrentML</link> (CML).
</simpara>
</listitem>
<listitem>
<simpara>
New structures: <literal>Int2</literal>, <literal>Int3</literal>, &#8230;, <literal>Int31</literal> and <literal>Word2</literal>, <literal>Word3</literal>, &#8230;, <literal>Word31</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Front-end bug fixes and improvements.
</simpara>
</listitem>
<listitem>
<simpara>
A new form of profiling with <literal>-profile count</literal>, which can be used to test code coverage.
</simpara>
</listitem>
<listitem>
<simpara>
A bytecode generator, available via <literal>-codegen bytecode</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Representation improvements:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Tuples and datatypes are packed to decrease space usage.
</simpara>
</listitem>
<listitem>
<simpara>
Ref cells may be unboxed into their containing object.
</simpara>
</listitem>
<listitem>
<simpara>
Arrays of tuples may represent the tuples unboxed.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>For a complete list of changes and bug fixes since 20040227, see the
<ulink url="https://raw.github.com/MLton/mlton/on-20041109-release/doc/changelog"><literal>changelog</literal></ulink>.</simpara>
</section>
<section id="_also_see_31">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20041109">Bugs20041109</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Release20051202">
<title>Release20051202</title>
<simpara>This is an archived public release of MLton, version 20051202.</simpara>
<section id="_changes_since_the_last_public_release_2">
<title>Changes since the last public release</title>
<itemizedlist>
<listitem>
<simpara>
The <link linkend="License">MLton license</link> is now BSD-style instead of the GPL.
</simpara>
</listitem>
<listitem>
<simpara>
New platforms: <link linkend="RunningOnMinGW">X86/MinGW</link> and HPPA/Linux.
</simpara>
</listitem>
<listitem>
<simpara>
Improved and expanded documentation, based on the MLton wiki.
</simpara>
</listitem>
<listitem>
<simpara>
Compiler.
</simpara>
<itemizedlist>
<listitem>
<simpara>
improved exception history.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CompileTimeOptions">Command-line switches</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>-as-opt</literal>, <literal>-mlb-path-map</literal>, <literal>-target-as-opt</literal>, <literal>-target-cc-opt</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Removed: <literal>-native</literal>, <literal>-sequence-unit</literal>, <literal>-warn-match</literal>, <literal>-warn-unused</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Language.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ForeignFunctionInterface">FFI</link> syntax changes and extensions.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>_symbol</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Changed: <literal>_export</literal>, <literal>_import</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Removed: <literal>_ffi</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasisAnnotations">ML Basis annotations</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>allowFFI</literal>, <literal>nonexhaustiveExnMatch</literal>, <literal>nonexhaustiveMatch</literal>, <literal>redundantMatch</literal>, <literal>sequenceNonUnit</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Deprecated: <literal>allowExport</literal>, <literal>allowImport</literal>, <literal>sequenceUnit</literal>, <literal>warnMatch</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Basis Library.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>Int1</literal>, <literal>Word1</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonStructure">MLton structure</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>Process.create</literal>, <literal>ProcEnv.setgroups</literal>, <literal>Rusage.measureGC</literal>, <literal>Socket.fdToSock</literal>, <literal>Socket.Ctl.getError</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Changed: <literal>MLton.Platform.Arch</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Other libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <link linkend="CKitLibrary">ckit</link>, <link linkend="MLNLFFI">ML-NLFFI library</link>, <link linkend="SMLNJLibrary">SML/NJ library</link>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Updates of <literal>mllex</literal> and <literal>mlyacc</literal> from SML/NJ.
</simpara>
</listitem>
<listitem>
<simpara>
Added <link linkend="MLNLFFI">mlnlffigen</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Profiling">Profiling</link> supports better inclusion/exclusion of code.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>For a complete list of changes and bug fixes since
<link linkend="Release20041109">Release20041109</link>, see the
<ulink url="https://raw.github.com/MLton/mlton/on-20051202-release/doc/changelog"><literal>changelog</literal></ulink> and
<link linkend="Bugs20041109">Bugs20041109</link>.</simpara>
</section>
<section id="_20051202_binary_packages">
<title>20051202 binary packages</title>
<itemizedlist>
<listitem>
<simpara>
x86
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386-cygwin.tgz">Cygwin</ulink> 1.5.18-1
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386-freebsd.tbz">FreeBSD</ulink> 5.4
</simpara>
</listitem>
<listitem>
<simpara>
Linux
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton_20051202-1_i386.deb">Debian</ulink> sid
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton_20051202-1_i386.stable.deb">Debian</ulink> stable (Sarge)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386.rpm">RedHat</ulink> 7.1-9.3 FC1-FC4
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386-linux.tgz">tgz</ulink> for other distributions (glibc 2.3)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386-mingw.tgz">MinGW</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386-netbsd.tgz">NetBSD</ulink> 2.0.2
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.i386-openbsd.tgz">OpenBSD</ulink> 3.7
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
PowerPC
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.powerpc-darwin.tgz">Darwin</ulink> 7.9.0 (Mac OS X)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Sparc
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.sparc-solaris.tgz">Solaris</ulink> 8
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_20051202_source_packages">
<title>20051202 source packages</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.src.tgz">source tgz</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
Debian <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton_20051202-1.dsc">dsc</ulink>, <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton_20051202-1.diff.gz">diff.gz</ulink>, <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton_20051202.orig.tar.gz">orig.tar.gz</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
RedHat <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20051202/mlton-20051202-1.src.rpm">source rpm</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_packages_available_at_other_sites">
<title>Packages available at other sites</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&amp;version=all&amp;exact=1&amp;keywords=mlton">Debian</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.freebsd.org/cgi/ports.cgi?query=mlton&amp;stype=all">FreeBSD</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
Fedora Core <ulink url="http://fedoraproject.org/extras/4/i386/repodata/repoview/mlton-0-20051202-8.fc4.html">4</ulink> <ulink url="http://fedoraproject.org/extras/5/i386/repodata/repoview/mlton-0-20051202-8.fc5.html">5</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://packages.ubuntu.com/dapper/devel/mlton">Ubuntu</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_32">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20051202">Bugs20051202</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/guide/20051202/">MLton Guide (20051202)</ulink>.
</simpara>
<simpara>A snapshot of the MLton wiki at the time of release.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Release20070826">
<title>Release20070826</title>
<simpara>This is an archived public release of MLton, version 20070826.</simpara>
<section id="_changes_since_the_last_public_release_3">
<title>Changes since the last public release</title>
<itemizedlist>
<listitem>
<simpara>
New platforms:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAMD64">AMD64</link>/<link linkend="RunningOnLinux">Linux</link>, <link linkend="RunningOnAMD64">AMD64</link>/<link linkend="RunningOnFreeBSD">FreeBSD</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnHPPA">HPPA</link>/<link linkend="RunningOnHPUX">HPUX</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC">PowerPC</link>/<link linkend="RunningOnAIX">AIX</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnX86">X86</link>/<link linkend="RunningOnDarwin">Darwin (Mac OS X)</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Compiler.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Support for 64-bit platforms.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Native amd64 codegen.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="CompileTimeOptions">Compile-time options</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>-codegen amd64</literal>, <literal>-codegen x86</literal>, <literal>-default-type <emphasis>type</emphasis></literal>, <literal>-profile-val {false|true}</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Changed: <literal>-stop f</literal> (file listing now includes <literal>.mlb</literal> files).
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Bytecode codegen.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Support for exception history.
</simpara>
</listitem>
<listitem>
<simpara>
Support for profiling.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Language.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="MLBasisAnnotations">ML Basis annotations</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Removed: <literal>allowExport</literal>, <literal>allowImport</literal>, <literal>sequenceUnit</literal>, <literal>warnMatch</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="BasisLibrary">Basis Library</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>PackWord16Big</literal>, <literal>PackWord16Little</literal>, <literal>PackWord64Big</literal>, <literal>PackWord64Little</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20070826-release/doc/changelog"><literal>changelog</literal></ulink>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonStructure">MLton structure</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>MLTON_MONO_ARRAY</literal>, <literal>MLTON_MONO_VECTOR</literal>, <literal>MLTON_REAL</literal>, <literal>MLton.BinIO.tempPrefix</literal>, <literal>MLton.CharArray</literal>, <literal>MLton.CharVector</literal>, <literal>MLton.Exn.defaultTopLevelHandler</literal>, <literal>MLton.Exn.getTopLevelHandler</literal>, <literal>MLton.Exn.setTopLevelHandler</literal>, <literal>MLton.IntInf.BigWord</literal>, <literal>Mlton.IntInf.SmallInt</literal>, <literal>MLton.LargeReal</literal>, <literal>MLton.LargeWord</literal>, <literal>MLton.Real</literal>, <literal>MLton.Real32</literal>, <literal>MLton.Real64</literal>, <literal>MLton.Rlimit.Rlim</literal>, <literal>MLton.TextIO.tempPrefix</literal>, <literal>MLton.Vector.create</literal>, <literal>MLton.Word.bswap</literal>, <literal>MLton.Word8.bswap</literal>, <literal>MLton.Word16</literal>, <literal>MLton.Word32</literal>, <literal>MLton.Word64</literal>, <literal>MLton.Word8Array</literal>, <literal>MLton.Word8Vector</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Changed: <literal>MLton.Array.unfoldi</literal>, <literal>MLton.IntInf.rep</literal>, <literal>MLton.Rlimit</literal>, <literal>MLton.Vector.unfoldi</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Deprecated: <literal>MLton.Socket</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Other libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <link linkend="MLRISCLibrary">MLRISC library</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Updated: <link linkend="CKitLibrary">ckit library</link>, <link linkend="SMLNJLibrary">SML/NJ library</link>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools.
</simpara>
</listitem>
</itemizedlist>
<simpara>For a complete list of changes and bug fixes since
<link linkend="Release20051202">Release20051202</link>, see the
<ulink url="https://raw.github.com/MLton/mlton/on-20070826-release/doc/changelog"><literal>changelog</literal></ulink> and
<link linkend="Bugs20051202">Bugs20051202</link>.</simpara>
</section>
<section id="_20070826_binary_packages">
<title>20070826 binary packages</title>
<itemizedlist>
<listitem>
<simpara>
AMD64
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.amd64-linux.tgz">Linux</ulink>, glibc 2.3
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
HPPA
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.hppa-hpux1100.tgz">HPUX</ulink> 11.00 and above, statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
PowerPC
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.powerpc-aix51.tgz">AIX</ulink> 5.1 and above, statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.powerpc-darwin.gmp-static.tgz">Darwin</ulink> 8.10 (Mac OS X), statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.powerpc-darwin.gmp-macports.tgz">Darwin</ulink> 8.10 (Mac OS X), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/opt/local/lib</literal> (suitable for <ulink url="http://macports.org">MacPorts</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Sparc
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.sparc-solaris8.tgz">Solaris</ulink> 8 and above, statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
X86
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-cygwin.tgz">Cygwin</ulink> 1.5.24-2
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-darwin.gmp-macports.tgz">Darwin (.tgz)</ulink> 8.10 (Mac OS X), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/opt/local/lib</literal> (suitable for <ulink url="http://macports.org">MacPorts</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-darwin.gmp-macports.dmg">Darwin (.dmg)</ulink> 8.10 (Mac OS X), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/opt/local/lib</literal> (suitable for <ulink url="http://macports.org">MacPorts</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-darwin.gmp-static.tgz">Darwin (.tgz)</ulink> 8.10 (Mac OS X), statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-darwin.gmp-static.dmg">Darwin (.dmg)</ulink> 8.10 (Mac OS X), statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-freebsd.tgz">FreeBSD</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-linux.tgz">Linux</ulink>, glibc 2.3
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-linux.glibc213.gmp-static.tgz">Linux</ulink>, glibc 2.1, statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-mingw.gmp-dll.tgz">MinGW</ulink>, dynamically linked against <link linkend="GnuMP">GnuMP</link> (requires <literal>libgmp-3.dll</literal>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.x86-mingw.gmp-static.tgz">MinGW</ulink>, statically linked against <link linkend="GnuMP">GnuMP</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_20070826_source_packages">
<title>20070826 source packages</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton-20070826-1.src.tgz">source tgz</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
Debian <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton_20070826-1.dsc">dsc</ulink>,
 <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton_20070826-1.diff.gz">diff.gz</ulink>,
 <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20070826/mlton_20070826.orig.tar.gz">orig.tar.gz</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_packages_available_at_other_sites_2">
<title>Packages available at other sites</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://packages.debian.org/search?keywords=mlton&amp;searchon=names&amp;suite=all&amp;section=all">Debian</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.freebsd.org/cgi/ports.cgi?query=mlton&amp;stype=all">FreeBSD</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://admin.fedoraproject.org/pkgdb/packages/name/mlton">Fedora</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=mlton&amp;searchon=names&amp;version=all&amp;release=all">Ubuntu</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_33">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20070826">Bugs20070826</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/guide/20070826/">MLton Guide (20070826)</ulink>.
</simpara>
<simpara>A snapshot of the MLton wiki at the time of release.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Release20100608">
<title>Release20100608</title>
<simpara>This is an archived public release of MLton, version 20100608.</simpara>
<section id="_changes_since_the_last_public_release_4">
<title>Changes since the last public release</title>
<itemizedlist>
<listitem>
<simpara>
New platforms.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAMD64">AMD64</link>/<link linkend="RunningOnDarwin">Darwin</link> (Mac OS X Snow Leopard)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnIA64">IA64</link>/<link linkend="RunningOnHPUX">HPUX</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC64">PowerPC64</link>/<link linkend="RunningOnAIX">AIX</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Compiler.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CompileTimeOptions">Command-line switches</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>-mlb-path-var <emphasis>&lt;name&gt; &lt;value&gt;</emphasis></literal>
</simpara>
</listitem>
<listitem>
<simpara>
Removed: <literal>-keep sml</literal>, <literal>-stop sml</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Improved constant folding of floating-point operations.
</simpara>
</listitem>
<listitem>
<simpara>
Experimental: Support for compiling to a C library; see <link linkend="LibrarySupport">documentation</link>.
</simpara>
</listitem>
<listitem>
<simpara>
Extended <literal>-show-def-use <emphasis>output</emphasis></literal> to include types of variable definitions.
</simpara>
</listitem>
<listitem>
<simpara>
Deprecated features (to be removed in a future release)
</simpara>
<itemizedlist>
<listitem>
<simpara>
Bytecode codegen: The bytecode codegen has not seen significant use and it is not well understood by any of the active developers.
</simpara>
</listitem>
<listitem>
<simpara>
Support for <literal>.cm</literal> files as input: The ML Basis system provides much better infrastructure for "programming in the very large" than the (very) limited support for CM.  The <literal>cm2mlb</literal> tool (available in the source distribution) can be used to convert CM projects to MLB projects, preserving the CM scoping of module identifiers.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20100608-release/doc/changelog"><literal>changelog</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Runtime.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunTimeOptions">@MLton switches</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>may-page-heap {false|true}</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>may-page-heap</literal>: By default, MLton will not page the heap to disk when unable to grow the heap to accommodate an allocation. (Previously, this behavior was the default, with no means to disable, with security an least-surprise issues.)
</simpara>
</listitem>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20100608-release/doc/changelog"><literal>changelog</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Language.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Allow numeric characters in <link linkend="MLBasis">ML Basis</link> path variables.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="BasisLibrary">Basis Library</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20100608-release/doc/changelog"><literal>changelog</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonStructure">MLton structure</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>MLton.equal</literal>, <literal>MLton.hash</literal>, <literal>MLton.Cont.isolate</literal>, <literal>MLton.GC.Statistics</literal>, <literal>MLton.Pointer.sizeofPointer</literal>, <literal>MLton.Socket.Address.toVector</literal>
</simpara>
</listitem>
<listitem>
<simpara>
Changed:
</simpara>
</listitem>
<listitem>
<simpara>
Deprecated: <literal>MLton.Socket</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="UnsafeStructure">Unsafe structure</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added versions of all of the monomorphic array and vector structures.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Other libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Updated: <link linkend="CKitLibrary">ckit library</link>, <link linkend="MLRISCLibrary">MLRISC library</link>, <link linkend="SMLNJLibrary">SML/NJ library</link>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>mllex</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Eliminated top-level <literal>type int = Int.int</literal> in output.
</simpara>
</listitem>
<listitem>
<simpara>
Include <literal>(*#line line:col "file.lex" *)</literal> directives in output.
</simpara>
</listitem>
<listitem>
<simpara>
Added <literal>%posint</literal> command, to set the <literal>yypos</literal> type and allow the lexing of multi-gigabyte files.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>mlnlffigen</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added command-line switches <literal>-linkage archive</literal> and <literal>-linkage shared</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Deprecated command-line switch <literal>-linkage static</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Added support for <link linkend="RunningOnIA64">IA64</link> and <link linkend="RunningOnHPPA">HPPA</link> targets.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>mlyacc</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Eliminated top-level <literal>type int = Int.int</literal> in output.
</simpara>
</listitem>
<listitem>
<simpara>
Include <literal>(*#line line:col "file.grm" *)</literal> directives in output.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>For a complete list of changes and bug fixes since <link linkend="Release20070826">Release20070826</link>, see the
<ulink url="https://raw.github.com/MLton/mlton/on-20100608-release/doc/changelog"><literal>changelog</literal></ulink>
and <link linkend="Bugs20070826">Bugs20070826</link>.</simpara>
</section>
<section id="_20100608_binary_packages">
<title>20100608 binary packages</title>
<itemizedlist>
<listitem>
<simpara>
AMD64 (aka "x86-64" or "x64")
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.amd64-darwin.gmp-macports.tgz">Darwin (.tgz)</ulink> 10.3 (Mac OS X Snow Leopard), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/opt/local/lib</literal> (suitable for <ulink url="http://macports.org">MacPorts</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.amd64-darwin.gmp-static.tgz">Darwin (.tgz)</ulink> 10.3 (Mac OS X Snow Leopard), statically linked against <link linkend="GnuMP">GnuMP</link> (but requires <link linkend="GnuMP">GnuMP</link> for generated executables)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.amd64-linux.tgz">Linux</ulink>, glibc 2.11
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.amd64-linux.static.tgz">Linux</ulink>, statically linked
</simpara>
</listitem>
<listitem>
<simpara>
Windows MinGW 32/64 <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/MLton-20100608-1.exe">self-extracting</ulink> (28MB) or <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/MLton-20100608-1.msi">MSI</ulink> (61MB) installer
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
X86
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.x86-cygwin.tgz">Cygwin</ulink> 1.7.5
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.x86-darwin.gmp-macports.tgz">Darwin (.tgz)</ulink> 9.8 (Mac OS X Leopard), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/opt/local/lib</literal> (suitable for <ulink url="http://macports.org">MacPorts</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.x86-darwin.gmp-static.tgz">Darwin (.tgz)</ulink> 9.8 (Mac OS X Leopard), statically linked against <link linkend="GnuMP">GnuMP</link> (but requires <link linkend="GnuMP">GnuMP</link> for generated executables)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.x86-linux.tgz">Linux</ulink>, glibc 2.11
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608-1.x86-linux.static.tgz">Linux</ulink>, statically linked
</simpara>
</listitem>
<listitem>
<simpara>
Windows MinGW 32/64 <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/MLton-20100608-1.exe">self-extracting</ulink> (28MB) or <ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/MLton-20100608-1.msi">MSI</ulink> (61MB) installer
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_20100608_source_packages">
<title>20100608 source packages</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20100608/mlton-20100608.src.tgz">mlton-20100608.src.tgz</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_packages_available_at_other_sites_3">
<title>Packages available at other sites</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://packages.debian.org/search?keywords=mlton&amp;searchon=names&amp;suite=all&amp;section=all">Debian</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.freebsd.org/cgi/ports.cgi?query=mlton&amp;stype=all">FreeBSD</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://admin.fedoraproject.org/pkgdb/acls/name/mlton">Fedora</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://packages.ubuntu.com/search?suite=default&amp;section=all&amp;arch=any&amp;searchon=names&amp;keywords=mlton">Ubuntu</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_34">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20100608">Bugs20100608</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/guide/20100608/">MLton Guide (20100608)</ulink>.
</simpara>
<simpara>A snapshot of the MLton wiki at the time of release.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Release20130715">
<title>Release20130715</title>
<simpara>This is an archived public release of MLton, version 20130715.</simpara>
<section id="_changes_since_the_last_public_release_5">
<title>Changes since the last public release</title>
<itemizedlist>
<listitem>
<simpara>
Compiler.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Cosmetic improvements to type-error messages.
</simpara>
</listitem>
<listitem>
<simpara>
Removed features:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Bytecode codegen: The bytecode codegen had not seen significant use and it was not well understood by any of the active developers.
</simpara>
</listitem>
<listitem>
<simpara>
Support for <literal>.cm</literal> files as input: The <link linkend="MLBasis">ML Basis system</link> provides much better infrastructure for "programming in the very large" than the (very) limited support for CM.  The <literal>cm2mlb</literal> tool (available in the source distribution) can be used to convert CM projects to MLB projects, preserving the CM scoping of module identifiers.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20130715-release/doc/changelog"><literal>changelog</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Runtime.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20130715-release/doc/changelog"><literal>changelog</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Language.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Interpret <literal>(*#line line:col "file" *)</literal> directives as relative file names.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLBasisAnnotations">ML Basis annotations</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added: <literal>resolveScope</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="BasisLibrary">Basis Library</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Improved performance of <literal>String.concatWith</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Use bit operations for <literal>REAL.class</literal> and other low-level operations.
</simpara>
</listitem>
<listitem>
<simpara>
Support additional variables with <literal>Posix.ProcEnv.sysconf</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Bug fixes: see <ulink url="https://raw.github.com/MLton/mlton/on-20130715-release/doc/changelog"><literal>changelog</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<link linkend="MLtonStructure">MLton structure</link>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Removed: <literal>MLton.Socket</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Other libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Updated: <link linkend="CKitLibrary">ckit library</link>, <link linkend="MLRISCLibrary">MLRISC library</link>, <link linkend="SMLNJLibrary">SML/NJ library</link>
</simpara>
</listitem>
<listitem>
<simpara>
Added: <link linkend="MLLPTLibrary">MLLPT library</link>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>mllex</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Generate <literal>(*#line line:col "file.lex" *)</literal> directives with simple (relative) file names, rather than absolute paths.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>mlyacc</literal>
</simpara>
<itemizedlist>
<listitem>
<simpara>
Generate <literal>(*#line line:col "file.grm" *)</literal> directives with simple (relative) file names, rather than absolute paths.
</simpara>
</listitem>
<listitem>
<simpara>
Fixed bug in comment-handling in lexer.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>For a complete list of changes and bug fixes since
<link linkend="Release20100608">Release20100608</link>, see the
<ulink url="https://raw.github.com/MLton/mlton/on-20130715-release/doc/changelog"><literal>changelog</literal></ulink> and
<link linkend="Bugs20100608">Bugs20100608</link>.</simpara>
</section>
<section id="_20130715_binary_packages">
<title>20130715 binary packages</title>
<itemizedlist>
<listitem>
<simpara>
AMD64 (aka "x86-64" or "x64")
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20130715/mlton-20130715-1.amd64-darwin.gmp-macports.tgz">Darwin (.tgz)</ulink> 11.4 (Mac OS X Lion), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/opt/local/lib</literal> (suitable for <ulink url="http://macports.org">MacPorts</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20130715/mlton-20130715-1.amd64-darwin.gmp-static.tgz">Darwin (.tgz)</ulink> 11.4 (Mac OS X Lion), statically linked against <link linkend="GnuMP">GnuMP</link> (but requires <link linkend="GnuMP">GnuMP</link> for generated executables)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20130715/mlton-20130715-1.amd64-linux.tgz">Linux</ulink>, glibc 2.15

</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
X86
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20130715/mlton-20130715-1.x86-linux.tgz">Linux</ulink>, glibc 2.15

</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_20130715_source_packages">
<title>20130715 source packages</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://sourceforge.net/projects/mlton/files/mlton/20130715/mlton-20130715.src.tgz">mlton-20130715.src.tgz</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_downstream_packages">
<title>Downstream packages</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://packages.debian.org/search?keywords=mlton&amp;searchon=names&amp;suite=all&amp;section=all">Debian</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.freebsd.org/cgi/ports.cgi?query=mlton&amp;stype=all">FreeBSD</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://admin.fedoraproject.org/pkgdb/acls/name/mlton">Fedora</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://packages.ubuntu.com/search?suite=default&amp;section=all&amp;arch=any&amp;searchon=names&amp;keywords=mlton">Ubuntu</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_35">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20130715">Bugs20130715</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/guide/20130715/">MLton Guide (20130715)</ulink>.
</simpara>
<simpara>A snapshot of the MLton website at the time of release.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Release20180207">
<title>Release20180207</title>
<simpara>Here you can download the latest public release of MLton, version 20180207.</simpara>
<section id="_changes_since_the_last_public_release_6">
<title>Changes since the last public release</title>
<itemizedlist>
<listitem>
<simpara>
Compiler.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added an experimental LLVM codegen (<literal>-codegen llvm</literal>); requires LLVM tools
  (<literal>llvm-as</literal>, <literal>opt</literal>, <literal>llc</literal>) version &ge; 3.7.
</simpara>
</listitem>
<listitem>
<simpara>
Made many substantial cosmetic improvements to front-end diagnostic
  messages, especially with respect to source location regions, type inference
  for <literal>fun</literal> and <literal>val rec</literal> declarations, signature constraints applied to a
  structure, <literal>sharing type</literal> specifications and <literal>where type</literal> signature
  expressions, type constructor or type variable escaping scope, and
  nonexhaustive pattern matching.
</simpara>
</listitem>
<listitem>
<simpara>
Fixed minor bugs with exception replication, precedence parsing of function
  clauses, and simultaneous <literal>sharing</literal> of multiple structures.
</simpara>
</listitem>
<listitem>
<simpara>
Made compilation deterministic (eliminate output executable name from
  compile-time specified <literal>@MLton</literal> runtime arguments; deterministically generate
  magic constant for executable).
</simpara>
</listitem>
<listitem>
<simpara>
Updated <literal>-show-basis</literal> (recursively expand structures in environments,
  displaying components with long identifiers; append <literal>(* @ region *)</literal>
  annotations to items shown in environment).
</simpara>
</listitem>
<listitem>
<simpara>
Forced amd64 codegen to generate PIC on amd64-linux targets.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Runtime.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added <literal>gc-summary-file file</literal> runtime option.
</simpara>
</listitem>
<listitem>
<simpara>
Reorganized runtime support for <literal>IntInf</literal> operations so that programs that
  do not use <literal>IntInf</literal> compile to executables with no residual dependency on GMP.
</simpara>
</listitem>
<listitem>
<simpara>
Changed heap representation to store forwarding pointer for an object in
  the object header (rather than in the object data and setting the header to a
  sentinel value).
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Language.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added support for selected SuccessorML features; see
  <ulink url="http://mlton.org/SuccessorML">http://mlton.org/SuccessorML</ulink> for details.
</simpara>
</listitem>
<listitem>
<simpara>
Added <literal>(*#showBasis "file" *)</literal> directive; see
  <ulink url="http://mlton.org/ShowBasisDirective">http://mlton.org/ShowBasisDirective</ulink> for details.
</simpara>
</listitem>
<listitem>
<simpara>
FFI:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added <literal>pure</literal>, <literal>impure</literal>, and <literal>reentrant</literal> attributes to <literal>_import</literal>.  An
    unattributed <literal>_import</literal> is treated as <literal>impure</literal>.  A <literal>pure</literal> <literal>_import</literal> may be
    subject to more aggressive optimizations (common subexpression elimination,
    dead-code elimination).  An <literal>_import</literal>-ed C function that (directly or
    indirectly) calls an <literal>_export</literal>-ed SML function should be attributed
    <literal>reentrant</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
ML Basis annotations.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added <literal>allowSuccessorML {false|true}</literal> to enable all SuccessorML features
    and other annotations to enable specific SuccessorML features; see
    <ulink url="http://mlton.org/SuccessorML">http://mlton.org/SuccessorML</ulink> for details.
</simpara>
</listitem>
<listitem>
<simpara>
Split <literal>nonexhaustiveMatch {warn|error|igore}</literal> and <literal>redundantMatch
    {warn|error|ignore}</literal> into <literal>nonexhaustiveMatch</literal> and <literal>redundantMatch</literal>
    (controls diagnostics for <literal>case</literal> expressions, <literal>fn</literal> expressions, and <literal>fun</literal>
    declarations (which may raise <literal>Match</literal> on failure)) and <literal>nonexhaustiveBind</literal>
    and <literal>redundantBind</literal> (controls diagnostics for <literal>val</literal> declarations (which may
    raise <literal>Bind</literal> on failure)).
</simpara>
</listitem>
<listitem>
<simpara>
Added <literal>valrecConstr {warn|error|ignore}</literal> to report when a <literal>val rec</literal> (or
    <literal>fun</literal>) declaration redefines an identifier that previously had constructor
    status.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Basis Library.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Improved performance of <literal>Array.copy</literal>, <literal>Array.copyVec</literal>, <literal>Vector.append</literal>,
    <literal>String.^</literal>, <literal>String.concat</literal>, <literal>String.concatWith</literal>, and other related
    functions by using <literal>memmove</literal> rather than element-by-element constructions.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<literal>Unsafe</literal> structure.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Added unsafe operations for array uninitialization and raw arrays; see
    <ulink url="https://github.com/MLton/mlton/pull/207">https://github.com/MLton/mlton/pull/207</ulink> for details.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Other libraries.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Updated: ckit library, MLLPT library, MLRISC library, SML/NJ library
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Tools.
</simpara>
<itemizedlist>
<listitem>
<simpara>
mlnlffigen
</simpara>
<itemizedlist>
<listitem>
<simpara>
Updated to warn and skip (rather than abort) when encountering functions
    with <literal>struct</literal>/<literal>union</literal> argument or return type.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>For a complete list of changes and bug fixes since
<link linkend="Release20130715">Release20130715</link>, see the
<ulink url="https://github.com/MLton/mlton/blob/on-20180207-release/CHANGELOG.adoc"><literal>CHANGELOG.adoc</literal></ulink> and
<link linkend="Bugs20130715">Bugs20130715</link>.</simpara>
</section>
<section id="_20180207_binary_packages">
<title>20180207 binary packages</title>
<itemizedlist>
<listitem>
<simpara>
AMD64 (aka "x86-64" or "x64")
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://sourceforge.net/projects/mlton/files/mlton/20180207/mlton-20180207-1.amd64-darwin.gmp-homebrew.tgz">Darwin (.tgz)</ulink> 16.7 (Mac OS X Sierra), dynamically linked against <link linkend="GnuMP">GnuMP</link> in <literal>/usr/local/lib</literal> (suitable for <ulink url="https://brew.sh/">Homebrew</ulink> install of <link linkend="GnuMP">GnuMP</link>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://sourceforge.net/projects/mlton/files/mlton/20180207/mlton-20180207-1.amd64-darwin.gmp-static.tgz">Darwin (.tgz)</ulink> 16.7 (Mac OS X Sierra), statically linked against <link linkend="GnuMP">GnuMP</link> (but requires <link linkend="GnuMP">GnuMP</link> for generated executables)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://sourceforge.net/projects/mlton/files/mlton/20180207/mlton-20180207-1.amd64-linux.tgz">Linux</ulink>, glibc 2.23





</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_20180207_source_packages">
<title>20180207 source packages</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://sourceforge.net/projects/mlton/files/mlton/20180207/mlton-20180207.src.tgz">mlton-20180207.src.tgz</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_36">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Bugs20180207">Bugs20180207</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/guide/20180207/">MLton Guide (20180207)</ulink>.
</simpara>
<simpara>A snapshot of the MLton website at the time of release.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ReleaseChecklist">
<title>ReleaseChecklist</title>
<section id="_advance_preparation_for_release">
<title>Advance preparation for release</title>
<itemizedlist>
<listitem>
<simpara>
Update <literal>./CHANGELOG.adoc</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Write entries for missing notable commits.
</simpara>
</listitem>
<listitem>
<simpara>
Write summary of changes from previous release.
</simpara>
</listitem>
<listitem>
<simpara>
Update with estimated release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <literal>./README.adoc</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Check features and description.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <literal>man/{mlton,mlprof}.1</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Check compile-time and run-time options in <literal>man/mlton.1</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Check options in <literal>man/mlprof.1</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Update with estimated release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <literal>doc/guide</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Synchronize <link linkend="Features">Features</link> page with <literal>./README.adoc</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Update <link linkend="Credits">Credits</link> page with acknowledgements.
</simpara>
</listitem>
<listitem>
<simpara>
Create <emphasis role="strong">ReleaseYYYYMM??</emphasis> page (i.e., forthcoming release) based on <emphasis role="strong">ReleaseXXXXLLCC</emphasis> (i.e., previous release).
</simpara>
<itemizedlist>
<listitem>
<simpara>
Update summary from <literal>./CHANGELOG.adoc</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Update links to estimated release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Create <emphasis role="strong">BugsYYYYMM??</emphasis> page based on <emphasis role="strong">BugsXXXXLLCC</emphasis>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Update links to estimated release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Spell check pages.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Ensure that all updates are pushed to <literal>master</literal> branch of <ulink url="https://github.com/MLton/mlton"><literal>mlton</literal></ulink>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_prepare_sources_for_tagging">
<title>Prepare sources for tagging</title>
<itemizedlist>
<listitem>
<simpara>
Update <literal>./CHANGELOG.adoc</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Update with proper release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <literal>man/{mlton,mlprof}.1</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Update with proper release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <literal>doc/guide</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Rename <emphasis role="strong">ReleaseYYYYMM??</emphasis> to <emphasis role="strong">ReleaseYYYYMMDD</emphasis> with proper release date.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Update links with proper release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Rename <emphasis role="strong">BugsYYYYMM??</emphasis> to <emphasis role="strong">BugsYYYYMMDD</emphasis> with proper release date.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Update links with proper release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <emphasis role="strong">ReleaseXXXXLLCC</emphasis>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Change intro to "<literal>This is an archived public release of MLton, version XXXXLLCC.</literal>"
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <link linkend="Home">Home</link> with note of new release.
</simpara>
<itemizedlist>
<listitem>
<simpara>
Change <literal>What's new?</literal> text to <literal>Please try out our new release, &lt;:ReleaseYYYYMMDD:MLton YYYYMMDD&gt;</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Update <literal>Download</literal> link with proper release date.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Update <link linkend="Releases">Releases</link> with new release.
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
Ensure that all updates are pushed to <literal>master</literal> branch of <ulink url="https://github.com/MLton/mlton"><literal>mlton</literal></ulink>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_tag_sources">
<title>Tag sources</title>
<itemizedlist>
<listitem>
<simpara>
Shell commands:
</simpara>
<screen>git clone http://github.com/MLton/mlton mlton.git
cd mlton.git
git checkout master
git tag -a -m "Tagging YYYYMMDD release" on-YYYYMMDD-release master
git push origin on-YYYYMMDD-release</screen>
</listitem>
</itemizedlist>
</section>
<section id="_packaging">
<title>Packaging</title>
<section id="_sourceforge_frs">
<title>SourceForge FRS</title>
<itemizedlist>
<listitem>
<simpara>
Create <emphasis role="strong">YYYYMMDD</emphasis> directory:
</simpara>
<screen>sftp user@frs.sourceforge.net:/home/frs/project/mlton/mlton
sftp&gt; mkdir YYYYMMDD
sftp&gt; quit</screen>
</listitem>
</itemizedlist>
</section>
<section id="_source_release">
<title>Source release</title>
<itemizedlist>
<listitem>
<simpara>
Create <literal>mlton-YYYYMMDD.src.tgz</literal>:
</simpara>
<screen>git clone http://github.com/MLton/mlton mlton
cd mlton
git checkout on-YYYYMMDD-release
make MLTON_VERSION=YYYYMMDD source-release
cd ..</screen>
<simpara>or</simpara>
<screen>wget https://github.com/MLton/mlton/archive/on-YYYYMMDD-release.tar.gz
tar xzvf on-YYYYMMDD-release.tar.gz
cd mlton-on-YYYYMMDD-release
make MLTON_VERSION=YYYYMMDD source-release
cd ..</screen>
</listitem>
<listitem>
<simpara>
Upload <literal>mlton-YYYYMMDD.src.tgz</literal>:
</simpara>
<screen>scp mlton-YYYYMMDD.src.tgz user@frs.sourceforge.net:/home/frs/project/mlton/mlton/YYYYMMDD/</screen>
</listitem>
<listitem>
<simpara>
Update <emphasis role="strong">ReleaseYYYYMMDD</emphasis> with <literal>mlton-YYYYMMDD.src.tgz</literal> link.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_binary_releases">
<title>Binary releases</title>
<itemizedlist>
<listitem>
<simpara>
Build and create <literal>mlton-YYYYMMDD-1.ARCH-OS.tgz</literal>:
</simpara>
<screen>wget http://sourceforge.net/projects/mlton/files/mlton/YYYYMMDD/mlton-YYYYMMDD.src.tgz
tar xzvf mlton-YYYYMMDD.src.tgz
cd mlton-YYYYMMDD
make binary-release
cd ..</screen>
</listitem>
<listitem>
<simpara>
Upload <literal>mlton-YYYYMMDD-1.ARCH-OS.tgz</literal>:
</simpara>
<screen>scp mlton-YYYYMMDD-1.ARCH-OS.tgz user@frs.sourceforge.net:/home/frs/project/mlton/mlton/YYYYMMDD/</screen>
</listitem>
<listitem>
<simpara>
Update <emphasis role="strong">ReleaseYYYYMMDD</emphasis> with <literal>mlton-YYYYMMDD-1.ARCH-OS.tgz</literal> link.
</simpara>
</listitem>
</itemizedlist>
</section>
</section>
<section id="_website">
<title>Website</title>
<itemizedlist>
<listitem>
<simpara>
<literal>guide/YYYYMMDD</literal> gets a copy of <literal>doc/guide/localhost</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Shell commands:
</simpara>
<screen>wget http://sourceforge.net/projects/mlton/files/mlton/YYYYMMDD/mlton-YYYYMMDD.src.tgz
tar xzvf mlton-YYYYMMDD.src.tgz
cd mlton-YYYYMMDD
cd doc/guide
cp -prf localhost YYYYMMDD
tar czvf guide-YYYYMMDD.tgz YYYYMMDD
rsync -avzP --delete -e ssh YYYYMMDD user@web.sourceforge.net:/home/project-web/mlton/htdocs/guide/
rsync -avzP --delete -e ssh guide-YYYYMMDD.tgz user@web.sourceforge.net:/home/project-web/mlton/htdocs/guide/</screen>
</listitem>
</itemizedlist>
</section>
<section id="_announce_release">
<title>Announce release</title>
<itemizedlist>
<listitem>
<simpara>
Mail announcement to:
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="mailto:MLton-user@mlton.org"><literal>MLton-user@mlton.org</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_misc">
<title>Misc.</title>
<itemizedlist>
<listitem>
<simpara>
Generate new <link linkend="Performance">Performance</link> numbers.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Releases">
<title>Releases</title>
<simpara>Public releases of MLton:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Release20180207">Release20180207</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Release20130715">Release20130715</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Release20100608">Release20100608</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Release20070826">Release20070826</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Release20051202">Release20051202</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Release20041109">Release20041109</link>
</simpara>
</listitem>
<listitem>
<simpara>
Release20040227
</simpara>
</listitem>
<listitem>
<simpara>
Release20030716
</simpara>
</listitem>
<listitem>
<simpara>
Release20030711
</simpara>
</listitem>
<listitem>
<simpara>
Release20030312
</simpara>
</listitem>
<listitem>
<simpara>
Release20020923
</simpara>
</listitem>
<listitem>
<simpara>
Release20020410
</simpara>
</listitem>
<listitem>
<simpara>
Release20011006
</simpara>
</listitem>
<listitem>
<simpara>
Release20010806
</simpara>
</listitem>
<listitem>
<simpara>
Release20010706
</simpara>
</listitem>
<listitem>
<simpara>
Release20000906
</simpara>
</listitem>
<listitem>
<simpara>
Release20000712
</simpara>
</listitem>
<listitem>
<simpara>
Release19990712
</simpara>
</listitem>
<listitem>
<simpara>
Release19990319
</simpara>
</listitem>
<listitem>
<simpara>
Release19980826
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="RemoveUnused">
<title>RemoveUnused</title>
<simpara><link linkend="RemoveUnused">RemoveUnused</link> is an optimization pass for both the <link linkend="SSA">SSA</link> and
<link linkend="SSA2">SSA2</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>s, invoked from <link linkend="SSASimplify">SSASimplify</link> and
<link linkend="SSA2Simplify">SSA2Simplify</link>.</simpara>
<section id="_description_49">
<title>Description</title>
<simpara>This pass aggressively removes unused:</simpara>
<itemizedlist>
<listitem>
<simpara>
datatypes
</simpara>
</listitem>
<listitem>
<simpara>
datatype constructors
</simpara>
</listitem>
<listitem>
<simpara>
datatype constructor arguments
</simpara>
</listitem>
<listitem>
<simpara>
functions
</simpara>
</listitem>
<listitem>
<simpara>
function arguments
</simpara>
</listitem>
<listitem>
<simpara>
function returns
</simpara>
</listitem>
<listitem>
<simpara>
blocks
</simpara>
</listitem>
<listitem>
<simpara>
block arguments
</simpara>
</listitem>
<listitem>
<simpara>
statements (variable bindings)
</simpara>
</listitem>
<listitem>
<simpara>
handlers from non-tail calls (mayRaise analysis)
</simpara>
</listitem>
<listitem>
<simpara>
continuations from non-tail calls (mayReturn analysis)
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_implementation_54">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/remove-unused.fun"><literal>remove-unused.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/remove-unused2.fun"><literal>remove-unused2.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_52">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Restore">
<title>Restore</title>
<simpara><link linkend="Restore">Restore</link> is a rewrite pass for the <link linkend="SSA">SSA</link> and <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>s, invoked from <link linkend="KnownCase">KnownCase</link> and
<link linkend="LocalRef">LocalRef</link>.</simpara>
<section id="_description_50">
<title>Description</title>
<simpara>This pass restores the SSA condition for a violating <link linkend="SSA">SSA</link> or
<link linkend="SSA2">SSA2</link> program; the program must satisfy:</simpara>
<blockquote>
<simpara>Every path from the root to a use of a variable (excluding globals)
passes through a def of that variable.</simpara>
</blockquote>
</section>
<section id="_implementation_55">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/restore.sig"><literal>restore.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/restore.fun"><literal>restore.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/restore2.sig"><literal>restore2.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/restore2.fun"><literal>restore2.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_53">
<title>Details and Notes</title>
<simpara>Based primarily on Section 19.1 of <link linkend="References_Appel98">Modern Compiler Implementation in ML</link>.</simpara>
<simpara>The main deviation is the calculation of liveness of the violating
variables, which is used to predicate the insertion of phi arguments.
This is due to the algorithm&#8217;s bias towards imperative languages, for
which it makes the assumption that all variables are defined in the
start block and all variables are "used" at exit.</simpara>
<simpara>This is "optimized" for restoration of functions with small numbers of
violating variables&#8201;&#8212;&#8201;use bool vectors to represent sets of violating
variables.</simpara>
<simpara>Also, we use a <literal>Promise.t</literal> to suspend part of the dominance frontier
computation.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ReturnStatement">
<title>ReturnStatement</title>
<simpara>Programmers coming from languages that have a <literal>return</literal> statement, such
as C, Java, and Python, often ask how one can translate functions that
return early into SML.  This page briefly describes a number of ways
to translate uses of <literal>return</literal> to SML.</simpara>
<section id="_conditional_iterator_function">
<title>Conditional iterator function</title>
<simpara>A conditional iterator function, such as
<ulink url="http://www.standardml.org/Basis/list.html#SIG:LIST.find:VAL"><literal>List.find</literal></ulink>,
<ulink url="http://www.standardml.org/Basis/list.html#SIG:LIST.exists:VAL"><literal>List.exists</literal></ulink>,
or
<ulink url="http://www.standardml.org/Basis/list.html#SIG:LIST.all:VAL"><literal>List.all</literal></ulink>
is probably what you want in most cases.  Unfortunately, it might be
the case that the particular conditional iteration pattern that you
want isn&#8217;t provided for your data structure.  Usually the best
alternative in such a case is to implement the desired iteration
pattern as a higher-order function.  For example, to implement a
<literal>find</literal> function for arrays (which already exists as
<ulink url="http://www.standardml.org/Basis/array.html#SIG:ARRAY.findi:VAL"><literal>Array.find</literal></ulink>)
one could write</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun find predicate array = let
   fun loop i =
       if i = Array.length array then
          NONE
       else if predicate (Array.sub (array, i)) then
          SOME (Array.sub (array, i))
       else
          loop (i+1)
in
   loop 0
end</programlisting>
<simpara>Of course, this technique, while probably the most common case in
practice, applies only if you are essentially iterating over some data
structure.</simpara>
</section>
<section id="_escape_handler">
<title>Escape handler</title>
<simpara>Probably the most direct way to translate code using <literal>return</literal>
statements is to basically implement <literal>return</literal> using exception
handling.  The mechanism can be packaged into a reusable module with
the signature
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/public/control/exit.sig"><literal>exit.sig</literal></ulink>):</simpara>
<programlisting language="sml" linenumbering="unnumbered">(**
 * Signature for exit (or escape) handlers.
 *
 * Note that the implementation necessarily uses exception handling.  This
 * is to make proper resource handling possible.  Exceptions raised by the
 * implementation can be caught by wildcard exception handlers.  Wildcard
 * exception handlers should generally reraise exceptions after performing
 * their effects.
 *)
signature EXIT = sig
   type 'a t
   (** The type of exits. *)

   val within : ('a t, 'a) CPS.t
   (**
    * Sets up an exit and passes it to the given function.  The function
    * may then return normally or by calling {to} with the exit and a
    * return value.  For example,
    *
    *&gt; Exit.within
    *&gt;    (fn l =&gt;
    *&gt;        if condition then
    *&gt;           Exit.to l 1
    *&gt;        else
    *&gt;           2)
    *
    * evaluates either to {1} or to {2} depending on the {condition}.
    *
    * Note that the function receiving the exit is called from a non-tail
    * position.
    *)

   val to : 'a t -&gt; 'a -&gt; 'b
   (**
    * {to l v} returns from the {within} invocation that introduced the
    * exit {l} with the value {v}.  Evaluating {to l v} outside of the
    * {within} invocation that introduced {l} is a programming error and
    * raises an exception.
    *
    * Note that the type variable {'b} only appears as the return type.
    * This means that {to} doesn't return normally to the caller and can
    * be called from a context of any type.
    *)

   val call : ('a -&gt; 'b, 'a) CPS.t
   (**
    * Simpler, but less flexibly typed, interface to {within} and {to}.
    * Specifically, {call f} is equivalent to {within (f o to)}.
    *)
end</programlisting>
<simpara>(<link linkend="References_HarperEtAl93">Typing First-Class Continuations in ML</link>
discusses the typing of a related construct.)  The implementation
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/detail/control/exit.sml"><literal>exit.sml</literal></ulink>)
is straightforward:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Exit :&gt; EXIT = struct
   type 'a t = 'a -&gt; exn

   fun within block = let
      exception EscapedExit of 'a
   in
      block EscapedExit
      handle EscapedExit value =&gt; value
   end

   fun to exit value = raise exit value

   fun call block = within (block o to)
end</programlisting>
<simpara>Here is an example of how one could implement a <literal>find</literal> function given
an <literal>app</literal> function:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun appToFind (app : ('a -&gt; unit) -&gt; 'b -&gt; unit)
              (predicate : 'a -&gt; bool)
              (data : 'b) =
    Exit.call
       (fn return =&gt;
           (app (fn x =&gt;
                    if predicate x then
                       return (SOME x)
                    else
                       ())
                data
          ; NONE))</programlisting>
<simpara>In the above, as soon as the expression <literal>predicate x</literal> evaluates to
<literal>true</literal> the <literal>app</literal> invocation is terminated.</simpara>
</section>
<section id="_continuation_passing_style_cps">
<title>Continuation-passing Style (CPS)</title>
<simpara>A general way to implement complex control patterns is to use
<ulink url="http://en.wikipedia.org/wiki/Continuation-passing_style">CPS</ulink>.  In CPS,
instead of returning normally, functions invoke a function passed as
an argument.  In general, multiple continuation functions may be
passed as arguments and the ordinary return continuation may also be
used.  As an example, here is a function that finds the leftmost
element of a binary tree satisfying a given predicate:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a tree = LEAF | BRANCH of 'a tree * 'a * 'a tree

fun find predicate = let
   fun recurse continue =
       fn LEAF =&gt;
          continue ()
        | BRANCH (lhs, elem, rhs) =&gt;
          recurse
             (fn () =&gt;
                 if predicate elem then
                    SOME elem
                 else
                    recurse continue rhs)
             lhs
in
   recurse (fn () =&gt; NONE)
end</programlisting>
<simpara>Note that the above function returns as soon as the leftmost element
satisfying the predicate is found.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RSSA">
<title>RSSA</title>
<simpara><link linkend="RSSA">RSSA</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from <link linkend="SSA2">SSA2</link> by
<link linkend="ToRSSA">ToRSSA</link>, optimized by <link linkend="RSSASimplify">RSSASimplify</link>, and translated by
<link linkend="ToMachine">ToMachine</link> to <link linkend="Machine">Machine</link>.</simpara>
<section id="_description_51">
<title>Description</title>
<simpara><link linkend="RSSA">RSSA</link> is a <link linkend="IntermediateLanguage">IntermediateLanguage</link> that makes representation
decisions explicit.</simpara>
</section>
<section id="_implementation_56">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/rssa.sig"><literal>rssa.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/rssa.fun"><literal>rssa.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_4">
<title>Type Checking</title>
<simpara>The new type language is aimed at expressing bit-level control over
layout and associated packing of data representations.  There are
singleton types that denote constants, other atomic types for things
like integers and reals, and arbitrary sum types and sequence (tuple)
types.  The big change to the type system is that type checking is now
based on subtyping, not type equality.  So, for example, the singleton
type <literal>0xFFFFEEBB</literal> whose only inhabitant is the eponymous constant is a
subtype of the type <literal>Word32</literal>.</simpara>
</section>
<section id="_details_and_notes_54">
<title>Details and Notes</title>
<simpara>SSA is an abbreviation for Static Single Assignment.  The <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> is a variant of SSA.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RSSAShrink">
<title>RSSAShrink</title>
<simpara><link linkend="RSSAShrink">RSSAShrink</link> is an optimization pass for the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_52">
<title>Description</title>
<simpara>This pass implements a whole family of compile-time reductions, like:</simpara>
<itemizedlist>
<listitem>
<simpara>
constant folding, copy propagation
</simpara>
</listitem>
<listitem>
<simpara>
inline the <literal>Goto</literal> to a block with a unique predecessor
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_implementation_57">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/rssa.fun"><literal>rssa.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_55">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RSSASimplify">
<title>RSSASimplify</title>
<simpara>The optimization passes for the <link linkend="RSSA">RSSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> are
collected and controlled by the <literal>Backend</literal> functor
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/backend.sig"><literal>backend.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/backend.fun"><literal>backend.fun</literal></ulink>).</simpara>
<simpara>The following optimization pass is implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RSSAShrink">RSSAShrink</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The following implementation passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ImplementHandlers">ImplementHandlers</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ImplementProfiling">ImplementProfiling</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="InsertLimitChecks">InsertLimitChecks</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="InsertSignalChecks">InsertSignalChecks</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The optimization passes can be controlled from the command-line by the options</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-diag-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep diagnostic info for pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-drop-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;omit optimization pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-keep-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep the results of pass
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="RunningOnAIX">
<title>RunningOnAIX</title>
<simpara>MLton runs fine on AIX.</simpara>
<section id="_also_see_37">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC">RunningOnPowerPC</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC64">RunningOnPowerPC64</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnAlpha">
<title>RunningOnAlpha</title>
<simpara>MLton runs fine on the Alpha architecture.</simpara>
<section id="_notes_4">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for Alpha, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for Alpha, MLton uses <literal>-align 8</literal> by default.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnAMD64">
<title>RunningOnAMD64</title>
<simpara>MLton runs fine on the AMD64 (aka "x86-64" or "x64") architecture.</simpara>
<section id="_notes_5">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for AMD64, MLton targets the 64-bit ABI.
</simpara>
</listitem>
<listitem>
<simpara>
On AMD64, MLton supports native code generation (<literal>-codegen native</literal> or <literal>-codegen amd64</literal>).
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for AMD64, MLton uses <literal>-align 8</literal> by default.  Using
<literal>-align 4</literal> may be incompatible with optimized builds of the <link linkend="GnuMP">GnuMP</link>
library, which assume 8-byte alignment.  (See the thread at
<ulink url="http://www.mlton.org/pipermail/mlton/2009-October/030674.html">http://www.mlton.org/pipermail/mlton/2009-October/030674.html</ulink> for more
details.)
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnARM">
<title>RunningOnARM</title>
<simpara>MLton runs fine on the ARM architecture.</simpara>
<section id="_notes_6">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for ARM, MLton doesn&#8217;t support native code generation
(<literal>-codegen native</literal>).  Hence, performance is not as good as it might be
and compile times are longer.  Also, the quality of code generated by
<literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.  You can
change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnCygwin">
<title>RunningOnCygwin</title>
<simpara>MLton runs on the <ulink url="http://www.cygwin.com/">Cygwin</ulink> emulation layer,
which provides a Posix-like environment while running on Windows.  To
run MLton with Cygwin, you must first install Cygwin on your Windows
machine.  To do this, visit the Cygwin site from your Windows machine
and run their <literal>setup.exe</literal> script.  Then, you can unpack the MLton
binary <literal>tgz</literal> in your Cygwin environment.</simpara>
<simpara>To run MLton cross-compiled executables on Windows, you must install
the Cygwin <literal>dll</literal> on the Windows machine.</simpara>
<section id="_known_issues_2">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
Time profiling is disabled.
</simpara>
</listitem>
<listitem>
<simpara>
Cygwin&#8217;s <literal>mmap</literal> emulation is less than perfect.  Sometimes it
interacts badly with <literal>Posix.Process.fork</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
The <ulink url="https://raw.github.com/MLton/mlton/master/regression/socket.sml"><literal>socket.sml</literal></ulink> regression
test fails.  We suspect this is not a bug and is simply due to our
test relying on a certain behavior when connecting to a socket that
has not yet accepted, which is handled differently on Cygwin than
other platforms.  Any help in understanding and resolving this issue
is appreciated.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_38">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnMinGW">RunningOnMinGW</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnDarwin">
<title>RunningOnDarwin</title>
<simpara>MLton runs fine on Darwin (and on Mac OS X).</simpara>
<section id="_notes_7">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
MLton requires the <link linkend="GnuMP">GnuMP</link> library, which is available via
<ulink url="http://www.finkproject.org">Fink</ulink>, <ulink url="http://www.macports.com">MacPorts</ulink>,
<ulink url="http://mxcl.github.io/homebrew/">Homebrew</ulink>.
</simpara>
</listitem>
<listitem>
<simpara>
For Intel-based Macs, MLton targets the <link linkend="RunningOnAMD64">AMD64 architecture</link> on Darwin 10 (Mac OS X Snow Leopard) and higher and
targets the <link linkend="RunningOnX86">x86 architecture</link> on Darwin 8 (Mac OS X
Tiger) and Darwin 9 (Mac OS X Leopard).
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_known_issues_3">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
Executables that save and load worlds on Darwin 11 (Mac OS X Lion)
and higher should be compiled with <literal>-link-opt -fno-PIE</literal> ; see
<link linkend="MLtonWorld">MLtonWorld</link> for more details.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ProfilingTime">ProfilingTime</link> may give inaccurate results on multi-processor
machines.  The <literal>SIGPROF</literal> signal, used to sample the profiled program,
is supposed to be delivered 100 times a second (i.e., at 10000us
intervals), but there can be delays of over 1 minute between the
delivery of consecutive <literal>SIGPROF</literal> signals.  A more complete
description may be found
<ulink url="http://lists.apple.com/archives/Unix-porting/2007/Aug/msg00000.html">here</ulink>
and
<ulink url="http://lists.apple.com/archives/Darwin-dev/2007/Aug/msg00045.html">here</ulink>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_39">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAMD64">RunningOnAMD64</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnPowerPC">RunningOnPowerPC</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnX86">RunningOnX86</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnFreeBSD">
<title>RunningOnFreeBSD</title>
<simpara>MLton runs fine on <ulink url="http://www.freebsd.org/">FreeBSD</ulink>.</simpara>
<section id="_notes_8">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
MLton is available as a <ulink url="http://www.freebsd.org/">FreeBSD</ulink>
<ulink url="http://www.freebsd.org/cgi/ports.cgi?query=mlton&amp;stype=all">port</ulink>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_known_issues_4">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
Executables often run more slowly than on a comparable Linux
machine.  We conjecture that part of this is due to costs due to heap
resizing and kernel zeroing of pages.  Any help in solving the problem
would be appreciated.
</simpara>
</listitem>
<listitem>
<simpara>
FreeBSD defaults to a datasize limit of 512M, even if you have more
than that amount of memory in the computer. Hence, your MLton process
will be limited in the amount of memory it has. To fix this problem,
turn up the datasize and the default datasize available to a process:
Edit <literal>/boot/loader.conf</literal> to set the limits. For example, the setting
</simpara>
<screen>   kern.maxdsiz="671088640"
   kern.dfldsiz="671088640"
   kern.maxssiz="134217728"</screen>
<simpara>will give a process 640M of datasize memory, default to 640M available
and set 128M of stack size memory.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnHPPA">
<title>RunningOnHPPA</title>
<simpara>MLton runs fine on the HPPA architecture.</simpara>
<section id="_notes_9">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for HPPA, MLton targets the 32-bit HPPA architecture.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for HPPA, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for HPPA, MLton uses <literal>-align 8</literal> by default.  While
this speeds up reals, it also may increase object sizes.  If your
program does not make significant use of reals, you might see a
speedup with <literal>-align 4</literal>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnHPUX">
<title>RunningOnHPUX</title>
<simpara>MLton runs fine on HPUX.</simpara>
<section id="_also_see_40">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnHPPA">RunningOnHPPA</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnIA64">
<title>RunningOnIA64</title>
<simpara>MLton runs fine on the IA64 architecture.</simpara>
<section id="_notes_10">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for IA64, MLton targets the 64-bit ABI.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for IA64, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for IA64, MLton uses <literal>-align 8</literal> by default.
</simpara>
</listitem>
<listitem>
<simpara>
On the IA64, the <link linkend="GnuMP">GnuMP</link> library supports multiple ABIs.  See the
<link linkend="GnuMP">GnuMP</link> page for more details.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnLinux">
<title>RunningOnLinux</title>
<simpara>MLton runs fine on Linux.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="RunningOnMinGW">
<title>RunningOnMinGW</title>
<simpara>MLton runs on <ulink url="http://mingw.org">MinGW</ulink>, a library for porting Unix
applications to Windows.  Some library functionality is missing or
changed.</simpara>
<section id="_notes_11">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
To compile MLton on MinGW:
</simpara>
<itemizedlist>
<listitem>
<simpara>
The <link linkend="GnuMP">GnuMP</link> library is required.
</simpara>
</listitem>
<listitem>
<simpara>
The Bash shell is required.  If you are using a prebuilt MSYS, you
probably want to symlink <literal>bash</literal> to <literal>sh</literal>.
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section id="_known_issues_5">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
Many functions are unimplemented and will <literal>raise SysErr</literal>.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>MLton.Itimer.set</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.ProcEnv.setgroups</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Process.kill</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.Process.reap</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>MLton.World.load</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>OS.FileSys.readLink</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>OS.IO.poll</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>OS.Process.terminate</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.chown</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.fchown</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.fpathconf</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.link</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.mkfifo</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.pathconf</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.readlink</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.FileSys.symlink</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.dupfd</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.getfd</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.getfl</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.getlk</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.setfd</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.setfl</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.setlkw</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.IO.setlk</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.ctermid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getegid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.geteuid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getgid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getgroups</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getlogin</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getpgrp</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getpid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getppid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.getuid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.setgid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.setpgid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.setsid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.setuid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.sysconf</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.times</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.ProcEnv.ttyname</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.exece</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.execp</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.exit</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.fork</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.kill</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.pause</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.waitpid_nh</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.Process.waitpid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.SysDB.getgrgid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.SysDB.getgrnam</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.SysDB.getpwuid</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.drain</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.flow</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.flush</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.getattr</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.getpgrp</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.sendbreak</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.setattr</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Posix.TTY.TC.setpgrp</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Unix.kill</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Unix.reap</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>UnixSock.fromAddr</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>UnixSock.toAddr</literal>
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnNetBSD">
<title>RunningOnNetBSD</title>
<simpara>MLton runs fine on <ulink url="http://www.netbsd.org/">NetBSD</ulink>.</simpara>
<section id="_installing_the_correct_packages_for_netbsd">
<title>Installing the correct packages for NetBSD</title>
<simpara>The NetBSD system installs 3rd party packages by a mechanism known as
pkgsrc. This is a tree of Makefiles which when invoked downloads the
source code, builds a package and installs it on the system. In order
to run MLton on NetBSD, you will have to install several packages for
it to work:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>shells/bash</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>devel/gmp</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>devel/gmake</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>In order to get graphical call-graphs of profiling information, you
will need the additional package</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>graphics/graphviz</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>To build the documentation for MLton, you will need the addtional
package</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>textproc/asciidoc</literal>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_tips_for_compiling_and_using_mlton_on_netbsd">
<title>Tips for compiling and using MLton on NetBSD</title>
<simpara>MLton can be a memory-hog on computers with little memory.  While
640Mb of RAM ought to be enough to self-compile MLton one might want
to do some tuning to the NetBSD VM subsystem in order to succeed.  The
notes presented here is what <link linkend="JesperLouisAndersen">JesperLouisAndersen</link> uses for
compiling MLton on his laptop.</simpara>
<section id="_the_netbsd_vm_subsystem">
<title>The NetBSD VM subsystem</title>
<simpara>NetBSD uses a VM subsystem named
<ulink url="http://www.ccrc.wustl.edu/pub/chuck/tech/uvm/">UVM</ulink>.
<ulink url="http://www.selonen.org/arto/netbsd/vm_tune.html">Tuning the VM system</ulink>
can be done via the <literal>sysctl(8)</literal>-interface with the "VM" MIB set.</simpara>
</section>
<section id="_tuning_the_netbsd_vm_subsystem_for_mlton">
<title>Tuning the NetBSD VM subsystem for MLton</title>
<simpara>MLton uses a lot of anonymous pages when it is running. Thus, we will
need to tune up the default of 80 for anonymous pages.  Setting</simpara>
<screen>sysctl -w vm.anonmax=95
sysctl -w vm.anonmin=50
sysctl -w vm.filemin=2
sysctl -w vm.execmin=2
sysctl -w vm.filemax=4
sysctl -w vm.execmax=4</screen>
<simpara>makes it less likely for the VM system to swap out anonymous pages.
For a full explanation of the above flags, see the documentation.</simpara>
<simpara>The result is that my laptop goes from a MLton compile where it swaps
a lot to a MLton compile with no swapping.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="RunningOnOpenBSD">
<title>RunningOnOpenBSD</title>
<simpara>MLton runs fine on <ulink url="http://www.openbsd.org/">OpenBSD</ulink>.</simpara>
<section id="_known_issues_6">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
The <ulink url="https://raw.github.com/MLton/mlton/master/regression/socket.sml"><literal>socket.sml</literal></ulink> regression
test fails.  We suspect this is not a bug and is simply due to our
test relying on a certain behavior when connecting to a socket that
has not yet accepted, which is handled differently on OpenBSD than
other platforms.  Any help in understanding and resolving this issue
is appreciated.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnPowerPC">
<title>RunningOnPowerPC</title>
<simpara>MLton runs fine on the PowerPC architecture.</simpara>
<section id="_notes_12">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for PowerPC, MLton targets the 32-bit PowerPC
architecture.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for PowerPC, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
On the PowerPC, the <link linkend="GnuMP">GnuMP</link> library supports multiple ABIs.  See
the <link linkend="GnuMP">GnuMP</link> page for more details.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnPowerPC64">
<title>RunningOnPowerPC64</title>
<simpara>MLton runs fine on the PowerPC64 architecture.</simpara>
<section id="_notes_13">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for PowerPC64, MLton targets the 64-bit PowerPC
architecture.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for PowerPC64, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
On the PowerPC64, the <link linkend="GnuMP">GnuMP</link> library supports multiple ABIs.  See
the <link linkend="GnuMP">GnuMP</link> page for more details.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnS390">
<title>RunningOnS390</title>
<simpara>MLton runs fine on the S390 architecture.</simpara>
<section id="_notes_14">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for S390, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnSolaris">
<title>RunningOnSolaris</title>
<simpara>MLton runs fine on Solaris.</simpara>
<section id="_notes_15">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
You must install the <literal>binutils</literal>, <literal>gcc</literal>, and <literal>make</literal> packages.  You
can find out how to get these at
<ulink url="http://www.sunfreeware.com">sunfreeware.com</ulink>.
</simpara>
</listitem>
<listitem>
<simpara>
Making the documentation requires that you install <literal>latex</literal> and
<literal>dvips</literal>, which are available in the <literal>tetex</literal> package.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_known_issues_7">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
Bootstrapping on the <link linkend="RunningOnSparc">Sparc architecture</link> is so slow
as to be impractical (many hours on a 500MHz UltraSparc).  For this
reason, we strongly recommend building with a
<link linkend="CrossCompiling">cross compiler</link>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_41">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnAMD64">RunningOnAMD64</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnSparc">RunningOnSparc</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RunningOnX86">RunningOnX86</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnSparc">
<title>RunningOnSparc</title>
<simpara>MLton runs fine on the Sparc architecture.</simpara>
<section id="_notes_16">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
When compiling for Sparc, MLton targets the 32-bit Sparc
architecture (i.e., Sparc V8).
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for Sparc, MLton doesn&#8217;t support native code
generation (<literal>-codegen native</literal>).  Hence, performance is not as good as
it might be and compile times are longer.  Also, the quality of code
generated by <literal>gcc</literal> is important.  By default, MLton calls <literal>gcc -O1</literal>.
You can change this by calling MLton with <literal>-cc-opt -O2</literal>.  We have seen
this speed up some programs by as much as 30%, especially those
involving floating point; however, it can also more than double
compile times.
</simpara>
</listitem>
<listitem>
<simpara>
When compiling for Sparc, MLton uses <literal>-align 8</literal> by default.  While
this speeds up reals, it also may increase object sizes.  If your
program does not make significant use of reals, you might see a
speedup with <literal>-align 4</literal>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_known_issues_8">
<title>Known issues</title>
<itemizedlist>
<listitem>
<simpara>
Bootstrapping on the <link linkend="RunningOnSparc">Sparc architecture</link> is so slow
as to be impractical (many hours on a 500MHz UltraSparc).  For this
reason, we strongly recommend building with a
<link linkend="CrossCompiling">cross compiler</link>.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_42">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="RunningOnSolaris">RunningOnSolaris</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunningOnX86">
<title>RunningOnX86</title>
<simpara>MLton runs fine on the x86 architecture.</simpara>
<section id="_notes_17">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
On x86, MLton supports native code generation (<literal>-codegen native</literal> or
<literal>-codegen x86</literal>).
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="RunTimeOptions">
<title>RunTimeOptions</title>
<simpara>Executables produced by MLton take command line arguments that control
the runtime system.  These arguments are optional, and occur before
the executable&#8217;s usual arguments.  To use these options, the first
argument to the executable must be <literal>@MLton</literal>.  The optional arguments
then follow, must be terminated by <literal>--</literal>, and are followed by any
arguments to the program.  The optional arguments are <emphasis>not</emphasis> made
available to the SML program via <literal>CommandLine.arguments</literal>.  For
example, a valid call to <literal>hello-world</literal> is:</simpara>
<screen>hello-world @MLton gc-summary fixed-heap 10k -- a b c</screen>
<simpara>In the above example,
<literal>CommandLine.arguments () = ["a", "b", "c"]</literal>.</simpara>
<simpara>It is allowed to have a sequence of <literal>@MLton</literal> arguments, as in:</simpara>
<screen>hello-world @MLton gc-summary -- @MLton fixed-heap 10k -- a b c</screen>
<simpara>Run-time options can also control MLton, as in</simpara>
<screen>mlton @MLton fixed-heap 0.5g -- foo.sml</screen>
<section id="_options_2">
<title>Options</title>
<itemizedlist>
<listitem>
<simpara>
<literal>fixed-heap <emphasis>x</emphasis>{k|K|m|M|g|G}</literal>
</simpara>
<simpara>Use a fixed size heap of size <emphasis>x</emphasis>, where <emphasis>x</emphasis> is a real number and the
trailing letter indicates its units.</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="center" valign="top"><simpara><literal>k</literal> or <literal>K</literal></simpara></entry>
<entry align="left" valign="top"><simpara>1024</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>m</literal> or <literal>M</literal></simpara></entry>
<entry align="left" valign="top"><simpara>1,048,576</simpara></entry>
</row>
<row>
<entry align="center" valign="top"><simpara><literal>g</literal> or <literal>G</literal></simpara></entry>
<entry align="left" valign="top"><simpara>1,073,741,824</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>A value of <literal>0</literal> means to use almost all the RAM present on the machine.</simpara>
<simpara>The heap size used by <literal>fixed-heap</literal> includes all memory allocated by
SML code, including memory for the stack (or stacks, if there are
multiple threads).  It does not, however, include any memory used for
code itself or memory used by C globals, the C stack, or malloc.</simpara>
</listitem>
<listitem>
<simpara>
<literal>gc-messages</literal>
</simpara>
<simpara>Print a message at the start and end of every garbage collection.</simpara>
</listitem>
<listitem>
<simpara>
<literal>gc-summary</literal>
</simpara>
<simpara>Print a summary of garbage collection statistics upon program
termination to standard error.</simpara>
</listitem>
<listitem>
<simpara>
<literal>gc-summary-file <emphasis>file</emphasis></literal>
</simpara>
<simpara>Print a summary of garbage collection statistics upon program
termination to the file specified by <emphasis>file</emphasis>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>load-world <emphasis>world</emphasis></literal>
</simpara>
<simpara>Restart the computation with the file specified by <emphasis>world</emphasis>, which must
have been created by a call to <literal>MLton.World.save</literal> by the same
executable.  See <link linkend="MLtonWorld">MLtonWorld</link>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>max-heap <emphasis>x</emphasis>{k|K|m|M|g|G}</literal>
</simpara>
<simpara>Run the computation with an automatically resized heap that is never
larger than <emphasis>x</emphasis>, where <emphasis>x</emphasis> is a real number and the trailing letter
indicates the units as with <literal>fixed-heap</literal>.  The heap size for
<literal>max-heap</literal> is accounted for as with <literal>fixed-heap</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>may-page-heap {false|true}</literal>
</simpara>
<simpara>Enable paging the heap to disk when unable to grow the heap to a
desired size.</simpara>
</listitem>
<listitem>
<simpara>
<literal>no-load-world</literal>
</simpara>
<simpara>Disable <literal>load-world</literal>.  This can be used as an argument to the compiler
via <literal>-runtime no-load-world</literal> to create executables that will not load
a world.  This may be useful to ensure that set-uid executables do not
load some strange world.</simpara>
</listitem>
<listitem>
<simpara>
<literal>ram-slop <emphasis>x</emphasis></literal>
</simpara>
<simpara>Multiply <emphasis>x</emphasis> by the amount of RAM on the machine to obtain what the
runtime views as the amount of RAM it can use.  Typically <emphasis>x</emphasis> is less
than 1, and is used to account for space used by other programs
running on the same machine.</simpara>
</listitem>
<listitem>
<simpara>
<literal>stop</literal>
</simpara>
<simpara>Causes the runtime to stop processing <literal>@MLton</literal> arguments once the next
<literal>--</literal> is reached.  This can be used as an argument to the compiler via
<literal>-runtime stop</literal> to create executables that don&#8217;t process any <literal>@MLton</literal>
arguments.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ScopeInference">
<title>ScopeInference</title>
<simpara>Scope inference is an analysis/rewrite pass for the <link linkend="AST">AST</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="Elaborate">Elaborate</link>.</simpara>
<section id="_description_53">
<title>Description</title>
<simpara>This pass adds free type variables to the <literal>val</literal> or <literal>fun</literal>
declaration where they are implicitly scoped.</simpara>
</section>
<section id="_implementation_58">
<title>Implementation</title>
<simpara><ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/scope.sig"><literal>scope.sig</literal></ulink>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/elaborate/scope.fun"><literal>scope.fun</literal></ulink></simpara>
</section>
<section id="_details_and_notes_56">
<title>Details and Notes</title>
<simpara>Scope inference determines for each type variable, the declaration
where it is bound.  Scope inference is a direct implementation of the
specification given in section 4.6 of the
<link linkend="DefinitionOfStandardML">Definition</link>.  Recall that a free occurrence
of a type variable <literal>'a</literal> in a declaration <literal>d</literal> is <emphasis>unguarded</emphasis>
in <literal>d</literal> if <literal>'a</literal> is not part of a smaller declaration.  A type
variable <literal>'a</literal> is implicitly scoped at <literal>d</literal> if <literal>'a</literal> is
unguarded in <literal>d</literal> and <literal>'a</literal> does not occur unguarded in any
declaration containing <literal>d</literal>.</simpara>
<simpara>The first pass of scope inference walks down the tree and renames all
explicitly bound type variables in order to avoid name collisions.  It
then walks up the tree and adds to each declaration the set of
unguarded type variables occurring in that declaration.  At this
point, if declaration <literal>d</literal> contains an unguarded type variable
<literal>'a</literal> and the immediately containing declaration does not contain
<literal>'a</literal>, then <literal>'a</literal> is implicitly scoped at <literal>d</literal>.  The final
pass walks down the tree leaving a <literal>'a</literal> at the a declaration where
it is scoped and removing it from all enclosed declarations.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SelfCompiling">
<title>SelfCompiling</title>
<simpara>If you want to compile MLton, you must first get the <link linkend="Sources">Sources</link>. You
can compile with either MLton or SML/NJ, but we strongly recommend
using MLton, since it generates a much faster and more robust
executable.</simpara>
<section id="_compiling_with_mlton">
<title>Compiling with MLton</title>
<simpara>To compile with MLton, you need the binary versions of <literal>mlton</literal>,
<literal>mllex</literal>, and <literal>mlyacc</literal> that come with the MLton binary package.  To be
safe, you should use the same version of MLton that you are building.
However, older versions may work, as long as they don&#8217;t go back too
far.  To build MLton, run <literal>make</literal> from within the root directory of the
sources.  This will build MLton first with the already installed
binary version of MLton and will then rebuild MLton with itself.</simpara>
<simpara>First, the <literal>Makefile</literal> calls <literal>mllex</literal> and <literal>mlyacc</literal> to build the lexer
and parser, and then calls <literal>mlton</literal> to compile itself.  When making
MLton using another version the <literal>Makefile</literal> automatically uses
<literal>mlton-stubs.mlb</literal>, which will put in enough stubs to emulate the
<literal>structure MLton</literal>.  Once MLton is built, the <literal>Makefile</literal> will rebuild
MLton with itself, this time using <literal>mlton.mlb</literal> and the real
<literal>structure MLton</literal> from the <link linkend="BasisLibrary">Basis Library</link>.  This second round
of compilation is essential in order to achieve a fast and robust
MLton.</simpara>
<simpara>Compiling MLton requires at least 1GB of RAM for 32-bit platforms (2GB is
preferable) and at least 2GB RAM for 64-bit platforms (4GB is preferable).
If your machine has less RAM, self-compilation will
likely fail, or at least take a very long time due to paging.  Even if
you have enough memory, there simply may not be enough available, due
to memory consumed by other processes.  In this case, you may see an
<literal>Out of memory</literal> message, or self-compilation may become extremely
slow.  The only fix is to make sure that enough memory is available.</simpara>
<section id="_possible_errors">
<title>Possible Errors</title>
<itemizedlist>
<listitem>
<simpara>
The C compiler may not be able to find the <link linkend="GnuMP">GnuMP</link> header file,
<literal>gmp.h</literal> leading to an error like the following.
</simpara>
<screen>  cenv.h:49:18: fatal error: gmp.h: No such file or directory</screen>
<simpara>The solution is to install (or build) GnuMP on your machine.  If you
install it at a location not on the default seach path, then run
<literal>make WITH_GMP_INC_DIR=<emphasis>/path/to/gmp/include</emphasis> WITH_GMP_LIB_DIR=<emphasis>/path/to/gmp/lib</emphasis></literal>.</simpara>
</listitem>
<listitem>
<simpara>
The following errors indicates that a binary version of MLton could
not be found in your path.
</simpara>
<screen>/bin/sh: mlton: command not found</screen>
<screen>make[2]: mlton: Command not found</screen>
<simpara>You need to have <literal>mlton</literal> in your path to build MLton from source.</simpara>
<simpara>During the build process, there are various times that the <literal>Makefile</literal>-s
look for a <literal>mlton</literal> in your path and in <literal>src/build/bin</literal>.  It is OK if
the latter doesn&#8217;t exist when the build starts; it is the target being
built.  Failure to find a <literal>mlton</literal> in your path will abort the build.</simpara>
</listitem>
</itemizedlist>
</section>
</section>
<section id="_compiling_with_sml_nj">
<title>Compiling with SML/NJ</title>
<simpara>To compile with SML/NJ, run <literal>make bootstrap-smlnj</literal> from within the
root directory of the sources.  You must use a recent version of
SML/NJ.  First, the <literal>Makefile</literal> calls <literal>ml-lex</literal> and <literal>ml-yacc</literal> to build
the lexer and parser.  Then, it calls SML/NJ with the appropriate
<literal>sources.cm</literal> file.  Once MLton is built with SML/NJ, the <literal>Makefile</literal>
will rebuild MLton with this SML/NJ built MLton and then will rebuild
MLton with the MLton built MLton.  Building with SML/NJ takes
significant time (particularly during the "<literal>parseAndElaborate</literal>" phase
when the SML/NJ built MLton is compiling MLton).  Unless you are doing
compiler development and need rapid recompilation, we recommend
compiling with MLton.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Serialization">
<title>Serialization</title>
<simpara><link linkend="StandardML">Standard ML</link> does not have built-in support for
serialization.  Here are papers that describe user-level approaches:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Elsman04">Elsman04</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Kennedy04">Kennedy04</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The MLton repository also contains an experimental generic programming
library (see
<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/generic/unstable/README"><literal>README</literal></ulink>) that
includes a pickling (serialization) generic (see
<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/generic/unstable/public/value/pickle.sig"><literal>pickle.sig</literal></ulink>).</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ShareZeroVec">
<title>ShareZeroVec</title>
<simpara><link linkend="ShareZeroVec">ShareZeroVec</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_54">
<title>Description</title>
<simpara>An SSA optimization to share zero-length vectors.</simpara>
<simpara>From <ulink url="https://github.com/MLton/mlton/commit/be8c5f576"><literal>be8c5f576</literal></ulink>, which replaced the use of the
<literal>Array_array0Const</literal> primitive in the Basis Library implementation with a
(nullary) <literal>Vector_vector</literal> primitive:</simpara>
<blockquote>
<simpara>The original motivation for the <literal>Array_array0Const</literal> primitive was to share the
heap space required for zero-length vectors among all vectors (of a given type).
It was claimed that this optimization is important, e.g., in a self-compile,
where vectors are used for lots of syntax tree elements and many of those
vectors are empty. See:
<ulink url="http://www.mlton.org/pipermail/mlton-devel/2002-February/021523.html">http://www.mlton.org/pipermail/mlton-devel/2002-February/021523.html</ulink></simpara>
<simpara>Curiously, the full effect of this optimization has been missing for quite some
time (perhaps since the port of <link linkend="ConstantPropagation">ConstantPropagation</link> to the SSA IL).  While
<link linkend="ConstantPropagation">ConstantPropagation</link> has "globalized" the nullary application of the
<literal>Array_array0Const</literal> primitive, it also simultaneously transformed it to an
application of the <literal>Array_uninit</literal> (previously, the <literal>Array_array</literal>) primitive to
the zero constant.  The hash-consing of globals, meant to create exactly one
global for each distinct constant, treats <literal>Array_uninit</literal> primitives as unequal
(appropriately, since <literal>Array_uninit</literal> allocates an array with identity (though
the identity may be supressed by a subsequent <literal>Array_toVector</literal>)), hence each
distinct <literal>Array_array0Const</literal> primitive in the program remained as distinct
globals.  The limited amount of inlining prior to <link linkend="ConstantPropagation">ConstantPropagation</link> meant
that there were typically fewer than a dozen "copies" of the same empty vector
in a program for a given type.</simpara>
<simpara>As a "functional" primitive, a nullary <literal>Vector_vector</literal> is globalized by
ClosureConvert, but is further recognized by ConstantPropagation and hash-consed
into a unique instance for each type.</simpara>
</blockquote>
<simpara>However, a single, shared, global <literal>Vector_vector ()</literal> inhibits the
coercion-based optimizations of <literal>Useless</literal>.  For example, consider the
following program:</simpara>
<programlisting language="sml" linenumbering="unnumbered">    val n = valOf (Int.fromString (hd (CommandLine.arguments ())))

    val v1 = Vector.tabulate (n, fn i =&gt;
                              let val w = Word16.fromInt i
                              in (w - 0wx1, w, w + 0wx1 + w)
                              end)
    val v2 = Vector.map (fn (w1, w2, w3) =&gt; (w1, 0wx2 * w2, 0wx3 * w3)) v1
    val v3 = VectorSlice.vector (VectorSlice.slice (v1, 1, SOME (n - 2)))
    val ans1 = Vector.foldl (fn ((w1,w2,w3),w) =&gt; w + w1 + w2 + w3) 0wx0 v1
    val ans2 = Vector.foldl (fn ((_,w2,_),w) =&gt; w + w2) 0wx0 v2
    val ans3 = Vector.foldl (fn ((_,w2,_),w) =&gt; w + w2) 0wx0 v3

    val _ = print (concat ["ans1 = ", Word16.toString ans1, "  ",
                           "ans2 = ", Word16.toString ans2, "  ",
                           "ans3 = ", Word16.toString ans3, "\n"])</programlisting>
<simpara>We would like <literal>v2</literal> and <literal>v3</literal> to be optimized from
<literal>(word16 * word16 * word16) vector</literal> to <literal>word16 vector</literal> because only
the 2nd component of the elements is needed to compute the answer.</simpara>
<simpara>With <literal>Array_array0Const</literal>, each distinct occurrence of
<literal>Array_array0Const((word16 * word16 * word16))</literal> arising from
polyvariance and inlining remained a distinct
<literal>Array_uninit((word16 * word16 * word16)) (0x0)</literal> global, which
resulted in distinct occurrences for the
<literal>val v1 = Vector.tabulate ...</literal> and for the
<literal>val v2 = Vector.map ...</literal>. The latter could be optimized to
<literal>Array_uninit(word16) (0x0)</literal> by <literal>Useless</literal>, because its result only
flows to places requiring the 2nd component of the elements.</simpara>
<simpara>With <literal>Vector_vector ()</literal>, the distinct occurrences of
<literal>Vector_vector((word16 * word16 * word16)) ()</literal> arising from
polyvariance are globalized during <literal>ClosureConvert</literal>, those global
references may be further duplicated by inlining, but the distinct
occurrences of <literal>Vector_vector((word16 * word16 * word16)) ()</literal> are
merged to a single occurrence.  Because this result flows to places
requiring all three components of the elements, it remains
<literal>Vector_vector((word16 * word16 * word16)) ()</literal> after
<literal>Useless</literal>. Furthermore, because one cannot (in constant time) coerce a
<literal>(word16 * word16 * word16) vector</literal> to a <literal>word16 vector</literal>, the <literal>v2</literal>
value remains of type <literal>(word16 * word16 * word16) vector</literal>.</simpara>
<simpara>One option would be to drop the 0-element vector "optimization"
entirely.  This costs some space (no sharing of empty vectors) and
some time (allocation and garbage collection of empty vectors).</simpara>
<simpara>Another option would be to reinstate the <literal>Array_array0Const</literal> primitive
and associated <literal>ConstantPropagation</literal> treatment.  But, the semantics
and purpose of <literal>Array_array0Const</literal> was poorly understood, resulting in
this break.</simpara>
<simpara>The <link linkend="ShareZeroVec">ShareZeroVec</link> pass pursues a different approach: perform the 0-element
vector "optimization" as a separate optimization, after
<literal>ConstantPropagation</literal> and <literal>Useless</literal>.  A trivial static analysis is
used to match <literal>val v: t vector = Array_toVector(t) (a)</literal> with
corresponding <literal>val a: array = Array_uninit(t) (l)</literal> and the later are
expanded to
<literal>val a: t array = if 0 = l then zeroArr_[t] else Array_uninit(t) (l)</literal>
with a single global <literal>val zeroArr_[t] = Array_uninit(t) (0)</literal> created
for each distinct type (after coercion-based optimizations).</simpara>
<simpara>One disadvantage of this approach, compared to the <literal>Vector_vector(t) ()</literal>
approach, is that <literal>Array_toVector</literal> is applied each time a vector
is created, even if it is being applied to the <literal>zeroArr_[t]</literal>
zero-length array.  (Although, this was the behavior of the
<literal>Array_array0Const</literal> approach.)  This updates the object header each
time, whereas the <literal>Vector_vector(t) ()</literal> approach would have updated
the object header once, when the global was created, and the
<literal>zeroVec_[t]</literal> global and the <literal>Array_toVector</literal> result would flow to the
join point.</simpara>
<simpara>It would be possible to properly share zero-length vectors, but doing
so is a more sophisticated analysis and transformation, because there
can be arbitrary code between the
<literal>val a: t array = Array_uninit(t) (l)</literal> and the corresponding
<literal>val v: v vector = Array_toVector(t) (a)</literal>, although, in practice,
nothing happens when a zero-length vector is created.  It may be best
to pursue a more general "array to vector" optimization that
transforms creations of static-length vectors (e.g., all the
<literal>Vector.new&lt;N&gt;</literal> functions) into <literal>Vector_vector</literal> primitives (some of
which could be globalized).</simpara>
</section>
<section id="_implementation_59">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/share-zero-vec.fun"><literal>share-zero-vec.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_57">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ShowBasis">
<title>ShowBasis</title>
<simpara>MLton has a flag, <literal>-show-basis &lt;file&gt;</literal>, that causes MLton to pretty
print to <emphasis>file</emphasis> the basis defined by the input program.  For example,
if <literal>foo.sml</literal> contains</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f x = x + 1</programlisting>
<simpara>then <literal>mlton -show-basis foo.basis foo.sml</literal> will create <literal>foo.basis</literal>
with the following contents.</simpara>
<screen>val f: int -&gt; int</screen>
<simpara>If you only want to see the basis and do not wish to compile the
program, you can call MLton with <literal>-stop tc</literal>.</simpara>
<section id="_displaying_signatures">
<title>Displaying signatures</title>
<simpara>When displaying signatures, MLton prefixes types defined in the
signature them with <literal>_sig.</literal> to distinguish them from types defined in the
environment.  For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature SIG =
   sig
      type t
      val x: t * int -&gt; unit
   end</programlisting>
<simpara>is displayed as</simpara>
<screen>signature SIG =
   sig
      type t
      val x: _sig.t * int -&gt; unit
   end</screen>
<simpara>Notice that <literal>int</literal> occurs without the <literal>_sig.</literal> prefix.</simpara>
<simpara>MLton also uses a canonical name for each type in the signature, and
that name is used everywhere for that type, no matter what the input
signature looked like.  For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature SIG =
   sig
      type t
      type u = t
      val x: t
      val y: u
   end</programlisting>
<simpara>is displayed as</simpara>
<screen>signature SIG =
   sig
      type t
      type u = _sig.t
      val x: _sig.t
      val y: _sig.t
   end</screen>
<simpara>Canonical names are always relative to the "top" of the signature,
even when used in nested substructures.  For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature S =
   sig
      type t
      val w: t
      structure U:
         sig
            type u
            val x: t
            val y: u
         end
      val z: U.u
   end</programlisting>
<simpara>is displayed as</simpara>
<screen>signature S =
   sig
      type t
      val w: _sig.t
      val z: _sig.U.u
      structure U:
         sig
            type u
            val x: _sig.t
            val y: _sig.U.u
         end
   end</screen>
</section>
<section id="_displaying_structures">
<title>Displaying structures</title>
<simpara>When displaying structures, MLton uses signature constraints wherever
possible, combined with <literal>where type</literal> clauses to specify the meanings
of the types defined within the signature.  For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature SIG =
   sig
      type t
      val x: t
   end
structure S: SIG =
   struct
      type t = int
      val x = 13
   end
structure S2:&gt; SIG = S</programlisting>
<simpara>is displayed as</simpara>
<screen>signature SIG =
   sig
      type t
      val x: _sig.t
   end
structure S: SIG
             where type t = int
structure S2: SIG
              where type t = S2.t</screen>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ShowBasisDirective">
<title>ShowBasisDirective</title>
<simpara>A comment of the form <literal>(*#showBasis "&lt;file&gt;"*)</literal> is recognized as a directive to
save the current basis (i.e., environment) to <literal>&lt;file&gt;</literal> (in the same format as
the <literal>-show-basis &lt;file&gt;</literal> <link linkend="CompileTimeOptions">compile-time option</link>).  The
<literal>&lt;file&gt;</literal> is interpreted relative to the source file in which it appears.  The
comment is lexed as a distinct token and is parsed as a structure-level
declaration.  [Note that treating the directive as a top-level declaration would
prohibit using it inside a functor body, which would make the feature
significantly less useful in the context of the MLton compiler sources (with its
nearly fully functorial style).]</simpara>
<simpara>This feature is meant to facilitate auto-completion via
<ulink url="https://github.com/MatthewFluet/company-mlton"><literal>company-mlton</literal></ulink> and similar
tools.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ShowProf">
<title>ShowProf</title>
<simpara>If an executable is compiled for <link linkend="Profiling">profiling</link>, then it
accepts a special command-line runtime system argument, <literal>show-prof</literal>,
that outputs information about the source functions that are profiled.
Normally, this information is used by <literal>mlprof</literal>.  This page documents
the <literal>show-prof</literal> output format, and is intended for those working on
the profiler internals.</simpara>
<simpara>The <literal>show-prof</literal> output is ASCII, and consists of a sequence of lines.</simpara>
<itemizedlist>
<listitem>
<simpara>
The magic number of the executable.
</simpara>
</listitem>
<listitem>
<simpara>
The number of source names in the executable.
</simpara>
</listitem>
<listitem>
<simpara>
A line for each source name giving the name of the function, a tab,
the filename of the file containing the function, a colon, a space,
and the line number that the function starts on in that file.
</simpara>
</listitem>
<listitem>
<simpara>
The number of (split) source functions.
</simpara>
</listitem>
<listitem>
<simpara>
A line for each (split) source function, where each line consists of
a source-name index (into the array of source names) and a successors
index (into the array of split-source sequences, defined below).
</simpara>
</listitem>
<listitem>
<simpara>
The number of split-source sequences.
</simpara>
</listitem>
<listitem>
<simpara>
A line for each split-source sequence, where each line is a space
separated list of (split) source functions.
</simpara>
</listitem>
</itemizedlist>
<simpara>The latter two arrays, split sources and split-source sequences,
define a directed graph, which is the call-graph of the program.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Shrink">
<title>Shrink</title>
<simpara><link linkend="Shrink">Shrink</link> is a rewrite pass for the <link linkend="SSA">SSA</link> and <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>s, invoked from every optimization pass (see
<link linkend="SSASimplify">SSASimplify</link> and <link linkend="SSA2Simplify">SSA2Simplify</link>).</simpara>
<section id="_description_55">
<title>Description</title>
<simpara>This pass implements a whole family of compile-time reductions, like:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>#1(a, b)</literal> &#8658; <literal>a</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>case C x of C y =&gt; e</literal> &#8658; <literal>let y = x in e</literal>
</simpara>
</listitem>
<listitem>
<simpara>
constant folding, copy propagation
</simpara>
</listitem>
<listitem>
<simpara>
eta blocks
</simpara>
</listitem>
<listitem>
<simpara>
tuple reconstruction elimination
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_implementation_60">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/shrink.sig"><literal>shrink.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/shrink.fun"><literal>shrink.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/shrink2.sig"><literal>shrink2.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/shrink2.fun"><literal>shrink2.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_58">
<title>Details and Notes</title>
<simpara>The <link linkend="Shrink">Shrink</link> pass is run after every <link linkend="SSA">SSA</link> and <link linkend="SSA2">SSA2</link>
optimization pass.</simpara>
<simpara>The <link linkend="Shrink">Shrink</link> implementation also includes functions to eliminate
unreachable blocks from a <link linkend="SSA">SSA</link> or <link linkend="SSA2">SSA2</link> program or function.
The <link linkend="Shrink">Shrink</link> pass does not guarantee to eliminate all unreachable
blocks.  Doing so would unduly complicate the implementation, and it
is almost always the case that all unreachable blocks are eliminated.
However, a small number of optimization passes require that the input
have no unreachable blocks (essentially, when the analysis works on
the control flow graph and the rewrite iterates on the vector of
blocks).  These passes explicitly call <literal>eliminateDeadBlocks</literal>.</simpara>
<simpara>The <link linkend="Shrink">Shrink</link> pass has a special case to turn a non-tail call where
the continuation and handler only do <literal>Profile</literal> statements into a tail
call where the <literal>Profile</literal> statements precede the tail call.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SimplifyTypes">
<title>SimplifyTypes</title>
<simpara><link linkend="SimplifyTypes">SimplifyTypes</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_56">
<title>Description</title>
<simpara>This pass computes a "cardinality" of each datatype, which is an
abstraction of the number of values of the datatype.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>Zero</literal> means the datatype has no values (except for bottom).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>One</literal> means the datatype has one value (except for bottom).
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Many</literal> means the datatype has many values.
</simpara>
</listitem>
</itemizedlist>
<simpara>This pass removes all datatypes whose cardinality is <literal>Zero</literal> or <literal>One</literal>
and removes:</simpara>
<itemizedlist>
<listitem>
<simpara>
components of tuples
</simpara>
</listitem>
<listitem>
<simpara>
function args
</simpara>
</listitem>
<listitem>
<simpara>
constructor args
</simpara>
</listitem>
</itemizedlist>
<simpara>which are such datatypes.</simpara>
<simpara>This pass marks constructors as one of:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>Useless</literal>: it never appears in a <literal>ConApp</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Transparent</literal>: it is the only variant in its datatype and its argument type does not contain any uses of <literal>array</literal> or <literal>vector</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Useful</literal>: otherwise
</simpara>
</listitem>
</itemizedlist>
<simpara>This pass also removes <literal>Useless</literal> and <literal>Transparent</literal> constructors.</simpara>
</section>
<section id="_implementation_61">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/simplify-types.fun"><literal>simplify-types.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_59">
<title>Details and Notes</title>
<simpara>This pass must happen before polymorphic equality is implemented because</simpara>
<itemizedlist>
<listitem>
<simpara>
it will make polymorphic equality faster because some types are simpler
</simpara>
</listitem>
<listitem>
<simpara>
it removes uses of polymorphic equality that must return true
</simpara>
</listitem>
</itemizedlist>
<simpara>We must keep track of <literal>Transparent</literal> constructors whose argument type
uses <literal>array</literal> because of datatypes like the following:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = T of t array</programlisting>
<simpara>Such a datatype has <literal>Cardinality.Many</literal>, but we cannot eliminate the
datatype and replace the lhs by the rhs, i.e. we must keep the
circularity around.</simpara>
<simpara>Must do similar things for <literal>vectors</literal>.</simpara>
<simpara>Also, to eliminate as many <literal>Transparent</literal> constructors as possible, for
something like the following,</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = T of u array
     and u = U of t vector</programlisting>
<simpara>we (arbitrarily) expand one of the datatypes first.  The result will
be something like</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype u = U of u array array</programlisting>
<simpara>where all uses of <literal>t</literal> are replaced by <literal>u array</literal>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SML3d">
<title>SML3d</title>
<simpara>The <ulink url="http://sml3d.cs.uchicago.edu/">SML3d Project</ulink> is a collection of
libraries to support 3D graphics programming using Standard ML and the
<ulink url="http://www.opengl.org/">OpenGL</ulink> graphics API. It currently requires the
MLton implementation of SML and is supported on Linux, Mac OS X, and
Microsoft Windows. There is also support for
<ulink url="http://www.khronos.org/opencl/">OpenCL</ulink>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SMLNET">
<title>SMLNET</title>
<simpara><ulink url="http://www.cl.cam.ac.uk/research/tsg/SMLNET">SML.NET</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link> that
targets the .NET Common Language Runtime.</simpara>
<simpara>SML.NET is based on the <link linkend="MLj">MLj</link> compiler.</simpara>
<section id="_also_see_43">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_BentonEtAl04">BentonEtAl04</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SMLNJ">
<title>SMLNJ</title>
<simpara><ulink url="http://www.smlnj.org/">SML/NJ</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link>.  It is a
native code compiler that runs on a variety of platforms and has a
number of libraries and tools.</simpara>
<simpara>We maintain a list of SML/NJ&#8217;s <link linkend="SMLNJDeviations">deviations</link> from
<link linkend="DefinitionOfStandardML">The Definition of Standard ML</link>.</simpara>
<simpara>MLton has support for some features of SML/NJ in order to ease porting
between MLton and SML/NJ.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CompilationManager">CompilationManager</link> (CM)
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LineDirective">LineDirective</link>s
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SMLofNJStructure">SMLofNJStructure</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="UnsafeStructure">UnsafeStructure</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SMLNJDeviations">
<title>SMLNJDeviations</title>
<simpara>Here are some deviations of <link linkend="SMLNJ">SML/NJ</link> from
<link linkend="DefinitionOfStandardML">The Definition of Standard ML (Revised)</link>.
Some of these are documented in the
<ulink url="http://www.smlnj.org/doc/Conversion/index.html">SML '97 Conversion Guide</ulink>.
Since MLton does not deviate from the Definition, you should look here
if you are having trouble porting a program from MLton to SML/NJ or
vice versa.  If you discover other deviations of SML/NJ that aren&#8217;t
listed here, please send mail to
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>.</simpara>
<itemizedlist>
<listitem>
<simpara>
SML/NJ allows spaces in long identifiers, as in <literal>S . x</literal>.  Section
2.5 of the Definition implies that <literal>S . x</literal> should be treated as three
separate lexical items.
</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows <literal>op</literal> to appear in <literal>val</literal> specifications:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature FOO = sig
   val op + : int * int -&gt; int
end</programlisting>
<simpara>The grammar on page 14 of the Definition does not allow it. Recent
versions of SML/NJ do give a warning.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ rejects
</simpara>
<programlisting language="sml" linenumbering="unnumbered">(op *)</programlisting>
<simpara>as an unmatched close comment.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows <literal>=</literal> to be rebound by the declaration:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val op = = 13</programlisting>
<simpara>This is explicitly forbidden on page 5 of the Definition. Recent
versions of SML/NJ do give a warning.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows rebinding <literal>true</literal>, <literal>false</literal>, <literal>nil</literal>, <literal>::</literal>, and <literal>ref</literal> by
the declarations:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun true () = ()
fun false () = ()
fun nil () = ()
fun op :: () = ()
fun ref () = ()</programlisting>
<simpara>This is explicitly forbidden on page 9 of the Definition.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ extends the syntax of the language to allow vector
expressions and patterns like the following:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val v = #[1,2,3]
val #[x,y,z] = v</programlisting>
<simpara>MLton supports vector expressions and patterns with the <link linkend="SuccessorML_VectorExpsAndPats"><literal>allowVectorExpsAndPats</literal></link> <link linkend="MLBasisAnnotations">ML Basis annotation</link>.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ extends the syntax of the language to allow <emphasis>or patterns</emphasis>
like the following:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype foo = Foo of int | Bar of int
val (Foo x | Bar x) = Foo 13</programlisting>
<simpara>MLton supports or patterns with the <link linkend="SuccessorML_OrPats"><literal>allowOrPats</literal></link> <link linkend="MLBasisAnnotations">ML Basis annotation</link>.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows higher-order functors, that is, functors can be
components of structures and can be passed as functor arguments and
returned as functor results.  As a consequence, SML/NJ allows
abbreviated functor definitions, as in the following:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature S =
  sig
    type t
    val x: t
  end
functor F (structure A: S): S =
  struct
    type t = A.t * A.t
    val x = (A.x, A.x)
  end
functor G = F</programlisting>
</listitem>
<listitem>
<simpara>
SML/NJ extends the syntax of the language to allow <literal>functor</literal> and
<literal>signature</literal> declarations to occur within the scope of <literal>local</literal> and
<literal>structure</literal> declarations.
</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows duplicate type specifications in signatures when the
duplicates are introduced by <literal>include</literal>, as in the following:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature SIG1 =
   sig
      type t
      type u
   end
signature SIG2 =
   sig
      type t
      type v
   end
signature SIG =
   sig
      include SIG1
      include SIG2
   end</programlisting>
<simpara>This is disallowed by rule 77 of the Definition.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows sharing constraints between type abbreviations in
signatures, as in the following:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature SIG =
   sig
      type t = int * int
      type u = int * int
      sharing type t = u
   end</programlisting>
<simpara>These are disallowed by rule 78 of the Definition.  Recent versions of
SML/NJ correctly disallow sharing constraints between type
abbreviations in signatures.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ disallows multiple <literal>where type</literal> specifications of the same
type name, as in the following
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature S =
  sig
     type t
     type u = t
  end
  where type u = int</programlisting>
<simpara>This is allowed by rule 64 of the Definition.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows <literal>and</literal> in <literal>sharing</literal> specs in signatures, as in
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature S =
   sig
      type t
      type u
      type v
      sharing type t = u
      and type u = v
   end</programlisting>
</listitem>
<listitem>
<simpara>
SML/NJ does not expand the <literal>withtype</literal> derived form as described by
the Definition.  According to page 55 of the Definition, the type
bindings of a <literal>withtype</literal> declaration are substituted simultaneously in
the connected datatype.  Consider the following program.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">type u = real ;
datatype a =
    A of t
  | B of u
withtype u = int
and t = u</programlisting>
<simpara>According to the Definition, it should be expanded to the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type u = real ;
datatype a =
    A of u
  | B of int ;
type u = int
and t = u</programlisting>
<simpara>However, SML/NJ expands <literal>withtype</literal> bindings sequentially, meaning that
earlier bindings are expanded within later ones. Hence, the above
program is expanded to the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type u = real ;
datatype a =
    A of int
  | B of int ;
type u = int
type t = int</programlisting>
</listitem>
<listitem>
<simpara>
SML/NJ allows <literal>withtype</literal> specifications in signatures.
</simpara>
<simpara>MLton supports <literal>withtype</literal> specifications in signatures with the <link linkend="SuccessorML_SigWithtype"><literal>allowSigWithtype</literal></link> <link linkend="MLBasisAnnotations">ML Basis annotation</link>.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ allows a <literal>where</literal> structure specification that is similar to a
<literal>where type</literal> specification.  For example:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S = struct type t = int end
signature SIG =
  sig
     structure T : sig type t end
  end where T = S</programlisting>
<simpara>This is equivalent to:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S = struct type t = int end
signature SIG =
  sig
     structure T : sig type t end
  end where type T.t = S.t</programlisting>
<simpara>SML/NJ also allows a definitional structure specification that is
similar to a definitional type specification.  For example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S = struct type t = int end
signature SIG =
  sig
     structure T : sig type t end = S
  end</programlisting>
<simpara>This is equivalent to the previous examples and to:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S = struct type t = int end
signature SIG =
  sig
     structure T : sig type t end where type t = S.t
  end</programlisting>
</listitem>
<listitem>
<simpara>
SML/NJ disallows binding non-datatypes with datatype replication.
For example, it rejects the following program that should be allowed
according to the Definition.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b) t = 'a * 'b
datatype u = datatype t</programlisting>
<simpara>This idiom can be useful when one wants to rename a type without
rewriting all the type arguments.  For example, the above would have
to be written in SML/NJ as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">type ('a, 'b) t = 'a * 'b
type ('a, 'b) u = ('a, 'b) t</programlisting>
</listitem>
<listitem>
<simpara>
SML/NJ disallows sharing a structure with one of its substructures.
For example, SML/NJ disallows the following.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature SIG =
   sig
      structure S:
         sig
            type t
            structure T: sig type t end
         end
      sharing S = S.T
   end</programlisting>
<simpara>This signature is allowed by the Definition.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ disallows polymorphic generalization of refutable
patterns. For example, SML/NJ disallows the following.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val [x] = [[]]
val _ = (1 :: x, "one" :: x)</programlisting>
<simpara>Recent versions of SML/NJ correctly allow polymorphic generalization
of refutable patterns.</simpara>
</listitem>
<listitem>
<simpara>
SML/NJ uses an overly restrictive context for type inference.  For
example, SML/NJ rejects both of the following.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S =
struct
  val z = (fn x =&gt; x) []
  val y = z :: [true] :: nil
end</programlisting>
<programlisting language="sml" linenumbering="unnumbered">structure S : sig val z : bool list end =
struct
  val z = (fn x =&gt; x) []
end</programlisting>
<simpara>These structures are allowed by the Definition.</simpara>
</listitem>
</itemizedlist>
<section id="_deviations_from_the_basis_library_specification">
<title>Deviations from the Basis Library Specification</title>
<simpara>Here are some deviations of SML/NJ from the <link linkend="BasisLibrary">Basis Library</link>
<ulink url="http://www.standardml.org/Basis">specification</ulink>.</simpara>
<itemizedlist>
<listitem>
<simpara>
SML/NJ exposes the equality of the <literal>vector</literal> type in structures such
as <literal>Word8Vector</literal> that abstractly match <literal>MONO_VECTOR</literal>, which says
<literal>type vector</literal>, not <literal>eqtype vector</literal>.  So, for example, SML/NJ accepts
the following program:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (v: Word8Vector.vector) = v = v</programlisting>
</listitem>
<listitem>
<simpara>
SML/NJ exposes the equality property of the type <literal>status</literal> in
<literal>OS.Process</literal>. This means that programs which directly compare two
values of type <literal>status</literal> will work with SML/NJ but not MLton.
</simpara>
</listitem>
<listitem>
<simpara>
Under SML/NJ on Windows, <literal>OS.Path.validVolume</literal> incorrectly considers
absolute empty volumes to be valid. In other words, when the
expression
</simpara>
<programlisting language="sml" linenumbering="unnumbered">OS.Path.validVolume { isAbs = true, vol = "" }</programlisting>
<simpara>is evaluated by SML/NJ on Windows, the result is <literal>true</literal>.  MLton, on
the other hand, correctly follows the Basis Library Specification,
which states that on Windows, <literal>OS.Path.validVolume</literal> should return
<literal>false</literal> whenever <literal>isAbs = true</literal> and <literal>vol = ""</literal>.</simpara>
<simpara>This incorrect behavior causes other <literal>OS.Path</literal> functions to behave
differently. For example, when the expression</simpara>
<programlisting language="sml" linenumbering="unnumbered">OS.Path.toString (OS.Path.fromString "\\usr\\local")</programlisting>
<simpara>is evaluated by SML/NJ on Windows, the result is <literal>"\\usr\\local"</literal>,
whereas under MLton on Windows, evaluating this expression (correctly)
causes an <literal>OS.Path.Path</literal> exception to be raised.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SMLNJLibrary">
<title>SMLNJLibrary</title>
<simpara>The <ulink url="http://www.smlnj.org/doc/smlnj-lib/index.html">SML/NJ Library</ulink> is a
collection of libraries that are distributed with SML/NJ.  Due to
differences between SML/NJ and MLton, these libraries will not work
out-of-the box with MLton.</simpara>
<simpara>As of 20180119, MLton includes a port of the SML/NJ Library
synchronized with SML/NJ version 110.82.</simpara>
<section id="_usage_8">
<title>Usage</title>
<itemizedlist>
<listitem>
<simpara>
You can import a sub-library of the SML/NJ Library into an MLB file with:
</simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<thead>
<row>
<entry align="left" valign="top">MLB file</entry>
<entry align="left" valign="top">Description</entry>
</row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/Util/smlnj-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Various utility modules, included collections, simple formating, &#8230;</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/Controls/controls-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>A library for managing control flags in an application.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/HashCons/hash-cons-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Support for implementing hash-consed data structures.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/HTML/html-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>HTML 3.2 parsing and pretty-printing library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/HTML4/html4-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>HTML 4.01 parsing and pretty-printing library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/INet/inet-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Networking utilities; supported on both Unix and Windows systems.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/JSON/json-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>JavaScript Object Notation (JSON) reading and writing library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/PP/pp-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Pretty-printing library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/Reactive/reactive-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Reactive scripting library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/RegExp/regexp-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Regular expression library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/SExp/sexp-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>S-expression library.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/Unix/unix-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>Utilities for Unix-based operating systems.</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara><literal>$(SML_LIB)/smlnj-lib/XML/xml-lib.mlb</literal></simpara></entry>
<entry align="left" valign="top"><simpara>XML library.</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
<listitem>
<simpara>
If you are porting a project from SML/NJ&#8217;s <link linkend="CompilationManager">CompilationManager</link> to
MLton&#8217;s <link linkend="MLBasis">ML Basis system</link> using <literal>cm2mlb</literal>, note that the
following maps are included by default:
</simpara>
<screen># SMLNJ Library
$SMLNJ-LIB                              $(SML_LIB)/smlnj-lib
$smlnj-lib.cm                           $(SML_LIB)/smlnj-lib/Util
$controls-lib.cm                        $(SML_LIB)/smlnj-lib/Controls
$hash-cons-lib.cm                       $(SML_LIB)/smlnj-lib/HashCons
$html-lib.cm                            $(SML_LIB)/smlnj-lib/HTML
$html4-lib.cm                           $(SML_LIB)/smlnj-lib/HTML4
$inet-lib.cm                            $(SML_LIB)/smlnj-lib/INet
$json-lib.cm                            $(SML_LIB)/smlnj-lib/JSON
$pp-lib.cm                              $(SML_LIB)/smlnj-lib/PP
$reactive-lib.cm                        $(SML_LIB)/smlnj-lib/Reactive
$regexp-lib.cm                          $(SML_LIB)/smlnj-lib/RegExp
$sexp-lib.cm                            $(SML_LIB)/smlnj-lib/SExp
$unix-lib.cm                            $(SML_LIB)/smlnj-lib/Unix
$xml-lib.cm                             $(SML_LIB)/smlnj-lib/XML</screen>
<simpara>This will automatically convert a <literal>$/smlnj-lib.cm</literal> import in an input
<literal>.cm</literal> file into a <literal>$(SML_LIB)/smlnj-lib/Util/smlnj-lib.mlb</literal> import in
the output <literal>.mlb</literal> file.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_4">
<title>Details</title>
<simpara>The following changes were made to the SML/NJ Library, in addition to
deriving the <literal>.mlb</literal> files from the <literal>.cm</literal> files:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>HTML4/pp-init.sml</literal> (added): Implements <literal>structure PrettyPrint</literal> using the SML/NJ PP Library.  This implementation is taken from the SML/NJ compiler source, since the SML/NJ HTML4 Library used the <literal>structure PrettyPrint</literal> provided by the SML/NJ compiler itself.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/base64.sml</literal> (modified): Rewrote use of <literal>Unsafe.CharVector.create</literal> and <literal>Unsafe.CharVector.update</literal>; MLton assumes that vectors are immutable.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/engine.mlton.sml</literal> (added, not exported): Implements <literal>structure Engine</literal>, providing time-limited, resumable computations using <link linkend="MLtonThread">MLtonThread</link>, <link linkend="MLtonSignal">MLtonSignal</link>, and <link linkend="MLtonItimer">MLtonItimer</link>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/graph-scc-fn.sml</literal> (modified): Rewrote use of <literal>where</literal> structure specification.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/redblack-map-fn.sml</literal> (modified): Rewrote use of <literal>where</literal> structure specification.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/redblack-set-fn.sml</literal> (modified): Rewrote use of <literal>where</literal> structure specification.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/time-limit.mlb</literal> (added): Exports <literal>structure TimeLimit</literal>, which is <emphasis>not</emphasis> exported by <literal>smlnj-lib.mlb</literal>.  Since MLton is very conservative in the presence of threads and signals, program performance may be adversely affected by unnecessarily including <literal>structure TimeLimit</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Util/time-limit.mlton.sml</literal> (added): Implements <literal>structure TimeLimit</literal> using <literal>structure Engine</literal>.  The SML/NJ implementation of <literal>structure TimeLimit</literal> uses SML/NJ&#8217;s first-class continuations, signals, and interval timer.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_patch_4">
<title>Patch</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/lib/smlnj-lib/smlnj-lib.patch"><literal>smlnj-lib.patch</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SMLofNJStructure">
<title>SMLofNJStructure</title>
<programlisting language="sml" linenumbering="unnumbered">signature SML_OF_NJ =
   sig
      structure Cont:
         sig
            type 'a cont
            val callcc: ('a cont -&gt; 'a) -&gt; 'a
            val isolate: ('a -&gt; unit) -&gt; 'a cont
            val throw: 'a cont -&gt; 'a -&gt; 'b
         end
      structure SysInfo:
         sig
            exception UNKNOWN
            datatype os_kind = BEOS | MACOS | OS2 | UNIX | WIN32

            val getHostArch: unit -&gt; string
            val getOSKind: unit -&gt; os_kind
            val getOSName: unit -&gt; string
         end

      val exnHistory: exn -&gt; string list
      val exportFn: string * (string * string list -&gt; OS.Process.status) -&gt; unit
      val exportML: string -&gt; bool
      val getAllArgs: unit -&gt; string list
      val getArgs: unit -&gt; string list
      val getCmdName: unit -&gt; string
   end</programlisting>
<simpara><literal>SMLofNJ</literal> implements a subset of the structure of the same name
provided in <link linkend="SMLNJ">Standard ML of New Jersey</link>.  It is included to
make it easier to port programs between the two systems.  The
semantics of these functions may be different than in SML/NJ.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>structure Cont</literal>
</simpara>
<simpara>implements continuations.</simpara>
</listitem>
<listitem>
<simpara>
<literal>SysInfo.getHostArch ()</literal>
</simpara>
<simpara>returns the string for the architecture.</simpara>
</listitem>
<listitem>
<simpara>
<literal>SysInfo.getOSKind</literal>
</simpara>
<simpara>returns the OS kind.</simpara>
</listitem>
<listitem>
<simpara>
<literal>SysInfo.getOSName ()</literal>
</simpara>
<simpara>returns the string for the host.</simpara>
</listitem>
<listitem>
<simpara>
<literal>exnHistory</literal>
</simpara>
<simpara>the same as <literal>MLton.Exn.history</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>getCmdName ()</literal>
</simpara>
<simpara>the same as <literal>CommandLine.name ()</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>getArgs ()</literal>
</simpara>
<simpara>the same as <literal>CommandLine.arguments ()</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>getAllArgs ()</literal>
</simpara>
<simpara>the same as <literal>getCmdName()::getArgs()</literal>.</simpara>
</listitem>
<listitem>
<simpara>
<literal>exportFn f</literal>
</simpara>
<simpara>saves the state of the computation to a file that will apply <literal>f</literal> to
the command-line arguments upon restart.</simpara>
</listitem>
<listitem>
<simpara>
<literal>exportML f</literal>
</simpara>
<simpara>saves the state of the computation to file <literal>f</literal> and continue.  Returns
<literal>true</literal> in the restarted computation and <literal>false</literal> in the continuing
computation.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SMLSharp">
<title>SMLSharp</title>
<simpara><ulink url="http://www.pllab.riec.tohoku.ac.jp/smlsharp/">SML#</ulink> is an
<link linkend="StandardMLImplementations">implementation</link> of an extension of SML.</simpara>
<simpara>It includes some
<ulink url="http://www.pllab.riec.tohoku.ac.jp/smlsharp/?Tools">generally useful SML tools</ulink>
including a pretty printer generator, a document generator, and a
regression testing framework, and
<ulink url="http://www.pllab.riec.tohoku.ac.jp/smlsharp/?Library%2FScripting">scripting library</ulink>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Sources">
<title>Sources</title>
<simpara>We maintain our sources with <link linkend="Git">Git</link>.  You can
<ulink url="https://github.com/MLton/mlton/">view them on the web</ulink> or access
them with a git client.</simpara>
<simpara>Anonymous read-only access is available via</simpara>
<screen>https://github.com/MLton/mlton.git</screen>
<simpara>or</simpara>
<screen>git://github.com/MLton/mlton.git</screen>
<section id="_commit_email">
<title>Commit email</title>
<simpara>All commits are sent to
<ulink url="mailto:MLton-commit@mlton.org"><literal>MLton-commit@mlton.org</literal></ulink>
(<ulink url="https://lists.sourceforge.net/lists/listinfo/mlton-commit">subscribe</ulink>,
<ulink url="https://sourceforge.net/mailarchive/forum.php?forum_name=mlton-commit">archive</ulink>,
<ulink url="http://www.mlton.org/pipermail/mlton-commit/">archive</ulink>) which is a
read-only mailing list for commit emails.  Discussion should go to
<ulink url="mailto:MLton-devel@mlton.org"><literal>MLton-devel@mlton.org</literal></ulink>.</simpara>
</section>
<section id="_changelog">
<title>Changelog</title>
<simpara>See <ulink url="https://github.com/MLton/mlton/blob/master/CHANGELOG.adoc"><literal>CHANGELOG.adoc</literal></ulink> for a list of
changes and bug fixes.</simpara>
</section>
<section id="_subversion">
<title>Subversion</title>
<simpara>Prior to 20130308, we used <link linkend="Subversion">Subversion</link>.</simpara>
</section>
<section id="_cvs">
<title>CVS</title>
<simpara>Prior to 20050730, we used <link linkend="CVS">CVS</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SpaceSafety">
<title>SpaceSafety</title>
<simpara>Informally, space safety is a property of a language implementation
that asymptotically bounds the space used by a running program.</simpara>
<section id="_also_see_44">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
Chapter 12 of <link linkend="References_Appel92">Appel92</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Clinger98">Clinger98</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SSA">
<title>SSA</title>
<simpara><link linkend="SSA">SSA</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from <link linkend="SXML">SXML</link> by
<link linkend="ClosureConvert">ClosureConvert</link>, optimized by <link linkend="SSASimplify">SSASimplify</link>, and translated by
<link linkend="ToSSA2">ToSSA2</link> to <link linkend="SSA2">SSA2</link>.</simpara>
<section id="_description_57">
<title>Description</title>
<simpara><link linkend="SSA">SSA</link> is a <link linkend="FirstOrder">FirstOrder</link>, <link linkend="SimplyTyped">SimplyTyped</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.
It is the main <link linkend="IntermediateLanguage">IntermediateLanguage</link> used for optimizations.</simpara>
<simpara>An <link linkend="SSA">SSA</link> program consists of a collection of datatype declarations,
a sequence of global statements, and a collection of functions, along
with a distinguished "main" function.  Each function consists of a
collection of basic blocks, where each basic block is a sequence of
statements ending with some control transfer.</simpara>
</section>
<section id="_implementation_62">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa.sig"><literal>ssa.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa.fun"><literal>ssa.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa-tree.sig"><literal>ssa-tree.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa-tree.fun"><literal>ssa-tree.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_5">
<title>Type Checking</title>
<simpara>Type checking (<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/type-check.sig"><literal>type-check.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/type-check.fun"><literal>type-check.fun</literal></ulink>) of a <link linkend="SSA">SSA</link> program
verifies the following:</simpara>
<itemizedlist>
<listitem>
<simpara>
no duplicate definitions (tycons, cons, vars, labels, funcs)
</simpara>
</listitem>
<listitem>
<simpara>
no out of scope references (tycons, cons, vars, labels, funcs)
</simpara>
</listitem>
<listitem>
<simpara>
variable definitions dominate variable uses
</simpara>
</listitem>
<listitem>
<simpara>
case transfers are exhaustive and irredundant
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Enter</literal>/<literal>Leave</literal> profile statements match
</simpara>
</listitem>
<listitem>
<simpara>
"traditional" well-typedness
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_60">
<title>Details and Notes</title>
<simpara>SSA is an abbreviation for Static Single Assignment.</simpara>
<simpara>For some initial design discussion, see the thread at:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://mlton.org/pipermail/mlton/2001-August/019689.html">http://mlton.org/pipermail/mlton/2001-August/019689.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>For some retrospectives, see the threads at:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://mlton.org/pipermail/mlton/2003-January/023054.html">http://mlton.org/pipermail/mlton/2003-January/023054.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://mlton.org/pipermail/mlton/2007-February/029597.html">http://mlton.org/pipermail/mlton/2007-February/029597.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SSA2">
<title>SSA2</title>
<simpara><link linkend="SSA2">SSA2</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from <link linkend="SSA">SSA</link> by
<link linkend="ToSSA2">ToSSA2</link>, optimized by <link linkend="SSA2Simplify">SSA2Simplify</link>, and translated by
<link linkend="ToRSSA">ToRSSA</link> to <link linkend="RSSA">RSSA</link>.</simpara>
<section id="_description_58">
<title>Description</title>
<simpara><link linkend="SSA2">SSA2</link> is a <link linkend="FirstOrder">FirstOrder</link>, <link linkend="SimplyTyped">SimplyTyped</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, a slight variant of the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>,</simpara>
<simpara>Like <link linkend="SSA">SSA</link>, an <link linkend="SSA2">SSA2</link> program consists of a collection of datatype
declarations, a sequence of global statements, and a collection of
functions, along with a distinguished "main" function.  Each function
consists of a collection of basic blocks, where each basic block is a
sequence of statements ending with some control transfer.</simpara>
<simpara>Unlike <link linkend="SSA">SSA</link>, <link linkend="SSA2">SSA2</link> includes mutable fields in objects and makes
the vector type constructor n-ary instead of unary.  This allows
optimizations like <link linkend="RefFlatten">RefFlatten</link> and <link linkend="DeepFlatten">DeepFlatten</link> to be expressed.</simpara>
</section>
<section id="_implementation_63">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa2.sig"><literal>ssa2.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa2.fun"><literal>ssa2.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa-tree2.sig"><literal>ssa-tree2.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa-tree2.fun"><literal>ssa-tree2.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_6">
<title>Type Checking</title>
<simpara>Type checking (<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/type-check2.sig"><literal>type-check2.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/type-check2.fun"><literal>type-check2.fun</literal></ulink>) of a <link linkend="SSA2">SSA2</link>
program verifies the following:</simpara>
<itemizedlist>
<listitem>
<simpara>
no duplicate definitions (tycons, cons, vars, labels, funcs)
</simpara>
</listitem>
<listitem>
<simpara>
no out of scope references (tycons, cons, vars, labels, funcs)
</simpara>
</listitem>
<listitem>
<simpara>
variable definitions dominate variable uses
</simpara>
</listitem>
<listitem>
<simpara>
case transfers are exhaustive and irredundant
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Enter</literal>/<literal>Leave</literal> profile statements match
</simpara>
</listitem>
<listitem>
<simpara>
"traditional" well-typedness
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_61">
<title>Details and Notes</title>
<simpara>SSA is an abbreviation for Static Single Assignment.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SSA2Simplify">
<title>SSA2Simplify</title>
<simpara>The optimization passes for the <link linkend="SSA2">SSA2</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> are
collected and controlled by the <literal>Simplify2</literal> functor
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/simplify2.sig"><literal>simplify2.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/simplify2.fun"><literal>simplify2.fun</literal></ulink>).</simpara>
<simpara>The following optimization passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="DeepFlatten">DeepFlatten</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RefFlatten">RefFlatten</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RemoveUnused">RemoveUnused</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Zone">Zone</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>There are additional analysis and rewrite passes that augment many of the other optimization passes:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Restore">Restore</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Shrink">Shrink</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The optimization passes can be controlled from the command-line by the options</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-diag-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep diagnostic info for pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-disable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;skip optimization pass (if normally performed)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-enable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;perform optimization pass (if normally skipped)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-keep-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep the results of pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-loop-passes &lt;n&gt;</literal>&#8201;&#8212;&#8201;loop optimization passes
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-ssa2-passes &lt;passes&gt;</literal>&#8201;&#8212;&#8201;ssa optimization passes
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SSASimplify">
<title>SSASimplify</title>
<simpara>The optimization passes for the <link linkend="SSA">SSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> are
collected and controlled by the <literal>Simplify</literal> functor
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/simplify.sig"><literal>simplify.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/simplify.fun"><literal>simplify.fun</literal></ulink>).</simpara>
<simpara>The following optimization passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CombineConversions">CombineConversions</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CommonArg">CommonArg</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CommonBlock">CommonBlock</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="CommonSubexp">CommonSubexp</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ConstantPropagation">ConstantPropagation</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Contify">Contify</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Flatten">Flatten</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Inline">Inline</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="IntroduceLoops">IntroduceLoops</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="KnownCase">KnownCase</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LocalFlatten">LocalFlatten</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LocalRef">LocalRef</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LoopInvariant">LoopInvariant</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LoopUnfoll">LoopUnfoll</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LoopUnswitch">LoopUnswitch</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Redundant">Redundant</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RedundantTests">RedundantTests</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="RemoveUnused">RemoveUnused</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ShareZeroVec">ShareZeroVec</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SimplifyTypes">SimplifyTypes</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Useless">Useless</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The following implementation passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="PolyEqual">PolyEqual</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PolyHash">PolyHash</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>There are additional analysis and rewrite passes that augment many of the other optimization passes:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Multi">Multi</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Restore">Restore</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Shrink">Shrink</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The optimization passes can be controlled from the command-line by the options:</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-diag-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep diagnostic info for pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-disable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;skip optimization pass (if normally performed)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-enable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;perform optimization pass (if normally skipped)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-keep-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep the results of pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-loop-passes &lt;n&gt;</literal>&#8201;&#8212;&#8201;loop optimization passes
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-ssa-passes &lt;passes&gt;</literal>&#8201;&#8212;&#8201;ssa optimization passes
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Stabilizers">
<title>Stabilizers</title>
<section id="_installation">
<title>Installation</title>
<itemizedlist>
<listitem>
<simpara>
Stabilizers currently require the MLton sources, this should be fixed by the next release
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_license">
<title>License</title>
<itemizedlist>
<listitem>
<simpara>
Stabilizers are released under the MLton License
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_instructions">
<title>Instructions</title>
<itemizedlist>
<listitem>
<simpara>
Download and build a source copy of MLton
</simpara>
</listitem>
<listitem>
<simpara>
Extract the tar.gz file attached to this page
</simpara>
</listitem>
<listitem>
<simpara>
Some examples are provided in the "examples/" sub directory, more examples will be added to this page in the following week
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_bug_reports_suggestions">
<title>Bug reports / Suggestions</title>
<itemizedlist>
<listitem>
<simpara>
Please send any errors you encounter to schatzp and lziarek at cs.purdue.edu
</simpara>
</listitem>
<listitem>
<simpara>
We are looking to expand the usability of stabilizers
</simpara>
</listitem>
<listitem>
<simpara>
Please send any suggestions and desired functionality to the above email addresses
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_note">
<title>Note</title>
<itemizedlist>
<listitem>
<simpara>
This is an alpha release. We expect to have another release shortly with added functionality soon
</simpara>
</listitem>
<listitem>
<simpara>
More documentation, such as signatures and descriptions of functionality, will be forthcoming
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_documentation">
<title>Documentation</title>
<programlisting language="sml" linenumbering="unnumbered">signature STABLE =
  sig
     type checkpoint

     val stable: ('a -&gt; 'b) -&gt; ('a -&gt; 'b)
     val stabilize: unit -&gt; 'a

     val stableCP: (('a -&gt; 'b) * (unit -&gt; unit)) -&gt;
                    (('a -&gt; 'b) *  checkpoint)
     val stabilizeCP: checkpoint -&gt; unit

     val unmonitoredAssign: ('a ref * 'a) -&gt; unit
     val monitoredAssign: ('a ref * 'a) -&gt; unit
  end</programlisting>
<simpara><literal>Stable</literal> provides functions to manage stable sections.</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>type checkpoint</literal>
</simpara>
<simpara>handle used to stabilize contexts other than the current one.</simpara>
</listitem>
<listitem>
<simpara>
<literal>stable f</literal>
</simpara>
<simpara>returns a function identical to <literal>f</literal> that will execute within a stable section.</simpara>
</listitem>
<listitem>
<simpara>
<literal>stabilize ()</literal>
</simpara>
<simpara>unrolls the effects made up to the current context to at least the
nearest enclosing <emphasis>stable</emphasis> section.  These effects may have propagated
to other threads, so all affected threads are returned to a globally
consistent previous state.  The return is undefined because control
cannot resume after stabilize is called.</simpara>
</listitem>
<listitem>
<simpara>
<literal>stableCP (f, comp)</literal>
</simpara>
<simpara>returns a function <literal>f'</literal> and checkpoint tag <literal>cp</literal>.  Function <literal>f'</literal> is
identical to <literal>f</literal> but when applied will execute within a stable
section.  <literal>comp</literal> will be executed if <literal>f'</literal> is later stabilized.  <literal>cp</literal>
is used by <literal>stabilizeCP</literal> to stabilize a given checkpoint.</simpara>
</listitem>
<listitem>
<simpara>
<literal>stabilizeCP cp</literal>
</simpara>
<simpara>same as stabilize except that the (possibly current) checkpoint to
stabilize is provided.</simpara>
</listitem>
<listitem>
<simpara>
<literal>unmonitoredAssign (r, v)</literal>
</simpara>
<simpara>standard assignment (<literal>:=</literal>).  The version of CML distributed rebinds
<literal>:=</literal> to a monitored version so interesting effects can be recorded.</simpara>
</listitem>
<listitem>
<simpara>
<literal>monitoredAssign (r, v)</literal>
</simpara>
<simpara>the assignment operator that should be used in programs that use
stabilizers. <literal>:=</literal> is rebound to this by including CML.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_download_7">
<title>Download</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="guide/Stabilizers.attachments/stabilizers_alpha_2006-10-09.tar.gz"><literal>stabilizers_alpha_2006-10-09.tar.gz</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_45">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_ZiarekEtAl06">ZiarekEtAl06</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="StandardML">
<title>StandardML</title>
<simpara>Standard ML (SML) is a programming language that combines excellent
support for rapid prototyping, modularity, and development of large
programs, with performance approaching that of C.</simpara>
<section id="_sml_resources">
<title>SML Resources</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="StandardMLTutorials">Tutorials</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="StandardMLBooks">Books</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="StandardMLImplementations">Implementations</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_aspects_of_sml">
<title>Aspects of SML</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="DefineTypeBeforeUse">DefineTypeBeforeUse</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="EqualityType">EqualityType</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="EqualityTypeVariable">EqualityTypeVariable</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="GenerativeDatatype">GenerativeDatatype</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="GenerativeException">GenerativeException</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Identifier">Identifier</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="OperatorPrecedence">OperatorPrecedence</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Overloading">Overloading</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PolymorphicEquality">PolymorphicEquality</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TypeVariableScope">TypeVariableScope</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ValueRestriction">ValueRestriction</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_using_sml">
<title>Using SML</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Fixpoints">Fixpoints</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ForLoops">ForLoops</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="FunctionalRecordUpdate">FunctionalRecordUpdate</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="InfixingOperators">InfixingOperators</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Lazy">Lazy</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ObjectOrientedProgramming">ObjectOrientedProgramming</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="OptionalArguments">OptionalArguments</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Printf">Printf</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PropertyList">PropertyList</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ReturnStatement">ReturnStatement</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Serialization">Serialization</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="StandardMLGotchas">StandardMLGotchas</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="StyleGuide">StyleGuide</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TipsForWritingConciseSML">TipsForWritingConciseSML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="UniversalType">UniversalType</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_programming_in_sml">
<title>Programming in SML</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Emacs">Emacs</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Enscript">Enscript</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Pygments">Pygments</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_notes_18">
<title>Notes</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="StandardMLHistory">History of SML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Regions">Regions</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_related_languages">
<title>Related Languages</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Alice">Alice</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="FSharp">F#</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="OCaml">OCaml</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="StandardMLBooks">
<title>StandardMLBooks</title>
<section id="_introductory_books">
<title>Introductory Books</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Ullman98">Elements of ML Programming</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Paulson96">ML For the Working Programmer</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_HansenRichel99">Introduction to Programming using SML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_FelleisenFreidman98">The Little MLer</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_applications_3">
<title>Applications</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Shipman02">Unix System Programming with Standard ML</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_reference_books">
<title>Reference Books</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_GansnerReppy04">The Standard ML Basis Library</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="DefinitionOfStandardML">The Definition of Standard ML (Revised)</link>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_related_topics">
<title>Related Topics</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="References_Reppy07">Concurrent Programming in ML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Okasaki99">Purely Functional Data Structures</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="StandardMLGotchas">
<title>StandardMLGotchas</title>
<simpara>This page contains brief explanations of some recurring sources of
confusion and problems that SML newbies encounter.</simpara>
<simpara>Many confusions about the syntax of SML seem to arise from the use of
an interactive REPL (Read-Eval Print Loop) while trying to learn the
basics of the language.  While writing your first SML programs, you
should keep the source code of your programs in a form that is
accepted by an SML compiler as a whole.</simpara>
<section id="_the_literal_and_literal_keyword">
<title>The <literal>and</literal> keyword</title>
<simpara>It is a common mistake to misuse the <literal>and</literal> keyword or to not know how
to introduce mutually recursive definitions.  The purpose of the <literal>and</literal>
keyword is to introduce mutually recursive definitions of functions
and datatypes.  For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun isEven 0w0 = true
  | isEven 0w1 = false
  | isEven n = isOdd (n-0w1)
and isOdd 0w0 = false
  | isOdd 0w1 = true
  | isOdd n = isEven (n-0w1)</programlisting>
<simpara>and</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype decl = VAL of id * pat * expr
           (* | ... *)
     and expr = LET of decl * expr
           (* | ... *)</programlisting>
<simpara>You can also use <literal>and</literal> as a shorthand in a couple of other places, but
it is not necessary.</simpara>
</section>
<section id="_constructed_patterns">
<title>Constructed patterns</title>
<simpara>It is a common mistake to forget to parenthesize constructed patterns
in <literal>fun</literal> bindings.  Consider the following invalid definition:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun length nil = 0
  | length h :: t = 1 + length t</programlisting>
<variablelist>
<varlistentry>
<term>
The pattern `h 
</term>
<listitem>
<simpara>
t` needs to be parenthesized:
</simpara>
</listitem>
</varlistentry>
</variablelist>
<programlisting language="sml" linenumbering="unnumbered">fun length nil = 0
  | length (h :: t) = 1 + length t</programlisting>
<simpara>The parentheses are needed, because a <literal>fun</literal> definition may have
multiple consecutive constructed patterns through currying.</simpara>
<simpara>The same applies to nonfix constructors.  For example, the parentheses
in</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun valOf NONE = raise Option
  | valOf (SOME x) = x</programlisting>
<simpara>are required.  However, the outermost constructed pattern in a <literal>fn</literal> or
<literal>case</literal> expression need not be parenthesized, because in those cases
there is always just one constructed pattern.  So, both</simpara>
<programlisting language="sml" linenumbering="unnumbered">val valOf = fn NONE =&gt; raise Option
             | SOME x =&gt; x</programlisting>
<simpara>and</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun valOf x = case x of
                 NONE =&gt; raise Option
               | SOME x =&gt; x</programlisting>
<simpara>are fine.</simpara>
</section>
<section id="_declarations_and_expressions">
<title>Declarations and expressions</title>
<simpara>It is a common mistake to confuse expressions and declarations.
Normally an SML source file should only contain declarations.  The
following are declarations:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype dt = ...
fun f ... = ...
functor Fn (...) = ...
infix ...
infixr ...
local ... in ... end
nonfix ...
open ...
signature SIG = ...
structure Struct = ...
type t = ...
val v = ...</programlisting>
<simpara>Note that</simpara>
<programlisting language="sml" linenumbering="unnumbered">let ... in ... end</programlisting>
<simpara>isn&#8217;t a declaration.</simpara>
<simpara>To specify a side-effecting computation in a source file, you can write:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = ...</programlisting>
</section>
<section id="_equality_types">
<title>Equality types</title>
<simpara>SML has a fairly intricate built-in notion of equality.  See
<link linkend="EqualityType">EqualityType</link> and <link linkend="EqualityTypeVariable">EqualityTypeVariable</link> for a thorough
discussion.</simpara>
</section>
<section id="_nested_cases">
<title>Nested cases</title>
<simpara>It is a common mistake to write nested case expressions without the
necessary parentheses.  See <link linkend="UnresolvedBugs">UnresolvedBugs</link> for a discussion.</simpara>
</section>
<section id="_op">
<title>(op *)</title>
<simpara>It used to be a common mistake to parenthesize <literal>op *</literal> as <literal>(op *)</literal>.
Before SML&#8217;97, <literal>*)</literal> was considered a comment terminator in SML and
caused a syntax error.  At the time of writing, <link linkend="SMLNJ">SML/NJ</link> still
rejects the code.  An extra space may be used for portability:
<literal>(op * )</literal>. However, parenthesizing <literal>op</literal> is redundant, even though it
is a widely used convention.</simpara>
</section>
<section id="_overloading">
<title>Overloading</title>
<simpara>A number of standard operators (<literal>+</literal>, <literal>-</literal>, <literal>~</literal>, <literal>*</literal>, <literal>&lt;</literal>, <literal>&gt;</literal>, &#8230;) and
numeric constants are overloaded for some of the numeric types (<literal>int</literal>,
<literal>real</literal>, <literal>word</literal>).  It is a common surprise that definitions using
overloaded operators such as</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun min (x, y) = if y &lt; x then y else x</programlisting>
<simpara>are not overloaded themselves.  SML doesn&#8217;t really support
(user-defined) overloading or other forms of ad hoc polymorphism.  In
cases such as the above where the context doesn&#8217;t resolve the
overloading, expressions using overloaded operators or constants get
assigned a default type.  The above definition gets the type</simpara>
<programlisting language="sml" linenumbering="unnumbered">val min : int * int -&gt; int</programlisting>
<simpara>See <link linkend="Overloading">Overloading</link> and <link linkend="TypeIndexedValues">TypeIndexedValues</link> for further discussion.</simpara>
</section>
<section id="_semicolons">
<title>Semicolons</title>
<simpara>It is a common mistake to use redundant semicolons in SML code.  This
is probably caused by the fact that in an SML REPL, a semicolon (and
enter) is used to signal the REPL that it should evaluate the
preceding chunk of code as a unit.  In SML source files, semicolons
are really needed in only two places.  Namely, in expressions of the
form</simpara>
<programlisting language="sml" linenumbering="unnumbered">(exp ; ... ; exp)</programlisting>
<simpara>and</simpara>
<programlisting language="sml" linenumbering="unnumbered">let ... in exp ; ... ; exp end</programlisting>
<simpara>Note that semicolons act as expression (or declaration) separators
rather than as terminators.</simpara>
</section>
<section id="_stale_bindings">
<title>Stale bindings</title>
<simpara></simpara>
</section>
<section id="_unresolved_records">
<title>Unresolved records</title>
<simpara></simpara>
</section>
<section id="_value_restriction">
<title>Value restriction</title>
<simpara>See <link linkend="ValueRestriction">ValueRestriction</link>.</simpara>
</section>
<section id="_type_variable_scope">
<title>Type Variable Scope</title>
<simpara>See <link linkend="TypeVariableScope">TypeVariableScope</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="StandardMLHistory">
<title>StandardMLHistory</title>
<simpara><link linkend="StandardML">Standard ML</link> grew out of <link linkend="ML">ML</link> in the early 1980s.</simpara>
<simpara>For an excellent overview of SML&#8217;s history, see Appendix F of the
<link linkend="DefinitionOfStandardML">Definition</link>.</simpara>
<simpara>For an overview if its history before 1982, see <link linkend="References_Milner82">How ML Evolved</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="StandardMLImplementations">
<title>StandardMLImplementations</title>
<simpara>There are a number of implementations of <link linkend="StandardML">Standard ML</link>,
from interpreters, to byte-code compilers, to incremental compilers,
to whole-program compilers.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Alice">Alice ML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="HaMLet">HaMLet</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLKit">ML Kit</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Home">MLton</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MoscowML">Moscow ML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="PolyML">Poly/ML</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SMLSharp">SML#</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SMLNJ">SML/NJ</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SMLNET">SML.NET</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TILT">TILT</link>
</simpara>
</listitem>
</itemizedlist>
<section id="_not_actively_maintained">
<title>Not Actively Maintained</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.dcs.ed.ac.uk/home/edml/">Edinburgh ML</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="MLj">MLj</link>
</simpara>
</listitem>
<listitem>
<simpara>
MLWorks
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Poplog">Poplog</link>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cs.cornell.edu/Info/People/jgm/til.tar.Z">TIL</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="StandardMLPortability">
<title>StandardMLPortability</title>
<simpara>Technically, SML&#8217;97 as defined in the
<link linkend="DefinitionOfStandardML">Definition</link>
requires only a minimal initial basis, which, while including the
types <literal>int</literal>, <literal>real</literal>, <literal>char</literal>, and <literal>string</literal>, need have
no operations on those base types.  Hence, the only observable output
of an SML&#8217;97 program is termination or raising an exception.  Most SML
compilers should agree there, to the degree each agrees with the
Definition.  See <link linkend="UnresolvedBugs">UnresolvedBugs</link> for MLton&#8217;s very few corner cases.</simpara>
<simpara>Realistically, a program needs to make use of the
<link linkend="BasisLibrary">Basis Library</link>.
Within the Basis Library, there are numerous places where the behavior
is implementation dependent.  For a trivial example:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val _ = valOf (Int.maxInt)</programlisting>
<simpara>may either raise the <literal>Option</literal> exception (if
<literal>Int.maxInt == NONE</literal>) or may terminate normally.  The default
Int/Real/Word sizes are the biggest implementation dependent aspect;
so, one implementation may raise <literal>Overflow</literal> while another can
accommodate the result.  Also, maximum array and vector lengths are
implementation dependent.  Interfacing with the operating system is a
bit murky, and implementations surely differ in handling of errors
there.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="StandardMLTutorials">
<title>StandardMLTutorials</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.dcs.napier.ac.uk/course-notes/sml/manual.html">A Gentle Introduction to ML</ulink>.
Andrew Cummings.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.dcs.ed.ac.uk/home/stg/NOTES/">Programming in Standard ML '97: An Online Tutorial</ulink>.
Stephen Gilmore.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Harper11">Programming in Standard ML</link>.
Robert Harper.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Tofte96">Essentials of Standard ML Modules</link>.
Mads Tofte.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="References_Tofte09">Tips for Computer Scientists on Standard ML (Revised)</link>.
Mads Tofte.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="StaticSum">
<title>StaticSum</title>
<simpara>While SML makes it impossible to write functions whose types would
depend on the values of their arguments, or so called dependently
typed functions, it is possible, and arguably commonplace, to write
functions whose types depend on the types of their arguments.  Indeed,
the types of parametrically polymorphic functions like <literal>map</literal> and
<literal>foldl</literal> can be said to depend on the types of their arguments.  What
is less commonplace, however, is to write functions whose behavior
would depend on the types of their arguments.  Nevertheless, there are
several techniques for writing such functions.
<link linkend="TypeIndexedValues">Type-indexed values</link> and <link linkend="Fold">fold</link> are two such
techniques.  This page presents another such technique dubbed static
sums.</simpara>
<section id="_ordinary_sums">
<title>Ordinary Sums</title>
<simpara>Consider the sum type as defined below:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Sum = struct
   datatype ('a, 'b) t = INL of 'a | INR of 'b
end</programlisting>
<simpara>While a generic sum type such as defined above is very useful, it has
a number of limitations.  As an example, we could write the function
<literal>out</literal> to extract the value from a sum as follows:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun out (s : ('a, 'a) Sum.t) : 'a =
    case s
     of Sum.INL a =&gt; a
      | Sum.INR a =&gt; a</programlisting>
<simpara>As can be seen from the type of <literal>out</literal>, it is limited in the sense that
it requires both variants of the sum to have the same type.  So, <literal>out</literal>
cannot be used to extract the value of a sum of two different types,
such as the type <literal>(int, real) Sum.t</literal>.  As another example of a
limitation, consider the following attempt at a <literal>succ</literal> function:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun succ (s : (int, real) Sum.t) : ??? =
    case s
     of Sum.INL i =&gt; i + 1
      | Sum.INR r =&gt; Real.nextAfter (r, Real.posInf)</programlisting>
<simpara>The above definition of <literal>succ</literal> cannot be typed, because there is no
type for the codomain within SML.</simpara>
</section>
<section id="_static_sums">
<title>Static Sums</title>
<simpara>Interestingly, it is possible to define values <literal>inL</literal>, <literal>inR</literal>, and
<literal>match</literal> that satisfy the laws</simpara>
<screen>match (inL x) (f, g) = f x
match (inR x) (f, g) = g x</screen>
<simpara>and do not suffer from the same limitions.  The definitions are
actually quite trivial:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure StaticSum = struct
   fun inL x (f, _) = f x
   fun inR x (_, g) = g x
   fun match x = x
end</programlisting>
<simpara>Now, given the <literal>succ</literal> function defined as</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun succ s =
    StaticSum.match s
       (fn i =&gt; i + 1,
        fn r =&gt; Real.nextAfter (r, Real.posInf))</programlisting>
<simpara>we get</simpara>
<programlisting language="sml" linenumbering="unnumbered">succ (StaticSum.inL 1) = 2
succ (StaticSum.inR Real.maxFinite) = Real.posInf</programlisting>
<simpara>To better understand how this works, consider the following signature
for static sums:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure StaticSum :&gt; sig
   type ('dL, 'cL, 'dR, 'cR, 'c) t
   val inL : 'dL -&gt; ('dL, 'cL, 'dR, 'cR, 'cL) t
   val inR : 'dR -&gt; ('dL, 'cL, 'dR, 'cR, 'cR) t
   val match : ('dL, 'cL, 'dR, 'cR, 'c) t -&gt; ('dL -&gt; 'cL) * ('dR -&gt; 'cR) -&gt; 'c
end = struct
   type ('dL, 'cL, 'dR, 'cR, 'c) t = ('dL -&gt; 'cL) * ('dR -&gt; 'cR) -&gt; 'c
   open StaticSum
end</programlisting>
<simpara>Above, <literal>'d</literal> stands for domain and <literal>'c</literal> for codomain.  The key
difference between an ordinary sum type, like <literal>(int, real) Sum.t</literal>, and
a static sum type, like <literal>(int, real, real, int, real) StaticSum.t</literal>, is
that the ordinary sum type says nothing about the type of the result
of deconstructing a sum while the static sum type specifies the type.</simpara>
<simpara>With the sealed static sum module, we get the type</simpara>
<programlisting language="sml" linenumbering="unnumbered">val succ : (int, int, real, real, 'a) StaticSum.t -&gt; 'a</programlisting>
<simpara>for the previously defined <literal>succ</literal> function.  The type specifies that
<literal>succ</literal> maps a left <literal>int</literal> to an <literal>int</literal> and a right <literal>real</literal> to a <literal>real</literal>.
For example, the type of <literal>StaticSum.inL 1</literal> is
<literal>(int, 'cL, 'dR, 'cR, 'cL) StaticSum.t</literal>.  Unifying this with the
argument type of <literal>succ</literal> gives the type <literal>(int, int, real, real, int)
StaticSum.t -&gt; int</literal>.</simpara>
<simpara>The <literal>out</literal> function is quite useful on its own.  Here is how it can be
defined:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure StaticSum = struct
   open StaticSum
   val out : ('a, 'a, 'b, 'b, 'c) t -&gt; 'c =
    fn s =&gt; match s (fn x =&gt; x, fn x =&gt; x)
end</programlisting>
<simpara>Due to the value restriction, lack of first class polymorphism and
polymorphic recursion, the usefulness and convenience of static sums
is somewhat limited in SML.  So, don&#8217;t throw away the ordinary sum
type just yet.  Static sums can nevertheless be quite useful.</simpara>
<section id="_example_send_and_receive_with_argument_type_dependent_result_types">
<title>Example: Send and Receive with Argument Type Dependent Result Types</title>
<simpara>In some situations it would seem useful to define functions whose
result type would depend on some of the arguments.  Traditionally such
functions have been thought to be impossible in SML and the solution
has been to define multiple functions.  For example, the
<ulink url="http://www.standardml.org/Basis/socket.html"><literal>Socket</literal> structure</ulink> of the
Basis library defines 16 <literal>send</literal> and 16 <literal>recv</literal> functions.  In contrast,
the Net structure
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/sweeks/basic/unstable/net.sig"><literal>net.sig</literal></ulink>) of the
Basic library designed by Stephen Weeks defines only a single <literal>send</literal>
and a single <literal>receive</literal> and the result types of the functions depend on
their arguments.  The implementation
(<ulink url="https://github.com/MLton/mltonlib/blob/master/com/sweeks/basic/unstable/net.sml"><literal>net.sml</literal></ulink>) uses
static sums (with a slighly different signature:
<ulink url="https://github.com/MLton/mltonlib/blob/master/com/sweeks/basic/unstable/static-sum.sig"><literal>static-sum.sig</literal></ulink>).</simpara>
</section>
<section id="_example_picking_monad_results">
<title>Example: Picking Monad Results</title>
<simpara>Suppose that we need to write a parser that accepts a pair of integers
and returns their sum given a monadic parsing combinator library.  A
part of the signature of such library could look like this</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature PARSING = sig
   include MONAD
   val int : int t
   val lparen : unit t
   val rparen : unit t
   val comma : unit t
   (* ... *)
end</programlisting>
<simpara>where the <literal>MONAD</literal> signature could be defined as</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature MONAD = sig
   type 'a t
   val return : 'a -&gt; 'a t
   val &gt;&gt;= : 'a t * ('a -&gt; 'b t) -&gt; 'b t
end
infix &gt;&gt;=</programlisting>
<simpara>The straightforward, but tedious, way to write the desired parser is:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val p = lparen &gt;&gt;= (fn _ =&gt;
        int    &gt;&gt;= (fn x =&gt;
        comma  &gt;&gt;= (fn _ =&gt;
        int    &gt;&gt;= (fn y =&gt;
        rparen &gt;&gt;= (fn _ =&gt;
        return (x + y))))))</programlisting>
<simpara>In Haskell, the parser could be written using the <literal>do</literal> notation
considerably less verbosely as:</simpara>
<programlisting language="haskell" linenumbering="unnumbered">p = do { lparen ; x &lt;- int ; comma ; y &lt;- int ; rparen ; return $ x + y }</programlisting>
<simpara>SML doesn&#8217;t provide a <literal>do</literal> notation, so we need another solution.</simpara>
<simpara>Suppose we would have a "pick" notation for monads that would allows
us to write the parser as</simpara>
<programlisting language="sml" linenumbering="unnumbered">val p = `lparen ^ \int ^ `comma ^ \int ^ `rparen @ (fn x &amp; y =&gt; x + y)</programlisting>
<simpara>using four auxiliary combinators: <literal>&grave;</literal>, <literal>\</literal>, <literal>^</literal>, and <literal>@</literal>.</simpara>
<simpara>Roughly speaking</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>&grave;p</literal> means that the result of <literal>p</literal> is dropped,
</simpara>
</listitem>
<listitem>
<simpara>
<literal>\p</literal> means that the result of <literal>p</literal> is taken,
</simpara>
</listitem>
<listitem>
<simpara>
<literal>p ^ q</literal> means that results of <literal>p</literal> and <literal>q</literal> are taken as a product, and
</simpara>
</listitem>
<listitem>
<simpara>
<literal>p @ a</literal> means that the results of <literal>p</literal> are passed to the function <literal>a</literal> and that result is returned.
</simpara>
</listitem>
</itemizedlist>
<simpara>The difficulty is in implementing the concatenation combinator <literal>^</literal>.
The type of the result of the concatenation depends on the types of
the arguments.</simpara>
<simpara>Using static sums and the <link linkend="ProductType">product type</link>, the pick
notation for monads can be implemented as follows:</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor MkMonadPick (include MONAD) = let
   open StaticSum
in
   struct
      fun `a = inL (a &gt;&gt;= (fn _ =&gt; return ()))
      val \ = inR
      fun a @ f = out a &gt;&gt;= (return o f)
      fun a ^ b =
          (match b o match a)
             (fn a =&gt;
                 (fn b =&gt; inL (a &gt;&gt;= (fn _ =&gt; b)),
                  fn b =&gt; inR (a &gt;&gt;= (fn _ =&gt; b))),
              fn a =&gt;
                 (fn b =&gt; inR (a &gt;&gt;= (fn a =&gt; b &gt;&gt;= (fn _ =&gt; return a))),
                  fn b =&gt; inR (a &gt;&gt;= (fn a =&gt; b &gt;&gt;= (fn b =&gt; return (a &amp; b))))))
   end
end</programlisting>
<simpara>The above implementation is inefficient, however.  It uses many more
bind operations, <literal>&gt;&gt;=</literal>, than necessary.  That can be solved with an
additional level of abstraction:</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor MkMonadPick (include MONAD) = let
   open StaticSum
in
   struct
      fun `a = inL (fn b =&gt; a &gt;&gt;= (fn _ =&gt; b ()))
      fun \a = inR (fn b =&gt; a &gt;&gt;= b)
      fun a @ f = out a (return o f)
      fun a ^ b =
          (match b o match a)
             (fn a =&gt; (fn b =&gt; inL (fn c =&gt; a (fn () =&gt; b c)),
                       fn b =&gt; inR (fn c =&gt; a (fn () =&gt; b c))),
              fn a =&gt; (fn b =&gt; inR (fn c =&gt; a (fn a =&gt; b (fn () =&gt; c a))),
                       fn b =&gt; inR (fn c =&gt; a (fn a =&gt; b (fn b =&gt; c (a &amp; b))))))
   end
end</programlisting>
<simpara>After instantiating and opening either of the above monad pick
implementations, the previously given definition of <literal>p</literal> can be
compiled and results in a parser whose result is of type <literal>int</literal>.  Here
is a functor to test the theory:</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Test (Arg : PARSING) = struct
   local
      structure Pick = MkMonadPick (Arg)
      open Pick Arg
   in
      val p : int t =
          `lparen ^ \int ^ `comma ^ \int ^ `rparen @ (fn x &amp; y =&gt; x + y)
   end
end</programlisting>
</section>
</section>
<section id="_also_see_46">
<title>Also see</title>
<simpara>There are a number of related techniques.  Here are some of them.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Fold">Fold</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TypeIndexedValues">TypeIndexedValues</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="StephenWeeks">
<title>StephenWeeks</title>
<simpara>I live in the New York City area and work at <ulink url="http://janestcapital.com">Jane Street Capital</ulink>.</simpara>
<simpara>My <ulink url="http://sweeks.com/">home page</ulink>.</simpara>
<simpara>You can email me at <ulink url="mailto:sweeks@sweeks.com">sweeks@sweeks.com</ulink>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="StyleGuide">
<title>StyleGuide</title>
<simpara>These conventions are chosen so that inertia is towards modularity, code reuse and finding bugs early, <emphasis>not</emphasis> to save typing.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="SyntacticConventions">SyntacticConventions</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Subversion">
<title>Subversion</title>
<simpara><ulink url="http://subversion.apache.org/">Subversion</ulink> is a version control system.
The MLton project used Subversion to maintain its
<link linkend="Sources">source code</link>, but switched to <link linkend="Git">Git</link> on 20130308.</simpara>
<simpara>Here are some online Subversion resources.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://svnbook.red-bean.com">Version Control with Subversion</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SuccessorML">
<title>SuccessorML</title>
<simpara>The purpose of <ulink url="http://sml-family.org/successor-ml/">successor ML</ulink>, or
sML for short, is to provide a vehicle for the continued evolution of
ML, using Standard ML as a starting point. The intention is for
successor ML to be a living, evolving dialect of ML that is responsive
to community needs and advances in language design, implementation,
and semantics.</simpara>
<section id="_successorml_features_in_mlton">
<title>SuccessorML Features in MLton</title>
<simpara>The following SuccessorML features have been implemented in MLton.
The features are disabled by default, and may be enabled utilizing the
feature&#8217;s corresponding <link linkend="MLBasisAnnotations">ML Basis annotation</link>
which is listed directly after the feature name.  In addition, the
<literal>allowSuccessorML {false|true}</literal> annotation can be used to
simultaneously enable all of the features.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="SuccessorML_DoDecls" xreflabel="[SuccessorML_DoDecls]"/>
<literal>do</literal> Declarations: <literal>allowDoDecls {false|true}</literal>
</simpara>
<simpara>Allow a <literal>do <emphasis>exp</emphasis></literal> declaration form, which evaluates <emphasis>exp</emphasis> for its
side effects.  The following example uses a <literal>do</literal> declaration:</simpara>
<programlisting language="sml" linenumbering="unnumbered">do print "Hello world.\n"</programlisting>
<simpara>and is equivalent to:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val () = print "Hello world.\n"</programlisting>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_ExtendedConsts" xreflabel="[SuccessorML_ExtendedConsts]"/>
Extended Constants: <literal>allowExtendedConsts {false|true}</literal>
</simpara>
<simpara>Allow or disallow all of the extended constants features.  This is a
proxy for all of the following annotations.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="SuccessorML_ExtendedNumConsts" xreflabel="[SuccessorML_ExtendedNumConsts]"/>
Extended Numeric Constants: <literal>allowExtendedNumConsts {false|true}</literal>
</simpara>
<simpara>Allow underscores as a separator in numeric constants and allow binary
integer and word constants.</simpara>
<simpara>Underscores in a numeric constant must occur between digits and
consecutive underscores are allowed.</simpara>
<simpara>Binary integer constants use the prefix <literal>0b</literal> and binary word constants
use the prefix <literal>0wb</literal>.</simpara>
<simpara>The following example uses extended numeric constants (although it may
be incorrectly syntax highlighted):</simpara>
<programlisting language="sml" linenumbering="unnumbered">val pb = 0b10101
val nb = ~0b10_10_10
val wb = 0wb1010
val i = 4__327__829
val r = 6.022_140_9e23</programlisting>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_ExtendedTextConsts" xreflabel="[SuccessorML_ExtendedTextConsts]"/> Extended Text Constants: <literal>allowExtendedTextConsts {false|true}</literal>
</simpara>
<simpara>Allow characters with integer codes &ge; 128 and &le; 247 that
correspond to syntactically well-formed UTF-8 byte sequences in text
constants.</simpara>
<simpara>Any 1, 2, 3, or 4 byte sequence that can be properly decoded to a
binary number according to the UTF-8 encoding/decoding scheme is
allowed in a text constant (but invalid sequences are not explicitly
rejected) and denotes the corresponding sequence of characters with
integer codes &ge; 128 and &le; 247.  This feature enables "UTF-8
convenience" (but not comprehensive Unicode support); in particular,
it allows one to copy text from a browser and paste it into a string
constant in an editor and, furthermore, if the string is printed to a
terminal, then will (typically) appear as the original text.  The
following example uses UTF-8 byte sequences:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val s1 : String.string = "\240\159\130\161"
val s2 : String.string = "🂡"
val _ = print ("s1 --&gt; " ^ s1 ^ "\n")
val _ = print ("s2 --&gt; " ^ s2 ^ "\n")
val _ = print ("String.size s1 --&gt; " ^ Int.toString (String.size s1) ^ "\n")
val _ = print ("String.size s2 --&gt; " ^ Int.toString (String.size s2) ^ "\n")
val _ = print ("s1 = s2 --&gt; " ^ Bool.toString (s1 = s2) ^ "\n")</programlisting>
<simpara>and, when compiled and executed, will display:</simpara>
<screen>s1 --&gt; 🂡
s2 --&gt; 🂡
String.size s1 --&gt; 4
String.size s2 --&gt; 4
s1 = s2 --&gt; true</screen>
<simpara>Note that the <literal>String.string</literal> type corresponds to any sequence of
8-bit values, including invalid UTF-8 sequences; hence the string
constant <literal>"\192"</literal> (a UTF-8 leading byte with no UTF-8 continuation
byte) is valid.  Similarly, the <literal>Char.char</literal> type corresponds to a
single 8-bit value; hence the char constant <literal>#"α"</literal> is not valid, as
the text constant <literal>"α"</literal> denotes a sequence of two 8-bit values.</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_LineComments" xreflabel="[SuccessorML_LineComments]"/>
Line Comments: <literal>allowLineComments {false|true}</literal>
</simpara>
<simpara>Allow line comments beginning with the token <literal>(*)</literal>.  The following
example uses a line comment:</simpara>
<programlisting language="sml" linenumbering="unnumbered">(*) This is a line comment</programlisting>
<simpara>Line comments properly nest within block comments.  The following
example uses line comments nested within block comments:</simpara>
<programlisting language="sml" linenumbering="unnumbered">(*
val x = 4 (*) This is a line comment
*)

(*
val y = 5 (*) This is a line comment *)
*)</programlisting>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_OptBar" xreflabel="[SuccessorML_OptBar]"/>
Optional Pattern Bars: <literal>allowOptBar {false|true}</literal>
</simpara>
<simpara>Allow a bar to appear before the first match rule of a <literal>case</literal>, <literal>fn</literal>,
or <literal>handle</literal> expression, allow a bar to appear before the first
function-value binding of a <literal>fun</literal> declaration, and allow a bar to
appear before the first constructor binding or description of a
<literal>datatype</literal> declaration or specification.  The following example uses
leading bars in a <literal>datatype</literal> declaration, a <literal>fun</literal> declaration, and a
<literal>case</literal> expression:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t =
  | C
  | B
  | A

fun
  | f NONE = 0
  | f (SOME t) =
     (case t of
        | A =&gt; 1
        | B =&gt; 2
        | C =&gt; 3)</programlisting>
<simpara>By eliminating the special case of the first element, this feature
allows for simpler refactoring (e.g., sorting the lines of the
<literal>datatype</literal> declaration&#8217;s constructor bindings to put the constructors
in alphabetical order).</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_OptSemicolon" xreflabel="[SuccessorML_OptSemicolon]"/>
Optional Semicolons: <literal>allowOptSemicolon {false|true}</literal>
</simpara>
<simpara>Allow a semicolon to appear after the last expression in a sequence or
<literal>let</literal>-body expression.  The following example uses a trailing
semicolon in the body of a <literal>let</literal> expression:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun h z =
  let
    val x = 3 * z
  in
     f x ;
     g x ;
  end</programlisting>
<simpara>By eliminating the special case of the last element, this feature
allows for simpler refactoring.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_OrPats" xreflabel="[SuccessorML_OrPats]"/>
Disjunctive (Or) Patterns: <literal>allowOrPats {false|true}</literal>
</simpara>
<simpara>Allow disjunctive (a.k.a., "or") patterns of the form <literal><emphasis>pat<subscript>1</subscript></emphasis> |
<emphasis>pat<subscript>2</subscript></emphasis></literal>, which matches a value that matches either <literal><emphasis>pat<subscript>1</subscript></emphasis></literal> or
<literal><emphasis>pat<subscript>2</subscript></emphasis></literal>.  Disjunctive patterns have lower precedence than <literal>as</literal>
patterns and constraint patterns, much as <literal>orelse</literal> expressions have
lower precedence than <literal>andalso</literal> expressions and constraint
expressions.  Both sub-patterns of a disjunctive pattern must bind the
same variables with the same types.  The following example uses
disjunctive patterns:</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A of int | B of int | C of int | D of int * int | E of int * int

fun f t =
  case t of
     A x | B x | C x =&gt; x + 1
   | D (x, _) | E (_, x) =&gt; x * 2</programlisting>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_RecordPunExps" xreflabel="[SuccessorML_RecordPunExps]"/>
Record Punning Expressions: <literal>allowRecordPunExps {false|true}</literal>
</simpara>
<simpara>Allow record punning expressions, whereby an identifier <literal><emphasis>vid</emphasis></literal> as an
expression row in a record expression denotes the expression row
<literal><emphasis>vid</emphasis> = <emphasis>vid</emphasis></literal> (i.e., treating a label as a variable).  The following
example uses record punning expressions (and also record punning
patterns):</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun incB r =
  case r of {a, b, c} =&gt; {a, b = b + 1, c}</programlisting>
<simpara>and is equivalent to:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun incB r =
  case r of {a = a, b = b, c = c} =&gt; {a = a, b = b + 1, c = c}</programlisting>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_SigWithtype" xreflabel="[SuccessorML_SigWithtype]"/>
<literal>withtype</literal> in Signatures: <literal>allowSigWithtype {false|true}</literal>
</simpara>
<simpara>Allow <literal>withtype</literal> to modify a <literal>datatype</literal> specification in a signature.
The following example uses <literal>withtype</literal> in a signature (and also
<literal>withtype</literal> in a declaration):</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature STREAM =
  sig
    datatype 'a u = Nil | Cons of 'a * 'a t
    withtype 'a t = unit -&gt; 'a u
  end
structure Stream : STREAM =
  struct
    datatype 'a u = Nil | Cons of 'a * 'a t
    withtype 'a t = unit -&gt; 'a u
  end</programlisting>
<simpara>and is equivalent to:</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature STREAM =
  sig
    datatype 'a u = Nil | Cons of 'a * (unit -&gt; 'a u)
    type 'a t = unit -&gt; 'a u
  end
structure Stream : STREAM =
  struct
    datatype 'a u = Nil | Cons of 'a * (unit -&gt; 'a u)
    type 'a t = unit -&gt; 'a u
  end</programlisting>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_VectorExpsAndPats" xreflabel="[SuccessorML_VectorExpsAndPats]"/>
Vector Expressions and Patterns: <literal>allowVectorExpsAndPats {false|true}</literal>
</simpara>
<simpara>Allow or disallow vector expressions and vector patterns.  This is a
proxy for all of the following annotations.</simpara>
<itemizedlist>
<listitem>
<simpara>
<anchor id="SuccessorML_VectorExps" xreflabel="[SuccessorML_VectorExps]"/>
Vector Expressions: <literal>allowVectorExps {false|true}</literal>
</simpara>
<simpara>Allow vector expressions of the form <literal>#[<emphasis>exp<subscript>0</subscript></emphasis>, <emphasis>exp<subscript>1</subscript></emphasis>, &#8230;, <emphasis>exp<subscript>n-1</subscript></emphasis>]</literal> (where <emphasis>n ≥ 0</emphasis>).  The expression has type <literal><emphasis>τ</emphasis> vector</literal> when each expression <emphasis>exp<subscript>i</subscript></emphasis> has type <literal><emphasis>τ</emphasis></literal>.</simpara>
</listitem>
<listitem>
<simpara>
<anchor id="SuccessorML_VectorPats" xreflabel="[SuccessorML_VectorPats]"/>
Vector Patterns: <literal>allowVectorPats {false|true}</literal>
</simpara>
<simpara>Allow vector patterns of the form <literal>#[<emphasis>pat<subscript>0</subscript></emphasis>, <emphasis>pat<subscript>1</subscript></emphasis>, &#8230;, <emphasis>pat<subscript>n-1</subscript></emphasis>]</literal> (where <emphasis>n ≥ 0</emphasis>).  The pattern matches values of type <literal><emphasis>τ</emphasis> vector</literal> when each pattern <emphasis>pat<subscript>i</subscript></emphasis> matches values of type <literal><emphasis>τ</emphasis></literal>.</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SureshJagannathan">
<title>SureshJagannathan</title>
<simpara>I am an Associate Professor at the <ulink url="http://www.cs.purdue.edu/">Department of Computer Science</ulink> at Purdue University.
My research focus is in programming language design and implementation, concurrency,
and distributed systems.  I am interested in various aspects of MLton, mostly related to (in no particular order): (1) control-flow analysis (2) representation
strategies (e.g., flattening), (3) IR formats, and (4) extensions for distributed programming.</simpara>
<simpara>Please see my <ulink url="http://www.cs.purdue.edu/homes/suresh/index.html">Home page</ulink> for more details.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Swerve">
<title>Swerve</title>
<simpara><ulink url="http://ftp.sun.ac.za/ftp/mirrorsites/ocaml/Systems_programming/book/c3253.html">Swerve</ulink>
is an HTTP server written in SML, originally developed with SML/NJ.
<link linkend="RayRacine">RayRacine</link> ported Swerve to MLton in January 2005.</simpara>
<simpara><ulink url="guide/Swerve.attachments/swerve.tar.bz2">Download</ulink> the port.</simpara>
<simpara>Excerpt from the included <literal>README</literal>:</simpara>
<blockquote>
<simpara>Total testing of this port consisted of a successful compile, startup,
and serving one html page with one gif image.  Given that the original
code was throughly designed and implemented in a thoughtful manner and
I expect it is quite usable modulo a few minor bugs introduced by my
porting effort.</simpara>
</blockquote>
<simpara>Swerve is described in <link linkend="References_Shipman02">Shipman02</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SXML">
<title>SXML</title>
<simpara><link linkend="SXML">SXML</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from <link linkend="XML">XML</link> by
<link linkend="Monomorphise">Monomorphise</link>, optimized by <link linkend="SXMLSimplify">SXMLSimplify</link>, and translated by
<link linkend="ClosureConvert">ClosureConvert</link> to <link linkend="SSA">SSA</link>.</simpara>
<section id="_description_59">
<title>Description</title>
<simpara>SXML is a simply-typed version of <link linkend="XML">XML</link>.</simpara>
</section>
<section id="_implementation_64">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/sxml.sig"><literal>sxml.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/sxml.fun"><literal>sxml.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/sxml-tree.sig"><literal>sxml-tree.sig</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_7">
<title>Type Checking</title>
<simpara><link linkend="SXML">SXML</link> shares the type checker for <link linkend="XML">XML</link>.</simpara>
</section>
<section id="_details_and_notes_62">
<title>Details and Notes</title>
<simpara>There are only two differences between <link linkend="XML">XML</link> and <link linkend="SXML">SXML</link>.  First,
<link linkend="SXML">SXML</link> <literal>val</literal>, <literal>fun</literal>, and <literal>datatype</literal> declarations always have an
empty list of type variables.  Second, <link linkend="SXML">SXML</link> variable references
always have an empty list of type arguments.  Constructors uses can
only have a nonempty list of type arguments if the constructor is a
primitive.</simpara>
<simpara>Although we could rely on the type system to enforce these constraints
by parameterizing the <link linkend="XML">XML</link> signature, <link linkend="StephenWeeks">StephenWeeks</link> did so in a
previous version of the compiler, and the software engineering gains
were not worth the effort.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SXMLShrink">
<title>SXMLShrink</title>
<simpara>SXMLShrink is an optimization pass for the <link linkend="SXML">SXML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SXMLSimplify">SXMLSimplify</link>.</simpara>
<section id="_description_60">
<title>Description</title>
<simpara>This pass performs optimizations based on a reduction system.</simpara>
</section>
<section id="_implementation_65">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/shrink.sig"><literal>shrink.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/shrink.fun"><literal>shrink.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_63">
<title>Details and Notes</title>
<simpara><link linkend="SXML">SXML</link> shares the <link linkend="XMLShrink">XMLShrink</link> simplifier.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="SXMLSimplify">
<title>SXMLSimplify</title>
<simpara>The optimization passes for the <link linkend="SXML">SXML</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> are
collected and controlled by the <literal>SxmlSimplify</literal> functor
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/sxml-simplify.sig"><literal>sxml-simplify.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/sxml-simplify.fun"><literal>sxml-simplify.fun</literal></ulink>).</simpara>
<simpara>The following optimization passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Polyvariance">Polyvariance</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="SXMLShrink">SXMLShrink</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The following implementation passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ImplementExceptions">ImplementExceptions</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ImplementSuffix">ImplementSuffix</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The following optimization passes are not implemented, but might prove useful:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Uncurry">Uncurry</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="LambdaLift">LambdaLift</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The optimization passes can be controlled from the command-line by the options</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-diag-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep diagnostic info for pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-disable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;skip optimization pass (if normally performed)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-enable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;perform optimization pass (if normally skipped)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-keep-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep the results of pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-sxml-passes &lt;passes&gt;</literal>&#8201;&#8212;&#8201;sxml optimization passes
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="SyntacticConventions">
<title>SyntacticConventions</title>
<simpara>Here are a number of syntactic conventions useful for programming in
SML.</simpara>
<section id="_general">
<title>General</title>
<itemizedlist>
<listitem>
<simpara>
A line of code never exceeds 80 columns.
</simpara>
</listitem>
<listitem>
<simpara>
Only split a syntactic entity across multiple lines if it doesn&#8217;t fit on one line within 80 columns.
</simpara>
</listitem>
<listitem>
<simpara>
Use alphabetical order wherever possible.
</simpara>
</listitem>
<listitem>
<simpara>
Avoid redundant parentheses.
</simpara>
</listitem>
<listitem>
<simpara>
When using <literal>:</literal>, there is no space before the colon, and a single space after it.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_identifiers">
<title>Identifiers</title>
<itemizedlist>
<listitem>
<simpara>
Variables, record labels and type constructors begin with and use
small letters, using capital letters to separate words.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">cost
maxValue</programlisting>
</listitem>
<listitem>
<simpara>
Variables that represent collections of objects (lists, arrays,
vectors, &#8230;) are often suffixed with an <literal>s</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">xs
employees</programlisting>
</listitem>
<listitem>
<simpara>
Constructors, structure identifiers, and functor identifiers begin
with a capital letter.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">Queue
LinkedList</programlisting>
</listitem>
<listitem>
<simpara>
Signature identifiers are in all capitals, using <literal>_</literal> to separate
words.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">LIST
BINARY_HEAP</programlisting>
</listitem>
</itemizedlist>
</section>
<section id="_types_2">
<title>Types</title>
<itemizedlist>
<listitem>
<simpara>
Alphabetize record labels.  In a record type, there are spaces after
colons and commas, but not before colons or commas, or at the
delimiters <literal>{</literal> and <literal>}</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">{bar: int, foo: int}</programlisting>
</listitem>
<listitem>
<simpara>
Only split a record type across multiple lines if it doesn&#8217;t fit on
one line. If a record type must be split over multiple lines, put one
field per line.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">{bar: int,
 foo: real * real,
 zoo: bool}</programlisting>
</listitem>
<listitem>
<simpara>
In a tuple type, there are spaces before and after each <literal>*</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">int * bool * real</programlisting>
</listitem>
<listitem>
<simpara>
Only split a tuple type across multiple lines if it doesn&#8217;t fit on
one line.  In a tuple type split over multiple lines, there is one
type per line, and the <literal>*</literal>-s go at the beginning of the lines.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">int
* bool
* real</programlisting>
<simpara>It may also be useful to parenthesize to make the grouping more
apparent.</simpara>
<programlisting language="sml" linenumbering="unnumbered">(int
 * bool
 * real)</programlisting>
</listitem>
<listitem>
<simpara>
In an arrow type split over multiple lines, put the arrow at the
beginning of its line.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">int * real
-&gt; bool</programlisting>
<simpara>It may also be useful to parenthesize to make the grouping more
apparent.</simpara>
<programlisting language="sml" linenumbering="unnumbered">(int * real
 -&gt; bool)</programlisting>
</listitem>
<listitem>
<simpara>
Avoid redundant parentheses.
</simpara>
</listitem>
<listitem>
<simpara>
Arrow types associate to the right, so write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">a -&gt; b -&gt; c</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered">a -&gt; (b -&gt; c)</programlisting>
</listitem>
<listitem>
<simpara>
Type constructor application associates to the left, so write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">int ref list</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered">(int ref) list</programlisting>
</listitem>
<listitem>
<simpara>
Type constructor application binds more tightly than a tuple type,
so write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">int list * bool list</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered">(int list) * (bool list)</programlisting>
</listitem>
<listitem>
<simpara>
Tuple types bind more tightly than arrow types, so write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">int * bool -&gt; real</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered">(int * bool) -&gt; real</programlisting>
</listitem>
</itemizedlist>
</section>
<section id="_core">
<title>Core</title>
<itemizedlist>
<listitem>
<simpara>
A core expression or declaration split over multiple lines does not
contain any blank lines.
</simpara>
</listitem>
<listitem>
<simpara>
A record field selector has no space between the <literal>#</literal> and the record
label.  So, write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">#foo</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered"># foo</programlisting>
</listitem>
<listitem>
<simpara>
A tuple has a space after each comma, but not before, and not at the
delimiters <literal>(</literal> and <literal>)</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">(e1, e2, e3)</programlisting>
</listitem>
<listitem>
<simpara>
A tuple split over multiple lines has one element per line, and the
commas go at the end of the lines.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">(e1,
 e2,
 e3)</programlisting>
</listitem>
<listitem>
<simpara>
A list has a space after each comma, but not before, and not at the
delimiters <literal>[</literal> and <literal>]</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">[e1, e2, e3]</programlisting>
</listitem>
<listitem>
<simpara>
A list split over multiple lines has one element per line, and the
commas at the end of the lines.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">[e1,
 e2,
 e3]</programlisting>
</listitem>
<listitem>
<simpara>
A record has spaces before and after <literal>=</literal>, a space after each comma,
but not before, and not at the delimiters <literal>{</literal> and <literal>}</literal>.  Field names
appear in alphabetical order.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">{bar = 13, foo = true}</programlisting>
</listitem>
<listitem>
<simpara>
A sequence expression has a space after each semicolon, but not before.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">(e1; e2; e3)</programlisting>
</listitem>
<listitem>
<simpara>
A sequence expression split over multiple lines has one expression
per line, and the semicolons at the beginning of lines.  Lisp and
Scheme programmers may find this hard to read at first.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">(e1
 ; e2
 ; e3)</programlisting>
<simpara><emphasis>Rationale</emphasis>: this makes it easy to visually spot the beginning of each
expression, which becomes more valuable as the expressions themselves
are split across multiple lines.</simpara>
</listitem>
<listitem>
<simpara>
An application expression has a space between the function and the
argument.  There are no parens unless the argument is a tuple (in
which case the parens are really part of the tuple, not the
application).
</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a
f (a1, a2, a3)</programlisting>
</listitem>
<listitem>
<simpara>
Avoid redundant parentheses.  Application associates to left, so
write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">f a1 a2 a3</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered">((f a1) a2) a3</programlisting>
</listitem>
<listitem>
<simpara>
Infix operators have a space before and after the operator.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">x + y
x * y - z</programlisting>
</listitem>
<listitem>
<simpara>
Avoid redundant parentheses.  Use <link linkend="OperatorPrecedence">OperatorPrecedence</link>.  So, write
</simpara>
<programlisting language="sml" linenumbering="unnumbered">x + y * z</programlisting>
<simpara>not</simpara>
<programlisting language="sml" linenumbering="unnumbered">x + (y * z)</programlisting>
</listitem>
<listitem>
<simpara>
An <literal>andalso</literal> expression split over multiple lines has the <literal>andalso</literal>
at the beginning of subsequent lines.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">e1
andalso e2
andalso e3</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>case</literal> expression is indented as follows
</simpara>
<programlisting language="sml" linenumbering="unnumbered">case e1 of
   p1 =&gt; e1
 | p2 =&gt; e2
 | p3 =&gt; e3</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>datatype</literal>'s constructors are alphabetized.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B | C</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>datatype</literal> declaration has a space before and after each <literal>|</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of int | C</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>datatype</literal> split over multiple lines has one constructor per line,
with the <literal>|</literal> at the beginning of lines and the constructors beginning
3 columns to the right of the <literal>datatype</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t =
   A
 | B
 | C</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>fun</literal> declaration may start its body on the subsequent line,
indented 3 spaces.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f x y =
   let
      val z = x + y + z
   in
      z
   end</programlisting>
</listitem>
<listitem>
<simpara>
An <literal>if</literal> expression is indented as follows.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">if e1
   then e2
else e3</programlisting>
</listitem>
<listitem>
<simpara>
A sequence of <literal>if</literal>-<literal>then</literal>-<literal>else</literal>-s is indented as follows.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">if e1
   then e2
else if e3
   then e4
else if e5
   then e6
else e7</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>let</literal> expression has the <literal>let</literal>, <literal>in</literal>, and <literal>end</literal> on their own
lines, starting in the same column.  Declarations and the body are
indented 3 spaces.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">let
   val x = 13
   val y = 14
in
   x + y
end</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>local</literal> declaration has the <literal>local</literal>, <literal>in</literal>, and <literal>end</literal> on their own
lines, starting in the same column.  Declarations are indented 3
spaces.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
   val x = 13
in
   val y = x
end</programlisting>
</listitem>
<listitem>
<simpara>
An <literal>orelse</literal> expression split over multiple lines has the <literal>orelse</literal> at
the beginning of subsequent lines.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">e1
orelse e2
orelse e3</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>val</literal> declaration has a space before and after the <literal>=</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val p = e</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>val</literal> declaration can start the expression on the subsequent line,
indented 3 spaces.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val p =
   if e1 then e2 else e3</programlisting>
</listitem>
</itemizedlist>
</section>
<section id="_signatures">
<title>Signatures</title>
<itemizedlist>
<listitem>
<simpara>
A <literal>signature</literal> declaration is indented as follows.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature FOO =
   sig
      val x: int
   end</programlisting>
<simpara><emphasis>Exception</emphasis>: a signature declaration in a file to itself can omit the
indentation to save horizontal space.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature FOO =
sig

val x: int

end</programlisting>
<simpara>In this case, there should be a blank line after the <literal>sig</literal> and before
the <literal>end</literal>.</simpara>
</listitem>
<listitem>
<simpara>
A <literal>val</literal> specification has a space after the colon, but not before.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x: int</programlisting>
<simpara><emphasis>Exception</emphasis>: in the case of operators (like <literal>+</literal>), there is a space
before the colon to avoid lexing the colon as part of the operator.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val + : t * t -&gt; t</programlisting>
</listitem>
<listitem>
<simpara>
Alphabetize specifications in signatures.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">sig
   val x: int
   val y: bool
end</programlisting>
</listitem>
</itemizedlist>
</section>
<section id="_structures">
<title>Structures</title>
<itemizedlist>
<listitem>
<simpara>
A <literal>structure</literal> declaration has a space on both sides of the <literal>=</literal>.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Foo = Bar</programlisting>
</listitem>
<listitem>
<simpara>
A <literal>structure</literal> declaration split over multiple lines is indented as
follows.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S =
   struct
      val x = 13
   end</programlisting>
<simpara><emphasis>Exception</emphasis>: a structure declaration in a file to itself can omit the
indentation to save horizontal space.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S =
struct

val x = 13

end</programlisting>
<simpara>In this case, there should be a blank line after the <literal>struct</literal> and
before the <literal>end</literal>.</simpara>
</listitem>
<listitem>
<simpara>
Declarations in a <literal>struct</literal> are separated by blank lines.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">struct
   val x =
      let
         y = 13
      in
         y + 1
      end

   val z = 14
end</programlisting>
</listitem>
</itemizedlist>
</section>
<section id="_functors">
<title>Functors</title>
<itemizedlist>
<listitem>
<simpara>
A <literal>functor</literal> declaration has spaces after each <literal>:</literal> (or <literal>:&gt;</literal>) but not
before, and a space before and after the <literal>=</literal>.  It is indented as
follows.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Foo (S: FOO_ARG): FOO =
   struct
       val x = S.x
   end</programlisting>
<simpara><emphasis>Exception</emphasis>: a functor declaration in a file to itself can omit the
indentation to save horizontal space.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Foo (S: FOO_ARG): FOO =
struct

val x = S.x

end</programlisting>
<simpara>In this case, there should be a blank line after the <literal>struct</literal>
and before the <literal>end</literal>.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Talk">
<title>Talk</title>
<section id="_the_mlton_standard_ml_compiler">
<title>The MLton Standard ML Compiler</title>
<simpara><emphasis role="strong">Henry Cejtin, Matthew Fluet, Suresh Jagannathan, Stephen Weeks</emphasis></simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkStandardML">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkDiveIn">
<title>TalkDiveIn</title>
<section id="_dive_in">
<title>Dive In</title>
<itemizedlist>
<listitem>
<simpara>
to <link linkend="Development">Development</link>
</simpara>
</listitem>
<listitem>
<simpara>
to <link linkend="Documentation">Documentation</link>
</simpara>
</listitem>
<listitem>
<simpara>
to <link linkend="Download">Download</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkMLtonHistory">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkFolkLore">
<title>TalkFolkLore</title>
<section id="_folk_lore">
<title>Folk Lore</title>
<itemizedlist>
<listitem>
<simpara>
Defunctorization and monomorphisation are feasible
</simpara>
</listitem>
<listitem>
<simpara>
Global control-flow analysis is feasible
</simpara>
</listitem>
<listitem>
<simpara>
Early closure conversion is feasible
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkWholeProgram">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkMLtonFeatures">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkFromSMLTo">
<title>TalkFromSMLTo</title>
<section id="_from_standard_ml_to_s_t_f_o_il">
<title>From Standard ML to S-T F-O IL</title>
<itemizedlist>
<listitem>
<simpara>
What issues arise when translating from Standard ML into an intermediate language?
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkMLtonApproach">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkHowModules">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkHowHigherOrder">
<title>TalkHowHigherOrder</title>
<section id="_higher_order_functions">
<title>Higher-order Functions</title>
<itemizedlist>
<listitem>
<simpara>
How does one represent SML&#8217;s higher-order functions?
</simpara>
</listitem>
<listitem>
<simpara>
MLton&#8217;s answer: defunctionalize
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara>See <link linkend="ClosureConvert">ClosureConvert</link>.</simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkMLtonApproach">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkWholeProgram">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkHowModules">
<title>TalkHowModules</title>
<section id="_modules">
<title>Modules</title>
<itemizedlist>
<listitem>
<simpara>
How does one represent SML&#8217;s modules?
</simpara>
</listitem>
<listitem>
<simpara>
MLton&#8217;s answer: defunctorize
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara>See <link linkend="Elaborate">Elaborate</link>.</simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkFromSMLTo">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkHowPolymorphism">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkHowPolymorphism">
<title>TalkHowPolymorphism</title>
<section id="_polymorphism">
<title>Polymorphism</title>
<itemizedlist>
<listitem>
<simpara>
How does one represent SML&#8217;s polymorphism?
</simpara>
</listitem>
<listitem>
<simpara>
MLton&#8217;s answer: monomorphise
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara>See <link linkend="Monomorphise">Monomorphise</link>.</simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkHowModules">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkHowHigherOrder">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkMLtonApproach">
<title>TalkMLtonApproach</title>
<section id="_mlton_8217_s_approach">
<title>MLton&#8217;s Approach</title>
<itemizedlist>
<listitem>
<simpara>
whole-program optimization using a simply-typed, first-order intermediate language
</simpara>
</listitem>
<listitem>
<simpara>
ensures programs are not penalized for exploiting abstraction and modularity
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkStandardML">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkFromSMLTo">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkMLtonFeatures">
<title>TalkMLtonFeatures</title>
<section id="_mlton_features">
<title>MLton Features</title>
<itemizedlist>
<listitem>
<simpara>
Supports full Standard ML language and Basis Library
</simpara>
</listitem>
<listitem>
<simpara>
Generates standalone executables
</simpara>
</listitem>
<listitem>
<simpara>
Extensions
</simpara>
<itemizedlist>
<listitem>
<simpara>
Foreign function interface (SML to C, C to SML)
</simpara>
</listitem>
<listitem>
<simpara>
ML Basis system for programming in the very large
</simpara>
</listitem>
<listitem>
<simpara>
Extension libraries
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara>See <link linkend="Features">Features</link>.</simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkFolkLore">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkMLtonHistory">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkMLtonHistory">
<title>TalkMLtonHistory</title>
<section id="_mlton_history">
<title>MLton History</title>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="25*"/>
<colspec colname="col_2" colwidth="75*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara>April 1997</simpara></entry>
<entry align="left" valign="top"><simpara>Stephen Weeks wrote a defunctorizer for SML/NJ</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Aug. 1997</simpara></entry>
<entry align="left" valign="top"><simpara>Begin independent compiler (<literal>smlc</literal>)</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Oct. 1997</simpara></entry>
<entry align="left" valign="top"><simpara>Monomorphiser</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Nov. 1997</simpara></entry>
<entry align="left" valign="top"><simpara>Polyvariant higher-order control-flow analysis (10,000 lines)</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>March 1999</simpara></entry>
<entry align="left" valign="top"><simpara>First release of MLton (48,006 lines)</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Jan. 2002</simpara></entry>
<entry align="left" valign="top"><simpara>MLton at 102,541 lines</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Jan. 2003</simpara></entry>
<entry align="left" valign="top"><simpara>MLton at 112,204 lines</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Jan. 2004</simpara></entry>
<entry align="left" valign="top"><simpara>MLton at 122,299 lines</simpara></entry>
</row>
<row>
<entry align="left" valign="top"><simpara>Nov. 2004</simpara></entry>
<entry align="left" valign="top"><simpara>MLton at 141,311 lines</simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara>See <link linkend="History">History</link>.</simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkMLtonFeatures">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkDiveIn">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkStandardML">
<title>TalkStandardML</title>
<section id="_standard_ml">
<title>Standard ML</title>
<itemizedlist>
<listitem>
<simpara>
a high-level language makes
</simpara>
<itemizedlist>
<listitem>
<simpara>
a programmer&#8217;s life easier
</simpara>
</listitem>
<listitem>
<simpara>
a compiler writer&#8217;s life harder
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
perceived overheads of features discourage their use
</simpara>
<itemizedlist>
<listitem>
<simpara>
higher-order functions
</simpara>
</listitem>
<listitem>
<simpara>
polymorphic datatypes
</simpara>
</listitem>
<listitem>
<simpara>
separate modules
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara>Also see <link linkend="StandardML">Standard ML</link>.</simpara>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="Talk">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkMLtonApproach">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkTemplate">
<title>TalkTemplate</title>
<section id="_title">
<title>Title</title>
<itemizedlist>
<listitem>
<simpara>
Bullet
</simpara>
</listitem>
<listitem>
<simpara>
Bullet
</simpara>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="ZZZPrev">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="ZZZNext">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TalkWholeProgram">
<title>TalkWholeProgram</title>
<section id="_whole_program_compiler">
<title>Whole Program Compiler</title>
<itemizedlist>
<listitem>
<simpara>
Each of these techniques requires whole-program analysis
</simpara>
</listitem>
<listitem>
<simpara>
But, additional benefits:
</simpara>
<itemizedlist>
<listitem>
<simpara>
eliminate (some) variability in programming styles
</simpara>
</listitem>
<listitem>
<simpara>
specialize representations
</simpara>
</listitem>
<listitem>
<simpara>
simplifies and improves runtime system
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?>
&#160;<?asciidoc-br?></simpara>
<simpara><?asciidoc-hr?></simpara>
<informaltable
frame="all"
rowsep="1" colsep="1"
>
<tgroup cols="2">
<colspec colname="col_1" colwidth="50*"/>
<colspec colname="col_2" colwidth="50*"/>
<tbody>
<row>
<entry align="left" valign="top"><simpara><link linkend="TalkHowHigherOrder">Prev</link></simpara></entry>
<entry align="right" valign="top"><simpara><link linkend="TalkFolkLore">Next</link></simpara></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TILT">
<title>TILT</title>
<simpara><ulink url="http://www.cs.cornell.edu/home/jgm/tilt.html">TILT</ulink> is a
<link linkend="StandardMLImplementations">Standard ML implementation</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="TipsForWritingConciseSML">
<title>TipsForWritingConciseSML</title>
<simpara>SML is a rich enough language that there are often several ways to
express things.  This page contains miscellaneous tips (ideas not
rules) for writing concise SML.  The metric that we are interested in
here is the number of tokens or words (rather than the number of
lines, for example).</simpara>
<section id="_datatypes_in_signatures">
<title>Datatypes in Signatures</title>
<simpara>A seemingly frequent source of repetition in SML is that of datatype
definitions in signatures and structures.  Actually, it isn&#8217;t
repetition at all.  A datatype specification in a signature, such as,</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature EXP = sig
   datatype exp = Fn of id * exp | App of exp * exp | Var of id
end</programlisting>
<simpara>is just a specification of a datatype that may be matched by multiple
(albeit identical) datatype declarations.  For example, in</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure AnExp : EXP = struct
   datatype exp = Fn of id * exp | App of exp * exp | Var of id
end

structure AnotherExp : EXP = struct
   datatype exp = Fn of id * exp | App of exp * exp | Var of id
end</programlisting>
<simpara>the types <literal>AnExp.exp</literal> and <literal>AnotherExp.exp</literal> are two distinct types.  If
such <link linkend="GenerativeDatatype">generativity</link> isn&#8217;t desired or needed, you
can avoid the repetition:</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Exp = struct
   datatype exp = Fn of id * exp | App of exp * exp | Var of id
end

signature EXP = sig
   datatype exp = datatype Exp.exp
end

structure Exp : EXP = struct
   open Exp
end</programlisting>
<simpara>Keep in mind that this isn&#8217;t semantically equivalent to the original.</simpara>
</section>
<section id="_clausal_function_definitions">
<title>Clausal Function Definitions</title>
<simpara>The syntax of clausal function definitions is rather repetitive.  For
example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun isSome NONE = false
  | isSome (SOME _) = true</programlisting>
<simpara>is more verbose than</simpara>
<programlisting language="sml" linenumbering="unnumbered">val isSome =
 fn NONE =&gt; false
  | SOME _ =&gt; true</programlisting>
<simpara>For recursive functions the break-even point is one clause higher.  For example,</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun fib 0 = 0
  | fib 1 = 1
  | fib n = fib (n-1) + fib (n-2)</programlisting>
<simpara>isn&#8217;t less verbose than</simpara>
<programlisting language="sml" linenumbering="unnumbered">val rec fib =
 fn 0 =&gt; 0
  | 1 =&gt; 1
  | n =&gt; fib (n-1) + fib (n-2)</programlisting>
<simpara>It is quite often the case that a curried function primarily examines
just one of its arguments.  Such functions can be written particularly
concisely by making the examined argument last.  For example, instead
of</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun eval (Fn (v, b)) env =&gt; ...
  | eval (App (f, a) env =&gt; ...
  | eval (Var v) env =&gt; ...</programlisting>
<simpara>consider writing</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun eval env =
 fn Fn (v, b) =&gt; ...
  | App (f, a) =&gt; ...
  | Var v =&gt; ...</programlisting>
</section>
<section id="_parentheses">
<title>Parentheses</title>
<simpara>It is a good idea to avoid using lots of irritating superfluous
parentheses.  An important rule to know is that prefix function
application in SML has higher precedence than any infix operator.  For
example, the outer parentheses in</simpara>
<programlisting language="sml" linenumbering="unnumbered">(square (5 + 1)) + (square (5 * 2))</programlisting>
<simpara>are superfluous.</simpara>
<simpara>People trained in other languages often use superfluous parentheses in
a number of places.  In particular, the parentheses in the following
examples are practically always superfluous and are best avoided:</simpara>
<programlisting language="sml" linenumbering="unnumbered">if (condition) then ... else ...
while (condition) do ...</programlisting>
<simpara>The same basically applies to case expressions:</simpara>
<programlisting language="sml" linenumbering="unnumbered">case (expression) of ...</programlisting>
<simpara>It is not uncommon to match a tuple of two or more values:</simpara>
<programlisting language="sml" linenumbering="unnumbered">case (a, b) of
   (A1, B1) =&gt; ...
 | (A2, B2) =&gt; ...</programlisting>
<simpara>Such case expressions can be written more concisely with an
<link linkend="ProductType">infix product constructor</link>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">case a &amp; b of
   A1 &amp; B1 =&gt; ...
 | A2 &amp; B2 =&gt; ...</programlisting>
</section>
<section id="_conditionals">
<title>Conditionals</title>
<simpara>Repeated sequences of conditionals such as</simpara>
<programlisting language="sml" linenumbering="unnumbered">if x &lt; y then ...
else if x = y then ...
else ...</programlisting>
<simpara>can often be written more concisely as case expressions such as</simpara>
<programlisting language="sml" linenumbering="unnumbered">case Int.compare (x, y) of
   LESS =&gt; ...
 | EQUAL =&gt; ...
 | GREATER =&gt; ...</programlisting>
<simpara>For a custom comparison, you would then define an appropriate datatype
and a reification function.  An alternative to using datatypes is to
use dispatch functions</simpara>
<programlisting language="sml" linenumbering="unnumbered">comparing (x, y)
{lt = fn () =&gt; ...,
 eq = fn () =&gt; ...,
 gt = fn () =&gt; ...}</programlisting>
<simpara>where</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun comparing (x, y) {lt, eq, gt} =
    (case Int.compare (x, y) of
        LESS =&gt; lt
      | EQUAL =&gt; eq
      | GREATER =&gt; gt) ()</programlisting>
<simpara>An advantage is that no datatype definition is needed.  A disadvantage
is that you can&#8217;t combine multiple dispatch results easily.</simpara>
</section>
<section id="_command_query_fusion">
<title>Command-Query Fusion</title>
<simpara>Many are familiar with the
<ulink url="http://en.wikipedia.org/wiki/Command-Query_Separation">Command-Query
Separation Principle</ulink>.  Adhering to the principle, a signature for an
imperative stack might contain specifications</simpara>
<programlisting language="sml" linenumbering="unnumbered">val isEmpty : 'a t -&gt; bool
val pop : 'a t -&gt; 'a</programlisting>
<simpara>and use of a stack would look like</simpara>
<programlisting language="sml" linenumbering="unnumbered">if isEmpty stack
then ... pop stack ...
else ...</programlisting>
<simpara>or, when the element needs to be named,</simpara>
<programlisting language="sml" linenumbering="unnumbered">if isEmpty stack
then let val elem = pop stack in ... end
else ...</programlisting>
<simpara>For efficiency, correctness, and conciseness, it is often better to
combine the query and command and return the result as an option:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val pop : 'a t -&gt; 'a option</programlisting>
<simpara>A use of a stack would then look like this:</simpara>
<programlisting language="sml" linenumbering="unnumbered">case pop stack of
   NONE =&gt; ...
 | SOME elem =&gt; ...</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ToMachine">
<title>ToMachine</title>
<simpara><link linkend="ToMachine">ToMachine</link> is a translation pass from the <link linkend="RSSA">RSSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="Machine">Machine</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_61">
<title>Description</title>
<simpara>This pass converts from a <link linkend="RSSA">RSSA</link> program into a <link linkend="Machine">Machine</link> program.</simpara>
<simpara>It uses <link linkend="AllocateRegisters">AllocateRegisters</link>, <link linkend="Chunkify">Chunkify</link>, and <link linkend="ParallelMove">ParallelMove</link>.</simpara>
</section>
<section id="_implementation_66">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/backend.sig"><literal>backend.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/backend.fun"><literal>backend.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_64">
<title>Details and Notes</title>
<simpara>Because the MLton runtime system is shared by all <link linkend="Codegen">codegens</link>, it is most
convenient to decide on stack layout <emphasis>before</emphasis> any <link linkend="Codegen">codegen</link> takes over.
In particular, we compute all the stack frame info for each <link linkend="RSSA">RSSA</link>
function, including stack size, <link linkend="GarbageCollection">garbage collector</link>
masks for each frame, etc.  To do so, the <link linkend="Machine">Machine</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> imagines an abstract machine with an infinite
number of (pseudo-)registers of every size.  A liveness analysis
determines, for each variable, whether or not it is live across a
point where the runtime system might take over (for example, any
garbage collection point) or a non-tail call to another <link linkend="RSSA">RSSA</link>
function.  Those that are live go on the stack, while those that
aren&#8217;t live go into psuedo-registers.  From this information, we know
all we need to about each stack frame.  On the downside, nothing
further on is allowed to change this stack info; it is set in stone.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TomMurphy">
<title>TomMurphy</title>
<simpara>Tom Murphy VII is a long time MLton user and occasional contributor. He works on programming languages for his PhD work at Carnegie Mellon in Pittsburgh, USA. <link linkend="AdamGoode">AdamGoode</link> lives on the same floor of Wean Hall.</simpara>
<simpara><ulink url="http://tom7.org">Home page</ulink></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ToRSSA">
<title>ToRSSA</title>
<simpara><link linkend="ToRSSA">ToRSSA</link> is a translation pass from the <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="RSSA">RSSA</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_62">
<title>Description</title>
<simpara>This pass converts a <link linkend="SSA2">SSA2</link> program into a <link linkend="RSSA">RSSA</link> program.</simpara>
<simpara>It uses <link linkend="PackedRepresentation">PackedRepresentation</link>.</simpara>
</section>
<section id="_implementation_67">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/ssa-to-rssa.sig"><literal>ssa-to-rssa.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/backend/ssa-to-rssa.fun"><literal>ssa-to-rssa.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_65">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ToSSA2">
<title>ToSSA2</title>
<simpara><link linkend="ToSSA2">ToSSA2</link> is a translation pass from the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link> to the <link linkend="SSA2">SSA2</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link>.</simpara>
<section id="_description_63">
<title>Description</title>
<simpara>This pass is a simple conversion from a <link linkend="SSA">SSA</link> program into a
<link linkend="SSA2">SSA2</link> program.</simpara>
<simpara>The only interesting portions of the translation are:</simpara>
<itemizedlist>
<listitem>
<simpara>
an <link linkend="SSA">SSA</link> <literal>ref</literal> type becomes an object with a single mutable field
</simpara>
</listitem>
<listitem>
<simpara>
<literal>array</literal>, <literal>vector</literal>, and <literal>ref</literal> are eliminated in favor of select and updates
</simpara>
</listitem>
<listitem>
<simpara>
<literal>Case</literal> transfers separate discrimination and constructor argument selects
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_implementation_68">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa-to-ssa2.sig"><literal>ssa-to-ssa2.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/ssa-to-ssa2.fun"><literal>ssa-to-ssa2.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_66">
<title>Details and Notes</title>
<simpara></simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TypeChecking">
<title>TypeChecking</title>
<simpara>MLton&#8217;s type checker follows the <link linkend="DefinitionOfStandardML">Definition</link>
closely, so you may find differences between MLton and other SML
compilers that do not follow the Definition so closely.  In
particular, SML/NJ has many deviations from the Definition&#8201;&#8212;&#8201;please
see <link linkend="SMLNJDeviations">SMLNJDeviations</link> for those that we are aware of.</simpara>
<simpara>In some respects MLton&#8217;s type checker is more powerful than other SML
compilers, so there are programs that MLton accepts that are rejected
by some other SML compilers.  These kinds of programs fall into a few
simple categories.</simpara>
<itemizedlist>
<listitem>
<simpara>
MLton resolves flexible record patterns using a larger context than
many other SML compilers.  For example, MLton accepts the
following.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f {x, ...} = x
val _ = f {x = 13, y = "foo"}</programlisting>
</listitem>
<listitem>
<simpara>
MLton uses as large a context as possible to resolve the type of
variables constrained by the value restriction to be monotypes.  For
example, MLton accepts the following.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S:
   sig
      val f: int -&gt; int
   end =
   struct
      val f = (fn x =&gt; x) (fn y =&gt; y)
   end</programlisting>
</listitem>
</itemizedlist>
<section id="_type_error_messages">
<title>Type error messages</title>
<simpara>To aid in the understanding of type errors, MLton&#8217;s type checker
displays type errors differently than other SML compilers.  In
particular, when two types are different, it is important for the
programmer to easily understand why they are different.  So, MLton
displays only the differences between two types that don&#8217;t match,
using underscores for the parts that match.  For example, if a
function expects <literal>real * int</literal> but gets <literal>real * real</literal>, the type error
message would look like</simpara>
<screen>expects: _ * [int]
but got: _ * [real]</screen>
<simpara>As another aid to spotting differences, MLton places brackets <literal>[]</literal>
around the parts of the types that don&#8217;t match.  A common situation is
when a function receives a different number of arguments than it
expects, in which case you might see an error like</simpara>
<screen>expects: [int * real]
but got: [int * real * string]</screen>
<simpara>The brackets make it easy to see that the problem is that the tuples
have different numbers of components&#8201;&#8212;&#8201;not that the components don&#8217;t
match.  Contrast that with a case where a function receives the right
number of arguments, but in the wrong order, in which case you might
see an error like</simpara>
<screen>expects: [int] * [real]
but got: [real] * [int]</screen>
<simpara>Here the brackets make it easy to see that the components do not match.</simpara>
<simpara>We appreciate feedback on any type error messages that you find
confusing, or suggestions you may have for improvements to error
messages.</simpara>
</section>
<section id="_the_shortest_most_recent_rule_for_type_names">
<title>The shortest/most-recent rule for type names</title>
<simpara>In a type error message, MLton often has a number of choices in
deciding what name to use for a type.  For example, in the following
type-incorrect program</simpara>
<programlisting language="sml" linenumbering="unnumbered">type t = int
fun f (x: t) = x
val _ = f "foo"</programlisting>
<simpara>MLton reports the error message</simpara>
<screen>Error: z.sml 3.9-3.15.
  Function applied to incorrect argument.
    expects: [t]
    but got: [string]
    in: f "foo"</screen>
<simpara>MLton could have reported <literal>expects: [int]</literal> instead of <literal>expects: [t]</literal>.
However, MLton uses the shortest/most-recent rule in order to decide
what type name to display.  This rule means that, at the point of the
error, MLton first looks for the shortest name for a type in terms of
number of structure identifiers (e.g. <literal>foobar</literal> is shorter than <literal>A.t</literal>).
Next, if there are multiple names of the same length, then MLton uses
the most recently defined name.  It is this tiebreaker that causes
MLton to prefer <literal>t</literal> to <literal>int</literal> in the above example.</simpara>
<simpara>In signature matching, most recently defined is not taken to include
all of the definitions introduced by the structure (since the matching
takes place outside the structure and before it is defined).  For
example, in the following type-incorrect program</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S:
   sig
      val x: int
   end =
   struct
      type t = int
      val x = "foo"
   end</programlisting>
<simpara>MLton reports the error message</simpara>
<screen>Error: z.sml 2.4-4.6.
  Variable in structure disagrees with signature (type): x.
    structure: val x: [string]
    defn at: z.sml 7.11-7.11
    signature: val x: [int]
    spec at: z.sml 3.11-3.11</screen>
<simpara>If there is a type that only exists inside the structure being
matched, then the prefix <literal>_str.</literal> is used.  For example, in the
following type-incorrect program</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure S:
   sig
      val x: int
   end =
   struct
      datatype t = T
      val x = T
   end</programlisting>
<simpara>MLton reports the error message</simpara>
<screen>Error: z.sml 2.4-4.6.
  Variable in structure disagrees with signature (type): x.
    structure: val x: [_str.t]
    defn at: z.sml 7.11-7.11
    signature: val x: [int]
    spec at: z.sml 3.11-3.11</screen>
<simpara>in which the <literal>[_str.t]</literal> refers to the type defined in the structure.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TypeConstructor">
<title>TypeConstructor</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, a type constructor is a function from
types to types.  Type constructors can be <emphasis>nullary</emphasis>, meaning that
they take no arguments, as in <literal>char</literal>, <literal>int</literal>, and <literal>real</literal>.
Type constructors can be <emphasis>unary</emphasis>, meaning that they take one
argument, as in <literal>array</literal>, <literal>list</literal>, and <literal>vector</literal>.  A program
can define a new type constructor in two ways: a <literal>type</literal> definition
or a <literal>datatype</literal> declaration.  User-defined type constructors can
can take any number of arguments.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = T of int * real            (* 0 arguments *)
type 'a t = 'a * int                    (* 1 argument *)
datatype ('a, 'b) t = A | B of 'a * 'b  (* 2 arguments *)
type ('a, 'b, 'c) t = 'a * ('b  -&gt; 'c)  (* 3 arguments *)</programlisting>
<simpara>Here are the syntax rules for type constructor application.</simpara>
<itemizedlist>
<listitem>
<simpara>
Type constructor application is written in postfix.  So, one writes
 <literal>int list</literal>, not <literal>list int</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Unary type constructors drop the parens, so one writes
 <literal>int list</literal>, not <literal>(int) list</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Nullary type constructors drop the argument entirely, so one writes
 <literal>int</literal>, not <literal>() int</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
N-ary type constructors use tuple notation; for example,
 <literal>(int, real) t</literal>.
</simpara>
</listitem>
<listitem>
<simpara>
Type constructor application associates to the left.  So,
 <literal>int ref list</literal> is the same as <literal>(int ref) list</literal>.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="TypeIndexedValues">
<title>TypeIndexedValues</title>
<simpara><link linkend="StandardML">Standard ML</link> does not support ad hoc polymorphism.  This
presents a challenge to programmers.  The problem is that at first
glance there seems to be no practical way to implement something like
a function for converting a value of any type to a string or a
function for computing a hash value for a value of any type.
Fortunately there are ways to implement type-indexed values in SML as
discussed in <link linkend="References_Yang98">Yang98</link>.  Various articles such as
<link linkend="References_Danvy98">Danvy98</link>, <link linkend="References_Ramsey11">Ramsey11</link>, <link linkend="References_Elsman04">Elsman04</link>,
<link linkend="References_Kennedy04">Kennedy04</link>, and <link linkend="References_Benton05">Benton05</link> also contain examples of
type-indexed values.</simpara>
<simpara><emphasis role="strong">NOTE:</emphasis> The technique used in the following example uses an early (and
somewhat broken) variation of the basic technique used in an
experimental generic programming library (see
<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/generic/unstable/README"><literal>README</literal></ulink>) that can
be found from the MLton repository.  The generic programming library
also includes a more advanced generic pretty printing function (see
<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/generic/unstable/public/value/pretty.sig"><literal>pretty.sig</literal></ulink>).</simpara>
<section id="_example_converting_any_sml_value_to_roughly_sml_syntax">
<title>Example: Converting any SML value to (roughly) SML syntax</title>
<simpara>Consider the problem of converting any SML value to a textual
presentation that matches the syntax of SML as closely as possible.
One solution is a type-indexed function that maps a given type to a
function that maps any value (of the type) to its textual
presentation.  A type-indexed function like this can be useful for a
variety of purposes.  For example, one could use it to show debugging
information.  We&#8217;ll call this function "<literal>show</literal>".</simpara>
<simpara>We&#8217;ll do a fairly complete implementation of <literal>show</literal>.  We do not
distinguish infix and nonfix constructors, but that is not an
intrinsic property of SML datatypes.  We also don&#8217;t reconstruct a type
name for the value, although it would be particularly useful for
functional values.  To reconstruct type names, some changes would be
needed and the reader is encouraged to consider how to do that.  A
more realistic implementation would use some pretty printing
combinators to compute a layout for the result.  This should be a
relatively easy change (given a suitable pretty printing library).
Cyclic values (through references and arrays) do not have a standard
textual presentation and it is impossible to convert arbitrary
functional values (within SML) to a meaningful textual presentation.
Finally, it would also make sense to show sharing of references and
arrays.  We&#8217;ll leave these improvements to an actual library
implementation.</simpara>
<simpara>The following code uses the <link linkend="Fixpoints">fixpoint framework</link> and other
utilities from an Extended Basis library (see
<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/README"><literal>README</literal></ulink>).</simpara>
<section id="_signature">
<title>Signature</title>
<simpara>Let&#8217;s consider the design of the <literal>SHOW</literal> signature:</simpara>
<programlisting language="sml" linenumbering="unnumbered">infixr --&gt;

signature SHOW = sig
   type 'a t       (* complete type-index *)
   type 'a s       (* incomplete sum *)
   type ('a, 'k) p (* incomplete product *)
   type u          (* tuple or unlabelled product *)
   type l          (* record or labelled product *)

   val show : 'a t -&gt; 'a -&gt; string

   (* user-defined types *)
   val inj : ('a -&gt; 'b) -&gt; 'b t -&gt; 'a t

   (* tuples and records *)
   val * : ('a, 'k) p * ('b, 'k) p -&gt; (('a, 'b) product, 'k) p

   val U :           'a t -&gt; ('a, u) p
   val L : string -&gt; 'a t -&gt; ('a, l) p

   val tuple  : ('a, u) p -&gt; 'a t
   val record : ('a, l) p -&gt; 'a t

   (* datatypes *)
   val + : 'a s * 'b s -&gt; (('a, 'b) sum) s

   val C0 : string -&gt; unit s
   val C1 : string -&gt; 'a t -&gt; 'a s

   val data : 'a s -&gt; 'a t

   val Y : 'a t Tie.t

   (* exceptions *)
   val exn : exn t
   val regExn : (exn -&gt; ('a * 'a s) option) -&gt; unit

   (* some built-in type constructors *)
   val refc : 'a t -&gt; 'a ref t
   val array : 'a t -&gt; 'a array t
   val list : 'a t -&gt; 'a list t
   val vector : 'a t -&gt; 'a vector t
   val --&gt; : 'a t * 'b t -&gt; ('a -&gt; 'b) t

   (* some built-in base types *)
   val string : string t
   val unit : unit t
   val bool : bool t
   val char : char t
   val int : int t
   val word : word t
   val real : real t
end</programlisting>
<simpara>While some details are shaped by the specific requirements of <literal>show</literal>,
there are a number of (design) patterns that translate to other
type-indexed values.  The former kind of details are mostly shaped by
the syntax of SML values that <literal>show</literal> is designed to produce.  To this
end, abstract types and phantom types are used to distinguish
incomplete record, tuple, and datatype type-indices from each other
and from complete type-indices.  Also, names of record labels and
datatype constructors need to be provided by the user.</simpara>
<section id="_arbitrary_user_defined_datatypes">
<title>Arbitrary user-defined datatypes</title>
<simpara>Perhaps the most important pattern is how the design supports
arbitrary user-defined datatypes.  A number of combinators together
conspire to provide the functionality.  First of all, to support new
user-defined types, a combinator taking a conversion function to a
previously supported type is provided:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val inj : ('a -&gt; 'b) -&gt; 'b t -&gt; 'a t</programlisting>
<simpara>An injection function is sufficient in this case, but in the general
case, an embedding with injection and projection functions may be
needed.</simpara>
<simpara>To support products (tuples and records) a product combinator is
provided:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val * : ('a, 'k) p * ('b, 'k) p -&gt; (('a, 'b) product, 'k) p</programlisting>
<simpara>The second (phantom) type variable <literal>'k</literal> is there to distinguish
between labelled and unlabelled products and the type <literal>p</literal>
distinguishes incomplete products from complete type-indices of type
<literal>t</literal>.  Most type-indexed values do not need to make such distinctions.</simpara>
<simpara>To support sums (datatypes) a sum combinator is provided:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val + : 'a s * 'b s -&gt; (('a, 'b) sum) s</programlisting>
<simpara>Again, the purpose of the type <literal>s</literal> is to distinguish incomplete sums
from complete type-indices of type <literal>t</literal>, which usually isn&#8217;t necessary.</simpara>
<simpara>Finally, to support recursive datatypes, including sets of mutually
recursive datatypes, a <link linkend="Fixpoints">fixpoint tier</link> is provided:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val Y : 'a t Tie.t</programlisting>
<simpara>Together these combinators (with the more domain specific combinators
<literal>U</literal>, <literal>L</literal>, <literal>tuple</literal>, <literal>record</literal>, <literal>C0</literal>, <literal>C1</literal>, and <literal>data</literal>) enable one to
encode a type-index for any user-defined datatype.</simpara>
</section>
<section id="_exceptions">
<title>Exceptions</title>
<simpara>The <literal>exn</literal> type in SML is a <link linkend="UniversalType">universal type</link> into which
all types can be embedded.  SML also allows a program to generate new
exception variants at run-time.  Thus a mechanism is required to register
handlers for particular variants:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val exn : exn t
val regExn : (exn -&gt; ('a * 'a s) option) -&gt; unit</programlisting>
<simpara>The universal <literal>exn</literal> type-index then makes use of the registered
handlers.  The above particular form of handler, which converts an
exception value to a value of some type and a type-index for that type
(essentially an existential type) is designed to make it convenient to
write handlers.  To write a handler, one can conveniently reuse
existing type-indices:</simpara>
<programlisting language="sml" linenumbering="unnumbered">exception Int of int

local
   open Show
in
   val () = regExn (fn Int v =&gt; SOME (v, C1"Int" int)
                     | _     =&gt; NONE)
end</programlisting>
<simpara>Note that a single handler may actually handle an arbitrary number of
different exceptions.</simpara>
</section>
<section id="_other_types">
<title>Other types</title>
<simpara>Some built-in and standard types typically require special treatment
due to their special nature.  The most important of these are arrays
and references, because cyclic data (ignoring closures) and observable
sharing can only be constructed through them.</simpara>
<simpara>When arrow types are really supported, unlike in this case, they
usually need special treatment due to the contravariance of arguments.</simpara>
<simpara>Lists and vectors require special treatment in the case of <literal>show</literal>,
because of their special syntax.  This isn&#8217;t usually the case.</simpara>
<simpara>The set of base types to support also needs to be considered unless
one exports an interface for constructing type-indices for entirely
new base types.</simpara>
</section>
</section>
</section>
<section id="_usage_9">
<title>Usage</title>
<simpara>Before going to the implementation, let&#8217;s look at some examples.  For
the following examples, we&#8217;ll assume a structure binding
<literal>Show :&gt; SHOW</literal>.  If you want to try the examples immediately, just
skip forward to the implementation.</simpara>
<simpara>To use <literal>show</literal>, one first needs a type-index, which is then given to
<literal>show</literal>.  To show a list of integers, one would use the type-index
<literal>list int</literal>, which has the type <literal>int list Show.t</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val "[3, 1, 4]" =
    let open Show in show (list int) end
       [3, 1, 4]</programlisting>
<simpara>Likewise, to show a list of lists of characters, one would use the
type-index <literal>list (list char)</literal>, which has the type <literal>char list list
Show.t</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val "[[#\"a\", #\"b\", #\"c\"], []]" =
    let open Show in show (list (list char)) end
       [[#"a", #"b", #"c"], []]</programlisting>
<simpara>Handling standard types is not particularly interesting.  It is more
interesting to see how user-defined types can be handled.  Although
the <literal>option</literal> datatype is a standard type, it requires no special
support, so we can treat it as a user-defined type.  Options can be
encoded easily using a sum:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun option t = let
   open Show
in
   inj (fn NONE =&gt; INL ()
         | SOME v =&gt; INR v)
       (data (C0"NONE" + C1"SOME" t))
end

val "SOME 5" =
    let open Show in show (option int) end
       (SOME 5)</programlisting>
<simpara>Readers new to type-indexed values might want to type annotate each
subexpression of the above example as an exercise.  (Use a compiler to
check your annotations.)</simpara>
<simpara>Using a product, user specified records can be also be encoded easily:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val abc = let
   open Show
in
   inj (fn {a, b, c} =&gt; a &amp; b &amp; c)
       (record (L"a" (option int) *
                L"b" real *
                L"c" bool))
end

val "{a = SOME 1, b = 3.0, c = false}" =
    let open Show in show abc end
       {a = SOME 1, b = 3.0, c = false}</programlisting>
<simpara>As you can see, both of the above use <literal>inj</literal> to inject user-defined
types to the general purpose sum and product types.</simpara>
<simpara>Of particular interest is whether recursive datatypes and cyclic data
can be handled.  For example, how does one write a type-index for a
recursive datatype such as a cyclic graph?</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a graph = VTX of 'a * 'a graph list ref
fun arcs (VTX (_, r)) = r</programlisting>
<simpara>Using the <literal>Show</literal> combinators, we could first write a new type-index
combinator for <literal>graph</literal>:</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun graph a = let
   open Tie Show
in
   fix Y (fn graph_a =&gt;
             inj (fn VTX (x, y) =&gt; x &amp; y)
                 (data (C1"VTX"
                          (tuple (U a *
                                  U (refc (list graph_a)))))))
end</programlisting>
<simpara>To show a graph with integer labels</simpara>
<programlisting language="sml" linenumbering="unnumbered">val a_graph = let
   val a = VTX (1, ref [])
   val b = VTX (2, ref [])
   val c = VTX (3, ref [])
   val d = VTX (4, ref [])
   val e = VTX (5, ref [])
   val f = VTX (6, ref [])
in
   arcs a := [b, d]
 ; arcs b := [c, e]
 ; arcs c := [a, f]
 ; arcs d := [f]
 ; arcs e := [d]
 ; arcs f := [e]
 ; a
end</programlisting>
<simpara>we could then simply write</simpara>
<programlisting language="sml" linenumbering="unnumbered">val "VTX (1, ref [VTX (2, ref [VTX (3, ref [VTX (1, %0), \
    \VTX (6, ref [VTX (5, ref [VTX (4, ref [VTX (6, %3)])])] as %3)]), \
    \VTX (5, ref [VTX (4, ref [VTX (6, ref [VTX (5, %2)])])] as %2)]), \
    \VTX (4, ref [VTX (6, ref [VTX (5, ref [VTX (4, %1)])])] as %1)] as %0)" =
    let open Show in show (graph int) end
       a_graph</programlisting>
<simpara>There is a subtle gotcha with cyclic data.  Consider the following code:</simpara>
<programlisting language="sml" linenumbering="unnumbered">exception ExnArray of exn array

val () = let
   open Show
in
   regExn (fn ExnArray a =&gt;
              SOME (a, C1"ExnArray" (array exn))
            | _ =&gt; NONE)
end

val a_cycle = let
   val a = Array.fromList [Empty]
in
   Array.update (a, 0, ExnArray a) ; a
end</programlisting>
<simpara>Although the above looks innocent enough, the evaluation  of</simpara>
<programlisting language="sml" linenumbering="unnumbered">val "[|ExnArray %0|] as %0" =
    let open Show in show (array exn) end
       a_cycle</programlisting>
<simpara>goes into an infinite loop.  To avoid this problem, the type-index
<literal>array exn</literal> must be evaluated only once, as in the following:</simpara>
<programlisting language="sml" linenumbering="unnumbered">val array_exn = let open Show in array exn end

exception ExnArray of exn array

val () = let
   open Show
in
   regExn (fn ExnArray a =&gt;
              SOME (a, C1"ExnArray" array_exn)
            | _ =&gt; NONE)
end

val a_cycle = let
   val a = Array.fromList [Empty]
in
   Array.update (a, 0, ExnArray a) ; a
end

val "[|ExnArray %0|] as %0" =
    let open Show in show array_exn end
       a_cycle</programlisting>
<simpara>Cyclic data (excluding closures) in Standard ML can only be
constructed imperatively through arrays and references (combined with
exceptions or recursive datatypes).  Before recursing to a reference
or an array, one needs to check whether that reference or array has
already been seen before.  When <literal>ref</literal> or <literal>array</literal> is called with a
type-index, a new cyclicity checker is instantiated.</simpara>
</section>
<section id="_implementation_69">
<title>Implementation</title>
<programlisting language="sml" linenumbering="unnumbered">structure SmlSyntax = struct
   local
      structure CV = CharVector and C = Char
   in
      val isSym = Char.contains "!%&amp;$#+-/:&lt;=&gt;?@\\~`^|*"

      fun isSymId s = 0 &lt; size s andalso CV.all isSym s

      fun isAlphaNumId s =
          0 &lt; size s
          andalso C.isAlpha (CV.sub (s, 0))
          andalso CV.all (fn c =&gt; C.isAlphaNum c
                                  orelse #"'" = c
                                  orelse #"_" = c) s

      fun isNumLabel s =
          0 &lt; size s
          andalso #"0" &lt;&gt; CV.sub (s, 0)
          andalso CV.all C.isDigit s

      fun isId s = isAlphaNumId s orelse isSymId s

      fun isLongId s = List.all isId (String.fields (#"." &lt;\ op =) s)

      fun isLabel s = isId s orelse isNumLabel s
   end
end

structure Show :&gt; SHOW = struct
   datatype 'a t = IN of exn list * 'a -&gt; bool * string
   type 'a s = 'a t
   type ('a, 'k) p = 'a t
   type u = unit
   type l = unit

   fun show (IN t) x = #2 (t ([], x))

   (* user-defined types *)
   fun inj inj (IN b) = IN (b o Pair.map (id, inj))

   local
      fun surround pre suf (_, s) = (false, concat [pre, s, suf])
      fun parenthesize x = if #1 x then surround "(" ")" x else x
      fun construct tag =
          (fn (_, s) =&gt; (true, concat [tag, " ", s])) o parenthesize
      fun check p m s = if p s then () else raise Fail (m^s)
   in
      (* tuples and records *)
      fun (IN l) * (IN r) =
          IN (fn (rs, a &amp; b) =&gt;
                 (false, concat [#2 (l (rs, a)),
                                 ", ",
                                 #2 (r (rs, b))]))

      val U = id
      fun L l = (check SmlSyntax.isLabel "Invalid label: " l
               ; fn IN t =&gt; IN (surround (l^" = ") "" o t))

      fun tuple (IN t) = IN (surround "(" ")" o t)
      fun record (IN t) = IN (surround "{" "}" o t)

      (* datatypes *)
      fun (IN l) + (IN r) = IN (fn (rs, INL a) =&gt; l (rs, a)
                                 | (rs, INR b) =&gt; r (rs, b))

      fun C0 c = (check SmlSyntax.isId "Invalid constructor: " c
                ; IN (const (false, c)))
      fun C1 c (IN t) = (check SmlSyntax.isId "Invalid constructor: " c
                       ; IN (construct c o t))

      val data = id

      fun Y ? = Tie.iso Tie.function (fn IN x =&gt; x, IN) ?

      (* exceptions *)
      local
         val handlers = ref ([] : (exn -&gt; unit t option) list)
      in
         val exn = IN (fn (rs, e) =&gt; let
                             fun lp [] =
                                 C0(concat ["&lt;exn:",
                                            General.exnName e,
                                            "&gt;"])
                               | lp (f::fs) =
                                 case f e
                                  of NONE =&gt; lp fs
                                   | SOME t =&gt; t
                             val IN f = lp (!handlers)
                          in
                             f (rs, ())
                          end)
         fun regExn f =
             handlers := (Option.map
                             (fn (x, IN f) =&gt;
                                 IN (fn (rs, ()) =&gt;
                                        f (rs, x))) o f)
                         :: !handlers
      end

      (* some built-in type constructors *)
      local
         fun cyclic (IN t) = let
            exception E of ''a * bool ref
         in
            IN (fn (rs, v : ''a) =&gt; let
                      val idx = Int.toString o length
                      fun lp (E (v', c)::rs) =
                          if v' &lt;&gt; v then lp rs
                          else (c := false ; (false, "%"^idx rs))
                        | lp (_::rs) = lp rs
                        | lp [] = let
                             val c = ref true
                             val r = t (E (v, c)::rs, v)
                          in
                             if !c then r
                             else surround "" (" as %"^idx rs) r
                          end
                   in
                      lp rs
                   end)
         end

         fun aggregate pre suf toList (IN t) =
             IN (surround pre suf o
                 (fn (rs, a) =&gt;
                     (false,
                      String.concatWith
                         ", "
                         (map (#2 o curry t rs)
                              (toList a)))))
      in
         fun refc ? = (cyclic o inj ! o C1"ref") ?
         fun array ? = (cyclic o aggregate "[|" "|]" (Array.foldr op:: [])) ?
         fun list ? = aggregate "[" "]" id ?
         fun vector ? = aggregate "#[" "]" (Vector.foldr op:: []) ?
      end

      fun (IN _) --&gt; (IN _) = IN (const (false, "&lt;fn&gt;"))

      (* some built-in base types *)
      local
         fun mk toS = (fn x =&gt; (false, x)) o toS o (fn (_, x) =&gt; x)
      in
         val string =
             IN (surround "\"" "\"" o mk (String.translate Char.toString))
         val unit = IN (mk (fn () =&gt; "()"))
         val bool = IN (mk Bool.toString)
         val char = IN (surround "#\"" "\"" o mk Char.toString)
         val int = IN (mk Int.toString)
         val word = IN (surround "0wx" "" o mk Word.toString)
         val real = IN (mk Real.toString)
      end
   end
end

(* Handlers for standard top-level exceptions *)
val () = let
   open Show
   fun E0 name = SOME ((), C0 name)
in
   regExn (fn Bind =&gt; E0"Bind"
            | Chr =&gt; E0"Chr"
            | Div =&gt; E0"Div"
            | Domain =&gt; E0"Domain"
            | Empty =&gt; E0"Empty"
            | Match =&gt; E0"Match"
            | Option =&gt; E0"Option"
            | Overflow  =&gt; E0"Overflow"
            | Size =&gt; E0"Size"
            | Span =&gt; E0"Span"
            | Subscript =&gt; E0"Subscript"
            | _ =&gt; NONE)
 ; regExn (fn Fail s =&gt; SOME (s, C1"Fail" string)
            | _ =&gt; NONE)
end</programlisting>
</section>
<section id="_also_see_47">
<title>Also see</title>
<simpara>There are a number of related techniques.  Here are some of them.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="Fold">Fold</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="StaticSum">StaticSum</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="TypeVariableScope">
<title>TypeVariableScope</title>
<simpara>In <link linkend="StandardML">Standard ML</link>, every type variable is <emphasis>scoped</emphasis> (or
bound) at a particular point in the program.  A type variable can be
either implicitly scoped or explicitly scoped.  For example, <literal>'a</literal> is
implicitly scoped in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x</programlisting>
<simpara>and is implicitly scoped in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id = fn x: 'a =&gt; x</programlisting>
<simpara>On the other hand, <literal>'a</literal> is explicitly scoped in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a id: 'a -&gt; 'a = fn x =&gt; x</programlisting>
<simpara>and is explicitly scoped in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a id = fn x: 'a =&gt; x</programlisting>
<simpara>A type variable can be scoped at a <literal>val</literal> or <literal>fun</literal> declaration.  An SML
type checker performs scope inference on each top-level declaration to
determine the scope of each implicitly scoped type variable.  After
scope inference, every type variable is scoped at exactly one
enclosing <literal>val</literal> or <literal>fun</literal> declaration.  Scope inference shows that the
first and second example above are equivalent to the third and fourth
example, respectively.</simpara>
<simpara>Section 4.6 of the <link linkend="DefinitionOfStandardML">Definition</link> specifies
precisely the scope of an implicitly scoped type variable.  A free
occurrence of a type variable <literal>'a</literal> in a declaration <literal>d</literal> is said to be
<emphasis>unguarded</emphasis> in <literal>d</literal> if <literal>'a</literal> is not part of a smaller declaration.  A
type variable <literal>'a</literal> is implicitly scoped at <literal>d</literal> if <literal>'a</literal> is unguarded in
<literal>d</literal> and <literal>'a</literal> does not occur unguarded in any declaration containing
<literal>d</literal>.</simpara>
<section id="_scope_inference_examples">
<title>Scope inference examples</title>
<itemizedlist>
<listitem>
<simpara>
In this example,
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x</programlisting>
<simpara><literal>'a</literal> is unguarded in <literal>val id</literal> and does not occur unguarded in any
containing declaration.  Hence, <literal>'a</literal> is scoped at <literal>val id</literal> and the
declaration is equivalent to the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a id: 'a -&gt; 'a = fn x =&gt; x</programlisting>
</listitem>
<listitem>
<simpara>
In this example,
</simpara>
<programlisting language="sml" linenumbering="unnumbered"> val f = fn x =&gt; let exception E of 'a in E x end</programlisting>
<simpara><literal>'a</literal> is unguarded in <literal>val f</literal> and does not occur unguarded in any
containing declaration.  Hence, <literal>'a</literal> is scoped at <literal>val f</literal> and the
declaration is equivalent to the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a f = fn x =&gt; let exception E of 'a in E x end</programlisting>
</listitem>
<listitem>
<simpara>
In this example (taken from the <link linkend="DefinitionOfStandardML">Definition</link>),
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x: int -&gt; int = let val id: 'a -&gt; 'a = fn z =&gt; z in id id end</programlisting>
<simpara><literal>'a</literal> occurs unguarded in <literal>val id</literal>, but not in <literal>val x</literal>.  Hence, <literal>'a</literal> is
implicitly scoped at <literal>val id</literal>, and the declaration is equivalent to
the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val x: int -&gt; int = let val 'a id: 'a -&gt; 'a = fn z =&gt; z in id id end</programlisting>
</listitem>
<listitem>
<simpara>
In this example,
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = (fn x: 'a =&gt; x) (fn y =&gt; y)</programlisting>
<simpara><literal>'a</literal> occurs unguarded in <literal>val f</literal> and does not occur unguarded in any
containing declaration.  Hence, <literal>'a</literal> is implicitly scoped at <literal>val f</literal>,
and the declaration is equivalent to the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val 'a f = (fn x: 'a =&gt; x) (fn y =&gt; y)</programlisting>
<simpara>This does not type check due to the <link linkend="ValueRestriction">ValueRestriction</link>.</simpara>
</listitem>
<listitem>
<simpara>
In this example,
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f x =
  let
    fun g (y: 'a) = if true then x else y
  in
    g x
  end</programlisting>
<simpara><literal>'a</literal> occurs unguarded in <literal>fun g</literal>, not in <literal>fun f</literal>.  Hence, <literal>'a</literal> is
implicitly scoped at <literal>fun g</literal>, and the declaration is equivalent to</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f x =
  let
    fun 'a g (y: 'a) = if true then x else y
  in
    g x
  end</programlisting>
<simpara>This fails to type check because <literal>x</literal> and <literal>y</literal> must have the same type,
but the <literal>x</literal> occurs outside the scope of the type variable <literal>'a</literal>.  MLton
reports the following error.</simpara>
<screen>Error: z.sml 3.21-3.41.
  Then and else branches disagree.
    then: [???]
    else: ['a]
    in: if true then x else y
    note: type would escape its scope: 'a
    escape to: z.sml 1.1-6.5</screen>
<simpara>This problem could be fixed either by adding an explicit type
constraint, as in <literal>fun f (x: 'a)</literal>, or by explicitly scoping <literal>'a</literal>, as
in <literal>fun 'a f x = ...</literal>.</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_restrictions_on_type_variable_scope">
<title>Restrictions on type variable scope</title>
<simpara>It is not allowed to scope a type variable within a declaration in
which it is already in scope (see the last restriction listed on page
9 of the <link linkend="DefinitionOfStandardML">Definition</link>).  For example, the
following program is invalid.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun 'a f (x: 'a) =
   let
      fun 'a g (y: 'a) = y
   in
      ()
   end</programlisting>
<simpara>MLton reports the following error.</simpara>
<screen>Error: z.sml 3.11-3.12.
  Type variable scoped at an outer declaration: 'a.
    scoped at: z.sml 1.1-6.6</screen>
<simpara>This is an error even if the scoping is implicit.  That is, the
following program is invalid as well.</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f (x: 'a) =
   let
      fun 'a g (y: 'a) = y
   in
      ()
   end</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Unicode">
<title>Unicode</title>
<section id="_support_in_the_definition_of_standard_ml">
<title>Support in The Definition of Standard ML</title>
<simpara>There is no real support for Unicode in the
<link linkend="DefinitionOfStandardML">Definition</link>; there are only a few throw-away
sentences along the lines of "the characters with numbers 0 to 127
coincide with the ASCII character set."</simpara>
</section>
<section id="_support_in_the_standard_ml_basis_library">
<title>Support in The Standard ML Basis Library</title>
<simpara>Neither is there real support for Unicode in the <link linkend="BasisLibrary">Basis Library</link>.  The general consensus (which includes the opinions of the
editors of the Basis Library) is that the <literal>WideChar</literal> and <literal>WideString</literal>
structures are insufficient for the purposes of Unicode.  There is no
<literal>LargeChar</literal> structure, which in itself is a deficiency, since a
programmer can not program against the largest supported character
size.</simpara>
</section>
<section id="_current_support_in_mlton">
<title>Current Support in MLton</title>
<simpara>MLton, as a minor extension over the Definition, supports UTF-8 byte
sequences in text constants.  This feature enables "UTF-8 convenience"
(but not comprehensive Unicode support); in particular, it allows one
to copy text from a browser and paste it into a string constant in an
editor and, furthermore, if the string is printed to a terminal, then
will (typically) appear as the original text.  See the
<link linkend="SuccessorML_ExtendedTextConsts">extended text constants feature of Successor ML</link> for more details.</simpara>
<simpara>MLton, also as a minor extension over the Definition, supports
<literal>\Uxxxxxxxx</literal> numeric escapes in text constants and has preliminary
internal support for 16- and 32-bit characters and strings.</simpara>
<simpara>MLton provides <literal>WideChar</literal> and <literal>WideString</literal> structures, corresponding
to 32-bit characters and strings, respectively.</simpara>
</section>
<section id="_questions_and_discussions">
<title>Questions and Discussions</title>
<simpara>There are periodic flurries of questions and discussion about Unicode
in MLton/SML.  In December 2004, there was a discussion that led to
some seemingly sound design decisions.  The discussion started at:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-December/026396.html">http://www.mlton.org/pipermail/mlton/2004-December/026396.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>There is a good summary of points at:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-December/026440.html">http://www.mlton.org/pipermail/mlton/2004-December/026440.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara>In November 2005, there was a followup discussion and the beginning of
some coding.</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2005-November/028300.html">http://www.mlton.org/pipermail/mlton/2005-November/028300.html</ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_also_see_48">
<title>Also see</title>
<simpara>The <link linkend="fxp">fxp</link> XML parser has some support for dealing with Unicode
documents.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="UniversalType">
<title>UniversalType</title>
<simpara>A universal type is a type into which all other types can be embedded.
Here&#8217;s a <link linkend="StandardML">Standard ML</link> signature for a universal type.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature UNIVERSAL_TYPE =
   sig
      type t

      val embed: unit -&gt; ('a -&gt; t) * (t -&gt; 'a option)
   end</programlisting>
<simpara>The idea is that <literal>type t</literal> is the universal type and that each call to
<literal>embed</literal> returns a new pair of functions <literal>(inject, project)</literal>, where
<literal>inject</literal> embeds a value into the universal type and <literal>project</literal> extracts
the value from the universal type.  A pair <literal>(inject, project)</literal>
returned by <literal>embed</literal> works together in that <literal>project u</literal> will return
<literal>SOME v</literal> if and only if <literal>u</literal> was created by <literal>inject v</literal>.  If <literal>u</literal> was
created by a different function <literal>inject'</literal>, then <literal>project</literal> returns
<literal>NONE</literal>.</simpara>
<simpara>Here&#8217;s an example embedding integers and reals into a universal type.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Test (U: UNIVERSAL_TYPE): sig end =
   struct
      val (intIn: int -&gt; U.t, intOut) = U.embed ()
      val r: U.t ref = ref (intIn 13)
      val s1 =
         case intOut (!r) of
            NONE =&gt; "NONE"
          | SOME i =&gt; Int.toString i
      val (realIn: real -&gt; U.t, realOut) = U.embed ()
      val () = r := realIn 13.0
      val s2 =
         case intOut (!r) of
            NONE =&gt; "NONE"
          | SOME i =&gt; Int.toString i
      val s3 =
         case realOut (!r) of
            NONE =&gt; "NONE"
          | SOME x =&gt; Real.toString x
      val () = print (concat [s1, " ", s2, " ", s3, "\n"])
   end</programlisting>
<simpara>Applying <literal>Test</literal> to an appropriate implementation will print</simpara>
<screen>13 NONE 13.0</screen>
<simpara>Note that two different calls to embed on the same type return
different embeddings.</simpara>
<simpara>Standard ML does not have explicit support for universal types;
however, there are at least two ways to implement them.</simpara>
<section id="_implementation_using_exceptions">
<title>Implementation Using Exceptions</title>
<simpara>While the intended use of SML exceptions is for exception handling, an
accidental feature of their design is that the <literal>exn</literal> type is a
universal type.  The implementation relies on being able to declare
exceptions locally to a function and on the fact that exceptions are
<link linkend="GenerativeException">generative</link>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure U:&gt; UNIVERSAL_TYPE =
   struct
      type t = exn

      fun 'a embed () =
         let
            exception E of 'a
            fun project (e: t): 'a option =
               case e of
                  E a =&gt; SOME a
                | _ =&gt; NONE
         in
            (E, project)
         end
   end</programlisting>
</section>
<section id="_implementation_using_functions_and_references">
<title>Implementation Using Functions and References</title>
<programlisting language="sml" linenumbering="unnumbered">structure U:&gt; UNIVERSAL_TYPE =
   struct
      datatype t = T of {clear: unit -&gt; unit,
                         store: unit -&gt; unit}

      fun 'a embed () =
         let
            val r: 'a option ref = ref NONE
            fun inject (a: 'a): t =
               T {clear = fn () =&gt; r := NONE,
                  store = fn () =&gt; r := SOME a}
            fun project (T {clear, store}): 'a option =
               let
                  val () = store ()
                  val res = !r
                  val () = clear ()
               in
                  res
               end
         in
            (inject, project)
         end
   end</programlisting>
<simpara>Note that due to the use of a shared ref cell, the above
implementation is not thread safe.</simpara>
<simpara>One could try to simplify the above implementation by eliminating the
<literal>clear</literal> function, making <literal>type t = unit -&gt; unit</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure U:&gt; UNIVERSAL_TYPE =
   struct
      type t = unit -&gt; unit

      fun 'a embed () =
         let
            val r: 'a option ref = ref NONE
            fun inject (a: 'a): t = fn () =&gt; r := SOME a
            fun project (f: t): 'a option = (r := NONE; f (); !r)
         in
            (inject, project)
         end
   end</programlisting>
<simpara>While correct, this approach keeps the contents of the ref cell alive
longer than necessary, which could cause a space leak.  The problem is
in <literal>project</literal>, where the call to <literal>f</literal> stores some value in some ref cell
<literal>r'</literal>.  Perhaps <literal>r'</literal> is the same ref cell as <literal>r</literal>, but perhaps not.  If
we do not clear <literal>r'</literal> before returning from <literal>project</literal>, then <literal>r'</literal> will
keep the value alive, even though it is useless.</simpara>
</section>
<section id="_also_see_49">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="PropertyList">PropertyList</link>: Lisp-style property lists implemented with a universal type
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="UnresolvedBugs">
<title>UnresolvedBugs</title>
<simpara>Here are the places where MLton deviates from
<link linkend="DefinitionOfStandardML">The Definition of Standard ML (Revised)</link> and
the <link linkend="BasisLibrary">Basis Library</link>.  In general, MLton complies with
the <link linkend="DefinitionOfStandardML">Definition</link> quite closely, typically much
more closely than other SML compilers (see, e.g., our list of
<link linkend="SMLNJDeviations">SML/NJ&#8217;s deviations</link>).  In fact, the four deviations
listed here are the only known deviations, and we have no immediate
plans to fix them.  If you find a deviation not listed here, please
report a <link linkend="Bug">Bug</link>.</simpara>
<simpara>We don&#8217;t plan to fix these bugs because the first (parsing nested
cases) has historically never been accepted by any SML compiler, the
second clearly indicates a problem in the
<link linkend="DefinitionOfStandardML">Definition</link>, and the remaining are difficult
to resolve in the context of MLton&#8217;s implementaton of Standard ML (and
unlikely to be problematic in practice).</simpara>
<itemizedlist>
<listitem>
<simpara>
MLton does not correctly parse case expressions nested within other
matches. For example, the following fails.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">fun f 0 y =
      case x of
         1 =&gt; 2
       | _ =&gt; 3
  | f _ y = 4</programlisting>
<simpara>To do this in a program, simply parenthesize the case expression.</simpara>
<simpara>Allowing such expressions, although compliant with the Definition,
would be a mistake, since using parentheses is clearer and no SML
compiler has ever allowed them.  Furthermore, implementing this would
require serious yacc grammar rewriting followed by postprocessing.</simpara>
</listitem>
<listitem>
<simpara>
MLton does not raise the <literal>Bind</literal> exception at run time when
evaluating <literal>val rec</literal> (and <literal>fun</literal>) declarations that redefine
identifiers that previously had constructor status.  (By default,
MLton does warn at compile time about <literal>val rec</literal> (and <literal>fun</literal>)
declarations that redefine identifiers that previously had
constructors status; see the <literal>valrecConstr</literal> <link linkend="MLBasisAnnotations">ML Basis annotation</link>.)  For example, the Definition requires the
following program to type check, but also (bizarelly) requires it to
raise the <literal>Bind</literal> exception
</simpara>
<programlisting language="sml" linenumbering="unnumbered">val rec NONE = fn () =&gt; ()</programlisting>
<simpara>The Definition&#8217;s behavior is obviously an error, a mismatch between
the static semantics (rule 26) and the dynamic semantics (rule 126).
Given the comments on rule 26 in the Definition, it seems clear that
the authors meant for <literal>val rec</literal> to allow an identifier&#8217;s constructor
status to be overridden both statically and dynamically.  Hence, MLton
and most SML compilers follow rule 26, but do not follow rule 126.</simpara>
</listitem>
<listitem>
<simpara>
MLton does not hide the equality aspect of types declared in
<literal>abstype</literal> declarations. So, MLton accepts programs like the following,
while the Definition rejects them.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">abstype t = T with end
val _ = fn (t1, t2 : t) =&gt; t1 = t2

abstype t = T with val a = T end
val _ = a = a</programlisting>
<simpara>One consequence of this choice is that MLton accepts the following
program, in accordance with the Definition.</simpara>
<programlisting language="sml" linenumbering="unnumbered">abstype t = T with val eq = op = end
val _ = fn (t1, t2 : t) =&gt; eq (t1, t2)</programlisting>
<simpara>Other implementations will typically reject this program, because they
make an early choice for the type of <literal>eq</literal> to be <literal>''a * ''a -&gt; bool</literal>
instead of <literal>t * t -&gt; bool</literal>.  The choice is understandable, since the
Definition accepts the following program.</simpara>
<programlisting language="sml" linenumbering="unnumbered">abstype t = T with val eq = op = end
val _ = eq (1, 2)</programlisting>
</listitem>
<listitem>
<simpara>
MLton (re-)type checks each functor definition at every
corresponding functor application (the compilation technique of
defunctorization).  One consequence of this implementation is that
MLton accepts the following program, while the Definition rejects
it.
</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor F (X: sig type t end) = struct
    val f = id id
end
structure A = F (struct type t = int end)
structure B = F (struct type t = bool end)
val _ = A.f 10
val _ = B.f "dude"</programlisting>
<simpara>On the other hand, other implementations will typically reject the
following program, while MLton and the Definition accept it.</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor F (X: sig type t end) = struct
    val f = id id
end
structure A = F (struct type t = int end)
structure B = F (struct type t = bool end)
val _ = A.f 10
val _ = B.f false</programlisting>
<simpara>See <link linkend="References_DreyerBlume07">DreyerBlume07</link> for more details.</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="UnsafeStructure">
<title>UnsafeStructure</title>
<simpara>This module is a subset of the <literal>Unsafe</literal> module provided by SML/NJ,
with a few extract operations for <literal>PackWord</literal> and <literal>PackReal</literal>.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature UNSAFE_MONO_ARRAY =
   sig
      type array
      type elem

      val create: int -&gt; array
      val sub: array * int -&gt; elem
      val update: array * int * elem -&gt; unit
   end

signature UNSAFE_MONO_VECTOR =
   sig
      type elem
      type vector

      val sub: vector * int -&gt; elem
   end

signature UNSAFE =
   sig
      structure Array:
         sig
            val create: int * 'a -&gt; 'a array
            val sub: 'a array * int -&gt; 'a
            val update: 'a array * int * 'a -&gt; unit
         end
      structure CharArray: UNSAFE_MONO_ARRAY
      structure CharVector: UNSAFE_MONO_VECTOR
      structure IntArray: UNSAFE_MONO_ARRAY
      structure IntVector: UNSAFE_MONO_VECTOR
      structure Int8Array: UNSAFE_MONO_ARRAY
      structure Int8Vector: UNSAFE_MONO_VECTOR
      structure Int16Array: UNSAFE_MONO_ARRAY
      structure Int16Vector: UNSAFE_MONO_VECTOR
      structure Int32Array: UNSAFE_MONO_ARRAY
      structure Int32Vector: UNSAFE_MONO_VECTOR
      structure Int64Array: UNSAFE_MONO_ARRAY
      structure Int64Vector: UNSAFE_MONO_VECTOR
      structure IntInfArray: UNSAFE_MONO_ARRAY
      structure IntInfVector: UNSAFE_MONO_VECTOR
      structure LargeIntArray: UNSAFE_MONO_ARRAY
      structure LargeIntVector: UNSAFE_MONO_VECTOR
      structure LargeRealArray: UNSAFE_MONO_ARRAY
      structure LargeRealVector: UNSAFE_MONO_VECTOR
      structure LargeWordArray: UNSAFE_MONO_ARRAY
      structure LargeWordVector: UNSAFE_MONO_VECTOR
      structure RealArray: UNSAFE_MONO_ARRAY
      structure RealVector: UNSAFE_MONO_VECTOR
      structure Real32Array: UNSAFE_MONO_ARRAY
      structure Real32Vector: UNSAFE_MONO_VECTOR
      structure Real64Array: UNSAFE_MONO_ARRAY
      structure Vector:
         sig
            val sub: 'a vector * int -&gt; 'a
         end
      structure Word8Array: UNSAFE_MONO_ARRAY
      structure Word8Vector: UNSAFE_MONO_VECTOR
      structure Word16Array: UNSAFE_MONO_ARRAY
      structure Word16Vector: UNSAFE_MONO_VECTOR
      structure Word32Array: UNSAFE_MONO_ARRAY
      structure Word32Vector: UNSAFE_MONO_VECTOR
      structure Word64Array: UNSAFE_MONO_ARRAY
      structure Word64Vector: UNSAFE_MONO_VECTOR

      structure PackReal32Big : PACK_REAL
      structure PackReal32Little : PACK_REAL
      structure PackReal64Big : PACK_REAL
      structure PackReal64Little : PACK_REAL
      structure PackRealBig : PACK_REAL
      structure PackRealLittle : PACK_REAL
      structure PackWord16Big : PACK_WORD
      structure PackWord16Little : PACK_WORD
      structure PackWord32Big : PACK_WORD
      structure PackWord32Little : PACK_WORD
      structure PackWord64Big : PACK_WORD
      structure PackWord64Little : PACK_WORD
   end</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Useless">
<title>Useless</title>
<simpara><link linkend="Useless">Useless</link> is an optimization pass for the <link linkend="SSA">SSA</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSASimplify">SSASimplify</link>.</simpara>
<section id="_description_64">
<title>Description</title>
<simpara>This pass:</simpara>
<itemizedlist>
<listitem>
<simpara>
removes components of tuples that are constants (use unification)
</simpara>
</listitem>
<listitem>
<simpara>
removes function arguments that are constants
</simpara>
</listitem>
<listitem>
<simpara>
builds some kind of dependence graph where
</simpara>
<itemizedlist>
<listitem>
<simpara>
a value of ground type is useful if it is an arg to a primitive
</simpara>
</listitem>
<listitem>
<simpara>
a tuple is useful if it contains a useful component
</simpara>
</listitem>
<listitem>
<simpara>
a constructor is useful if it contains a useful component or is used in a <literal>Case</literal> transfer
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>If a useful tuple is coerced to another useful tuple, then all of
their components must agree (exactly).  It is trivial to convert a
useful value to a useless one.</simpara>
</section>
<section id="_implementation_70">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/useless.fun"><literal>useless.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_67">
<title>Details and Notes</title>
<simpara>It is also trivial to convert a useful tuple to one of its useful
components&#8201;&#8212;&#8201;but this seems hard.</simpara>
<simpara>Suppose that you have a <literal>ref</literal>/<literal>array</literal>/<literal>vector</literal> that is useful, but the
components aren&#8217;t&#8201;&#8212;&#8201;then the components are converted to type <literal>unit</literal>,
and any primitive args must be as well.</simpara>
<simpara>Unify all handler arguments so that <literal>raise</literal>/<literal>handle</literal> has a consistent
calling convention.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Users">
<title>Users</title>
<simpara>Here is a list of companies, projects, and courses that use or have
used MLton.  If you use MLton and are not here, please add your
project with a brief description and a link.  Thanks.</simpara>
<section id="_companies">
<title>Companies</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.hardcoreprocessing.com/">Hardcore Processing</ulink> uses MLton as a <ulink url="http://www.hardcoreprocessing.com/Freeware/MLTonWin32.html">crosscompiler from Linux to Windows</ulink> for graphics and game software.
</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.cex3d.net/">CEX3D Converter</ulink>, a conversion program for 3D objects.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.hardcoreprocessing.com/company/showreel/index.html">Interactive Showreel</ulink>, which contains a crossplatform GUI-toolkit and a realtime renderer for a subset of RenderMan written in Standard ML.
</simpara>
</listitem>
<listitem>
<simpara>
various <ulink url="http://www.hardcoreprocessing.com/entertainment/index.html">games</ulink>
</simpara>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mathworks.com/products/polyspace/">MathWorks/PolySpace Technologies</ulink> builds their product that detects runtime errors in embedded systems based on abstract interpretation.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.reactive-systems.com/">Reactive Systems</ulink> uses MLton to build Reactis, a model-based testing and validation package used in the automotive and aerospace industries.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_projects">
<title>Projects</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www-ia.hiof.no/%7Erolando/adate_intro.html">ADATE</ulink>, Automatic Design of Algorithms Through Evolution, a system for automatic programming i.e., inductive inference of algorithms. ADATE can automatically generate non-trivial and novel algorithms written in Standard ML.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://types.bu.edu/reports/Dim+Wes+Mul+Tur+Wel+Con:TIC-2000-LNCS.html">CIL</ulink>, a compiler for SML based on intersection and union types.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cs.cmu.edu/%7Econcert/">ConCert</ulink>, a project investigating certified code for grid computing.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://hcoop.sourceforge.net/">Cooperative Internet hosting tools</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.fantasy-coders.de/projects/gh/">Guugelhupf</ulink>, a simple search engine.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mpi-sws.org/%7Erossberg/hamlet/">HaMLet</ulink>, a model implementation of Standard ML.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://code.google.com/p/kepler-code/">KeplerCode</ulink>, independent verification of the computational aspects of proofs of the Kepler conjecture and the Dodecahedral conjecture.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.gilith.com/research/metis/">Metis</ulink>, a first-order prover (used in the <ulink url="http://hol.sourceforge.net/">HOL4 theorem prover</ulink> and the <ulink url="http://isabelle.in.tum.de/">Isabelle theorem prover</ulink>).
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://tom7misc.cvs.sourceforge.net/viewvc/tom7misc/net/mlftpd/">mlftpd</ulink>, an ftp daemon written in SML.  <link linkend="TomMurphy">TomMurphy</link> is also working on <ulink url="http://tom7misc.cvs.sourceforge.net/viewvc/tom7misc/net/">replacements for standard network services</ulink> in SML.  He also uses MLton to build his entries (<ulink url="http://www.cs.cmu.edu/%7Etom7/icfp2001/">2001</ulink>, <ulink url="http://www.cs.cmu.edu/%7Etom7/icfp2002/">2002</ulink>, <ulink url="http://www.cs.cmu.edu/%7Etom7/icfp2004/">2004</ulink>, <ulink url="http://www.cs.cmu.edu/%7Etom7/icfp2005/">2005</ulink>) in the annual ICFP programming contest.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.informatik.uni-freiburg.de/proglang/research/software/mlope/">MLOPE</ulink>, an offline partial evaluator for Standard ML.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.ida.liu.se/%7Epelab/rml/">RML</ulink>, a system for developing, compiling and debugging and teaching structural operational semantics (SOS) and natural semantics specifications.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.macs.hw.ac.uk/ultra/skalpel/index.html">Skalpel</ulink>, a type-error slicer for SML
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cs.cmu.edu/%7Etom7/ssapre/">SSA PRE</ulink>, an implementation of Partial Redundancy Elimination for MLton.
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="Stabilizers">Stabilizers</link>, a modular checkpointing abstraction for concurrent functional programs.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://ttic.uchicago.edu/%7Epl/sa-sml/">Self-Adjusting SML</ulink>, self-adjusting computation, a model of computing where programs can automatically adjust to changes to their data.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://faculty.ist.unomaha.edu/winter/ShiftLab/TL_web/TL_index.html">TL System</ulink>, providing general-purpose support for rewrite-based transformation over elements belonging to a (user-defined) domain language.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://projects.laas.fr/tina/">Tina</ulink> (Time Petri net Analyzer)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.twelf.org/">Twelf</ulink> an implementation of the LF logical framework.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.cs.indiana.edu/%7Errnewton/wavescope/">WaveScript/WaveScript</ulink>, a sensor network project; the WaveScript compiler can generate SML (MLton) code.
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_courses">
<title>Courses</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.eecs.harvard.edu/%7Enr/cs152/">Harvard CS-152</ulink>, undergraduate programming languages.
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.ia-stud.hiof.no/%7Erolando/PL/">Høgskolen i Østfold IAI30202</ulink>, programming languages.
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Utilities">
<title>Utilities</title>
<simpara>This page is a collection of basic utilities used in the examples on
various pages.  See</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="InfixingOperators">InfixingOperators</link>, and
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ProductType">ProductType</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>for longer discussions on some of these utilities.</simpara>
<programlisting language="sml" linenumbering="unnumbered">(* Operator precedence table *)
infix   8  * / div mod        (* +1 from Basis Library *)
infix   7  + - ^              (* +1 from Basis Library *)
infixr  6  :: @               (* +1 from Basis Library *)
infix   5  = &lt;&gt; &gt; &gt;= &lt; &lt;=     (* +1 from Basis Library *)
infix   4  &lt;\ \&gt;
infixr  4  &lt;/ /&gt;
infix   3  o
infix   2  &gt;|
infixr  2  |&lt;
infix   1  :=                 (* -2 from Basis Library *)
infix   0  before &amp;

(* Some basic combinators *)
fun const x _ = x
fun cross (f, g) (x, y) = (f x, g y)
fun curry f x y = f (x, y)
fun fail e _ = raise e
fun id x = x

(* Product type *)
datatype ('a, 'b) product = &amp; of 'a * 'b

(* Sum type *)
datatype ('a, 'b) sum = INL of 'a | INR of 'b

(* Some type shorthands *)
type 'a uop = 'a -&gt; 'a
type 'a fix = 'a uop -&gt; 'a
type 'a thunk = unit -&gt; 'a
type 'a effect = 'a -&gt; unit
type ('a, 'b) emb = ('a -&gt; 'b) * ('b -&gt; 'a)

(* Infixing, sectioning, and application operators *)
fun x &lt;\ f = fn y =&gt; f (x, y)
fun f \&gt; y = f y
fun f /&gt; y = fn x =&gt; f (x, y)
fun x &lt;/ f = f x

(* Piping operators *)
val op&gt;| = op&lt;/
val op|&lt; = op\&gt;</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="ValueRestriction">
<title>ValueRestriction</title>
<simpara>The value restriction is a rule that governs when type inference is
allowed to polymorphically generalize a value declaration.  In short,
the value restriction says that generalization can only occur if the
right-hand side of an expression is syntactically a value.  For
example, in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = fn x =&gt; x
val _ = (f "foo"; f 13)</programlisting>
<simpara>the expression <literal>fn x =&gt; x</literal> is syntactically a value, so <literal>f</literal> has
polymorphic type <literal>'a -&gt; 'a</literal> and both calls to <literal>f</literal> type check.  On the
other hand, in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f = let in fn x =&gt; x end
val _ = (f "foo"; f 13)</programlisting>
<simpara>the expression <literal>let in fn x =&gt; end end</literal> is not syntactically a value
and so <literal>f</literal> can either have type <literal>int -&gt; int</literal> or <literal>string -&gt; string</literal>,
but not <literal>'a -&gt; 'a</literal>.  Hence, the program does not type check.</simpara>
<simpara><link linkend="DefinitionOfStandardML">The Definition of Standard ML</link> spells out
precisely which expressions are syntactic values (it refers to such
expressions as <emphasis>non-expansive</emphasis>).  An expression is a value if it is of
one of the following forms.</simpara>
<itemizedlist>
<listitem>
<simpara>
a constant (<literal>13</literal>, <literal>"foo"</literal>, <literal>13.0</literal>, &#8230;)
</simpara>
</listitem>
<listitem>
<simpara>
a variable (<literal>x</literal>, <literal>y</literal>, &#8230;)
</simpara>
</listitem>
<listitem>
<simpara>
a function (<literal>fn x =&gt; e</literal>)
</simpara>
</listitem>
<listitem>
<simpara>
the application of a constructor other than <literal>ref</literal> to a value (<literal>Foo v</literal>)
</simpara>
</listitem>
<listitem>
<simpara>
a type constrained value (<literal>v: t</literal>)
</simpara>
</listitem>
<listitem>
<simpara>
a tuple in which each field is a value <literal>(v1, v2, ...)</literal>
</simpara>
</listitem>
<listitem>
<simpara>
a record in which each field is a value <literal>{l1 = v1, l2 = v2, ...}</literal>
</simpara>
</listitem>
<listitem>
<simpara>
a list in which each element is a value <literal>[v1, v2, ...]</literal>
</simpara>
</listitem>
</itemizedlist>
<section id="_why_the_value_restriction_exists">
<title>Why the value restriction exists</title>
<simpara>The value restriction prevents a ref cell (or an array) from holding
values of different types, which would allow a value of one type to be
cast to another and hence would break type safety.  If the restriction
were not in place, the following program would type check.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val r: 'a option ref = ref NONE
val r1: string option ref = r
val r2: int option ref = r
val () = r1 := SOME "foo"
val v: int = valOf (!r2)</programlisting>
<simpara>The first line violates the value restriction because <literal>ref NONE</literal> is
not a value.  All other lines are type correct.  By its last line, the
program has cast the string <literal>"foo"</literal> to an integer.  This breaks type
safety, because now we can add a string to an integer with an
expression like <literal>v + 13</literal>.  We could even be more devious, by adding
the following two lines, which allow us to threat the string <literal>"foo"</literal>
as a function.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val r3: (int -&gt; int) option ref = r
val v: int -&gt; int = valOf (!r3)</programlisting>
<simpara>Eliminating the explicit <literal>ref</literal> does nothing to fix the problem.  For
example, we could replace the declaration of <literal>r</literal> with the following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f: unit -&gt; 'a option ref = fn () =&gt; ref NONE
val r: 'a option ref = f ()</programlisting>
<simpara>The declaration of <literal>f</literal> is well typed, while the declaration of <literal>r</literal>
violates the value restriction because <literal>f ()</literal> is not a value.</simpara>
</section>
<section id="_unnecessarily_rejected_programs">
<title>Unnecessarily rejected programs</title>
<simpara>Unfortunately, the value restriction rejects some programs that could
be accepted.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
val f: 'a -&gt; 'a = id id</programlisting>
<simpara>The type constraint on <literal>f</literal> requires <literal>f</literal> to be polymorphic, which is
disallowed because <literal>id id</literal> is not a value.  MLton reports the
following type error.</simpara>
<screen>Error: z.sml 2.5-2.5.
  Type of variable cannot be generalized in expansive declaration: f.
    type: ['a] -&gt; ['a]
    in: val 'a f: ('a -&gt; 'a) = id id</screen>
<simpara>MLton indicates the inability to make <literal>f</literal> polymorphic by saying that
the type of <literal>f</literal> cannot be generalized (made polymorphic) its
declaration is expansive (not a value).  MLton doesn&#8217;t explicitly
mention the value restriction, but that is the reason.  If we leave
the type constraint off of <literal>f</literal></simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
val f = id id</programlisting>
<simpara>then the program succeeds; however, MLton gives us the following
warning.</simpara>
<screen>Warning: z.sml 2.5-2.5.
  Type of variable was not inferred and could not be generalized: f.
    type: ??? -&gt; ???
    in: val f = id id</screen>
<simpara>This warning indicates that MLton couldn&#8217;t polymorphically generalize
<literal>f</literal>, nor was there enough context using <literal>f</literal> to determine its type.
This in itself is not a type error, but it it is a hint that something
is wrong with our program.  Using <literal>f</literal> provides enough context to
eliminate the warning.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
val f = id id
val _ = f 13</programlisting>
<simpara>But attempting to use <literal>f</literal> as a polymorphic function will fail.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
val f = id id
val _ = f 13
val _ = f "foo"</programlisting>
<screen>Error: z.sml 4.9-4.15.
  Function applied to incorrect argument.
    expects: [int]
    but got: [string]
    in: f "foo"</screen>
</section>
<section id="_alternatives_to_the_value_restriction">
<title>Alternatives to the value restriction</title>
<simpara>There would be nothing wrong with treating <literal>f</literal> as polymorphic in</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
val f = id id</programlisting>
<simpara>One might think that the value restriction could be relaxed, and that
only types involving <literal>ref</literal> should be disallowed.  Unfortunately, the
following example shows that even the type <literal>'a -&gt; 'a</literal> can cause
problems.  If this program were allowed, then we could cast an integer
to a string (or any other type).</simpara>
<programlisting language="sml" linenumbering="unnumbered">val f: 'a -&gt; 'a =
   let
      val r: 'a option ref = ref NONE
   in
      fn x =&gt;
      let
         val y = !r
         val () = r := SOME x
      in
         case y of
            NONE =&gt; x
          | SOME y =&gt; y
      end
   end
val _ = f 13
val _ = f "foo"</programlisting>
<simpara>The previous version of Standard ML took a different approach
(<link linkend="References_MilnerEtAl90">MilnerEtAl90</link>, <link linkend="References_Tofte90">Tofte90</link>, <link linkend="ImperativeTypeVariable">ImperativeTypeVariable</link>)
than the value restriction.  It encoded information in the type system
about when ref cells would be created, and used this to prevent a ref
cell from holding multiple types.  Although it allowed more programs
to be type checked, this approach had significant drawbacks.  First,
it was significantly more complex, both for implementers and for
programmers.  Second, it had an unfortunate interaction with the
modularity, because information about ref usage was exposed in module
signatures.  This either prevented the use of references for
implementing a signature, or required information that one would like
to keep hidden to propagate across modules.</simpara>
<simpara>In the early nineties, Andrew Wright studied about 250,000 lines of
existing SML code and discovered that it did not make significant use
of the extended typing ability, and proposed the value restriction as
a simpler alternative (<link linkend="References_Wright95">Wright95</link>).  This was adopted in the
revised <link linkend="DefinitionOfStandardML">Definition</link>.</simpara>
</section>
<section id="_working_with_the_value_restriction">
<title>Working with the value restriction</title>
<simpara>One technique that works with the value restriction is
<link linkend="EtaExpansion">EtaExpansion</link>.  We can use eta expansion to make our <literal>id id</literal>
example type check follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val id: 'a -&gt; 'a = fn x =&gt; x
val f: 'a -&gt; 'a = fn z =&gt; (id id) z</programlisting>
<simpara>This solution means that the computation (in this case <literal>id id</literal>) will
be performed each time <literal>f</literal> is applied, instead of just once when <literal>f</literal>
is declared.  In this case, that is not a problem, but it could be if
the declaration of <literal>f</literal> performs substantial computation or creates a
shared data structure.</simpara>
<simpara>Another technique that sometimes works is to move a monomorphic
computation prior to a (would-be) polymorphic declaration so that the
expression is a value.  Consider the following program, which fails
due to the value restriction.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of string | B of 'a
val x: 'a t = A (if true then "yes" else "no")</programlisting>
<simpara>It is easy to rewrite this program as</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype 'a t = A of string | B of 'a
local
   val s = if true then "yes" else "no"
in
   val x: 'a t = A s
end</programlisting>
<simpara>The following example (taken from <link linkend="References_Wright95">Wright95</link>) creates a ref
cell to count the number of times a function is called.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val count: ('a -&gt; 'a) -&gt; ('a -&gt; 'a) * (unit -&gt; int) =
   fn f =&gt;
   let
      val r = ref 0
   in
      (fn x =&gt; (r := 1 + !r; f x), fn () =&gt; !r)
   end
val id: 'a -&gt; 'a = fn x =&gt; x
val (countId: 'a -&gt; 'a, numCalls) = count id</programlisting>
<simpara>The example does not type check, due to the value restriction.
However, it is easy to rewrite the program, staging the ref cell
creation before the polymorphic code.</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = T of int ref
val count1: unit -&gt; t = fn () =&gt; T (ref 0)
val count2: t * ('a -&gt; 'a) -&gt; (unit -&gt; int) * ('a -&gt; 'a) =
   fn (T r, f) =&gt; (fn () =&gt; !r, fn x =&gt; (r := 1 + !r; f x))
val id: 'a -&gt; 'a = fn x =&gt; x
val t = count1 ()
val countId: 'a -&gt; 'a = fn z =&gt; #2 (count2 (t, id)) z
val numCalls = #1 (count2 (t, id))</programlisting>
<simpara>Of course, one can hide the constructor <literal>T</literal> inside a <literal>local</literal> or behind
a signature.</simpara>
</section>
<section id="_also_see_50">
<title>Also see</title>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ImperativeTypeVariable">ImperativeTypeVariable</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="VariableArityPolymorphism">
<title>VariableArityPolymorphism</title>
<simpara><link linkend="StandardML">Standard ML</link> programmers often face the problem of how to
provide a variable-arity polymorphic function.  For example, suppose
one is defining a combinator library, e.g. for parsing or pickling.
The signature for such a library might look something like the
following.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature COMBINATOR =
   sig
      type 'a t

      val int: int t
      val real: real t
      val string: string t
      val unit: unit t
      val tuple2: 'a1 t * 'a2 t -&gt; ('a1 * 'a2) t
      val tuple3: 'a1 t * 'a2 t * 'a3 t -&gt; ('a1 * 'a2 * 'a3) t
      val tuple4: 'a1 t * 'a2 t * 'a3 t * 'a4 t
                  -&gt; ('a1 * 'a2 * 'a3 * 'a4) t
      ...
   end</programlisting>
<simpara>The question is how to define a variable-arity tuple combinator.
Traditionally, the only way to take a variable number of arguments in
SML is to put the arguments in a list (or vector) and pass that.  So,
one might define a tuple combinator with the following signature.</simpara>
<programlisting language="sml" linenumbering="unnumbered">val tupleN: 'a list -&gt; 'a list t</programlisting>
<simpara>The problem with this approach is that as soon as one places values in
a list, they must all have the same type.  So, programmers often take
an alternative approach, and define a family of <literal>tuple&lt;N&gt;</literal> functions,
as we see in the <literal>COMBINATOR</literal> signature above.</simpara>
<simpara>The family-of-functions approach is ugly for many reasons.  First, it
clutters the signature with a number of functions when there should
really only be one.  Second, it is <emphasis>closed</emphasis>, in that there are a fixed
number of tuple combinators in the interface, and should a client need
a combinator for a large tuple, he is out of luck.  Third, this
approach often requires a lot of duplicate code in the implementation
of the combinators.</simpara>
<simpara>Fortunately, using <link linkend="Fold01N">Fold01N</link> and <link linkend="ProductType">products</link>, one can
provide an interface and implementation that solves all these
problems.  Here is a simple pickling module that converts values to
strings.</simpara>
<programlisting language="sml" linenumbering="unnumbered">structure Pickler =
   struct
      type 'a t = 'a -&gt; string

      val unit = fn () =&gt; ""

      val int = Int.toString

      val real = Real.toString

      val string = id

      type 'a accum = 'a * string list -&gt; string list

      val tuple =
         fn z =&gt;
         Fold01N.fold
         {finish = fn ps =&gt; fn x =&gt; concat (rev (ps (x, []))),
          start = fn p =&gt; fn (x, l) =&gt; p x :: l,
          zero = unit}
         z

      val ` =
         fn z =&gt;
         Fold01N.step1
         {combine = (fn (p, p') =&gt; fn (x &amp; x', l) =&gt; p' x' :: "," :: p (x, l))}
         z
   end</programlisting>
<simpara>If one has <literal>n</literal> picklers of types</simpara>
<programlisting language="sml" linenumbering="unnumbered">val p1: a1 Pickler.t
val p2: a2 Pickler.t
...
val pn: an Pickler.t</programlisting>
<simpara>then one can construct a pickler for n-ary products as follows.</simpara>
<programlisting language="sml" linenumbering="unnumbered">tuple `p1 `p2 ... `pn $ : (a1 &amp; a2 &amp; ... &amp; an) Pickler.t</programlisting>
<simpara>For example, with <literal>Pickler</literal> in scope, one can prove the following
equations.</simpara>
<programlisting language="sml" linenumbering="unnumbered">"" = tuple $ ()
"1" = tuple `int $ 1
"1,2.0" = tuple `int `real $ (1 &amp; 2.0)
"1,2.0,three" = tuple `int `real `string $ (1 &amp; 2.0 &amp; "three")</programlisting>
<simpara>Here is the signature for <literal>Pickler</literal>.  It shows why the <literal>accum</literal> type is
useful.</simpara>
<programlisting language="sml" linenumbering="unnumbered">signature PICKLER =
   sig
      type 'a t

      val int: int t
      val real: real t
      val string: string t
      val unit: unit t

      type 'a accum
      val ` : ('a accum, 'b t, ('a, 'b) prod accum,
               'z1, 'z2, 'z3, 'z4, 'z5, 'z6, 'z7) Fold01N.step1
      val tuple: ('a t, 'a accum, 'b accum, 'b t, unit t,
                  'z1, 'z2, 'z3, 'z4, 'z5) Fold01N.t
   end

structure Pickler: PICKLER = Pickler</programlisting>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="Variant">
<title>Variant</title>
<simpara>A <emphasis>variant</emphasis> is an arm of a datatype declaration.  For example, the
datatype</simpara>
<programlisting language="sml" linenumbering="unnumbered">datatype t = A | B of int | C of real</programlisting>
<simpara>has three variants: <literal>A</literal>, <literal>B</literal>, and <literal>C</literal>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="VesaKarvonen">
<title>VesaKarvonen</title>
<simpara>Vesa Karvonen is a student at the <ulink url="http://www.cs.helsinki.fi/index.en.html">University of Helsinki</ulink>.
His interests lie in programming techniques that allow complex programs to be expressed
clearly and concisely and the design and implementation of programming languages.</simpara>
<informalfigure>
<mediaobject>
  <imageobject>
  <imagedata fileref="VesaKarvonen.attachments/vesa-in-mlton-t-shirt.jpg" align="center"/>
  </imageobject>
  <textobject><phrase>VesaKarvonen.attachments/vesa-in-mlton-t-shirt.jpg</phrase></textobject>
</mediaobject>
</informalfigure>
<simpara>Things he&#8217;d like to see for SML and hopes to be able to contribute towards:</simpara>
<itemizedlist>
<listitem>
<simpara>
A practical tool for documenting libraries. Preferably one that is
based on extracting the documentation from source code comments.
</simpara>
</listitem>
<listitem>
<simpara>
A good IDE. Possibly an enhanced SML mode (<literal>esml-mode</literal>) for Emacs.
Google for <ulink url="http://www.google.com/search?&amp;q=SLIME+video">SLIME video</ulink> to
get an idea of what he&#8217;d like to see. Some specific notes:
</simpara>
<itemizedlist>
<listitem>
<simpara>
show type at point
</simpara>
</listitem>
<listitem>
<simpara>
robust, consistent indentation
</simpara>
</listitem>
<listitem>
<simpara>
show documentation
</simpara>
</listitem>
<listitem>
<simpara>
jump to definition (see <link linkend="EmacsDefUseMode">EmacsDefUseMode</link>)
</simpara>
</listitem>
</itemizedlist>
<simpara><link linkend="EmacsBgBuildMode">EmacsBgBuildMode</link> has also been written for working with MLton.</simpara>
</listitem>
<listitem>
<simpara>
Documented and cataloged libraries. Perhaps something like
<ulink url="http://www.boost.org">Boost</ulink>, but for SML libraries.  Here is a partial
list of libraries, tools, and frameworks Vesa is or has been working
on:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Asynchronous Programming Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/async/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Extended Basis Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/extended-basis/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Generic Programming Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/generic/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Pretty Printing Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/prettier/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Random Generator Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/random/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
RPC (Remote Procedure Call) Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/org/mlton/vesak/rpc-lib/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.libsdl.org/">SDL</ulink> Binding (<ulink url="https://github.com/MLton/mltonlib/blob/master/org/mlton/vesak/sdl/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Unit Testing Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/unit-test/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Use Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/org/mlton/vesak/use-lib/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
<listitem>
<simpara>
Windows Library (<ulink url="https://github.com/MLton/mltonlib/blob/master/com/ssh/windows/unstable/README"><literal>README</literal></ulink>)
</simpara>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<simpara>Note that most of these libraries have been ported to several <link linkend="StandardMLImplementations">SML implementations</link>.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="WarnUnusedAnomalies">
<title>WarnUnusedAnomalies</title>
<simpara>The <literal>warnUnused</literal> <link linkend="MLBasisAnnotations">MLBasis annotation</link> can be used
to report unused identifiers.  This can be useful for catching bugs
and for code maintenance (e.g., eliminating dead code).  However, the
<literal>warnUnused</literal> annotation can sometimes behave in counter-intuitive
ways.  This page gives some of the anomalies that have been reported.</simpara>
<itemizedlist>
<listitem>
<simpara>
Functions whose only uses are recursive uses within their bodies are
not warned as unused:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">local
fun foo () = foo () : unit
val bar = let fun baz () = baz () : unit in baz end
in
end</programlisting>
<screen>Warning: z.sml 3.5.
  Unused variable: bar.</screen>
</listitem>
<listitem>
<simpara>
Components of actual functor argument that are necessary to match
the functor argument signature but are unused in the body of the
functor are warned as unused:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor Warning (type t val x : t) = struct
   val y = x
end
structure X = Warning (type t = int val x = 1)</programlisting>
<screen>Warning: z.sml 4.29.
  Unused type: t.</screen>
</listitem>
<listitem>
<simpara>
No component of a functor result is warned as unused.  In the
following, the only uses of <literal>f2</literal> are to match the functor argument
signatures of <literal>functor G</literal> and <literal>functor H</literal> and there are no uses of
<literal>z</literal>:
</simpara>
<programlisting language="sml" linenumbering="unnumbered">functor F(structure X : sig type t end) = struct
   type t = X.t
   fun f1 (_ : X.t) = ()
   fun f2 (_ : X.t) = ()
   val z = ()
end
functor G(structure Y : sig
                           type t
                           val f1 : t -&gt; unit
                           val f2 : t -&gt; unit
                           val z : unit
                        end) = struct
   fun g (x : Y.t) = Y.f1 x
end
functor H(structure Y : sig
                           type t
                           val f1 : t -&gt; unit
                           val f2 : t -&gt; unit
                           val z : unit
                        end) = struct
   fun h (x : Y.t) = Y.f1 x
end
functor Z() = struct
   structure S = F(structure X = struct type t = unit end)
   structure SG = G(structure Y = S)
   structure SH = H(structure Y = S)
end
structure U = Z()
val _ = U.SG.g ()
val _ = U.SH.h ()</programlisting>
<screen></screen>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="WesleyTerpstra">
<title>WesleyTerpstra</title>
<simpara>Wesley W. Terpstra is a PhD student at the Technische Universitat Darmstadt (Germany).</simpara>
<simpara>Research interests</simpara>
<itemizedlist>
<listitem>
<simpara>
Distributed systems (P2P)
</simpara>
</listitem>
<listitem>
<simpara>
Number theory (Error-correcting codes)
</simpara>
</listitem>
</itemizedlist>
<simpara>My interest in SML is centered on the fact the the language is able to directly express ideas from number theory which are important for my work. Modules and Functors seem to be a very natural basis for implementing many algebraic structures. MLton provides an ideal platform for actual implementation as it is fast and has unboxed words.</simpara>
<simpara>Things I would like from MLton in the future:</simpara>
<itemizedlist>
<listitem>
<simpara>
Some better optimization of mathematical expressions
</simpara>
</listitem>
<listitem>
<simpara>
IPv6 and multicast support
</simpara>
</listitem>
<listitem>
<simpara>
A complete GUI toolkit like mGTK
</simpara>
</listitem>
<listitem>
<simpara>
More supported platforms so that applications written under MLton have a wider audience
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="WholeProgramOptimization">
<title>WholeProgramOptimization</title>
<simpara>Whole-program optimization is a compilation technique in which
optimizations operate over the entire program.  This allows the
compiler many optimization opportunities that are not available when
analyzing modules separately (as with separate compilation).</simpara>
<simpara>Most of MLton&#8217;s optimizations are whole-program optimizations.
Because MLton compiles the whole program at once, it can perform
optimization across module boundaries.  As a consequence, MLton often
reduces or eliminates the run-time penalty that arises with separate
compilation of SML features such as functors, modules, polymorphism,
and higher-order functions.  MLton takes advantage of having the
entire program to perform transformations such as: defunctorization,
monomorphisation, higher-order control-flow analysis, inlining,
unboxing, argument flattening, redundant-argument removal, constant
folding, and representation selection.  Whole-program compilation is
an integral part of the design of MLton and is not likely to change.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="WishList">
<title>WishList</title>
<simpara>This page is mainly for recording recurring feature requests.  If you
have a new feature request, you probably want to query interest on one
of the <link linkend="Contact">mailing lists</link> first.</simpara>
<simpara>Please be aware of MLton&#8217;s policy on
<link linkend="LanguageChanges">language changes</link>.  Nonetheless, we hope to provide
support for some of the "immediate" <link linkend="SuccessorML">SuccessorML</link> proposals in a
future release.</simpara>
<section id="_support_for_link_options_in_ml_basis_files">
<title>Support for link options in ML Basis files</title>
<simpara>Introduce a mechanism to specify link options in <link linkend="MLBasis">ML Basis</link>
files.  For example, generalizing a bit, a ML Basis declaration of the
form</simpara>
<screen>option "option"</screen>
<simpara>could be introduced whose semantics would be the same (as closely as
possible) as if the option string were specified on the compiler
command line.</simpara>
<simpara>The main motivation for this is that a MLton library that would
introduce bindings (through <link linkend="ForeignFunctionInterface">FFI</link>) to an
external library could be packaged conveniently as a single MLB file.
For example, to link with library <literal>foo</literal> the MLB file would simply
contain:</simpara>
<screen>option "-link-opt -lfoo"</screen>
<simpara>Similar feature requests have been discussed previously on the mailing lists:</simpara>
<itemizedlist>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2004-July/025553.html">http://www.mlton.org/pipermail/mlton/2004-July/025553.html</ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="http://www.mlton.org/pipermail/mlton/2005-January/026648.html">http://www.mlton.org/pipermail/mlton/2005-January/026648.html</ulink>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="XML">
<title>XML</title>
<simpara><link linkend="XML">XML</link> is an <link linkend="IntermediateLanguage">IntermediateLanguage</link>, translated from <link linkend="CoreML">CoreML</link> by
<link linkend="Defunctorize">Defunctorize</link>, optimized by <link linkend="XMLSimplify">XMLSimplify</link>, and translated by
<link linkend="Monomorphise">Monomorphise</link> to <link linkend="SXML">SXML</link>.</simpara>
<section id="_description_65">
<title>Description</title>
<simpara><link linkend="XML">XML</link> is polymorphic, higher-order, with flat patterns.  Every
<link linkend="XML">XML</link> expression is annotated with its type.  Polymorphic
generalization is made explicit through type variables annotating
<literal>val</literal> and <literal>fun</literal> declarations.  Polymorphic instantiation is made
explicit by specifying type arguments at variable references.  <link linkend="XML">XML</link>
patterns can not be nested and can not contain wildcards, constraints,
flexible records, or layering.</simpara>
</section>
<section id="_implementation_71">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/xml.sig"><literal>xml.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/xml.fun"><literal>xml.fun</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/xml-tree.sig"><literal>xml-tree.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/xml-tree.fun"><literal>xml-tree.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_type_checking_8">
<title>Type Checking</title>
<simpara><link linkend="XML">XML</link> also has a type checker, used for debugging.  At present, the
type checker is also the best specification of the type system of
<link linkend="XML">XML</link>.  If you need more details, the type checker
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/type-check.sig"><literal>type-check.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/type-check.fun"><literal>type-check.fun</literal></ulink>), is pretty short.</simpara>
<simpara>Since the type checker does not affect the output of the compiler
(unless it reports an error), it can be turned off.  The type checker
recursively descends the program, checking that the type annotating
each node is the same as the type synthesized from the types of the
expressions subnodes.</simpara>
</section>
<section id="_details_and_notes_68">
<title>Details and Notes</title>
<simpara><link linkend="XML">XML</link> uses the same atoms as <link linkend="CoreML">CoreML</link>, hence all identifiers
(constructors, variables, etc.) are unique and can have properties
attached to them.  Finally, <link linkend="XML">XML</link> has a simplifier (<link linkend="XMLShrink">XMLShrink</link>),
which implements a reduction system.</simpara>
<section id="_types_3">
<title>Types</title>
<simpara><link linkend="XML">XML</link> types are either type variables or applications of n-ary type
constructors.  There are many utility functions for constructing and
destructing types involving built-in type constructors.</simpara>
<simpara>A type scheme binds list of type variables in a type.  The only
interesting operation on type schemes is the application of a type
scheme to a list of types, which performs a simultaneous substitution
of the type arguments for the bound type variables of the scheme.  For
the purposes of type checking, it is necessary to know the type scheme
of variables, constructors, and primitives.  This is done by
associating the scheme with the identifier using its property list.
This approach is used instead of the more traditional environment
approach for reasons of speed.</simpara>
</section>
<section id="_xmltree">
<title>XmlTree</title>
<simpara>Before defining <literal>XML</literal>, the signature for language <link linkend="XML">XML</link>, we need to
define an auxiliary signature <literal>XML_TREE</literal>, that contains the datatype
declarations for the expression trees of <link linkend="XML">XML</link>.  This is done solely
for the purpose of modularity&#8201;&#8212;&#8201;it allows the simplifier and type
checker to be defined by separate functors (which take a structure
matching <literal>XML_TREE</literal>).  Then, <literal>Xml</literal> is defined as the signature for a
module containing the expression trees, the simplifier, and the type
checker.</simpara>
<simpara>Both constructors and variables can have type schemes, hence both
constructor and variable references specify the instance of the scheme
at the point of references.  An instance is specified with a vector of
types, which corresponds to the type variables in the scheme.</simpara>
<simpara><link linkend="XML">XML</link> patterns are flat (i.e. not nested).  A pattern is a
constructor with an optional argument variable.  Patterns only occur
in <literal>case</literal> expressions.  To evaluate a case expression, compare the
test value sequentially against each pattern.  For the first pattern
that matches, destruct the value if necessary to bind the pattern
variables and evaluate the corresponding expression.  If no pattern
matches, evaluate the default.  All patterns of a case statement are
of the same variant of <literal>Pat.t</literal>, although this is not enforced by ML&#8217;s
type system.  The type checker, however, does enforce this.  Because
tuple patterns are irrefutable, there will only ever be one tuple
pattern in a case expression and there will be no default.</simpara>
<simpara><link linkend="XML">XML</link> contains value, exception, and mutually recursive function
declarations.  There are no free type variables in <link linkend="XML">XML</link>.  All type
variables are explicitly bound at either a value or function
declaration.  At some point in the future, exception declarations may
go away, and exceptions may be represented with a single datatype
containing a <literal>unit ref</literal> component to implement genericity.</simpara>
<simpara><link linkend="XML">XML</link> expressions are like those of <link linkend="CoreML">CoreML</link>, with the following
exceptions.  There are no records expressions.  After type inference,
all records (some of which may have originally been tuples in the
source) are converted to tuples, because once flexible record patterns
have been resolved, tuple labels are superfluous.  Tuple components
are ordered based on the field ordering relation.  <link linkend="XML">XML</link> eta expands
primitives and constructors so that there are always fully applied.
Hence, the only kind of value of arrow type is a lambda.  This
property is useful for flow analysis and later in code generation.</simpara>
<simpara>An <link linkend="XML">XML</link> program is a list of toplevel datatype declarations and a
body expression.  Because datatype declarations are not generative,
the defunctorizer can safely move them to toplevel.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
</section>
<section id="XMLShrink">
<title>XMLShrink</title>
<simpara>XMLShrink is an optimization pass for the <link linkend="XML">XML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="XMLSimplify">XMLSimplify</link>.</simpara>
<section id="_description_66">
<title>Description</title>
<simpara>This pass performs optimizations based on a reduction system.</simpara>
</section>
<section id="_implementation_72">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/shrink.sig"><literal>shrink.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/shrink.fun"><literal>shrink.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_69">
<title>Details and Notes</title>
<simpara>The simplifier is based on <link linkend="References_AppelJim97">Shrinking Lambda Expressions in Linear Time</link>.</simpara>
<simpara>The source program may contain functions that are only called once, or
not even called at all.  Match compilation introduces many such
functions.  In order to reduce the program size, speed up later
phases, and improve the flow analysis, a source to source simplifier
is run on <link linkend="XML">XML</link> after type inference and match compilation.</simpara>
<simpara>The simplifier implements the reductions shown below.  The reductions
eliminate unnecessary declarations (see the side constraint in the
figure), applications where the function is immediate, and case
statements where the test is immediate.  Declarations can be
eliminated only when the expression is nonexpansive (see Section 4.7
of the <link linkend="DefinitionOfStandardML">Definition</link>), which is a syntactic
condition that ensures that the expression has no effects
(assignments, raises, or nontermination).  The reductions on case
statements do not show the other irrelevant cases that may exist.  The
reductions were chosen so that they were strongly normalizing and so
that they never increased tree size.</simpara>
<itemizedlist>
<listitem>
<simpara>
</simpara>
<programlisting language="sml" linenumbering="unnumbered">let x = e1 in e2</programlisting>
<simpara>reduces to</simpara>
<programlisting language="sml" linenumbering="unnumbered">e2 [x -&gt; e1]</programlisting>
<simpara>if <literal>e1</literal> is a constant or variable or if <literal>e1</literal> is nonexpansive and <literal>x</literal> occurs zero or one time in <literal>e2</literal></simpara>
</listitem>
<listitem>
<simpara>
</simpara>
<programlisting language="sml" linenumbering="unnumbered">(fn x =&gt; e1) e2</programlisting>
<simpara>reduces to</simpara>
<programlisting language="sml" linenumbering="unnumbered">let x = e2 in e1</programlisting>
</listitem>
<listitem>
<simpara>
</simpara>
<programlisting language="sml" linenumbering="unnumbered">e1 handle e2</programlisting>
<simpara>reduces to</simpara>
<programlisting language="sml" linenumbering="unnumbered">e1</programlisting>
<simpara>if <literal>e1</literal> is nonexpansive</simpara>
</listitem>
<listitem>
<simpara>
</simpara>
<programlisting language="sml" linenumbering="unnumbered">case let d in e end of p1 =&gt; e1 ...</programlisting>
<simpara>reduces to</simpara>
<programlisting language="sml" linenumbering="unnumbered">let d in case e of p1 =&gt; e1 ... end</programlisting>
</listitem>
<listitem>
<simpara>
</simpara>
<programlisting language="sml" linenumbering="unnumbered">case C e1 of C x =&gt; e2</programlisting>
<simpara>reduces to</simpara>
<programlisting language="sml" linenumbering="unnumbered">let x = e1 in e2</programlisting>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="XMLSimplify">
<title>XMLSimplify</title>
<simpara>The optimization passes for the <link linkend="XML">XML</link> <link linkend="IntermediateLanguage">IntermediateLanguage</link> are
collected and controlled by the <literal>XmlSimplify</literal> functor
(<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/xml-simplify.sig"><literal>xml-simplify.sig</literal></ulink>,
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/xml-simplify.fun"><literal>xml-simplify.fun</literal></ulink>).</simpara>
<simpara>The following optimization passes are implemented:</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="XMLSimplifyTypes">XMLSimplifyTypes</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="XMLShrink">XMLShrink</link>
</simpara>
</listitem>
</itemizedlist>
<simpara>The optimization passes can be controlled from the command-line by the options</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-diag-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep diagnostic info for pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-disable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;skip optimization pass (if normally performed)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-enable-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;perform optimization pass (if normally skipped)
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-keep-pass &lt;pass&gt;</literal>&#8201;&#8212;&#8201;keep the results of pass
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-xml-passes &lt;passes&gt;</literal>&#8201;&#8212;&#8201;xml optimization passes
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
<section id="XMLSimplifyTypes">
<title>XMLSimplifyTypes</title>
<simpara><link linkend="XMLSimplifyTypes">XMLSimplifyTypes</link> is an optimization pass for the <link linkend="XML">XML</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="XMLSimplify">XMLSimplify</link>.</simpara>
<section id="_description_67">
<title>Description</title>
<simpara>This pass simplifies types in an <link linkend="XML">XML</link> program, eliminating all
unused type arguments.</simpara>
</section>
<section id="_implementation_73">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/simplify-types.sig"><literal>simplify-types.sig</literal></ulink>
</simpara>
</listitem>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/xml/simplify-types.fun"><literal>simplify-types.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_70">
<title>Details and Notes</title>
<simpara>It first computes a simple fixpoint on all the <literal>datatype</literal> declarations
to determine which <literal>datatype</literal> <literal>tycon</literal> args are actually used.  Then it
does a single pass over the program to determine which polymorphic
declaration type variables are used, and rewrites types to eliminate
unused type arguments.</simpara>
<simpara>This pass should eliminate any spurious duplication that the
<link linkend="Monomorphise">Monomorphise</link> pass might perform due to phantom types.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="Zone">
<title>Zone</title>
<simpara><link linkend="Zone">Zone</link> is an optimization pass for the <link linkend="SSA2">SSA2</link>
<link linkend="IntermediateLanguage">IntermediateLanguage</link>, invoked from <link linkend="SSA2Simplify">SSA2Simplify</link>.</simpara>
<section id="_description_68">
<title>Description</title>
<simpara>This pass breaks large <link linkend="SSA2">SSA2</link> functions into zones, which are
connected subgraphs of the dominator tree.  For each zone, at the node
that dominates the zone (the "zone root"), it places a tuple
collecting all of the live variables at that node.  It replaces any
variables used in that zone with offsets from the tuple.  The goal is
to decrease the liveness information in large <link linkend="SSA">SSA</link> functions.</simpara>
</section>
<section id="_implementation_74">
<title>Implementation</title>
<itemizedlist>
<listitem>
<simpara>
<ulink url="https://github.com/MLton/mlton/blob/master/mlton/ssa/zone.fun"><literal>zone.fun</literal></ulink>
</simpara>
</listitem>
</itemizedlist>
</section>
<section id="_details_and_notes_71">
<title>Details and Notes</title>
<simpara>Compute strongly-connected components to avoid put tuple constructions
in loops.</simpara>
<simpara>There are two (expert) flags that govern the use of this pass</simpara>
<itemizedlist>
<listitem>
<simpara>
<literal>-max-function-size &lt;n&gt;</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>-zone-cut-depth &lt;n&gt;</literal>
</simpara>
</listitem>
</itemizedlist>
<simpara>Zone splitting only works when the number of basic blocks in a
function is greater than <literal>n</literal>.  The <literal>n</literal> used to cut the dominator tree
is set by <literal>-zone-cut-depth</literal>.</simpara>
<simpara>There is currently no attempt to be safe-for-space.  That is, the
tuples are not restricted to containing only "small" values.</simpara>
<simpara>In the <literal>HOL</literal> program, the particular problem is the main function,
which has 161,783 blocks and 257,519 variables&#8201;&#8212;&#8201;the product of those
two numbers being about 41 billion.  Now, we&#8217;re not likely going to
need that much space since we use a sparse representation.  But even
1/100th would really hurt.  And of course this rules out bit vectors.</simpara>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</section>
<section id="ZZZOrphanedPages">
<title>ZZZOrphanedPages</title>
<simpara>The contents of these pages have been moved to other pages.</simpara>
<simpara>These templates are used by other pages.</simpara>
<itemizedlist>
<listitem>
<simpara>
<link linkend="CompilerPassTemplate">CompilerPassTemplate</link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="TalkTemplate">TalkTemplate</link>
</simpara>
</listitem>
</itemizedlist>
<simpara><?asciidoc-pagebreak?></simpara>
</section>
</article>