Sophie

Sophie

distrib > Fedora > 15 > i386 > by-pkgid > d07d7ab417d79053e7e0155c99e1a1c8 > files > 2270

mlton-20100608-3.fc15.i686.rpm

<!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>InfixingOperators - 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%;">
      InfixingOperators
    <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">
Fixity specifications are not part of signatures in <a href="StandardML">Standard ML</a>. When one wants to use a module that provides functions designed to be used as infix operators there are several obvious alternatives: 
        <ul>

        <li>
<p>
 Use only prefix applications. Unfortunately there are situations where   infix applications lead to considerably more readable code. 
</p>
</li>
        <li>
<p>
 Make the fixity declarations at the top-level. This may lead to   collisions and may be unsustainable in a large project. Pollution of the   top-level should be avoided. 
</p>
</li>
        <li>
<p>
 Make the fixity declarations at each scope where you want to use infix   applications. The duplication becomes inconvenient if the operators are   widely used. Duplication of code should be avoided. 
</p>
</li>
        <li>
<p>
 Use non-standard extensions, such as the <a href="MLBasis"> ML Basis system</a>   to control the scope of fixity declarations. This has the obvious   drawback of reduced portability. 
</p>
</li>
        <li>
<p>
 Reuse existing infix operator symbols (<tt>^</tt>, <tt>+</tt>, <tt>-</tt>, ...).   This can be convenient when the standard operators aren't needed in the   same scope with the new operators.  On the other hand, one is limited to   the standard operator symbols and the code may appear confusing. 
</p>
</li>

        </ul>


<p>
None of the obvious alternatives is best in every case. The following describes a slightly less obvious alternative that can sometimes be useful. The idea is to approximate Haskell's special syntax for treating any identifier enclosed in grave accents (backquotes) as an infix operator. In Haskell, instead of writing the prefix application <tt>f&nbsp;x&nbsp;y</tt> one can write the infix application <tt>x&nbsp;`f`&nbsp;y</tt>. 
</p>
<h2 id="head-2064441d71938e807c277e86da93e8d294ecdcf1">Infixing operators</h2>
<p>
Let's first take a look at the definitions of the operators: 
<pre class=code>
<B><FONT COLOR="#A020F0">infix</FONT></B>  3 &lt;\     <B><FONT COLOR="#A020F0">fun</FONT></B> x &lt;\ f = <B><FONT COLOR="#A020F0">fn</FONT></B> y =&gt; f (x, y)     <I><FONT COLOR="#B22222">(* Left section      *)</FONT></I>
<B><FONT COLOR="#A020F0">infix</FONT></B>  3 \&gt;     <B><FONT COLOR="#A020F0">fun</FONT></B> f \&gt; y = f y                  <I><FONT COLOR="#B22222">(* Left application  *)</FONT></I>
<B><FONT COLOR="#A020F0">infixr</FONT></B> 3 /&gt;     <B><FONT COLOR="#A020F0">fun</FONT></B> f /&gt; y = <B><FONT COLOR="#A020F0">fn</FONT></B> x =&gt; f (x, y)     <I><FONT COLOR="#B22222">(* Right section     *)</FONT></I>
<B><FONT COLOR="#A020F0">infixr</FONT></B> 3 &lt;/     <B><FONT COLOR="#A020F0">fun</FONT></B> x &lt;/ f = f x                  <I><FONT COLOR="#B22222">(* Right application *)</FONT></I>

<B><FONT COLOR="#A020F0">infix</FONT></B>  2 o  <I><FONT COLOR="#B22222">(* See motivation below *)</FONT></I>
<B><FONT COLOR="#A020F0">infix</FONT></B>  0 := 
</PRE>
 The left and right sectioning operators, <tt>&lt;\</tt> and <tt>/&gt;</tt>, are useful in SML for partial application of infix operators. <a href = "References#Paulson96"> ML For the Working Programmer</a> describes curried functions <tt>secl</tt> and <tt>secr</tt> for the same purpose on pages 179-181. For example, 
<pre class=code>
List.map (<B><FONT COLOR="#A020F0">op</FONT></B>- /&gt; y) 
</PRE>
 is a function for subtracting <tt>y</tt> from a list of integers and 
<pre class=code>
List.exists (x &lt;\ <B><FONT COLOR="#A020F0">op</FONT></B>=) 
</PRE>
 is a function for testing whether a list contains an <tt>x</tt>. 
</p>
<p>
Together with the left and right application operators, <tt>\&gt;</tt> and <tt>&lt;/</tt>, the sectioning operators provide a way to treat any binary function (i.e. a function whose domain is a pair) as an infix operator. In general, 
<pre>x0 &lt;\f1\&gt; x1 &lt;\f2\&gt; x2 ... &lt;\fN\&gt; xN  =  fN (... f2 (f1 (x0, x1), x2) ..., xN)
</pre>and 
<pre>xN &lt;/fN/&gt; ... x2 &lt;/f2/&gt; x1 &lt;/f1/&gt; x0  =  fN (xN, ... f2 (x2, f1 (x1, x0)) ...) </pre>
</p>
<h3 id="head-eb01bf04c9a0e8a71c45816513df424f1c7ffedb">Examples</h3>
<p>
As a fairly realistic example, consider providing a function for sequencing comparisons: 
<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> Order <I><FONT COLOR="#B22222">(* ... *)</FONT></I> =
   <B><FONT COLOR="#0000FF">struct</FONT></B>
      <I><FONT COLOR="#B22222">(* ... *)</FONT></I>
      <B><FONT COLOR="#A020F0">val</FONT></B> orWhenEq = <B><FONT COLOR="#A020F0">fn</FONT></B> (EQUAL, th) =&gt; th ()
                      | (other,  _) =&gt; other
      <I><FONT COLOR="#B22222">(* ... *)</FONT></I>
   <B><FONT COLOR="#0000FF">end</FONT></B> 
</PRE>
 Using <tt>orWhenEq</tt> and the infixing operators, one can write a <tt>compare</tt> function for triples as 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> compare (fad, fbe, fcf) ((a, b, c), (d, e, f)) =
    fad (a, d) &lt;\Order.orWhenEq\&gt; `fbe (b, e) &lt;\Order.orWhenEq\&gt; `fcf (c, f)
</PRE>
 where <tt>`</tt> is defined as 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> `f x = <B><FONT COLOR="#A020F0">fn</FONT></B> () =&gt; f x
</PRE>
 Although <tt>orWhenEq</tt> can be convenient (try rewriting the above without it), it is probably not useful enough to be defined at the top level as an infix operator. Fortunately we can use the infixing operators and don't have to. 
</p>
<p>
Another fairly realistic example would be to use the infixing operators with the technique described on the <a href="Printf">Printf</a> page. Assuming that you would have a <tt>Printf</tt> module binding <tt>printf</tt>, <tt>`</tt>, and formatting combinators named <tt>int</tt> and <tt>string</tt>, you could write 
<pre class=code>
<B><FONT COLOR="#A020F0">let</FONT></B> <B><FONT COLOR="#0000FF">open</FONT></B> Printf <B><FONT COLOR="#A020F0">in</FONT></B>
  printf (`<B><FONT COLOR="#BC8F8F">&quot;Here's an int &quot;</FONT></B>&lt;\int\&gt;<B><FONT COLOR="#BC8F8F">&quot; and a string &quot;</FONT></B>&lt;\string\&gt;<B><FONT COLOR="#BC8F8F">&quot;.&quot;</FONT></B>) <B><FONT COLOR="#5F9EA0">13</FONT></B> <B><FONT COLOR="#BC8F8F">&quot;foo&quot;</FONT></B> <B><FONT COLOR="#A020F0">end</FONT></B> 
</PRE>
 without having to duplicate the fixity declarations. Alternatively, you could write 
<pre class=code>
P.printf (P.`<B><FONT COLOR="#BC8F8F">&quot;Here's an int &quot;</FONT></B>&lt;\P.int\&gt;<B><FONT COLOR="#BC8F8F">&quot; and a string &quot;</FONT></B>&lt;\P.string\&gt;<B><FONT COLOR="#BC8F8F">&quot;.&quot;</FONT></B>) <B><FONT COLOR="#5F9EA0">13</FONT></B> <B><FONT COLOR="#BC8F8F">&quot;foo&quot;</FONT></B> 
</PRE>
 assuming you have the made the binding 
<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> P = Printf
</PRE>
 
</p>
<h2 id="head-cc41911c3699b10c36ceb8fb01f0650a4e0e758d">Application and piping operators</h2>
<p>
The left and right application operators may also provide some notational convenience on their own. In general, 
<pre>f \&gt; x1 \&gt; ... \&gt; xN = f x1 ... xN </pre>and 
<pre>xN &lt;/ ... &lt;/ x1 &lt;/ f = f x1 ... xN </pre>
</p>
<p>
If nothing else, both of them can eliminate parentheses. For example, 
<pre class=code>
foo (<B><FONT COLOR="#5F9EA0">1</FONT></B> + <B><FONT COLOR="#5F9EA0">2</FONT></B>) = foo \&gt; <B><FONT COLOR="#5F9EA0">1</FONT></B> + <B><FONT COLOR="#5F9EA0">2</FONT></B> 
</PRE>
 
</p>
<p>
The left and right application operators are related to operators that could be described as the right and left piping operators: 
<pre class=code>
<B><FONT COLOR="#A020F0">infix</FONT></B>  1 &gt;|     <B><FONT COLOR="#A020F0">val</FONT></B> <B><FONT COLOR="#A020F0">op</FONT></B>&gt;| = <B><FONT COLOR="#A020F0">op</FONT></B>&lt;/      <I><FONT COLOR="#B22222">(* Left pipe *)</FONT></I>
<B><FONT COLOR="#A020F0">infixr</FONT></B> 1 |&lt;     <B><FONT COLOR="#A020F0">val</FONT></B> <B><FONT COLOR="#A020F0">op</FONT></B>|&lt; = <B><FONT COLOR="#A020F0">op</FONT></B>\&gt;      <I><FONT COLOR="#B22222">(* Right pipe *)</FONT></I> 
</PRE>
 
</p>
<p>
As you can see, the left and right piping operators, &gt;| and |&lt;, are the same as the right and left application operators, respectively, except the associativities are reversed and the binding strength is lower. They are useful for piping data through a sequence of operations. In general, 
<pre>  x &gt;| f1 &gt;| ... &gt;| fN
= fN (... (f1 x) ...)
= (fN o ... o f1) x </pre>and 
<pre>  fN |&lt; ... |&lt; f1 |&lt; x
= fN (... (f1 x) ...)
= (fN o ... o f1) x </pre>
</p>
<p>
The right piping operator, <tt>|&lt;</tt>, is provided by the Haskell prelude as <tt>$</tt>. It can be convenient in CPS or continuation passing style. 
</p>
<p>
A use for the left piping operator is with parsing combinators. In a strict language, like SML, eta-reduction is generally unsafe. Using the left piping operator, parsing functions can be formatted conveniently as 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> parsingFunc input =
   input &gt;| <I><FONT COLOR="#B22222">(* ... *)</FONT></I>
         || <I><FONT COLOR="#B22222">(* ... *)</FONT></I>
         || <I><FONT COLOR="#B22222">(* ... *)</FONT></I> 
</PRE>
 where <tt>||</tt> is supposed to be a combinator provided by the parsing combinator library. 
</p>
<h2 id="head-aacfb4ed5c69ecb1facd0a8a1b5aa3f2e9deeeed">About precedences</h2>
<p>
You probably noticed that we redefined the <a href="OperatorPrecedence">precedences</a> of the function composition operator <tt>o</tt> and the assignment operator <tt>:=</tt>. Doing so is not strictly necessary, but can be convenient and should be relatively safe. Consider the following motivating examples from <a href="WesleyTerpstra"> Wesley W. Terpstra</a> relying on the redefined precedences: 
<pre class=code>
Word8.fromInt o Char.ord o s &lt;\String.sub
<I><FONT COLOR="#B22222">(* Combining sectioning and composition *)</FONT></I>

x := s &lt;\String.sub\&gt; i
<I><FONT COLOR="#B22222">(* Assigning the result of an infixed application *)</FONT></I> 
</PRE>
 
</p>
<p>
In imperative languages, assignment usually has the lowest precedence (ignoring statement separators). The precedence of <tt>:=</tt> in the <a href="BasisLibrary"> Basis library</a> is perhaps unnecessarily high, because an expression of the form <tt>r&nbsp;:=&nbsp;x</tt> always returns a unit, which makes little sense to combine with anything. Dropping <tt>:=</tt> to the lowest precedence level makes it behave more like in other imperative languages. 
</p>
<p>
The case for <tt>o</tt> is different. With the exception of <tt>before</tt> and <tt>:=</tt>, it doesn't seem to make much sense to use <tt>o</tt> with any of the operators defined by the Basis library in an unparenthesized expression. This is simply because none of the other operators deal with functions. It would seem that the precedence of <tt>o</tt> could be chosen completely arbitrarily from the set <tt>{1,&nbsp;...,&nbsp;9</tt>} without having any adverse effects with respect to other infix operators defined by the Basis library. 
</p>
<h2 id="head-bb4d2ad8129dd782305f5b40532aa67acfd4581e">Design of the symbols</h2>
<p>
The closest approximation of Haskell's <tt>x&nbsp;`f`&nbsp;y</tt> syntax achievable in Standard ML would probably be something like <tt>x&nbsp;`f^&nbsp;y</tt>, but <tt>^</tt> is already used for string concatenation by the Basis library. Other combinations of the characters <tt>`</tt> and <tt>^</tt> would be possible, but none seems clearly the best visually. The symbols <tt>&lt;\</tt>, <tt>\&gt;</tt>, <tt>&lt;/</tt> and <tt>/&gt;</tt> are reasonably concise and have a certain self-documenting appearance and symmetry, which can help to remember them. As the names suggest, the symbols of the piping operators <tt>&gt;|</tt> and <tt>|&lt;</tt> are inspired by Unix shell pipelines. 
</p>
<h2 id="head-a4bc8bf5caf54b18cea9f58e83dd4acb488deb17">Also see</h2>

    <ul>

    <li>
<p>
 <a href="Utilities">Utilities</a> 
</p>
</li>
</ul>

</div>



<p>
<hr>
Last edited on 2009-10-22 12:20:45 by <span title="cpe-76-190-146-39.neo.res.rr.com">RanAriGur</span>.
</body></html>