From: daanturo <daanturo@gmail.com>
To: Jean Louis <bugs@gnu.support>
Cc: 59333@debbugs.gnu.org
Subject: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 12:29:24 +0700 [thread overview]
Message-ID: <6ff5662c-eaaa-e8dd-2fa0-2c27c384cdaf@gmail.com> (raw)
In-Reply-To: <Y3hf1OAzc6Gi/VtQ@protected.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]
On @ 2022-11-17 13:36, Mattias Engdegård wrote:
> The proposed patch also appears incorrect
It was a mistake when I copying and pasting. This patch corrected that and
removed the erroneous breakage mention.
If there would ever be a vote to reduce the number of `let` variants to lighten
the maintenance burden, I bet that the `let*` ones will remain instead of the
versions without the ability to refer to prior bindings. As `let*` can cover
`let` but the reverse is impossible.
```emacs-lisp
(let* ((_a a)
(a (+ 1 _a))
(b (+ 2 _a))))
```
Therefore, in my opinion, new `XXXlet` macros variants should be defined like
`XXXlet*` instead, maybe with only `XXXlet*` without `XXXlet`, since we will
eventually need an asterisk version in the future anyway. (Also dash-like easy
destructuring is sweet if possible.)
Why do need to define (publicly) then maintain for eternity `letf`, `flet`,
`dlet`, `lexical-let`, `pcase-let`, `if-let`, `when-let`, etc. when only their
`*` versions should be exposed and encompass every use case just fine?
I think `and-let*` is the most sensible case here as it doesn't have a more
limited `and-let` version.
On 19/11/2022 11:47, Jean Louis wrote:
> * daanturo <daanturo@gmail.com> [2022-11-17 10:16]:
>> --=-=-=
>> Content-Type: text/plain
>>
>> Tags: patch
>>
>>
>> The dlet breakage comes as much surprise to me. There's not even a
>> single entry in NEWS that mentions it.
>>
>>
>> The last line of `dlet' is now: (let ,binders ,@body))) while I need
>> it to be as below: (let* ,binders ,@body))
>>
>>
--
Daanturo.
[-- Attachment #2: 0001-Define-macro-dlet-asterisk.patch --]
[-- Type: text/x-patch, Size: 2144 bytes --]
From 57fa015d03232e5517cb6d2082d24ef18ca88e24 Mon Sep 17 00:00:00 2001
From: Daanturo <daanturo@gmail.com>
Date: Sat, 19 Nov 2022 12:02:35 +0700
Subject: [PATCH] Define macro dlet*
* lisp/subr.el: implementation.
* doc/lispref/variables.texi: documentation.
* etc/NEWS: announce it.
---
doc/lispref/variables.texi | 6 ++++++
etc/NEWS | 5 +++++
lisp/subr.el | 8 ++++++++
3 files changed, 19 insertions(+)
diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
index 7206f2acd2..11a0f220ca 100644
--- a/doc/lispref/variables.texi
+++ b/doc/lispref/variables.texi
@@ -303,6 +303,12 @@ Local Variables
the forms, and then make the variables non-special again.
@end defspec
+@defspec dlet* (bindings@dots{}) forms@dots{}
+This form is like @code{dlet}, but each valueform can refer to the
+symbols already bound previously, like what @code{let*} is to
+@code{let}.
+@end defspec
+
@defspec named-let name bindings &rest body
This special form is a looping construct inspired from the
Scheme language. It is similar to @code{let}: It binds the variables in
diff --git a/etc/NEWS b/etc/NEWS
index 0b8f4539f9..11f9ccb26a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3269,6 +3269,11 @@ The following generalized variables have been made obsolete:
\f
* Lisp Changes in Emacs 29.1
+
++++
+** New macro 'dlet*'.
+Like what 'let*' is to 'let'.
+
+++
** Interpreted closures are "safe for space".
As was already the case for byte-compiled closures, instead of capturing
diff --git a/lisp/subr.el b/lisp/subr.el
index 6b83196d05..ecca52f99e 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2155,6 +2155,14 @@ dlet
binders)
(let ,binders ,@body)))
+(defmacro dlet* (binders &rest body)
+ "Like `let*' but using dynamic scoping."
+ (declare (indent 1) (debug let))
+ `(let (_)
+ ,@(mapcar (lambda (binder)
+ `(defvar ,(if (consp binder) (car binder) binder)))
+ binders)
+ (let* ,binders ,@body)))
(defmacro with-wrapper-hook (hook args &rest body)
"Run BODY, using wrapper functions from HOOK with additional ARGS.
--
2.38.1
prev parent reply other threads:[~2022-11-19 5:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 7:13 bug#59333: [PATCH] Define macro dlet* daanturo
2022-11-17 7:25 ` Eli Zaretskii
2022-11-17 7:40 ` Daan Ro
2022-11-19 4:37 ` Jean Louis
2022-11-17 13:22 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-17 13:36 ` Mattias Engdegård
2022-11-25 0:14 ` Stefan Kangas
2022-11-19 4:28 ` Jean Louis
2022-11-19 4:47 ` Jean Louis
2022-11-19 5:29 ` daanturo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ff5662c-eaaa-e8dd-2fa0-2c27c384cdaf@gmail.com \
--to=daanturo@gmail.com \
--cc=59333@debbugs.gnu.org \
--cc=bugs@gnu.support \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.