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

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 50136 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#50136: 28.0.50; A problem with rx-let expansion
Date: Fri, 20 Aug 2021 20:45:41 +0200

20 aug. 2021 kl. 19.21 skrev Michael Heerdegen <michael_heerdegen <at> web.de>:

> I guess it's not very useful for the current mechanism.  With a
> macro-like thing, the expansion would just not use the value if it's nil.  The
> expander would check whether the argument was provided.

Yes. It was (and is) a trade-off between the simpler "template-like" semantics currently used and the programmatic "execute code" semantics of Lisp macros. The idea was that the simpler semantics would be simpler and sufficient for most uses, and `eval` forms could always be employed in other cases.

I'm still fretting over having made the wrong call, and that at least I should have omitted parametrised rx definitions until better understood.

If you just have one optional argument, try &rest -- at least its default-case semantics are crystal clear (no arguments inserted). Obviously, you could also use separate rx macros for different parameter lists:

(rx-let ((delimited (grp delim) (seq delim (group-n grp (* (not delim)) delim)))
         (double-quoted (grp) (delimited grp ?\")))

etc.

Previous Next

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