[Haskell-cafe] ANNOUNCE: Megaparsec – an improved and actively maintained fork of Parsec

Carter Schonwald carter.schonwald at gmail.com
Wed Sep 30 19:32:26 UTC 2015

Agreed. Great work, and if we can find a path to this being a foundation
for or inspiring parsec 4.0, that would probably be a net win for everyone.

On Wednesday, September 30, 2015, Nicola Gigante <nicola.gigante at gmail.com>

> > Il giorno 29/set/2015, alle ore 21:46, Andrey Chudnov <
> achudnov at gmail.com <javascript:;>> ha scritto:
> >
> > (Artyom, I hope you can forward the following to the original author
> and, ideally, have them subscribe to the mailing list)
> >
> > As a heavy user of parsec, I have to say this is simply awesome. I've
> read through the announcement and the changelog, and I have to say the
> changes seem to be spot on and scratch so many old itches I have personally
> struggled with when using parsec. I'm at the point where I am seriously
> considering porting all my code to megaparsec; however, lack of
> compatibility with GHC <7.10 is a bit of a deal-breaker at this point.
> >
> > I'd like to discuss the decision to fork parsec. Now, I'm not judging:
> as long as the license permits it, whether to fork or not is really up to
> the forker.
> >
> > However, it seems the author of megaparsec would like it to become the
> new standard parsing library (see "How you can help"). I'd like that too.
> However, I don't think that forking is the best way to achieve that. Of the
> two reasons that were given here, the first (stagnant development and
> maintenance) is a good reason to become either a co-maintainer, or a new
> maintainer. There seems to be a pretty smooth process for that now, and it
> doesn't raise any eyebrows when someone requests to be the new maintainer
> having good reasons for it (like willingness to contribute time and effort
> to the package).
> >
> > The second reason is backwards compatibility. It's true the changes
> might break some code, but that's why we have major versions. And the
> overall architecture and interface is still in line with parsec. So, to me
> it makes perfect sense to call megaparsec a parsec- and get some
> continuity from the older library. That way megaparsec becomes the default
> just by inheritance.
> >
> > So, if the author of megaparsec is open to becoming a maintainer of
> parsec, I'm sure the Hackage Trustees would be willing to help. If not, I'm
> personally willing to champion that.
> >
> > /Andrey
> >
> +1
> Megaparsec seems awesome to me, especially the monad transformers issue
> is exactly what I missed in using Parsec.
> As someone that often teaches a bit of haskell, I would also like it to
> become
> "Parsec 4.0” if that’s possible. That would save a lot of boilerplate in
> docs and
> tutorials about why I’m talking about megaparsec while it seems the most
> used
> library is parsec and explain the reasons of the fork etc.. every time.
> To megaparsec’s author: great work!
> Bye,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150930/6e4ea760/attachment.html>

More information about the Haskell-Cafe mailing list