Status of Haskell Platform 2014.2.0.0

[Mark Lentczner]

On Tue, Jul 15, 2014 at 12:25 PM, Matthias Kilian <kili at outback.escape.de>
wrote:

> Apart from this, i guess future versions of attoparsec (and other
> libraries included in the HP) will probably depend on more libraries
> not yet in the HP. So what's the correct way to deal with this?
>
> - Use newer versions for libraries like attoparsec and add additional
>   libraries they depend on?
>
> - Or reduce the number of libraries included in the HP?


This a fundamental tension with having a set of packages like the platform:
The point of a library being in the platform is that it forms part of the
stable base for all other development work. But then a library in it has
become a stable base.

If stable library pulls in a new dependency on a library that isn't
stable... then the depending library is no longer stable. [Stable here
refers to API and expectation stability... not code quality.] Libraries in
the platform should, ideally, be very conservative with adding new
dependencies.

In the past, we have set the bar that a package will not move forward in
version in the platform if it requires a dependency that is not in the
platform. If we relax this, you can see where it leads: A is admitted into
the platform. Later it depends on B, not in the platform... so we bundle B
into the platform as well (as A needs it). Now, people start to come to
expect that B is "there"... and depend on it... but it hasn't ever signed
up to the stability commitment, and so if it changes radically... the
platform, as practically seen by users is no longer stable.

We are a very fast moving bunch here in the Haskell world. In part because
both our language and ecosystem of tools have enabled us to build on their
safety. For example: In it's short 9 month life (introduced in Oct 2013),
scientific has had 7 major API revisions in 16 releases. That is pretty
unprecedented for packages that make up other stable library sets other
ecosystems.

It would be hard to include a package with that much API motion in a set of
stable packages whose API you could code against... and expect it to be
relatively unchanged in a year. Imagine if Data.Map's API changed that
often.... I certainly don't want to have to constantly fiddle with my
project over a year to keep it working with Data.Map. And even if I update
my platform once every six months (I know... I know... but *most *years...)
then it is *still* wasted time if I need to fiddle with my project to be
sure it still works with Data.Map.  Of course, Data.Map is stable... and
this doesn't happen.

We should have this discussion again after the release. We should
re-evaluate what we expect from the libraries that are in the platform, and
we should set more clear stability metrics. Looking forward to lively
discussions on this over beer in Gothenburg!

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140715/860579c0/attachment-0001.html>