proposal #2461: add Traversable generalizations
of?mapAccumL?and mapAccumR
Conor McBride
conor at strictlypositive.org
Mon Jul 28 03:59:41 EDT 2008
Hi Michael
On 28 Jul 2008, at 07:50, Michael Karcher wrote:
David wrote (with patch applied):
> newtype Backward f a = Backward { runBackward :: f a } deriving
Functor
> instance Applicative f => Applicative (Backward f) where
> pure = Backward . pure
> (Backward f) <*> (Backward a) = Backward (a <**> f)
You said:
> According to the haddock of Control.Applicative, this line is
> semantically
> equivalent to
> Backward f <*> Backward a = Backward (f <*> a)
I'm not saying the haddock is entirely clear, but it certainly
doesn't necessitate the interpretation you're making.
> So I don't see the point of this "transformer". It seems to do
> nothing, just
> as
> newtype Backward f a = Backward { runBackward :: f a }
> deriving (Functor, Applicative)
> would also do.
Appearances can be deceptive, so why not actually try it?
*Backward> traverse print ["bong", "bing"]
"bong"
"bing"
[(),()]
*Backward> runBackward $ traverse (Backward . print) ["bong", "bing"]
"bing"
"bong"
[(),()]
(<*>) does the function's effects before the argument's;
(<**>) does the argument's effects before the function's.
In contrast with monads, the applicative interface does
not offer the ability to make the choice of one computation
depend on the value of another (in Lindley/Wadler/Yallop
terminology, applicative functors are "oblivious"). One
consequence is that it's easy to reverse the order of
computation.
All the best
Conor
More information about the Libraries
mailing list