Proposal: splitting the network package

Henning Thielemann lemming at henning-thielemann.de
Thu Jan 31 11:28:52 CET 2013


On Thu, 31 Jan 2013, Thomas Schilling wrote:

> I don't think this would work. If "network" still contains a module
> Network.URI and a package adds a dependency on "network-uri" which
> also exports a module Network.URI, then you would have to specify the
> package name in your import, i.e.:
>
>  import "network-uri" Network.URI
>
> Then, once Network.URI is removed from "network", users have to edit
> their sources again to remove the explicit package import. I think the
> only reasonable way to handle things is to use flags in a .cabal file,
> i.e., the same way we had to deal with base-3 => base-4 transition
> (which was very annoying).

An alternative would be to split the "network" package into "network-uri" 
and "network-socket". Users of network-uri would have to switch to 
network-socket as well. However, the types of "network" and 
"network-socket" would be incompatible unless the "network-socket" package 
re-exports the modules from "network" or vice versa.

E.g. could we put this into the "network" package:

{-# LANGUAGE PackageImports #-}
module Network.Socket ( module S )  where

import qualified "network-socket" Network.Socket as S

?

Interestingly, the GHC documentation uses Network.Socket for explaining 
the PackageImports extension.



More information about the Libraries mailing list