Proposal: Add concatMapM function (#2042)
johan.tibell at gmail.com
Thu Jan 31 06:35:06 EST 2008
> Freezing base is a bad idea.
> - we'd end up with silly packages called things like 'listexts' with
> - 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?
More information about the Libraries