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. Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this:
· There are some people working on GHC itself. That is already a big job. Just getting GHC ready to release is hard. Hence the desire that Herbert mentions to strip it down as much as possible. · But a release of GHC is not adequate. No one except power users should install a GHC release. It should be a secret among the cognoscenti that a GHC release has happened. · The first sensible unit of installation (at least for a non-power user) is the Haskell Platform. It includes the tools you need (Happy, Alex, Cabal) as well as a small but useful collection of libraries. That’s why GHC’s download page explicitly says “Stop! Shouldn’t you be installing the Haskell Platform instead?”. · HP releases should therefore, in contrast to GHC releases, be widely publicised. · Moreover, a HP release should very closely follow a GHC release (though the former could occur more often), to reduce the chance that a naïve user bypasses the HP and gets GHC alone. That is what Mark is rightly working on at this very moment for GHC 7.10. We probably should work harder to reduce the lag. In this sense, the plan was always that “the GHC and the Platform release are one and the same”. I think of the HP release as the “real GHC release”. It’s just that, as an implementation mechanism, the GHC team push out the bare GHC bits, so that the HP team have something firm to chew on. So that was the plan. I still think it’s a good plan. But it clearly is not working well, and I’m hazy about why. Possible reasons: · Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn’t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. · Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. So here are the questions in my mind: · Is the original plan still good? · Is it possible to make the HP so that installing it does not get in the way of power users? So that installing it is, at worst, a waste of disk space? Personally I like the plan because it’s simple; because it usefully empowers, and splits responsibility between, two different groups (GHC and HP); and because it makes life easy for our users. Simon From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2015 06:22 To: Gershom B Cc: Manuel M T Chakravarty; haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Tue, Mar 24, 2015 at 10:09 PM, Gershom B <gersh...@gmail.com<mailto:gersh...@gmail.com>> wrote: 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. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all 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. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: The problem is how GHC is released: 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. This is an insufficient set of things for most users. 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. 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!) 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. 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. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
