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

[Johan Tibell]

On Fri, Feb 27, 2009 at 12:03 AM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> 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.

Yes, that's indeed the reason we added it. My current thinking is that
we'd drop `recv` from network-bytestring in favor of `recv_`. I've
checked how many libraries on Hackage depend on network-bytestring and
there are few enough that we could make such a change. It's a bit
unfortunate that these libraries have an open dependency on
network-bytestring (e.g. network-bytestring >= 0.1.1.2). I will
contact the maintainers of those libraries before making a new
release.

> 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.

I would be interested in trying to create a better API. However, I'm
not sure what it would look like. The design space is pretty big.

* How can we provide the static guarantees we want? Perhaps with some
kind of lightweight monadic regions but if so which definition should
we use i.e. can a region return a Socket to the parent region or not?
This has implications on how easy the API is to understand.

* Should we use enumerators or not? Can they be added as a convenience
layer on top of type safe low-level layer?

Cheers,

Johan