Parsec branch (was Re: Bug in Parsec.Token)

Antoine Latter aslatter at
Wed Jun 9 23:41:30 EDT 2010

On Sat, Apr 3, 2010 at 6:21 AM, wren ng thornton
<wren at> wrote:
> I'd argue that it's acceptable, at least under this plan:
> * fork parsec-2.1 as parsec2-2.1
> * continue to develop parsec2-* (as desired)
> * deprecate parsec<3 with message to switch to parsec2-*
> * continue parsec>=3 as parsec-*
> The harm is minimal because:
> (a) anyone who is too lazy to upgrade their .cabal can still use parsec-2.1
> until it bitrots
> (b) anyone who is too lazy to upgrade their code to parsec>=3 can just
> update their .cabal to use parsec2-* if they want to avoid bitrot
> (c) anyone using parsec>=3 won't notice a thing.

I really like this plan, so I've finally gotten something done in this

I pulled parsec- off of hackage and stuffed it into a fresh
darcs repo, and I've made two branches off of it:

This is a new package that I am willing to maintain. I expect to be
limiting my actions to maintaing compatibility with as many GHC
releases as practical, and I will accept patches needed to get working
on other implementations. Fixes such as Greg's above are also
appropriate when kept in sync with main-line.

I propose to upload this to hackage as parsec- It is identical
in all respects to, except each module is marked as
deprecated, producing the following warning:

    Warning: In the use of type constructor or class `LanguageDef'
             (imported from Text.ParserCombinators.Parsec.Token):
             Deprecated: "Please use the parsec2 package or upgrade to
a higher version of parsec"

Any comments on either of these two branches? Is parsec2 the right
name for the branch package? Does anyone want to see anything
different in the package description text?

Is the next step getting parsec2 into the Platform, and updating
inter-platform deps?

Take care,

More information about the Libraries mailing list