On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson < thomas.dubuis...@gmail.com> wrote:
> I'm in favor of the entire Network library being reworked with an > improved API that is higher level and type-safe instead of a direct > translation/FFI of Berkeley sockets. I also would like the Network > package to export Data instances for headers while taking advantage of > pretty, prettyclass, and parsec. I started such work with > network-data but never really got off the ground with it. > I've given this some thought. There are a few different things that would be nice to have in a new API: * Use a binary type (e.g. ByteString) instead of Strings. (see network-bytestring) * Encoding more things in the type system, in particular the socket state (opened, closed, connected, etc). I would like to avoid a very heavyweight encoding though. * Allow folds over the input i.e. foldSocket :: (a -> ByteString -> a) -> a -> Socket -> IO a I'm all for having a higher level API but I would like to keep the Berkeley socket interface. The reason is the following: If we provide a higher level API that does not expose the whole underlying OS API there will be some users who can't use the library and will have to resort to writing their own bindings. I've seen this problem in a few other libraries. The reasoning often goes something like this: This interface will cover 90% (or 95%) of all the use cases so its sufficient for most people. The problem with this kind of reasoning is that I have to write my own OS bindings for every ten libraries I use (on average). Perhaps we should start a wiki page where we can take some notes on things that could be improved in the style of Haskell' discussions (i.e. outlines of the problem together possible solutions together with their trade-offs. Python's PEPs are a good model here)? -- Johan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe