<div>This has been a lot on my mind lately as my current library provides additional functionality to data types from a wide array of other packages. I face a version of Wadler&#39;s expression problem. </div>
<div> </div>
<div>I provide a set of classes for injecting into monoids/seminearrings/etc. to allow for quick reductions over different data structures. The problem is that of course the interfaces are fairly general so whole swathes of types (including every applicative functor!) qualifies for certain operations. </div>

<div> </div>
<div>Perhaps the ultimate answer would be to push more of the instances down into the source packages. I can do this with some of the monoid instances, but convincing folks of the utility of the fact that their particular applicative forms a right-seminearring when it contains a monoid is another matter entirely. </div>

<div> </div>
<div>The problem is there is no path to get there from here. Getting another library to depend on mine, they have to pick up the brittle dependency set I have now. Splitting my package into smaller packages fails because I need to keep the instances for 3rd party data types packed with the class definitions to avoid orphan instances and poor API design. So the option to split things into the equivalent of &#39;buster-ui&#39;, &#39;buster-network&#39; and so forth largely fails on that design criterion. I can do that for new monoids, rings and so forth that I define that purely layer on top of the base functionality I provide, but not for ones that provide additional instances for 3rd party data types.</div>

<div> </div>
<div>I can keep adding libraries as dependencies like I am doing now, but that means that my library continues to accrete content at an alarming rate and more importantly every one introduces a greater possibility of build issues, because I can only operate in an environment where every one of my dependencies can install.</div>

<div> </div>
<div>This further exacerbates the problem that no one would want to add all of my pedantic instances because to do so they would have to inject a huge brittle dependency into their package.</div>
<div> </div>
<div>The only other alternative that I seem to have at this point in the cabal packaging system is to create a series of flags for optional functionality. This solves _my_ problem, in particular it lets me install on a much broader base of environments, but now the order in which my package was installed with respect to its dependencies matters. In particular, clients of the library won&#39;t know if they have access to half of the instances, and so are stuck limiting themselves to working either on a particular computer, or using the intersection of the functionality I can provide.</div>

<div> </div>
<div>Perhaps, what I would ideally like to have would be some kind of &#39;augments&#39; or &#39;codependencies&#39; clause in the cabal file inside of flags and build targets that indicates packages that should force my package to reinstall after a package matching the version range inside the codependencies clause is installed or at least prompt indicatig that new functionality would be available and what packages you should reinstall.</div>

<div> </div>
<div>This would let me have my cake and eat it too. I could provide a wide array of instances for different stock data types, and I could know that if someone depends on both, say,  &#39;monoids&#39; and &#39;parsec 3&#39; that the parsec instances will be present and usable in my package.</div>

<div> </div>
<div>Most importantly, it would allow me to fix my &#39;expression problem&#39;. Others could introduce dependencies on the easier to install library allowing me to shrink the library and I would be able to install in more environments.</div>

<div> </div>
<div>-Edward Kmett</div>
<div> </div>
<div class="gmail_quote">On Tue, Apr 7, 2009 at 9:20 AM, John Dorsey <span dir="ltr">&lt;<a href="mailto:haskell@colquitt.org">haskell@colquitt.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">John Lato wrote:<br>&gt; I think that the proper solution is to break up libraries into<br>&gt; separate packages as Jeff suggests (buster, buster-ui, etc.), but then<br>&gt; the total packages on hackage would explode.  I don&#39;t feel great about<br>
<br></div>I thought about this a while back and came to the conclusion that the<br>package count should only grow by a small contant factor due to this,<br>and that&#39;s a lot better than dealing with hairy and problematic<br>
dependencies.<br><br>It should usually be:<br><br> libfoo<br> libfoo-blarg<br> libfoo-xyzzy<br> etc.<br><br>and more rarely:<br><br> libbar-with-xyzzy<br> libbar-no-xyzzy<br> etc.<br><br>each providing libbar.  Although I don&#39;t remember whether Cabal has<br>
&#39;provides&#39;.  The latter case could explode exponentially for weird<br>packages that have several soft dependencies that can&#39;t be managed in<br>the plugin manner, but I can&#39;t see that being a real issue.<br>
<br>This looks manageable to me, but I&#39;m no packaging guru.  I guess it&#39;s a<br>little harder for authors/maintainers of packages that look like leaves<br>in the dependency tree, which could be bad.  Am I missing something bad?<br>
<br>Regards,<br><font color="#888888">John<br></font>
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>