[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59333: [PATCH] Define macro dlet*
From: |
daanturo |
Subject: |
bug#59333: [PATCH] Define macro dlet* |
Date: |
Sat, 19 Nov 2022 12:29:24 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 |
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.
0001-Define-macro-dlet-asterisk.patch
Description: Text Data