<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="MsoNormal" style="margin-left:36.0pt">It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString."<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Reading your blog post [1] it seems that we are addressing different questions:<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Calibri",sans-serif">My proposal is only that the act of *<b>installing</b>* a package does not break existing installed package, and is not rejected because it risks doing
so.</span></p></div></div></blockquote><div>Thank you for the clarification, I had misread that. On that front: I agree. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Calibri",sans-serif">You agree that the confusing behaviour you describe can’t happen with Cabal. In any one build, Cabal can ensure that only one version of each package is
used in the build, so such a message could never show up.</span></p></div></div></blockquote><div>I've seen people discussing exactly such a change to Cabal's behavior, so I mistakenly took your comments to be heading in that direction. While I think there *might* be some future where we could expose that functionality, it could be incredibly confusing. I'd feel much better starting off with simply the act of installing. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="font-family:"Calibri",sans-serif"> <u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Calibri",sans-serif">What you want is for the confusing behaviour to be true of GHCi too. Well that’s simple enough: ensure that the set of
<b>exposed</b> packages (ie the ones you say ‘import M’ for), is consistent in the same way. The point is that I may need to install a bunch of packages to build a program. If I’m using Cabal, none of those newly installed packages need be exposed; I simply
need them there so I can compile my program (using Cabal). But at the moment I can’t do that.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">That leaves open the following question. Suppose<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Calibri",sans-serif">I want to install
<b>and expose</b> package P and Q<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Calibri",sans-serif">But alas, P depends on containers 2.9 and Q depends on containers 3.1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Now I’m stuck. But there is a good reason for being stuck, and one that is explicable.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><u></u> </span></p></div></div></blockquote><div><br></div><div>If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above</div><div><br></div><div>* if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden</div><div>* if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden</div><div><br></div><div>But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right?</div><div><br></div><div>Michael</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
</blockquote>
</div>
</div>
</div></div></div></blockquote></div></div>