As long as we're playing the permutation game, I also frequently use mconcatMap, and mconcatMapM. Actually, my concatMapM is secretly '(Monad m, Monoid b) => (a -> m b) -> [a] -> m b', but I suppose you could argue that's inconsistent with the existing naming scheme. I guess I don't mind it because unlike the generalization of [a] to Foldable a, I haven't had ambiguity problems with generalizing [a] to Monoid a. Just personal experience though. On Fri, Feb 8, 2019 at 9:04 AM Carter Schonwald wrote:

friend asked me to raise this

previously https://ghc.haskell.org/trac/ghc/ticket/2042 seems like it iddn't happen last time because base lived outside of ghc?

-- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] concatMapM f xs = liftM concat (mapM f xs)

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

I'm neutral to slightly negative on the proposal, but if one is going to put it forth, this is a pretty crippled version of what the combinator could be. Switching liftM to fmap, and mapM to traverse gets you Applicative m. There is no reason to limit this to Monad. -Edward On Fri, Feb 8, 2019 at 12:04 PM Carter Schonwald wrote:

friend asked me to raise this

previously https://ghc.haskell.org/trac/ghc/ticket/2042 seems like it iddn't happen last time because base lived outside of ghc?

-- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads. concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] concatMapM f xs = liftM concat (mapM f xs)

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