<!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>MLNLFFIImplementation - 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%;">
      MLNLFFIImplementation
    <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">
MLton's implementation(s) of the <a href="MLNLFFI">MLNLFFI</a> library differs from the SML/NJ implementation in two important ways: 
    <ul>

    <li>
<p>
 MLton cannot utilize the <tt>Unsafe.cast</tt> "cheat" described in Section 3.7 of <a href = "References#Blume01">Blume01</a>.  (MLton's representation of <a href="Closure">closures</a> and <a href="PackedRepresentation">aggressive representation</a> optimizations make an <tt>Unsafe.cast</tt> even more "unsafe" than in other implementations.)  We have considered two solutions: 
</p>
</li>

            <ul>

            <li>
<p>
 One solution is to utilize an additional type parameter (as described in Section 3.7 of <a href = "References#Blume01">Blume01</a>):  
</p>
</li>

                    <ul>

     
<pre class=code>
<B><FONT COLOR="#0000FF">signature</FONT></B> C = <B><FONT COLOR="#0000FF">sig</FONT></B>
    <B><FONT COLOR="#A020F0">type</FONT></B><FONT COLOR="#228B22"><B> ('t, 'f, 'c) obj
    </FONT></B><B><FONT COLOR="#A020F0">eqtype</FONT></B><FONT COLOR="#228B22"><B> ('t, 'f, 'c) obj'
    </FONT></B>...
    <B><FONT COLOR="#A020F0">type</FONT></B><FONT COLOR="#228B22"><B> ('o, 'f) ptr   
    </FONT></B><B><FONT COLOR="#A020F0">eqtype</FONT></B><FONT COLOR="#228B22"><B> ('o, 'f) ptr'
    </FONT></B>...
    <B><FONT COLOR="#A020F0">type</FONT></B><FONT COLOR="#228B22"><B> 'f fptr
    </FONT></B><B><FONT COLOR="#A020F0">type</FONT></B><FONT COLOR="#228B22"><B> 'f ptr'
    </FONT></B>...
    <B><FONT COLOR="#0000FF">structure</FONT></B> T : <B><FONT COLOR="#0000FF">sig</FONT></B>
        <B><FONT COLOR="#A020F0">type</FONT></B><FONT COLOR="#228B22"><B> ('t, 'f) typ
        </FONT></B>...
    <B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
<p>
 <em>The rule for <tt>('t,&nbsp;'f,&nbsp;'c)&nbsp;obj</tt>,<tt>('t,&nbsp;'f,&nbsp;'c)&nbsp;ptr</tt>, and also <tt>('t,&nbsp;'f)&nbsp;T.typ</tt> is that whenever <tt>F&nbsp;fptr</tt> occurs within the instantiation of <tt>'t</tt>, then <tt>'f</tt> must be instantiated to <tt>F</tt>.  In all other cases, <tt>'f</tt> will be instantiated to <tt>unit</tt>.</em> (In the actual MLton implementation, an abstract type <tt>naf</tt> (not-a-function) is used instead of <tt>unit</tt>.) 
</p>

                    </ul>


   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 <tt>ml-nlffigen</tt>, which are necessarily implementation dependent (in order to make <a href="CallingFromSMLToCFunctionPointer">calls through a C function pointer</a>), may be easily extended to emit the additional type parameter.  Client code which uses such generated glue-code (e.g., Section 1 of <a href = "References#Blume01">Blume01</a>) need rarely write type-annotations, thanks to the magic of type inference.             <li class="gap">
<p>
 The above implementation suffers from two disadvantages.  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 <tt>MLRep</tt> structure provided by MLton, this point is mostly moot).   
</p>
<p>
   Second, it appears to unecessarily duplicate type information.  For example, an external C variable of type <tt>int&nbsp;(*&nbsp;f[3])(int)</tt> (that is, an array of three function pointers), would be represented by the SML type <tt>(((sint&nbsp;-&gt;&nbsp;sint)&nbsp;fptr,&nbsp;dec&nbsp;dg3)&nbsp;arr,&nbsp;sint&nbsp;-&gt;&nbsp;sint,&nbsp;rw)&nbsp;obj</tt>.  One might well ask why the <tt>'f</tt> instantiation (<tt>sint&nbsp;-&gt;&nbsp;sint</tt> in this case) cannot be <em>extracted</em> from the <tt>'t</tt> instantiation (<tt>((sint&nbsp;-&gt;&nbsp;sint)&nbsp;fptr,&nbsp;dec&nbsp;dg3)&nbsp;arr</tt> in this case), obviating the need for a separate <em>function-type</em> type argument.  There are a number of components to an complete answer to this question.  Foremost is the fact that <a href="StandardML"> Standard ML</a> supports neither (general) type-level functions nor intensional polymorphism.   
</p>
<p>
   A more direct answer for MLNLFFI is that in the SML/NJ implemention, the definition of the types <tt>('t,&nbsp;'c)&nbsp;obj</tt> and <tt>('t,&nbsp;'c)&nbsp;ptr</tt> are made in such a way that the type variables <tt>'t</tt> and <tt>'c</tt> are <a href="PhantomType"> phantom</a> (not contributing to the run-time representation of an <tt>('t,&nbsp;'c)&nbsp;obj</tt> or <tt>('t,&nbsp;'c)&nbsp;ptr</tt> value), despite the fact that the types <tt>((sint&nbsp;-&gt;&nbsp;sint)&nbsp;fptr,&nbsp;rw)&nbsp;ptr</tt> and <tt>((double&nbsp;-&gt;&nbsp;double)&nbsp;fptr,&nbsp;rw)&nbsp;ptr</tt> necessarily carry distinct (and type incompatible) run-time (C-)type information (RTTI), corresponding to the different calling conventions of the two C functions.  The <tt>Unsafe.cast</tt> "cheat" overcomes the type incompatibility without introducing a new type variable (as in the first solution above). 
</p>
<p>
   Hence, the reason that <em>function-type</em> type cannot be extracted from the <tt>'t</tt> type variable instantiation is that the type of the representation of RTTI doesn't even <em>see</em> the (phantom) <tt>'t</tt> type variable.  The solution which presents itself is to give up on the phantomness of the <tt>'t</tt> type variable, making it available to the representation of RTTI. 
</p>
<p>
   This is not without some small drawbacks.  Because many of the types used to instatiate <tt>'t</tt> carry more structure than is strictly necessary for <tt>'t</tt>'s RTTI, it is sometimes necessary to wrap and unwrap RTTI to accomodate the additional structure.  (In the other implementations, the corresponding operations can pass along the RTTI unchanged.)  However, these coercions contribute miniscule overhead; in fact, in a majority of cases, MLton's optimizations will completely eliminate the RTTI from the final program. 
</p>
</li>

            </ul>


 The implementation distributed with MLton uses the second solution. <p>
 Bonus question: Why can't one use a <a href="UniversalType"> universal type</a> to eliminate the use of <tt>Unsafe.cast</tt>? 
</p>

            <ul>

            <li>
<p>
 Answer: ??? 
</p>
</li>

            </ul>


    <li class="gap">
<p>
 MLton (in both of the above implementations) provides a richer <tt>MLRep</tt> structure, utilizing <tt>Int&lt;N&gt;</tt> and <tt>Word&lt;N&gt;</tt> structures. 
<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> MLRep = <B><FONT COLOR="#0000FF">struct</FONT></B>
    <B><FONT COLOR="#0000FF">structure</FONT></B> Char =
       <B><FONT COLOR="#0000FF">struct</FONT></B>
          <B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int8
          <B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word8
          <I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
          <B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
                                             <B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
       <B><FONT COLOR="#0000FF">end</FONT></B>
    <B><FONT COLOR="#0000FF">structure</FONT></B> Short =
       <B><FONT COLOR="#0000FF">struct</FONT></B>
          <B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int16
          <B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word16
          <I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
          <B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
                                             <B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
       <B><FONT COLOR="#0000FF">end</FONT></B>
    <B><FONT COLOR="#0000FF">structure</FONT></B> Int =
       <B><FONT COLOR="#0000FF">struct</FONT></B>
          <B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int32
          <B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word32
          <I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
          <B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
                                             <B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
       <B><FONT COLOR="#0000FF">end</FONT></B>  
    <B><FONT COLOR="#0000FF">structure</FONT></B> Long =
       <B><FONT COLOR="#0000FF">struct</FONT></B>
          <B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int32
          <B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word32
          <I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
          <B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
                                             <B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
       <B><FONT COLOR="#0000FF">end</FONT></B>
    <B><FONT COLOR="#0000FF">structure</FONT></B> LongLong =
       <B><FONT COLOR="#0000FF">struct</FONT></B>
          <B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int64
          <B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word64
          <I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
          <B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
                                             <B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
       <B><FONT COLOR="#0000FF">end</FONT></B>
    <B><FONT COLOR="#0000FF">structure</FONT></B> Float = Real32
    <B><FONT COLOR="#0000FF">structure</FONT></B> Double = Real64
<B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
 This would appear to be a better interface, even when an implementation must choose <tt>Int32</tt> and <tt>Word32</tt> as the representation for smaller C-types. 
</p>
</li>
</ul>

</div>



<hr>
Last edited on 2005-12-02 05:11:01 by <span title="209-6-203-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com"><a href="http://mlton.org/MatthewFluet">MatthewFluet</a></span>.
</body></html>
