On Friday 22 April 2005 10:38, 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).
These should definitely be there, no matter what the name.
One constraint would be that the Handle has to be in Binary mode.
Why?
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).
So what? If the handle is in text mode, you won't get the exact bytes as they are in the file, when calling hGetWord8 (at least on some systems). But that is exactly what I would expect if the handle is in text mode. If I need the exact binary representation of a text file, I have to use binary, of course.
I presume that hPutWord8 (fromIntegral (ord '\n')) should not flush a line-buffered Handle,
I can't see a reason not to flush it. Could you explain why you think it should not? What have terminal settings to do with file handle modes??
which is another slight complication. Perhaps line-buffering should be the same as block-buffering on binary Handles.
I don't know if this is a good idea. What if I want to talk to a terminal in line buffered mode using binary IO (for instance to do en- and decoding myself)? I may be overlooking something important but I cannot see why we need any of these restrictions. Binary IO should be the foundation on which higher level functions can be built. If you restrict the most basic IO primitives (for instance by requiring binary mode or ignoring line buffering) this is no longer possible in general. Ben