all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


      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.