Proposal: Add (&) to Data.Function

[John Wiegley]

>>>>> Dan Burton <danburton.email at gmail.com> writes:

> Rewritten with whitespace, it can look much prettier:

> ("Hello", "world")
>   |> _1.traverse %~ toUpper
>   |> _2          .~ 42

Or:

  ("Hello", "world")
    & _1.traverse %~ toUpper
    & _2          .~ 42

But now we are just arguing aesthetics.  Please keep in mind that choosing |>
over & on aesthetic grounds has an unfortunate casualty: |> doesn't fit into
the operator hierarchy of lens, while & does quite nicely.  So while I can't
argue |> over &, or vice-versa, for their own sake, we should not lose sight
of this clear cost to lens in choosing |>.

And I feel this is important, because as lens matures it could become one of
the shining features of Haskell.  There are certain lens traversals that are
able to work pure magic in nice, compact expressions, while remaining quite
readable over their non-lens counterparts -- such as picking all Int's out of
an arbitrarily complex structure:

    ghci> (("hello","world"),"!!!", 2 :: Int, ()) ^..biplate :: [Int]
    [2]

Once lens catches on, the operator we're calling |> or & will become an
operator that gets used many times a day by lens users, so it should be as
unobtrusive as possible, and fit with the natural pattern of other, related
operators.

I realize Johan suggested we not consider the choice of operator in the
context of any one library, but we also shouldn't ignore a prominent library
that has a significant use case for that operator.  In fact, not having this
operator hasn't been an issue for nearly many years now, but the reason we're
discussing it today is due to lens.

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net