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. <br><br>On Wednesday, September 30, 2015, Nicola Gigante <<a href="mailto:nicola.gigante@gmail.com">nicola.gigante@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Il giorno 29/set/2015, alle ore 21:46, Andrey Chudnov <<a href="javascript:;" onclick="_e(event, 'cvml', 'achudnov@gmail.com')">achudnov@gmail.com</a>> ha scritto:<br>
><br>
> (Artyom, I hope you can forward the following to the original author and, ideally, have them subscribe to the mailing list)<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> 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-4.0.0.0 and get some continuity from the older library. That way megaparsec becomes the default just by inheritance.<br>
><br>
> 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.<br>
><br>
> /Andrey<br>
><br>
<br>
+1<br>
<br>
Megaparsec seems awesome to me, especially the monad transformers issue<br>
is exactly what I missed in using Parsec.<br>
<br>
As someone that often teaches a bit of haskell, I would also like it to become<br>
"Parsec 4.0” if that’s possible. That would save a lot of boilerplate in docs and<br>
tutorials about why I’m talking about megaparsec while it seems the most used<br>
library is parsec and explain the reasons of the fork etc.. every time.<br>
<br>
To megaparsec’s author: great work!<br>
<br>
<br>
Bye,<br>
Nicola<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Haskell-Cafe@haskell.org')">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote>