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

[John Van Enk]

Moving off list to the Wiki has my vote.

On Mon, Jun 22, 2009 at 7:52 AM, Thomas
DuBuisson<thomas.dubuisson at gmail.com> wrote:
> 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
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
/jve