> You mean "apply the function on the right to the result of the left"?
Yes.
(.) :: a -> (a -> b) -> b
x.f == f x

Prefix usage:
given: (f :: Integer -> Char) and (g :: Double -> Double -> Integer)
(foo = .f) == \x -> f x
(bar = .g) == \x y = g x y

foo :: Double -> Double -> Char
foo = .g.f

> How about making . reverse composition, and...symbol for flip ($)
> [1,2,3]#null.not
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.

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*.

With the prefix dot operator, I like how small the transition from pointwise to point-free code is:
f x = x.null.not
f = .null.not

Same is true of the hash-dot style too, of course:
f x = x#null.not
f = null.not

Both are quite a better than Haskell today:
f x = not (null x)
f x = not $ null x
f x = (not . null) x
f = not . null

> left-to-right order lets you think of the
> starting value and make a sequence of transformations
does syntax affect this? if someone views a solution with an imperative point-of-view, won't they just use $ or parenthesis everywhere anyway?

Thanks,
Greg