Haskell Platform decision: time to bless parsec 3?

[Derek Elkins]

> On 6 November 2010 15:18, Don Stewart <dons at galois.com> wrote:
> > Hey all,
> >
> > This is a loose end in the package policy situation: when the HP has a
> > major upgrade, the policy is to do all major upgrades for any packages
> > contained in the HP, as long as they don't add new dependencies.
> >
> > One exception to this rule has been parsec, where parsec 2 was
> > considered "blessed" on an ad hoc basis.
> >
> > 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?
>
> Yes. I think that if a package has a significant discontinuity then it
> has to be reconsidered at least to some degree.
>
> In the case of parsec 2 and 3, initially parsec 3 was an experimental
> new version, by different authors. It was not initially clear if it
> would be an obvious replacement, if it was functionally correct and if
> the performance or documentation was up to scratch compared to version
> 2.
>
> Personally I would be satisfied if the current maintainer(s) would
> state that they believe the current parsec 3 release is up to standard
> and that they believe it should become the new version in the
> platform.
>
> Duncan

I would say Parsec 3 is not less up to standard than Parsec 2.

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

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.

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
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
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.
The only particularly good argument I've seen against having Parsec 3
(v. Parsec 2) in the Platform is the extensions issue.

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.