On Mon, Aug 2, 2010 at 4:32 AM, Antoine Latter <aslatter@gmail.com> wrote:
On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic
> On 2 August 2010 16:24, Jean-Philippe Bernardy <bernardy@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