Glynn Clements writes:
The problem is that API for that yet is not even designed, so programs can't be written such that they will work after the default encoding change.
Personally, I would take the C approach: redefine Char to mean a byte (i.e. CChar), treat string literals as bytes, keep the existing type signatures on all of the existing Haskell98 functions, and provide a completely new wide-character API for those who wish to use it.
I really don't like having a type called "Char" that's defined to be a byte, rather than a character. On the other hand, I don't know how much of a pain it would be to replace Char with Word8 in the file IO library, which would be my preferred temporary solution.
Given the frequency with which this issue crops up, and the associated lack of action to date, I'd rather not have to wait until someone finally gets around to designing the new, improved, genuinely-I18N-ised API before we can read/write arbitrary files without too much effort.
Any I18N-ized API would need a bit-level layer underneath, right? In
fact, a good low-level IO library could support multiple higher-level
APIs. Has there been any progress on something like that?
--
David Menendez