benjamin.franksen at bessy.de
Fri Apr 22 06:35:21 EDT 2005
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
These should definitely be there, no matter what the name.
> 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).
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
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.
More information about the Libraries