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