<div dir="ltr"><div>I strongly believe we need the HP to be able to compete with Python etc with "batteries included". Having a set of blessed packages with stable APIs makes development easier, so the HP is a very important part of the Haskell eco system IMHO.<br>
<br></div><div>Having graphics packages in the platform does make it a bit wierd to install on servers which are typically not equipped with OpenGL etc.<br></div><div><div><br>Johan<br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-04-16 4:28 GMT+02:00 Simon Hengel <span dir="ltr"><<a href="mailto:sol@typeful.net" target="_blank">sol@typeful.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">> >and I have a somewhat cunning plan along these lines (related to some<br>
> >other ghc-pkg/cabal improvement work) which might make that rather<br>
> >easier<br>
> ><br>
> >what I want is for ghc itself to come with multiple profiles, with one<br>
> >being the minimum (base + rts + deps), and that could be used as a basis<br>
> >for new envs<br>
><br>
> With such a feature, it sounds like we can get the best of both worlds:<br>
> * a feature-rich Haskell Platform to support beginners<br>
> * minimal sandboxes for advanced users<br>
<br>
</div>The issue with such integrated approaches that affect the whole<br>
toolchain (ghc, cabal, etc.) is that this can seriously harm innovation,<br>
at least if the net result is that it gets harder and harder to write<br>
alternative package managers, etc.<br>
<br>
TL;DR: If anything, we should make things *less integrated* (read more<br>
open and hackable).<br>
<br>
Let me try to make my point by looking at Haddock.  Let's assume you are<br>
not happy with the current state of Haskell documentation tools.  In<br>
such a situation it can makes perfect sense to give it a fresh start.<br>
But Haddock is so integrated with GHC, Hackage, Cabal,...  that this is<br>
very hard to do.  You can write an alternate documentation tool, but it<br>
may be hard for potential uses to experiment with it.  Currently I think<br>
the only feasible way to get your changes in or experiment with new<br>
ideas is through the current maintainer, and if the current maintainer<br>
thinks your approach is a bad idea or just does not like you or does not<br>
have the time to look at your code you may be in a situation where it's<br>
hard to improve things.  There is a lack of competition and I think it<br>
is not something absurd to assume that this lack of competition results<br>
in a lack of innovation.<br>
<div class=""><br>
> >Where would something like the HP actually make sense?  For stuff that<br>
> >has external dependencies that are not easily  installable with<br>
> >cabal-install (like curses bindings, SSL support, etc.).  We have none<br>
> >of this in the HP.  So I think currently we just have additional costs,<br>
> >but no benefits (+ we harm innovation by arbitrarily "endorsing" random<br>
> >packages).<br>
><br>
> I understand this point of view, but allow me to offer an opposing one.<br>
> By putting packages with external dependencies into Haskell Platform, we<br>
> often increase the dependencies of Haskell Platform itself.  For example,<br>
> Haskell Platform currently includes Graphics packages; installing Haskell<br>
> Platform on a server entails installing a number of OpenGL libraries that<br>
> are never used.<br>
<br>
</div>My point here was that (from my perspective) the cost/benefit ratio of<br>
bundling packages that are easily installable with cabal-install is<br>
negative.<br>
<br>
Cheers,<br>
Simon<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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></div>