[Haskell-cafe] Function application layout

[Casey McCann]

2011/5/26 Daniel Fischer <daniel.is.fischer at googlemail.com>
> 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.