Proposal: Add concatMapM function (#2042)

[Johan Tibell]

> 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).

I've been thinking about this lately. As you mentioned, we have
functions that do I/O with Strings. These functions can be split up
into two groups:

* Those who do binary I/O but (ab)use String to store binary data
(e.g. the socket API.) We might want to change their type to [Word8]
or something similar.
* Those who do text I/O. We might want to add an encoding parameter to
those or add other, identical functions that takes the encoding as a
parameter and use a default encoding for the functions that lack
explicit encoding. e.g.

> readFile :: FilePath -> IO String  -- defaults to some encoding
> readFileWithEnc :: Encoding -> FilePath -> IO String  -- explicit encoding, should have a better function name

> data Encoding = Ascii | Utf8 | Utf16  -- no ALL CAPS pretty please!

> decode :: Encoding -> [Word8] -> String  -- you read something from a socket, now you want to decode it

How would such a change fit into the package compatibility proposal
number 4.3? Isn't there also an interaction with the Haskell' spec
here as well if it defines a few of those functions?

-- Johan