On Tue, Jul 15, 2014 at 12:25 PM, Matthias Kilian
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