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. 
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform

Reply via email to