Re: [Haskell-cafe] Suggestion for Network.Socket in regards to PortNumber

Johan - glad you chimed in! I'm all in favor of keeping a low level interface and don't have an issue with Network.Socket existing, I additionally really like the suggestion of moving from the ML to a wiki in the same style as Haskell'. I'll port these comments to the wiki if that is whats agreed on and hold off on other thoughts for now. * ByteStrings! Absolutely. The one issue is I feel network packets should be represented as strict bytestrings and any encode/decode issues resulting in a 'Left err' via binary-strict or some beefed up version of that package. * Avoiding a 'heavy weight' solution for socket state might get ugly fast with all the 'Either a b' results that we'll need - also a socket can close at any time so a socket in 'Connected' state might not actually be connected. I understand the attraction to a light solution using existential types but Tim Sheard sketched for me a reasonable alternative which I invite him to restate here, if he has the time. Thomas On Mon, Jun 22, 2009 at 12:16 AM, Johan Tibell wrote:

On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson 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