<div class="gmail_quote">On Thu, Feb 26, 2009 at 1:45 PM, Johan Tibell <span dir="ltr">&lt;<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I find it quite inconvenient to use the `recv` function in<br>
Network.Socket as it throws an exception when reaching EOF and there&#39;s<br>
no way to check whether EOF has been reached before calling `recv`.</blockquote><div><br>I agree, the current behaviour is quite unfortunate. In fact, I&#39;m pretty sure I added an entry point named recv_ to network-bytestring to work around precisely this problem.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;m also interested in understanding the reasons behind the design of<br>
the `recv` function in the network library.</blockquote><div><br>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&#39;s buffered, but sockets aren&#39;t buffered, and the symmetric isEOF function isn&#39;t available. I don&#39;t like the way the Handle API works, but I grudgingly accept it as not amenable to change.<br>
<br>There&#39;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&#39;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.<br>
<br>Really, the big thing that&#39;s missing here is enough application of elbow grease from someone who&#39;s got a good eye for design and doesn&#39;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.<br>
</div></div><br>