GNU bug report logs - #37440
[PATCH] New rx implementation with extension constructs

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#37440: closed ([PATCH] New rx implementation with extension
 constructs)
Date: Wed, 25 Sep 2019 21:31:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 25 Sep 2019 14:30:28 -0700
with message-id <ab02b59a-8729-827a-9266-1e81afe33e35 <at> cs.ucla.edu>
and subject line Re: [PATCH] New rx implementation with extension constructs
has caused the debbugs.gnu.org bug report #37440,
regarding [PATCH] New rx implementation with extension constructs
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
37440: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37440
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] New rx implementation with extension constructs
Date: Tue, 17 Sep 2019 14:49:51 +0200

[Message part 3 (text/plain, inline)]

[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 (application/octet-stream, attachment)]

[0002-Add-rx-extension-mechanism.patch (application/octet-stream, attachment)]

[Message part 6 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 37440-done <at> debbugs.gnu.org
Subject: Re: [PATCH] New rx implementation with extension constructs
Date: Wed, 25 Sep 2019 14:30:28 -0700

Thanks, I installed those patches into master and am closing the bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.