On Fri, Dec 7, 2012 at 9:24 AM, Mark Lentczner wrote:

In my Haskell Implementors 2012 talk Haskell Platform: Field Report and Future Goals, I called for an expansion of the content of the platform to bring it up to par with what other programming language platforms provide.

Please see my blog post today: http://mtnviewmark.wordpress.com/2012/12/06/growing/)

Where I outline what is missing, and call for a ramp up in our efforts to grow the platform.

I agree with Thomas's call for using Vincent's crypto packages. I also think blaze-html is the best option for HTML generation. Let me bring up one other package: yaml (written by me). I think it's a pretty good fit for the standard YAML packaging library, since it simply reuses the existing infrastructure from the aeson package (i.e. the ToJSON and FromJSON typeclasses, and the Value datatype). But I'm actually a bit concerned about proposing it, based on some history. There was a major improvement put forward in version 0.11.2 of the text package, which meant that compile times were drastically reduced due to a better set of rewrite rules for pack. This affected a number of my packages directly, particularly persistent, which had a large number of compile-time Text values for representing table and column names. Moving from text 0.11.1 to 0.11.2 meant in some cases that programs transformed from uncompilable to compilable. In other cases, it was the difference between 10 minute compiles and 10 second compiles. I thought the natural response to this would be to put a lower bound on text. After all, following the PVP, there should be no problem with updating a minor version number. However, when I did so, many users of the Haskell Platform were no longer able to compile due to conflicting dependencies. The result: I had to put in some dirty conditional compilation tricks in persistent to avoid inlining `pack` when using older versions of text. Now this problem may be completely resolved in newer versions of cabal-install, but I think having a large number of packages in the global package database pegged at specific versions is a very strong recipe for reintroducing version hell. Coming back to yaml: it depends on conduit. Suppose after the HP is released, I release a new version of conduit. And suppose some other package (say, xml-conduit) depends on this newer version. What happens when the user tries to install a package that depends on the newer xml-conduit and yaml at the same time? Ideally I'd want them to get yaml recompiled against a newer version of conduit, but conflicting user and global databases can be a very sore point. I'm all in favor of increasing the scope of the HP, but having a lot of version numbers set in stone could be problematic. Perhaps a solution would be to have the HP packages go into the user package database instead of the global database, I'm really not sure. Michael

* Mark Lentczner [2012-12-06 23:24:41-0800]

In my Haskell Implementors 2012 talk Haskell Platform: Field Report and Future Goals, I called for an expansion of the content of the platform to bring it up to par with what other programming language platforms provide.

Please see my blog post today: http://mtnviewmark.wordpress.com/2012/12/06/growing/)

Where I outline what is missing, and call for a ramp up in our efforts to grow the platform.

Couple of thoughts: 1. file utils I would suggest filemanip [1]. It has good coverage and sane API. Last time I looked, there were no good alternatives to it on hackage. [1]: http://hackage.haskell.org/package/filemanip 2. test framework I have mixed feelings here. On the one hand, it would be good to have one in the platform. On the other hand, we're seeing some competition in this area (the main competitors being test-framework, HTF and hspec), and including one of them into the platform would give it advantage on the market and might discourage development of its alternatives. Roman

On Thu, Dec 06, 2012 at 11:24:41PM -0800, Mark Lentczner wrote:

In my Haskell Implementors 2012 talk Haskell Platform: Field Report and Future Goals, I called for an expansion of the content of the platform to bring it up to par with what other programming language platforms provide.

Please see my blog post today: http://mtnviewmark.wordpress.com/2012/12/06/growing/)

Where I outline what is missing, and call for a ramp up in our efforts to grow the platform.

Hi Mark, I agree in general with the goals of growing the haskell platform; I more than once expressed the same interests. However I really don't see how it can happens at the moment. The bar is too high in general. While i can understand the reason (and agree) for most of the requirements on the list of acceptance, in general this is working against the platform. I would prefer the platform to offer many more good packages that maybe doesn't meet all the high quality requirements, but provide a necessary feature for users, and see them improve over time through the platform. At the moment, I think we expect perfect packages that will enter a freezing state after being accepted. In my mind, having multiple levels of platform could be a good idea. the current platform would be platform-base, and you could have something like platform-unstable, platform-experimental, that would mark the intent of being in the platform: - users can start rely on the package with the clear expectation of change in next versions. - users/devs can proactively improve packages that are missing stuff I think there's clearly a middle ground between the graveyard-like property of the platform and pure cabal/hackage usage. I believe this is being worked on, from the other end with Michael's stackage, but more effort to meet in the middle would be a good idea. -- Vincent