Proposal: Add concatMapM function (#2042)

[Bulat Ziganshin]

Hello Johan,

Thursday, January 31, 2008, 2:35:06 PM, you wrote:

> * 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

i can quickly tell why it's bad idea. it doubles amount of i/o
functions just for this particular need. then you will notice that we
also need functions which don't lock Handle or add some other
processing and number of functions will double again and again

i don't even say that for practical programming you will quickly find
that passing encoding for particular file down all the functions that
work with it is a nightmare

the right way to deal with "modifiers" is to attach them to the Handle
itself like this:

f <- openFile "name" >>= withLocking >>= withEncoding utf8

and now look at http://haskell.org/haskellwiki/Library/Streams ;)


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

btw, it's another bad idea which means that set of encodings cannot be
changed without changing library. it will be especially "great" if we
will hard-code this into base, meaning that in order to get support
for new encodings you should upgrade your ghc and any new encodings
will become available for ghc users ONE YEAR AFTER actual implementation

in FP language, the best way to provide encoding is to define it as
pair of functions:

data Encoding = Encoding { encode :: String -> String
                         , decode :: String -> String }

utf8 = Encoding encodeUtf8 decodeUtf8


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com