Actually one more thing I realized about this idea that would be wild... Since re2c itself is written in C, it can be easily compiled to wasm (even if it has a

Actually one more thing I realized about this idea that would be wild... Since re2c itself is written in C, it can be easily compiled to wasm (even if it has a few gotos). So then you get an engine that can compile user patterns at runtime, rather than having it be an offline process. (I don't really think there is that much difference in constraints between the offline and online processes, as some of have suggested. For example I observed that re2c compile time is linear with respect # constants strings in a large range in that benchmark.) I have been thinking of embedding wasm in Oil, mainly to do reasonably fast string transformations. Because one goal of Oil is to provide an alternative to extremely tortured string transformation syntax like: https://github.com/dylanaraps/pure-bash-bible https://github.com/dylanaraps/pure-bash-bible And Oil has the eggex language, that compiles to egrep syntax, and uses libc's engine. But it would be cool if it could compile to DFAs with an embedded re2c compiler. Then again, I was surprised that the compiled C code was not faster than an intepreter for small cases, so maybe this whole thing is too complex for the benefit... I guess I would have to do some up front benchmarks to see if this is even worth it. It could be that you need an extremely fast wasm engine to make it worthwhile, and all of those are tied to big JS engines and their very non-portable JITs. [1] https://johnwickerson.wordpress.com/2020/05/21/diagrams-for-composing-compilers/ https://johnwickerson.wordpress.com/2020/05/21/diagrams-for-... ---- edit: found some related comments: https://news.ycombinator.com/item?id=18553393 https://news.ycombinator.com/item?id=18553393 Surprise, the "totally shocking" result there is due to BACKTRACKING :) Automata-based regex in wasm beats native browser regex because it doesn't backtrack.