emacs-bug-tracker
[Top][All Lists]
Advanced

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

bug#50136: closed (28.0.50; A problem with rx-let expansion)


From: GNU bug Tracking System
Subject: bug#50136: closed (28.0.50; A problem with rx-let expansion)
Date: Mon, 23 Aug 2021 18:06:01 +0000

Your message dated Mon, 23 Aug 2021 20:05:26 +0200
with message-id <4A408FC9-3B89-40D9-9A88-60AA384BF9DC@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@gnu.org.)


-- 
50136: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50136
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- 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.




--- End Message ---
--- Begin Message --- 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@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).



--- End Message ---

reply via email to

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