Hi Tim,<div>it seems a good idea, although I hardly believe such isolation is achievable in practice. Just a feeling, though :)</div><div>However, I really hope we, as a community, will be able to finally fix the Cabal Hell. It's a topic with a lot of hype lately,</div>
<div>but few "practical, hands dirty" approaches :)</div><div><br></div><div>Cheers,</div><div>Alfredo</div><div><br><div class="gmail_quote">On 18 November 2012 13:33, <span dir="ltr"><<a href="mailto:timothyhobbs@seznam.cz" target="_blank">timothyhobbs@seznam.cz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I've read a lot of negative regarding the problems with cabal and hackage.<br>I've written quite a few of them myself.<br>
<br>I want to propose a simple change in philosophy of packages.<br><br>Haskell has inherited a philosophy from the imperative world,<br>that there are two types of packages:<br>Libraries and applications.<br><br>Libraries are big collections of modules.<br>
Applications are big collections of modules.<br><br>There is a difference from the perspective of the build system. <br><br>Applications are big collections of modules that belong together and mutually rely upon each other for the application to work. Such that if one module is missing, the application cannot build and thus cannot do useful tasks. If an application doesn't build, then the maintainer has to go and fix that problem. This isn't perfect, I do not solve this problem in this email.<br>
<br>Libraries don't always have this property.<br>For example, <span><a href="http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Column.html" target="_blank">XMonad.Layout.Column</a> has no mutual dependency on </span><span><a href="http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Circle.html" target="_blank">XMonad.Layout.Circle</a>.<br>
<br>This is a feature of libraries that can and should be taken advantage of wherever possible :)<br><br>We can and should,<br>break up libraries into "books".<br><br>I hold this opinion,<br>because libraries are hard to maintain.<br>
<br>If xmonad-contrib refuses to build,<br>I open up it's source code,<br>and see some hundred modules.<br><br>I cannot,<br>as a non-xmonad developer,<br>imagine myself fixing such a large library.<br>But if it was just one small module from that library I wanted,<br>
and it refused to build,<br>and I opened it up,<br>and there were just 3 files there.<br>I wouldn't feel so overwhelmed.<br><br>I would fix the problem myself.<br><br>What I'm trying to say,<br>is that "books"<br>
(small packages containing 3 modules or less)<br>are so easy to maintain,<br>that they really need no maintainer at all.<br>Any idiot can fix one.<br><br>But libraries,<br>with their hundreds of modules,<br>and seemingly endless dependencies,<br>
Can be much harder to maintain,<br>and require a knowledgeable maintainer.<br><br>So lets stop publishing libraries,<br>and maintaining libraries,<br>and listening to people crying when libraries don't build,<br>and lets start writing books,<br>
and publishing really small packages,<br>that are so simple anyone can fix them when they break<br>even when they have no in depth knowledge of the package.<br><br>Lets make a new guideline for "libraries"<br>that if it is possible to split a library into two or more,<br>
non-mutually dependent parts,<br>than we *should* split them such.<br><br>Timothy<br><br>PS,<br><br>I noticed that yesod is already a collection of "books",<br>but it appears to me, that these packages are STILL mutually dependent :(<br>
</span></div><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>
<br></blockquote></div><br></div>