Become parsec-4.0.0.0 about megaparsec

[abooij]

I'd like to add that while there is no need to worry about backwards compatibility, it would be worth emphasizing that this is a very major release point, and code that used to work with Parsec < 4 will most likely not work correctly anymore with what would become parsec 4, even if it compiles. This is also in the spirit of burning (broken) bridges that Mark likes to have for now.

But obviously this is all up to Mark.

[mrkkrp]

I don't know what to say, I've not decided yet. On one hand, using of name Parsec will almost certainly make this library widely used in future.

On the other hand there are reasons to stay with Megaparsec:

1. If current maintenance of Parsec continues the same way for long enough period of time, Megaparsec will become quite popular anyway. Or another library will replace Parsec, as long as it's a good library, there is nothing wrong with that.
2. There are other distribution methods apart from Hackage. Stackage for example. Should I go there and tell them to build Parsec from my repo from now on because my library is self-proclaimed Parsec? I don't feel entirely comfortable with this business.
3. If we decide to rename it, it can lead to whole lot of confusion. We will need to rename everything including repo and re-announce it. Right now Parsec is very popular and there are a lot of materials that explain how to use it. If we instantly replace it with something very different, people will be getting unexpected problems. Of course they can specify version of Parsec to use, but this way they lock themselves into using software that will be never updated.
4. Finally, Megaparsec is quite different from Parsec. It follows different naming conventions — that's not something libraries change even between major versions. There are other changes and they are not entirely cosmetic. A lot of projects depend on Parsec “as is”, some of them will be locked into depending on Parsec 3 or will have to try to avoid depending on Parsec…
5. Right now when people ask that Megaparsec should be like Parsec I can tell them that this is a different library. It will be more difficult to explain why new Parsec is so different when it certainly could be more compatible. It seems like compatibility is valued by original Parsec, it still has a lot of modules that just re-export stuff.

After all, who says that original Parsec won't get new commits? I think that project is not dead yet. Its current maintainer may have reason why he cannot actively support it right now. Who knows what happened to him, I've seen commit log and he was active enough in the past, so I don't think he just ignores people on purpose or forgot about the project. There should be a reason for this inactivity. What if he chooses different path to follow when he's back?

[abooij]

@mrkkrp, I think your overarching concern is the following: would people appreciate it if parsec 4 would take the direction you are taking? Would people mind if parsec 4 would be much different from parsec <4, with many renames and changes in semantics? And would people mind if that trend continued for a while, while you're trying to improve the state of parser combinators?

If you want to know, you (or someone else) should send out an email to the haskell-cafe mailing list and ask exactly that. The responses will be most interesting either way.

[mrkkrp]

@achudnov, I've decided against becoming Parsec 4. I think if people find this library good, they will use it anyway. It doesn't feel like Megaparsec needs more famous name to be adopted by the community (although I agree that this library as Parsec 4 would gain popularity faster). Becoming Parsec would also increase amount of work I need to do even if it's just taking over Parsec on Hackage and elsewhere and renaming of everything in the repo — that's just not what I'm interested in.

Things I want to do right now include:

• releasing of Megaparsec 4.1.0 that compiles with GHC 7.8 and 7.6;
• new README.md file that defines Megaparsec as something standalone, not in terms of Parsec;
• Megaparsec site with educational materials and tutorials.

Even although name Parsec is famous, I don't think I have rights on that name and renaming feels like additional overhead for me (maybe I'm just lazy). Thank you for the proposition though, it's much appreciated.

[mrkkrp]

@achudnov, But it seems like he indeed just ignores people, here is some activity related to a different (his own) project:

https://github.com/aslatter?tab=contributions&from=2015-10-22

I'm beginning to think that probably I should accept that proposition and became maintainer of Parsec. But to avoid confusion, Megaparsec will remain Megaparsec and Parsec will remain Parsec. However, I might be able to prepare “final” release of Parsec, 3.2.0 in which I might take the pain to fix critical bugs again without breaking compatibility with older versions of Parsec and perhaps port some tests. Then I could suspend development of Parsec with a message that would redirect people towards Megaparsec. At the same time we could tell people that if they don't like Megaparsec and they are ready to move Parsec forward, they are welcome to take over Parsec.

How about this idea?

[achudnov]

I don't think the Hackage admins are going to buy the idea of someone taking over a package when they (s)he doesn't intend to support it long term. But, feel free to give it a try. You can also talk to some of the other Parsec maintainers and see if they'd go along with the plan of you submitting a single large patch to Parsec and issuing recommendations to switch to Megapasec. Among them, @feuerbach appears to be the most active.

[recursion-ninja]

@achudnov Short term support is better then the current abandonment status of Parsec. I like @mrkkrp proposal of supporting a final stable version of Parsec with critical bugs fixed. For instance, my coworker and I were baffled for the better part of an hour by this bug. We realized days latter that the defect was in the library, not our reason skills...

I think the list of tracked and unfixed bugs in the Parsec repo should speak for itself when proposing the maintainership transfer. Especially given how @mrkkrp has pointed out solutions to many of the Parsec issues within the repo's bug tracker.

[mrkkrp]

Parsec's maintainer is back: https://github.com/aslatter/parsec. I hope he will be more active in the future.