Haskell Platform decision: time to bless parsec 3?

[Iavor Diatchki]

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 <aslatter at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>