The choice of fixity came about because actually the most common thing replaced by (<&>) is actually (>>=), when the thing you are binding to no longer has an effect, not actually (<$>), despite what the name suggests.

This made a non-trivial difference in the amount of parentheses in real code, and was a conscious decision, so reverting it is not something I would do lightly and breaks real code.

Back during the discussion of whether we should adopt (&), (<&>) also came up, but with only one voice in favor, and nobody else really feeling passionately, and with various colors like this available for the bikeshed it was dropped.

-Edward



On Thu, Apr 17, 2014 at 3:32 PM, Hans Höglund <hans@hanshoglund.se> wrote:

Can we argue about the fixity for (<&>)? I've always it as infixl 4, to mix it in with other applicative operators, e.g.:

(:) <$> fx <*> fl

becomes

fx <&> (:) <*> fl

I agree, this seems to be a mistake in lens.


Last I checked,

(&) = flip ($)

is both shorter to type, and more explicit than:

import Control.Apply.Reverse

  - Clark


Well the purpose here is to propose a standard name and fixity, not to save keystrokes.

When a lot of libraries start to define a (trivial) thing under different names, that to me is a good indication that it should be in the standard library. It is a matter of keeping the signal-to-noise ratio large, which greatly helps when reading unfamiliar code.

Hans

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe