Composability in Haskell arises from abstraction made possible by a rich type system and simple semantics. IMHO and from my experience with dynamic languages, any syntactic solution to Composability will be a dead end, i.e. will not beget any other useful abstractions.
All true, but let's not forget that there is a nuts-and-bolts aspect to it, as well. The fact that we can write the wonderfully clear & concise
f = f1 . f2 . f3
in Haskell arises from the things you mentioned and also from the language syntax. In a language that is only slightly different, we might need to write something like
f = compose(compose(f1, f2), f3)
Indeed, despite Lisp's vaunted expressiveness, in many flavors of Lisp you'd have to write something about as complicated.
Certainly syntax is very important; but I would suggest my point still stands even if you allow all of haskell's syntactic bits (in this case the ability to define infix functions of non-word characters).
And I think haskell's type system actually comes into play in your second code block example: languages where function arity is dynamic or untyped will never be able to make use of that simple infix syntax rule in your first code block.
Indeed, despite Lisp's vaunted expressiveness, in many flavors of Lisp you'd have to write something about as complicated.
Common Lisp lets you redefine syntax to support equally easy function composition. You can even get rid of the parentheses syntax altogether and switch to Haskell syntax. People don't do it, though, because Common Lisp is not a functional programming language, and that also would be against Lisp nature.
I don't know if Clojure has reader macros that are as expressive as Common Lisp ones (I'd be happy to learn the answer from some Clojure hacker). Other Lisps are either very old or domain specific.
Clojure has a function (comp ...) that composes an arbitrary number of functions, and the macros -> and ->> that sort of pipe a value through a list of expressions. (Still new to clojure myself)
