<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 10:09 PM, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task.</blockquote></div><br>Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet <i>all</i> users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. </div><div class="gmail_extra"><br></div><div class="gmail_extra">I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>The problem is how GHC is released:</b> It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. <i>This is an insufficient set of things for most users.</i></div><div class="gmail_extra"><br></div><div class="gmail_extra">At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Mark</div><div class="gmail_extra"><br></div><div class="gmail_extra">(*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type. </div><div class="gmail_extra"><br></div></div>