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