Re: Haskell Platform decision: time to bless parsec 3?

Hello, For some alternative design choices you might also be interested in Parsimony (http://hackage.haskell.org/package/parsimony). It is similar to a trimmed-down Parsec 2, but it supports token streams other then lists (e.g., it can parse directly from byte-strings). Parsers supports user state but, unlike Parsec, they have only a single type parameter, which looks much nicer. The basic idea is simple: instead of parameterizing on the type of tokens (like Parsec), Parsimony parameterizes on the type of token streams instead. The type of tokens are computed from the type of token streams (details are in Parsimony.Stream). Because parsers already pass around the token stream as a piece of state, it is easy to add user state by just defining a new type of token stream which has the user state as an extra component (for details see Parsimony.UserState). Hope that this helps, -Iavor On Sat, Nov 6, 2010 at 3:11 PM, Antoine Latter wrote:

On Sat, Nov 6, 2010 at 5: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.

I'm not really for this but not strongly against. The only concrete argument I have is that then the end-user would have to think about the correct way to layer to monads so that the state backtracks at the same time as the parser.

There also might be performance implications for those wishing to use the state (but I'm guessing that it would get better for those not using it, which is likely the common case).

...

* 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.

I doubt there is a good reason.

...

* 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.

Assuming we move the Parsec 'many' implementation into the Alternative class definition, this should have no/little impact on performance for all the combinators mentioned by Stephen. Maybe they could be specialized to internal Parsec structures in the future, but at the moment they really aren't.

My previous Parsec benchmarks have been somewhat ad-hoc, so I would like a better benchmark suite before doing this.

...

Groetjes,

Martijn.

On 11/6/10 16:18, Don Stewart wrote:

...

I propose we agree to remove this ad hoc rule, and thus the HP will ship with parsec 3.

Does anyone have concerns with this?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries