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