Bryan O'Sullivan wrote:
Peter Simons suggests that in fact Network.Socket would be a better home for all of the new functionality, instead of Network.BSD, as the IPv6 entry points and constants do not have a BSD heritage (they're defined in RFC 2553, and available on all modern operating systems under the same names). I agree.
It turns out there's a hitch with this notion. The HostName and
ServiceName types are defined in Network.BSD, but they're desirable to
use in the type signature of getAddrInfo.
While it's possible to move these types into a hidden module such that
they're re-exported by Network.BSD and Network.Socket, this has the
nasty consequence of breaking pre-existing network code due to
Network.Socket now exporting these types, causing the Haskell compiler
to complain about the new ambiguities introduced.
I can think of three ways around this.
1. Accept the breakage this causes. I'm not suggesting this as
realistic or desirable, merely a possibility to consider.
2. Put getAddrInfo and getNameInfo into Network.BSD, as my original
patch did. This doesn't break any existing code, but is a bit
disappointing as we can no longer ignore and wholesale deprecate
Network.BSD.
3. Introduce new, non-conflicting type synonyms in Network.Socket for
the use of getAddrInfo and getNameInfo, and ignore the names in
Network.BSD. I could see using NodeName instead of HostName, but I
don't have a good replacement for ServiceName in mind. Furthermore, I
don't know that introducing type synonyms in order to make one or two
function signatures more readable is really desirable. Does anyone have
any opinions?
4. Something else that I haven't thought of.
Answers on the back of a postcard, please. Unless someone indicates a
strong preference, I'll go with option #2.