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
Abraham Egnor wrote:
Passing a Ptr isn't that onerous; it's easy enough to make functions
that have the signature you'd like:
import System.IO
import Data.Word (Word8)
import Foreign.Marshal.Array
hPutBytes :: Handle -> [Word8] -> IO ()
hPutBytes h ws = withArray ws $ \p -> hPutBuf h p $ length ws
Glynn Clements wrote:
Actually, the more I think about it, the more I think that "simple,
stupid programs" probably shouldn't be using Unicode at all.
I.e. Char, String, string literals, and the I/O functions in Prelude,
IO etc should all be using bytes, with a distinct wide-character API
available
Glynn Clements <[EMAIL PROTECTED]> writes:
>> 1. API for manipulating byte sequences in I/O (without representing
>>them in String type).
>
> Note that this needs to include all of the core I/O functions, not
> just reading/writing streams. E.g. FilePath is currently an alias for
> String, but
Marcin 'Qrczak' Kowalczyk wrote:
> >> 1. API for manipulating byte sequences in I/O (without representing
> >>them in String type).
> >
> > Note that this needs to include all of the core I/O functions, not
> > just reading/writing streams. E.g. FilePath is currently an alias for
> > String,
Glynn Clements <[EMAIL PROTECTED]> writes:
> Right now, the attempt at providing I18N "for free", by defining Char
> to mean Unicode, has essentially backfired, IMHO. Anything that isn't
> ISO-8859-1 just doesn't work for the most part, and anyone who wants
Basically, I'm inclined to agree with w
