Binary IO

Peter Simons simons at cryp.to
Fri Apr 22 11:09:27 EDT 2005


John Meacham writes:

 >> >> hPutBufNonBlocking :: Handle -> Ptr a -> Int -> IO Int
 >> >> hGetBufNonBlocking :: Handle -> Ptr a -> Int -> IO Int

 >> What is difficult to implement about these functions? Aren't
 >> they just wrappers for read(2) and write(2)?

 > In any case, these seem much too low level for the task
 > at hand, which is to just make portable binary IO
 > _possible_. not necessarily efficient or elegant.

Well, there is a difference between "it is possible" and "it
does actually work", and my guess is that any non-trivial
application which performs byte-wise I/O will _not_ work in
practice. I doubt you could implement Darcs with that API;
and you certainly couldn't implement Bittorrent with this
API (which was the question that spawned this thread).


 > And hGet/PutWord8 are fast enough for most situations.

Are you certain? Which interesting applications do you know
that read and write one byte at a time? I can't speak for
"most" situations, but in those situations where I needed
binary I/O this API would have been impracticable.


 > We certainly don't want to have to teach a new user about
 > Foreign.C.Storable just because they want to do a little
 > simple binary IO.

That's why you write libraries which provide a more
comfortable API based on the primitives. You cannot write
such a library, however, if your primitives are slow to
begin with!

Don't get me wrong -- I don't oppose the addition of those
functions to the standard libraries. I just don't think
they'll be good for much in the real world.

Peter



More information about the Libraries mailing list