Haskell Platform decision: time to bless parsec 3?

[Christian Maeder]

Am 12.11.2010 01:32, schrieb Derek Elkins:
> I would say Parsec 3 is not less up to standard than Parsec 2.

I think, the question should be. Should we bless a (yet missing) Parsec3
library (without compatibility layer) in addition to the current parsec
2 library?

> The performance is comparable to Parsec 2, and there are still some
> things that can be done, as were mentioned in this thread alone.  If
> nothing else, the main example for Parsec 3 being slow, was rerun with
> Parsec 3.1 and was comparable to Parsec 2.
> 
> As far as correctness, the bug reports I've received have mostly been
> relatively minor and usually have applied to Parsec 2 as well.
> However, a good unit/regression test suite is definitely something
> that Parsec (any version) could use.  There is, of course, no shortage
> of systems tests of Parsec that would be quite conspicuous if they
> failed.  I have not gotten a single report along the lines of "I've
> upgraded to Parsec 3 and now my parser doesn't work."

the compatibility is fine, but mixing both interfaces (Text.Parsec.* and
Text.ParserCombinators.Parsec.*) should not be encouraged (and if I
don't mix I do not need a compatibility layer).

> Parsec 2 has no documentation at all.  The Parsec letter is for Parsec
> 1, but is still quite relevant to all versions of Parsec.  The Haddock
> documentation was added in Parsec 3.  Suffice it to say, Parsec 3 is
> far better than Parsec 2 in this regard.  The new features of Parsec
> have (non-trivial) Haddock documentation, but a documented,
> significant example using the new features would be a good addition.

the new parsec2 package seems to have the documentation taken from parsec 3.

> As far as Don's concerns with regard to stability: As suggested above,
> most of the emails I've received have been minor bugs that are often
> in Parsec 2 as well, or feature requests, and there haven't been that
> many of either.  I have no big changes in mind.  The next big change I
> forsee is dropping the compatibility layer at some point.  Other than

How should we drop the compatibility layer once it is part of the HP
without breaking much code? (Omit the compatibility layer in the first
place and ask my initial question!)

> that, I can see the Stream class changing significantly, but I believe
> that can be done in a way that is mostly transparent to users.  That
> is just speculation at this point.
> 
> While I agree that currently the monad transformer aspect of Parsec 3

I wonder if Parsec3 is well designed wrt user state, since a user state
could be part of the underlying monad. (Could/Would the user state be
dropped if compatibility to parsec 2 would be no issue?)

> is not a common requirement, the ability to parse ByteStrings and
> other types (like Text) is certainly something that would be
> beneficial to many.  Parsec 3 runs Parsec 2 code virtually unchanged.

Still, I had a hard time to change my Parsec 2 code to use Bytestrings
instead of Strings via Parsec 3.

> The only particularly good argument I've seen against having Parsec 3
> (v. Parsec 2) in the Platform is the extensions issue.

Unfortunately, most parsers use extensions (even
Text.ParserCombinators.ReadP), which makes it difficult for other
haskell compilers to profit from the haskell code base.

In fact, I wished that the parsec2 modules requiring extensions would be
in an extra package. But it seems to be difficult to avoid extensions
(as also Parsimony shows) just to support more general streams.

> I'm less involved in the Haskell community than I was years ago and I
> expect that trend to continue a little bit more, and lately I haven't
> been the best maintainer.  I wouldn't want the me right now to be the
> maintainer for a package in the Haskell Platform, so I've asked
> Antoine Latter to take up maintainership of Parsec 3 and he has
> agreed.  He's certainly familiar with the code and has been involved
> in Parsec 3 almost from the beginning.  I don't see any trouble during
> or after the transition.  I'll push a minor version upgrade with some
> pending patches, and then after that it will be Antoine's show.  He
> also doesn't have any big changes planned.

I'm strongly against putting parsec 3 as is into the HP.
Creating it as new major of parsec caused enough trouble, moving it into
the HP is no good remedy (in my eyes).

Christian