1 files changed, 37 insertions, 0 deletions

diff --git a/2024/talks/regex.md b/2024/talks/regex.md
new file mode 100644
index 00000000..32ea74f5
--- /dev/null
+++ b/2024/talks/regex.md
@@ -0,0 +1,37 @@
+[[!meta title="Emacs regex compilation and future directions for expressive pattern matching"]]
+[[!meta copyright="Copyright © 2024 Danny McClanahan"]]
+[[!inline pages="internal(2024/info/regex-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Emacs regex compilation and future directions for expressive pattern matching
+Danny McClanahan (they/them) - Pronunciation: məˈklænəˌhæn / mk-CLAN-uh-han, han like "hand", IRC: cosmicexplorer, @hipsterelectron@circumstances.run on mastodon - @hipsterelectron on twitter -  @cosmicexplorer on github - @cosmicexplorer in #emacsconf on irc.libera.chat, <mailto:dmcC2@hypnicjerk.ai>
+
+[[!inline pages="internal(2024/info/regex-before)" raw="yes"]]
+
+Emacs is a delightful case study for the capabilities of regular expressions, because Emacs forms user interfaces via text, which retains the expressivity of a GUI with the user-level interactivity of written language. Because we use text for both input and output, regexps in Emacs form part of a user-level grammar for human thought. As a result, Emacs and Emacs users have a rich intuitive grasp of regular expressions, which provides a unique vantage point to consider how they may be improved in general.
+
+When I began my investigation, I assumed that Emacs would be able to use an existing off-the-shelf regex engine, that this would be more performant than regex-emacs.c, and that the greatest challenge would be providing a sufficiently robust build process (see emacs-devel: <https://lists.gnu.org/archive/html/emacs-devel/2024-04/msg00142.html>). However, I quickly found that Emacs (as usual) is far more configurable than alternatives (see rust regex discussion: <https://github.com/rust-lang/regex/discussions/1167#discussioncomment-8585027>). Now don't get this twisted: emacs-devel was open to deprecating functionality that hampered optimization! But the biggest challenge by far is that regex-emacs.c is categorically more powerful than alternatives: it can match against <span class="underline">non-contiguous input</span> (across both halves of the gap buffer), as well as non-UTF8 text with its fantastic multibyte encoding (see <https://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html>).
+
+So a more complex picture begins to emerge: Emacs actually uses regexps far more widely and deeply than anywhere else, and its regex engine requirements aren't "legacy", but the result of caring more deeply about language than anywhere else. While regex engines have historically been known to introduce functionality not backed by formal theory that's later found to be hard to optimize, Emacs instead charts a path for other engines to follow. Formalizing backrefs is state-of-the-art, but possible (see <https://jamiejennings.com/posts/2021-09-23-dont-look-back-2/>), and I believe the same can be achieved for the other affordances Emacs users have come to expect. Subsequently, I have focused on identifying where we can constrain the problem space to improve performance without losing those affordances, such as explicit precompilation in lisp code (see <https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00108.html>).
+
+There are many branching paths here. With the libgccjit native compiler, we can now implement regex matching in lisp itself. While \`rx' can compose patterns to an extent, we could provide a more powerful primitive than regular expressions alone for complex parsing tasks. And while many regex engines employ complex optimization heuristics, we can instead introduce specific functionality for e.g. SIMD literal search into lisp code, allowing lisp users to intelligently select for themselves how and when to employ less-powerful but more-performant search routines.
+
+We don't need to backtrack! We can try all these paths at once.
+
+About the speaker:
+
+Me: Typing free software to break the shoulders of giants from golden handcuffs.
+Work: Composeable build tools, parsing frameworks, and cryptographic messaging. All of these are misused to subjugate and oppress, but I build infrastructure for positive liberties.
+
+This talk will cover my train of thought over the course of this year on how regex engines in general may be improved, and the discussions with emacs-devel that have helped me along. I hope this talk will convince people of the boundless future directions in text search. My PhD research will be inspired by the expressivity and power of Emacs.
+
+
+
+[[!inline pages="internal(2024/info/regex-after)" raw="yes"]]
+
+[[!inline pages="internal(2024/info/regex-nav)" raw="yes"]]
+
+