2011/5/26 Daniel Fischer
As far as I'm concerned, a left-associative version of ($) would sometimes be nice (on the other hand, right-associativity of ($) is sometimes also nice), but usually, I don't find parentheses too obnoxious.
I have a whole set of function application/composition/lifting operators that I'm rather fond of, but it involves replacing some standard operators, and in particular changes the fixity of ($) drastically, so it's something I only use in small bits of personal code that I'll never publish anywhere. The main idea is that there are two groups of operators, each of which are internally pretty consistent and vaguely generalized from standard operators. Very low precedence, function application associates toward argument: f <| x = x |> f = f x, (>>>) and (<<<) for composition, and (>>=), (=<<), (>=>), and (<=<) behaving as expected. (<|) takes the place of standard ($), and (|>) allows a "pipe forward" style similar to using (>>=). Mid-to-high precedence, function application associates away from argument: ($) has the same fixity as (<$>) and (<*>), as do the binding operators (=<$) and (=<*), the latter being a function I haven't seen before that does about what you'd expect from the name. Composition is usually just (.) in most cases because of the style in which I use these. What it amounts to is that the first group is used mostly as pseudo-syntax delimiting expressions that would otherwise be parenthesized, while the second group is used for writing expressions that would conceptually be simple one-liners if not for involving lifting into some sort of Functor. The choice of symbols makes it easy to remember which is which, even if it's not perfectly consistent. Mostly, though, this is probably just another reason why my personal coding style would be bafflingly opaque to most people, so oh well. - C.