GNU bug report logs - #50136
28.0.50; A problem with rx-let expansion

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Fri, 20 Aug 2021 14:01:01 UTC

Severity: normal

Found in version 28.0.50

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#50136: closed (28.0.50; A problem with rx-let expansion)
Date: Mon, 23 Aug 2021 18:06:01 +0000
[Message part 1 (text/plain, inline)]
Your message dated Mon, 23 Aug 2021 20:05:26 +0200
with message-id <4A408FC9-3B89-40D9-9A88-60AA384BF9DC <at> acm.org>
and subject line Re: 28.0.50; A problem with rx-let expansion
has caused the debbugs.gnu.org bug report #50136,
regarding 28.0.50; A problem with rx-let expansion
to be marked as done.

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


-- 
50136: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50136
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: 28.0.50; A problem with rx-let expansion
Date: Fri, 20 Aug 2021 15:59:44 +0200
Hello,

I'm referring to this paragraph in rx.el:

;; FIXME: Consider adding extensions in Lisp macro style, where
;; arguments are passed unevaluated to code that returns the rx form
;; to use.
;; [...]
;; While this would permit more powerful extensions, it's unclear just
;; how often they would be used in practice.  Let's wait until there is
;; demand for it.

Ok - here is!  I would find that approach much more natural than the
current one.  Look:

Already the first `rx-let' pseudo macro I tried hit a problem (bug) with
the current approach:

#+begin_src emacs-lisp
(rx-let ((scatter (string)
                  (regex (mapconcat #'string (string-to-list string) ".*"))))
  (rx (scatter "abc"))) => useless error message
#+end_src

while the following version (the only difference is the argument name)
works as expected:

#+begin_src emacs-lisp
(rx-let ((scatter (s) (regex (mapconcat #'string (string-to-list s) ".*"))))
  (rx (scatter "abc"))) ==> "a.*b.*c"
#+end_src

Seems the function form #'string gets replaced and ends as #'"abc" in
the first version because the function name accidentally collides with
the argument name.

Personally I would be more happy with a thing called `rx-macrolet' than
with an extended `rx-let' to support this additional macro-like kind of
syntax.

TIA,

Michael.



[Message part 3 (message/rfc822, inline)]
From: Mattias Engdegård <mattiase <at> acm.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 50136-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 28.0.50; A problem with rx-let expansion
Date: Mon, 23 Aug 2021 20:05:26 +0200
23 aug. 2021 kl. 18.59 skrev Michael Heerdegen <michael_heerdegen <at> web.de>:

> Maybe at least one sentence about that this mechanism just performs
> trivial substitution?

I didn't do that now, because I couldn't see how it could be interpreted otherwise (and there's the manual link).

> I find the term "user-defined" distracting, because anybody (including
> library and package developers) is "affected".  Apart from that, ok for
> me.

Thank you, changed.

> Didn't try the example, but it looks good.

Thanks for looking at it. Good examples are always hard to write!

> | (eval EXPR)    Match the rx sexp from evaluating EXPR at compile time.
> 
> can we say "expansion time" instead of "compile time"?

We can, and now do!

Closing; I think we're done here (complain if not).



This bug report was last modified 3 years and 273 days ago.

Previous Next


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