Udo Stenzel wrote:
One more reason to fix the I/O functions to handle encodings and have a seperate/underlying binary I/O API.
The problem is that we also need to fix them to handle *no encoding*.
What are you proposing here? Making the breakage even worse by specifying a text based api that uses "no encoding"?
No. I'm suggesting that many of the I/O functions shouldn't be treating their arguments or return values as text.
Having a seperate byte based api is far better. If you don't know the encoding, all you have is bytes, no text.
My point is that many of the existing functions should be changed to use bytes instead of text (not separate byte/char versions). E.g.: type FilePath = [Byte] If you have a reason to treat a FilePath as text, then you convert it. E.g. names <- getDirectoryContents dir let namesT = map (toString localeEncoding) names We don't need a separate getDirectoryContentsAsText, and we certainly don't want that to be the default. For stream I/O, then having both text and binary read/write functions makes sense.
String's are a list of unicode characters, [Word8] is a list of bytes.
And what comes out of (and goes into) most core library functions is the latter.
So System.Directory needs to be specified in terms of bytes, too. Looks like a clean solution to me.
Sure. But I'm looking for a solution which doesn't involve re-writing
everything, and which won't result in lots of programs suddenly
becoming unreliable if the hardwired default ISO-8859-1 conversion is
changed.
--
Glynn Clements