Simon Marlow wrote:
Does anyone have any *objections* to introducing
System.IO.hGetWord8 :: Handle -> IO Word8 System.IO.hPutWord8 :: Word8 -> Handle -> IO Word8
(I prefer these names, please speak up if you prefer hGetByte/hPutByte instead, or something else like hGetOctet/hPutOctet).
No objections (other than the argument order, as Henning pointed out), but I would prefer byte/octet; I don't really care which.
One constraint would be that the Handle has to be in Binary mode. Lifting this constraint in GHC is a bit tricky because we currenly use the OS's text<->binary translation to do I/O (doesn't matter on Unix, right now).
Byte I/O should work on both text and binary streams.
I presume that hPutWord8 (fromIntegral (ord '\n')) should not flush a line-buffered Handle, which is another slight complication.
No, it should flush it.
Perhaps line-buffering should be the same as block-buffering on binary Handles.
Buffering mode and EOL conversions should be orthogonal.
With regard to the last three points, byte I/O isn't just for binary
files. It's equally useful for "8-bit text" I/O, i.e. the historical
Unix (and ANSI C stdio) model, where and you just shuffle bytes around
without paying attention to the encoding.
--
Glynn Clements