Re: Proposal: Add (&) to Data.Function

...

...

...

...

Dan Burton 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