ANNOUNCE: parsec2 - a fork or parsec circa 2.1 - Haskell-Cafe

ANNOUNCE: parsec2 - a fork or parsec circa 2.1

Antoine Latter

1 Aug 2010 1 Aug '10

10:27 p.m.

Hello, I would like to announce the parsec2 package, which is a maintained fork of the parsec library as of version 2.1.0.1. This project is for folks who would like to use the simpler interface and fewer extensions relative to parsec-3.0+, but don't want to rely on an old version of a package on hackage. Parsec is designed from scratch as an industrial-strength parser library. It is simple, safe, well documented (on the package homepage), has extensive libraries and good error messages, and is also fast. Changes relative to parsec-2.1.0.1: * Added haddocks done for parsec-3 * in Parsec.Token, sort names after accounting for case sensitivity, not before from: Greg Fitzgerald When I say that I'm maintaining the parsec2 package, that means I am accepting bugfix patches and doing work to ensure that the package builds on the current version of GHC. Patches are welcome to support building on any other Haskell implementations. Any inovations in the field of parser combinators will be happening in other venues. Documentation patches are also welcome. I'm not quite sure what to do about the fact that both parsec2 and mainline parsec provide modules of the same name. If there's motion towards using the parsec2 package, we might be able to deprecate and then retire the compatibility layer provided by parsec-3.*. Links: On Hackage: http://hackage.haskell.org/package/parsec2-1.0.0 Source repository: darcs get http://code.haskell.org/parsec2/parsec2 Report a bug: http://trac.haskell.org/parsec2/newticket Antoine

Show replies by date

Jean-Philippe Bernardy

2 Aug 2 Aug

2:24 a.m.

New subject: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

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. Thanks, JP. On Mon, Aug 2, 2010 at 4:27 AM, Antoine Latter wrote:

...

Hello,

I would like to announce the parsec2 package, which is a maintained fork of the parsec library as of version 2.1.0.1.

This project is for folks who would like to use the simpler interface and fewer extensions relative to parsec-3.0+, but don't want to rely on an old version of a package on hackage.

Parsec is designed from scratch as an industrial-strength parser library. It is simple, safe, well documented (on the package homepage), has extensive libraries and good error messages, and is also fast.

Changes relative to parsec-2.1.0.1:

* Added haddocks done for parsec-3

* in Parsec.Token, sort names after accounting for case sensitivity, not before from: Greg Fitzgerald

When I say that I'm maintaining the parsec2 package, that means I am accepting bugfix patches and doing work to ensure that the package builds on the current version of GHC. Patches are welcome to support building on any other Haskell implementations. Any inovations in the field of parser combinators will be happening in other venues. Documentation patches are also welcome.

I'm not quite sure what to do about the fact that both parsec2 and mainline parsec provide modules of the same name. If there's motion towards using the parsec2 package, we might be able to deprecate and then retire the compatibility layer provided by parsec-3.*.

Links:

On Hackage: http://hackage.haskell.org/package/parsec2-1.0.0 Source repository: darcs get http://code.haskell.org/parsec2/parsec2 Report a bug: http://trac.haskell.org/parsec2/newticket

Antoine _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Ivan Miljenovic

2:55 a.m.

New subject: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

On 2 August 2010 16:24, Jean-Philippe Bernardy 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.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Antoine Latter

7:32 a.m.

New subject: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic wrote:

...

On 2 August 2010 16:24, Jean-Philippe Bernardy 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.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Antoine Latter

7:34 a.m.

New subject: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

On Mon, Aug 2, 2010 at 6:32 AM, Antoine Latter wrote:

...

On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic 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.

Joachim Breitner

10:36 a.m.

New subject: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

Hi, Am Montag, den 02.08.2010, 06:34 -0500 schrieb Antoine Latter:

...

On Mon, Aug 2, 2010 at 6:32 AM, Antoine Latter wrote:

...
On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic 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.

with my Debian Haskell Group hat on, I would very much welcome a convergence on _one_ parsec package, so that we don’t have to package two. I’m happy with patching existing packages to use a parsec3 compatibility layer as long as the required changes are of the trivial, type-checked kind or only affect the .cabal file :-). But I do need some assurance that parsec3 is ready to replace parsec2, both performance and reliability-wise. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

Jason Dagit

1:25 p.m.

New subject: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1

On Mon, Aug 2, 2010 at 4:32 AM, Antoine Latter wrote:

...

On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic wrote:

...
On 2 August 2010 16:24, Jean-Philippe Bernardy 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

5405

Age (days ago)

5405

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Antoine Latter
Ivan Miljenovic
Jason Dagit
Jean-Philippe Bernardy
Joachim Breitner