Haskell Platform decision: time to bless parsec 3?

[Antoine Latter]

On Sat, Nov 6, 2010 at 5:24 PM, Martijn van Steenbergen
<martijn at van.steenbergen.nl> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>