[Haskell-cafe] Coming up with a better API for Network.Socket.recv

[Bryan O'Sullivan]

On Thu, Feb 26, 2009 at 1:45 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> I find it quite inconvenient to use the `recv` function in
> Network.Socket as it throws an exception when reaching EOF and there's
> no way to check whether EOF has been reached before calling `recv`.


I agree, the current behaviour is quite unfortunate. In fact, I'm pretty
sure I added an entry point named recv_ to network-bytestring to work around
precisely this problem.


> I'm also interested in understanding the reasons behind the design of
> the `recv` function in the network library.


I think that it was modeled after the Handle API, which provides an isEOF
function that you can call to see whether a Handle is done before you try
reading it. This works well enough on a Handle because it's buffered, but
sockets aren't buffered, and the symmetric isEOF function isn't available. I
don't like the way the Handle API works, but I grudgingly accept it as not
amenable to change.

There's another problem with the network APIs: they mirror the BSD socket
API too faithfully, and provide insufficient type safety. You can try to
send on an unconnected socket, and to bind a socket that's already
connected, both of which should be statically forbidden. The APIs for
datagram-oriented networking ought to be distinct from the stream-oriented
variety, I think, even if the underlying C-level calls end up being
substantially the same.

Really, the big thing that's missing here is enough application of elbow
grease from someone who's got a good eye for design and doesn't mind all the
slog involved. I think that if someone published a network-alt package (much
like the one that was published a few years ago) and tooted their horn
vigorously enough, we could put the existing network package out to pasture
in fairly short order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090226/0d13e7df/attachment.htm