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

Simon Marlow writes:

Does anyone have any *objections* to introducing

System.IO.hGetWord8 :: Handle -> IO Word8 System.IO.hPutWord8 :: Word8 -> Handle -> IO Word8

I don't mind having these functions, but to be honest I doubt that they would be useful for real life applications. Reading a byte at a time is a performance nightmare, buffering or not. IMHO, the much better API is this one: hPutBufNonBlocking :: Handle -> Ptr a -> Int -> IO Int hGetBufNonBlocking :: Handle -> Ptr a -> Int -> IO Int Peter

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⑈