> You mean "apply the function on the right to the result of the left"?<br>Yes.<br>(.) :: a -> (a -> b) -> b<br>x.f == f x<br><br>Prefix usage:<br>given: (f :: Integer -> Char) and (g :: Double -> Double -> Integer)
<br>(foo = .f) == \x -> f x<br>(bar = .g) == \x y = g x y<br><br>foo :: Double -> Double -> Char<br>foo = .g.f <br><br>> How about making . reverse composition, and...symbol for flip ($)<br>> [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))). 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>> left-to-right order lets you think of the<br>> starting value and make a sequence of transformations
<br>does syntax affect this? 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>