Hi, Simon Hengel wrote:
Where would something like the HP actually make sense?
In my experience, the Haskell Platform makes it significantly easier to use Haskell on Windows. On Windows and/or for the typical Haskellers on Windows, it is hard to build a package that depends on external C libraries or uses a configure script, however trivial. This is because on Windows, there is no way to manage installed C libraries without understanding C development. But most Windows users are not C programmers, and some Windows Haskellers even learn Haskell as their first programming language. In extreme cases, ghc and cabal are the first command-line tool they learn. So on Windows, before the Haskell Platform was introduced, `cabal install some-random-package` usually failed for some dependency that required a C library. With the Haskell Platform, `cabal install some-random-package` usually works. I guess there are two effects: 1. The Haskell platform seems to bundle some packages that require external C libraries or configure scripts. The network package comes to mind. 2. The existence of the Haskell platform encourages non-Windows developers to avoid dependencies that are not in the Haskell platform. Because of effect 1, this translates to non-Windows developers avoiding dependencies that are hard to install on Windows. So from the perspective of using Haskell on Windows, the Haskell Platform is very successful, and installing it is good advice. If anything, it should be bigger, not smaller. And it should focus on libraries with external dependencies. So could we make a Haskell-on-Windows-Platform and drop the Haskell Platform for the other platforms? This would give Haskellers on Windows the first effect, but it would disable the second effect. I'm not sure how much the first effect is worth without the second. Why should we care about Haskellers on Windows? I think there are some important classes of new Haskellers that are on Windows, at least initially, and if we want to convert them to long-time Haskellers, we need to support them in their context. For example, here are three reasons to start your Haskell experience on Windows: 1. You might be a student at a university where the lab computers run Windows. A minimal installation without excellent support for libraries would be fine for following a lecture on Haskell, but you will not take Haskell serious if it doesn't give you easy access to libraries. In fact, installing Haskell libraries can be very easy, but only if you get the external dependency issue out of the way. 2. You might be a not-yet-programmer who wants to use a embedded DSL for your domain, and you're on Windows "by default" or because of the tradition in your field. We like to claim that Haskell is good for embedded DSLs, so we should support this usage scenario. 3. You might be a not-yet-programmer who wants to use an external DSL for your domain, and you're on Windows as above, and you want to become a power-user of the DSL. So maybe you start reporting bugs and are asked to `cabal install` the development version to check fixes. Or maybe you want to copy-and-adapt a little Haskell program that uses a library interface to the DSL for scripting purposes. We see both of this happening for pandoc, for example. Also, Haskell is a high-level language, and it would be somewhat silly if Haskell programs would not be easily portable due to low-level issues. Tillmann