emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make regexp handling more regular


From: Philipp Stephani
Subject: Re: Make regexp handling more regular
Date: Wed, 2 Dec 2020 12:21:50 +0100

Am Mi., 2. Dez. 2020 um 12:14 Uhr schrieb Stefan Kangas
<stefankangas@gmail.com>:
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > So my idle shower thought for the day is: Is there any reasonable path
> > forward that the Emacs Lisp language could take here?
> >
> > Well, we obviously can't alter functions like `string-match' and
> > `re-search-forward' -- they have well-defined semantics, and we can't
> > make them return a match object.  But we could make a new set of
> > functions that are more, er, functional.
>
> I like the idea of adding an entirely new built-in API based on the
> current state of the art.  I would begin such a project by looking into
> what other Lisps are doing, such as CL, Clojure, Guile and Racket.  Why
> shouldn't Emacs Lisp be best-in-class?
>
> As for naming, how about just using a short prefix such as "re-"?
> AFAICT, we currently have only five functions using that prefix.
>
> Tangentially, I have always been wondering if its feasible to add a new
> regular expression type to `read' where you don't have to incessantly
> double quote all special characters.  (One could take inspiration from
> Python, for example, which adds an "r" character to strings to turn them
> into regexps: r"regexp".)
>

Yes, I think all of these make sense:
1. Support for stateless matching, with functions returning match
objects (like s-match, but also for searching)
2. Support for PCRE/"extended" regexp. Add customization options for
the interactive commands to read this dialect.
3. Support for raw strings, maybe using a syntax like #"...".

If we want to take more cues from other programming languages, we
should create a "compiled regex pattern" type. Multiple dialects
(traditional Emacs regexp, rx, PCRE) would then compile down to a
single such type.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]