FWIW, there is a similar project [1] which compiles a regex to bytecode. The benchmarks [2] are impressive.

[1] https://github.com/humio/jitrex [1] https://github.com/humio/jitrex?tab=readme-ov-file#performan...

A related project that might interest some people: https://github.com/telekons/one-more-re-nightmare

And the pretty hard to find blog post about it: https://applied-langua.ge/posts/omrn-compiler.html

By looking at the benchmarks, it is interesting to see how much an advantage have non-backtracking engines versus the default Java one. It is also interesting that most of the regular expressions I happen to write are not backtracking, so it’s likely I’m paying a ticket every time for a feature I’m not going to see.

It would be interesting if the default Java class the implements regular expressions would detect whether backtracking is actually used in the regular expression when it is compiled and decide whether the full blown engine is really necessary or a lightweight one would be enough.

C# does this as well. Its OOB Regex engine can compile expressions to automata at runtime, or there’s an alternate newer back-end to generate the source code at compile time, which is useful in AOT as you can’t JIT the IL there.

Similar to the blog post, this allows it to be one of the fastest: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa...

looks very interesting - coming from the perl (ie the original PCRE) it’s rather a pity that this is focused on the JVM since Java is not the most regex friendly authoring environment (sorry I do not know if other JVM denizens like Kotlin / Clojure have more natural regex syntax)

Larry Walls version 2 of PCRE is doing some interesting innovation which, while continuing the model of a character level syntax where punctuation <[.+*]> and so on are the “verbs” as the regex Sub-Language (one of the Slangs of raku), now provides deep support for unicode (eg. a digit test looks at the unicode properties, not just <[0..9]>), and can be gradually unpacked using <token> and <rule> methods all the way up to a full blown composable class based Grammar … so you can still write regex one-liners perl style but then evolve that to a small Grammar to reduce line noise and drive up code clarity

Are there any plans to provide your library on the MoarVM?