[Haskell-cafe] Re: [Haskell] ANNOUNCE: parsec2 - a fork or parsec
dagit at codersbase.com
Mon Aug 2 13:25:13 EDT 2010
On Mon, Aug 2, 2010 at 4:32 AM, Antoine Latter <aslatter at gmail.com> wrote:
> On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
> > On 2 August 2010 16:24, Jean-Philippe Bernardy <bernardy at chalmers.se>
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe