IO operations for bytearray

[Boarders]

Often one wants to use ByteArray over a ByteString but you have to implement all of the IO operations yourself (with a good chance for shooting yourself in the foot). I think it would be better if the library provided such operations e.g. taking the operations from ByteString

getLine :: IO ByteArray

getContents :: IO ByteArray

putStr :: ByteArray -> IO ()

interact :: (ByteArray -> ByteArray) -> IO ()

readFile :: FilePath -> IO ByteArray

writeFile :: FilePath -> ByteArray -> IO ()

appendFile :: FilePath -> ByteArray -> IO () 

hGetLine :: Handle -> IO ByteArray

hGetContents :: Handle -> IO ByteArray

hGet :: Handle -> Int -> IO ByteArray

hGetSome :: Handle -> Int -> IO ByteArray

hGetNonBlocking :: Handle -> Int -> IO ByteArray

hPut :: Handle -> ByteArray -> IO ()

hPutNonBlocking :: Handle -> ByteArray -> IO ByteArray

hPutStr :: Handle -> Byte\Array -> IO ()

I realise there are longstanding debates the remit of the primitive library and if this is not the place for it then I think it would be worthwhile for the CLC to declare a place for such utilities. This would give people more of a choice over whether to use ByteArray vs ByteString vs Vector without having to re-implement basics every time (or try to find others who have).

[Bodigrim]

These functions could be tricky to get right, especially getLine / hGetLine. Is conversion between ByteString and ByteArray (haskell/bytestring#186) prohibitively expensive in your use case, @Boarders? Cf. haskell/bytestring#83 discussing IO operations for ShortByteString, which is ByteArray in disguise.

[andrewthad]

I have a few of these available in byteslice, but they operate on Bytes (which is just ByteArray with slicing) instead of ByteArray. What I have found is that, for consumption (ByteArray as an argument), having functions take the sliced variant is preferable. You'll end up having to write the sliced variant anyway if you don't provide these.

To get to the heart of the question, I do not think that primitive is a good place for these. This library has historically concerned itself with boxed wrappers around primops, and I don't see a compelling reason to break with that precedent. Handle-oriented functions can live (as they have already to some extent) in byteslice. There is already a naming convention there of suffixing operations with U when a ByteArray return type makes sense (for example: hGetU :: Handle -> Int -> IO ByteArray would be accepted if PRed). Alternatively, they could live in bytestring, although there, they would need to operate on ShortByteString instead of ByteArray.