Proposal: pare down traversable

David Feuer david.feuer at
Sat Sep 26 21:32:15 UTC 2015

Argh. I'd love to be able to deprecate sequenceA sooner rather than later.
Are there polymorphic recursive settings where sequenceA is more efficient
than traverse id? If not, we can start sinking it immediately; if so, we
have to wait for sequence to be ready to take its place.
On Sep 26, 2015 5:21 PM, "Edward Kmett" <ekmett at> wrote:

> Until we get rid of (>>) from Control.Monad and we can then rely upon (*>)
> and (>>) having the same performance characteristics mapM_ and traverse_
> are not interchangeable. I realize you didn't say anything about those
> functions, but hear me out.
> The tentative migration plan is, assuming the "monad of no return"
> proposal goes through, to first eliminate (>>) then fix mapM_. This avoids
> the very awkward intermediate state that would be a result of directly
> implementing your proposal here where mapM_ needs a stronger constraint
> (Monad) than mapM does, which would use Applicative!
> I therefore very strongly advocate waiting for the elimination of (>>)
> through the monad of no return proposal before we proceed with any
> simplification of Traversable.
> -Edward
> On Sat, Sep 26, 2015 at 5:05 PM, David Feuer <david.feuer at>
> wrote:
>> Traversable currently has traverse, sequenceA, sequence, and mapM
>> methods. sequence and mapM seem to be dinosaurs now. I'd like to suggest
>> that sequenceA be turned into a deprecated function and mapM be moved from
>> Control.Monad to Data.Traversable and re-exported from Control.Monad.
>> I expect most instance declarations to survive unchanged. The only CPP
>> pain point will be that instances that define sequenceA will have to define
>> sequence instead.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list