[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37440: [PATCH] New rx implementation with extension constructs
From: |
Mattias Engdegård |
Subject: |
bug#37440: [PATCH] New rx implementation with extension constructs |
Date: |
Tue, 17 Sep 2019 14:49:51 +0200 |
[Continuing from
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00048.html]
Here is a new rx implementation (faster, easier to work with, fewer bugs,
better tests), and, as a separate patch, an rx extension mechanism adding the
macros `rx-define', `rx-let' and `rx-let-eval'.
The first patch is a ground-up rewrite of rx. It should be completely
compatible.
The second patch adds
(rx-define NAME [ARGS] RX)
(rx-let ((NAME [ARGS] RX) ...) BODY)
(rx-let-eval ((NAME [ARGS] RX) ...) BODY)
as mentioned in the emacs-devel thread earlier. Additions to the manual are
included.
Although I believe this to be a consistent and useful design that could be used
as-is, some points worth thinking about are:
* Allow for multiple RXs in the definitions, making an implicit (seq ...). This
could be done with the Schemeish syntax
(rx-define NAME RX...)
(rx-define (NAME ARGS...) RX...)
which is quite readable as "definition mirrors use". Should then the &rest
parameter be declared using a dotted list, as
(rx-define (NAME ARG1 ARG2 . ARG-REST) RX...)
?
* There is some disagreement regarding whether function-like definitions should
be standard Lisp expressions instead of the restricted substitution-based
macros in this patch, as in
(rx-define whole (x) `(seq bos ,x eos))
I believe the usability of the chosen design is better, but see the point of
not reinventing the wheel.
* Not entirely satisfied with the name `rx-let-eval', but unless someone comes
up with something better, it stands.
0001-New-rx-implementation.patch
Description: Binary data
0002-Add-rx-extension-mechanism.patch
Description: Binary data
- bug#37440: [PATCH] New rx implementation with extension constructs,
Mattias Engdegård <=