Re: Binary IO

On Fri, Apr 22, 2005 at 09:38:07AM +0100, Simon Marlow wrote:

On 21 April 2005 18:36, Aaron Denney wrote:

...

On 2005-04-21, Simon Marlow wrote:

...

On 21 April 2005 11:16, John Meacham wrote:

...

but a useful stopgap, because their use would guarentee your code wouldn't suddenly stop working when ghc changes its IO system.

That isn't going to happen, but I take your point.

You mean we're not going to fix it?

Not at all - just that we don't plan to break existing code if/when a replacement for the current I/O library is introduced. Sorry for the misunderstanding.

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).

Sounds good to me. can we please also add readBinaryFile :: String -> IO [Word8] writeBinaryFile :: String -> [Word8] -> IO () these would sidestep the whole opening the file in binary mode issue and are non-trivial to implement (needing unsafeInterleaveIO). They are also quite useful says anecdotal evidence! (all of these will be implemented in jhc. if we get hugs and nhc then we actually can write portable code that uses binary data for the first time and without resorting to cpp! yay!)

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).

jhc has a similar restriction. mainly, you can't mix hGetWord8 an hGetChar routines. this is due to underlying restrictions on getwchar. I will add a compatable openBinaryFile routine so code can be written portably between the two. I assume it is also okay to use them on Sockets too.

I presume that hPutWord8 (fromIntegral (ord '\n')) should not flush a line-buffered Handle, which is another slight complication. Perhaps line-buffering should be the same as block-buffering on binary Handles.

Why second-guess the user? if they want block-buffering, let them choose it. line-buffering should be left as is on binary handles. After all, they might be communicating with a terminal but in binary mode because they are handling their own character encoding or speaking strange ANSI-esque escape codes. John -- John Meacham - ⑆repetae.net⑆john⑈