GNU bug report logs - #59333
[PATCH] Define macro dlet*

Previous Next

Full log

View this message in rfc822 format

From: daanturo <daanturo <at> gmail.com>
To: Jean Louis <bugs <at> gnu.support>
Cc: 59333 <at> debbugs.gnu.org
Subject: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 12:29:24 +0700

[Message part 1 (text/plain, inline)]

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 <at> 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.

[0001-Define-macro-dlet-asterisk.patch (text/x-patch, attachment)]

Previous Next

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