Suggestion for Network.Socket in regards to PortNumber

older
Re: [Haskell-cafe] GHCi infers a...

John Van Enk

21 Jun 2009 21 Jun '09

9:45 p.m.

Hello List, Is there any one else in favor of hiding the PortNum constructor in Network.Socket in the next release? Here's why: Prelude> :m + Network.Socket Data.Word Prelude Network.Socket Data.Word> let p = 5000 :: Word16 Prelude Network.Socket Data.Word> let p' = PortNum p Prelude Network.Socket Data.Word> let p'' = fromIntegral p :: PortNumber Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1.1 ... linking ... done. Prelude Network.Socket Data.Word> p 5000 Prelude Network.Socket Data.Word> p' 34835 Prelude Network.Socket Data.Word> p'' 5000 Notice that using the PortNum constructor does not at all do what the user expects. This really should be a hidden constructor. Perhaps we can add the following: mkPortNum :: (Num a) => a -> PortNumber mkPortNum p = fromIntegral p /jve

Show replies by date

Donn Cave

21 Jun 21 Jun

10:02 p.m.

Quoth John Van Enk , [... example showing that PortNum is stored in network byte order ]

...

Notice that using the PortNum constructor does not at all do what the user expects. This really should be a hidden constructor.

Could you elaborate, what does the user expect? Donn

John Van Enk

10:59 p.m.

On Sun, Jun 21, 2009 at 6:02 PM, Donn Cave wrote:

...

Could you elaborate, what does the user expect?

Users will probably expect (PortNum 0x2000) to represent a port number of 0x2000 (8192), not 0x0020 (32). /jve

Thomas DuBuisson

11:22 p.m.

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. Thomas On Sun, Jun 21, 2009 at 2:45 PM, John Van Enk wrote:

...

Hello List,

Is there any one else in favor of hiding the PortNum constructor in Network.Socket in the next release? Here's why:

Prelude> :m + Network.Socket Data.Word Prelude Network.Socket Data.Word> let p = 5000 :: Word16 Prelude Network.Socket Data.Word> let p' = PortNum p Prelude Network.Socket Data.Word> let p'' = fromIntegral p :: PortNumber Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1.1 ... linking ... done. Prelude Network.Socket Data.Word> p 5000 Prelude Network.Socket Data.Word> p' 34835 Prelude Network.Socket Data.Word> p'' 5000

Notice that using the PortNum constructor does not at all do what the user expects. This really should be a hidden constructor.

Perhaps we can add the following:

mkPortNum :: (Num a) => a -> PortNumber mkPortNum p = fromIntegral p

/jve _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Johan Tibell

22 Jun 22 Jun

7:16 a.m.

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

Thomas DuBuisson

11:52 a.m.

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

John Van Enk

11:55 a.m.

Moving off list to the Wiki has my vote. On Mon, Jun 22, 2009 at 7:52 AM, Thomas DuBuisson 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 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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /jve

Johan Tibell

12:03 p.m.

On Mon, Jun 22, 2009 at 1:52 PM, Thomas DuBuisson < thomas.dubuisson@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.

Yes, please start a new wiki page. We can still discuss issues here and add things to the wiki as different solutions materialize.

...

* 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.

Good point. The encodings using existential types are not very lightweight in my opinion. I'd love to hear Tim's alternative. -- Johan

Thomas DuBuisson

12:46 p.m.

All, I've started to add to the network trac [1] - its just framework for now. Please do add proposals, organized comments, and feel free to alter the framework. I'm not sure how formal we'd like to make this so I haven't even tried to make guidelines for proposals. I'll add proposals and perhaps try my hand at guidelines throughout this week. Thomas [1] http://trac.haskell.org/network/wiki/WikiStart Possible proposal guidelines: [2] http://hackage.haskell.org/trac/haskell-prime/wiki/CreateProposal [3] http://www.python.org/dev/peps/ On Mon, Jun 22, 2009 at 5:03 AM, Johan Tibell wrote:

...

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

Yes, please start a new wiki page. We can still discuss issues here and add things to the wiki as different solutions materialize.

...
* 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.

Good point. The encodings using existential types are not very lightweight in my opinion. I'd love to hear Tim's alternative.

-- Johan

Johan Tibell

3:19 p.m.

On Mon, Jun 22, 2009 at 2:46 PM, Thomas DuBuisson < thomas.dubuisson@gmail.com> wrote:

...

All, I've started to add to the network trac [1] - its just framework for now. Please do add proposals, organized comments, and feel free to alter the framework. I'm not sure how formal we'd like to make this so I haven't even tried to make guidelines for proposals. I'll add proposals and perhaps try my hand at guidelines throughout this week.

Lets just get some concrete proposals up there and see if we need some kind of guidelines and what those guidelines should be. FWIW I like the PEP style. -- Johan

John Van Enk

24 Jun 24 Jun

7:15 p.m.

One thing I'd really like to see, now that I'm thinking about it, is to drop the dependency on the ./configure step when building network. If I can figure this out without changing how Network.Socket works now, would that be something we could merge into the package? I've love to see a Build-Type of Simple. On Mon, Jun 22, 2009 at 8:03 AM, Johan Tibell wrote:

...

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

Yes, please start a new wiki page. We can still discuss issues here and add things to the wiki as different solutions materialize.

...
* 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.

Good point. The encodings using existential types are not very lightweight in my opinion. I'd love to hear Tim's alternative.

-- Johan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /jve

Johan Tibell

7:25 p.m.

On Wed, Jun 24, 2009 at 9:15 PM, John Van Enk wrote:

...

One thing I'd really like to see, now that I'm thinking about it, is to drop the dependency on the ./configure step when building network. If I can figure this out without changing how Network.Socket works now, would that be something we could merge into the package?

I've love to see a Build-Type of Simple.

I would like this as well and I've talked briefly with Duncan about it. Someone who knows autoconf well needs to figure out everything configure does for the network package and if we can get Cabal to do it instead -- Johan

John Van Enk

7:28 p.m.

I'll take a swing at it. :) If it's as easy as it was to get HsOpenSSL to build without the ./configure (on windows even!), it shouldn't be too bad. PS: If any one has contact with the maintainers of HsOpenSSL, poke them for me. I'd like my patch included. :) On Wed, Jun 24, 2009 at 3:25 PM, Johan Tibell wrote:

...

On Wed, Jun 24, 2009 at 9:15 PM, John Van Enk wrote:

...
One thing I'd really like to see, now that I'm thinking about it, is to drop the dependency on the ./configure step when building network. If I can figure this out without changing how Network.Socket works now, would that be something we could merge into the package?

I've love to see a Build-Type of Simple.

I would like this as well and I've talked briefly with Duncan about it. Someone who knows autoconf well needs to figure out everything configure does for the network package and if we can get Cabal to do it instead

-- Johan

-- /jve

5862

Age (days ago)

5865

Last active (days ago)

List overview

Download

12 comments

4 participants

participants (4)

Donn Cave
Johan Tibell
John Van Enk
Thomas DuBuisson