On Thu, 2009-02-26 at 22:45 +0100, Johan Tibell wrote: > Hi all, > > 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`. > This means that all calls to `recv` needs to be wrapped in an > exception handler.
NB: tryJust (guard . isEOFError) $ recv ... with base-4 or tryJust (ioErrors >=> guard . isEOFError) $ recv ... with base-3, right? > I've been thinking about changing the version of > `recv` that's included in the network-bytestring library [1] so it > behaves differently from the one in the network library. Before I do > so I thought I should see if we can reach a consensus on what a nicer > definition of `recv` would look like. My current thinking is that it > would mimic what C/Python/Java does and return a zero length > ByteString when EOF is reached. +1 In the interest of totality. Also, Prelude.getChar/System.IO.hGetChar should have return type IO (Maybe Char) in the interest of totality. > I'm also interested in understanding the reasons behind the design of > the `recv` function in the network library. More generally, I'm > interested in discussing the pros and cons of the current Haskell I/O > library design where the different read functions throw EOF exceptions > and you have to call e.g. hIsEOF before reading from a Handle. > > 1. http://github.com/tibbe/network-bytestring jcc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe