Binary IO

[Benjamin Franksen]

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