Binary IO

[John Meacham]

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 <simonmar at microsoft.com> 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⑈