
On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic
On 2 August 2010 16:24, Jean-Philippe Bernardy
wrote: Can you explain why you could not use the parsec name, with revision number (say) 2.2?
This would help improve hackage/cabal/... versioning mechanism.
I think the idea is to give it more prominence: if you go to http://hackage.haskell.org/package/parsec, the version that hits you immediately is 3.1.0; it isn't as immediately obvious that there is a new parsec-2.x version out.
Also, quite a few folks like to map a package on Hackage to a package in a distribution. If there is a legitimate need for the 2.x series to be maintained, this could get it into various distributions.
That said, if parsec2 is only a bug-fix branch of parsec-2.x, is there any particular reason work couldn't be done to improve the performance of parsec-3 when using the compatibility layer (and even improving the performance of parsec-3 overall) rather than a specific branch/fork?
The release of parsec-3.1 dramatically improved the performance of parsec3 to roughly parsec-2.1 levels. So I don't know of any downside to switching over to the compatibility layer other the fact that it's a much newer code-base, and that it's a much further departure
Unless the API changes from either parsec-2.x or the compatibility modules in parsec-3, I'm not sure how much use this would be; as it stands, in Gentoo we already tweak a lot of package cabal files to remove the upper bounds on parsec some of them impose, and we're likely to do the same to make packages that use parsec2 just use "normal" parsec instead.
I don't have a huge problem with that - if there is anything wrong with parsec3 or it's compatibility layer I'm as likely as anyone else to submit a patch to fix it. There seemed to be a demand for te older branch to resume maintenance, and I'm more than happy to keep it building and roll releases. Antoine
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com