Word8-Based IO

[Simon Marlow]

> Was there any kind of consensus emerging on this? Leaving aside what=20
> might be done with the Char-based functions (and people seem to think=20
> they're fine as is) I'd like to suggest the following:
>=20
> * System.IO: addition of new Word8-based functions
>=20
>   hGetOctet :: Handle -> IO Word8
>   hLookAheadOctet :: Handle -> IO Word8
>   hPutOctet :: Handle -> Word8 -> IO ()

I'd go for hGetWord8, hLookAheadWord8 and so on, but it's not a big
deal.

>   hPutArray :: Handle -> [Word8] -> IO ()

There are currently these two functions in Data.Array.IO:

  hGetArray :: Handle -> IOUArray Int Word8 -> Int -> IO Int=20
  hPutArray :: Handle -> IOUArray Int Word8 -> Int -> IO ()=20

turning an IOUArray Int Word8 into [Word8] is accomplished by
Data.Array.IArray.elems.

>   hLazyGetArray :: Handle -> IO [Word8]

Other suggestions: hGetContentsRaw, hGetWord8Contents

> ...as per hGetChar, hLookAhead, hPutChar, hPutStr and hGetContents.
>=20
>   hGetArrayBlock :: Handle -> Int -> IO [Word8]
>   hGetArrayReady :: Handle -> Int -> IO [Word8]
>=20
> hGetArrayBlock would read so many octets from the handle, up=20
> to the EOF.
> hGetArrayReady would read so many octets from the handle, up=20
> to the EOF=20
> or octets not ready. The semantics would be something like this:

We used to have hGetBuf and hGetBufFull in IOExts, which are analogous
to your hGetArrayReady and hGetArrayBlock respectively.  I forget why
exactly, but we removed hGetBufFull and made hGetBuf behave as the
blocking version.

Hmm, I'm not sure about these functions returns lists.  Arrays seem more
natural to me, also given that we have nice overloaded support for
arrays which makes conversion to/from lists painless.

> ...but I expect they should be implemented natively.
>=20
>   hSetFileSize :: Handle -> Integer -> IO ()
>=20
> There's currently no way to set the size of a file.=20
> hSetFileSize would truncate the file or pad with zero octets.

Yes, we should have this too.

> * Network.Socket
>=20
> The send & receive functions don't do any kind of character=20
> interpretation do they? I suggest these functions be given=20
> new types (and=20
> probably new names, as I suppose we'll need the old ones for=20
> compatibility):
>=20
>   sendTo :: Socket -> [Word8] -> SockAddr -> IO Int
>   recvFrom :: Socket -> Int -> IO ([Word8], Int, SockAddr)
>   send :: Socket -> [Word8] -> IO Int
>   recv :: Socket -> Int -> IO [Word8]

Yes, sounds fine.

Cheers,
	Simon