<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";
color:#1F497D;}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Vishal<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Just to reiterate:<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt;margin-left:36.0pt">
<i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail.</span></i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">
The above is a start, but clearly I’m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I’m sure I have repeated above stuff that is well worn territory.)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I urge you strongly to begin your project by writing out your proposed design, and seeking feedback from the community.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Vishal Agrawal [mailto:vishal4556@gmail.com]
<br>
<b>Sent:</b> 12 May 2015 18:54<br>
<b>To:</b> Simon Peyton Jones<br>
<b>Cc:</b> Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan@well-typed.com); Ryan Trinkle; haskell-infrastructure@community.galois.com; cabal-devel@haskell.org; ghc-devs@haskell.org; Haskell Libraries<br>
<b>Subject:</b> Re: QRE: Cabal and simultaneous installations of the same package<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Yes, consistency means allowing only a single instance of a package in a environment.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
A environment is very cheap to create than sandbox. Like every time a package is imported in ghci, a new environment is created which includes all the earlier package and new package. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Multiple environment can give sandbox for free.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Single database will have many benefits, although I don't think it is requirement. I plan to move to single database somewhat in middle.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Tue, May 12, 2015 at 7:09 PM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<span style="font-size:10.5pt;background:white">Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all
of the existing packages.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.5pt;background:white"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Let’s see if I understand this correctly. I believe that Duncan/you envisage the following scenario:</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Package database</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">: you can install any package, compiled against any dependencies,
without breaking anything. So the package database can contain multiple instances of P-2.3, compiled against different dependencies.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Environment</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">. The “environment” maps a package name, such as “P-2.3” to a particular
package instance in the database. When you say “ghc –c Foo.hs –package P”, the “-package 2.3” consults the environment to determine which of the many P-2.3 instances you might mean.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Mind you, GHC’s new –package flag takes a package key (which identifies a unique package instance in the database). So I’m hazy about exactly when the environment is used.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">You can in principle have many environments (akin to sandboxes) but only one database</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">.
There is a UI issue about how you define and maintain environments.</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Duncan argues that, for predictability,
<b>every environment should be</b> <b>consistent</b>. </span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:72.0pt">
<span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D">o</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’m not sure exactly what “consistent” means. Can I have P-2.3 and P-2.4 in the same environment, or only one P (for a given package name P)?</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:72.0pt">
<span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D">o</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Intuitively, though, “consistent” means that all packages in the environment are compatible; they won’t give rise to the confusing “P-2.3:M.T does not match P-2.4:M.T” errors.
</span><o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The environment is irrelevant when cabal is installing a package,</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">. Cabal just computes
a set of consistent dependencies, installs any missing dependencies, and installs the package. So the environment only matters for explicit user –package flags.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out
in detail.</span></i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> The above is a start, but clearly I’m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I’m
sure I have repeated above stuff that is well worn territory.)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks!</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Simon</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Vishal
Agrawal [mailto:<a href="mailto:vishal4556@gmail.com" target="_blank">vishal4556@gmail.com</a>]
<br>
<b>Sent:</b> 11 May 2015 23:02<br>
<b>To:</b> Simon Peyton Jones<br>
<b>Cc:</b> Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (<a href="mailto:duncan@well-typed.com" target="_blank">duncan@well-typed.com</a>); Ryan Trinkle;
<a href="mailto:haskell-infrastructure@community.galois.com" target="_blank">haskell-infrastructure@community.galois.com</a>;
<a href="mailto:cabal-devel@haskell.org" target="_blank">cabal-devel@haskell.org</a>;
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>; Haskell Libraries</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: QRE: Cabal and simultaneous installations of the same package<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.5pt">Thanks. I will start working on it soon. Currently I am having a great mentorship by Ryan Trinkle. We have talked a few times, mostly about the plan
of the project. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.5pt">The main problem that can arise by the project is by enforcing consistency. It is already well documented by Duncan Coutts in a blog post from which
I took most of the ideas from. <a href="http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/" target="_blank"><span style="color:purple">http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/</span></a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.5pt">> <span style="background:white">Enforcing consistency does have implications for the user interface. There will be situations where one wants to
install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. For example, suppose we have two different web stacks that have many packages in common but that require different versions of some
common package. In that case we could not have a consistent environment that contains both. Thus the user interface will have to do something when the user asks to add the second web stack to an environment that already contains the first. The user interface
could minimise the problem by encouraging a style of use where most environments are quite small, but it cannot be avoided in general.</span></span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:16.8pt;background:white">
<span style="font-size:10.5pt">> While what I am suggesting for consistency is relatively strong, we cannot get away without enforcing some restrictions on the environment. For example if our environment did contain two instances of the same version of a package
then which one would we get when we launch GHCi? So my view is that given that we cannot avoid the user interface issues with environment consistency, it is better to go for the stronger and more useful form.</span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.5pt">I am little unsure about what other community members think about it, but there is an acceptance from Duncan Coutts. If consistency is not enforced,
errors like ‘bytestring is not bytestring’ can increase many times after implementing persistent package store as there will be a larger pool of packages. If enforced, there might be situation where developer will not be able load two package at the same time
which can earlier work at the same time. My personal preference is to enforce consistency.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 11-May-2015, at 9:47 pm, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Exactly! It’s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it’s possible to install
two instances of A-2.0. My fingers can almost touch it. Go Vishal!</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Simon</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Boespflug,
Mathieu [<a href="mailto:m@tweag.io" target="_blank">mailto:m@tweag.io</a>] <br>
<b>Sent:</b> 11 May 2015 16:42<br>
<b>To:</b> Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (<a href="mailto:duncan@well-typed.com" target="_blank">duncan@well-typed.com</a>); Ryan Trinkle;
<a href="mailto:haskell-infrastructure@community.galois.com" target="_blank">haskell-infrastructure@community.galois.com</a>;
<a href="mailto:cabal-devel@haskell.org" target="_blank">cabal-devel@haskell.org</a>;
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>; Vishal Agrawal; Haskell Libraries<br>
<b>Subject:</b> Re: QRE: Cabal and simultaneous installations of the same package</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just
one instance of a lib in any given binary.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had
you started from an empty sandbox, then you would be able to build the app!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2
simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">On 11 May 2015 at 14:52, Daniel Trstenjak <<a href="mailto:daniel.trstenjak@gmail.com" target="_blank"><span style="color:purple">daniel.trstenjak@gmail.com</span></a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><br>
Hi Simon,<br>
<br>
On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote:<br>
> Well, no one is actually suggesting that!<br>
<br>
But you're just getting it automatically if you're depending e.g.<br>
on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0.<br>
<br>
Currently you can't build this dependency graph, right? And with<br>
this proposed feature you will be getting C 1.0 and 2.0 into your binary.<br>
<br>
<br>
Perhaps a even more nasty case is, if you're using a haskell library<br>
which wraps a stateful c library, and now you're having multiple<br>
versions of the same haskell library operating on the same c library state.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><br>
<br>
Greetings,<br>
Daniel<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank"><span style="color:purple">ghc-devs@haskell.org</span></a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank"><span style="color:purple">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</span></a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>