Proposal [Trac #1212]: add IPv6 support to network library

[Bryan O'Sullivan]

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.

	<b