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