Proposal: Add concatMapM function (#2042)

[Simon Marlow]

Bulat Ziganshin wrote:
> Hello Henning,
> 
> Tuesday, January 29, 2008, 9:54:18 PM, you wrote:
> 
>> The question is - where to add it, if not to Data.List? We could setup new
>> Data.List.Extras. But this would have the same problem like Data.List.
>> Is the solution to move Data.List from 'base' to 'containers' or so, since
>> the basic list functions are already in Prelude?
> 
> the whole problem is that base is hard-wired with ghc and CAN'T BE
> UPGRADED. so i propose to add new package for all those new funcs and
> freeze base to solve problem of ghc versions incompatibility

Freezing base is a bad idea.

  - we'd end up with silly packages called things like 'listexts' with
    Data.List.Exts.

  - we have no way of evolving the design of the libraries, no way to
    make improvements.  We're stuck with a design which is widely
    acknowledged to be lacking in various serious ways (e.g. no Unicode
    in the IO library).

What we propose to do instead is to provide better support for backwards 
compatibility.  I'm honestly not sure whether this will lead to more 
problems, or whether it will just work nicely, but it's pretty clear we 
have to try.

Before responding, take a good read through

http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility

In particular, I think the most practical approach is 4.3, although this 
doesn't give complete backwards compatibility.  If you have a better 
suggestion, let's hear it - but please nothing of the form "oh, it must be 
possible to just do X", think about all the ramifications of "just doing X" 
and add a proposal to the wiki page, or write a new page.

In addition to this, we need to get packages using the Package Versioning 
Policy:

http://haskell.org/haskellwiki/Package_versioning_policy

For this we need support in Cabal and/or Hackage.  By the time we release 
GHC 6.10, we want most packages in Hackage using accurate dependencies, so 
that the majority will continue to work with GHC 6.10.

Something else we have to think about is upgrades.  We're now commonly 
seeing multiple versions of packages installed, leading to problems when 
resolving dependencies ends up with two different versions of a given 
package, and type errors ensue.  It's probably time to start a new wiki 
page for thinking about solutions to this.

Cheers,
	Simon