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

[Thomas DuBuisson]

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<johan.tibell at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>