Haskell Platform decision: time to bless parsec 3?

[Sterling Clover]

On Nov 6, 2010, at 12:24 PM, Martijn van Steenbergen wrote:

> I would like to see some changes before it becomes a blessed package. I'd love to hear your thoughts on the following ideas:
> 
> * Get rid of the user state type parameter u. If you want state, set m = StateT s.
> * Text.Parsec.Prim currently exports its own version of <|> specialized to the ParsecT type constructor. Is there a good reason for this? It clashes when I also import Control.Applicative in my own modules.
> * Most of the combinators in Text.Parsec.Combinator have types specialized to ParsecT (with a Stream class constraint as consequence) while they could be defined in terms of Applicative only. I think these should be rewritten in terms of Applicative (or Monad if absolutely necessary) whenever possible.

These are useful suggestions for Parsec. But the proposal is not to add Parsec to the platform, but just to upgrade to v. 3. The concerns apply equally well to v. 2, which is already in the platform. I'm all for upgrading to Parsec 3, which is more general and reportedly has comparable performance now, and pursuing further work on Parsec through working with the Parsec maintainer (i.e. outside of the libraries process.)

Cheers,
Sterl.