You can use lazy_static to have global Regex and call that from a Nom function. There is no special support from Nom required.
Alternatively one can build a parser combinator library that compiles to a large Regex. That Regex would return a big Matcher, so a convenience wrapper for that would need to be made usable by a wrapper created from the same parser combinator.
Alternatively one can build a parser combinator library that compiles to a large Regex.
Maybe I'm misunderstanding what you meant, but I don't think you can do this in the general case (since parser combinators can describe languages that are more complicated than/not describable within regular languages).
And having written these crates, I went back to writing Ruby for my day job. I am not a very experienced rustacean, and what skill I developed writing these things has faded, but I use the last one daily, so the regex-based parser is still working pretty well.
* It's a "parser combinator library" inasmuch as it allows you to write reusable parsing rules that can be components of other rules.
I think you shouldn't need to escape to regex for performance. I don't understand why would regex crate be so much faster in Rust? Some crazy optimizations the nom doesn't make?
Not an parser guru, but when I used megaparsec in Haskell course, I never thought I should switch to regex for speed.
Yes, there are crazy optimizations in the regex crate. :-)
But it almost certainly depends on what you're doing. If you're using Nom, you're probably performing a parsing task. A regex might be faster there, but maybe not by too much, depending. If you're doing a searching task though, perhaps where there are few matches relative to the size of the haystack, then it's quite plausible that the regex will go a lot more than 3x as fast as Nom.
In any case, I'm not sure if Haskell is comparable. I'm not sure that any Haskell native regex engine is really known for its speed, although I haven't done any sort of comprehensive benchmarking.
There are other considerations. A parser written with Nom might be easier to read and/or manipulate than a parser written with regex. But even there, it depends.
Comments
They must have combinator for regex so you can escape to it if needed.
You can use lazy_static to have global Regex and call that from a Nom function. There is no special support from Nom required.
Alternatively one can build a parser combinator library that compiles to a large Regex. That Regex would return a big Matcher, so a convenience wrapper for that would need to be made usable by a wrapper created from the same parser combinator.
Maybe I'm misunderstanding what you meant, but I don't think you can do this in the general case (since parser combinators can describe languages that are more complicated than/not describable within regular languages).
I wrote a crate to facilitate this:*
https://github.com/dfhoughton/pidgin
As it says there, you can only build non-recursive grammars this way.
And the reason I wrote that crate:
https://github.com/dfhoughton/two-timer
And the reason I wrote that crate:
https://github.com/dfhoughton/jobrog
And having written these crates, I went back to writing Ruby for my day job. I am not a very experienced rustacean, and what skill I developed writing these things has faded, but I use the last one daily, so the regex-based parser is still working pretty well.
* It's a "parser combinator library" inasmuch as it allows you to write reusable parsing rules that can be components of other rules.
I think you shouldn't need to escape to regex for performance. I don't understand why would regex crate be so much faster in Rust? Some crazy optimizations the nom doesn't make?
Not an parser guru, but when I used megaparsec in Haskell course, I never thought I should switch to regex for speed.
Yes, there are crazy optimizations in the regex crate. :-)
But it almost certainly depends on what you're doing. If you're using Nom, you're probably performing a parsing task. A regex might be faster there, but maybe not by too much, depending. If you're doing a searching task though, perhaps where there are few matches relative to the size of the haystack, then it's quite plausible that the regex will go a lot more than 3x as fast as Nom.
In any case, I'm not sure if Haskell is comparable. I'm not sure that any Haskell native regex engine is really known for its speed, although I haven't done any sort of comprehensive benchmarking.
There are other considerations. A parser written with Nom might be easier to read and/or manipulate than a parser written with regex. But even there, it depends.
Combinator alternatives, especially nested ones, will "naively" iteratate over cases until match is found.
In regexp those (nested) alternatives may be expressed much more efficiently as state machine or whatever.