Growing Haskell Platform

[Michael Snoyman]

On Fri, Dec 7, 2012 at 9:24 AM, Mark Lentczner <mark.lentczner at gmail.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121207/107030c9/attachment-0001.htm>