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

[Johan Tibell]

On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson <
thomas.dubuisson at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090622/483fcf3f/attachment-0001.html