[Haskell-cafe] Re: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

[Jason Dagit]

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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100802/d45d220c/attachment.html