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