On Fri, Dec 7, 2012 at 9:24 AM, Mark Lentczner
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