<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta name="robots" content="index,nofollow">



<title>StandardMLGotchas - MLton Standard ML Compiler (SML Compiler)</title>
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="all" href="common.css">
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="screen" href="screen.css">
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="print" href="print.css">


<link rel="Start" href="Home">


</head>

<body lang="en" dir="ltr">

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-833377-1";
urchinTracker();
</script>
<table bgcolor = lightblue cellspacing = 0 style = "border: 0px;" width = 100%>
  <tr>
    <td style = "
		border: 0px;
		color: darkblue; 
		font-size: 150%;
		text-align: left;">
      <a class = mltona href="Home">MLton 20061025</a>
    <td style = "
		border: 0px;
		font-size: 150%;
		text-align: center;
		width: 50%;">
      StandardMLGotchas
    <td style = "
		border: 0px;
		text-align: right;">
      <table cellspacing = 0 style = "border: 0px">
        <tr style = "vertical-align: middle;">
      </table>
  <tr style = "background-color: white;">
    <td colspan = 3
	style = "
		border: 0px;
		font-size:70%;
		text-align: right;">
      <a href = "Home">Home</a>
      &nbsp;<a href = "Index">Index</a>
      &nbsp;
</table>
<div id="content" lang="en" dir="ltr">
This page contains brief explanations of some recurring sources of confusion and problems that SML newbies encounter. <h4 id="head-d153f77b9f48402c9dba22f2ebe391ae24b06832">The and keyword</h4>
<p>
It is a common mistake to misuse the <tt>and</tt> keyword or to not know how to introduce mutually recursive definitions.  The purpose of the <tt>and</tt> keyword is to introduce mutually recursive definitions of functions and datatypes.  For example, 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">isEven</FONT></I></B></FONT></B> 0w0 <B><FONT COLOR="#5F9EA0">=</FONT></B> true
  <B><FONT COLOR="#5F9EA0">|</FONT></B> isEven 0w1 <B><FONT COLOR="#5F9EA0">=</FONT></B> false
  <B><FONT COLOR="#5F9EA0">|</FONT></B> isEven n <B><FONT COLOR="#5F9EA0">=</FONT></B> isOdd (n<B><FONT COLOR="#5F9EA0">-</FONT></B>0w1)
<B><FONT COLOR="#A020F0">and</FONT></B> isOdd 0w0 <B><FONT COLOR="#5F9EA0">=</FONT></B> false
  <B><FONT COLOR="#5F9EA0">|</FONT></B> isOdd 0w1 <B><FONT COLOR="#5F9EA0">=</FONT></B> true
  <B><FONT COLOR="#5F9EA0">|</FONT></B> isOdd n <B><FONT COLOR="#5F9EA0">=</FONT></B> isEven (n<B><FONT COLOR="#5F9EA0">-</FONT></B>0w1)
</PRE>
<p>
 
</p>
<p>
and 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">datatype</FONT></B> decl <B><FONT COLOR="#5F9EA0">=</FONT></B> VAL <B><FONT COLOR="#A020F0">of</FONT></B> id <B><FONT COLOR="#5F9EA0">*</FONT></B> pat <B><FONT COLOR="#5F9EA0">*</FONT></B> expr
           <I><FONT COLOR="#B22222">(* | ... *)</FONT></I>
     <B><FONT COLOR="#A020F0">and</FONT></B> expr <B><FONT COLOR="#5F9EA0">=</FONT></B> LET <B><FONT COLOR="#A020F0">of</FONT></B> decl <B><FONT COLOR="#5F9EA0">*</FONT></B> expr
           <I><FONT COLOR="#B22222">(* | ... *)</FONT></I>
</PRE>
<p>
 
</p>
<p>
You can also use <tt>and</tt> as a shorthand in a couple of other places, but it is not obligatory. 
</p>
<h4 id="head-b73586d63b2830f6d817e9b9150d4be4bdb9b049">Constructed patterns</h4>
<p>
It is a common mistake to forget to parenthesize constructed patterns in <tt>fun</tt> bindings.  Consider the following invalid definition: 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">length</FONT></I></B></FONT></B> nil <B><FONT COLOR="#5F9EA0">=</FONT></B> 0
  <B><FONT COLOR="#5F9EA0">|</FONT></B> length h <B><FONT COLOR="#5F9EA0">::</FONT></B> t <B><FONT COLOR="#5F9EA0">=</FONT></B> 1 <B><FONT COLOR="#5F9EA0">+</FONT></B> length t
</PRE>
<p>
 
</p>
<p>
The pattern <tt>h&nbsp;::&nbsp;t</tt> needs to be parenthesized: 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">length</FONT></I></B></FONT></B> nil <B><FONT COLOR="#5F9EA0">=</FONT></B> 0
  <B><FONT COLOR="#5F9EA0">|</FONT></B> length (h <B><FONT COLOR="#5F9EA0">::</FONT></B> t) <B><FONT COLOR="#5F9EA0">=</FONT></B> 1 <B><FONT COLOR="#5F9EA0">+</FONT></B> length t
</PRE>
<p>
 
</p>
<p>
The parentheses are needed, because a <tt>fun</tt> definition may specify multiple curried formal parameters. 
</p>
<p>
The same applies to nonfix constructors.  For example, the parentheses in 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">valOf</FONT></I></B></FONT></B> <B><FONT COLOR="#5F9EA0">NONE</FONT></B> <B><FONT COLOR="#5F9EA0">=</FONT></B> <B><FONT COLOR="#A020F0">raise</FONT></B> Option
  <B><FONT COLOR="#5F9EA0">|</FONT></B> valOf (<B><FONT COLOR="#5F9EA0">SOME</FONT></B> x) <B><FONT COLOR="#5F9EA0">=</FONT></B> x
</PRE>
<p>
 
</p>
<p>
are required.  However, the outermost constructed pattern in a <tt>fn</tt> or <tt>case</tt> expression need not be parenthesized.  Both 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">val</FONT></B> valOf <B><FONT COLOR="#5F9EA0">=</FONT></B> <B><FONT COLOR="#A020F0">fn</FONT></B> <B><FONT COLOR="#5F9EA0">NONE</FONT></B> <B><FONT COLOR="#5F9EA0">=</FONT></B><B><FONT COLOR="#5F9EA0">&gt;</FONT></B> <B><FONT COLOR="#A020F0">raise</FONT></B> Option
             <B><FONT COLOR="#5F9EA0">|</FONT></B> <B><FONT COLOR="#5F9EA0">SOME</FONT></B> x <B><FONT COLOR="#5F9EA0">=</FONT></B><B><FONT COLOR="#5F9EA0">&gt;</FONT></B> x
</PRE>
<p>
 
</p>
<p>
and 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">valOf</FONT></I></B></FONT></B> x <B><FONT COLOR="#5F9EA0">=</FONT></B> <B><FONT COLOR="#A020F0">case</FONT></B> x <B><FONT COLOR="#A020F0">of</FONT></B>
                 <B><FONT COLOR="#5F9EA0">NONE</FONT></B> <B><FONT COLOR="#5F9EA0">=</FONT></B><B><FONT COLOR="#5F9EA0">&gt;</FONT></B> <B><FONT COLOR="#A020F0">raise</FONT></B> Option
               <B><FONT COLOR="#5F9EA0">|</FONT></B> <B><FONT COLOR="#5F9EA0">SOME</FONT></B> x <B><FONT COLOR="#5F9EA0">=</FONT></B><B><FONT COLOR="#5F9EA0">&gt;</FONT></B> x
</PRE>
<p>
 
</p>
<p>
are fine. 
</p>
<h4 id="head-8ab1923fa5e92fee24951419e65f282dd12cf824">Declarations and expressions</h4>
<p>
It is a common mistake to confuse expressions and declarations.  Normally a SML source file should only contain declarations.  The following are declarations: 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">datatype</FONT></B> dt <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">f</FONT></I></B></FONT></B> ... <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
<B><FONT COLOR="#5F9EA0">functor</FONT></B> Fn (...) <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
<B><FONT COLOR="#A020F0">infix</FONT></B> ...
<B><FONT COLOR="#A020F0">infixr</FONT></B> ...
<B><FONT COLOR="#A020F0">local</FONT></B> ... <B><FONT COLOR="#A020F0">in</FONT></B> ... <B><FONT COLOR="#A020F0">end</FONT></B>
<B><FONT COLOR="#A020F0">nonfix</FONT></B> ...
<B><FONT COLOR="#A020F0">open</FONT></B> ...
<B><FONT COLOR="#5F9EA0">signature</FONT></B> SIG <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
<B><FONT COLOR="#5F9EA0">structure</FONT></B> Struct <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
<B><FONT COLOR="#A020F0">type</FONT></B> t <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
<B><FONT COLOR="#A020F0">val</FONT></B> v <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
</PRE>
<p>
 
</p>
<p>
Note that 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">let</FONT></B> ... <B><FONT COLOR="#A020F0">in</FONT></B> ... <B><FONT COLOR="#A020F0">end</FONT></B>
</PRE>
<p>
 
</p>
<p>
isn't a declaration. 
</p>
<p>
To specify a side-effecting computation in a source file, you can write: 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">val</FONT></B> () <B><FONT COLOR="#5F9EA0">=</FONT></B> ...
</PRE>
<p>
 
</p>
<h4 id="head-72f187fcc8b266cbc48f0060c51c75d2448f865c">Equality types</h4>
<p>
SML has a fairly intricate built-in notion of equality.  See <a href="EqualityType">EqualityType</a> and <a href="EqualityTypeVariable">EqualityTypeVariable</a> for a thorough discussion. 
</p>
<h4 id="head-04f8ae45c52f8b12ec8a7fe6650fd9d29cf11660">Nested cases</h4>
<p>
It is a common mistake to write nested case expressions without the necessary parentheses.  See <a href="UnresolvedBugs">UnresolvedBugs</a> for a discussion. 
</p>
<h4 id="head-4d2e5cf4124c665b4ee3f17586873d386091b28e">(op *)</h4>
<p>
It used to be a common mistake to parenthesize <tt>op&nbsp;*</tt> as <tt>(op&nbsp;*)</tt>. Before SML'97, <tt>*)</tt> was considered a comment terminator in SML and caused a syntax error.  At the time of writing, <a href="SMLNJ">SML/NJ</a> still rejects the code.  An extra space may be used for portability: <tt>(op&nbsp;*&nbsp;)</tt>. However, parenthesizing <tt>op</tt> is redundant, even though it is a widely used convention. 
</p>
<h4 id="head-cb2f163ccc20cb7388203cf1edbc6860b44ea0f0">Overloading</h4>
<p>
A number of standard operators (<tt>+</tt>, <tt>-</tt>, <tt>~</tt>, <tt>*</tt>, <tt>&lt;</tt>, <tt>&gt;</tt>, ...) and numeric constants are overloaded for some of the numeric types (<tt>int</tt>, <tt>real</tt>, <tt>word</tt>).  It is a common surprise that definitions using overloaded operators such as 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">fun </FONT></B><B><FONT COLOR="#0000FF"><B><I><FONT COLOR="#000000">min</FONT></I></B></FONT></B> (x, y) <B><FONT COLOR="#5F9EA0">=</FONT></B> <B><FONT COLOR="#A020F0">if</FONT></B> y &lt; x <B><FONT COLOR="#A020F0">then</FONT></B> y <B><FONT COLOR="#A020F0">else</FONT></B> x
</PRE>
<p>
 
</p>
<p>
are not overloaded themselves.  SML doesn't really support (user-defined) overloading or other forms of ad hoc polymorphism.  In cases such as the above where the context doesn't resolve the overloading, expressions using overloaded operators or constants get assigned a default type.  The above definition gets the type 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">val</FONT></B> min : <B><FONT COLOR="#228B22">int</FONT></B> <B><FONT COLOR="#5F9EA0">*</FONT></B> <B><FONT COLOR="#228B22">int</FONT></B> <B><FONT COLOR="#5F9EA0">-</FONT></B><B><FONT COLOR="#5F9EA0">&gt;</FONT></B> <B><FONT COLOR="#228B22">int</FONT></B>
</PRE>
<p>
 
</p>
<p>
See <a href="Overloading">Overloading</a> and <a href="TypeIndexedValues">TypeIndexedValues</a> for further discussion. 
</p>
<h4 id="head-1158dc6391ca1c282b0274da233e5b47974ab44c">Semicolons</h4>
<p>
It is a common mistake to use redundant semicolons in SML code.  This is probably caused by the fact that in a SML REPL, a semicolon (and enter) is used to signal the implementation 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 
</p>

<pre class=code>
(exp ; ... ; exp)
</PRE>
<p>
 
</p>
<p>
and 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">let</FONT></B> ... <B><FONT COLOR="#A020F0">in</FONT></B> exp ; ... ; exp <B><FONT COLOR="#A020F0">end</FONT></B>
</PRE>
<p>
 
</p>
<h4 id="head-72e54dc34abda1fd4474891b84fd2cdee65e658e">Stale bindings</h4>
<h4 id="head-80eea6d8744ff759ee13086143a80641754b67b7">Unresolved records</h4>
<h4 id="head-403e61388aa56bd37081a03b6455c2a4b2991e43">Value restriction</h4>
<p>
See <a href="ValueRestriction">ValueRestriction</a>. 
</p>
</div>



<p>
<hr>
Last edited on 2006-08-14 10:17:53 by <span title="www-cache2.hel.fi.ssh.com"><a href="VesaKarvonen">VesaKarvonen</a></span>.
</body></html>
