<!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>UnresolvedBugs - 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">

<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 20051202</a>
    <td style = "
		border: 0px;
		font-size: 150%;
		text-align: center;
		width: 50%;">
      UnresolvedBugs
    <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">
Here are the places where MLton deviates from the <a href="DefinitionOfStandardML">Definition of SML</a>.  In general, MLton complies with the Definition quite closely, typically much more closely than other SML compilers (see, e.g., our list of <a href="SMLNJDeviations">SML/NJ's deviations</a>).  In fact, the three deviations listed here are the only known deviations, and we have no plans to fix them.  If you find a deviation not listed here, please report a <a href="Bug">Bug</a>. <p>
We don't plan to fix these bugs because one of them (parsing nested cases) has historically never been accepted by any SML compiler, while the other two clearly indicate problems in the Definition. 
</p>

    <ul>

    <li>
<p>
 MLton does not correctly parse case expressions nested within other  matches. For example, the following fails. 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> f <B><FONT COLOR="#5F9EA0">0</FONT></B> y =
      <B><FONT COLOR="#A020F0">case</FONT></B> x <B><FONT COLOR="#A020F0">of</FONT></B>
         <B><FONT COLOR="#5F9EA0">1</FONT></B> =&gt; <B><FONT COLOR="#5F9EA0">2</FONT></B>
       | _ =&gt; <B><FONT COLOR="#5F9EA0">3</FONT></B>
  | f _ y = <B><FONT COLOR="#5F9EA0">4</FONT></B>
</PRE>
   To do this in a program, simply parenthesize the case expression. 
</p>
<p>
 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. 
</p>
</li>
    <li class="gap">
<p>
 MLton rejects rebinding of constructors with <tt>val&nbsp;rec</tt>  declarations, as in 
<pre class=code>
 <B><FONT COLOR="#A020F0">val</FONT></B> <B><FONT COLOR="#A020F0">rec</FONT></B> NONE = <B><FONT COLOR="#A020F0">fn</FONT></B> () =&gt; ()
</PRE>
  The <a href="DefinitionOfStandardML"> Definition</a> (bizarrely) requires this  program to type check, but to raise <tt>Bind</tt>.  
</p>
<p>
 We have no plans to change this behavior, as the Definition's  behavior is clearly an error, a mismatch between the static semantics  and the dynamic semantics. 
</p>
</li>
    <li class="gap">
<p>
 MLton does not hide the equality aspect of types declared in  abstype declarations. So, MLton accepts programs like the following,  while the <a href="DefinitionOfStandardML"> Definition</a> rejects them. 
<pre class=code>
<B><FONT COLOR="#A020F0">abstype</FONT></B><FONT COLOR="#228B22"><B> t </FONT></B>=<FONT COLOR="#228B22"><B> <FONT COLOR="#B8860B">T</FONT> </FONT></B><B><FONT COLOR="#A020F0">with</FONT></B> <B><FONT COLOR="#A020F0">end</FONT></B>
<B><FONT COLOR="#A020F0">val</FONT></B> _ = <B><FONT COLOR="#A020F0">fn</FONT></B> (t1, t2 : t) =&gt; t1 = t2

<B><FONT COLOR="#A020F0">abstype</FONT></B><FONT COLOR="#228B22"><B> t </FONT></B>=<FONT COLOR="#228B22"><B> <FONT COLOR="#B8860B">T</FONT> </FONT></B><B><FONT COLOR="#A020F0">with</FONT></B> <B><FONT COLOR="#A020F0">val</FONT></B> a = T <B><FONT COLOR="#A020F0">end</FONT></B>
<B><FONT COLOR="#A020F0">val</FONT></B> _ = a = a
</PRE>
  One consequence of this choice is that MLton accepts the following  program, in accordance with the <a href="DefinitionOfStandardML"> Definition</a>. 
<pre class=code>
 <B><FONT COLOR="#A020F0">abstype</FONT></B><FONT COLOR="#228B22"><B> t </FONT></B>=<FONT COLOR="#228B22"><B> <FONT COLOR="#B8860B">T</FONT> </FONT></B><B><FONT COLOR="#A020F0">with</FONT></B> <B><FONT COLOR="#A020F0">val</FONT></B> eq = <B><FONT COLOR="#A020F0">op</FONT></B> = <B><FONT COLOR="#A020F0">end</FONT></B>
 <B><FONT COLOR="#A020F0">val</FONT></B> _ = <B><FONT COLOR="#A020F0">fn</FONT></B> (t1, t2 : t) =&gt; eq (t1, t2)
</PRE>
  Other implementations will typically reject this program, because  they make an early choice for the type of <tt>eq</tt> to be   <tt>''a&nbsp;*&nbsp;''a&nbsp;-&gt;&nbsp;bool</tt> instead of <tt>t&nbsp;*&nbsp;t&nbsp;-&gt;&nbsp;bool</tt>.  The choice  is understandable, since the <a href="DefinitionOfStandardML">Definition</a>  accepts the following program. 
<pre class=code>
 <B><FONT COLOR="#A020F0">abstype</FONT></B><FONT COLOR="#228B22"><B> t </FONT></B>=<FONT COLOR="#228B22"><B> <FONT COLOR="#B8860B">T</FONT> </FONT></B><B><FONT COLOR="#A020F0">with</FONT></B> <B><FONT COLOR="#A020F0">val</FONT></B> eq = <B><FONT COLOR="#A020F0">op</FONT></B> = <B><FONT COLOR="#A020F0">end</FONT></B>
 <B><FONT COLOR="#A020F0">val</FONT></B> _ = eq (<B><FONT COLOR="#5F9EA0">1</FONT></B>, <B><FONT COLOR="#5F9EA0">2</FONT></B>)
</PRE>
 
</p>
</li>
</ul>

</div>



<p>
<hr>
Last edited on 2005-12-02 03:06:59 by <span title="ppp-71-139-183-221.dsl.snfc21.pacbell.net"><a href="StephenWeeks">StephenWeeks</a></span>.
</body></html>
