&gt; You mean &quot;apply the function on the right to the result of the left&quot;?<br>Yes.<br>(.) :: a -&gt; (a -&gt; b) -&gt; b<br>x.f == f x<br><br>Prefix usage:<br>given: (f :: Integer -&gt; Char) and (g :: Double -&gt; Double -&gt; Integer)
<br>(foo = .f) == \x -&gt; f x<br>(bar = .g) == \x y = g x y<br><br>foo :: Double -&gt; Double -&gt; Char<br>foo = .g.f&nbsp; <br><br>&gt; How about making . reverse composition, and...symbol for flip ($)<br>&gt; [1,2,3]#null.not
<br>that works too, and is clearly easier to implement, but there's an opportunity to shorten the gap between Haskell and the mainstream languages, and without losing functional composition.<br><br>Also, if you flip the meaning of dot, some existing code will still compile, but produce different values (map ((+1) . (*2))).&nbsp; By changing the type signature of the infix operator, it would break all existing code at *compile-time*.
<br><br>With the prefix dot operator, I like how small the transition from pointwise to point-free code is:<br>f x = x.null.not<br>f = .null.not<br><br>Same is true of the hash-dot style too, of course:<br>f x = x#null.not
<br>f = null.not<br><br>Both are quite a better than Haskell today:<br>f x = not (null x)<br>f x = not $ null x<br>f x = (not . null) x<br>f = not . null<br><br>&gt; left-to-right order lets you think of the<br>&gt; starting value and make a sequence of transformations
<br>does syntax affect this?&nbsp; if someone views a solution with an imperative point-of-view, won't they just use $ or parenthesis everywhere anyway?<br><br>Thanks,<br>Greg<br>