File: TypeChecking

package info (click to toggle)
mlton 20100608-5.1
  • links: PTS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 36,628 kB
  • ctags: 70,047
  • sloc: ansic: 18,441; lisp: 2,879; makefile: 1,572; sh: 1,326; pascal: 256; asm: 97
file content (209 lines) | stat: -rw-r--r-- 8,578 bytes parent folder | download | duplicates (3)
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
<!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>TypeChecking - 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%;">
      TypeChecking
    <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 = "TitleIndex">Index</a>
      &nbsp;
</table>
<div id="content" lang="en" dir="ltr">
MLton's type checker follows the <a href="DefinitionOfStandardML">Definition</a> 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 -- please see <a href="SMLNJDeviations">SMLNJDeviations</a> for those that we are aware of. <p>
In some respects MLton'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. 
</p>

    <ul>

    <li>
<p>
 MLton resolves flexible record patterns using a larger context than  many other SML compilers.  For example, MLton accepts the  following. 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> f {x, ...} = x
<B><FONT COLOR="#A020F0">val</FONT></B> _ = f {x = <B><FONT COLOR="#5F9EA0">13</FONT></B>, y = <B><FONT COLOR="#BC8F8F">&quot;foo&quot;</FONT></B>}
</PRE>
 
</p>
</li>
    <li class="gap">
<p>
 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. 
<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> S:
   <B><FONT COLOR="#0000FF">sig</FONT></B>
      <B><FONT COLOR="#A020F0">val</FONT></B> f: int -&gt; int
   <B><FONT COLOR="#0000FF">end</FONT></B> =
   <B><FONT COLOR="#0000FF">struct</FONT></B>
      <B><FONT COLOR="#A020F0">val</FONT></B> f = (<B><FONT COLOR="#A020F0">fn</FONT></B> x =&gt; x) (<B><FONT COLOR="#A020F0">fn</FONT></B> y =&gt; y)
   <B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
 
</p>
</li>

    </ul>


<h2 id="head-05f93ee06dde2d7fa78009c59b64a585bd6ab4ca">Type error messages</h2>
<p>
To aid in the understanding of type errors, MLton'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't match, using underscores for the parts that match.  For example, if a function expects <tt>real&nbsp;*&nbsp;int</tt> but gets <tt>real&nbsp;*&nbsp;real</tt>, the type error message would look like 
</p>

<pre>expects: _ * [int]
but got: _ * [real]
</pre><p>
As another aid to spotting differences, MLton places brackets <tt>[]</tt> around the parts of the types that don'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 
</p>

<pre>expects: [int * real]
but got: [int * real * string]
</pre><p>
The brackets make it easy to see that the problem is that the tuples have different numbers of components -- not that the components don't match.  Contrast that with a case where a function receives the right number of arguments, but in the wrong order. 
</p>

<pre>expects: [int] * [real]
but got: [real] * [int]
</pre><p>
Here the brackets make it easy to see that the components do not match. 
</p>
<p>
We appreciate feedback on any type error messages that you find confusing, or suggestions you may have for improvements to error messages. 
</p>
<h2 id="head-e849875c2946f3612529e7b5c9eeeb137490f29b">The shortest/most-recent rule for type names</h2>
<p>
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 
</p>

<pre class=code>
<B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> t </FONT></B>=<B><FONT COLOR="#228B22"> int
</FONT></B><B><FONT COLOR="#A020F0">fun</FONT></B> f (x: t) = x
<B><FONT COLOR="#A020F0">val</FONT></B> _ = f <B><FONT COLOR="#BC8F8F">&quot;foo&quot;</FONT></B>
</PRE>
<p>
 
</p>
<p>
MLton reports 
</p>

<pre>Error: z.sml 3.9.
  Function applied to incorrect argument.
    expects: [t]
    but got: [string]
    in: f "foo"
</pre><p>
MLton could have reported <tt>expects:&nbsp;[int]</tt> instead of  <tt>expects:&nbsp;[t]</tt>.  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. <tt>foobar</tt> is shorter than <tt>A.t</tt>).  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 <tt>t</tt> to <tt>int</tt> in the above example. 
</p>
<p>
In signature matching, most recently defined is taken to include all of the definitions introduced by the structure.  For example 
</p>

<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> S:
   <B><FONT COLOR="#0000FF">sig</FONT></B>
      <B><FONT COLOR="#A020F0">val</FONT></B> x: int
   <B><FONT COLOR="#0000FF">end</FONT></B> =
   <B><FONT COLOR="#0000FF">struct</FONT></B>
      <B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> t </FONT></B>=<B><FONT COLOR="#228B22"> int
      </FONT></B><B><FONT COLOR="#A020F0">val</FONT></B> x = <B><FONT COLOR="#BC8F8F">&quot;foo&quot;</FONT></B>
   <B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
<p>
 
</p>
<p>
MLton reports the error message 
</p>

<pre>Error: z.sml 2.4.
  Variable type in structure disagrees with signature.
    variable: x
    structure: [string]
    signature: [t]
</pre><p>
in which the <tt>[t]</tt> refers to the type defined in the structure, since that is more recent than the definition of <tt>int</tt>. 
</p>
<p>
In signatures with type equations, this can be somewhat confusing. For example. 
</p>

<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> S:
   <B><FONT COLOR="#0000FF">sig</FONT></B>
      <B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> t
      </FONT></B><B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> u </FONT></B>=<B><FONT COLOR="#228B22"> t
   </FONT></B><B><FONT COLOR="#0000FF">end</FONT></B> =
   <B><FONT COLOR="#0000FF">struct</FONT></B>
      <B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> t </FONT></B>=<B><FONT COLOR="#228B22"> int
      </FONT></B><B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> u </FONT></B>=<B><FONT COLOR="#228B22"> char
   </FONT></B><B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
<p>
 
</p>
<p>
MLton reports the error 
</p>

<pre>Error: z.sml 2.4.
  Type definition in structure disagrees with signature.
    type: u
    structure: [u]
    signature: [t]
</pre><p>
This error reflects the fact that the signature requires type <tt>u</tt> to equal <tt>t</tt>, but that in the structure, <tt>u</tt> is defined to be <tt>char</tt>, whose most-recent name is <tt>u</tt>, while the signature requires <tt>u</tt> to be <tt>int</tt>, whose most-recent name is <tt>t</tt>. 
</p>
</div>



<p>
<hr>
Last edited on 2007-08-15 22:07:31 by <span title="fenrir.uchicago.edu"><a href="MatthewFluet">MatthewFluet</a></span>.
</body></html>