simonmar at microsoft.com
Fri Apr 22 04:38:07 EDT 2005
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
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).
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,
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.
More information about the Libraries