Me too. The reason is in IO predates me. We should add it under a new name however. On Thu, Aug 28, 2014 at 5:06 PM, David Feuer wrote:

That sounds like a no-brainer to me. On Aug 28, 2014 10:41 AM, "Edward Kmett" wrote:

...

inet_addr doesn't do any lookups, it is basically a glorified parsing problem converting from a string to a host address.

http://hackage.haskell.org/package/network-2.6.0.1/docs/src/Network-Socket.h...

Why, beyond the obvious implementation details, does it live in IO?

Given that the current version lives in IO, should there be a version that is obviously made pure so that folks who want to use it directly can do so without having to bury it behind an unsafePerformIO?

This isn't a concrete proposal at this time, but more an attempt to sound out if such a proposal should be formed.

-Edward

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I'm not opposed to fixing it, but given that people shouldn't be using it anyway I'm not in a hurry. We should be encouraging people to use getAddrInfo rather than baking in IPv4 accidentally. On Aug 28, 2014 8:23 AM, "Michael Snoyman" wrote:

On Thu, Aug 28, 2014 at 6:21 PM, Johan Tibell wrote:

...

Me too. The reason is in IO predates me. We should add it under a new name however.

+1 on the proposal, and +2 on doing it under a new name.

Michael

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Thu, Aug 28, 2014 at 11:28 AM, Thomas DuBuisson < thomas.dubuisson@gmail.com> wrote:

I'd be in favor of a more drastic change, such as removing inet_addr entirely . Largely because `inet_addr("255.255.255.255") ~ inet_addr("foobar")` as noted by the inet_addr man page. Let's add an `inet_aton :: String -> m String` for some `m`.

Or, as previously noted, go straight to getaddrinfo and friends, which have sensible interfaces *and* support more than IPv4. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Thu, Aug 28, 2014 at 1:31 PM, Thomas DuBuisson < thomas.dubuisson@gmail.com> wrote:

I fully support directing users to getAddrInfo. My comment boils down to: let's remove broken functions instead of making them easier to use and less consistent with the rest of the API.

Only if we run a deprecation cycle for at least one major version of network. Just removing a function breaks code for no reason and is user-hostile. It's important to give end users a warning that the function is going away and some time (12 months or more IMO) to fix their code, especially for packages that belong to the platform. G -- Gregory Collins

On Mon, Sep 1, 2014 at 12:47 AM, Gregory Collins wrote:

On Thu, Aug 28, 2014 at 1:31 PM, Thomas DuBuisson < thomas.dubuisson@gmail.com> wrote:

...

I fully support directing users to getAddrInfo. My comment boils down to: let's remove broken functions instead of making them easier to use and less consistent with the rest of the API.

Only if we run a deprecation cycle for at least one major version of network. Just removing a function breaks code for no reason and is user-hostile. It's important to give end users a warning that the function is going away and some time (12 months or more IMO) to fix their code, especially for packages that belong to the platform.

Why bother? Nobody ever does this now, so there's no good reason to start. It only wastes a little bit of end-use time, all they have to do is dig through docs and/or commit messages (or maybe a changelog message, if someone can be bothered to write one) to see if there's a useful replacement mentioned. Seriously, I'm strongly in favor of both removing broken-ness and deprecation cycles. Every time we update our library stack I have to go through this, and every time I run across 4 or 5 libraries (minimum) with functions disappearing out from under us. Even top-20, supposedly well-maintained packages are guilty. John L.