<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 31, 2013 at 12:28 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Thu, 31 Jan 2013, Thomas Schilling wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think this would work. If "network" still contains a module<br>
Network.URI and a package adds a dependency on "network-uri" which<br>
also exports a module Network.URI, then you would have to specify the<br>
package name in your import, i.e.:<br>
<br>
import "network-uri" Network.URI<br>
<br>
Then, once Network.URI is removed from "network", users have to edit<br>
their sources again to remove the explicit package import. I think the<br>
only reasonable way to handle things is to use flags in a .cabal file,<br>
i.e., the same way we had to deal with base-3 => base-4 transition<br>
(which was very annoying).<br>
</blockquote>
<br></div>
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.<br>
<br>
E.g. could we put this into the "network" package:<br>
<br>
{-# LANGUAGE PackageImports #-}<br>
module Network.Socket ( module S ) where<br>
<br>
import qualified "network-socket" Network.Socket as S<br>
<br>
?<br>
<br>
Interestingly, the GHC documentation uses Network.Socket for explaining the PackageImports extension.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Recently, we have a similar situation with http-conduit. Based on that, I'd recommend going for a conditional export situation.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>* Release a new version of network (1.5) that does not include the Network.URI module.</div><div class="gmail_extra" style>* Create a network-uri package that uses conditionals in the cabal file.</div>
<div class="gmail_extra" style> * If it's compiled against network version 1.4 or earlier, it doesn't provide any modules.</div><div class="gmail_extra" style> * If it's compiled against network 1.5 or later, it provides the Network.URI module.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>This way, there's only ever one package which is providing Network.URI.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Note: I think there might be a requirement that a library section always have at least one exported module. If so, I suppose network-uri should always export some extra package as well, perhaps Network.URI.Temp which contains everything in Network.URI.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Michael</div></div>