scala-parser-combinators vs fastparse

[SethTisue]

the following exchange between @odersky and @lihaoyi occurred on scala-debate recently:

@odersky Parser combinators is the same thing. It would be great to have a separate module which
improves on the current state.

@lihaoyi If you really are interested, such a thing exists http://lihaoyi.github.io/fastparse/ It's almost drop-in except a lot better to use. Not to mention 4-10x slowdown vs hand-rolled instead of the scala-parser-combinator's 400x

@odersky It would be great to see fastparse as a module in the stdlib! If you want to contribute it that would be much appreciated. The best way to get things rolling is via Slip: https://github.com/scala/slip

some further discussion on Gitter:

@soc I'm not sure I understood his plan. Is it replacing the actual implementation of scala.util.combinators? Is it getting rid of scala.util.combinators "preferred" status in terms of being an official module?

@SethTisue I don’t know either

@tpolecat you may register my vote for no preferred parser combinator library

@odersky I would like to encourage contributions, of whatever form. There's no plan yet. It depends where people want to take it. Anybody who takes initiative has my vote.

@SethTisue I’m definitely interested in discussing it. if Haoyi’s stuff is strictly superior to the old library in every important respect (Haoyi certainly seems to think it is! and if some interested folks could confirm that, what great news that would be), then scala-parser-combinators could be mothballed. although scala-parser-combinators is community-maintained these days, the Scala maintainers still have an interest in its status given that scala-parser-combinators is in the scala package and under the scala org on GitHub. and in the Artima book.

@odersky Who's maintaining scala-parser-combinators? It would be good to get their input as well.

@SethTisue Antoine Gourlay (@gourlaysama)

[Ichoran]

I would really like for fastparse to be part of the standard distribution (even if in a module and not the standard library). It's the kind of tool--often needed, hard to get right yourself, saves a ton of time if it's there--that is really a win for a standard library. I ended up creating my own parsing library focused on extreme performance (comparable to hand-rolled in many cases). Even though it's a bit fiddly to use, I use it all over the place. I'd use fastparse instead probably 80% of the time if there was no extra dependency to pull in and a more-certain maintenance future.

[SethTisue]

a significant past discussion on this (started by @soc in November 2014): https://groups.google.com/d/msg/scala-internals/4N-uK5YOtKI/teWdFXR290oJ

[puffnfresh]

The standard distribution should not include a parser combinator library.

[dickwall]

Could have both the old one and a new one in parallel for while.

Currently parser-combinators are already a separate module in the core library, also they are primarily community maintained.

[lihaoyi]

I've written up a section on Debugging Parsers in the FastParse documentation. If you actually care about parser combinators you should check it out, because this is one facet where FastParse is probably best-in-industry AFAICT.

[soc]

I'd prefer dropping scala-parser-combinators, and writing some migration document pointing to fastparse. (Pretty much similar to what happened with scala-actors vs. akka.)

[puffnfresh]

@soc 👍

[lihaoyi]

I'd prefer dropping scala-parser-combinators, and writing some migration document pointing to fastparse. (Pretty much similar to what happened with scala-actors vs. akka.)

I'd happy to give someone from The Powers That Be™ collaborator access to FastParse, if there's someone I trust actually cares about things.

So far, I've seen zero interest: no questions, no issues raised, no discussions on gitter, no PRs sent. There are people using it, but as far as I can tell nobody involved in this discussion has even downloaded the thing at all or read any documentation (not that there's any shortage of it).

It's probably a bit premature to talk about how we can FastParse the Official™ parser-combinator library =D

[Ichoran]

Once I finish wading through writing least squares fitting routines I'll need to parse stuff, and I'll use fastparse. I will probably complain bitterly that ~! is nothing like ! and thus is poorly chosen notation. Besides, it's a cut. Don't you want scissors notation? :<?

[lihaoyi]

I will probably complain bitterly that ~! is nothing like ! and thus is poorly chosen notation.

I just copied that from scala-parser-combinators! I had no active decision in picking it, I also haven't really seen Cut used much on the internet (despite how important I think they are) and I can't find any other examples of it used except in scala-parser-combinators and MacroPEG (which is again my own). After I managed to convince @sirthias to put cuts into Parboiled2, he chose ~!~ which IMHO is not much different.

As far as the name blame game goes, it seems to go to 2008 @adriaanm

(github doesn't do recursive blame AFAIK, so sorry @adriaanm if you are being wrongly blamed)

I don't think scissors have enough cuttiness in them; perhaps a sword would be more appropriate

p1 =||====> p2 | p3 =||====> p4