/usr/share/doc/mlton/guide/StandardMLGotchas is in mlton-doc 20100608-5.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 | <!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 MLTONWIKIVERSION</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>
<a href = "TitleIndex">Index</a>
</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. <p>
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.
</p>
<h4 id="head-d685d6ac284370652bba2e2a7d86c4399c393136">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> isEven <B><FONT COLOR="#5F9EA0">0w0</FONT></B> = true
| isEven <B><FONT COLOR="#5F9EA0">0w1</FONT></B> = false
| isEven n = isOdd (n-<B><FONT COLOR="#5F9EA0">0w1</FONT></B>)
<B><FONT COLOR="#A020F0">and</FONT></B> isOdd <B><FONT COLOR="#5F9EA0">0w0</FONT></B> = false
| isOdd <B><FONT COLOR="#5F9EA0">0w1</FONT></B> = true
| isOdd n = isEven (n-<B><FONT COLOR="#5F9EA0">0w1</FONT></B>)
</PRE>
<p>
</p>
<p>
and
</p>
<pre class=code>
<B><FONT COLOR="#A020F0">datatype</FONT></B><B><FONT COLOR="#228B22"> decl </FONT></B>=<B><FONT COLOR="#228B22"> <FONT COLOR="#B8860B">VAL</FONT> <B><FONT COLOR="#A020F0">of</FONT></B> id * pat * expr
<I><FONT COLOR="#B22222">(* | ... *)</FONT></I>
</FONT></B><B><FONT COLOR="#A020F0">and</FONT></B><B><FONT COLOR="#228B22"> expr </FONT></B>=<B><FONT COLOR="#228B22"> <FONT COLOR="#B8860B">LET</FONT> <B><FONT COLOR="#A020F0">of</FONT></B> decl * expr
<I><FONT COLOR="#B22222">(* | ... *)</FONT></I>
</FONT></B></PRE>
<p>
</p>
<p>
You can also use <tt>and</tt> as a shorthand in a couple of other places, but it is not necessary.
</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> length nil = <B><FONT COLOR="#5F9EA0">0</FONT></B>
| length h :: t = <B><FONT COLOR="#5F9EA0">1</FONT></B> + length t
</PRE>
<p>
</p>
<p>
The pattern <tt>h :: t</tt> needs to be parenthesized:
</p>
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> length nil = <B><FONT COLOR="#5F9EA0">0</FONT></B>
| length (h :: t) = <B><FONT COLOR="#5F9EA0">1</FONT></B> + length t
</PRE>
<p>
</p>
<p>
The parentheses are needed, because a <tt>fun</tt> definition may have multiple consecutive constructed patterns through currying.
</p>
<p>
The same applies to nonfix constructors. For example, the parentheses in
</p>
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> valOf NONE = <B><FONT COLOR="#A020F0">raise</FONT></B> Option
| valOf (SOME x) = 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, because in those cases there is always just one constructed pattern. So, both
</p>
<pre class=code>
<B><FONT COLOR="#A020F0">val</FONT></B> valOf = <B><FONT COLOR="#A020F0">fn</FONT></B> NONE => <B><FONT COLOR="#A020F0">raise</FONT></B> Option
| SOME x => x
</PRE>
<p>
</p>
<p>
and
</p>
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> valOf x = <B><FONT COLOR="#A020F0">case</FONT></B> x <B><FONT COLOR="#A020F0">of</FONT></B>
NONE => <B><FONT COLOR="#A020F0">raise</FONT></B> Option
| SOME x => 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 an SML source file should only contain declarations. The following are declarations:
</p>
<pre class=code>
<B><FONT COLOR="#A020F0">datatype</FONT></B><B><FONT COLOR="#228B22"> dt </FONT></B>=<B><FONT COLOR="#228B22"> </FONT></B>...
<B><FONT COLOR="#A020F0">fun</FONT></B> f ... = ...
<B><FONT COLOR="#0000FF">functor</FONT></B> Fn (...) = ...
<B><FONT COLOR="#A020F0">infix</FONT></B> ...
<B><FONT COLOR="#A020F0">infixr</FONT></B> ...
<B><FONT COLOR="#0000FF">local</FONT></B> ... <B><FONT COLOR="#0000FF">in</FONT></B> ... <B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#A020F0">nonfix</FONT></B> ...
<B><FONT COLOR="#0000FF">open</FONT></B> ...
<B><FONT COLOR="#0000FF">signature</FONT></B> SIG = ...
<B><FONT COLOR="#0000FF">structure</FONT></B> Struct = ...
<B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> t </FONT></B>=<B><FONT COLOR="#228B22"> </FONT></B>...
<B><FONT COLOR="#A020F0">val</FONT></B> v = ...
</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> () = ...
</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 *</tt> as <tt>(op *)</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 * )</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><</tt>, <tt>></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> min (x, y) = <B><FONT COLOR="#A020F0">if</FONT></B> y < 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 : int * int -> int
</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 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
</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>
<p>
Note that semicolons act as expression (or declaration) separators rather than as terminators.
</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>
<h4 id="head-2ae43ee231b8601d841d31e22732569161aeb94e">Type Variable Scope</h4>
<p>
See <a href="TypeVariableScope">TypeVariableScope</a>.
</p>
</div>
<p>
<hr>
Last edited on 2007-08-23 04:25:03 by <span title="c-71-57-91-146.hsd1.il.comcast.net"><a href="MatthewFluet">MatthewFluet</a></span>.
</body></html>
|