On Mon, Aug 2, 2010 at 4:32 AM, Antoine Latter <aslat...@gmail.com> wrote:
> 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 > Is parsec-3.1 using the compatibility layer roughly the same speed as parsec-2.1, or is parsec-3.1 using the native parec3 api almost as fast as 2.1? I haven't been following along, but are the comparative benchmarks published anywhere? Thanks, Jason
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe