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 <[EMAIL PROTECTED]> | "In this house, we obey the laws <http://www.eyrie.org/~zednenem> | of thermodynamics!" _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
