Add flipped fmap

Edward Kmett ekmett at
Thu Apr 8 18:33:12 EDT 2010

On Thu, Apr 8, 2010 at 6:16 PM, wren ng thornton <wren at
> wrote:

> wren ng thornton wrote:
>> Edward Kmett wrote:
>>> <**> cannot be defined in terms of flip as it swaps the order of the
>>> effects as well.
>> But I thought:
>>    (<**>) = liftA2 (flip ($))
>> :)

> If (<**>) were to have been defined as flip(liftA2(flip($))), then I would
> be supportive of it. My definition has the same perspicuous type as (<*>)
> but adding support for non-LtR ordering of effects/evaluation, which seems
> to be the goal of the (<**>) combinator. However, (<**>) as it is actually
> defined forces one to give up the applicative style in order to alter
> evaluation ordering. In so doing it does not come to support another style
> and therefore simply looks like a wart on the API. Someone might could make
> an argument for (<**>) supporting a sort of object-oriented style in terms
> of evaluation order, but that style is not otherwise supported by the
> Applicative combinators, and so I wouldn't find it convincing.
As written

x <**> f =liftA2 (flip ($)) x f = flip id <$> x <*> f

keeps the order of effects reading from left to right, to be consistent with
the other applicative combinators as opposed to the other candidate:

I think in many ways the strict left to right effect evaluation order is
what makes Applicative code readable. You don't have to reason piecemeal
about the order of effects.

Both the naive flip (<*>) and your proposed

flip (liftA2 (flip ($)) x y = flip (liftA2 (flip id)) x y = liftA2 (flip id)
y x = flip id <$> y <*> x

sacrifice that important property.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Libraries mailing list