I don't have benchmarks that support the removal of sequenceA at this time. I also don't have ones that support its retention, but at this stage removal has the higher burden of proof. We should eventually be able to eventually kick sequence and mapM out of the class and simultaneously weaken their constraints, so assuming that much happens you'll eventually be able to use sequence as sequenceA. The question then becomes if we'll be able to eliminate sequenceA as well, or if it should remain in the class. None of these migrations paths viably end with sequence being a member of the class, though, so the best case is that we find `traverse id` is never appreciably worse and can separately move sequence/sequenceA out of the class. Otherwise we'd be left with the annoyance of defining sequenceA. Unfortunately the same issue mentioned above regarding the relationship between mapM and mapM_ applies mutatis mutandis to sequence and sequence_, so we can't really weaken the constraint on sequence until the monad of no return proposal extended with (>>) goes through, putting both potential simplifications of the Traversable class on the same general clock. -Edward On Sat, Sep 26, 2015 at 5:32 PM, David Feuer wrote:

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" 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

The fact that Monad got the nice sequence name and Applicative got the ugly stepduckling sequenceA name is an unfortunate accident of history that I for one do not want to see in the next Haskell Report. Once the decision is made that something should go away, it seems generally best to get rid of it sooner rather than later. On Mon, Sep 28, 2015 at 2:44 AM, Roman Cheplyaka wrote:

On 09/27/2015 12:32 AM, David Feuer wrote:

...

Argh. I'd love to be able to deprecate sequenceA sooner rather than later.

Why? What benefit does this change bring?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Thu, Oct 8, 2015 at 4:24 AM, Mark Lentczner wrote:

The whole shebang, from FTP through MRP and whatever else you have up your sleeves should NEVER have been foist piecemeal onto the current system. If you really want those things - package them as a cohesive whole - find a way to use them in your code bases for two years (alternate Prelude) - prove they work, iron out the mistakes - THEN make a single large wholesale change - probably along with a Haskell report.

I agree with Mark that FTP (seen in the light of MRP) is incomplete and piecemeal. The half-baked nature already causes productivity losses, see https://ghc.haskell.org/trac/ghc/ticket/10830 Otoh, I doubt that David is singularly to blame for this ("whatever else you have up your sleeves") nor are his intentions, like many a derring-do haskeller's, any less than sincere in wanting to improve things. Thing is, a new Haskell report sounds terribly onerous and folks make it easy on themselves to make the changes they want to see. A new Haskell report seems to require tremendous ounces of foresight, focus, and conviviality among stakeholders to pull it off. -- Kim-Ee