Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1
On 2 August 2010 16:24, Jean-Philippe Bernardy berna...@chalmers.se 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. 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? 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. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1
On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 2 August 2010 16:24, Jean-Philippe Bernardy berna...@chalmers.se 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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1
On Mon, Aug 2, 2010 at 6:32 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: 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 How about I finish my sentences. My second downside was that parsec-3 is a much further departure from Haskell2010 than parsec-2. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
