rx.el is one of the best concepts I've discovered in a long time.
It's another instance of "Don't come up with a new (mini)language when
Lisp can do better": it's easier to learn, more flexible, easier to
write, much easier to read and as a consequence much more maintainable.

> Some people, when confronted with a problem, think "I know, I'll use
> regular expressions." Now they have two problems.
> -- Jamie Zawinski

It's also much more "programmable" thanks to its `eval' expression.
(It's possible to count!)

See http://francismurillo.github.io/2017-03-30-Exploring-Emacs-rx-Macro/
for some nice examples.

I think it's high time we moved away from traditional regexps and
embraced the concept of rx.el.  I'm thinking of implementing it for
Guile.



At the moment the rx.el implementation is built on top of Emacs regexps
which are implemented in C.  I believe this does not use the power of
Lisp as much as it could.

The traditional regexps work in two steps: first build a blackbox
automaton from the string expression, then test if the input matches.

Building the automaton is costly.  In C, we build it once and save the
result in a variable so that every regexp match does not rebuild the
automaton each time.

In high-level languages, automatons are automatically cached to save the
cost of building them.

The rx.el library/concept could alleviate this issue altogether: because
we express the automaton directly in Lisp, the parsing step is not
needed and thus the building cost could be tremendously reduced.

So the rx.el building steps

  rx expression -> regexp string -> C regexp automaton

could boil down to simply

  rx automaton

It would be interesting to compare the performance.  This also means
that there would be no need for caching on behalf of the supporting
language.

What do you think?

--
Pierre Neidhardt