Proposal: Add (&) to Data.Function

[Edward Kmett]

My major point was originally that code written with & 'reads' well if the
person reads the operator as 'and' or 'and then', but with '|>' you have to
mix metaphors involving pipes that don't quite exactly hold and further
exacerbate the common complaint that Haskell has a ton of complex
multicharacter operators that nobody knows how to pronounce.

On Tue, Nov 20, 2012 at 1:59 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Tue, Nov 20, 2012 at 10:46 AM, John Wiegley <johnw at fpcomplete.com>wrote:
>
>> Yes, a strong positive in favor of & of |> is that it allows the lens
>> library
>> to offer the highly useful variants &= and &~, which have obvious (and
>> related) meanings to someone using lens.  |>= and |>~ would get a bit
>> awkward
>> in comparison.
>>
>
> I don't think embedding APL in Haskell should be a guiding principle. ;)
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121120/e90e52cc/attachment.htm>